Hi, sorry, I should have clarified that I am also the upstream maintainer, and I keep the "debian" directory in the same source repository as everything else. That's what I meant about submitting a pull request on GitHub. It would still be a modification to debian/rules.
The backstory here is that because those mahimahi programs (mm-link, mm-delay, mm-onoff, mm-loss, mm-webrecord, mm-webreplay) run setuid root, we are paranoid about using PATH at runtime. So we try to resolve these absolute pathnames at build-time. If Debian wants to hardcode the locations, fine with me. I am curious -- why is it important that builds be identical between usrmerge systems and non-usrmerge systems? It's not like we try to have builds be identical between systems with different versions of the compiler, etc. Still, though, if this is the notion of reproducibility that Debian wants its packages to have, I'm happy to comply and have no quibbles with your patch. Cheers, Keith On Fri, Dec 18, 2020 at 3:24 PM Vagrant Cascadian < vagr...@reproducible-builds.org> wrote: > On 2020-12-18, Keith Winstein wrote: > > Thank you for tracking this down! Happy to take the patch -- would you > mind > > filing this as an upstream pull request at > > https://github.com/ravinet/mahimahi ? That way we will have this in one > > place when we next have cycles to upload a new mahimahi package. > > I'm not sure an "upstream" patch would make sense in this specific case; > in Debian, the most compatible path should be in /bin and /sbin, but > this would not necessarily be the case with all distros, and relying on > the path detection might actually be appropriate in some cases. > > So the patch I submitted only modifies debian/rules, not any of the > upstream code. > > > An upstream fix *might* be to not embed the full paths at all, and rely > a working system PATH, though there may be cases where this does not > work... but I am not familiar enough with mahimahi to know if that would > be workable. The upstream code that triggers this is the use of > AC_PATH_PROG in configure.ac. > > For what it's worth, it also embeds the path to other binaries through > AC_PATH_PROG, but many of those don't change on a Debian usrmerge > system. > > > Happy to dialog a little further to sort this out, and thanks for the > quick response! > > > live well, > vagrant >
