[Kernel-packages] [Bug 750585] Re: [FFe] support for making linux-libc-dev coinstallable under multiarch
IDK how this got added to bash-completion. It's already an arch:all binary package, since it's just shell code. Ah, I see. False positive from Steve's text search that found: completions/strace:done 2/dev/null /usr/include/asm/unistd.h ./completions/strace: unistd=/usr/include/asm/unistd_32.h ./completions/strace: unistd=/usr/include/asm/unistd_64.h All 3 of those files exist on trusty x86_64 with i386 libs installed, so strace completion should be fine. Closing. ** Changed in: bash-completion (Ubuntu) Status: Triaged = Invalid -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-ti-omap4 in Ubuntu. https://bugs.launchpad.net/bugs/750585 Title: [FFe] support for making linux-libc-dev coinstallable under multiarch Status in armel-cross-toolchain-base package in Ubuntu: Fix Released Status in bash-completion package in Ubuntu: Invalid Status in eglibc package in Ubuntu: Fix Released Status in gcc-defaults package in Ubuntu: Fix Released Status in klibc package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux-ti-omap4 package in Ubuntu: Invalid Status in newlib package in Ubuntu: Fix Released Status in armel-cross-toolchain-base source package in Natty: Fix Released Status in bash-completion source package in Natty: Won't Fix Status in eglibc source package in Natty: Fix Released Status in gcc-defaults source package in Natty: Fix Released Status in klibc source package in Natty: Fix Released Status in linux source package in Natty: Fix Released Status in linux-ti-omap4 source package in Natty: Fix Released Status in newlib source package in Natty: Fix Released Status in armel-cross-toolchain-base source package in Oneiric: Invalid Status in bash-completion source package in Oneiric: Won't Fix Status in eglibc source package in Oneiric: Fix Released Status in gcc-defaults source package in Oneiric: Fix Released Status in klibc source package in Oneiric: Fix Released Status in linux source package in Oneiric: Fix Released Status in linux-ti-omap4 source package in Oneiric: Fix Released Status in newlib source package in Oneiric: Fix Released Bug description: FFe justification: now that multiarch support for runtime libraries in the base system is available in the archive, the next step in this process is multiarch coinstallability of -dev packages. Although most of the remaining work on multiarch -dev can and will take place in ppa for natty given where we are in the release cycle, any -dev package tree has at its root linux-libc-dev which is built from the 'linux' source package - the package which is updated more frequently than any other by SRU. Rather than trying to keep up with SRUs, or artificially inflating the version of a linux-libc-dev-only package build in ppa, it would be welcome if a multiarch-ready linux-libc-dev could be included in the archive for natty. Risks: anything that looks directly in /usr/include/asm for headers will have problems with this change; anything that uses the system include path from the compiler will not. My best efforts at examining the archive for this issue (see below for details) have turned up only four packages in main and universe that are affected: three C library implementations, and bash-completion. Updating these packages in concert is manageable (patch for eglibc is ready, patches for the others are in preparation), but there's always some risk that the text search on package sources has missed something, and there wouldn't be room for another full archive rebuild before release to catch other breakage. Details: In order to have coinstallable multiarch -dev packages of any sort, linux-libc-dev first needs to be coinstallable since libc-dev depends on it. This seems to be straightforward to achieve; only the asm directory needs to be moved to the multiarch directory path, all the other header files appear to be (sensibly) architecture-neutral and can be shared between architectures. The compiler will find /usr/include/triplet/asm for the corresponding architecture with no problems; I've done a number of test builds that work just fine this way. The only trouble is with software that walks the filesystem looking for asm/foo.h includes instead of trusting the compiler to resolve them. It's unlikely that software should need to do this since the asm headers should as a rule not be directly included from userspace anyway, but the chances are not zero. I didn't expect nearly as many packages to break as did by the move to /usr/lib/triplet, either, so it seems my faith in the sanity of upstream build systems is generally misplaced. And I don't think we have time to discover any resulting issues with another archive
[Kernel-packages] [Bug 750585] Re: [FFe] support for making linux-libc-dev coinstallable under multiarch
just saw Steve's earlier comment, apparently the logic to pick the right unistd_32.h or unistd_64.h was added after that, so this is Fix Released, not Invalid. There's now asm/unistd_x32.h as well. AFAICT from poking around in the kernel source, uname -m should return x86_64 when called from a x86_x32 uname binary. I don't see anything mucking with utsname()-machine, outside of what I think is just the ia32 handling, not used for x86_x32 userspace (since they still run in long mode, with 64 bit registers. They just choose not to use addresses that don't fit in 32bits.) So x86_x32 userspace won't ever get their own unistd.h processed, but it's minimally different from unistd_64.h, and has to be that way for the kernel support to be as minimally invasive as it is. The extra names that unistd_x32.h has that unistd_64.h doesn't is probably not relevant unless you're trying to debug the glibc wrappers around the calls that need help, I hope. You *could* use cpp to get the right unistd.h, but you couldn't just cpp /usr/include/unistd.h, because that would substitute the __NR_callname macros that the script is looking for. ** Changed in: bash-completion (Ubuntu) Status: Invalid = Fix Released -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-ti-omap4 in Ubuntu. https://bugs.launchpad.net/bugs/750585 Title: [FFe] support for making linux-libc-dev coinstallable under multiarch Status in armel-cross-toolchain-base package in Ubuntu: Fix Released Status in bash-completion package in Ubuntu: Fix Released Status in eglibc package in Ubuntu: Fix Released Status in gcc-defaults package in Ubuntu: Fix Released Status in klibc package in Ubuntu: Fix Released Status in linux package in Ubuntu: Fix Released Status in linux-ti-omap4 package in Ubuntu: Invalid Status in newlib package in Ubuntu: Fix Released Status in armel-cross-toolchain-base source package in Natty: Fix Released Status in bash-completion source package in Natty: Won't Fix Status in eglibc source package in Natty: Fix Released Status in gcc-defaults source package in Natty: Fix Released Status in klibc source package in Natty: Fix Released Status in linux source package in Natty: Fix Released Status in linux-ti-omap4 source package in Natty: Fix Released Status in newlib source package in Natty: Fix Released Status in armel-cross-toolchain-base source package in Oneiric: Invalid Status in bash-completion source package in Oneiric: Won't Fix Status in eglibc source package in Oneiric: Fix Released Status in gcc-defaults source package in Oneiric: Fix Released Status in klibc source package in Oneiric: Fix Released Status in linux source package in Oneiric: Fix Released Status in linux-ti-omap4 source package in Oneiric: Fix Released Status in newlib source package in Oneiric: Fix Released Bug description: FFe justification: now that multiarch support for runtime libraries in the base system is available in the archive, the next step in this process is multiarch coinstallability of -dev packages. Although most of the remaining work on multiarch -dev can and will take place in ppa for natty given where we are in the release cycle, any -dev package tree has at its root linux-libc-dev which is built from the 'linux' source package - the package which is updated more frequently than any other by SRU. Rather than trying to keep up with SRUs, or artificially inflating the version of a linux-libc-dev-only package build in ppa, it would be welcome if a multiarch-ready linux-libc-dev could be included in the archive for natty. Risks: anything that looks directly in /usr/include/asm for headers will have problems with this change; anything that uses the system include path from the compiler will not. My best efforts at examining the archive for this issue (see below for details) have turned up only four packages in main and universe that are affected: three C library implementations, and bash-completion. Updating these packages in concert is manageable (patch for eglibc is ready, patches for the others are in preparation), but there's always some risk that the text search on package sources has missed something, and there wouldn't be room for another full archive rebuild before release to catch other breakage. Details: In order to have coinstallable multiarch -dev packages of any sort, linux-libc-dev first needs to be coinstallable since libc-dev depends on it. This seems to be straightforward to achieve; only the asm directory needs to be moved to the multiarch directory path, all the other header files appear to be (sensibly) architecture-neutral and can be shared between architectures. The compiler will find /usr/include/triplet/asm for the corresponding architecture with no problems; I've done a number of test builds that work just fine this way. The only trouble is
[Kernel-packages] [Bug 750585] Re: [FFe] support for making linux-libc-dev coinstallable under multiarch
There is one task here in this ticket still marked as open. Anything left to be done? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-ti-omap4 in Ubuntu. https://bugs.launchpad.net/bugs/750585 Title: [FFe] support for making linux-libc-dev coinstallable under multiarch Status in “armel-cross-toolchain-base” package in Ubuntu: Fix Released Status in “bash-completion” package in Ubuntu: Triaged Status in “eglibc” package in Ubuntu: Fix Released Status in “gcc-defaults” package in Ubuntu: Fix Released Status in “klibc” package in Ubuntu: Fix Released Status in “linux” package in Ubuntu: Fix Released Status in “linux-ti-omap4” package in Ubuntu: Invalid Status in “newlib” package in Ubuntu: Fix Released Status in “armel-cross-toolchain-base” source package in Natty: Fix Released Status in “bash-completion” source package in Natty: Won't Fix Status in “eglibc” source package in Natty: Fix Released Status in “gcc-defaults” source package in Natty: Fix Released Status in “klibc” source package in Natty: Fix Released Status in “linux” source package in Natty: Fix Released Status in “linux-ti-omap4” source package in Natty: Fix Released Status in “newlib” source package in Natty: Fix Released Status in “armel-cross-toolchain-base” source package in Oneiric: Invalid Status in “bash-completion” source package in Oneiric: Won't Fix Status in “eglibc” source package in Oneiric: Fix Released Status in “gcc-defaults” source package in Oneiric: Fix Released Status in “klibc” source package in Oneiric: Fix Released Status in “linux” source package in Oneiric: Fix Released Status in “linux-ti-omap4” source package in Oneiric: Fix Released Status in “newlib” source package in Oneiric: Fix Released Bug description: FFe justification: now that multiarch support for runtime libraries in the base system is available in the archive, the next step in this process is multiarch coinstallability of -dev packages. Although most of the remaining work on multiarch -dev can and will take place in ppa for natty given where we are in the release cycle, any -dev package tree has at its root linux-libc-dev which is built from the 'linux' source package - the package which is updated more frequently than any other by SRU. Rather than trying to keep up with SRUs, or artificially inflating the version of a linux-libc-dev-only package build in ppa, it would be welcome if a multiarch-ready linux-libc-dev could be included in the archive for natty. Risks: anything that looks directly in /usr/include/asm for headers will have problems with this change; anything that uses the system include path from the compiler will not. My best efforts at examining the archive for this issue (see below for details) have turned up only four packages in main and universe that are affected: three C library implementations, and bash-completion. Updating these packages in concert is manageable (patch for eglibc is ready, patches for the others are in preparation), but there's always some risk that the text search on package sources has missed something, and there wouldn't be room for another full archive rebuild before release to catch other breakage. Details: In order to have coinstallable multiarch -dev packages of any sort, linux-libc-dev first needs to be coinstallable since libc-dev depends on it. This seems to be straightforward to achieve; only the asm directory needs to be moved to the multiarch directory path, all the other header files appear to be (sensibly) architecture-neutral and can be shared between architectures. The compiler will find /usr/include/triplet/asm for the corresponding architecture with no problems; I've done a number of test builds that work just fine this way. The only trouble is with software that walks the filesystem looking for asm/foo.h includes instead of trusting the compiler to resolve them. It's unlikely that software should need to do this since the asm headers should as a rule not be directly included from userspace anyway, but the chances are not zero. I didn't expect nearly as many packages to break as did by the move to /usr/lib/triplet, either, so it seems my faith in the sanity of upstream build systems is generally misplaced. And I don't think we have time to discover any resulting issues with another archive test rebuild and fix the resulting packages before the natty release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/armel-cross-toolchain-base/+bug/750585/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
[Kernel-packages] [Bug 750585] Re: [FFe] support for making linux-libc-dev coinstallable under multiarch
** Changed in: bash-completion (Ubuntu Natty) Status: Triaged = Won't Fix ** Changed in: bash-completion (Ubuntu Oneiric) Status: Triaged = Won't Fix -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-ti-omap4 in Ubuntu. https://bugs.launchpad.net/bugs/750585 Title: [FFe] support for making linux-libc-dev coinstallable under multiarch Status in “armel-cross-toolchain-base” package in Ubuntu: Fix Released Status in “bash-completion” package in Ubuntu: Triaged Status in “eglibc” package in Ubuntu: Fix Released Status in “gcc-defaults” package in Ubuntu: Fix Released Status in “klibc” package in Ubuntu: Fix Released Status in “linux” package in Ubuntu: Fix Released Status in “linux-ti-omap4” package in Ubuntu: Invalid Status in “newlib” package in Ubuntu: Fix Released Status in “armel-cross-toolchain-base” source package in Natty: Fix Released Status in “bash-completion” source package in Natty: Won't Fix Status in “eglibc” source package in Natty: Fix Released Status in “gcc-defaults” source package in Natty: Fix Released Status in “klibc” source package in Natty: Fix Released Status in “linux” source package in Natty: Fix Released Status in “linux-ti-omap4” source package in Natty: Fix Released Status in “newlib” source package in Natty: Fix Released Status in “armel-cross-toolchain-base” source package in Oneiric: Invalid Status in “bash-completion” source package in Oneiric: Won't Fix Status in “eglibc” source package in Oneiric: Fix Released Status in “gcc-defaults” source package in Oneiric: Fix Released Status in “klibc” source package in Oneiric: Fix Released Status in “linux” source package in Oneiric: Fix Released Status in “linux-ti-omap4” source package in Oneiric: Fix Released Status in “newlib” source package in Oneiric: Fix Released Bug description: FFe justification: now that multiarch support for runtime libraries in the base system is available in the archive, the next step in this process is multiarch coinstallability of -dev packages. Although most of the remaining work on multiarch -dev can and will take place in ppa for natty given where we are in the release cycle, any -dev package tree has at its root linux-libc-dev which is built from the 'linux' source package - the package which is updated more frequently than any other by SRU. Rather than trying to keep up with SRUs, or artificially inflating the version of a linux-libc-dev-only package build in ppa, it would be welcome if a multiarch-ready linux-libc-dev could be included in the archive for natty. Risks: anything that looks directly in /usr/include/asm for headers will have problems with this change; anything that uses the system include path from the compiler will not. My best efforts at examining the archive for this issue (see below for details) have turned up only four packages in main and universe that are affected: three C library implementations, and bash-completion. Updating these packages in concert is manageable (patch for eglibc is ready, patches for the others are in preparation), but there's always some risk that the text search on package sources has missed something, and there wouldn't be room for another full archive rebuild before release to catch other breakage. Details: In order to have coinstallable multiarch -dev packages of any sort, linux-libc-dev first needs to be coinstallable since libc-dev depends on it. This seems to be straightforward to achieve; only the asm directory needs to be moved to the multiarch directory path, all the other header files appear to be (sensibly) architecture-neutral and can be shared between architectures. The compiler will find /usr/include/triplet/asm for the corresponding architecture with no problems; I've done a number of test builds that work just fine this way. The only trouble is with software that walks the filesystem looking for asm/foo.h includes instead of trusting the compiler to resolve them. It's unlikely that software should need to do this since the asm headers should as a rule not be directly included from userspace anyway, but the chances are not zero. I didn't expect nearly as many packages to break as did by the move to /usr/lib/triplet, either, so it seems my faith in the sanity of upstream build systems is generally misplaced. And I don't think we have time to discover any resulting issues with another archive test rebuild and fix the resulting packages before the natty release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/armel-cross-toolchain-base/+bug/750585/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
