Re: Minutes from the "32bit architectures in Debian"-bof
* Helmut Grohne (hel...@subdivi.de) [150831 16:49]: > On Thu, Aug 20, 2015 at 03:04:17PM +0200, Andreas Barth wrote: > > minutes from the "32bit architectures in Debian" bof right now. > > It is my understanding that it was also agreed that mips and mipsel > would be dropped as release architectures after stretch. Yet it seems > this was missing from the minutes. Adding it here and now. I can't remember that. I however can remember that we agreed that decisions about individual arches out-of-scope for that bof because we focuse on things that all 32bit arches have in common. (We spoke about that the 32bit arches might be dropped at some point in future, especially if there is no additional use, e.g. all hardware sold for some time is able to run the 64bit aquivalent, but that's something else than "agreed after stretch"). Andi
Re: Minutes from the "32bit architectures in Debian"-bof
On Thu, Aug 20, 2015 at 03:04:17PM +0200, Andreas Barth wrote: > minutes from the "32bit architectures in Debian" bof right now. It is my understanding that it was also agreed that mips and mipsel would be dropped as release architectures after stretch. Yet it seems this was missing from the minutes. Adding it here and now. Helmut
Re: Minutes from the 32bit architectures in Debian-bof
Ben Hutchings wrote: On Wed, 2015-08-26 at 12:08 -0700, Josh Triplett wrote: Andreas Barth wrote: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? Discussion that we need to get rid of it one day should be started. Brand-new 32-bit-only x86 hardware is currently being sold, and will continue to be in the future. In particular, the Quark embedded platform is a 32-bit x86, roughly i586-class, with no 64-bit support, and no MMX or SSE, though it has a few modern instruction set extensions (notably for security). So, i386 needs to stick around for the foreseeable future. [...] The last I heard, all Quark chips have serious bugs that prevent Debian i386 from running on them. News to me; I've successfully booted Debian on the Quark I have. Do you have any additional information about this? As far as I know, the primary issue there is that Quark doesn't have some MSRs that i586/i686 systems have, so code that assumes those on certain classes and doesn't check for them will break. But as far as I know those issues have been patched upstream. - Josh Triplett
Re: Minutes from the 32bit architectures in Debian-bof
On Thu, 2015-08-27 at 10:45 -0700, Josh Triplett wrote: Ben Hutchings wrote: On Wed, 2015-08-26 at 12:08 -0700, Josh Triplett wrote: Andreas Barth wrote: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? Discussion that we need to get rid of it one day should be started. Brand-new 32-bit-only x86 hardware is currently being sold, and will continue to be in the future. In particular, the Quark embedded platform is a 32-bit x86, roughly i586-class, with no 64-bit support, and no MMX or SSE, though it has a few modern instruction set extensions (notably for security). So, i386 needs to stick around for the foreseeable future. [...] The last I heard, all Quark chips have serious bugs that prevent Debian i386 from running on them. News to me; I've successfully booted Debian on the Quark I have. Do you have any additional information about this? As far as I know, the primary issue there is that Quark doesn't have some MSRs that i586/i686 systems have, so code that assumes those on certain classes and doesn't check for them will break. But as far as I know those issues have been patched upstream. https://en.wikipedia.org/wiki/Intel_Quark#Segfault_bug Lots more errata here with no workaround: http://download.intel.com/support/processors/quark/sb/329677_quark_spec update_004.pdf This goes way beyond the usual obscure flaws that can be fixed in microcode or BIOS updates, or workarounds in the kernel. The fact that these errata aren't even being corrected in a later stepping is a good indication of just how few fucks Intel gives about this product line. Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part
Re: Minutes from the 32bit architectures in Debian-bof
Andreas Barth wrote: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? Discussion that we need to get rid of it one day should be started. Brand-new 32-bit-only x86 hardware is currently being sold, and will continue to be in the future. In particular, the Quark embedded platform is a 32-bit x86, roughly i586-class, with no 64-bit support, and no MMX or SSE, though it has a few modern instruction set extensions (notably for security). So, i386 needs to stick around for the foreseeable future. That said, I see no particular issue with moving all the i386 buildd systems to cross-compile from x86-64, to give the linker more address space to work with. LTO will become increasingly important, since new 32-bit systems will want small, optimized binaries, and building a large project with LTO requires a huge amount of memory. - Josh Triplett
Re: Minutes from the 32bit architectures in Debian-bof
On Tue, Aug 25, 2015 at 3:08 AM, Russ Allbery wrote: Can we fully support cross-grading to amd64 before we do that? My remaining i386 systems, and I'm sure I'm not the only one, are systems that I've been continuously dist-upgrading for some time precisely because I don't want to rebuild a system from scratch. If cross-grading were supported, I'd just do that and switch to amd64. I guess folks interested in cross-grading should translate [1] into a patch for [2], convince Holger to apply it and convert any errors into bug reports. 1. https://wiki.debian.org/CrossGrading 2. http://jenkins.debian.net/ -- bye, pabs https://wiki.debian.org/PaulWise
Re: Minutes from the 32bit architectures in Debian-bof
On Wed, 2015-08-26 at 13:51 +0500, Andrey Rahmatullin wrote: On Wed, Aug 26, 2015 at 09:38:04AM +0200, Andreas Barth wrote: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? FWIW, for x32, the security team would prefer if support in the Debian amd64 kernel would remain guarded by a boot-time option. You mean that on an kernel from an amd64-installation, 32bit binaries could only be used with an appropriate boot option? This however isn't any issue with the i386-architecture, but only on using this arch in an chroot in an amd64-installation. x32 is not just i386 binaries (though I'm curious why this should be disabled by default). Explained in https://bugs.debian.org/708070 Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Re: Minutes from the 32bit architectures in Debian-bof
* Andreas Barth: * Florian Weimer (f...@deneb.enyo.de) [150823 17:02]: * Andreas Barth: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? FWIW, for x32, the security team would prefer if support in the Debian amd64 kernel would remain guarded by a boot-time option. You mean that on an kernel from an amd64-installation, 32bit binaries could only be used with an appropriate boot option? Yes, x32 binaries. This subarchitecture is different from i386.
Re: Minutes from the 32bit architectures in Debian-bof
On Thu, Aug 27, 2015 at 12:30:42AM +0200, Julian Taylor wrote: On 26.08.2015 21:08, Josh Triplett wrote: Andreas Barth wrote: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? Discussion that we need to get rid of it one day should be started. Brand-new 32-bit-only x86 hardware is currently being sold, and will continue to be in the future. In particular, the Quark embedded platform is a 32-bit x86, roughly i586-class, with no 64-bit support, and no MMX or SSE, though it has a few modern instruction set extensions (notably for security). So, i386 needs to stick around for the foreseeable future. That said, I see no particular issue with moving all the i386 buildd systems to cross-compile from x86-64, to give the linker more address space to work with. LTO will become increasingly important, since new 32-bit systems will want small, optimized binaries, and building a large project with LTO requires a huge amount of memory. - Josh Triplett Does this cpu then have a 80 bit x87 fpu? Yes, for architectural compatibility and the expectation of working floating-point support. That thing is usually the most time consuming part in supporting i386 for numerical and scientific applications due to its compiler optimization dependant rounding behaviour. Its probably a better approach to just not build these type of packages on i386 at all. Nobody will seriously use them anyway and upstreams are not likely to care about bug reports either. While it's unlikely that anyone will want to run high-performance HPC-focused numeric applications on such platforms, some forms of numeric algorithms are critical on embedded platforms, such as positioning and sensor processing. I don't think it makes sense to stop building numeric algorithms for i386. Ideally, any alorithm that has particular dependencies on numeric behavior (such as rounding) should make the appropriate library calls (such as fesetround) to set the mode it wants. It might, on the other hand, make sense to carefully review the default compiler flags for the platform to ensure a safe default (that programs can then opt out of for performance if they know they can do so safely). I had the impression that gcc for i386 did that already (with options like -ffast-math or -Ofast changing that default). - Josh Triplett
Re: Minutes from the 32bit architectures in Debian-bof
On Wed, 2015-08-26 at 12:08 -0700, Josh Triplett wrote: Andreas Barth wrote: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? Discussion that we need to get rid of it one day should be started. Brand-new 32-bit-only x86 hardware is currently being sold, and will continue to be in the future. In particular, the Quark embedded platform is a 32-bit x86, roughly i586-class, with no 64-bit support, and no MMX or SSE, though it has a few modern instruction set extensions (notably for security). So, i386 needs to stick around for the foreseeable future. [...] The last I heard, all Quark chips have serious bugs that prevent Debian i386 from running on them. Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Re: Minutes from the 32bit architectures in Debian-bof
On 26.08.2015 21:08, Josh Triplett wrote: Andreas Barth wrote: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? Discussion that we need to get rid of it one day should be started. Brand-new 32-bit-only x86 hardware is currently being sold, and will continue to be in the future. In particular, the Quark embedded platform is a 32-bit x86, roughly i586-class, with no 64-bit support, and no MMX or SSE, though it has a few modern instruction set extensions (notably for security). So, i386 needs to stick around for the foreseeable future. That said, I see no particular issue with moving all the i386 buildd systems to cross-compile from x86-64, to give the linker more address space to work with. LTO will become increasingly important, since new 32-bit systems will want small, optimized binaries, and building a large project with LTO requires a huge amount of memory. - Josh Triplett Does this cpu then have a 80 bit x87 fpu? That thing is usually the most time consuming part in supporting i386 for numerical and scientific applications due to its compiler optimization dependant rounding behaviour. Its probably a better approach to just not build these type of packages on i386 at all. Nobody will seriously use them anyway and upstreams are not likely to care about bug reports either. 32 bit + sse fpu (x32) on the other hand is useful as it can help find long/int issues in the code that can cause problems on other 64 bit platforms with other conventions on integer size (like win64).
Re: Minutes from the 32bit architectures in Debian-bof
On Wed, 2015-08-26 at 09:38 +0200, Andreas Barth wrote: * Florian Weimer (f...@deneb.enyo.de) [150823 17:02]: * Andreas Barth: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? FWIW, for x32, the security team would prefer if support in the Debian amd64 kernel would remain guarded by a boot-time option. You mean that on an kernel from an amd64-installation, 32bit binaries could only be used with an appropriate boot option? This however isn't any issue with the i386-architecture, but only on using this arch in an chroot in an amd64-installation. Perhaps we could standardise a directory of config files containing kernel parameters that boot loaders should append by default? There are plenty of packages that this would be useful for. For x32 the installer (or maybe a package such as base-files) could add the 'syscall.x32=y'. Ben. -- Ben Hutchings Always try to do things in chronological order; it's less confusing that way. signature.asc Description: This is a digitally signed message part
Re: Minutes from the 32bit architectures in Debian-bof
* Florian Weimer (f...@deneb.enyo.de) [150823 17:02]: * Andreas Barth: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? FWIW, for x32, the security team would prefer if support in the Debian amd64 kernel would remain guarded by a boot-time option. You mean that on an kernel from an amd64-installation, 32bit binaries could only be used with an appropriate boot option? This however isn't any issue with the i386-architecture, but only on using this arch in an chroot in an amd64-installation. Andi
Re: Minutes from the 32bit architectures in Debian-bof
* Russ Allbery (r...@debian.org) [150825 03:09]: Andreas Barth a...@ayous.org writes: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? Discussion that we need to get rid of it one day should be started. Can we fully support cross-grading to amd64 before we do that? My remaining i386 systems, and I'm sure I'm not the only one, are systems that I've been continuously dist-upgrading for some time precisely because I don't want to rebuild a system from scratch. Sounds like a good idea. I don't expect to get rid of i386 for the next few cycles but it will need to happen one day. Andi
Re: Minutes from the 32bit architectures in Debian-bof
On Wed, Aug 26, 2015 at 09:38:04AM +0200, Andreas Barth wrote: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? FWIW, for x32, the security team would prefer if support in the Debian amd64 kernel would remain guarded by a boot-time option. You mean that on an kernel from an amd64-installation, 32bit binaries could only be used with an appropriate boot option? This however isn't any issue with the i386-architecture, but only on using this arch in an chroot in an amd64-installation. x32 is not just i386 binaries (though I'm curious why this should be disabled by default). -- WBR, wRAR signature.asc Description: Digital signature
Re: Minutes from the 32bit architectures in Debian-bof
On Aug 25, Russ Allbery r...@debian.org wrote: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? Discussion that we need to get rid of it one day should be started. Can we fully support cross-grading to amd64 before we do that? My remaining i386 systems, and I'm sure I'm not the only one, are systems that I've been continuously dist-upgrading for some time precisely because I don't want to rebuild a system from scratch. +1 Probably not much work is needed, I remember cross-grading from armel to armhf more than one year ago with some manual hacking but no major troubles. -- ciao, Marco pgpkUmFEyWVyj.pgp Description: PGP signature
Re: Minutes from the 32bit architectures in Debian-bof
Andreas Barth aba at ayous.org writes: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? Discussion that we need to get rid of it one day should be started. Eh, is this some sort of conspiracy to make Debian even more obsolete? I wish to continue use it on an i386 system (in this case, with the 686-pae kernel, though other people I know use the 486 kernel), please. Thanks, //mirabilos (current hat: user)
Re: Minutes from the 32bit architectures in Debian-bof
Andreas Barth a...@ayous.org writes: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? Discussion that we need to get rid of it one day should be started. Can we fully support cross-grading to amd64 before we do that? My remaining i386 systems, and I'm sure I'm not the only one, are systems that I've been continuously dist-upgrading for some time precisely because I don't want to rebuild a system from scratch. If cross-grading were supported, I'd just do that and switch to amd64. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/
Re: Minutes from the 32bit architectures in Debian-bof
* Andreas Barth: Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? FWIW, for x32, the security team would prefer if support in the Debian amd64 kernel would remain guarded by a boot-time option.
Minutes from the 32bit architectures in Debian-bof
Hi together, minutes from the 32bit architectures in Debian bof right now. Andi 32bit architectures in Debian - 32bit architectures are not going away for the forseeable - Compiling/Linking is the memory-using issue - We need a way to compile/link with more memory Proposal A: - Use cross-compilers in the usual buildd chroot (e.g. an arm64 gcc building native armhf packages in an armhf chroots) - Cross-compiling isn't tested enough for all compilers, e.g. currently not for ghc, clang - The cross-compiler should be used on all packages (by being installed by default in the chroot) - Only the compilers actively used/approved for crosscompiling are being allowed to be installed in the chroot - Advantages: Testsuites etc can still be used as now - Nothing to be changed for packages using dh - We need to work out if gcc still works correctly with it (e.g. bootstraping) - If necessary we could have minimal architectures with only the compilers as master arches Proposal B: - Partial architectures to avoid large packages - Nobody yet done the work Proposal C: - just wait until the architecture dies Mixed Proposal: - Do Proposal A for the compilers it works - For other compilers if it's too much effort to make Proposal A work we use Proposal B for those packages depending on those compilers - Recommendation: Mixed Proposal Specific issues: - for i386, there is still sold new hardware with 32bit-only. Are there open issues for i386 (apart from the 32bit-generic ones)? Discussion that we need to get rid of it one day should be started. - for powerpc, there is still 32bit-only hardware in use. - for excluding architectures on packages it would be nice to allow to blacklist architectures (instead of just listing all), plus linux64- and linux32-keywords (- aba will do the bug report) - discussion about generic topics plus i386 will happen on -devel, for other arches on the relevant porters list
