Debian Bug report logs - #962474
CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Timo Röhling <timo@gaussglocke.de>

To: submit@bugs.debian.org

Subject: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Date: Mon, 8 Jun 2020 16:26:26 +0200

[Message part 1 (text/plain, inline)]

Package: debhelper
Version: 13
Severity: wishlist

By default, CMake adds an RPATH entry to ELF binaries and deletes it
again at install time. However, due to the limitations of some
platforms, CMake will actually zero out the RPATH entry in the binary,
leaking the original path length and thus making the build not
reproducible (see the attached diffoscope output for an example).

CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
since most package won't ever ship with an RPATH entry anyway, I propose
adding -DCMAKE_SKIP_RPATH=ON to the default build options.

Cheers
Timo

[qhull_2019.1-5.diffoscope.txt (text/plain, attachment)]

Message #10 received at 962474@bugs.debian.org (full text, mbox, reply):

From: Timo Röhling <timo@gaussglocke.de>

To: 962474@bugs.debian.org

Subject: Re: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Date: Mon, 8 Jun 2020 16:47:54 +0200

[Message part 1 (text/plain, inline)]

For some reason, the downloaded output from
tests.reproducible-builds.org was double-gzipped.
Here is the properly uncompressed text.

[qhull_2019.1-5.diffoscope.txt (text/plain, attachment)]

Message #15 received at 962474@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Timo Röhling <timo@gaussglocke.de>, 962474@bugs.debian.org

Subject: Re: Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Date: Sun, 28 Jun 2020 09:48:33 +0200

Timo Röhling:
> Package: debhelper
> Version: 13
> Severity: wishlist
> 
> By default, CMake adds an RPATH entry to ELF binaries and deletes it
> again at install time. However, due to the limitations of some
> platforms, CMake will actually zero out the RPATH entry in the binary,
> leaking the original path length and thus making the build not
> reproducible (see the attached diffoscope output for an example).
> 
> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
> since most package won't ever ship with an RPATH entry anyway, I propose
> adding -DCMAKE_SKIP_RPATH=ON to the default build options.
> 
> Cheers
> Timo
> 

Hi Timo,

Thanks for the suggestion.

Has this proposal been tested on an archive-wide rebuild test to see how
much breaks with this option set?

~Niels

Message #20 received at 962474@bugs.debian.org (full text, mbox, reply):

From: Timo Röhling <timo@gaussglocke.de>

To: 962474@bugs.debian.org

Cc: reproducible-bugs@lists.alioth.debian.org

Subject: Re: Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Date: Mon, 29 Jun 2020 13:31:18 +0200

Control: user reproducible-builds@lists.alioth.debian.org
Control: usertag -1 + buildpath toolchain


>> By default, CMake adds an RPATH entry to ELF binaries and deletes it
>> again at install time. However, due to the limitations of some
>> platforms, CMake will actually zero out the RPATH entry in the binary,
>> leaking the original path length and thus making the build not
>> reproducible (see the attached diffoscope output for an example).
>>
>> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
>> since most package won't ever ship with an RPATH entry anyway, I propose
>> adding -DCMAKE_SKIP_RPATH=ON to the default build options.
> Thanks for the suggestion.
>
> Has this proposal been tested on an archive-wide rebuild test to see how
> much breaks with this option set?
I don't know, but I don't think so. I'm not directly involved with the
Reproducible Builds Team, I just pinged them on IRC after I filed this
bug. Cc'ing them now.

Message #25 received at 962474@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: Timo Röhling <timo@gaussglocke.de>, 962474@bugs.debian.org

Cc: reproducible-bugs@lists.alioth.debian.org

Subject: Re: Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Date: Mon, 29 Jun 2020 09:14:58 -0700

[Message part 1 (text/plain, inline)]

