Bug 1309923

Summary: Timestamps not preserved
Product: [Fedora] Fedora Reporter: Jason Tibbitts <j>
Component: rpmspectoolAssignee: Nils Philippsen <nphilipp>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 24CC: j, nphilipp
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-14 11:57:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Jason Tibbitts 2016-02-19 00:36:02 UTC
The packaging guidelines request that maintainers preserve the timestamps on downloaded files: https://fedoraproject.org/wiki/Packaging:Guidelines#Timestamps

It doesn't seem that rpmspectool does this, though to be fair, the classic spectool doesn't do this either.

Comment 1 Jan Kurik 2016-02-24 15:26:48 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

Comment 2 Nils Philippsen 2016-10-10 10:19:14 UTC
Sorry for getting back so late. I've just looked into this, and rpmspectool should write out downloaded files with timestamps preserved, if the server submits the relevant headers:

--- 8< --- rpmspectool/download.py ---
...
def download(url, where=None, dry_run=False, insecure=False, force=False):
...
            ts = c.getinfo(c.INFO_FILETIME)
...
    # set file modification time
    if ts != -1:
        os.utime(fpath, (time.time(), ts))
...
--- >8 -------------------------------

I've just tested this with the gimp spec file which has:

Source0:        http://download.gimp.org/pub/gimp/v%{binver}/gimp-%{version}%{dashprerel}.tar.bz2

This evaluates to:

Source0: http://download.gimp.org/pub/gimp/v2.8/gimp-2.8.18.tar.bz2

Here's the timestamp (UTC) of the file from http://download.gimp.org/pub/gimp/v2.8/:

gimp-2.8.18.tar.bz2         13-Jul-2016 20:44   20M

And here's the file rpmspectool downloaded:

nils@gibraltar:/tmp> rpmspectool get ~/devel/git/fedora/gimp/*spec
Downloading 'http://download.gimp.org/pub/gimp/v2.8/gimp-2.8.18.tar.bz2' to '/tmp/gimp-2.8.18.tar.bz2'
nils@gibraltar:/tmp> TZ=UTC ls -l gimp-2.8.18.tar.bz2
-rw-rw-r--. 1 nils nils 20824198 Jul 13 20:44 gimp-2.8.18.tar.bz2

Do you have a spec file/URL that reproduces the behavior your described?

Comment 3 Jason Tibbitts 2016-10-10 23:34:28 UTC
I've slept a couple of times since I filed this, so honestly I can't even pull together enough context to have even a guess at what I had tested.  And of course I should have at least pasted in an example or, well, anything useful.  If only for my own sanity.

It certainly does seem that the code is there.  I wouldn't be surprised if I had seen some issue relating to a server which simply didn't provide the timestamp informationr.  In any case, I'm thinking it's best to just close notabug, but I'll leave that to you to ensure I don't foul up any process you might have.

Comment 4 Nils Philippsen 2016-10-14 11:57:22 UTC
I've just checked that with an FTP URL, wasn't sure if that needed to be handled differently, but the files got downloaded with the correct timestamps, too. I'll close this one.