Re: Arch qualification for buster: call for DSA, Security, toolchain concerns
[Oy vey, crosspost list from hell -- not sure how to trim...] On Tue, Dec 11, 2018 at 09:46:21PM +0100, Gregor Riepl wrote: > I do think this just reinforces the point that second-class architectures > should have better, more robust support from the Debian project. > For example, arch-specific packages most decidedly have a place in Debian > The build and package delivery infrastructure should offer the same features > for both first and second class archs, including installer image building for > all "tiers" (stable, testing, unstable). It seems to me that the important bit is the testing suite. As a (now lapsed) x32 porter, I tried to implement that on my own (goal being an unofficial, weakly security supported[1] Jessie for x32). And tracking testing on my own proved to be too hard. What directly defeated me were binNMUs: with every arch having its own NMU counter and hidden triggers, this is already a mess. Add NMUs due to private ported packages, and all hell breaks loose. The rest is easy in comparison: a porter team can decide whether to snapshot testing as unofficial stable; point releases are a matter of running a buildd job (and fixing failures), same for security. We'd be able to concentrate on actual arch-specific issues. > The main difference should (IMHO) be the amount of support you get: While a > first-class arch will get faster fixes and a more stable dependency tree, > other archs will be more "sloppy", for example by not blocking stable releases > with their own RC bugs etc. Yeah, a completely one-way relationship: no issue on second-class would block first-class. > If this can be fulfilled, I don't think being a second-class arch will be such > a big deal. Not sure how far Debian is from this goal, but I can understand > that many DDs and DMs would rather invest their time into projects they have a > stake in, rather than hardware they don't (or don't want to?) understand. Yes, x32 suffers from needing obscure and hard to get hardware. :) Meow! [1]. The vast majority of security issues are non arch dependent, so blindly tracking and building first-class security updates gets us nearly all the way, reducing the work to babysitting buildds and looking into FTBFSes or yet another whole-new-language-ecosystem getting allowed into stable. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Ivan was a worldly man: born in St. Petersburg, raised in ⢿⡄⠘⠷⠚⠋⠀ Petrograd, lived most of his life in Leningrad, then returned ⠈⠳⣄ to the city of his birth to die.
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 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.
Bug#711703: src:s390-tools: uses deprecated find -perm +0123
Package: src:s390-tools Version: 1.17.1-1 Severity: normal Tags: patch Hi! An incoming version of findutils drops the syntax of find -perm +0123, which contradicts POSIX and thus has been deprecated since 2005. The replacement is -perm /0123. s390-tools uses it in two places in scripts/dbginfo.sh To update it: sed -i 's:-perm +\([0-9]\):-perm /\1:g' scripts/dbginfo.sh -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9.4-x32 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130608194051.26584.51916.report...@umbar.angband.pl