On 2020-06-29, Timo Röhling wrote:
>>> By default, CMake adds an RPATH entry to ELF binaries and deletes it
>>> again at install time. However, due to the limitations of some
>>> platforms, CMake will actually zero out the RPATH entry in the binary,
>>> leaking the original path length and thus making the build not
>>> reproducible (see the attached diffoscope output for an example).
>>>
>>> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
>>> since most package won't ever ship with an RPATH entry anyway, I propose
>>> adding -DCMAKE_SKIP_RPATH=ON to the default build options.
>> Thanks for the suggestion.

Thanks for identifying the issue!


>> Has this proposal been tested on an archive-wide rebuild test to see how
>> much breaks with this option set?
> I don't know, but I don't think so. I'm not directly involved with the
> Reproducible Builds Team, I just pinged them on IRC after I filed this
> bug. Cc'ing them now.

There is currently only one package tagged with:

  https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html

The tagging is not automated, so most likely there are more issues that
people have not yet been identified... any good search terms for
sources.debian.org that might produce a list to compare?


The tests.reproducible-builds.org infrastructure has been building
without any custom toolchains for quite a while now, but we did at one
point have the ability to build with custom packages. It is best to be
avoided, however, as then we have to constantly keep pace with whatever
tools we're patching...


It would be nice if this could be added to debhelper but disabled by
default unless a flag was set in DEB_BUILD_OPTIONS (or something
similar) so that we could enable it from the build environment in
reproducible builds test infrastructure without affecting the official
archive.


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #30 received at 962474@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: Timo Röhling <timo@gaussglocke.de>, 962474@bugs.debian.org

Cc: reproducible-bugs@lists.alioth.debian.org

Subject: Re: Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Date: Mon, 29 Jun 2020 09:37:37 -0700

[Message part 1 (text/plain, inline)]

On 2020-06-29, Vagrant Cascadian wrote:
> On 2020-06-29, Timo Röhling wrote:
>>>> By default, CMake adds an RPATH entry to ELF binaries and deletes it
>>>> again at install time. However, due to the limitations of some
>>>> platforms, CMake will actually zero out the RPATH entry in the binary,
>>>> leaking the original path length and thus making the build not
>>>> reproducible (see the attached diffoscope output for an example).
>>>>
>>>> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
>>>> since most package won't ever ship with an RPATH entry anyway, I propose
>>>> adding -DCMAKE_SKIP_RPATH=ON to the default build options.
>>> Thanks for the suggestion.
>
> Thanks for identifying the issue!
>
>
>>> Has this proposal been tested on an archive-wide rebuild test to see how
>>> much breaks with this option set?
>> I don't know, but I don't think so. I'm not directly involved with the
>> Reproducible Builds Team, I just pinged them on IRC after I filed this
>> bug. Cc'ing them now.
>
> There is currently only one package tagged with:
>
>   https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html

Also worth mentioning the upstream issue:

  https://gitlab.kitware.com/cmake/cmake/-/issues/18413

live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 962474@bugs.debian.org (full text, mbox, reply):

From: Vagrant Cascadian <vagrant@reproducible-builds.org>

To: Timo Röhling <timo@gaussglocke.de>, 962474@bugs.debian.org

Cc: reproducible-bugs@lists.alioth.debian.org

Subject: Re: Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Date: Mon, 29 Jun 2020 09:50:37 -0700

[Message part 1 (text/plain, inline)]

On 2020-06-29, Vagrant Cascadian wrote:
> On 2020-06-29, Vagrant Cascadian wrote:
>> On 2020-06-29, Timo Röhling wrote:
>>>>> By default, CMake adds an RPATH entry to ELF binaries and deletes it
>>>>> again at install time. However, due to the limitations of some
>>>>> platforms, CMake will actually zero out the RPATH entry in the binary,
>>>>> leaking the original path length and thus making the build not
>>>>> reproducible (see the attached diffoscope output for an example).
>>>>>
>>>>> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
>>>>> since most package won't ever ship with an RPATH entry anyway, I propose
>>>>> adding -DCMAKE_SKIP_RPATH=ON to the default build options.
>>>> Thanks for the suggestion.
>>
>> Thanks for identifying the issue!
>>
>>
>>>> Has this proposal been tested on an archive-wide rebuild test to see how
>>>> much breaks with this option set?
>>> I don't know, but I don't think so. I'm not directly involved with the
>>> Reproducible Builds Team, I just pinged them on IRC after I filed this
>>> bug. Cc'ing them now.
>>
>> There is currently only one package tagged with:
>>
>>   https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
>
> Also worth mentioning the upstream issue:
>
>   https://gitlab.kitware.com/cmake/cmake/-/issues/18413

