preparing to 4.5.19 release

Mike Frysinger vapier at
Thu Oct 8 02:23:18 UTC 2009

On Wednesday 07 October 2009 22:03:14 Roland McGrath wrote:
> > Another small issue is file timestamps in release tarball.
> > Since git does not store timestamps, all files will have current mtime
> > after checkout, while we still package files with last modification in
> > previous century (e.g. PORTING).
> I honestly just don't see any problem there.  Nobody cares what the
> timestamps are, as long as configure is newer than and that
> sort of thing (not that they should complain anyway if they decided to use
> --enable-maintainer-mode).

as you say, as long as the autotool timestamps are in sync (and thus cause 
them to re-run), it shouldnt matter.  only other timestamp issue i can think 
of is having a file that is really really old and ends up making tar whine 
about it when unpacking.

> > There is a script, git-set-file-times, which could be called right after
> > checkout to set mtime and atime of files to their latest commit time in
> > git:
> >;a=blob_plain;f=support/git-set-file-
> >times
> >
> > I suggest to use it for preparing release tarball.
> What I've always used is just 'make distcheck' (and now 'make srpm'), just
> based on my own checkout with whatever working file state it has (making
> sure manually that it's a clean checkout of the tagged state, of course).
> I can't tell if you are suggesting some new automation, or just encouraging
> that whoever does 'make distcheck' runs this thing on their working tree
> first.  Since I'm looking to get out of being the one who does that step in
> future cycles, it's not really my reaction that matters.

i hope `make distcheck` is kept in working order as it's the preferred way of 
packaging autotooled projects.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <>

More information about the Strace-devel mailing list