On 2021-08-23, Guillem Jover wrote: > On Fri, 2021-03-19 at 11:32:52 -0700, Vagrant Cascadian wrote: >> 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=.): ... >> 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!
Great! >> 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. I noticed SOURCE_DATE_EPOCH was defined in: /usr/share/dpkg/pkg-info.mk:SOURCE_DATE_EPOCH ?= $(call dpkg_late_eval,SOURCE_DATE_EPOCH,dpkg-parsechangelog -STimestamp) Would it make sense to do the same for DEB_BUILD_PATH? Or would CURDIR not be the right value at that time? Are there cases where SOURCE_DATE_EPOCH isn't defined when building packages (e.g. fakeroot debian/rules build). From a reproducible builds perspective, it seems SOURCE_DATE_EPOCH is working well enough, and defining DEB_BUILD_PATH in the same place should be good enough too. >> 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? Maybe so. *If* we do it well, there should be no real chance of breakage! :) >> From 2f2985a12673866a341551399a5461fe8d7e617b Mon Sep 17 00:00:00 2001 >> From: Vagrant Cascadian <[email protected]> >> 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? I'm not sure what's wrong with it ... Currently fixdebugpath would set something like: -fdebug-prefix-map=/absolute/path/to/build/dir=. This gets the value of DEB_BUILD_PATH from an environment variable instead. Or is there something I'm not grasping with how .spec files work? > 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. :/ I don't *think* defining this from a .spec file really changes that behavior, as long as you set the DEB_BUILD_PATH environment variable only once per build... it should effectively be a fixed value. When I tested this, I added in debian/rules: export DEB_BUILD_PATH=$(CURDIR) And everything *seemed* to work correctly. No matter what directory you're in: -ffile-prefix-map=/path/to/build/dir=. So when calling from directory /path/to/build/dir/A/B/C any embedded paths should get remapped to ./A/B/C, and from directory /path/to/build/dir/A/B/C/.. should get remapped to ./A/B/C/.. I think. This is less complicated that the BUILD_PATH_PREFIX_MAP specifications that Ximin Luo had earlier tried to get accepted into gcc; I do recall that tried to handle more complicated cases... live well, vagrant
signature.asc
Description: PGP signature
