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
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 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
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
24 matches
Mail list logo
