Bug#1065416: requesting input on recent posts to #1065416
Hi Matthias (2024.08.16_12:58:22_+0200) I tried to set you up with some questions that were easy to answer here, without trying to push any solution. Answering them would help the committee to understand the options on the table, and probably help the Kernel team to understand the problems with the current package structure. Let me repeat the questions, and you can check my assumptions: > Will it be another binary package in cross-toolchain-base, built from > linux-source-*? I'm assuming so? > Will cross-toolchain-base now contain linux-libc-dev-*-cross and > linux-libc-dev, as separate Arch: all, Multi-Arch: foreign binary > packages? I'm assuming linux-libc-dev-*-cross stay the way they currently are in cross-toolchain-base. You'd then add linux-libc-dev, Arch: any (as it used to be) Or maybe strip them down to dependency packages that depend on the cross package for each arch? > I don't know much about the stability of these headers, but I see > regular changes. I assume moving linux-libc-dev from the linux source > to cross-toolchain-base will mean that you'll have to do more frequent > uploads of cross-toolchain-base to keep them up to date, where this was > less critical for cross-compiler toolchains. > > What are the consequences of not staying up to date? I'm guessing > incoming bug reports from other packages wanting to use new features. I already put an assumption in there :P Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1065416: requesting input on recent posts to #1065416
Added Bastian to Cc for a question below. On Sun, Aug 25, 2024 at 01:14:27AM +0800, YunQiang Su wrote: > Helmut Grohne 于2024年8月24日周六 19:20写道： > > I think this is a bad example on multiple levels. For one thing, > > limits.h is glibc and not linux. Then, it is not actually > > architecture-dependent[1] (otherwise it could not be in /usr/include > > directly) and finally, the way gcc deals with limits.h is known broken > > for seven years and has a patch, see see > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677. > > > > Sure. That's why I think that we should keep kernel headers in > /usr//include for now before that we can be sure that these problem > has been fixed. It is the status quo that you try to defend where LIMITS_H_TEST is broken. Even now, gcc looks into /usr/include for target headers and it should not. Hence, I do not think this is not a reasonable argument for keeping the status quo. > One reason I'd prefer to keep the duplicating contents is that we may need to > have cross-toolchains for non debian official ports. With Bastian's Multi-Arch: foreign model, that is not a problem. He can just add the symlink farms for additional ports with little effort to the main linux-libc-dev package. src:linux tends to be uploaded more frequently than src:cross-toolchain-base. The way I understood Bastian is that he is ok with adding support for niche ports to the main package on demand. Last time I asked him to add an architecture, it was added relatively quickly. Bastian, would you confirm? > Keeping duplicating headers of glibc/linux-kernel won't break multiarch > support. While that is technically true, we also get all the downsides of the duplication. I still have difficulties to see the advantages of doing this. The arguments you brought forward thus far looked refutable to me. > The configure.ac of GCC won't try to find headers in multiarch directories. > So if we move all architecture-dependent headers into /usr/include/, > gcc will have some trouble to build itself, especially for multilib support. I attempted to answer this in my previous reply, but apparently the intended message did not arrive or there is a flaw in what I wrote. The idea for making building of gcc work is not that it should search /usr/include/ for the reasons that you mention. The idea was to create a symlink farm pointing to /usr/include/ inside the build directory and then pass that to gcc. In fact, the gcc build already does this more selectively. The directory is called $(builddir)/sys-include, see https://sources.debian.org/src/gcc-14/14.2.0-3/debian/rules2/#L1325 This method could be extended to also link linux kernel headers. > That's why gcc-multilib symlinks /usr/include/x86_64-linux-gnu/asm to > /usr/include/asm. > > You can have a try to build gcc without gcc-multilib installed with > ../configure --target=x86_64-linux-gnu --enable-multilib > > Or you can have a try to build cross-gcc with gcc-multilib installed: >../configure --target=aarch64-linux-gnu > Then some mistake of feature detection will happen. As far as I understand it, the aforementioned part in rules2 handles exactly this case (and that's what the comment states). Would you be able to add more details as to what goes wrong here? > Thus it may be the best solution for cross-toolchains to have itself > kernel/glibc headers. I am not sure what you mean here. I find it plausible to interpret this statement both as requesting the duplicate linux headers to be kept and as agreeing with Bastian's suggestion to construct the kernel/glibc headers as a symlink farm at the time of building gcc. Helmut
Bug#1065416: requesting input on recent posts to #1065416
Helmut Grohne 于2024年8月24日周六 19:20写道： > > On Fri, Aug 23, 2024 at 04:08:28PM +0800, Yunqiang Su wrote: > > I struggled with the build system, and I know the real problem: > > Thanks for chiming in! > > > 1. linux-libc-dev-ARCH-cross is useful, for some case if we maintain an > > cross toolchain of a port > > that Debian is not supported yet. The example is > > src:cross-toolchain-base-mipsen. > > I support the cross toolchain for 12 MIPS ports: EL/BE X 32/64/N32 X R2/R6. > > > > > > 2. It is not OK to search base headers when we configure gcc itself. > > > > https://patchwork.sourceware.org/project/gcc/patch/20240614121218.63375-1-...@gcc.gnu.org/ > > > > GCC/configure.ac detects features by the headers of linux/glibc. > > Let’s have a example: we are building a mips64el cross toolchain on a > > amd64 machine: > > If gcc/configure.ac sees /usr/include/limits.h before than > > /usr/mips64el-linux-gnuabi64/include/limits.h > > Our mips64el-linux-gnuabi64-gcc will have some problem. > > > > And you can find the `fixinclude` in GCC for more information. > > I think this is a bad example on multiple levels. For one thing, > limits.h is glibc and not linux. Then, it is not actually > architecture-dependent[1] (otherwise it could not be in /usr/include > directly) and finally, the way gcc deals with limits.h is known broken > for seven years and has a patch, see see > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677. > Sure. That's why I think that we should keep kernel headers in /usr//include for now before that we can be sure that these problem has been fixed. > As Bastian pointed out earlier, the exact location of the kernel headers > is not that important so long as gcc constructs a symlink farm for a > build-time sysroot. To me, it is not obvious that keeping a non-trivial > number of linux-libc-dev-$arch-cross packages duplicating content from > linux-libc-dev is the superior solution to constructing changing the > build of gcc-cross. > One reason I'd prefer to keep the duplicating contents is that we may need to have cross-toolchains for non debian official ports. > > @Mattias In fact. The current gcc-X-cross searches /usr/include when > > configure, it is dangerous. > > --includedir=/usr/mipsel-linux-gnu/include --with-sysroot=/ > > —prefix=/usr > > Is not good. > > The prefer way should be `—prefix=/usr` only with my patch. > > Again, I disagree. One of the biggest benefits of multiarch is that you > get to no longer distinguish between build-time paths from run-time > paths and always assume your sysroot to be / resulting in a lot of > simplification. We certainly want all of our cross compilers to search > /usr/include, so consulting that directory at build time actually makes > sense from a multiarch point of view. The multiarch way to deal with > architecture-specific differences (and headers that do not exist for all > architectures) is to move them to /usr/include/ such that > /usr/include only ever contains fully architecture-independent headers. > Keeping duplicating headers of glibc/linux-kernel won't break multiarch support. > So this is dangerous in the sense that we still have some > architecture-dependent headers in /usr/include directly. If you happen > to know any affected headers, I suggest filing bugs with the owning > packages and ask them to move them to the triplet subdirectory. > The configure.ac of GCC won't try to find headers in multiarch directories. So if we move all architecture-dependent headers into /usr/include/, gcc will have some trouble to build itself, especially for multilib support. That's why gcc-multilib symlinks /usr/include/x86_64-linux-gnu/asm to /usr/include/asm. You can have a try to build gcc without gcc-multilib installed with ../configure --target=x86_64-linux-gnu --enable-multilib Or you can have a try to build cross-gcc with gcc-multilib installed: ../configure --target=aarch64-linux-gnu Then some mistake of feature detection will happen. Thus it may be the best solution for cross-toolchains to have itself kernel/glibc headers. > Helmut > > [1] Technically, this is a lie if we consider competing libc > implementations. As Debian treats the libc as part of the > architecture, we'd really require gcc's and musl's limits.h to equal > here, but in reality musl just install theirs to the multiarch. > However, since musl-linux-any is not bootstrappable, for practical > matters, limits.h is architecture-independent on reasonable Debian > architectures including ports. > -- YunQiang Su
Bug#1065416: requesting input on recent posts to #1065416
On Fri, Aug 23, 2024 at 04:08:28PM +0800, Yunqiang Su wrote: > I struggled with the build system, and I know the real problem: Thanks for chiming in! > 1. linux-libc-dev-ARCH-cross is useful, for some case if we maintain an cross > toolchain of a port > that Debian is not supported yet. The example is > src:cross-toolchain-base-mipsen. > I support the cross toolchain for 12 MIPS ports: EL/BE X 32/64/N32 X R2/R6. > > > 2. It is not OK to search base headers when we configure gcc itself. > > https://patchwork.sourceware.org/project/gcc/patch/20240614121218.63375-1-...@gcc.gnu.org/ > > GCC/configure.ac detects features by the headers of linux/glibc. > Let’s have a example: we are building a mips64el cross toolchain on a > amd64 machine: > If gcc/configure.ac sees /usr/include/limits.h before than > /usr/mips64el-linux-gnuabi64/include/limits.h > Our mips64el-linux-gnuabi64-gcc will have some problem. > > And you can find the `fixinclude` in GCC for more information. I think this is a bad example on multiple levels. For one thing, limits.h is glibc and not linux. Then, it is not actually architecture-dependent[1] (otherwise it could not be in /usr/include directly) and finally, the way gcc deals with limits.h is known broken for seven years and has a patch, see see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677. As Bastian pointed out earlier, the exact location of the kernel headers is not that important so long as gcc constructs a symlink farm for a build-time sysroot. To me, it is not obvious that keeping a non-trivial number of linux-libc-dev-$arch-cross packages duplicating content from linux-libc-dev is the superior solution to constructing changing the build of gcc-cross. > @Mattias In fact. The current gcc-X-cross searches /usr/include when > configure, it is dangerous. > --includedir=/usr/mipsel-linux-gnu/include --with-sysroot=/ > —prefix=/usr > Is not good. > The prefer way should be `—prefix=/usr` only with my patch. Again, I disagree. One of the biggest benefits of multiarch is that you get to no longer distinguish between build-time paths from run-time paths and always assume your sysroot to be / resulting in a lot of simplification. We certainly want all of our cross compilers to search /usr/include, so consulting that directory at build time actually makes sense from a multiarch point of view. The multiarch way to deal with architecture-specific differences (and headers that do not exist for all architectures) is to move them to /usr/include/ such that /usr/include only ever contains fully architecture-independent headers. So this is dangerous in the sense that we still have some architecture-dependent headers in /usr/include directly. If you happen to know any affected headers, I suggest filing bugs with the owning packages and ask them to move them to the triplet subdirectory. Helmut [1] Technically, this is a lie if we consider competing libc implementations. As Debian treats the libc as part of the architecture, we'd really require gcc's and musl's limits.h to equal here, but in reality musl just install theirs to the multiarch. However, since musl-linux-any is not bootstrappable, for practical matters, limits.h is architecture-independent on reasonable Debian architectures including ports.
Bug#1065416: requesting input on recent posts to #1065416
I struggled with the build system, and I know the real problem: 1. linux-libc-dev-ARCH-cross is useful, for some case if we maintain an cross toolchain of a port that Debian is not supported yet. The example is src:cross-toolchain-base-mipsen. I support the cross toolchain for 12 MIPS ports: EL/BE X 32/64/N32 X R2/R6. 2. It is not OK to search base headers when we configure gcc itself. https://patchwork.sourceware.org/project/gcc/patch/20240614121218.63375-1-...@gcc.gnu.org/ GCC/configure.ac detects features by the headers of linux/glibc. Let’s have a example: we are building a mips64el cross toolchain on a amd64 machine: If gcc/configure.ac sees /usr/include/limits.h before than /usr/mips64el-linux-gnuabi64/include/limits.h Our mips64el-linux-gnuabi64-gcc will have some problem. And you can find the `fixinclude` in GCC for more information. @Mattias In fact. The current gcc-X-cross searches /usr/include when configure, it is dangerous. --includedir=/usr/mipsel-linux-gnu/include --with-sysroot=/ —prefix=/usr Is not good. The prefer way should be `—prefix=/usr` only with my patch.
Bug#1065416: requesting input on recent posts to #1065416
On 2024-08-16 19:35 +0200, Bastian Blank wrote: > > - Bastian's assertion that the current linux-libc-dev package doesn't > >break anything in the archive, doesn't say anything. These bits > >are just not used by anything in the archive. > > Ah, now we finally get somewhere. All of this is about non-Debian. Breaking "cross-compiling with debian tools on debian" is significant. It's not helpful to characterise that as 'non-Debian'. It's something we've done well for a long time, and is the reason some people use Debian. Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Bug#1065416: requesting input on recent posts to #1065416
Hi Bastian (2024.08.16_17:53:17_+) > > The Technical Committee is hoping that this will be resolved without > > requiring us to make a decision. If the take-over offer resolves the > > issue, then we will probably vote to take no further action. > > Well, take-over removes the need for talk. And talk is what is missing. > We can do it this way, but it make the load higher for everyone. Noted that this is still not your preferred solution here. The Committee isn't set on that solution, if you find other ways to resolve this, that works for us, too. > But at least now Mathias actually told that his problems doesn't > actually exist in the Debian archive, but outside of it. That's kind of > unexpected. We don't cross build anything in the archive, so it isn't completely unexpected to me. > I have a patch to move the headers (or better said a symlink farm) to > /usr/*/include. But we are still without any indication if this is the > problem he talked about. That's exactly what's described in this bug's opening message and in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059786#29 Bastian, I think you got caught up on the details of whether they needed to be symlinks or files, but I think either should work. Can I suggest posting this patch and seeing if Matthias thinks it's sufficient to resolve the issue? I understand your frustration with unclear details on exactly what was breaking and why. Reading the bugs, I think most of the questions about the problems are now answered somewhere in them. Stefano > > Bastian > > -- > You! What PLANET is this! > -- McCoy, "The City on the Edge of Forever", stardate 3134.0 > -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1065416: requesting input on recent posts to #1065416
On Fri, Aug 16, 2024 at 12:58:22PM +0200, Stefano Rivera wrote: > The Technical Committee is hoping that this will be resolved without > requiring us to make a decision. If the take-over offer resolves the > issue, then we will probably vote to take no further action. Well, take-over removes the need for talk. And talk is what is missing. We can do it this way, but it make the load higher for everyone. No idea if this is a good pretext to allow people to just not say anything about what they mean. But at least now Mathias actually told that his problems doesn't actually exist in the Debian archive, but outside of it. That's kind of unexpected. I have a patch to move the headers (or better said a symlink farm) to /usr/*/include. But we are still without any indication if this is the problem he talked about. Bastian -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0
Bug#1065416: requesting input on recent posts to #1065416
On Sat, Jul 20, 2024 at 01:01:42PM +0200, Matthias Klose wrote:
> I am re-adding lea...@debian.org, and now also commun...@debian.org. I still
> don't see this as an issue that the Technical Committee should decide. This
> is aggressively confrontational behavior of one of the Debian kernel
> maintainers, and it should be handled as that.
So this is a personal, not a technical problem.
> - I am accepting the offer given in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#108
> to take over the linux-libc-dev package.
> I will start working on that at DebCamp and DebConf.
No. Also maybe you want to talk to dimitri.led...@canonical.com, as
his question started all of this.
> - Bastian's assertion that the current linux-libc-dev package doesn't
>break anything in the archive, doesn't say anything. These bits
>are just not used by anything in the archive.
Ah, now we finally get somewhere. All of this is about non-Debian.
> As you can see from the commits for the gcc-for-{build,host} changes, these
> were done around the same time as this controversial linux-libc-dev upload.
> So while having to fix one messy set of patches from Helmut, Bastian assumes
> a no-reply on the linux-libc-dev issue as an OK, that's odd.
This was a bug report at a source package you maintain. Did you not see it?
Bastian
--
Oblivion together does not frighten me, beloved.
-- Thalassa (in Anne Mulhall's body), "Return to Tomorrow",
stardate 4770.3.
Bug#1065416: requesting input on recent posts to #1065416
Hi Matthias (2024.07.20_13:01:42_+0200) > I still don't see this as an issue that the Technical Committee should > decide. The Technical Committee is hoping that this will be resolved without requiring us to make a decision. If the take-over offer resolves the issue, then we will probably vote to take no further action. > - I am accepting the offer given in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#108 > to take over the linux-libc-dev package. > I will start working on that at DebCamp and DebConf. Can you tell us a little more about how you plan to maintain linux-libc-dev? Specifically: Will it be another binary package in cross-toolchain-base, built from linux-source-*? Will cross-toolchain-base now contain linux-libc-dev-*-cross and linux-libc-dev, as separate Arch: all, Multi-Arch: foreign binary packages? I don't know much about the stability of these headers, but I see regular changes. I assume moving linux-libc-dev from the linux source to cross-toolchain-base will mean that you'll have to do more frequent uploads of cross-toolchain-base to keep them up to date, where this was less critical for cross-compiler toolchains. What are the consequences of not staying up to date? I'm guessing incoming bug reports from other packages wanting to use new features. Stefano -- Stefano Rivera http://tumbleweed.org.za/ +1 415 683 3272
Bug#1065416: requesting input on recent posts to #1065416
Hi all, Am Tue, Jul 23, 2024 at 04:10:46PM +0900 schrieb Sean Whitton: > On Sat 20 Jul 2024 at 01:01pm +02, Matthias Klose wrote: > > > - I am accepting the offer given in > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#108 > > to take over the linux-libc-dev package. > > I will start working on that at DebCamp and DebConf. > > This is a significant point of agreement. Bastian, how about we revert > your changes for the time being, to give Matthias time to do this work? Since leader@d.o was involved: I personally consider this a good solution as well. Kind regards Andreas. -- https://fam-tille.de
Bug#1065416: requesting input on recent posts to #1065416
Hello, On Sat 20 Jul 2024 at 01:01pm +02, Matthias Klose wrote: > - I am accepting the offer given in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#108 > to take over the linux-libc-dev package. > I will start working on that at DebCamp and DebConf. This is a significant point of agreement. Bastian, how about we revert your changes for the time being, to give Matthias time to do this work? -- Sean Whitton
Bug#1065416: requesting input on recent posts to #1065416
I am re-adding lea...@debian.org, and now also commun...@debian.org. I
still don't see this as an issue that the Technical Committee should
decide. This is aggressively confrontational behavior of one of the
Debian kernel maintainers, and it should be handled as that.
On 15.05.24 14:15, Sean Whitton wrote:
Hello Matthias,
There have been a number of posts to #1065416 and it hasn't heard from
you in some time. The Technical Committee would like to help, but it is
difficult to see how we could do so without input from your side.
My position didn't change, and I didn't see any efforts in resolving the
uninstallability issue, and the buildability of the gcc-cross packages.
The ownership issue seems tractable. On the one hand, the binary
package names clearly belong to your package, but on the other hand, the
files that are installed seem like they belong to Linux.
I doubt that "belong to Linux" opinion. The files are made available via
the linux-source package, and then used to build new binary packages,
clearly marked by the Built-Using attribute.
I'm also not considering files contained in the binutils-source and
gcc-N-source packages as belonging to the binutils and GCC maintainers.
And I'm certainly not doing any changes that make the non-linux cross
toolchains uninstallable as one of the Debian Kernel maintainers is
doing that here. Just providing these files in a -source package
doesn't make you an owner for these files in packages using these
-source packages.
The same way, it's not ok to force uninstallabilty of the cross
compilers down everybody's throat, without seeking an agreement.
If you could respond to the recent messages, we may be able to get a
grip on some of the problems and make suggestions.
My first priority is to get the gcc cross compilers targeting the
various linux and hurd architectures installable and usable again.
- the cross-toolchain-base and cross-toolchain-base-ports packages
were uploaded twice to address the linux-source and glibc-source
changes.
The build conflicts against the linux-libc-dev-*-cross packages
had to be temporarily dropped for that.
- As the second step, I already requested to drop the provides
linux-libc-dev-*-cross from the new linux-libc-dev package.
If the availability of some architecture-specific files should
be announced, this can be announced in a non-confrontational
way. The -cross suffix is nothing that belongs to the linux
source package. Providing names like
linux-libc-dev- serves the same purpose.
This would make the cross compiler packages installable again.
- If that is not done, I will have to rename the
linux-libc-dev-*-cross packages, needing a pass through
the new queue.
This would make the cross compiler packages installable again,
if the previous item is not acted on.
- I am accepting the offer given in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065416#108
to take over the linux-libc-dev package.
I will start working on that at DebCamp and DebConf.
I am not ok to do changes, which first break stuff, and then having to
repair things later again. That's why I don't want to go the road
started here.
- Bastian's assertion that the current linux-libc-dev package doesn't
break anything in the archive, doesn't say anything. These bits
are just not used by anything in the archive.
- With Helmut's (unrelated) gcc-for-{build,host} changes, we saw a
lot of breakage, even after telling me these were tested. In the
end it took me more than 40 working hours to fix stuff during the
end-of-year break integrating these changes. I am fine spending
time to integrate such changes for cross build ability in a
Debian specific multiarch environment. Both Bastian and Helmut are
not GCC upstream contributors, and as seen in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1069066
people are trying to go the easy way pushing stuff in Debian, that
they don't want to spend the time to integrate upstream.
In the end it's me having to fix issues for the Debian packages. I would
like doing things in a non-breaking way.
As you can see from the commits for the gcc-for-{build,host} changes,
these were done around the same time as this controversial
linux-libc-dev upload. So while having to fix one messy set of patches
from Helmut, Bastian assumes a no-reply on the linux-libc-dev issue as
an OK, that's odd.
Matthias
Bug#1065416: requesting input on recent posts to #1065416
Hello Matthias, There have been a number of posts to #1065416 and it hasn't heard from you in some time. The Technical Committee would like to help, but it is difficult to see how we could do so without input from your side. The ownership issue seems tractable. On the one hand, the binary package names clearly belong to your package, but on the other hand, the files that are installed seem like they belong to Linux. If you could respond to the recent messages, we may be able to get a grip on some of the problems and make suggestions. Thanks. -- Sean Whitton signature.asc Description: PGP signature
