Hi! On Fri, 2021-03-19 at 11:32:52 -0700, Vagrant Cascadian wrote: > Package: dpkg > Severity: normal > Tags: patch > User: reproducible-bui...@lists.alioth.debian.org > Usertags: buildpath > X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org
> While the reproducible=+fixfilepath and reproducible=+fixdebugpath are > very helpful in stripping out the build path from binaries, many > binaries still end up including the build path because they also embed > the compiler flags (e.g. -ffile-prefix-map=/path/to/build-XYZ=.): > > > https://tests.reproducible-builds.org/debian/issues/unstable/records_build_flags_issue.html > > At the moment, we have identified over 150 packages in Debian affected > by this issue, though there are probably more that have not yet been > identified. Some packages may work around this issue by sanitizing or > stripping -ffile-prefix-map and -fdebug-prefix-map, but handling this on > a per-package basis is a bit of a whack-a-mole approach. > > > The attached patch attempts to switch fixfilepath and fixdebugpath to > use .spec files with the DEB_BUILD_PATH environment variable, which is > currently used internally for the fixfilepath and fixdebugpath > features. Ah I like this direction, yes! > Note that it is only a partial patch; it doesn't export DEB_BUILD_PATH > in dpkg-buildpackage and/or dpkg-buildflags; help as to the best place > to implement that would be appreciated! The ideal place to export such variable would be from dpkg-buildpackage, but sadly as long as that's not the canonical entry point for building packages, I'm seeing only doing that if the implementation can avoid assuming the variable is set and shows no regressions in that case. > Instead of changing fixfilepath/fixdebugpath, it might also be better to > add new options instead, as this is a significant change of the > implementation. If we'd be worried that the new behavior can break stuff, then that might make sense, but that would either imply that we need to manually switch current packages to explicitly use the new ones, or we need to flip the new ones as the default and disable the old ones, in case some package needs the old behavior. But that all seems a bit unnecessary to me? > Interested to hear your thoughts everyone! > From 2f2985a12673866a341551399a5461fe8d7e617b Mon Sep 17 00:00:00 2001 > From: Vagrant Cascadian <vagr...@reproducible-builds.org> > Date: Sun, 14 Mar 2021 00:19:56 -0800 > Subject: [PATCH] Implement reproducible=(fixfilepath|fixdebugpath) as spec > files. > diff --git a/data/fixdebugpath.specs b/data/fixdebugpath.specs > new file mode 100644 > index 000000000..e1cc16b0a > --- /dev/null > +++ b/data/fixdebugpath.specs > @@ -0,0 +1,2 @@ > +*self_spec: > ++ -fdebug-prefix-map=%:getenv(DEB_BUILD_PATH =.) I'm not sure the equal sign is correct here? Also there's a significant and potentially problematic behavior change here. The perl code currently uses Cwd::getcwd(), which will return an absolute pathname, which will be stable regardless of where the option is being used. Instead when passing «.» that suddenly becomes relative to the call site of each compiler invocation (not even of the dpkg-buildflags call. :/ > diff --git a/data/fixfilepath.specs b/data/fixfilepath.specs > new file mode 100644 > index 000000000..1f8561575 > --- /dev/null > +++ b/data/fixfilepath.specs > @@ -0,0 +1,2 @@ > +*self_spec: > ++ -ffile-prefix-map=%:getenv(DEB_BUILD_PATH =.) Ditto. Thanks, Guillem
