Processed: Re: Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Processing control commands: > reassign -1 tech-ctte Bug #1065416 [linux-libc-dev] linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely Bug reassigned from package 'linux-libc-dev' to 'tech-ctte'. No longer marked as found in versions linux/6.7.7-1. Ignoring request to alter fixed versions of bug #1065416 to the same values previously set > severity -1 normal Bug #1065416 [tech-ctte] linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely Severity set to 'normal' from 'serious' -- 1065416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Control: reassign -1 tech-ctte Control: severity -1 normal Hi I don't see any way to solve this issue right now. Please decide this matter according to 6.1 nr 2 Debian Constitution. Background: linux-libc-dev provides the Linux API for consumption by all userspace stuff. This package was arch-any for as long as I remember and provided only the headers for this single architecture. Since a short while this package is now arch-all and provides headers for all known Debian architectures in one swoop. This change was done when the Ubuntu maintainers asked if we wanted to follow. This now means that new architectures will need to get added to linux-libc-dev first and it is not longer required to push hand crafted packages somewhere in the ports archive. However the package now contains everything that is also contained in the uncoordinated linux-libc-dev-*-cross packages. The only difference is the physical location of the files (/usr/include instead of the policy violating /usr/*/include). This API proofed to be compatible with all tested packages available in the archive. Because of this (from my side unnecessary) code duplication, I opened the plan to replace linux-libc-dev-*-cross, see #1059786. Two months later the following bug report comes in: On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't > do that completely > > Provides: linux-libc-dev-amd64-cross (= 6.7.7-1), ... > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. > > Please stop providing the cross-packages, you don't even need a breaks, > because the current cross packages continue to work. > > Once that is done, I'll reduce the cross packages to some symlinks. Even after several e-mails, the OP was unable or unwilling to show where the problem actually lies. Please decide who is going to provide linux-libc-dev and all the associated cross stuff and how it should look like. Regards, Bastian -- Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On 21.03.24 07:58, Bastian Blank wrote: On Wed, Mar 20, 2024 at 09:59:31PM +0100, Matthias Klose wrote: Independent of any technical issues, this is a hijacking of a package name. Please revert that change. Okay. Please prepare to take over linux-libc-dev alltogether then, there can be only one copy. please drop the provides: linux-libc-dev-alpha-cross (= 6.7.9-2), linux-libc-dev-amd64-cross (= 6.7.9-2), linux-libc-dev-arm64-cross (= 6.7.9-2), linux-libc-dev-armel-cross (= 6.7.9-2), linux-libc-dev-armhf-cross (= 6.7.9-2), linux-libc-dev-hppa-cross (= 6.7.9-2), linux-libc-dev-i386-cross (= 6.7.9-2), linux-libc-dev-loong64-cross (= 6.7.9-2), linux-libc-dev-m68k-cross (= 6.7.9-2), linux-libc-dev-mips-cross (= 6.7.9-2), linux-libc-dev-mips64-cross (= 6.7.9-2), linux-libc-dev-mips64el-cross (= 6.7.9-2), linux-libc-dev-mips64r6el-cross (= 6.7.9-2), linux-libc-dev-mipsel-cross (= 6.7.9-2), linux-libc-dev-powerpc-cross (= 6.7.9-2), linux-libc-dev-ppc64-cross (= 6.7.9-2), linux-libc-dev-ppc64el-cross (= 6.7.9-2), linux-libc-dev-riscv64-cross (= 6.7.9-2), linux-libc-dev-s390x-cross (= 6.7.9-2), linux-libc-dev-sh4-cross (= 6.7.9-2), linux-libc-dev-sparc64-cross (= 6.7.9-2), linux-libc-dev-x32-cross (= 6.7.9-2)
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On Wed, Mar 20, 2024 at 09:59:31PM +0100, Matthias Klose wrote: > Independent of any technical issues, this is a hijacking of a package name. > Please revert that change. Okay. Please prepare to take over linux-libc-dev alltogether then, there can be only one copy. Bastian -- Insufficient facts always invite danger. -- Spock, "Space Seed", stardate 3141.9
Processed: Re: Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Processing control commands:
> reopen -1
Bug #1065416 {Done: Bastian Blank } [linux-libc-dev]
linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do
that completely
Bug reopened
Ignoring request to alter fixed versions of bug #1065416 to the same values
previously set
--
1065416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Control: reopen -1 On 20.03.24 21:48, Bastian Blank wrote: Hi Not a single piece of evidence of a breakage showed up within the last weeks. I'm therefor closing this bug report. Bastian, sorry for being quiet in the time of the time_t64 transitions. I am re-opening, and CCing lea...@debian.org. Independent of any technical issues, this is a hijacking of a package name. Please revert that change. Matthias
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Helmut On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote: > The problem arises in the reverse sense. If a file does not exist in > one, it is searched in the second and erroneously may be found. That may > make tests pass that should not pass and typically causes a link failure > later. But you want /usr/include to be found. Otherwise you would not be able to use most of the libraries for cross compiling. > . While I do not have a concrete example at hand, I have seen this > pattern repeatedly and generally favour moving stuff out of /usr/include > to avoid this kind of confusion that causes difficult to debug problems. > This also motivates #798955 (in addition to the problem with file > conflicts). In this case here, this would just find kernel headers for a different version. Those are essentially a headers only library, nothing is available for linking. And all the headers provided in /usr/include are the same for all architectures. So moving stuff out of /usr/include might be a good idea if the -dev package is itself arch dependent. > The one case I really do remember quite well is sanitizers. These should > not be enabled in the earlier toolchain stages and failing to disable > them tends to cause linker failures. I don't think it matches the > concrete situation exactly though. You also make a good case in your > followup reporting that gcc-13-cross actually builds. Yep. My problem is: I tested stuff, not everything of course, and did not see any breakage. Also I checked the values I know could influence that and they say it is fine. So at some point I have to assume it is not broken, as exhaustive search is simply not possible. The only statement in this bug report is now: it is located in a different location, so it is broken. No single piece of evidence is shown, like broken builds or some other ways to see the brokeness. Regards, Bastian -- A princess should not be afraid -- not with a brave knight to protect her. -- McCoy, "Shore Leave", stardate 3025.3
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Bastian, On Mon, Mar 04, 2024 at 11:04:22PM +0100, Bastian Blank wrote: > > Arguably, a cross toolchain build should probably search > > /usr/include/. I went back and forth a bit with Matthias > > about whether we could add this and did not fully understand his > > reasons, but there is one technical reason we want to avoid it for now. > > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed > > and these packages can have differing versions. When that happens and we > > search both /usr//include and /usr/include/, we'd > > mix two glibc versions with usually bad results (been there). > > But this is a search path. If a file exists in one, the second one is > not found. So nothing can happen even from version skew. The problem arises in the reverse sense. If a file does not exist in one, it is searched in the second and erroneously may be found. That may make tests pass that should not pass and typically causes a link failure later. While I do not have a concrete example at hand, I have seen this pattern repeatedly and generally favour moving stuff out of /usr/include to avoid this kind of confusion that causes difficult to debug problems. This also motivates #798955 (in addition to the problem with file conflicts). > > The other aspect here is that it is not sufficient to add > > /usr/include/ to the search path as you also need > > /usr/include to get a complete linux kernel headers experience. We > > definitely do not want to add /usr/include, because that is known to > > misguide configure tests performed for the target architecture. > > We are talking about the toolchain itself. What configure tests could > that be? Or is that premature optimization of the gcc build? The one case I really do remember quite well is sanitizers. These should not be enabled in the earlier toolchain stages and failing to disable them tends to cause linker failures. I don't think it matches the concrete situation exactly though. You also make a good case in your followup reporting that gcc-13-cross actually builds. > You just said that the search path used during the build of the > toolchain and the one for everything else are unrelated. So you are > free to create $BUILD/tmp-include with symlinks for asm, asm-generic, > linux. > > The toolchain as installed already finds all headers. So I still don't > see why we need this in the final system. I find this argument fairly convincing and hope Matthias also does. Thank you Helmut
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On Mon, Mar 04, 2024 at 11:04:23PM +0100, Bastian Blank wrote: > At least to show where it breaks. And I actually tried it and can not show the expected breakage from missing /usr/include in the search path. gcc-13-cross builds fine with only linux-libc-dev/6.7.7-1. | -rw-r--r-- 1 bastian bastian 38157 Mar 5 06:40 ../gcc-13-cross_14_amd64.changes Bastian -- You're too beautiful to ignore. Too much woman. -- Kirk to Yeoman Rand, "The Enemy Within", stardate unknown
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On Mon, Mar 04, 2024 at 01:49:24PM +0100, Helmut Grohne wrote: > The packaged gcc cross toolchain uses a sysroot during its own build > still. As it is implemented now, it searches /usr//include, but > not /usr/include/. So quite fundamentally, the Provides that > we two agreed do break the build of cross toolchains right now. Okay, so this problem is about the build of the toolchain, _not_ for everything that comes after. > Arguably, a cross toolchain build should probably search > /usr/include/. I went back and forth a bit with Matthias > about whether we could add this and did not fully understand his > reasons, but there is one technical reason we want to avoid it for now. > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed > and these packages can have differing versions. When that happens and we > search both /usr//include and /usr/include/, we'd > mix two glibc versions with usually bad results (been there). But this is a search path. If a file exists in one, the second one is not found. So nothing can happen even from version skew. > The other aspect here is that it is not sufficient to add > /usr/include/ to the search path as you also need > /usr/include to get a complete linux kernel headers experience. We > definitely do not want to add /usr/include, because that is known to > misguide configure tests performed for the target architecture. We are talking about the toolchain itself. What configure tests could that be? Or is that premature optimization of the gcc build? > So at least for now, I am convinced that we will need > /usr//include to be provided by the package providing > linux-libc-dev-arch-cross. You just said that the search path used during the build of the toolchain and the one for everything else are unrelated. So you are free to create $BUILD/tmp-include with symlinks for asm, asm-generic, linux. The toolchain as installed already finds all headers. So I still don't see why we need this in the final system. > That still leaves the question of which package would have to build that > new linux-libc-dev-cross. The two obvious answers are linux and > cross-toolchain-base. Do you have a preference here? No, the gcc build itself, because it is the only part that needs it from what you said here. > I hope this all makes more sense now. At least to show where it breaks. Bastian -- Each kiss is as the first. -- Miramanee, Kirk's wife, "The Paradise Syndrome", stardate 4842.6
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Bastian, On Mon, Mar 04, 2024 at 12:30:09PM +0100, Bastian Blank wrote: > On Mon, Mar 04, 2024 at 12:07:15PM +0100, Matthias Klose wrote: > > On 04.03.24 11:29, Bastian Blank wrote: > > > On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > > > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. > > > > > > Please be a bit more precise, there are no symlinks in this directory. > > > | # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h > > > | linux-libc-dev-alpha-cross: /usr/alpha-linux-gnu/include/asm/a.out.h > > > | # find /usr/alpha-linux-gnu/include/ -type l > > > | # > > yes, that is the problem. the cross gcc expects these headers in > > /usr/alpha-linux-gnu/include, not in the header location for the host. > > Please show your problem with a log, my crystal ball is broken. This very much was not obvious to me either. I've now talked to Matthias and believe I can explain the problem. The packaged gcc cross toolchain uses a sysroot during its own build still. As it is implemented now, it searches /usr//include, but not /usr/include/. So quite fundamentally, the Provides that we two agreed do break the build of cross toolchains right now. Arguably, a cross toolchain build should probably search /usr/include/. I went back and forth a bit with Matthias about whether we could add this and did not fully understand his reasons, but there is one technical reason we want to avoid it for now. We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed and these packages can have differing versions. When that happens and we search both /usr//include and /usr/include/, we'd mix two glibc versions with usually bad results (been there). While we might consider adding /usr/include/ to the cross toolchain build search path later, it is not something we can do now and before doing that, we need to better understand Matthias' reasons for keeping these separate as well. The other aspect here is that it is not sufficient to add /usr/include/ to the search path as you also need /usr/include to get a complete linux kernel headers experience. We definitely do not want to add /usr/include, because that is known to misguide configure tests performed for the target architecture. In principle, we could extend the symlink farm in linux-libc-dev to also have a lot of /usr/include//linux -> ../linux symlinks (assuming that no other package ever installs to /usr/include/linux, which is a property violated by aufs-dev and oss4-dev). So at least for now, I am convinced that we will need /usr//include to be provided by the package providing linux-libc-dev-arch-cross. As these are only necessary for building the cross toolchains, we probably don't want these in the main linux-libc-dev package. So how about adding a linux-libc-dev-cross package with yet more symlinks? Then we can move the provides over to the linux-libc-dev-cross package and that way repair the cross toolchain builds. I requested that linux-libc-dev provides these for bootstrapping to know which architectures linux-libc-dev actually supports. I don't need these provides exactly, I just need a mechanism to answer the question "Does linux-libc-dev work for a particular architecture?" from the binary package metadata, so we might just change the Provides there to linux-libc-dev-arch dropping the -cross suffix that traditionally identified packages putting stuff into /usr/. Does that sound reasonable to you? That still leaves the question of which package would have to build that new linux-libc-dev-cross. The two obvious answers are linux and cross-toolchain-base. Do you have a preference here? I hope this all makes more sense now. Helmut
Processed: Re: Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Processing control commands: > tags -1 moreinfo Bug #1065416 [linux-libc-dev] linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely Bug #1059786 [linux-libc-dev] cross-toolchain-base: Migrating linux-libc-dev Added tag(s) moreinfo. Added tag(s) moreinfo. -- 1059786: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059786 1065416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Control: tags -1 moreinfo On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't > do that completely > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. So you claim that /usr/DEB_HOST_GNU_TYPE/include is critical part of the API for this package name? If you think so, please provide evidence. This path is in violation of the Debian policy, so can't be provided by linux-libc-dev. Bastian -- You canna change the laws of physics, Captain; I've got to have thirty minutes!
Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
On Mon, Mar 04, 2024 at 12:07:15PM +0100, Matthias Klose wrote: > On 04.03.24 11:29, Bastian Blank wrote: > > On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > > > However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. > > > > Please be a bit more precise, there are no symlinks in this directory. > > | # dpkg -S /usr/alpha-linux-gnu/include/asm/a.out.h > > | linux-libc-dev-alpha-cross: /usr/alpha-linux-gnu/include/asm/a.out.h > > | # find /usr/alpha-linux-gnu/include/ -type l > > | # > yes, that is the problem. the cross gcc expects these headers in > /usr/alpha-linux-gnu/include, not in the header location for the host. Please show your problem with a log, my crystal ball is broken. arm-linux-gnueabihf-cpp-13 tells me: | #include <...> search starts here: | /usr/lib/gcc-cross/arm-linux-gnueabihf/13/include | /usr/lib/gcc-cross/arm-linux-gnueabihf/13/../../../../arm-linux-gnueabihf/include | /usr/include/arm-linux-gnueabihf | /usr/include | End of search list. So clearly /usr/include/arm-linux-gnueabihf is used. Regards, Bastian -- It would be illogical to assume that all conditions remain stable. -- Spock, "The Enterprise Incident", stardate 5027.3
Processed (with 1 error): Re: Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Processing control commands: > unmerge 1059786 -1 Unknown command or malformed arguments to command. > reassign -1 linux-libc-dev Bug #1065416 [cross-toolchain-base] linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely Bug #1059786 [cross-toolchain-base] cross-toolchain-base: Migrating linux-libc-dev Bug reassigned from package 'cross-toolchain-base' to 'linux-libc-dev'. Bug reassigned from package 'cross-toolchain-base' to 'linux-libc-dev'. Ignoring request to alter found versions of bug #1065416 to the same values previously set Ignoring request to alter found versions of bug #1059786 to the same values previously set Ignoring request to alter fixed versions of bug #1065416 to the same values previously set Ignoring request to alter fixed versions of bug #1059786 to the same values previously set > found -1 6.7.7-1 Bug #1065416 [linux-libc-dev] linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely Bug #1059786 [linux-libc-dev] cross-toolchain-base: Migrating linux-libc-dev Marked as found in versions linux/6.7.7-1. Marked as found in versions linux/6.7.7-1. > severity -1 serious Bug #1065416 [linux-libc-dev] linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely Bug #1059786 [linux-libc-dev] cross-toolchain-base: Migrating linux-libc-dev Severity set to 'serious' from 'normal' Severity set to 'serious' from 'normal' -- 1059786: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059786 1065416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Processed: Re: Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Processing control commands: > reassign -1 cross-toolchain-base Bug #1065416 [linux-libc-dev] linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely Bug reassigned from package 'linux-libc-dev' to 'cross-toolchain-base'. No longer marked as found in versions linux/6.7.7-1. Ignoring request to alter fixed versions of bug #1065416 to the same values previously set > forcemerge 1059786 -1 Bug #1059786 [cross-toolchain-base] cross-toolchain-base: Migrating linux-libc-dev Bug #1059786 [cross-toolchain-base] cross-toolchain-base: Migrating linux-libc-dev Added tag(s) sid and trixie. Bug #1065416 [cross-toolchain-base] linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely Severity set to 'normal' from 'serious' Added tag(s) patch. Merged 1059786 1065416 -- 1059786: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059786 1065416: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Control: reassign -1 cross-toolchain-base Control: forcemerge 1059786 -1 On Mon, Mar 04, 2024 at 08:53:11AM +0100, Matthias Klose wrote: > linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't > do that completely This is #1059786. This lacks a response from you. So I'm merging those. Bastian -- There are always alternatives. -- Spock, "The Galileo Seven", stardate 2822.3
Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Package: linux-libc-dev Version: 6.7.7-1 Severity: serious Tags: sid trixie linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely Provides: linux-libc-dev-amd64-cross (= 6.7.7-1), ... However the links in /usr/DEB_HOST_GNU_TYPE/include are missing. Please stop providing the cross-packages, you don't even need a breaks, because the current cross packages continue to work. Once that is done, I'll reduce the cross packages to some symlinks.