And BUILD_RPATH_USE_ORIGIN:

  https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/prop_tgt/BUILD_RPATH_USE_ORIGIN.rst


live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 962474@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Vagrant Cascadian <vagrant@reproducible-builds.org>, 962474@bugs.debian.org, Timo Röhling <timo@gaussglocke.de>

Cc: reproducible-bugs@lists.alioth.debian.org

Subject: Re: Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Date: Mon, 29 Jun 2020 19:54:49 +0200

Vagrant Cascadian:
> On 2020-06-29, Vagrant Cascadian wrote:
>> On 2020-06-29, Vagrant Cascadian wrote:
>>> On 2020-06-29, Timo Röhling wrote:
>>>>>> By default, CMake adds an RPATH entry to ELF binaries and deletes it
>>>>>> again at install time. However, due to the limitations of some
>>>>>> platforms, CMake will actually zero out the RPATH entry in the binary,
>>>>>> leaking the original path length and thus making the build not
>>>>>> reproducible (see the attached diffoscope output for an example).
>>>>>>
>>>>>> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
>>>>>> since most package won't ever ship with an RPATH entry anyway, I propose
>>>>>> adding -DCMAKE_SKIP_RPATH=ON to the default build options.
>>>>> Thanks for the suggestion.
>>>
>>> Thanks for identifying the issue!
>>>
>>>
>>>>> Has this proposal been tested on an archive-wide rebuild test to see how
>>>>> much breaks with this option set?
>>>> I don't know, but I don't think so. I'm not directly involved with the
>>>> Reproducible Builds Team, I just pinged them on IRC after I filed this
>>>> bug. Cc'ing them now.
>>>
>>> There is currently only one package tagged with:
>>>
>>>   https://tests.reproducible-builds.org/debian/issues/unstable/cmake_rpath_contains_build_path_issue.html
>>
>> Also worth mentioning the upstream issue:
>>
>>   https://gitlab.kitware.com/cmake/cmake/-/issues/18413
> 
> And BUILD_RPATH_USE_ORIGIN:
> 
>   https://gitlab.kitware.com/cmake/cmake/-/blob/master/Help/prop_tgt/BUILD_RPATH_USE_ORIGIN.rst
> 
> 
> live well,
>   vagrant
> 

Ok, I will add a temporary undocumented variable for you to test this.
It accepts any space separated list of "key-value pairs", which can be
used to override -D flags passed to cmake.  An example being:

export DH_INTERNAL_RB_TEST_BUG962474="CMAKE_SKIP_RPATH=ON"

But you can substitute it with other flags if you also want or need to
experiment with other flags, such as:

export DH_INTERNAL_RB_TEST_BUG962474="CMAKE_SKIP_RPATH=OFF \
                                      BUILD_RPATH_USE_ORIGIN=ON"

For the ease of debugging, debhelper will be verbal about this feature
being used.

It will be available with the next upload and be removed once your tests
have concluded.

~Niels

Message #45 received at 962474@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: Timo Röhling <timo@gaussglocke.de>, 962474@bugs.debian.org

Cc: reproducible-bugs@lists.alioth.debian.org

Subject: Re: Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Date: Mon, 29 Jun 2020 22:55:03 -0000

Timo Röhling wrote:

