This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 1309923 - Timestamps not preserved
Timestamps not preserved
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rpmspectool (Show other bugs)
24
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Nils Philippsen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-02-18 19:36 EST by Jason Tibbitts
Modified: 2016-10-14 07:57 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-10-14 07:57:22 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jason Tibbitts 2016-02-18 19:36:02 EST
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 10:26:48 EST
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 06:19:14 EDT
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 19:34:28 EDT
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 07:57:22 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.