--sCl4DBWLRgiuxxT3j07oVDHxLGgSerO1O
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQHcBAEBAgAGBQJXu2MwAAoJEHLfOeFtWkyvFGsN/jYXjQm73u9zJwKi4TGX2DL1
3Xsvs8WfjG+K55Cc93FhzzlhTXqOW5fmdoyrQThCFmXC9ZYLSA7Pngmjv1lc4uF5
vUnx0BwiJJ/Ye9v8M78ubkDS+BZZbw148Wepm4DvZb7v9vUSKqCrXs9/vVxTnnd5
/zDNKRdP8dJHERttoGEK/i3Xnswhv6XvZU972wqqMJYNhWKYMTQYW5YKr3QaLNoB
wyrKUnsubR/Oh1yBe0GJw7YSEixoEFiLeoXLTdEgu6Mo+1dt4wjb7Mj/Hjso0H8h
cyniqcmv0Dw8q4b5ribbSgn9+0NrnIK/fn7bSBf44OLrXDwTRQgLp5fXOncOS+L9
b/9tdMZWi0+99ybyA2gpVSvBDyOnfdD3B9cURd2AKxuPnYXDW4yJ+UuNTfKod4E1
GQ2x/JczqveJq2WzMd22SVQiF5oRn9LRrcMAwNe0UZEWzPfX2NafpErFPxIZ+Ecz
yOqRNqMaawyUuWFXJUbnmp0TTX40dLCS0qhGMPzhKV+2fELk8Gk1sJJt798zPo9W
S/CmV8aX6uKpprJ4LtKzb6cKe8fkgn/9yl6JgzO+2gFd52CF9qYdD33991wnYDk=
=2Jh/
-----END PGP SIGNATURE-----
--sCl4DBWLRgiuxxT3j07oVDHxLGgSerO1O--
=========================================================================
Date: Mon, 22 Aug 2016 15:13:17 -0600
Reply-To: Orion Poplawski <[log in to unmask]>
Sender: Mailing list for Scientific Linux developers worldwide
<[log in to unmask]>
From: Orion Poplawski <[log in to unmask]>
Subject: Missing update
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
I can't seem to find the gssproxy-0.4.1-8 update anywhere in SL.
https://access.redhat.com/errata/RHBA-2016:1527
Did it get missed?
Thanks.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane [log in to unmask]
Boulder, CO 80301 http://www.cora.nwra.com
=========================================================================
Date: Mon, 22 Aug 2016 16:20:36 -0500
Reply-To: Pat Riehecky <[log in to unmask]>
Sender: Mailing list for Scientific Linux developers worldwide
<[log in to unmask]>
From: Pat Riehecky <[log in to unmask]>
Subject: Re: Missing update
Comments: To: Orion Poplawski <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
Thanks for the report, I'll get this published tomorrow.
Pat
On 08/22/2016 04:13 PM, Orion Poplawski wrote:
> I can't seem to find the gssproxy-0.4.1-8 update anywhere in SL.
>
> https://access.redhat.com/errata/RHBA-2016:1527
>
> Did it get missed?
>
> Thanks.
>
=========================================================================
Date: Tue, 23 Aug 2016 08:23:58 -0500
Reply-To: Pat Riehecky <[log in to unmask]>
Sender: Mailing list for Scientific Linux developers worldwide
<[log in to unmask]>
From: Pat Riehecky <[log in to unmask]>
Subject: Re: Pacemaker rebranding
Comments: To: "aleksander.baranowski" <[log in to unmask]>,
"[log in to unmask]" <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
I slapped together a debranding patch late last night. An updated
package should go out shortly.
Thanks for the report!
Pat
On 08/22/2016 03:40 PM, aleksander.baranowski wrote:
> Hi Pat,
>
> I found that CentOS has same problem.
>
> In
> http://ftp1.scientificlinux.org/linux/scientific/7.2/SRPMS/vendor/pcs-0.9.143-15.el7.src.rpm
>
> Source1: HAM-logo.png
> I made SL logo, it's probably not the best in the world, but it's best
> what I can do (I'm not into graphic, but I can give my xcf file anyone
> is interested :)).
> There is also pcs-0.9.143/pcsd/public/favicon.ico which you can replace
> with http://ftp1.scientificlinux.org/favicon.ico
>
> The thing that bother me is that there is Red Hat font, I don't if these
> font is Red Hat property.
> pcs-0.9.143/pcsd/public/css/overpass_bold-web.svg
>
>
> According to page source: and overpass.css it's used on final page.
>
>
> When we come final page.
> There is commented footer
> <!-- <div id="footer">
> <div id="copyright">© 2012</div> <a
> href="http://www.redhat.com">Red Hat, Inc.</a> <a
> href="http://access.redhat.com/"> Red Hat
> Customer Portal</a>
> <div id="help"><a href="#">Help</a></div>
> </div> -->
>
> So I attached:
> HAM-log.png # Red Hat
> HAM-log-new.png # SL logo I made
> to_rebrand3.png # How does page look like with logo and favicon changed.
> It's shot of FF made with ksnapshot.
>
> I don't know how should I put these together. I noticed that SL using
> some magic *.ini file for rpms, that has changes that should be done to rpm.
>
> I hope that it's helpful
> Alex
>
>
> PS. I will inform also CentOS devel about that.
>
> On 08/22/2016 05:47 PM, Pat Riehecky wrote:
>> Oh My!
>>
>> Thanks for finding this! You can send a patch to this list and I'll
>> look at getting a fix put together.
>>
>> Pat
>>
>> On 08/22/2016 10:36 AM, aleksander.baranowski wrote:
>>> Hello Guys,
>>>
>>> I found out that after installation of pcs fence-agents lvm2-cluster
>>> gfs2-utils and basic configuration of clustering the main page of
>>> pacemaker is Red Hat branded :(.
>>>
>>> I can introduce the patch for SL sources, but I don't where should I
>>> deliver them.
>>>
>>> I attached the image, for your convenience.
>>>
>>> Bests
>>> Alex Baranowski
>>>
>>> PS. I used RHEL documentation for this addon
>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/High_Availability_Add-On_Reference/Red_Hat_Enterprise_Linux-7-High_Availability_Add-On_Reference-en-US.pdf
>>>
=========================================================================
Date: Tue, 23 Aug 2016 15:27:50 +0200
Reply-To: Ansgar Hockmann-Stolle <[log in to unmask]>
Sender: Mailing list for Scientific Linux developers worldwide
<[log in to unmask]>
From: Ansgar Hockmann-Stolle <[log in to unmask]>
Subject: Re: repomd.xml timestamps
Comments: To: [log in to unmask]
Comments: cc: Orion Poplawski <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha-256; boundary="------------ms020503030605070905050001"
Message-ID: <[log in to unmask]>
--------------ms020503030605070905050001
Content-Type: multipart/mixed;
boundary="------------FB003D1F3A478DBE9EBA4E36"
This is a multi-part message in MIME format.
--------------FB003D1F3A478DBE9EBA4E36
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Am 02.06.2016 um 17:08 schrieb Orion Poplawski:
> On 05/26/2016 08:42 AM, Pat Riehecky wrote:
>>
>>
>> On 05/25/2016 05:06 PM, Orion Poplawski wrote:
>>> On 05/19/2016 06:49 PM, Steven Haigh wrote:
>>>> Just to bang the drum, seems this has come up again:
>>>>
>>>> /etc/cron.daily/0yum-daily.cron:
>>>>
>>>> Not using downloaded repomd.xml because it is older than what we hav=
e:
>>>> Current : Wed May 18 06:06:41 2016
>>>> Downloaded: Wed May 18 06:06:39 2016
>>>>
>>>> Sadly the cron job doesn't tell me which repo this was on.
>>>>
>>> It's appeared here again today with the sl7 fastbugs repo.
>>>
>>> I've attached the two different files.
>>>
>>
>> :(
>>
>> I've updated the push process yet again. At every step of the process=
it
>> verifies the timestamp is current.
>>
>> In theory this will really really really fix this.
>=20
> Note that my original diagnosis of needing to set --revision I believe =
now was
> incorrect and that the timestamp of the repo is determined by the newes=
t
> metadata file listed in repomd.xml.
As the problem still persists I tried to understand what happens by
looking at the source of yum ...
In yum/repoMDObject.py the timestamp of one data element of repomd.xml
will be the input of "int()":
try:
nts =3D int(thisdata.timestamp)
if nts > self.timestamp: # max() not in old python
self.timestamp =3D nts
except:
pass
Attached you will find the current repomd.xml from:
ftp://ftp.scientificlinux.org/linux/scientific/7/x86_64/updates/security/=
repodata/repomd.xml
as "ftp_repomd.xml" and the cached one from one of our SL7 machines as
"cached_repomd.xml". They are different in indenting and sequence! But
the main problem is the bad timestamp of the updateinfo data element in
ftp_repomd.xml:
<data type=3D"updateinfo">
[...]
<timestamp>1471637392.18</timestamp>
This is not an int. It will be ignored without a warning and the
resulting timestamp is not raised. The timestamp of the last good data
element in the repomd.xml will be used. That is the reason for our
warning with so small time differences.
Please find the tool which creates the bad timestamp ;-)
Ciao
Ansgar Hockmann-Stolle
--=20
Ansgar Hockmann-Stolle =C2=B7 Universit=C3=A4t Osnabr=C3=BCck =C2=B7 Rech=
enzentrum
Albrechtstra=C3=9Fe 28, 49076 Osnabr=C3=BCck, Deutschland =C2=B7 Raum 31/=
E77B
+49 541 969-2749 (fax -2470) =C2=B7 http://www.home.uos.de/anshockm
--------------FB003D1F3A478DBE9EBA4E36
Content-Type: text/xml;
name="ftp_repomd.xml"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="ftp_repomd.xml"
<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<repomd xmlns=3D"http://linux.duke.edu/metadata/repo" xmlns:rpm=3D"http:/=
/linux.duke.edu/metadata/rpm">
<revision>1471637144</revision>
<data type=3D"filelists">
<checksum type=3D"sha256">495b3a136198421c04ee028f810c7232bd93b6332333b=
f9ce65228febaa1830a</checksum>
<open-checksum type=3D"sha256">df19066fd132020a3d6e9042ec7495df17c8b400=
189916bcbb2ec3687249354b</open-checksum>
<location href=3D"repodata/filelists.xml.gz"/>
<timestamp>1471637175</timestamp>
<size>3774038</size>
<open-size>63689661</open-size>
</data>
<data type=3D"updateinfo">
<checksum type=3D"sha256">2e3be34a99cb6df7dd0133d985616366d40aa81384d53=
f083660ccafd309971e</checksum>
<open-checksum type=3D"sha256">88b8649d4788c3c86577c3368c811a8e066053b8=
4770b0dc9c69f8b0692a9501</open-checksum>
<location href=3D"repodata/updateinfo.xml.bz2"/>
<timestamp>1471637392.18</timestamp>
<size>83660</size>
</data>
<data type=3D"primary">
<checksum type=3D"sha256">d014afee3dbc717ec76dc5f2a57eb2ec643bc97defa7e=
c3b06007b98e44a43fb</checksum>
<open-checksum type=3D"sha256">2801b9a7fffa80c97f78801b79a03cdb1e7f240b=
f56d90acaa549a0e3b98d9f0</open-checksum>
<location href=3D"repodata/primary.xml.gz"/>
<timestamp>1471637175</timestamp>
<size>3013244</size>
<open-size>21464035</open-size>
</data>
<data type=3D"other">
<checksum type=3D"sha256">bb72c83b9dc8782ae801aaa7b7916d468c49d05820f8c=
5b4b834202d1eeca2cf</checksum>
<open-checksum type=3D"sha256">e0050fa8719876538b3c579c6e44de72bf63b8bb=
a9e9b22114c58c78265689f3</open-checksum>
<location href=3D"repodata/other.xml.gz"/>
<timestamp>1471637175</timestamp>
<size>96575</size>
<open-size>1121329</open-size>
</data>
<data type=3D"filelists_db">
<checksum type=3D"sha256">f1fdbc5012afe78a20665aa20be2283f161efb2aeeb37=
ee4d40c158e0a5ef85d</checksum>
<open-checksum type=3D"sha256">31e68234b48d66c36e24a354a6cdb031bab1a701=
b4774c354cba2a2a15fa2e48</open-checksum>
<location href=3D"repodata/filelists.sqlite.xz"/>
<timestamp>1471637215</timestamp>
<database_version>10</database_version>
<size>2418876</size>
<open-size>29546496</open-size>
</data>
<data type=3D"primary_db">
<checksum type=3D"sha256">bb34434028ea9e0dd3e070112a808acc7dcbc60da5a30=
305064993e416accbeb</checksum>
<open-checksum type=3D"sha256">70711d13f026c914afffe0a2124f095b4434ac30=
3cf039a18ee612bf14ce5490</open-checksum>
<location href=3D"repodata/primary.sqlite.xz"/>
<timestamp>1471637228</timestamp>
<database_version>10</database_version>
<size>2719292</size>
<open-size>26143744</open-size>
</data>
<data type=3D"other_db">
<checksum type=3D"sha256">0987ff405f73bb8b8eb9a0266bdf6339ae9f0ca741f7c=
43b77036b2c1f976bde</checksum>
<open-checksum type=3D"sha256">0f910d91446c845236719fd692efa4c0b5ed063b=
b6d43ae213bd3928e3fa5822</open-checksum>
<location href=3D"repodata/other.sqlite.xz"/>
<timestamp>1471637186</timestamp>
<database_version>10</database_version>
<size>96432</size>
<open-size>1147904</open-size>
</data>
</repomd>
--------------FB003D1F3A478DBE9EBA4E36
Content-Type: text/xml;
name="cached_repomd.xml"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="cached_repomd.xml"
<?xml version=3D"1.0" encoding=3D"UTF-8"?>
<repomd xmlns=3D"http://linux.duke.edu/metadata/repo" xmlns:rpm=3D"http:/=
/linux.duke.edu/metadata/rpm">
<revision>1471637144</revision>
<data type=3D"primary">
<checksum type=3D"sha256">d014afee3dbc717ec76dc5f2a57eb2ec643bc97defa=
7ec3b06007b98e44a43fb</checksum>
<open-checksum type=3D"sha256">2801b9a7fffa80c97f78801b79a03cdb1e7f24=
0bf56d90acaa549a0e3b98d9f0</open-checksum>
<location href=3D"repodata/primary.xml.gz"/>
<timestamp>1471637175</timestamp>
<size>3013244</size>
<open-size>21464035</open-size>
</data>
<data type=3D"filelists">
<checksum type=3D"sha256">495b3a136198421c04ee028f810c7232bd93b633233=
3bf9ce65228febaa1830a</checksum>
<open-checksum type=3D"sha256">df19066fd132020a3d6e9042ec7495df17c8b4=
00189916bcbb2ec3687249354b</open-checksum>
<location href=3D"repodata/filelists.xml.gz"/>
<timestamp>1471637175</timestamp>
<size>3774038</size>
<open-size>63689661</open-size>
</data>
<data type=3D"other">
<checksum type=3D"sha256">bb72c83b9dc8782ae801aaa7b7916d468c49d05820f=
8c5b4b834202d1eeca2cf</checksum>
<open-checksum type=3D"sha256">e0050fa8719876538b3c579c6e44de72bf63b8=
bba9e9b22114c58c78265689f3</open-checksum>
<location href=3D"repodata/other.xml.gz"/>
<timestamp>1471637175</timestamp>
<size>96575</size>
<open-size>1121329</open-size>
</data>
<data type=3D"primary_db">
<checksum type=3D"sha256">bb34434028ea9e0dd3e070112a808acc7dcbc60da5a=
30305064993e416accbeb</checksum>
<open-checksum type=3D"sha256">70711d13f026c914afffe0a2124f095b4434ac=
303cf039a18ee612bf14ce5490</open-checksum>
<location href=3D"repodata/primary.sqlite.xz"/>
<timestamp>1471637228</timestamp>
<size>2719292</size>
<open-size>26143744</open-size>
<database_version>10</database_version>
</data>
<data type=3D"filelists_db">
<checksum type=3D"sha256">f1fdbc5012afe78a20665aa20be2283f161efb2aeeb=
37ee4d40c158e0a5ef85d</checksum>
<open-checksum type=3D"sha256">31e68234b48d66c36e24a354a6cdb031bab1a7=
01b4774c354cba2a2a15fa2e48</open-checksum>
<location href=3D"repodata/filelists.sqlite.xz"/>
<timestamp>1471637215</timestamp>
<size>2418876</size>
<open-size>29546496</open-size>
<database_version>10</database_version>
</data>
<data type=3D"other_db">
<checksum type=3D"sha256">0987ff405f73bb8b8eb9a0266bdf6339ae9f0ca741f=
7c43b77036b2c1f976bde</checksum>
<open-checksum type=3D"sha256">0f910d91446c845236719fd692efa4c0b5ed06=
3bb6d43ae213bd3928e3fa5822</open-checksum>
<location href=3D"repodata/other.sqlite.xz"/>
<timestamp>1471637186</timestamp>
<size>96432</size>
<open-size>1147904</open-size>
<database_version>10</database_version>
</data>
<data type=3D"updateinfo">
<checksum type=3D"sha">ccf9939bed0b83b37bc8300b9b749742c7cc6d19</chec=
ksum>
<open-checksum type=3D"sha">fd042d7283d37cd46e3d7cf51503abd63a7130fe<=
/open-checksum>
<location href=3D"repodata/updateinfo.xml.bz2"/>
<timestamp>1471637230</timestamp>
<size>86120</size>
<open-size>581285</open-size>
</data>
</repomd>
--------------FB003D1F3A478DBE9EBA4E36--
--------------ms020503030605070905050001
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
EKQwggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJE
RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy
dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQw
NzIyMTIwODI2WhcNMTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZO
LVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xv
YmFsIC0gRzAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTD
llA1PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1
OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8B
r3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9
bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSa
cXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQD
AgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQxw3kbuvVT
1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1UdIARbMFkwEQYPKwYBBAGB
rSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAQEEAwEwDwYNKwYB
BAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1odHRwOi8vcGtp
MDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEEbDBqMCwG
CCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEFBQcw
AoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq
hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhth
Jxb/w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvN
TVx07iHydQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEs
jmpttzUCGc/1OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6h
L5Kp2AvGhB8Exuse6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtU
FzCCBXAwggRYoAMCAQICBxekJHxXsqgwDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUx
EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1W
ZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA1MjcxNDUzMzNaFw0xOTA3MDkyMzU5MDBa
MIGRMQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0IE9zbmFicnVlY2sxFjAU
BgNVBAsTDVJlY2hlbnplbnRydW0xIzAhBgNVBAMTGlVuaS1Pc25hYnJ1ZWNrIFJaLUNBIEct
MDAyMSMwIQYJKoZIhvcNAQkBFhRjYUB1bmktb3NuYWJydWVjay5kZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAKS2cVeotteLlgW93NegDHJJLozyjF8ZfWeF7BCIawOO7RuW
C/bqXlK4/nbg3K2xEL6Yb0lyRb3lZCytSTADRybrv1mt9gXPCEZY2AaoWijExkTtauS+o5DA
Q8AcHp6M4ZRgGqhvvAsvqnBaFGqFgUQh9vvreRbV8ktf9RioVru8kMQm5Rbpe1V75yysmjZT
mk2pURF2/aUJNjd9fq6zoMJG6IMXNs99IEACV3idkWtEpUXqiDTJnA3eJX5bl4waRZoiWuMR
4UCFSaVtrxfHW6pniqsSKGM4gYe/DRmqjEgvCGwz2wjN6mg2hlFinHIG/0imb6zUy1Po3Fuu
shotWD8CAwEAAaOCAgEwggH9MBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEG
MBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUqh/YdxVumeRfkNbsYyZOGepnFFAwHwYD
VR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0RBBgwFoEUY2FAdW5pLW9zbmFi
cnVlY2suZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ds
b2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2Eu
ZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSB
yjCBxzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9P
Q1NQMEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNh
L3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRm
bi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEL
BQADggEBAKVT0ta1DB/aFrtNpyRw1Qu4xe+MFGG8xWl9VC7ZBBlytDFdh8kfJGd7dfanJhM4
KP3mmL+fjhP5zJzR1lB/8m0zd20BRSuPi/uNksEZEp8l1ULG9/DbFJJ6QwJVHkffo7+a5ISB
ebvrESF0gdZc6KIbVVJGLAudFDtS+G1nISuwxPvttjQ4k4LaBVsAtZ59sLfBWEweCCGwjqIB
COnxVyB2ZBugZS4mJjxZmzXz8DSab9uYPOz9El6UEdbsUr+IIi+qOl1ggyaZwhAOPtNvWWC2
RtHtW0s5OMCPoaNPKMTbPAezT5R9qYzqauNKWcL1cOa6dp7t1uQmg8YB3cVwV+QwggZTMIIF
O6ADAgECAgcahg7mc/nGMA0GCSqGSIb3DQEBCwUAMIGRMQswCQYDVQQGEwJERTEgMB4GA1UE
ChMXVW5pdmVyc2l0YWV0IE9zbmFicnVlY2sxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xIzAh
BgNVBAMTGlVuaS1Pc25hYnJ1ZWNrIFJaLUNBIEctMDAyMSMwIQYJKoZIhvcNAQkBFhRjYUB1
bmktb3NuYWJydWVjay5kZTAeFw0xNTEyMDgwODE0MTVaFw0xODEyMDcwODE0MTVaMGgxCzAJ
BgNVBAYTAkRFMSAwHgYDVQQKDBdVbml2ZXJzaXRhZXQgT3NuYWJydWVjazEWMBQGA1UECwwN
UmVjaGVuemVudHJ1bTEfMB0GA1UEAwwWQW5zZ2FyIEhvY2ttYW5uLVN0b2xsZTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKzzGc/gHTBUBbJVTtrucu8+1ksMPpYYJRoOCcLa
tCQzqAdcfic518A3/EAj0PDbaqC7r/kOTMwalsj0e4fVyoBmXKRkzInHft77QQwJK/d+GAVX
xEqMOw1GAUiYsREQZX32MGne6EwD09VSYuzT23MOiWzTe3IkPvnbXzlNYP39IofaiGGH5VHG
XxwZfLKRhech6nrVQIN+ey7+lREGt4RJxwZf821cpOoBV838YOtoK0F4W9z4pf6oXjlRDUrc
LRobXr3LR5snD6QhIfKwb0h6NcNbwJYo/vYbqSGEwOl+P8RHhPnrBDfHxB8BR+skMZDoIZ2g
/49ZXblIiTmDz38CAwEAAaOCAtYwggLSMEAGA1UdIAQ5MDcwEQYPKwYBBAGBrSGCLAEBBAME
MBEGDysGAQQBga0hgiwCAQQDATAPBg0rBgEEAYGtIYIsAQEEMAkGA1UdEwQCMAAwCwYDVR0P
BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU2Ym3BPvE
Uclul21UPyxv0I8LaLkwHwYDVR0jBBgwFoAUqh/YdxVumeRfkNbsYyZOGepnFFAwgaQGA1Ud
EQSBnDCBmYEoQW5zZ2FyLkhvY2ttYW5uLVN0b2xsZUB1bmktb3NuYWJydWVjay5kZYEdQW5z
Z2FyLkhvY2ttYW5uLVN0b2xsZUB1b3MuZGWBGmFuc2hvY2ttQHVuaS1vc25hYnJ1ZWNrLmRl
gQ9hbnNob2NrbUB1b3MuZGWBCmFoc0B1b3MuZGWBFWFoc0B1bmktb3NuYWJydWVjay5kZTCB
jwYDVR0fBIGHMIGEMECgPqA8hjpodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1vc25hYnJ1
ZWNrLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMECgPqA8hjpodHRwOi8vY2RwMi5wY2EuZGZuLmRl
L3VuaS1vc25hYnJ1ZWNrLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHdBggrBgEFBQcBAQSB0DCB
zTAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ
MEoGCCsGAQUFBzAChj5odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1vc25hYnJ1ZWNrLWNh
L3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDIucGNhLmRm
bi5kZS91bmktb3NuYWJydWVjay1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN
AQELBQADggEBAGEzfS8Q3g9PipONE56NeqwDYTwldVesorPZgo4kxtRfLwFca9yfZKF9kit6
ZMnI/TgJDam69kw8UJ9pg7/XDClqF+296ytSPQONsB8TSSgaKxweNf+oBuwwjbTJVmxCsMCp
h6l//eHC2YYpIS/UowpuB4ocoAxFKiRPJUq5KdQWeb+TPZe5Gmdb0dKNnpajdmVcDViSueuZ
t1cAzEm7JGj05W+aS6RtoaTFztUoJQWsTk1xCysD1Z+2q39MlnErCGPvCvphhTncd27IPWgI
H4iDHqJezv/0hDMXjbWWY2LZgEPwpjfr6R8AAKSYIKQlqzi8iVIrdyPLL4BQXKYyvGcxggQI
MIIEBAIBATCBnTCBkTELMAkGA1UEBhMCREUxIDAeBgNVBAoTF1VuaXZlcnNpdGFldCBPc25h
YnJ1ZWNrMRYwFAYDVQQLEw1SZWNoZW56ZW50cnVtMSMwIQYDVQQDExpVbmktT3NuYWJydWVj
ayBSWi1DQSBHLTAwMjEjMCEGCSqGSIb3DQEJARYUY2FAdW5pLW9zbmFicnVlY2suZGUCBxqG
DuZz+cYwDQYJYIZIAWUDBAIBBQCgggI7MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTE2MDgyMzEzMjc1MFowLwYJKoZIhvcNAQkEMSIEIEPpd7InzsOqCh8x
IAJfAbS36174YGJ6gDW/wroeT2+fMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsG
CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwga4GCSsGAQQBgjcQBDGBoDCBnTCBkTELMAkGA1UE
BhMCREUxIDAeBgNVBAoTF1VuaXZlcnNpdGFldCBPc25hYnJ1ZWNrMRYwFAYDVQQLEw1SZWNo
ZW56ZW50cnVtMSMwIQYDVQQDExpVbmktT3NuYWJydWVjayBSWi1DQSBHLTAwMjEjMCEGCSqG
SIb3DQEJARYUY2FAdW5pLW9zbmFicnVlY2suZGUCBxqGDuZz+cYwgbAGCyqGSIb3DQEJEAIL
MYGgoIGdMIGRMQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0IE9zbmFicnVl
Y2sxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xIzAhBgNVBAMTGlVuaS1Pc25hYnJ1ZWNrIFJa
LUNBIEctMDAyMSMwIQYJKoZIhvcNAQkBFhRjYUB1bmktb3NuYWJydWVjay5kZQIHGoYO5nP5
xjANBgkqhkiG9w0BAQEFAASCAQCKnTtAV9Mf+sIFXujEdj6wL5+oyNu656I1djS48ZQLsnz7
jxjH2vXVPCH51ThUX4cJZaEtuoysbOH3zZdXRQ+nN5YaYGuoR0UTcUzah4LeiV1Qy1RY78/4
T3QOHydD2agxrh8aeYigBs2DEZt4UeY7zzVmYEIT7gWhVdaZQ3qk/2KcXtQOEqzqa2TW6r3N
Z7dZotlO74ooy5yqhTTy0hM1S4ggdaqQ6oHMlVxri13SMDyKOIaxZwaLr0XTkeBq7xh2gBp2
fEIM/1/B1PFgfo5NY1ZlKC0oreRANt4pPHbTABavkN8X5lZotppRGUZzlof2+KCx2Eu58HTh
w0lA9Mw+AAAAAAAA
--------------ms020503030605070905050001--
=========================================================================
Date: Tue, 23 Aug 2016 09:06:33 -0500
Reply-To: Pat Riehecky <[log in to unmask]>
Sender: Mailing list for Scientific Linux developers worldwide
<[log in to unmask]>
From: Pat Riehecky <[log in to unmask]>
Subject: Re: repomd.xml timestamps
Comments: To: Ansgar Hockmann-Stolle <[log in to unmask]>
Comments: cc: Orion Poplawski <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <[log in to unmask]>
On 08/23/2016 08:27 AM, Ansgar Hockmann-Stolle wrote:
>
> Am 02.06.2016 um 17:08 schrieb Orion Poplawski:
>> On 05/26/2016 08:42 AM, Pat Riehecky wrote:
>>>
>>> On 05/25/2016 05:06 PM, Orion Poplawski wrote:
>>>> On 05/19/2016 06:49 PM, Steven Haigh wrote:
>>>>> Just to bang the drum, seems this has come up again:
>>>>>
>>>>> /etc/cron.daily/0yum-daily.cron:
>>>>>
>>>>> Not using downloaded repomd.xml because it is older than what we have:
>>>>> Current : Wed May 18 06:06:41 2016
>>>>> Downloaded: Wed May 18 06:06:39 2016
>>>>>
>>>>> Sadly the cron job doesn't tell me which repo this was on.
>>>>>
>>>> It's appeared here again today with the sl7 fastbugs repo.
>>>>
>>>> I've attached the two different files.
>>>>
>>> :(
>>>
>>> I've updated the push process yet again. At every step of the process it
>>> verifies the timestamp is current.
>>>
>>> In theory this will really really really fix this.
>> Note that my original diagnosis of needing to set --revision I believe now was
>> incorrect and that the timestamp of the repo is determined by the newest
>> metadata file listed in repomd.xml.
> As the problem still persists I tried to understand what happens by
> looking at the source of yum ...
>
> In yum/repoMDObject.py the timestamp of one data element of repomd.xml
> will be the input of "int()":
>
> try:
> nts = int(thisdata.timestamp)
> if nts > self.timestamp: # max() not in old python
> self.timestamp = nts
> except:
> pass
>
> Attached you will find the current repomd.xml from:
>
> ftp://ftp.scientificlinux.org/linux/scientific/7/x86_64/updates/security/repodata/repomd.xml
>
> as "ftp_repomd.xml" and the cached one from one of our SL7 machines as
> "cached_repomd.xml". They are different in indenting and sequence! But
> the main problem is the bad timestamp of the updateinfo data element in
> ftp_repomd.xml:
>
> <data type="updateinfo">
> [...]
> <timestamp>1471637392.18</timestamp>
>
> This is not an int. It will be ignored without a warning and the
> resulting timestamp is not raised. The timestamp of the last good data
> element in the repomd.xml will be used. That is the reason for our
> warning with so small time differences.
>
> Please find the tool which creates the bad timestamp ;-)
>
> Ciao
> Ansgar Hockmann-Stolle
>
Thanks for the report! I'll confess a bit of sorrow, but that is mostly
because I'd swear I'd fixed this a dozen or so times now.
At this point, the thing that writes the updateinfo.xml makes sure it is
older than repomd.xml, the thing that adds it into repomd.xml makes sure
it is older than repomd.xml before it was added, and the report script
checks all of this.
Ok, I'd swear now that every piece of the process tries to set the
timestamp right at every step... of course I've said that before...
Pat
=========================================================================
Date: Wed, 24 Aug 2016 10:23:01 +0200
Reply-To: Ansgar Hockmann-Stolle <[log in to unmask]>
Sender: Mailing list for Scientific Linux developers worldwide
<[log in to unmask]>
From: Ansgar Hockmann-Stolle <[log in to unmask]>
Subject: Re: repomd.xml timestamps
Comments: To: Pat Riehecky <[log in to unmask]>
Comments: cc: Orion Poplawski <[log in to unmask]>
In-Reply-To: <[log in to unmask]>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha-256; boundary="------------ms000005070804020201020104"
Message-ID: <[log in to unmask]>
--------------ms000005070804020201020104
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Am 23.08.2016 um 16:06 schrieb Pat Riehecky:
> On 08/23/2016 08:27 AM, Ansgar Hockmann-Stolle wrote:
>>
>> Am 02.06.2016 um 17:08 schrieb Orion Poplawski:
>>> On 05/26/2016 08:42 AM, Pat Riehecky wrote:
>>>>
>>>> On 05/25/2016 05:06 PM, Orion Poplawski wrote:
>>>>> On 05/19/2016 06:49 PM, Steven Haigh wrote:
>>>>>> Just to bang the drum, seems this has come up again:
>>>>>>
>>>>>> /etc/cron.daily/0yum-daily.cron:
>>>>>>
>>>>>> Not using downloaded repomd.xml because it is older than what we
>>>>>> have:
>>>>>> Current : Wed May 18 06:06:41 2016
>>>>>> Downloaded: Wed May 18 06:06:39 2016
>>>>>>
>>>>>> Sadly the cron job doesn't tell me which repo this was on.
>>>>>>
>>>>> It's appeared here again today with the sl7 fastbugs repo.
>>>>>
>>>>> I've attached the two different files.
>>>>>
>>>> :(
>>>>
>>>> I've updated the push process yet again. At every step of the
>>>> process it
>>>> verifies the timestamp is current.
>>>>
>>>> In theory this will really really really fix this.
>>> Note that my original diagnosis of needing to set --revision I
>>> believe now was
>>> incorrect and that the timestamp of the repo is determined by the new=
est
>>> metadata file listed in repomd.xml.
>> As the problem still persists I tried to understand what happens by
>> looking at the source of yum ...
>>
>> In yum/repoMDObject.py the timestamp of one data element of repomd.xml=
>> will be the input of "int()":
>>
>> try:
>> nts =3D int(thisdata.timestamp)
>> if nts > self.timestamp: # max() not in old python
>> self.timestamp =3D nts
>> except:
>> pass
>>
>> Attached you will find the current repomd.xml from:
>>
>> ftp://ftp.scientificlinux.org/linux/scientific/7/x86_64/updates/securi=
ty/repodata/repomd.xml
>>
>>
>> as "ftp_repomd.xml" and the cached one from one of our SL7 machines as=
>> "cached_repomd.xml". They are different in indenting and sequence! But=
>> the main problem is the bad timestamp of the updateinfo data element i=
n
>> ftp_repomd.xml:
>>
>> <data type=3D"updateinfo">
>> [...]
>> <timestamp>1471637392.18</timestamp>
>>
>> This is not an int. It will be ignored without a warning and the
>> resulting timestamp is not raised. The timestamp of the last good data=
>> element in the repomd.xml will be used. That is the reason for our
>> warning with so small time differences.
>>
>> Please find the tool which creates the bad timestamp ;-)
>>
>> Ciao
>> Ansgar Hockmann-Stolle
>>
>=20
> Thanks for the report! I'll confess a bit of sorrow, but that is mostl=
y
> because I'd swear I'd fixed this a dozen or so times now.
>=20
> At this point, the thing that writes the updateinfo.xml makes sure it i=
s
> older than repomd.xml, the thing that adds it into repomd.xml makes sur=
e
> it is older than repomd.xml before it was added, and the report script
> checks all of this.
>=20
> Ok, I'd swear now that every piece of the process tries to set the
> timestamp right at every step... of course I've said that before...
Do we talk about the same timestamp? I just did this:
> [root@vm476 ~]# yum clean metadata
> Quellen werden aufger=C3=A4umt:rz sl sl-extras sl-fastbugs sl-security
> 21 metadata Dateien entfernt
> 9 sqlite Dateien entfernt
> 0 metadata Dateien entfernt
> [root@vm476 ~]# yum check-update
> rz | 951 B 0=
0:00 =20
> sl | 3.7 kB 0=
0:00 =20
> sl-extras | 3.0 kB 0=
0:00
> sl-fastbugs | 2.9 kB 0=
0:00
> sl-security | 2.9 kB 0=
0:00
> (1/9): sl-extras/x86_64/updateinfo | 23 kB 0=
0:00
> (2/9): sl/x86_64/group_gz | 107 kB 0=
0:00
> (3/9): sl-fastbugs/x86_64/updateinfo | 76 kB 0=
0:00
> (4/9): sl-extras/x86_64/primary_db | 118 kB 0=
0:00
> (5/9): sl-security/x86_64/updateinfo | 82 kB 0=
0:00
> (6/9): sl/x86_64/updateinfo | 1.4 MB 0=
0:02
> (7/9): sl-fastbugs/x86_64/primary_db | 1.6 MB 0=
0:02
> (8/9): sl-security/x86_64/primary_db | 2.6 MB 0=
0:02
> (9/9): sl/x86_64/primary_db | 4.6 MB 0=
0:03
> rz/7/x86_64/primary | 13 kB 0=
0:00
> rz =
33/33
>=20
> kernel.x86_64 3.10.0-327.28.3.el7 sl=
-security
> kernel-tools.x86_64 3.10.0-327.28.3.el7 sl=
-security
> kernel-tools-libs.x86_64 3.10.0-327.28.3.el7 sl=
-security
> [root@vm476 ~]# egrep 'timestamp.*\.' $(find /var/cache/yum/ -name rep=
omd.xml)
> /var/cache/yum/x86_64/7/sl-fastbugs/repomd.xml: <timestamp>1471960896.=
16</timestamp>
> /var/cache/yum/x86_64/7/sl-security/repomd.xml: <timestamp>1471961274.=
74</timestamp>
Upps! Yum uses this <timestamp> XML-element, not the inode timestamp.
And with the "." it will fail.
Good luck with bug hunting!
Ansgar
--=20
Ansgar Hockmann-Stolle =C2=B7 Universit=C3=A4t Osnabr=C3=BCck =C2=B7 Rech=
enzentrum
Albrechtstra=C3=9Fe 28, 49076 Osnabr=C3=BCck, Deutschland =C2=B7 Raum 31/=
E77B
+49 541 969-2749 (fax -2470) =C2=B7 http://www.home.uos.de/anshockm
--------------ms000005070804020201020104
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC
EKQwggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJE
RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy
dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQw
NzIyMTIwODI2WhcNMTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZO
LVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xv
YmFsIC0gRzAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTD
llA1PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1
OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8B
r3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9
bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSa
cXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQD
AgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQxw3kbuvVT
1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1UdIARbMFkwEQYPKwYBBAGB
rSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAQEEAwEwDwYNKwYB
BAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1odHRwOi8vcGtp
MDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEEbDBqMCwG
CCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEFBQcw
AoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq
hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhth
Jxb/w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvN
TVx07iHydQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEs
jmpttzUCGc/1OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6h
L5Kp2AvGhB8Exuse6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtU
FzCCBXAwggRYoAMCAQICBxekJHxXsqgwDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUx
EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1W
ZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA1MjcxNDUzMzNaFw0xOTA3MDkyMzU5MDBa
MIGRMQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0IE9zbmFicnVlY2sxFjAU
BgNVBAsTDVJlY2hlbnplbnRydW0xIzAhBgNVBAMTGlVuaS1Pc25hYnJ1ZWNrIFJaLUNBIEct
MDAyMSMwIQYJKoZIhvcNAQkBFhRjYUB1bmktb3NuYWJydWVjay5kZTCCASIwDQYJKoZIhvcN
AQEBBQADggEPADCCAQoCggEBAKS2cVeotteLlgW93NegDHJJLozyjF8ZfWeF7BCIawOO7RuW
C/bqXlK4/nbg3K2xEL6Yb0lyRb3lZCytSTADRybrv1mt9gXPCEZY2AaoWijExkTtauS+o5DA
Q8AcHp6M4ZRgGqhvvAsvqnBaFGqFgUQh9vvreRbV8ktf9RioVru8kMQm5Rbpe1V75yysmjZT
mk2pURF2/aUJNjd9fq6zoMJG6IMXNs99IEACV3idkWtEpUXqiDTJnA3eJX5bl4waRZoiWuMR
4UCFSaVtrxfHW6pniqsSKGM4gYe/DRmqjEgvCGwz2wjN6mg2hlFinHIG/0imb6zUy1Po3Fuu
shotWD8CAwEAAaOCAgEwggH9MBIGA1UdEwEB/wQIMAYBAf8CAQEwDgYDVR0PAQH/BAQDAgEG
MBEGA1UdIAQKMAgwBgYEVR0gADAdBgNVHQ4EFgQUqh/YdxVumeRfkNbsYyZOGepnFFAwHwYD
VR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYDVR0RBBgwFoEUY2FAdW5pLW9zbmFi
cnVlY2suZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2ds
b2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRwOi8vY2RwMi5wY2Eu
ZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHXBggrBgEFBQcBAQSB
yjCBxzAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9P
Q1NQMEcGCCsGAQUFBzAChjtodHRwOi8vY2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNh
L3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDIucGNhLmRm
bi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcNAQEL
BQADggEBAKVT0ta1DB/aFrtNpyRw1Qu4xe+MFGG8xWl9VC7ZBBlytDFdh8kfJGd7dfanJhM4
KP3mmL+fjhP5zJzR1lB/8m0zd20BRSuPi/uNksEZEp8l1ULG9/DbFJJ6QwJVHkffo7+a5ISB
ebvrESF0gdZc6KIbVVJGLAudFDtS+G1nISuwxPvttjQ4k4LaBVsAtZ59sLfBWEweCCGwjqIB
COnxVyB2ZBugZS4mJjxZmzXz8DSab9uYPOz9El6UEdbsUr+IIi+qOl1ggyaZwhAOPtNvWWC2
RtHtW0s5OMCPoaNPKMTbPAezT5R9qYzqauNKWcL1cOa6dp7t1uQmg8YB3cVwV+QwggZTMIIF
O6ADAgECAgcahg7mc/nGMA0GCSqGSIb3DQEBCwUAMIGRMQswCQYDVQQGEwJERTEgMB4GA1UE
ChMXVW5pdmVyc2l0YWV0IE9zbmFicnVlY2sxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xIzAh
BgNVBAMTGlVuaS1Pc25hYnJ1ZWNrIFJaLUNBIEctMDAyMSMwIQYJKoZIhvcNAQkBFhRjYUB1
bmktb3NuYWJydWVjay5kZTAeFw0xNTEyMDgwODE0MTVaFw0xODEyMDcwODE0MTVaMGgxCzAJ
BgNVBAYTAkRFMSAwHgYDVQQKDBdVbml2ZXJzaXRhZXQgT3NuYWJydWVjazEWMBQGA1UECwwN
UmVjaGVuemVudHJ1bTEfMB0GA1UEAwwWQW5zZ2FyIEhvY2ttYW5uLVN0b2xsZTCCASIwDQYJ
KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKzzGc/gHTBUBbJVTtrucu8+1ksMPpYYJRoOCcLa
tCQzqAdcfic518A3/EAj0PDbaqC7r/kOTMwalsj0e4fVyoBmXKRkzInHft77QQwJK/d+GAVX
xEqMOw1GAUiYsREQZX32MGne6EwD09VSYuzT23MOiWzTe3IkPvnbXzlNYP39IofaiGGH5VHG
XxwZfLKRhech6nrVQIN+ey7+lREGt4RJxwZf821cpOoBV838YOtoK0F4W9z4pf6oXjlRDUrc
LRobXr3LR5snD6QhIfKwb0h6NcNbwJYo/vYbqSGEwOl+P8RHhPnrBDfHxB8BR+skMZDoIZ2g
/49ZXblIiTmDz38CAwEAAaOCAtYwggLSMEAGA1UdIAQ5MDcwEQYPKwYBBAGBrSGCLAEBBAME
MBEGDysGAQQBga0hgiwCAQQDATAPBg0rBgEEAYGtIYIsAQEEMAkGA1UdEwQCMAAwCwYDVR0P
BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNVHQ4EFgQU2Ym3BPvE
Uclul21UPyxv0I8LaLkwHwYDVR0jBBgwFoAUqh/YdxVumeRfkNbsYyZOGepnFFAwgaQGA1Ud
EQSBnDCBmYEoQW5zZ2FyLkhvY2ttYW5uLVN0b2xsZUB1bmktb3NuYWJydWVjay5kZYEdQW5z
Z2FyLkhvY2ttYW5uLVN0b2xsZUB1b3MuZGWBGmFuc2hvY2ttQHVuaS1vc25hYnJ1ZWNrLmRl
gQ9hbnNob2NrbUB1b3MuZGWBCmFoc0B1b3MuZGWBFWFoc0B1bmktb3NuYWJydWVjay5kZTCB
jwYDVR0fBIGHMIGEMECgPqA8hjpodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1vc25hYnJ1
ZWNrLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMECgPqA8hjpodHRwOi8vY2RwMi5wY2EuZGZuLmRl
L3VuaS1vc25hYnJ1ZWNrLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIHdBggrBgEFBQcBAQSB0DCB
zTAzBggrBgEFBQcwAYYnaHR0cDovL29jc3AucGNhLmRmbi5kZS9PQ1NQLVNlcnZlci9PQ1NQ
MEoGCCsGAQUFBzAChj5odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1vc25hYnJ1ZWNrLWNh
L3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDBKBggrBgEFBQcwAoY+aHR0cDovL2NkcDIucGNhLmRm
bi5kZS91bmktb3NuYWJydWVjay1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJKoZIhvcN
AQELBQADggEBAGEzfS8Q3g9PipONE56NeqwDYTwldVesorPZgo4kxtRfLwFca9yfZKF9kit6
ZMnI/TgJDam69kw8UJ9pg7/XDClqF+296ytSPQONsB8TSSgaKxweNf+oBuwwjbTJVmxCsMCp
h6l//eHC2YYpIS/UowpuB4ocoAxFKiRPJUq5KdQWeb+TPZe5Gmdb0dKNnpajdmVcDViSueuZ
t1cAzEm7JGj05W+aS6RtoaTFztUoJQWsTk1xCysD1Z+2q39MlnErCGPvCvphhTncd27IPWgI
H4iDHqJezv/0hDMXjbWWY2LZgEPwpjfr6R8AAKSYIKQlqzi8iVIrdyPLL4BQXKYyvGcxggQI
MIIEBAIBATCBnTCBkTELMAkGA1UEBhMCREUxIDAeBgNVBAoTF1VuaXZlcnNpdGFldCBPc25h
YnJ1ZWNrMRYwFAYDVQQLEw1SZWNoZW56ZW50cnVtMSMwIQYDVQQDExpVbmktT3NuYWJydWVj
ayBSWi1DQSBHLTAwMjEjMCEGCSqGSIb3DQEJARYUY2FAdW5pLW9zbmFicnVlY2suZGUCBxqG
DuZz+cYwDQYJYIZIAWUDBAIBBQCgggI7MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ
KoZIhvcNAQkFMQ8XDTE2MDgyNDA4MjMwMVowLwYJKoZIhvcNAQkEMSIEIMT90lqi02UFMtDI
H8iX/IiObV8vv2J+tB7tEzF0W98SMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsG
CWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw
BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwga4GCSsGAQQBgjcQBDGBoDCBnTCBkTELMAkGA1UE
BhMCREUxIDAeBgNVBAoTF1VuaXZlcnNpdGFldCBPc25hYnJ1ZWNrMRYwFAYDVQQLEw1SZWNo
ZW56ZW50cnVtMSMwIQYDVQQDExpVbmktT3NuYWJydWVjayBSWi1DQSBHLTAwMjEjMCEGCSqG
SIb3DQEJARYUY2FAdW5pLW9zbmFicnVlY2suZGUCBxqGDuZz+cYwgbAGCyqGSIb3DQEJEAIL
MYGgoIGdMIGRMQswCQYDVQQGEwJERTEgMB4GA1UEChMXVW5pdmVyc2l0YWV0IE9zbmFicnVl
Y2sxFjAUBgNVBAsTDVJlY2hlbnplbnRydW0xIzAhBgNVBAMTGlVuaS1Pc25hYnJ1ZWNrIFJa
LUNBIEctMDAyMSMwIQYJKoZIhvcNAQkBFhRjYUB1bmktb3NuYWJydWVjay5kZQIHGoYO5nP5
xjANBgkqhkiG9w0BAQEFAASCAQBItDAOKYqYMhM3ANzn1IEnoBZJR/luqC0AlCfp8Yfw9thn
tSX4CjPlSLyYxz4KHCT3IUbtddUXqhMgLS8I+jOIJ0IbmkBtnEUIPJBaYbsrJRARpYXmsuay
Hm0B9ePbG1GLAh0wiwqxzjuMqr2lw+VdR/laNra/z3j13ivgkIzp1qqZ8d0CxZcgFyupVu1o
EdrmPVORvXqtjVD4m6HMyQwoyTwLG0AtF9+EXcXIOaYhJ/SEMuer7YukSNZ+hCBFeGU61w2q
hPS2EBH0b7QeNV1awzLCFpeMyRf9Tk7O/1RN9SnFetOHWsASjZTp5P1Xd629bKOxpHFdSs/l
C6b3eEUlAAAAAAAA
--------------ms000005070804020201020104--