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
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
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
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
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
>>
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
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,
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
Control: user reproducible-bui...@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
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
For some reason, the downloaded output from
tests.reproducible-builds.org was double-gzipped.
Here is the properly uncompressed text.
---
/srv/reproducible-results/rbuild-debian/tmp.xJYgDafRbo/b1/qhull_2019.1-5_amd64.changes
+++
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
12 matches
Mail list logo
