Hi!
[ Just a very quick reply, will go over the other mails during the week. ]
On Wed, 2017-05-24 at 13:58:00 +, Ximin Luo wrote:
> Also the man page for dpkg-buildpackage is out-of-date:
>
>6. Unless a source-only build has been requested, it runs the
> buildinfo hook and calls
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: reproducible-builds@lists.alioth.debian.org
Dear Release Team,
Please consider unblocking quadrapassel 1:3.22.0-1.1:
quadrapassel (1:3.22.0-1.1) unstable; urgency=medium
*
Hi, Ximin. Thanks for your attention.
Ximin Luo writes ("Re: source-only builds and .buildinfo"):
> Also the man page for dpkg-buildpackage is out-of-date:
I think maybe you should file a bug about these ?
> >> So I think for `dgit push-source', there should be no .buildinfo ?
> >> At least,
Ian Jackson:
> [..]
>
>
> https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_Why_are_.buildinfo_files_always_generated_with_dpkg-buildpackage.3F
>
>
> As I wrote to Guillem, quoting the FAQ:
>
>> By default dpkg-buildpackage does active tasks such as cleaning via
>> debian/rules, and makes sure
Sean Whitton writes ("Re: source-only builds and .buildinfo"):
> On Wed, May 24, 2017 at 11:59:55AM +0100, Ian Jackson wrote:
> > [Ian:]
> > > Alternatively dgit could strip out the .buildinfo, depending on
> > > whether it ran rules clean.
>
> While a plain `dgit push-source` will prepare a
On Wed, May 24, 2017 at 11:59:55AM +0100, Ian Jackson wrote:
> > So I think for `dgit push-source', there should be no .buildinfo ?
> > At least, unless dgit ran the clean target.
> >
> > This suggests to me that dgit push-source should use dpkg-source
> > rather than dpkg-buildpackage, as you
(Resending with the right CC for reproducible-builds@lists.a.d.o)
Hi. I'm widening the scope of this thread because I think the
reproducible builds folks might have an opinion. (Holger said on IRC
that they'd welcome a CC.) So, I'm going to recap.
dpkg-buildpackage -S (which is the
control: severity -1 normal
thanks
Hi,
downgrading the severity because not being able to strip determinism from
a few files present in very few packages doesn't have a major impact on the
usability of this package. (It's actually closer to wishlist…)
--
cheers,
Holger
signature.asc
Processing control commands:
> severity -1 normal
Bug #843811 [strip-nondeterminism] strip-nondeterminism: does not strip
nondeterminism from /SYM64/ ar entries
Severity set to 'normal' from 'important'
--
843811: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843811
Debian Bug Tracking