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

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