Re: Arch qualification for buster: call for DSA, Security, toolchain concerns

[Adam Borowski]

[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

[Adam Borowski]

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

[Adam Borowski]

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

[Adam Borowski]

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