Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: > >The core issue as I see it is as follows: > >- Debian has decided to support only merged-/usr, including possibly > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 > as the interpreter in binaries. WTF? *Nobody* has been talking about breaking ABI like this, that I've seen. The interpreter must *not* be changed willy-nilly. -- Steve McIntyre, Cambridge, UK.st...@einval.com "I've only once written 'SQL is my bitch' in a comment. But that code is in use on a military site..." -- Simon Booth
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote: > > On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: > > > >The core issue as I see it is as follows: > > > >- Debian has decided to support only merged-/usr, including possibly > > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 > > as the interpreter in binaries. > > WTF? *Nobody* has been talking about breaking ABI like this, that I've > seen. The interpreter must *not* be changed willy-nilly. Nothing's happening 'willy-nilly'. We are discussing a bunch of seemingly crazy options, as in, "what would _actually_ explode if we do this or do that?", on this very d-devel thread. I posted a longer version here some days ago: https://lists.debian.org/debian-gcc/2023/05/msg00030.html Kind regards, Luca Boccassi
Bug#1035991: ITP: fonts-chomsky -- New York Times masthead, reimagined as a full font
Package: wnpp Severity: wishlist Owner: Gürkan Myczko X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: fonts-chomsky Version : 2.3+ds Upstream Authors: Fredrick R. Brennan URL : https://github.com/ctrlcctrlv/chomsky * License : OFL-1.1 Description : New York Times masthead, reimagined as a full font This is Chomsky, a newspaper masthead font in the style of the New York Times masthead.
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: >On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote: >> >> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: >> > >> >The core issue as I see it is as follows: >> > >> >- Debian has decided to support only merged-/usr, including possibly >> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 >> > as the interpreter in binaries. >> >> WTF? *Nobody* has been talking about breaking ABI like this, that I've >> seen. The interpreter must *not* be changed willy-nilly. > >Nothing's happening 'willy-nilly'. We are discussing a bunch of >seemingly crazy options, as in, "what would _actually_ explode if we >do this or do that?", on this very d-devel thread. I posted a longer >version here some days ago: > >https://lists.debian.org/debian-gcc/2023/05/msg00030.html Oh holy fuck. You're talking about changing ABI by doing this. That *is* utterly crazy. No. -- Steve McIntyre, Cambridge, UK.st...@einval.com "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, 12 May 2023 at 11:40, Steve McIntyre wrote: > > On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: > >On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote: > >> > >> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: > >> > > >> >The core issue as I see it is as follows: > >> > > >> >- Debian has decided to support only merged-/usr, including possibly > >> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 > >> > as the interpreter in binaries. > >> > >> WTF? *Nobody* has been talking about breaking ABI like this, that I've > >> seen. The interpreter must *not* be changed willy-nilly. > > > >Nothing's happening 'willy-nilly'. We are discussing a bunch of > >seemingly crazy options, as in, "what would _actually_ explode if we > >do this or do that?", on this very d-devel thread. I posted a longer > >version here some days ago: > > > >https://lists.debian.org/debian-gcc/2023/05/msg00030.html > > Oh holy fuck. > > You're talking about changing ABI by doing this. That *is* utterly > crazy. No. It's a thought experiment on a mailing list. If we can't even have those anymore, something went very wrong somewhere. You seem to be aware of things that wouldn't work anymore (I think?). If you have a couple of minutes to spare, may I please ask you to reply to that thread with such examples? I am genuinely interested in understanding and talking about it. Thank you. Kind regards, Luca Boccassi
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote: >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: >>On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote: >>> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: >>> > >>> >The core issue as I see it is as follows: >>> > >>> >- Debian has decided to support only merged-/usr, including possibly >>> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 >>> > as the interpreter in binaries. >>> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've >>> seen. The interpreter must *not* be changed willy-nilly. >> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of >>seemingly crazy options, as in, "what would _actually_ explode if we >>do this or do that?", on this very d-devel thread. I posted a longer >>version here some days ago: >> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html > >Oh holy fuck. > >You're talking about changing ABI by doing this. That *is* utterly >crazy. No. People have asked me to expand on this further... I've been involved in defining ABI before, specifically for armhf. It's not a quick and easy process. It needs buy-in from all sides to make things work, and people *really* value the interoperability that it enables. The interpreter path is one of the most important parts of the ABI spec, the bit that makes binaries compatible between all the various stakeholders: compiler/tools people, distros, software vendors, etc. Lots of the rest of the details downstream of this can be changed, and people do this all the time - compare multilib to multi-arch for example. That all works fine *so long as* the runtime linker can be located and started OK. Changing the interpreter path would mean moving to a Debian-specific ABI, breaking that compatibility. Hand-waving that away with (and I quote): "The vast majority of distros today ship the loader in /usr/lib as /lib is just a symlink, so it would be interoperable." is appalling arrogance. No. You do *not* get to break ABI with that argument. The point of the ABI spec is that *everybody* follows it. You don't change it just because you think it'll make your life a little easier when bootstrapping a system. -- Steve McIntyre, Cambridge, UK.st...@einval.com Welcome my son, welcome to the machine.
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, 12 May 2023 at 12:08, Steve McIntyre wrote: > > On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote: > >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: > >>On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote: > >>> > >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: > >>> > > >>> >The core issue as I see it is as follows: > >>> > > >>> >- Debian has decided to support only merged-/usr, including possibly > >>> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 > >>> > as the interpreter in binaries. > >>> > >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've > >>> seen. The interpreter must *not* be changed willy-nilly. > >> > >>Nothing's happening 'willy-nilly'. We are discussing a bunch of > >>seemingly crazy options, as in, "what would _actually_ explode if we > >>do this or do that?", on this very d-devel thread. I posted a longer > >>version here some days ago: > >> > >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html > > > >Oh holy fuck. > > > >You're talking about changing ABI by doing this. That *is* utterly > >crazy. No. > > People have asked me to expand on this further... > > I've been involved in defining ABI before, specifically for > armhf. It's not a quick and easy process. It needs buy-in from all > sides to make things work, and people *really* value the > interoperability that it enables. > > The interpreter path is one of the most important parts of the ABI > spec, the bit that makes binaries compatible between all the various > stakeholders: compiler/tools people, distros, software vendors, > etc. Lots of the rest of the details downstream of this can be > changed, and people do this all the time - compare multilib to > multi-arch for example. That all works fine *so long as* the runtime > linker can be located and started OK. The loader is still available via the old path, so external/third party/local/other software works unchanged. This should negatively only affect our 1st party packages, when running on a non-merged distro. And are _all_ our packages really 100% compatible with other distros at all? Are they even supposed to be? For example, if I download efibootmgr from Bookworm on an Ubuntu Focal machine, when I try to run it, it fails: root@focal:/tmp# wget http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb --2023-05-12 12:46:17-- http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4 Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 27572 (27K) [application/vnd.debian.binary-package] Saving to: 'efibootmgr_17-2_amd64.deb' efibootmgr_17-2_amd64.deb 100%[===>] 26.93K --.-KB/sin 0.04s 2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved [27572/27572] root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm root@focal:/tmp# ./ebm/bin/efibootmgr ./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr) Should I file a severity: serious bug against efibootmgr because it is not interoperable? The answer is obviously not, because it would be absurd to expect a binary compiled against libraries from one distro to "just work" on an entirely different distro. Glibc itself is not forward compatible, and is allowed to add new symbols, that are not present in older versions, and packages are allowed to depend on them. Aren't those also ABI breakages? What about all the libraries that bump soname? What about binaries that rely on newer kernel interfaces, or IPC interfaces? So, what I am asking is, what actual, real difference does it make if, by default (and with an override available for example), packages built on Debian for Debian record the ld path to point to its (actual) location on Debian, via say a compiler spec file that is injected in a deb build? There very likely is some real difference and impact, and I am genuinely and honestly asking what it could be. If nothing else, it's an interesting topic, even if likely nothing comes out of it. > Changing the interpreter path would mean moving to a Debian-specific > ABI, breaking that compatibility. Hand-waving that away with (and I > quote): > > "The vast majority of distros today ship the loader in /usr/lib as > /lib is just a symlink, so it would be interoperable." > > is appalling arrogance. No. You do *not* get to break ABI with that > argument. The point of the ABI spec is that *everybody* follows > it. You don't change it just because you think it'll make your life a > little easier when bootstrapping a system. AFAIK there are at least 3 distros where the default interpreter path is changed to follow distro-specific customizations: Gentoo, Nix, Guix. So evidently, some people *do* get to "break AB
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote: >On Fri, 12 May 2023 at 12:08, Steve McIntyre wrote: >> >> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote: >> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: >> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote: >> >>> >> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: >> >>> > >> >>> >The core issue as I see it is as follows: >> >>> > >> >>> >- Debian has decided to support only merged-/usr, including possibly >> >>> > moving /bin/sh to /usr/bin/sh or using /usr/lib*/ld-linux-x86-64.so.2 >> >>> > as the interpreter in binaries. >> >>> >> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've >> >>> seen. The interpreter must *not* be changed willy-nilly. >> >> >> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of >> >>seemingly crazy options, as in, "what would _actually_ explode if we >> >>do this or do that?", on this very d-devel thread. I posted a longer >> >>version here some days ago: >> >> >> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html >> > >> >Oh holy fuck. >> > >> >You're talking about changing ABI by doing this. That *is* utterly >> >crazy. No. >> >> People have asked me to expand on this further... >> >> I've been involved in defining ABI before, specifically for >> armhf. It's not a quick and easy process. It needs buy-in from all >> sides to make things work, and people *really* value the >> interoperability that it enables. >> >> The interpreter path is one of the most important parts of the ABI >> spec, the bit that makes binaries compatible between all the various >> stakeholders: compiler/tools people, distros, software vendors, >> etc. Lots of the rest of the details downstream of this can be >> changed, and people do this all the time - compare multilib to >> multi-arch for example. That all works fine *so long as* the runtime >> linker can be located and started OK. > >The loader is still available via the old path, so external/third >party/local/other software works unchanged. This should negatively >only affect our 1st party packages, when running on a non-merged >distro. So why the hell do you want to break this in the first place? Does a symlink in the "wrong" place offend you for some reason? For that you want to change a core assumption in *every single binary* in Debian? Believe me, I've been here in the past when we made changes in armhf to accommodate earlier mistakes. That was just for one architecture. What possible benefit do you see in this change? >And are _all_ our packages really 100% compatible with other distros >at all? Are they even supposed to be? > >For example, if I download efibootmgr from Bookworm on an Ubuntu Focal >machine, when I try to run it, it fails: > >root@focal:/tmp# wget >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb >--2023-05-12 12:46:17-- >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb >Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4 >Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... >connected. >HTTP request sent, awaiting response... 200 OK >Length: 27572 (27K) [application/vnd.debian.binary-package] >Saving to: 'efibootmgr_17-2_amd64.deb' > >efibootmgr_17-2_amd64.deb >100%[===>] 26.93K >--.-KB/sin 0.04s > >2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved >[27572/27572] > >root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm >root@focal:/tmp# ./ebm/bin/efibootmgr >./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version >`GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr) > >Should I file a severity: serious bug against efibootmgr because it is >not interoperable? You're wilfully missing the point, and you know it. >The answer is obviously not, because it would be absurd to expect a >binary compiled against libraries from one distro to "just work" on an >entirely different distro. Glibc itself is not forward compatible, and >is allowed to add new symbols, that are not present in older versions, >and packages are allowed to depend on them. Aren't those also ABI >breakages? What about all the libraries that bump soname? What about >binaries that rely on newer kernel interfaces, or IPC interfaces? > >So, what I am asking is, what actual, real difference does it make if, >by default (and with an override available for example), packages >built on Debian for Debian record the ld path to point to its (actual) >location on Debian, via say a compiler spec file that is injected in a >deb build? >There very likely is some real difference and impact, and I am >genuinely and honestly asking what it could be. If nothing else, it's >an interesting topic, even if likely nothing comes out of it. I have better things to do than argue about this. I refuse to engage with this right now. You're talking about breakin
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, May 12, 2023 at 03:29:29PM +0100, Steve McIntyre wrote: > >> >Oh holy fuck. > So why the hell do you want to break this in the first place? > You're wilfully missing the point, and you know it. > I have better things to do than argue about this. I refuse to engage > with this right now. You're talking about breaking things for *no* > discernible benefit that I've seen any discussion about. language please. and also assume good faith. thanks. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ Das Leben ist schön. Von 'einfach' war nie die Rede. (@lernzyklus) signature.asc Description: PGP signature
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On Fri, 12 May 2023 at 15:30, Steve McIntyre wrote: > > On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote: > >On Fri, 12 May 2023 at 12:08, Steve McIntyre wrote: > >> > >> On Fri, May 12, 2023 at 11:40:05AM +0100, Steve McIntyre wrote: > >> >On Fri, May 12, 2023 at 10:49:32AM +0100, Luca Boccassi wrote: > >> >>On Fri, 12 May 2023 at 09:40, Steve McIntyre wrote: > >> >>> > >> >>> On Fri, May 12, 2023 at 07:40:00AM +0200, Ansgar wrote: > >> >>> > > >> >>> >The core issue as I see it is as follows: > >> >>> > > >> >>> >- Debian has decided to support only merged-/usr, including possibly > >> >>> > moving /bin/sh to /usr/bin/sh or using > >> >>> > /usr/lib*/ld-linux-x86-64.so.2 > >> >>> > as the interpreter in binaries. > >> >>> > >> >>> WTF? *Nobody* has been talking about breaking ABI like this, that I've > >> >>> seen. The interpreter must *not* be changed willy-nilly. > >> >> > >> >>Nothing's happening 'willy-nilly'. We are discussing a bunch of > >> >>seemingly crazy options, as in, "what would _actually_ explode if we > >> >>do this or do that?", on this very d-devel thread. I posted a longer > >> >>version here some days ago: > >> >> > >> >>https://lists.debian.org/debian-gcc/2023/05/msg00030.html > >> > > >> >Oh holy fuck. > >> > > >> >You're talking about changing ABI by doing this. That *is* utterly > >> >crazy. No. > >> > >> People have asked me to expand on this further... > >> > >> I've been involved in defining ABI before, specifically for > >> armhf. It's not a quick and easy process. It needs buy-in from all > >> sides to make things work, and people *really* value the > >> interoperability that it enables. > >> > >> The interpreter path is one of the most important parts of the ABI > >> spec, the bit that makes binaries compatible between all the various > >> stakeholders: compiler/tools people, distros, software vendors, > >> etc. Lots of the rest of the details downstream of this can be > >> changed, and people do this all the time - compare multilib to > >> multi-arch for example. That all works fine *so long as* the runtime > >> linker can be located and started OK. > > > >The loader is still available via the old path, so external/third > >party/local/other software works unchanged. This should negatively > >only affect our 1st party packages, when running on a non-merged > >distro. > > So why the hell do you want to break this in the first place? Does a > symlink in the "wrong" place offend you for some reason? For that you > want to change a core assumption in *every single binary* in Debian? > Believe me, I've been here in the past when we made changes in armhf > to accommodate earlier mistakes. That was just for one > architecture. What possible benefit do you see in this change? As it was mentioned on the list, because it makes bootstrapping self-contained, that's a real and concrete benefit that some developers like Helmut care greatly about, and that's why we are talking about it. To me, it sounds very attractive to have a self-contained and canonicalized distro-wide configuration. If the canonical location where certain files are stored in /usr/bin or /usr/lib, it seems sensible to me to configure Debian software to look for it where we actually put it, while maintaining compatibility for external/local software so that it keeps working. And it is also unclear so far what would outright break - the externally defined ABI in terms of where the loader can be accessed at, would still be respected. Hence why questions are being asked. Nobody's being forced to do anything, this is just a discussion. > >And are _all_ our packages really 100% compatible with other distros > >at all? Are they even supposed to be? > > > >For example, if I download efibootmgr from Bookworm on an Ubuntu Focal > >machine, when I try to run it, it fails: > > > >root@focal:/tmp# wget > >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb > >--2023-05-12 12:46:17-- > >http://ftp.de.debian.org/debian/pool/main/e/efibootmgr/efibootmgr_17-2_amd64.deb > >Resolving ftp.de.debian.org (ftp.de.debian.org)... 141.76.2.4 > >Connecting to ftp.de.debian.org (ftp.de.debian.org)|141.76.2.4|:80... > >connected. > >HTTP request sent, awaiting response... 200 OK > >Length: 27572 (27K) [application/vnd.debian.binary-package] > >Saving to: 'efibootmgr_17-2_amd64.deb' > > > >efibootmgr_17-2_amd64.deb > >100%[===>] 26.93K > >--.-KB/sin 0.04s > > > >2023-05-12 12:46:17 (740 KB/s) - 'efibootmgr_17-2_amd64.deb' saved > >[27572/27572] > > > >root@focal:/tmp# dpkg -x efibootmgr_17-2_amd64.deb ebm > >root@focal:/tmp# ./ebm/bin/efibootmgr > >./ebm/bin/efibootmgr: /lib/x86_64-linux-gnu/libc.so.6: version > >`GLIBC_2.34' not found (required by ./ebm/bin/efibootmgr) > > > >Should I file a severity: serious bug against efibootmgr because it is > >not interoperable? > > You're wilfully missing the point, and you know it. I'm trying to determine
Re: Bug#1035904: dpkg currently warning about merged-usr systems (revisited)
On 2023-05-12 Ansgar wrote: [...] > The core issue as I see it is as follows: [...] > Do you think this summary of the issue is right? I think Simon's reading of the situation as posted in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1035904#30 makes a lot of sense. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
