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 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...

Do we talk about the same timestamp? I just did this:

> [root@vm476 ~]# yum clean metadata
> Quellen werden aufgeräumt: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     00:00     
> sl                                                       | 3.7 kB     00:00     
> sl-extras                                                | 3.0 kB     00:00
> sl-fastbugs                                              | 2.9 kB     00:00
> sl-security                                              | 2.9 kB     00:00
> (1/9): sl-extras/x86_64/updateinfo                         |  23 kB   00:00
> (2/9): sl/x86_64/group_gz                                  | 107 kB   00:00
> (3/9): sl-fastbugs/x86_64/updateinfo                       |  76 kB   00:00
> (4/9): sl-extras/x86_64/primary_db                         | 118 kB   00:00
> (5/9): sl-security/x86_64/updateinfo                       |  82 kB   00:00
> (6/9): sl/x86_64/updateinfo                                | 1.4 MB   00:02
> (7/9): sl-fastbugs/x86_64/primary_db                       | 1.6 MB   00:02
> (8/9): sl-security/x86_64/primary_db                       | 2.6 MB   00:02
> (9/9): sl/x86_64/primary_db                                | 4.6 MB   00:03
> rz/7/x86_64/primary                                        |  13 kB   00:00
> rz                                                                        33/33
> 
> 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 repomd.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

-- 
Ansgar Hockmann-Stolle · Universität Osnabrück · Rechenzentrum
Albrechtstraße 28, 49076 Osnabrück, Deutschland · Raum 31/E77B
+49 541 969-2749 (fax -2470) · http://www.home.uos.de/anshockm