Re: Bug#1030785: -ffile-prefix-map option and reproducibility
On Tue, Feb 14, 2023 at 05:07:49PM +0200, Peter Pentchev wrote: > Right, when I said "record the compiler flags", I did not mean "and always > pass them on verbatim". I think you may already know this, since you talk > about Python, but yeah, in Python's case things are really not that simple. > This command: > > python3 -c 'import pprint; import sysconfig; pprint.pp(dict(item for item > in sysconfig.get_config_vars().items() if "CFLAGS" in item[0]));' > > ...displays all of the "system configuration variables" (pretty much exactly > things recorded at Python build time) that have "CFLAGS" in their name, and > at least with Python 3.11 in testing, there are *a lot* of those. Some of them > are obviously module-specific configuration for the various Python standard > library modules, but there are others, too. > > Other systems record compiler (and linker, etc) flags with different > granularity, > but yes, you are correct that it makes a lot of sense to take care what is > recorded and how. Indeed. FWIW what we do with Perl is to filter away those flags that come from dpkg-buildflags [1], but record the others. The dpkg-buildflags ones get passed into XS module package builds separately by debhelper, so packages can individually opt out of things like hardening if necessary via the normal interface (DEB_BUILD_MAINT_OPTIONS etc.) There's some background that led to this in #657853 . Some important flags that really need to be recorded are those that affect the Perl <> XS module binary interface, in particular the LFS ones (-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64). [1] https://sources.debian.org/src/perl/5.36.0-7/debian/rules/#L182 -- Niko Tyni nt...@debian.org
Re: Bug#1030785: -ffile-prefix-map option and reproducibility
On Tue, Feb 14, 2023 at 09:51:50AM +, Simon McVittie wrote: > On Tue, 14 Feb 2023 at 10:21:31 +0200, Peter Pentchev wrote: > > I can't speak of many other systems, but at least with Perl's XS > > (the standard way to write Perl modules parts of which are compiled C code) > > and two of the ways this can be done in Python, it is the same: > > the C compiler's name and flags are recorded at the time the "wrapper" is > > built, so that they can be used later. At least IMHO, this has two main > > benefits: > > - people (or programs) that want to build a Perl/Python/OCaml/whatever > > module do not have to know anything about C compilers, flags, > > optimization, > > language-specific libraries[1] , etc. The consumers tell their own > > language > > ecosystem "look, I need to compile something that has C parts in it, go do > > something about it", and the wrapper for the C compiler knows exactly what > > to do > > - everything is compiled using the same compiler[2], the same optimization > > flags, the same libraries, etc., so one module that has C parts in it can > > call the C functions from another module directly with no fear of any kind > > of calling convention mismatch or whatever > > I think this is very common, but really a bit too simplistic. Some of > the compiler flags are part of an interface between components, and for > those flags, it makes sense to record them in the compiler-wrapper or > in some metadata file like a pkg-config .pc file; but some of them are > private implementation details of the component currently being compiled, > and don't make sense to replicate between components. > > For instance, -lpython3.11 is certainly part of the interface, -O2 -g > is not part of the interface *on Debian* but might be on other platforms > (on glibc systems there's only one C runtime library, but Microsoft > compilers use different and incompatible runtime libraries for release and > debug builds), but facts about the build directory like > -I/tmp/python3.11-3.11.2/Include or > -ffile-prefix-map=/tmp/python3.11-3.11.2=. are certainly not part of the > interface. > > Neither are warning-control options like -Wall or > -Werror=implicit-function-declaration, really: just because the Python > maintainers want warnings or even errors when comiling Python, that > doesn't necessarily mean it's right to require all Python extension > modules to be built with those same warnings. Right, when I said "record the compiler flags", I did not mean "and always pass them on verbatim". I think you may already know this, since you talk about Python, but yeah, in Python's case things are really not that simple. This command: python3 -c 'import pprint; import sysconfig; pprint.pp(dict(item for item in sysconfig.get_config_vars().items() if "CFLAGS" in item[0]));' ...displays all of the "system configuration variables" (pretty much exactly things recorded at Python build time) that have "CFLAGS" in their name, and at least with Python 3.11 in testing, there are *a lot* of those. Some of them are obviously module-specific configuration for the various Python standard library modules, but there are others, too. Other systems record compiler (and linker, etc) flags with different granularity, but yes, you are correct that it makes a lot of sense to take care what is recorded and how. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bug#1030785: -ffile-prefix-map option and reproducibility
On Tue, 14 Feb 2023 at 10:21:31 +0200, Peter Pentchev wrote: > I can't speak of many other systems, but at least with Perl's XS > (the standard way to write Perl modules parts of which are compiled C code) > and two of the ways this can be done in Python, it is the same: > the C compiler's name and flags are recorded at the time the "wrapper" is > built, so that they can be used later. At least IMHO, this has two main > benefits: > - people (or programs) that want to build a Perl/Python/OCaml/whatever > module do not have to know anything about C compilers, flags, optimization, > language-specific libraries[1] , etc. The consumers tell their own language > ecosystem "look, I need to compile something that has C parts in it, go do > something about it", and the wrapper for the C compiler knows exactly what > to do > - everything is compiled using the same compiler[2], the same optimization > flags, the same libraries, etc., so one module that has C parts in it can > call the C functions from another module directly with no fear of any kind > of calling convention mismatch or whatever I think this is very common, but really a bit too simplistic. Some of the compiler flags are part of an interface between components, and for those flags, it makes sense to record them in the compiler-wrapper or in some metadata file like a pkg-config .pc file; but some of them are private implementation details of the component currently being compiled, and don't make sense to replicate between components. For instance, -lpython3.11 is certainly part of the interface, -O2 -g is not part of the interface *on Debian* but might be on other platforms (on glibc systems there's only one C runtime library, but Microsoft compilers use different and incompatible runtime libraries for release and debug builds), but facts about the build directory like -I/tmp/python3.11-3.11.2/Include or -ffile-prefix-map=/tmp/python3.11-3.11.2=. are certainly not part of the interface. Neither are warning-control options like -Wall or -Werror=implicit-function-declaration, really: just because the Python maintainers want warnings or even errors when comiling Python, that doesn't necessarily mean it's right to require all Python extension modules to be built with those same warnings. smcv
Re: Bug#1030785: -ffile-prefix-map option and reproducibility
On Tue, Feb 14, 2023 at 09:04:47AM +0100, Stéphane Glondu wrote: > Hi, > > Le 08/02/2023 à 10:58, Emilio Pozuelo Monfort a écrit : > > What is the purpose of having the build flags in a file in the .deb? > > ocamlc can act as a driver for the C compiler, to compile C stubs with the > "right" flags. These flags are basically the CFLAGS ocaml was compiled with, > plus some additional OCaml-specific flags (like -fwrapv). > > But I wonder now: shouldn't the CFLAGS part be queried from the environment > at use time, rather than at OCaml compilation time? This setting of a non-C > compiler calling a C compiler must happen often... I don't know what's the > practice elsewhere. I can't speak of many other systems, but at least with Perl's XS (the standard way to write Perl modules parts of which are compiled C code) and two of the ways this can be done in Python, it is the same: the C compiler's name and flags are recorded at the time the "wrapper" is built, so that they can be used later. At least IMHO, this has two main benefits: - people (or programs) that want to build a Perl/Python/OCaml/whatever module do not have to know anything about C compilers, flags, optimization, language-specific libraries[1] , etc. The consumers tell their own language ecosystem "look, I need to compile something that has C parts in it, go do something about it", and the wrapper for the C compiler knows exactly what to do - everything is compiled using the same compiler[2], the same optimization flags, the same libraries, etc., so one module that has C parts in it can call the C functions from another module directly with no fear of any kind of calling convention mismatch or whatever - to reinforce the previous point: everything is compiled using the same recorded settings *no matter what* environment variables or paths there may be in the current user's execution environment, so that nothing will break if somebody has the wrong environment variable defined when they build a module a couple of months later. Of course, there are some cases when some such systems allow additional flags to be specified or overridden, but IMHO it is good that this must be done explicitly and is most often not done at all, so that everything is built in the same way and it can all work together [1] At least with Perl and Python, C code very often invokes functions from the Perl/Python standard library, the C code does not know how to create a list or how to invoke a Perl/Python function, so it has to use the language's internal libraries for that. [2] Well, okay, that's not strictly true, since the binary called "gcc" now may not be the same that was provided by the C compiler package a couple of months ago, but it ought to be guaranteed to generate compatible code and object files. So yeah, I'd say that "record the C compiler flags at build time" is pretty much standard practice for such interface providers. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org p...@storpool.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Re: Bug#1030785: -ffile-prefix-map option and reproducibility
Hi, Le 08/02/2023 à 10:58, Emilio Pozuelo Monfort a écrit : What is the purpose of having the build flags in a file in the .deb? ocamlc can act as a driver for the C compiler, to compile C stubs with the "right" flags. These flags are basically the CFLAGS ocaml was compiled with, plus some additional OCaml-specific flags (like -fwrapv). But I wonder now: shouldn't the CFLAGS part be queried from the environment at use time, rather than at OCaml compilation time? This setting of a non-C compiler calling a C compiler must happen often... I don't know what's the practice elsewhere. If I push the reasoning to the extreme, why doesn't gcc take into account CFLAGS itself? Cheers, -- Stéphane
Re: -ffile-prefix-map option and reproducibility
Hi! I'm end up with following thing: https://github.com/rockdrilla/debian-container/blob/808dfa15d130f833602a1486362cc551593a0d8a/image/python/template/rules#L543 Hovewer, "execute_before_dh_builddeb" recipe is for information only (to be viewed by human) and "execute_before_dh_install" recipe is for actual adjustments. ср, 8 февр. 2023 г. в 13:39, Guillem Jover : > > On Tue, 2023-02-07 at 20:00:06 +0100, Sven Joachim wrote: > > On 2023-02-07 17:50 +0100, Guillem Jover wrote: > > > On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: > > >> I suspect this was added to improve reproducibility. Ironically, it makes > > >> packages that capture this variable non reproducible, since the build > > >> path > > >> seems to be randomized (has it always been the case? since when?). It is > > >> the > > >> case of OCaml (see #1030785), and seemingly of R as well (found by > > >> grepping > > >> in my /etc). I wouldn't be surprised other packages are affected as well. > > > > > > AFAIR this was considered at the time, yes. If the flag is effectively > > > not fixing anything for the set of packages involved, and is in fact > > > actually making them unreproducible when they would not then, you can > > > disable the fixfilepath feature in the reproducible build flags area, > > > via DEB_BUILD_MAINT_OPTIONS. > > > > This does not help for packages which capture all build flags and store > > them in some file in the package (as is the case here). With > > DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath, dpkg-buildflags falls > > back to "-fdebug-prefix-map==.", and you have the same > > problem. If you disable that as well via > > DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath,-fixdebugpath, the > > -dbgsym packages will most likely end up unreproducible. > > Ah, you are absolutely right. I don't think the case of these flags > making the build unreproducible and the package not generating any > debug objects are going to be common at all. I considered mentioning > fixing the build to stop capturing, but felt it might be more effort > than requested. :) Should probably have mentioned anyway, as was done > elsewhere in the thread. > > In any case I'm thinking to add something like the attached to the man > page to try to clarify this. > > Thanks, > Guillem -- SY, Konstantin Demin
Re: Bug#1030785: -ffile-prefix-map option and reproducibility
On 2023-02-08, Stéphane Glondu wrote: > Thank you all for your answers! > > Using: > >DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath,-fixdebugpath > > makes the package unreproducible in another way that seems difficult to fix. Most likely reintroducing the things that the -ffile-prefix-map and -fdebug-prefix-map was effectively removing... We track these kinds of issues with the "records build flags" issue, which has a description of the problem and links to more information: https://tests.reproducible-builds.org/debian/issues/unstable/records_build_flags_issue.html There are some potential fixes to the issue more fundamentally, but they are currently stalled out... one of which I should probably spend some time on after bookworm release... You had earlier asked when this was enabled, this can mostly be found in the dpkg changelog: fixfilepath (a.k.a. -ffile-prefix-map) Enabled by default: dpkg (1.20.6) unstable; urgency=medium ... * dpkg-buildflags: Enable reproducible=fixfilepath by default. Thanks to Vagrant Cascadian . See https://lists.debian.org/debian-devel/2020/10/msg00222.html. Closes: #974087 ... -- Guillem Jover Fri, 08 Jan 2021 04:39:40 +0100 fixfilepath (a.k.a. -ffile-prefix-map) feature added, and enabled in reproducible builds infrastructure soon after: dpkg (1.19.1) unstable; urgency=medium ... - Dpkg::Vendor::Debian: Add fixfilepath support to reproducible feature. ... -- Guillem Jover Wed, 26 Sep 2018 15:13:22 +0200 fixdebugpath (a.k.a. -fdebug-prefix-map) enabled by default: dpkg (1.18.10) unstable; urgency=medium ... - Enable fixdebugpath build flag feature by default. Thanks to Mattia Rizzolo . Closes: #832179 ... -- Guillem Jover Sun, 31 Jul 2016 12:57:02 +0200 fixdebugpath (a.k.a. -fdebug-prefix-map) feature added, and presumably enabled in reproducible builds infrastructure soon after: dpkg (1.18.5) unstable; urgency=medium ... - Add fixdebugpath to reproducible feature in Dpkg::Vendor::Debian. Thanks to Daniel Kahn Gillmor . Closes: #819194 ... -- Guillem Jover Mon, 02 May 2016 04:14:57 +0200 Of course, this is only for packages respecting dpkg-buildflags. > Le 07/02/2023 à 19:12, Mattia Rizzolo a écrit : >> I actually propose to you to filter out the whole option from being >> saved. [...] > > I've gone this way, and managed to make the package reproducible, at > least with the build path variation. Glad that works! > I will upload the fixed ocaml package when the current batch of related > packages waiting in unstable migrates to testing, hopefully in 4 days. Thanks! live well, vagrant signature.asc Description: PGP signature
Re: -ffile-prefix-map option and reproducibility
On Tue, 2023-02-07 at 20:00:06 +0100, Sven Joachim wrote: > On 2023-02-07 17:50 +0100, Guillem Jover wrote: > > On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: > >> I suspect this was added to improve reproducibility. Ironically, it makes > >> packages that capture this variable non reproducible, since the build path > >> seems to be randomized (has it always been the case? since when?). It is > >> the > >> case of OCaml (see #1030785), and seemingly of R as well (found by grepping > >> in my /etc). I wouldn't be surprised other packages are affected as well. > > > > AFAIR this was considered at the time, yes. If the flag is effectively > > not fixing anything for the set of packages involved, and is in fact > > actually making them unreproducible when they would not then, you can > > disable the fixfilepath feature in the reproducible build flags area, > > via DEB_BUILD_MAINT_OPTIONS. > > This does not help for packages which capture all build flags and store > them in some file in the package (as is the case here). With > DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath, dpkg-buildflags falls > back to "-fdebug-prefix-map==.", and you have the same > problem. If you disable that as well via > DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath,-fixdebugpath, the > -dbgsym packages will most likely end up unreproducible. Ah, you are absolutely right. I don't think the case of these flags making the build unreproducible and the package not generating any debug objects are going to be common at all. I considered mentioning fixing the build to stop capturing, but felt it might be more effort than requested. :) Should probably have mentioned anyway, as was done elsewhere in the thread. In any case I'm thinking to add something like the attached to the man page to try to clarify this. Thanks, Guillem From 1d94da75b63115485ad1247c44f64973ed74339f Mon Sep 17 00:00:00 2001 From: Guillem Jover Date: Wed, 8 Feb 2023 11:26:14 +0100 Subject: [PATCH] man: Add notes about reproducibility properties for path fixing build features Mention that if the build captures the build flags that will make it unreproducible, the traps with trying to disable these flags to get back to a reproducible output. And that the ideal fix is to stop capturing build flags. Prompted-by: Sven Joachim --- man/dpkg-buildflags.pod | 9 + 1 file changed, 9 insertions(+) diff --git a/man/dpkg-buildflags.pod b/man/dpkg-buildflags.pod index 6067d4923..01c14269e 100644 --- a/man/dpkg-buildflags.pod +++ b/man/dpkg-buildflags.pod @@ -622,6 +622,13 @@ This has the effect of removing the build path from any generated file. If both B and B are set, this option takes precedence, because it is a superset of the former. +B: If the build process captures the build flags into the resulting +built objects, that will make the package unreproducible. +And while disabling this option might make some of the objects reproducible +again this would also require disabling B, which might make +any generated debug symbols objects unreproducible. +The ideal fix is to stop capturing build flags. + =item B This setting (enabled by default) adds @@ -632,6 +639,8 @@ set to the top-level directory of the package being built. This has the effect of removing the build path from any generated debug symbols. +B: This feature has similar reproducible properties as B. + =back =head1 ENVIRONMENT -- 2.39.1
Re: Bug#1030785: -ffile-prefix-map option and reproducibility
Thank you all for your answers! Using: DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath,-fixdebugpath makes the package unreproducible in another way that seems difficult to fix. Le 07/02/2023 à 19:12, Mattia Rizzolo a écrit : I actually propose to you to filter out the whole option from being saved. [...] I've gone this way, and managed to make the package reproducible, at least with the build path variation. I will upload the fixed ocaml package when the current batch of related packages waiting in unstable migrates to testing, hopefully in 4 days. Cheers, -- Stéphane
Re: -ffile-prefix-map option and reproducibility
On 07/02/2023 20:00, Sven Joachim wrote: On 2023-02-07 17:50 +0100, Guillem Jover wrote: On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: When building packages, a -ffile-prefix-map option is automatically injected into CFLAGS. Where does it come from? Since when? This is coming from dpkg-buildflags (in this case probably indirectly via debhelper). AFAICS it was added in dpkg 1.19.1 disabled by default, and then switched to enabled by default in dpkg 1.20.6 (see #974087). I suspect this was added to improve reproducibility. Ironically, it makes packages that capture this variable non reproducible, since the build path seems to be randomized (has it always been the case? since when?). It is the case of OCaml (see #1030785), and seemingly of R as well (found by grepping in my /etc). I wouldn't be surprised other packages are affected as well. AFAIR this was considered at the time, yes. If the flag is effectively not fixing anything for the set of packages involved, and is in fact actually making them unreproducible when they would not then, you can disable the fixfilepath feature in the reproducible build flags area, via DEB_BUILD_MAINT_OPTIONS. This does not help for packages which capture all build flags and store them in some file in the package (as is the case here). What is the purpose of having the build flags in a file in the .deb? Cheers, Emilio
Re: -ffile-prefix-map option and reproducibility
On 2023-02-07 17:50 +0100, Guillem Jover wrote: > On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: >> When building packages, a -ffile-prefix-map option is automatically injected >> into CFLAGS. Where does it come from? Since when? > > This is coming from dpkg-buildflags (in this case probably indirectly > via debhelper). AFAICS it was added in dpkg 1.19.1 disabled by default, > and then switched to enabled by default in dpkg 1.20.6 (see #974087). > >> I suspect this was added to improve reproducibility. Ironically, it makes >> packages that capture this variable non reproducible, since the build path >> seems to be randomized (has it always been the case? since when?). It is the >> case of OCaml (see #1030785), and seemingly of R as well (found by grepping >> in my /etc). I wouldn't be surprised other packages are affected as well. > > AFAIR this was considered at the time, yes. If the flag is effectively > not fixing anything for the set of packages involved, and is in fact > actually making them unreproducible when they would not then, you can > disable the fixfilepath feature in the reproducible build flags area, > via DEB_BUILD_MAINT_OPTIONS. This does not help for packages which capture all build flags and store them in some file in the package (as is the case here). With DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath, dpkg-buildflags falls back to "-fdebug-prefix-map==.", and you have the same problem. If you disable that as well via DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath,-fixdebugpath, the -dbgsym packages will most likely end up unreproducible. Cheers, Sven
Re: -ffile-prefix-map option and reproducibility
On Tue, Feb 07, 2023 at 04:41:47PM +0100, Stéphane Glondu wrote:
> When building packages, a -ffile-prefix-map option is automatically injected
> into CFLAGS. Where does it come from? Since when?
>
> I suspect this was added to improve reproducibility. Ironically, it makes
> packages that capture this variable non reproducible, since the build path
> seems to be randomized (has it always been the case? since when?).
The build path has always been randomized since, or at least it has been
for as long as I've been involved in Debian.
> It is the
> case of OCaml (see #1030785), and seemingly of R as well (found by grepping
> in my /etc). I wouldn't be surprised other packages are affected as well.
>
> Is there a way to not get this option? More elegant than explicitly
> filtering it out of CFLAGS in debian/rules...
Besides doing
DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath
I actually propose to you to filter out the whole option from being
saved. I've seen a similar pattern in other packages in the past, and
all of those packages already had a filtering function in place to
remove other gcc flags that make no sense being saved (just looking at:
- 8: const("camlConfig__8"="-O2 -fno-strict-aliasing -fwrapv -pthread
-fPIC -g -O2 -ffile-prefix-map=/build/ocaml-Vq2uKK/ocaml-4.13.1=.
-fstack-protector-strong -Wformat -Werror=format-security");
+ 8: const("camlConfig__8"="-O2 -fno-strict-aliasing -fwrapv -pthread
-fPIC -g -O2 -ffile-prefix-map=/build/ocaml-xz3WL7/ocaml-4.13.1=.
-fstack-protector-strong -Wformat -Werror=format-security");
makes me believe that many options have been stripped out…)
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
More about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
signature.asc
Description: PGP signature
Re: -ffile-prefix-map option and reproducibility
Hi! On Tue, 2023-02-07 at 16:41:47 +0100, Stéphane Glondu wrote: > When building packages, a -ffile-prefix-map option is automatically injected > into CFLAGS. Where does it come from? Since when? This is coming from dpkg-buildflags (in this case probably indirectly via debhelper). AFAICS it was added in dpkg 1.19.1 disabled by default, and then switched to enabled by default in dpkg 1.20.6 (see #974087). > I suspect this was added to improve reproducibility. Ironically, it makes > packages that capture this variable non reproducible, since the build path > seems to be randomized (has it always been the case? since when?). It is the > case of OCaml (see #1030785), and seemingly of R as well (found by grepping > in my /etc). I wouldn't be surprised other packages are affected as well. AFAIR this was considered at the time, yes. If the flag is effectively not fixing anything for the set of packages involved, and is in fact actually making them unreproducible when they would not then, you can disable the fixfilepath feature in the reproducible build flags area, via DEB_BUILD_MAINT_OPTIONS. Perhaps even "globally" from a language specific packaging helper or similar? > Is there a way to not get this option? More elegant than explicitly > filtering it out of CFLAGS in debian/rules... See above. I just noticed that several of these build flag features do not have information in the man page about when they got first introduced, so I'll be adding that in dpkg 1.22.x, once development opens up again. Thanks, Guillem
Re: -ffile-prefix-map option and reproducibility
Hi, Quoting Stéphane Glondu (2023-02-07 16:41:47) > When building packages, a -ffile-prefix-map option is automatically injected > into CFLAGS. Where does it come from? Since when? probably due to https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?id=b60c243ba99b8483202a6f6a814476275204fdff which references: https://lists.debian.org/debian-devel/2020/10/msg00222.html https://bugs.debian.org/974087 > I suspect this was added to improve reproducibility. Ironically, it makes > packages that capture this variable non reproducible, since the build path > seems to be randomized (has it always been the case? since when?). It is the > case of OCaml (see #1030785), and seemingly of R as well (found by grepping > in my /etc). I wouldn't be surprised other packages are affected as well. > > Is there a way to not get this option? More elegant than explicitly > filtering it out of CFLAGS in debian/rules... See the man page of dpkg-buildflags -- this might do what you want: export DEB_BUILD_MAINT_OPTIONS=reproducible=-fixfilepath Thanks! cheers, josch
-ffile-prefix-map option and reproducibility
Hi, When building packages, a -ffile-prefix-map option is automatically injected into CFLAGS. Where does it come from? Since when? I suspect this was added to improve reproducibility. Ironically, it makes packages that capture this variable non reproducible, since the build path seems to be randomized (has it always been the case? since when?). It is the case of OCaml (see #1030785), and seemingly of R as well (found by grepping in my /etc). I wouldn't be surprised other packages are affected as well. Is there a way to not get this option? More elegant than explicitly filtering it out of CFLAGS in debian/rules... Cheers, -- Stéphane
