On Sun, Jan 01, 2017 at 05:40:44PM +0100, Guillem Jover wrote:
> The only correct "solution" I see while keeping the current mess, would
> be to declare binNMU versions a globally shared resource across all
> architectures (in and out of archive!), trigger them globally for all
> architectures (or
[ Had this half-drafted, but had not found the time to finish it up
until now. ]
Hi!
On Mon, 2016-11-14 at 13:52:18 +, Ian Jackson wrote:
> Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#843773: Bug#843773:
> misleading timestamps in binnmus"):
> > Instead, f
On Thu, Dec 01, 2016 at 04:51:39PM +0100, Johannes Schauer wrote:
> Hi,
>
> Quoting Wouter Verhelst (2016-12-01 16:24:16)
> > On Mon, Nov 14, 2016 at 06:10:57PM +0100, Johannes Schauer wrote:
> > > But maybe to talk about this option: what would speak against changing the
> > > "nmu" command of wa
Hi,
Quoting Wouter Verhelst (2016-12-01 16:24:16)
> On Mon, Nov 14, 2016 at 06:10:57PM +0100, Johannes Schauer wrote:
> > But maybe to talk about this option: what would speak against changing the
> > "nmu" command of wanna-build to also add an option that allows setting a
> > timestamp, or even l
Hi,
(Sorry for piping in so late to the party here)
On Mon, Nov 14, 2016 at 06:10:57PM +0100, Johannes Schauer wrote:
> But maybe to talk about this option: what would speak against changing the
> "nmu" command of wanna-build to also add an option that allows setting a
> timestamp, or even let wa
Hi,
Quoting Holger Levsen (2016-11-14 18:25:34)
> To me it seems a binNMU should change SOURCE_DATE_EPOCH, as debian/changelog
> gets modified by changelog.$arch, so it's actually a different source which
> is being build.
debian/changelog doesn't get modified by changelog.$arch. The latter is
ge
Hi,
On Mon, 14 Nov 2016, Johannes Schauer wrote:
> > Can I ask you the converse question: what same-timestamp proposal do
> > you think is best and why ?
>
> I found Guillem's suggestion the most sensible and as far as I understand the
> matter also the easiest to implement:
>
> Quoting Guillem
Ian Jackson wrote:
[...]
> I'm not a fan of the idea of merely adding 1 second per binnmu. That
> would mean that making a second binnmu correctly would involve looking
> in the archive to see what the previous binnmu timestamp was.
[...]
The reference point would be the last source change accor
Hi,
thanks for having this discussion!
On Mon, Nov 14, 2016 at 06:10:57PM +0100, Johannes Schauer wrote:
> Quoting Ian Jackson (2016-11-14 17:33:55)
> > Can I ask you the converse question: what same-timestamp proposal do
> > you think is best and why ?
>
> I found Guillem's suggestion the most s
Hi,
Quoting Ian Jackson (2016-11-14 17:33:55)
> Unless the timestamp is of the binnmu request, plumbing to try to get
> the same timestamp will be difficult.
>
> I'm not a fan of the idea of merely adding 1 second per binnmu. That
> would mean that making a second binnmu correctly would involve
Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#843773: Bug#843773:
misleading timestamps in binnmus"):
> I want to understand why passing the same timestamp to all
> architectures is an inferior solution to your proposal.
This is a sensible question. Thanks for helpin
Hi,
Quoting Ian Jackson (2016-11-14 14:52:18)
>I don't think it is possible to make the binnmu timestamp the same
>across architectures. For example, a package might be rebuilt only
>on some architectures. I don't think we want to change that. In
>particular, even if we were pre
Johannes Schauer writes ("Re: [buildd-tools-devel] Bug#843773: Bug#843773:
misleading timestamps in binnmus"):
> Instead, file conflicts might be created from files with
> content that depends on SOURCE_DATE_EPOCH.
tl;dr:
Analysis. Revised proposal:
Introduce BUILD_DATE_
Hi,
Quoting Ximin Luo (2016-11-10 18:13:00)
> Holger Levsen wrote:
> > On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote:
> > > One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
> > > binNMU to a package.
> > >
> > > Any other ideas?
> > set SOURCE_DATE_EPOC
On 2016-11-10 11:33, Ian Jackson wrote:
> Cyril Brulebois writes ("Re: misleading timestamps in binnmus"):
> > Ian Jackson (2016-11-09):
> > > What version of sbuild do buildds run ? Ie, supposing that this is
> > > fixed in sbuild in stretch, will this be f
(resending again to the correct addresses; I could never get used to debbugs CC
behaviour.)
Ximin Luo:
> Ansgar Burchardt wrote:
>> The date from the last sourceful upload should probably still be used
>> for any date/time information included in generated files to ensure
>> they are identical on
Hi,
Quoting Niko Tyni (2016-11-10 10:01:38)
> On Thu, Nov 10, 2016 at 10:34:33AM +, Holger Levsen wrote:
> > can someone please point at a real life/archive example of such a file?
> > (a binNMU .changes file with Binary-Only-Changes field…)
>
> That's in the .buildinfo file (not .changes), a
On Thu, 2016-11-10 at 11:33 +, Ian Jackson wrote:
> Cyril Brulebois writes ("Re: misleading timestamps in binnmus"):
> > Ian Jackson (2016-11-09):
> > > What version of sbuild do buildds run ? Ie, supposing that this
> > > is
> > > fixed i
On Thu, Nov 10, 2016 at 08:59:48AM -0200, Johannes Schauer wrote:
> One solution would be to increase SOURCE_DATE_EPOCH by 1 second for every
> binNMU to a package.
>
> Any other ideas?
set SOURCE_DATE_EPOCH to the creation time of that changelog.$arch
entry?
--
cheers,
Holger
signat
On Thu, Nov 10, 2016 at 10:34:33AM +, Holger Levsen wrote:
> On Thu, Nov 10, 2016 at 08:24:38AM -0200, Johannes Schauer wrote:
> > > I certainly hope it's part of the .buildinfo file as well, else, for
> > > reproducing binNMUs we would also need to store the .changes files in an
> > > easily a
Cyril Brulebois writes ("Re: misleading timestamps in binnmus"):
> Ian Jackson (2016-11-09):
> > What version of sbuild do buildds run ? Ie, supposing that this is
> > fixed in sbuild in stretch, will this be fixed on the buildds ? Or do
> > we need to update j
On Thu, 2016-11-10 at 10:34 +, Holger Levsen wrote:
> I'm still confused, thinking that this Binary-Only-Changes field needs
> to be assembled into a file, called changelog.$arch, which is then put
> into the debian directory of the unpacked source package. (And which is
> then not included in
Hi,
Quoting Emilio Pozuelo Monfort (2016-11-10 07:04:55)
> On 10/11/16 10:00, Ansgar Burchardt wrote:
> > The date from the last sourceful upload should probably still be used
> > for any date/time information included in generated files to ensure
> > they are identical on all architectures (or at
On Thu, Nov 10, 2016 at 08:24:38AM -0200, Johannes Schauer wrote:
> > I certainly hope it's part of the .buildinfo file as well, else, for
> > reproducing binNMUs we would also need to store the .changes files in an
> > easily accessable manner… (which we plan to do for .buildinfo files, but
> > no
Hi,
Quoiting Holger Levsen (2016-11-10 07:48:33)
> On Thu, Nov 10, 2016 at 10:38:45AM +0100, Emilio Pozuelo Monfort wrote:
> > > I see. And this changelog.$arch is neither part of the source package,
> > > the .changes file nor the .buildinfo file, it's just included in the
> > > binary packages?
On Thu, Nov 10, 2016 at 10:38:45AM +0100, Emilio Pozuelo Monfort wrote:
> > I see. And this changelog.$arch is neither part of the source package,
> > the .changes file nor the .buildinfo file, it's just included in the
> > binary packages? Or is it also part of the .changes file?
> It's in .change
On 10/11/16 10:33, Holger Levsen wrote:
> On Thu, Nov 10, 2016 at 10:01:55AM +0100, Emilio Pozuelo Monfort wrote:
>> These days, a changelog entry is added to a changelog.$arch. This is to avoid
>> problems when co-installing ma:same packages, as the changelog entries
>> will/may
>> differ between
On Thu, Nov 10, 2016 at 10:01:55AM +0100, Emilio Pozuelo Monfort wrote:
> These days, a changelog entry is added to a changelog.$arch. This is to avoid
> problems when co-installing ma:same packages, as the changelog entries
> will/may
> differ between different architectures.
I see. And this cha
On 2016-11-10 10:00 +0100, Ansgar Burchardt wrote:
> The date from the last sourceful upload should probably still be used
> for any date/time information included in generated files to ensure
> they are identical on all architectures (or at least to try to do so).
>
> If you change the date in th
On 10/11/16 10:00, Ansgar Burchardt wrote:
> On Wed, 2016-11-09 at 10:04 +0100, Sven Joachim wrote:
>> On 2016-11-08 22:30 -0200, Johannes Schauer wrote:
>>> It seems that sbuild indeed re-uses the timestamp from the last
>>> debian/changelog entry in the binNMU changelog entry.
>>
>> This has been
On 10/11/16 00:53, Wouter Verhelst wrote:
> On Tue, Nov 08, 2016 at 10:41:09PM +, Ian Jackson wrote:
>> Is this a recommended recipe ? AIUI a buildd doing a binnmu will not
>> modify the debian/changelog file.
>
> Are you sure? When last I checked, this was not true (it may have
> changed sin
On Wed, 2016-11-09 at 10:04 +0100, Sven Joachim wrote:
> On 2016-11-08 22:30 -0200, Johannes Schauer wrote:
> > It seems that sbuild indeed re-uses the timestamp from the last
> > debian/changelog entry in the binNMU changelog entry.
>
> This has been done in an early attempt to make binNMUs co-in
Ian Jackson (2016-11-09):
> What version of sbuild do buildds run ? Ie, supposing that this is
> fixed in sbuild in stretch, will this be fixed on the buildds ? Or do
> we need to update jessie, or what ?
sbuild on buildds uses a specific version of sbuild, for reasons I'm not
going to summariz
On Tue, Nov 08, 2016 at 10:41:09PM +, Ian Jackson wrote:
> Is this a recommended recipe ? AIUI a buildd doing a binnmu will not
> modify the debian/changelog file.
Are you sure? When last I checked, this was not true (it may have
changed since, however).
--
< ron> I mean, the main *practica
Thanks to everyone who has provided information. I have summarised
it in #843773, against sbuild.
What version of sbuild do buildds run ? Ie, supposing that this is
fixed in sbuild in stretch, will this be fixed on the buildds ? Or do
we need to update jessie, or what ?
Ian.
--
Ian Jackson
Hi!
On Wed, 2016-11-09 at 11:16:09 +, Ian Jackson wrote:
> Sven Joachim writes ("Re: misleading timestamps in binnmus"):
> > I'm afraid I don't really have a good suggestion. Using current date
> > would work but obviously break reproducibility, and any oth
(CCing reproducible-builds again:)
Sven Joachim writes ("Re: misleading timestamps in binnmus"):
> I'm afraid I don't really have a good suggestion. Using current date
> would work but obviously break reproducibility, and any other date seems
> arbitrary.
I d
On Wed, Nov 09, 2016 at 10:04:28AM +0100, Sven Joachim wrote:
> I'm afraid I don't really have a good suggestion. Using current date
> would work but obviously break reproducibility, and any other date seems
> arbitrary.
Why would that break reproducibility? reproducible builds is about
reproduc
Hi all,
Quoting Ian Jackson (2016-11-08 21:48:12)
> Guillem Jover writes ("Re: misleading timestamps in binnmus"):
> > So the actual problem is that the last timestamp gets reused for the
> > binNMUs, which seems totally bogus to me. This needs to be fixed in
> > w
Guillem Jover writes ("Re: misleading timestamps in binnmus"):
> I think this should be fine. There's also SOURCE_DATE_EPOCH, that
> dpkg-buildpackage honors and otherwise sets now, which can be also
> retrieved with «dpkg-parsechangelog -STimestamp», but that should not
Hi!
On Tue, 2016-11-08 at 22:41:09 +, Ian Jackson wrote:
> I see the python2.7 source package does this:
>
> LAST_CHANGE := $(shell dpkg-parsechangelog -S Date)
> export BUILD_DATE := $(shell LC_ALL=C date -u +'%b %e %Y' -d
> '$(LAST_CHANGE)')
> export BUILD_TIME := $(shell LC_ALL=C date
41 matches
Mail list logo
