preparing to 4.5.19 release
vapier at gentoo.org
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 configure.ac and that
> sort of thing (not that they should complain anyway if they decided to use
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:
> > http://gitweb.samba.org/?p=rsync.git;a=blob_plain;f=support/git-set-file-
> > 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...
Size: 836 bytes
Desc: This is a digitally signed message part.
More information about the Strace-devel