Re: Porter roll call for Debian Stretch
On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote: > On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz > wrote: > [...] > > On the other hand, some packages dropped support for PowerPC32 like Mono > > but this isn't a concern for most users, I would say. > [...] > > However I need to mention that the specific ppc/mono issue is in fact > pretty interesting. The long thread is on debian-powerpc@l.d.o but the > short version is that this issue only happen because we build the > ppc32 mono version on a ppc64 kernel, I know that since I did debug > this issue. Which, if I read the bug correctly, is a yet another case of a bogus build system looking at characteristics of the machine it's compiled on rather than baseline of the arch. And, per your own work, it's +patch +fixed-upstream. > I have not heard from the ppc64el porters, but I suspect ppc64 will > not be a release arch. So you need to take into consideration that for > powerpc to remain a release arch, one need minimal working ppc64 port. > Could we solve the situation of ppc64 for Stretch, could it be moved > to official release arch ? What would you need ppc64 for? Unlike i386, powerpc includes 64-bit kernels so users don't need multiarch: powerpc has: linux-image-4.7.0-1-powerpc - Linux 4.7 for uniprocessor 32-bit PowerPC (signed) linux-image-4.7.0-1-powerpc-smp - Linux 4.7 for multiprocessor 32-bit PowerPC (signed) linux-image-4.7.0-1-powerpc64 - Linux 4.7 for 64-bit PowerPC (signed) i386 has: linux-image-4.7.0-1-686-pae-unsigned - Linux 4.7 for modern PCs linux-image-4.7.0-1-686-unsigned - Linux 4.7 for older PCs linux-image-4.7.0-1-grsec-686-pae - Linux 4.7 for modern PCs, Grsecurity protection linux-image-4.7.0-1-686 - Linux 4.7 for older PCs (signed) linux-image-4.7.0-1-686-pae - Linux 4.7 for modern PCs (signed) Note the joke: "for modern PCs". Unless you do embedded it takes some serious dumpster diving to find a machine not better served by an -amd64 kernel (and thus multiarch). The i386 architecture is not self-contained, powerpc is. Thus, there is no need for ppc64 (userland), as long as powerpc has the toolchain to build 64-bit kernels. And that's a primary target for gcc upstream. -- A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and throw away the fruits (can dump them into a cake, etc), let the drink age at least 3-6 months.
Re: Porter roll call for Debian Stretch
On 09/20/2016 05:46 PM, John Paul Adrian Glaubitz wrote: > On 09/20/2016 11:16 PM, Niels Thykier wrote: >>- powerpc: No porter (RM blocker) > > I'd be happy to pick up powerpc to keep it for Stretch. I'm already > maintaining powerpcspe which is very similar to powerpc. > Thank you Adrian for stepping up. You will have my support in this endeavor for the Stretch release. Milan signature.asc Description: OpenPGP digital signature
Re: Porter roll call for Debian Stretch
Adrian, On Fri, Sep 30, 2016 at 10:34 PM, John Paul Adrian Glaubitz wrote: [...] > On the other hand, some packages dropped support for PowerPC32 like Mono > but this isn't a concern for most users, I would say. [...] Thanks very much for stepping up as porter, you have my vote ! However I need to mention that the specific ppc/mono issue is in fact pretty interesting. The long thread is on debian-powerpc@l.d.o but the short version is that this issue only happen because we build the ppc32 mono version on a ppc64 kernel, I know that since I did debug this issue. I have not heard from the ppc64el porters, but I suspect ppc64 will not be a release arch. So you need to take into consideration that for powerpc to remain a release arch, one need minimal working ppc64 port. Could we solve the situation of ppc64 for Stretch, could it be moved to official release arch ? -M
Re: Porter roll call for Debian Stretch
On 09/30/2016 09:04 PM, Niels Thykier wrote: > As for "porter qualification" > = > > We got burned during the Jessie release, where a person answered the > roll call for sparc and we kept sparc as a release architecture for > Jessie. However, we ended up with a completely broken and unbootable > sparc kernel. To be fair, this happened because the upstream kernel development for SPARC came to an almost complete stop. There was basically only David Miller working on the port which turned out not to be enough. This isn't the case for PowerPC32 where upstream development is still very active because it's part of the PowerPC kernel which is maintained by IBM. PowerPC32 is also still quite popular which is why it still sees quite some testing in the wild. There are still new PowerPC32 designs based on embedded CPUs (FreeScale and the like). As for SPARC, Oracle is actually now heavily investing in Linux SPARC support, so even SPARC is getting back into shape which is why I hope we can add sparc64 as an official port soon. > That was an embarrassment to the Debian stability and quality > reputation that I never - ever - want to repeat. Well, mistakes happen and while I think it's good and important to learn from mistakes, we should not dramatize such issues. We have had worse issues like the OpenSSL entropy bug, for example, and we still managed to cope with the fallout in a very professional manner. > (For avoidance of doubt: I want to ensure that release architectures > "just work(tm)" and I have no desire to blame that volunteer). I don't think there is any concern regarding the powerpc port in this regard. wanna-build shows almost 11800 packages that are up-to-date which is a good indicator that the port is in good shape, both regarding the toolchain and various source packages which need architecture-specific adaptations like LibreOffice or JavaScript packages. On the other hand, some packages dropped support for PowerPC32 like Mono but this isn't a concern for most users, I would say. > If I am to support powerpc as a realease architecture for Stretch, I > need to know that there are *active* porters behind it committed to > keeping it in the working. People who would definitely catch such > issues long before the release. People who file bugs / submit patches etc. I agree and I'm actually doing that all the time. I always run unstable on my machines and constantly check wanna-build for build issues and report them upstream whenever they occur. I have helped dozens of such issues on "sh4" and "sparc64", for example. > If you need inspiration: Have a look at the [automatic testing of > ppc64el images]. Or the [arm64 machines on ci.debian.net] with > comparable results to amd64. This is the sort of thing that inspires > confidence in the ports for me and I think we should have vastly more of. I agree that would be nice to have. However, to be fair, we don't have that type of testing for all release architectures and to my current knowledge, automated testing of installation images is not a criteria for an architecture to maintain release status. My main argument for why we should keep the powerpc port is its popularity. If we look at the numbers from popcon [1], powerpc is still the fourth-most-popular port and I think we would disappoint many users if we were to drop the port for Stretch. Note that while ports like "arm64" or "ppc64el" receive lots of support, especially from companies, they still haven't reached the same popularity as the powerpc port for example. Heck, there are even more users for "hppa" and "sparc64" which both are just unofficial ports architectures. Thanks, Adrian > [1] http://popcon.debian.org/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Porter roll call for Debian Stretch
Niels Thykier: > [...] > > As for "porter qualification" > = > > We got burned during the Jessie release, where a person answered the > roll call for sparc and we kept sparc as a release architecture for > Jessie. However, we ended up with a completely broken and unbootable > sparc kernel. > > That was an embarrassment to the Debian stability and quality > reputation that I never - ever - want to repeat. > > (For avoidance of doubt: I want to ensure that release architectures > "just work(tm)" and I have no desire to blame that volunteer). > > > [...] > I have been reminded of my inaccurate memory. The broken sparc kernel was released in Wheezy (and discovered during Jessie). The roll call for Jessie happened shortly after Wheezy release but before DSA discovered the broken kernel. Nonetheless, the core argument still stands. Thanks, ~Niels
Re: Porter roll call for Debian Stretch
On Fri, 2016-09-30 at 19:04 +, Niels Thykier wrote: > As for "porter qualification" > = > > We got burned during the Jessie release, where a person answered the > roll call for sparc and we kept sparc as a release architecture for > Jessie. However, we ended up with a completely broken and unbootable > sparc kernel. fwiw, you mean wheezy. Regards, Adam
Re: Porter roll call for Debian Stretch
John Paul Adrian Glaubitz: > On 09/30/2016 06:08 PM, Niels Thykier wrote: >> I strongly /suspect/ that "no porters" for powerpc will imply the >> removal of powerpc for Stretch. It may or may not be moved to ports >> (assuming someone is willing to support it there). > > So, I take this as a "no" for the offer from me and Christoph Biedel to take > over the powerpc port for Stretch? > > [...] > > Thanks, > Adrian > My statement above was made based on the assumption stated in the first line of Mathieu's mail, which was "Assume there are no powerpc porters for Stretch". As for "porter qualification" = We got burned during the Jessie release, where a person answered the roll call for sparc and we kept sparc as a release architecture for Jessie. However, we ended up with a completely broken and unbootable sparc kernel. That was an embarrassment to the Debian stability and quality reputation that I never - ever - want to repeat. (For avoidance of doubt: I want to ensure that release architectures "just work(tm)" and I have no desire to blame that volunteer). If I am to support powerpc as a realease architecture for Stretch, I need to know that there are *active* porters behind it committed to keeping it in the working. People who would definitely catch such issues long before the release. People who file bugs / submit patches etc. If you need inspiration: Have a look at the [automatic testing of ppc64el images]. Or the [arm64 machines on ci.debian.net] with comparable results to amd64. This is the sort of thing that inspires confidence in the ports for me and I think we should have vastly more of. Thanks, ~Niels [automatic testing of ppc64el images]: https://lists.debian.org/debian-powerpc/2016/06/msg2.html [arm64 machines on ci.debian.net]: https://ci.debian.net/status/
Re: Porter roll call for Debian Stretch
On Fri, Sep 30, 2016 at 10:03:47AM +0200, Mathieu Malaterre wrote: > [Let's assume that we can't find a powerpc porter in time for Stretch.] Two potential porters stepped up, who might or might not be accepted. > 1. Will `powperpc` automatically be downgraded to simple port ? Or is > this also not automated and the port may simply be removed (eg. sparc) > ? Removal from the main archive isn't automatic, and assuming no serious kernel or toolchain breakage, I guess there's no reason for such removal to be hasty. On the other hand, place in -ports (aka second-class architectures) isn't automatic either, and relies on someone doing the work. > 2. Apart from loosing the automatic debian-installer stuff, what else > are we going to loose in that scenario ? Security support and stable release. -- A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and throw away the fruits (can dump them into a cake, etc), let the drink age at least 3-6 months.
Re: Enabling PIE by default for Stretch
[CCing porters, please also leave feedback in #835148 for non-release architectures] On 29.09.2016 21:39, Niels Thykier wrote: > Hi, > > As brought up on the meeting last night, I think we should try to go for > PIE by default in Stretch on all release architectures! > * It is a substantial hardening feature > * Upstream has vastly reduced the performance penalty for x86 > * The majority of all porters believe their release architecture is >ready for it. > * We have sufficient time to solve any issues or revert if it turns out >to be too problematic. > > As agreed on during the [meeting], if there are no major concerns to > this proposal in general within a week, I shall file a bug against GCC > requesting PIE by default on all release architectures (with backing > porters). please re-use #835148 > If there are only major concerns with individual architectures, I will > simply exclude said architectures in the "PIE by default" request. > > * Deadline for major concerns: Fri, 7th of October 2016. > > Fall-out > > > There will be some possible fall-out from this change: > > * There will be some FTBFS caused by some packages needing a rebuild >before reverse dependencies can enable PIE. These are a subset of >the bugs filed in the [pie+bindnow] build tests. > > * Some packages may not be ready for PIE. These will have to disable >it per package. A notable case being ghc (#712228), where we can >reuse the patch from Ubuntu to work around the issue. > > * A possible issue from Matthias was that no one has done a large scale >"PIE by default" on "arm* mips*". > > * There was concern about whether the 32bit arm architectures would be >notably affected by the PIE slow down (like x86 used to be). >It is not measured, but two arm porters did mention a possible >slowdown > > * It was questioned whether it made sense to invest time and effort in >enabling PIE for architectures which would not be included in Buster >(armel?). Personally, I do not see an issue, if the porters are >ready to put in the effort required. > > Thanks, > ~Niels > > [meeting]: > http://meetbot.debian.net/debian-release/2016/debian-release.2016-09-28-19.00.html > > [pie+bindnow]: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=pie-bindnow-20160906&users=balint%40balintreczey.hu;dist=unstable > > > >
Re: Porter roll call for Debian Stretch
On 09/30/2016 06:08 PM, Niels Thykier wrote: > I strongly /suspect/ that "no porters" for powerpc will imply the > removal of powerpc for Stretch. It may or may not be moved to ports > (assuming someone is willing to support it there). So, I take this as a "no" for the offer from me and Christoph Biedel to take over the powerpc port for Stretch? I have quite some experience with working on ports and unlike what Matthias claimed, I'm not just maintaining a few buildds but also getting architecture-specific bugs fixed and so on. Is there any specific qualification I am missing? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Porter roll call for Debian Stretch
Mathieu Malaterre: > Hi all, > > [...] > > [Let's assume that we can't find a powerpc porter in time for Stretch.] > > 1. Will `powperpc` automatically be downgraded to simple port ? Or is > this also not automated and the port may simply be removed (eg. sparc) > ? > 2. Apart from loosing the automatic debian-installer stuff, what else > are we going to loose in that scenario ? > > Thanks much for pointers ! > > -M > I strongly /suspect/ that "no porters" for powerpc will imply the removal of powerpc for Stretch. It may or may not be moved to ports (assuming someone is willing to support it there). Not sure I can answer your 2nd question though. ~Niels
Re: Porter roll call for Debian Stretch
You have a porter for PowerPC. See email from Adrian. ;-) -- Christian Sent from my iPhone > On 30 Sep 2016, at 10:03, Mathieu Malaterre wrote: > > Hi all, > >> On Fri, Sep 23, 2016 at 3:54 PM, Matthias Klose wrote: >>> On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote: On 09/20/2016 11:16 PM, Niels Thykier wrote: - powerpc: No porter (RM blocker) >>> >>> I'd be happy to pick up powerpc to keep it for Stretch. I'm already >>> maintaining powerpcspe which is very similar to powerpc. >> >> No, you are not maintaining powerpcspe as a release architecture, and that's >> something different than building packages for some of the ports >> architectures. >> If you can get powerpcspe accepted as a release architecture, then maybe you >> gain some credibility to maintain another release architecture ;) > > [Let's assume that we can't find a powerpc porter in time for Stretch.] > > 1. Will `powperpc` automatically be downgraded to simple port ? Or is > this also not automated and the port may simply be removed (eg. sparc) > ? > 2. Apart from loosing the automatic debian-installer stuff, what else > are we going to loose in that scenario ? > > Thanks much for pointers ! > > -M >
Re: Porter roll call for Debian Stretch
Hi all, On Fri, Sep 23, 2016 at 3:54 PM, Matthias Klose wrote: > On 20.09.2016 23:46, John Paul Adrian Glaubitz wrote: >> On 09/20/2016 11:16 PM, Niels Thykier wrote: >>>- powerpc: No porter (RM blocker) >> >> I'd be happy to pick up powerpc to keep it for Stretch. I'm already >> maintaining powerpcspe which is very similar to powerpc. > > No, you are not maintaining powerpcspe as a release architecture, and that's > something different than building packages for some of the ports > architectures. > If you can get powerpcspe accepted as a release architecture, then maybe you > gain some credibility to maintain another release architecture ;) [Let's assume that we can't find a powerpc porter in time for Stretch.] 1. Will `powperpc` automatically be downgraded to simple port ? Or is this also not automated and the port may simply be removed (eg. sparc) ? 2. Apart from loosing the automatic debian-installer stuff, what else are we going to loose in that scenario ? Thanks much for pointers ! -M