> >> By default, CMake adds an RPATH entry to ELF binaries and deletes it
> >> again at install time. However, due to the limitations of some
> >> platforms, CMake will actually zero out the RPATH entry in the binary,
> >> leaking the original path length and thus making the build not
> >> reproducible (see the attached diffoscope output for an example).
> >>
> >> CMAKE_SKIP_RPATH disables the RPATH machinery and fixes the issue, and
> >> since most package won't ever ship with an RPATH entry anyway, I propose
> >> adding -DCMAKE_SKIP_RPATH=ON to the default build options.
> > Thanks for the suggestion.
> >
> > Has this proposal been tested on an archive-wide rebuild test to see how
> > much breaks with this option set?
>
> I don't know, but I don't think so. I'm not directly involved with the
> Reproducible Builds Team, I just pinged them on IRC after I filed this
> bug. Cc'ing them now.

As Vagrant implies we have not done an archive-wide rebuild test on
this specifically. (I was actually not aware of this specific issue
until now.) However, let me give you my general thoughts on using our
testing framework for staging changes.

Although we do have the ability to make changes to our toolchain to
test things we don't really like to do this unless absolutely
necessary. Every deviation from Debian itself is a "bug" of sorts and
only confuses users, developers and even the Reproducible Builds team
themselves when things are (for example) reproducible in one
environment or fail to build in a place that folks have zero control
or visibility over.

In addition, in the past when we have had temporary changes they have
persisted far longer than anyone planned. This leads to frustration
and highly-demotivating outcomes when maintainers no long feel a
pressing need to accommodate a change because "well, all the packages
are now reproducible". Well, yeah, I *guess* …

Lastly, making just a small change is actually non-trivial to do and
involves more technical and cognitive overhead than it sounds. "Just"
is a dangerous word, as I am sure you all know. This could probably be
fixed, but we have limited bandwidth and we aren't trying to be a
staging ground anyway. I suppose this would be mitigated if we only
needed to export that particular Debhelper environment variable from
our 'master' build environment vs. uploading a patched package, but
the above arguments still stand as a general rule.

In other words, unless you have no reason to suspect that lots and
lots of things will break, I would highly and strongly recommend that
you simply make the changes in CMake/debhelper and upload. :)

(Speaking only as myself, I don't represent the entire Reproducible
Builds project, etc. etc. etc. And I am partly writing this so I can
refer others to it later in other parallel contexts...)

Thanks for working on this. :)


Regards,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-

Message #50 received at 962474@bugs.debian.org (full text, mbox, reply):

From: Timo Röhling <timo@gaussglocke.de>

To: 962474@bugs.debian.org

Cc: reproducible-bugs@lists.alioth.debian.org

Subject: Re: Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Date: Tue, 30 Jun 2020 02:19:40 +0200

On 30.06.2020 00:55, Chris Lamb wrote:
> In other words, unless you have no reason to suspect that lots and
> lots of things will break, I would highly and strongly recommend that
> you simply make the changes in CMake/debhelper and upload. :) 
I'd say the biggest risk lies in breaking test suites for shared
libraries, because they tend to be run from the build tree, which is why
CMake adds RPATHs to targets in the first place.

As precedent, I thought the way Debhelper introduced
-DCMAKE_SKIP_INSTALL_ALL_DEPENDENCY=ON in v13 was quite nice, and I
wouldn't mind if I had to opt-in for CMAKE_SKIP_RPATH by bumping my
compat level to (say) 14.

Cheers
Timo

Message #55 received at 962474@bugs.debian.org (full text, mbox, reply):

From: Niels Thykier <niels@thykier.net>

To: Chris Lamb <lamby@debian.org>, 962474@bugs.debian.org, Timo Röhling <timo@gaussglocke.de>

Cc: reproducible-bugs@lists.alioth.debian.org

Subject: Re: Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Date: Tue, 30 Jun 2020 09:58:37 +0200

Chris Lamb:
> [...]
> 
> In other words, unless you have no reason to suspect that lots and
> lots of things will break, I would highly and strongly recommend that
> you simply make the changes in CMake/debhelper and upload. :)
> 
> [...]


Hi,

