Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

On Fri, 2018-04-13 at 19:01:08 +0100, Ian Jackson wrote: > > On Thu, Apr 05, 2018 at 05:43:58PM +0200, Jean-Michel Vourgère wrote: > > > So, during compilation: > > > SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries > > > because it breaks Multi-Arch:same on bin-nmu. > > > > > > During dpkg

Re: Bug#802241: #802241: dpkg: please store the hash of the installed .deb and allow to query it

Hi! On Wed, 2018-06-06 at 23:40:54 +, Holger Levsen wrote: > ping on this bug, you haven't replied to it yet and it's a blocker for > "#774415 sbuild: please add the srebuild sbuild wrapper to reproduce builds" Oh, had not noticed this was a blocker for anything sorry. And thought the previou

Re: RFC: dpkg patch to using -ffile-prefix-map

rectly. From my side, I see no problem with merging something like the attached patch if it works (I've not even run the test suite on it I think :). Thanks, Guillem From a9ab53a1ea8e1e249b2dba6625a5aeb2c69a91d4 Mon Sep 17 00:00:00 2001 From: Guillem Jover Date: Mon, 30 Jul 2018 16:4

Re: RFC: dpkg patch to using -ffile-prefix-map

On Tue, 2018-07-31 at 10:40:08 +0800, Vagrant Cascadian wrote: > On 2018-07-31, Guillem Jover wrote: > > On Tue, 2018-07-31 at 08:29:33 +0800, Vagrant Cascadian wrote: > > And yeah, I also kind of understand gcc's upstream position, that if > > you unconditionally embed

Bug#910257: strip-nondeterminism: Remove need for obsolete libtimedate-perl dependency

code is actually a fallback for an old debhelper. So we can happily just remove the fallback and the dependency. :) Attached a patch fixing this. Thanks, Guillem From 0d335422c35dcc9fe198953b1e5aa9bd1377cf86 Mon Sep 17 00:00:00 2001 From: Guillem Jover Date: Thu, 4 Oct 2018 00:01:17 +0200

Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

Hi! On Thu, 2018-11-08 at 20:28:57 +, Holger Levsen wrote: > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote: > > We were again biten by this issue for some security-updates (most > > recent one nginx). Do any involved parties know, was there any > > progress in adressing

Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

Hi! On Fri, 2018-11-09 at 11:48:27 +0100, Guillem Jover wrote: > On Thu, 2018-11-08 at 20:28:57 +, Holger Levsen wrote: > > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote: > > > We were again biten by this issue for some security-updates (most > >

Re: Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

On Fri, 2018-11-09 at 11:55:38 +0100, Guillem Jover wrote: > Actually, I guess the other option that might be an option for stable is > to make dpkg-buildpackage generate the buildinfo file itself, and on > source-only uploads force the name to be _source.buildinfo regardless > of

Re: Enabling -ffile-prefix-map by default

Hi! On Wed, 2020-06-03 at 11:59:32 -0700, Vagrant Cascadian wrote: > On 2020-06-03, Benjamin Barenblat wrote: > > Related discussion [2] concluded that the option > > should be disabled by default and enabled after Reproducible Builds had > > trialed it for a while. Having enabled it in some of my

Re: Bug#969084: buildd.d.o: please don't use a tainted buildenv

On Thu, 2020-08-27 at 13:06:56 +, Holger Levsen wrote: > On Thu, Aug 27, 2020 at 03:00:43PM +0200, Aurelien Jarno wrote: > > On 2020-08-27 13:25, Holger Levsen wrote: > > > Package: buildd.debian.org > > > Severity: wishlist > > > User: reproducible-bui...@lists.alioth.debian.org > > > Usertags

Evaluation of bundling .buildinfo in .deb proposal

Hi! Holger proposed to bundle the .buildinfo files into .deb archives during the DebConf talk. I've mentioned to Holger that I'm not seeing this as being feasible and mentioned various reasons why, but I'm also still open to explore this possibility. So I've added these in a wiki page:

Re: Evaluation of bundling .buildinfo in .deb proposal

Hi! On Mon, 2020-08-31 at 12:39:07 +, Holger Levsen wrote: > On Mon, Aug 31, 2020 at 12:02:03PM -, Chris Lamb wrote: > > (As an obiter dictum, are we sure it was Holger who was proposing this > > idea in the talk, rather than mentioning it? I think he has previously > > echoed my view on t

Re: Enabling -ffile-prefix-map by default

Hi! On Thu, 2020-10-22 at 22:58:02 -, Chris Lamb wrote: > Guillem (and all the other dpkg folks), do you see any impediment to > raising the question of enabling fixfilepath by default with the > Debian community at large? Sorry, had pending a reply to this but was caught up with other stuff.

Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote: > On 2020-11-14, Sune Vuorela wrote: > > Unfortunately, only like 10% of the relevant packages have test suites > > enabled and run, because gettings things to work reliable is sometimes > > hard. > So, based on your estimate and the c

Re: Bug#974087: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

Hi! On Mon, 2020-11-16 at 02:33:53 +0100, Guillem Jover wrote: > On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote: > > > Adding more hurdles does not help. > > > I think this is a hurdle we do not need. > > > > To me, a one-line change in packagin

Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

On Fri, 2021-01-08 at 19:23:13 -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > [snip] > > We did a full archive rebuild testing this change, and I provided > > patches to all known affected packages several months ago. It is a > > one-line change in debian/rules in most cases: > > > > > > ht

Re: Re: Updating dpkg-buildflags to enable reproducible=+fixfilepath by default

having a thought about too. But as a starting point I prepared the attached patch, which sets the variable from dpkg-buildpackage and pkg-info.mk. Once there's agreement on the variable(s), I'm fine merging this, but whether to include this for bullseye would need release-team approval a

Re: Bug#873138: Installed-Build-Depends lack architecture qualification

Hi! On Sat, 2022-09-24 at 23:58:28 +0200, Helmut Grohne wrote: > On Thu, Aug 24, 2017 at 09:45:39PM +0200, Helmut Grohne wrote: > > while looking into a .buildinfo file, I noticed that > > Installed-Build-Depends are useless beyond #871494: They lack > > architecture qualification. Thus there is n

Re: Bug#1068483: dpkg-genbuildinfo: Should buildinfo files copy the hash of the source package?

Hi! On Sat, 2024-04-06 at 02:56:02 +0300, Adrian Bunk wrote: > Package: dpkg-dev > Version: 1.22.6 > Severity: normal > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > A thought I already wrote in a recent debian-devel discussion: > > In theory source package filenames should be eter

Re: Bug#882511: dpkg-buildpackage: should allow caller to force inclusion of source in buildinfo

that instead > of > the attached patch. The problem with this solution is that it is prone do accidental use, as it is very easy for a user to unknowingly have recreated the sources from a locally extracted tree (be that modified or not). On Sat, 2024-04-06 at 02:57:40 +02

Re: Bug#1068483: Bug#882511: dpkg-buildpackage: should allow caller to force inclusion of source in buildinfo

Hi! On Wed, 2024-04-10 at 15:22:45 -0700, Vagrant Cascadian wrote: > On 2024-04-09, Guillem Jover wrote: > > I've now finished the change I had in that branch, which implements > > support so that dpkg-buildpackage can be passed a .dsc or a source-dir, > > and in the fo