Re: Rebuilds with unexpected timestamps

2016-11-01 Thread Adrian Bunk
On Tue, Nov 01, 2016 at 12:05:38PM +, Ian Jackson wrote: >... > Personally I think a Linux kernel tarball, without accompanying git > history, is a GPL violation. >... Why would the git *history* matter for GPL compliance? You can push from a shallow clone. > Ian. cu Adrian -- "Is

Re: Rebuilds with unexpected timestamps [and 1 more messages]

2016-11-01 Thread Sean Whitton
Hello, On Tue, Nov 01, 2016 at 09:09:56AM +0800, Paul Wise wrote: > That already exists (see the dpkg-source manual page), but IIRC isn't > allowed in the archive because the ftp-masters do not want to have to > analyse the whole history of a git repository for DFSG issues. On Tue, Nov 01, 2016 a

Re: Rebuilds with unexpected timestamps

2016-11-01 Thread Simon McVittie
On Mon, 31 Oct 2016 at 17:02:53 +0200, Adrian Bunk wrote: > The ChangeLog file in the "source" tarball of the hello package is > generated from the git metadata. > > You are saying it is a bug that .git is not shipped in the source > tarball of GNU hello? I don't think it is, but I also can't a

Re: Rebuilds with unexpected timestamps

2016-11-01 Thread Holger Levsen
On Tue, Nov 01, 2016 at 12:05:38PM +, Ian Jackson wrote: > How exciting. So the official tarball of GNU hello is not the > preferred form for modification! ironically I could say "welcome to 2016"… ;) > Personally I think a Linux kernel tarball, without accompanying git > history, is a GPL v

Re: Rebuilds with unexpected timestamps

2016-11-01 Thread Ian Jackson
Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps"): > On Sun, Oct 30, 2016 at 11:48:56PM +, Simon McVittie wrote: > >... > > * Source for generated files in the tarball: should be in both git > > and tarball, but sometimes mistakenly omitted from ta

Re: Rebuilds with unexpected timestamps [and 1 more messages]

2016-10-31 Thread Adam Borowski
On Tue, Nov 01, 2016 at 09:09:56AM +0800, Paul Wise wrote: > On Mon, 2016-10-31 at 17:26 +0200, Adrian Bunk wrote: > > > At that point the best solution would be an alternative source > > package format that is based on git. > > That already exists (see the dpkg-source manual page), but IIRC isn'

Re: Rebuilds with unexpected timestamps [and 1 more messages]

2016-10-31 Thread Paul Wise
On Mon, 2016-10-31 at 17:26 +0200, Adrian Bunk wrote: > At that point the best solution would be an alternative source > package format that is based on git. That already exists (see the dpkg-source manual page), but IIRC isn't allowed in the archive because the ftp-masters do not want to have to

Re: Rebuilds with unexpected timestamps [and 1 more messages]

2016-10-31 Thread Adrian Bunk
On Mon, Oct 31, 2016 at 03:58:12PM +, Ian Jackson wrote: > Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps [and 1 more > messages]"): > > On Mon, Oct 31, 2016 at 01:42:26AM +, Ian Jackson wrote: > ... > > > If it does "sufficiently diff

Re: Rebuilds with unexpected timestamps [and 1 more messages]

2016-10-31 Thread Ian Jackson
Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps [and 1 more messages]"): > On Mon, Oct 31, 2016 at 01:42:26AM +, Ian Jackson wrote: ... > > If it does "sufficiently different" things, but still succeeds, when > > the timestamps are permited the

Re: Rebuilds with unexpected timestamps [and 1 more messages]

2016-10-31 Thread Adrian Bunk
On Mon, Oct 31, 2016 at 01:42:26AM +, Ian Jackson wrote: >... > Adrian Bunk writes ("Re: Rebuilds with unexpected timestamps"): > > Be prepared to see a lot of such issues when you touch random files. > > I'm certainly expecting to see lots of issues. >

Re: Rebuilds with unexpected timestamps

2016-10-31 Thread Adrian Bunk
On Sun, Oct 30, 2016 at 11:48:56PM +, Simon McVittie wrote: >... > * Source for generated files in the tarball: should be in both git and > tarball, but sometimes mistakenly omitted from tarballs (e.g. configure.ac, > m4/foo.m4, build-aux/git-version-gen). Leaving these out of the tarball i

Re: Rebuilds with unexpected timestamps

2016-10-30 Thread Adam Borowski
On Sun, Oct 30, 2016 at 04:02:48PM +, Ian Jackson wrote: > How much effort is it to do an archive rebuild nowadays ? How studly > a computer (or computers?) do I need. A few outdated data points: * a single cheap Odroid-U2 arm SoC needs 51 days * a beefy crapload-cores, everything-in-RAM mach

Re: Rebuilds with unexpected timestamps [and 1 more messages]

2016-10-30 Thread Ian Jackson
Paul Wise writes ("Re: Rebuilds with unexpected timestamps"): > On Mon, Oct 31, 2016 at 12:02 AM, Ian Jackson wrote: > > Could someone point me at some tools, or volunteer to help, or something ? > > Check out the wiki page about this: > https://wiki.debian.org/qa.d

Re: Rebuilds with unexpected timestamps

2016-10-30 Thread Simon McVittie
On Mon, 31 Oct 2016 at 00:38:22 +0200, Adrian Bunk wrote: > The "hello" package still builds after you autoreconf the package, > but the program no longer knows what version it is (automake tries to > run build-aux/git-version-gen which is not in the source tarball). I think that's an upstream bu

Re: Rebuilds with unexpected timestamps

2016-10-30 Thread Adrian Bunk
On Sun, Oct 30, 2016 at 04:02:48PM +, Ian Jackson wrote: >... > Most of our packages use `make' or something like it. make relies on > timestamps to decide what to rebuild. It seems that sometimes our > source packages contain combinations of timestamps (and perhaps stamp > files) which, in p

Re: Rebuilds with unexpected timestamps

2016-10-30 Thread Paul Wise
On Mon, Oct 31, 2016 at 12:02 AM, Ian Jackson wrote: > Could someone point me at some tools, or volunteer to help, or something ? Check out the wiki page about this: https://wiki.debian.org/qa.debian.org/ArchiveTesting > I ask because have found a new way to break packages :-). Whee! > What d

Rebuilds with unexpected timestamps

2016-10-30 Thread Ian Jackson
How much effort is it to do an archive rebuild nowadays ? How studly a computer (or computers?) do I need. Could someone point me at some tools, or volunteer to help, or something ? I ask because have found a new way to break packages :-). Most of our packages use `make' or something like it.