My concern here is that effectively, I as the debhelper maintainer will
be accepting all the risk.  In case of issues, it will drain my
bandwidth (as well or instead of your bandwidth), because the RC bugs
will be coming my way if it breaks.

That sets me up to an "interesting" trade off of options.

 1) I can accept the high risk and deploy the change now so we can reap
    the rewards now.
 2) I can just punt it to compat 14 and say it will come eventually -
    but then the reward is 6-10 years away (for 80% coverage).
 3) Obviously, I can also simply reject the change accepting none of the
    risk forcing you to test it first (or contest it at the tech-
    ctte's).

Honestly, I do not think any of the choices sound very exciting.

Can we not think of some better solution to this, where we can get the
reward sooner than 6 years without shoving all the risk onto me and
without shoving ton of work onto you?

I doubt this will be the last time we will need some archive-wide change
rolled out to all source packages to improve reproducibility.

> 
> Thanks for working on this. :)
> 
> [...]

Same. :)

~Niels

Message #60 received at 962474-close@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 962474-close@bugs.debian.org

Subject: Bug#962474: fixed in debhelper 13.2

Date: Sun, 05 Jul 2020 21:48:36 +0000

Source: debhelper
Source-Version: 13.2
Done: Niels Thykier <niels@thykier.net>

We believe that the bug you reported is fixed in the latest version of
debhelper, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 962474@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Niels Thykier <niels@thykier.net> (supplier of updated debhelper package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sun, 05 Jul 2020 21:14:04 +0000
Source: debhelper
Architecture: source
Version: 13.2
Distribution: unstable
Urgency: medium
Maintainer: Debhelper Maintainers <debhelper@packages.debian.org>
Changed-By: Niels Thykier <niels@thykier.net>
Closes: 961655 962474 962568
Changes:
 debhelper (13.2) unstable; urgency=medium
 .
   [ Niels Thykier ]
   * dh_missing: Explicitly remind people that they should not
     copy-waste multi-arch paths directly into debian/not-installed.
     Instead, recommend the use of wildcards of ${DEB_HOST_MULTIARCH}
     to replace the hardcoded value.
   * d/changelog: Clarify what dh_installman change in 13.1 related to
     #958343 was about.
   * Dh_Lib.pm: Add support for raising compat deprecation warnings to
     an error if there are pending removals.  This currently triggers
     for usage of compat 5 and 6.
   * cmake.pm: Pass -DCMAKE_SKIP_RPATH=ON -DBUILD_RPATH_USE_ORIGIN=ON
     to cmake in compat 14.  This should fix some reproducibility
     issues but may cause breakage if packages run binaries directly
     from the build directory.  Thanks to Timo Röhling for the
     suggestion.  (Closes: #962474)
   * dh,dh_auto_*: Change the handling of XDG_RUNTIME_DIR in compat 13.
     It is now only set to a writable directory for dh_auto_test but
     set to a much shorter directory avoid issues with socket lengths.
     In all other cases, the XDG_RUNTIME_DIR is now cleared.  Thanks to
     Simon McVittie for the report.  (Closes: #961655)
   * debhelper.pod: Document that --sourcedir clashes between dh_auto_*
     and dh_missing (etc.).  Thanks to Thorsten Glaser for reporting
     the issue.  (See #964230)
 .
   [ Anel Husakovic ]
   * debhelper.7: Fix typo/grammatical errors.
 .
   [ Translations ]
   * Update Portuguese translation (Américo Monteiro)  (Closes: #962568)
Checksums-Sha1:
 05ea609e70c96920fb2eabd8b98ca8e201bec20a 1835 debhelper_13.2.dsc
 3dc6a6d74afd8ab99935fe510eecc76300d1c603 540400 debhelper_13.2.tar.xz
 04106327212616acedd963dc4077d2a079aecb15 4586 debhelper_13.2_source.buildinfo
Checksums-Sha256:
 6eb15d5b5225dfa6076eb25db1f2740c9852e4589e0598fc647b35ce7dfa945c 1835 debhelper_13.2.dsc
 380a6196a28da0992878b0f5453d3adeb17eda27ca0b87453ef293bf2c7e6f46 540400 debhelper_13.2.tar.xz
 09a244e7e9697dc9ee9634ed29d968fde0a9f44f84daf27c9e8eb3ae7d38fa07 4586 debhelper_13.2_source.buildinfo
Files:
 2d0bc857672ad7825e37a7533b94431c 1835 devel optional debhelper_13.2.dsc
 6adebda3d1d9b3c260dcb6e81d162de8 540400 devel optional debhelper_13.2.tar.xz
 eb86ba1fb5ccefb6a67c8d26291bad97 4586 devel optional debhelper_13.2_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQJGBAEBCgAwFiEE8f9dDX4ALfD+VfsMplt42+Z8eqwFAl8CRZESHG5pZWxzQHRo
eWtpZXIubmV0AAoJEKZbeNvmfHqsVHMP/1+kGH0AHx4o2GAmS0c1u/O5dcUYJWTu
BTEOFBdObxNAu2MYN40u7RkfZUKUQNAFGktRTGrBQ06L+2I5lZNlu+tPPhfKzpCg
FTeV1Ud2JUWv2AgQ8yR+3GWVmor+NwDB0/eiWfA+8zNpE79T8un4UJvybErLayyI
2gsofGAn1O2CT1Pqp0A3WRohDtykQU4MJ/k6F9tmUKsBYmwrGmaR/m2UnD3E8x8s
usuKUtyzVaDEFnWiTofbQ9GiSmr0AUfBE1tqRyzl74aQuaiLTaL6moK/BYG/6Kex
9khjxRrcKpfEcOd0xwLYY3GF+xfLoV4adzxB6MapJecKGEgwzMk8rO+nWXsthHpv
KcfrV1B3gz5aXf2mwwa7SmS+MMUmL9jYm+HcVpaYbJoRUTvTh+VTYdh1cSmyfaod
x3AD338GyMyxdfwWvv9irtGiN1IJfaG/I3B31P8ODh56lkMmqXvvxKCKH5wpqdKy
bDE7YTz7omDGDQE7MqhNBEBgmRgqjWmxNdQdwaqOH8bDxTSA0lyQmR61Eg59KOhK
1inWm6zo/HolkhTvFiXrDQ0oPvHaUshW7NJWRkDur5xAO9qTrZCLqVrfDebxhGAJ
7o/IExNDdBFQxl4ExjcAfZ3u+lbKSlrbePo5hhQ6dof7Va88L7QB53gFBo5cC95f
3W0DKjgj+JDx
=Yx6f
-----END PGP SIGNATURE-----

Message #65 received at 962474@bugs.debian.org (full text, mbox, reply):

From: "Chris Lamb" <lamby@debian.org>

To: "Niels Thykier" <niels@thykier.net>, 962474@bugs.debian.org, Timo Röhling <timo@gaussglocke.de>

Cc: reproducible-bugs@lists.alioth.debian.org

Subject: Re: Bug#962474: CMAKE_SKIP_RPATH=ON improves reproducibility of CMake builds

Date: Fri, 24 Jul 2020 16:58:03 -0000

Hi Niels,

> Can we not think of some better solution to this, where we can get the
> reward sooner than 6 years without shoving all the risk onto me and
> without shoving ton of work onto you?

I hear you, ouch. :/  I had not appreciated all of the implications
here, particularly in that that you would get all the flak from the
fallout. Unfortunately, I can just imagine how this has played out in
the past with other changes.

I note that this bug has been marked as fixed in debhelper 13.2. To
help others viewing this bug from reproducible context, here is the
relevant changelog entry:

   * cmake.pm: Pass -DCMAKE_SKIP_RPATH=ON -DBUILD_RPATH_USE_ORIGIN=ON
     to cmake in compat 14.  This should fix some reproducibility
     issues but may cause breakage if packages run binaries directly
     from the build directory.


Regards,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-

Send a report that this bug log contains spam.