Re: Sending LTO delta to Debian
On 06.05.22 08:53, Steve Langasek wrote: Hi Andreas, On Thu, May 05, 2022 at 05:33:37PM -0300, Andreas Hasenack wrote: Hi, this came up again in a review, and I wanted to ask a broader audience. How to we send LTO[1] related delta to Debian, given that Debian isn't using LTO (yet)? Case in point was the ust package[2], which has this bit[3] part of the delta (just showing the first hunk): @@ -1,5 +1,5 @@ liblttng-ust-python-agent.so.1 liblttng-ust-python-agent1 #MINVER# * Build-Depends-Package: liblttng-ust-dev - __start_lttng_ust_tracepoints_ptrs@Base 2.13.0 - __stop_lttng_ust_tracepoints_ptrs@Base 2.13.0 + (optional=lto)__start_lttng_ust_tracepoints_ptrs@Base 2.13.0 + (optional=lto)__stop_lttng_ust_tracepoints_ptrs@Base 2.13.0 Is this upstreamable to Debian as is? I know this depends most of the time on the maintainer, but in general what would be our arguments? Does it change the behavior of package building when lto is not used? In a non-lto case, would the disappearance of those symbols be caught? When talking about upstreaming of changes to .symbols files, I prefer to argue it from a higher level: the two purposes of .symbols files are 1) to avoid user-affecting bugginess due to undetected ABI breakage, and 2) to ensure library dependencies are as relaxed as possible to give the best cross-release binary compatibility and minimize constraints on release upgrades. While in our case it's LTO that has resulted in these particular symbols disappearing, it's obvious from the names that these symbols are not intended to be part of the public ABI of this library - the fact that these symbols are exported is an accident, not something happening by design. So marking these symbols "optional" makes the packaging more correct in terms of describing the library's ABI, and more portable with respect to a variety of compiler options that may change the exposure of internal symbols. Thus it's a low-priority bug for Debian, but the change is intrinsically correct - not something Ubuntu-specific. symbols files are broken by design. however that design error was accepted into dpkg and issues mitigating that by either using the google or redhat solutions are ignored. so please be pragmatic about this and try to work around it. so yes, an issue for Debian to address these issues is appropriate. Matthias -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Sending LTO delta to Debian
Hi Andreas, On Thu, May 05, 2022 at 05:33:37PM -0300, Andreas Hasenack wrote: > Hi, > this came up again in a review, and I wanted to ask a broader audience. > How to we send LTO[1] related delta to Debian, given that Debian isn't > using LTO (yet)? > Case in point was the ust package[2], which has this bit[3] part of > the delta (just showing the first hunk): > @@ -1,5 +1,5 @@ > liblttng-ust-python-agent.so.1 liblttng-ust-python-agent1 #MINVER# > * Build-Depends-Package: liblttng-ust-dev > - __start_lttng_ust_tracepoints_ptrs@Base 2.13.0 > - __stop_lttng_ust_tracepoints_ptrs@Base 2.13.0 > + (optional=lto)__start_lttng_ust_tracepoints_ptrs@Base 2.13.0 > + (optional=lto)__stop_lttng_ust_tracepoints_ptrs@Base 2.13.0 > Is this upstreamable to Debian as is? I know this depends most of the > time on the maintainer, but in general what would be our arguments? > Does it change the behavior of package building when lto is not used? > In a non-lto case, would the disappearance of those symbols be caught? When talking about upstreaming of changes to .symbols files, I prefer to argue it from a higher level: the two purposes of .symbols files are 1) to avoid user-affecting bugginess due to undetected ABI breakage, and 2) to ensure library dependencies are as relaxed as possible to give the best cross-release binary compatibility and minimize constraints on release upgrades. While in our case it's LTO that has resulted in these particular symbols disappearing, it's obvious from the names that these symbols are not intended to be part of the public ABI of this library - the fact that these symbols are exported is an accident, not something happening by design. So marking these symbols "optional" makes the packaging more correct in terms of describing the library's ABI, and more portable with respect to a variety of compiler options that may change the exposure of internal symbols. Thus it's a low-priority bug for Debian, but the change is intrinsically correct - not something Ubuntu-specific. Hope that helps, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Re: Sending LTO delta to Debian
On Thursday, May 05 2022, Andreas Hasenack wrote: > this came up again in a review, and I wanted to ask a broader audience. > > How to we send LTO[1] related delta to Debian, given that Debian isn't > using LTO (yet)? TBH I think it depends on the Debian maintainer. I myself will gladly accept a patch disabling LTO in Debian if it's been identified that LTO will break my package, even if it's just to make things easier for the derivative distro's (Ubuntu usually, but can be others) maintainer (given that the patch will be a no-op in Debian, as you mentioned). But I'm talking about a simple d/rules patch that will just touch DEB_BUILD_MAINT_OPTIONS... > Case in point was the ust package[2], which has this bit[3] part of > the delta (just showing the first hunk): > @@ -1,5 +1,5 @@ > liblttng-ust-python-agent.so.1 liblttng-ust-python-agent1 #MINVER# > * Build-Depends-Package: liblttng-ust-dev > - __start_lttng_ust_tracepoints_ptrs@Base 2.13.0 > - __stop_lttng_ust_tracepoints_ptrs@Base 2.13.0 > + (optional=lto)__start_lttng_ust_tracepoints_ptrs@Base 2.13.0 > + (optional=lto)__stop_lttng_ust_tracepoints_ptrs@Base 2.13.0 > > Is this upstreamable to Debian as is? I know this depends most of the > time on the maintainer, but in general what would be our arguments? > Does it change the behavior of package building when lto is not used? > In a non-lto case, would the disappearance of those symbols be caught? ... this, OTOH, is more involved. Using "=XYZ" after "optional", in my experience, is only informational. If a symbol disappears, it will be reported even if it's marked as optional: https://git.dpkg.org/cgit/dpkg/dpkg.git/tree/scripts/Dpkg/Shlibs/Symbol.pm#n485 But dpkg-gensymbols won't make the distinction between "this symbol disappeared because of LTO" vs. "this symbol disappeared, period". With my DD hat on, I'd say that I probably wouldn't be happy accepting such a patch because it's much easier to introduce problems due to the fact that the symbol will be marked as optional regardless of the reason, but really shouldn't. Thanks, -- Sergio GPG key ID: E92F D0B3 6B14 F1F4 D8E0 EB2F 106D A1C8 C3CB BF14 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
Sending LTO delta to Debian
Hi, this came up again in a review, and I wanted to ask a broader audience. How to we send LTO[1] related delta to Debian, given that Debian isn't using LTO (yet)? Case in point was the ust package[2], which has this bit[3] part of the delta (just showing the first hunk): @@ -1,5 +1,5 @@ liblttng-ust-python-agent.so.1 liblttng-ust-python-agent1 #MINVER# * Build-Depends-Package: liblttng-ust-dev - __start_lttng_ust_tracepoints_ptrs@Base 2.13.0 - __stop_lttng_ust_tracepoints_ptrs@Base 2.13.0 + (optional=lto)__start_lttng_ust_tracepoints_ptrs@Base 2.13.0 + (optional=lto)__stop_lttng_ust_tracepoints_ptrs@Base 2.13.0 Is this upstreamable to Debian as is? I know this depends most of the time on the maintainer, but in general what would be our arguments? Does it change the behavior of package building when lto is not used? In a non-lto case, would the disappearance of those symbols be caught? 1. https://wiki.ubuntu.com/ToolChain/LTO 2. https://launchpad.net/ubuntu/+source/ust 3. https://git.launchpad.net/ubuntu/+source/ust/commit/?id=438c8ae30797d92cacc9d0e041a92583fbd5f09d -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
