Re: Re-evaluating architecture inclusion in unstable/experimental
On Sat, 2018-09-29 at 17:05 +0200, John Paul Adrian Glaubitz wrote: > On 9/29/18 8:48 AM, Ben Hutchings wrote: > > On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote: > > [...] > > > Furthermore, several of the ports are in very healthy condition and > > > even surpass some release architectures. The powerpc and ppc64 ports, > > > for example, build more packages than any of the mips* ports. > > > > I would be very happy to never have to wait for MIPS builds again. > > I don't have a problem with waiting for slow machines. I just think this > shows that the decisions what becomes a release architecture and what > doesn't isn't purely meritocratic. It's been a long time since Debian could run infrastructure on donated hardware. We need hardware that is reliable and that can be quickly replaced when (not if) it fails. So commercial availability is, and should continue to be, a release qualification. It is also unacceptable that the release of an urgent security update should have to wait a long time for builds. So speed matters. [...] > I think the problem that I have is that the release qualifications are > not practical in the sense that they don't necessarily meet our users > expectations. As I said, I think a tier-based system would be more > practical as it would allow ports to be degraded more gracefully instead > of just kicking them out like it was done with 32-Bit PowerPC. [...] Could you be more specific? Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
Re: Re-evaluating architecture inclusion in unstable/experimental
On Fri, 2018-09-28 at 14:16 +0200, John Paul Adrian Glaubitz wrote: [...] > Furthermore, several of the ports are in very healthy condition and > even surpass some release architectures. The powerpc and ppc64 ports, > for example, build more packages than any of the mips* ports. I would be very happy to never have to wait for MIPS builds again. > As for the kernel maintenance, except for Alpha, all the ports have > at least one kernel maintainer: > > * hppa: actively maintained by two people who also maintain the toolchain But the hardware is EOL since 2008. > * ia64: maintained by one paid developer at Intel To the extent of 2 whole commits this year! I'm pretty sure this is not actually his job any more. > * m68k: maintained by multiple independent kernel maintainers, at least > five people involved upstream; port is also getting new drivers But the available hardware is either too slow to be useful, or only available through crowdfunding (maybe, eventually). > * powerpc/ppc64: maintained mostly by IBM people IBM looks after 64-bit configurations, so ppc64 is covered but not powerpc. > * sh4: maintained by two kernel maintainers That may be, but the Debian port isn't stable enough to *build* a kernel: https://buildd.debian.org/status/logs.php?pkg=linux&arch=sh4 > * sparc64: used to be maintained by a team at Oracle but Oracle recently > changed their mind about Linux on SPARC; now it's back to > David Miller and some additional volunteers Oracle laid off their SPARC team. Fujitsu has another SPARC processor in development, but only for supercomputers (and they seem to be switching to Aarch64 later). So we can expect this architecture to slowly fade away now. > * x32: maintained by the people who maintain the x86 port of the kernel H. Peter Anvin did the original port in 2012, but so far as I can see none of the x86 maintainers have done any development on it since then. And yes, development work has been needed: - x32 has 64-bit time_t and that never worked quite right. This may have finally been fixed this year by Arnd Bergmann's work, but I'm not sure. - syscall restart was broken until 2015 when someone actually tested it. - There have been several regressions specific to x32, some of which stuck around for a year or so before someone and fixed them. [...] So, by all means have fun working on these ports, but aside from ppc64 I don't see any prospect of them meeting release qualifications. Ben. -- Ben Hutchings For every action, there is an equal and opposite criticism. - Harrison signature.asc Description: This is a digitally signed message part
Re: Porter roll call for Debian Stretch
On Sat, 2016-10-01 at 15:48 +0200, John Paul Adrian Glaubitz wrote: > On 10/01/2016 02:17 PM, Ben Hutchings wrote: > > > > > > > > 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. > > > > This is not at all true. My experience is that IBM doesn't even build- > > test 32-bit configurations, as evidenced by several stable updates > > causing FTBFS in Debian. > > They care enough that they are fixing bugs. Just recently, a bug in the > PowerPC kernel was fixed that affected 32-bit embedded PowerPCs only. $ git log --author=ibm --grep='ppc-?32|powerpc-?32|32-bit' -i -E arch/powerpc finds me fewer than ten commits per year. > > > > > > > > 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. > > [...] > > > > Oracle cares about Solaris on SPARC, not Linux on SPARC. > > Well, then you know more than the people at Oracle that I am talking to. [... much evidence of Oracle supporting Linux on SPARC ...] OK, I accept this has changed, but I'm quite surprised - Oracle is ruthlessly commercial, and I'm mystified as to who they expect to buy it. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Re: Porter roll call for Debian Stretch
On Fri, 2016-09-30 at 22:34 +0200, John Paul Adrian Glaubitz wrote: > 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. This is not at all true. My experience is that IBM doesn't even build- test 32-bit configurations, as evidenced by several stable updates causing FTBFS in Debian. > 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). Which are very different from the Power Macs and similar platforms that most Debian powerpc users care about. > 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. [...] Oracle cares about Solaris on SPARC, not Linux on SPARC. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Re: Porter roll call for Debian Stretch
On Sat, 2016-10-01 at 02:28 +0200, Adam Borowski wrote: > On Fri, Sep 30, 2016 at 11:01:55PM +0200, Mathieu Malaterre wrote: [...] > > 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: [...] This is only the case because ppc64 has a lower level of support (unofficial port) than powerpc (release architecture). The 64-bit kernel package should be dropped once powerpc is at the same or lower level of support than ppc64 - just as we've done for i386, s390 and sparc. Ben. -- Ben Hutchings Klipstein's 4th Law of Prototyping and Production: A fail-safe circuit will destroy others. signature.asc Description: This is a digitally signed message part
Re: Roll call for porters of architectures in sid and testing (Status update)
On Sat, 2013-09-21 at 19:36 +0200, Émeric MASCHINO wrote: > Hi, > > I'm a long-time ia64 Debian user (> 10 years). I'm mostly focused on > desktop aspects (GNOME, Iceweasel, LibreOffice, Qt Creator, C++ 3D > software development) while most other ia64 users that I know are more > inclined on server use. > > I'm not a DD/DM, but daily update my ia64 workstation, report bugs and > do my best to provide useful information in order to get them fixed. Thank you for this. > I've also provided a couple of kernel patches in the past. I'm cross > testing with Gentoo to ensure that bugs I report are Debian-specific > or ia64-generic. > > I'll continue testing/software development activity on ia64 for the > Jessie cycle, and more generally, until Debian drops ia64. I'm already > waiting for Wayland on ia64 and other big updates. > > So please, keep ia64 in the bandwagon ;-) But I don't think ia64 is well-supported even in wheezy. The kernel doesn't boot on some common machines and no-one seems to be able to fix it. Ben. -- Ben Hutchings compatible: Gracefully accepts erroneous data from any source signature.asc Description: This is a digitally signed message part
Re: [DRAFT v2] Policy for Linux kernel, initramfs, boot loader update process
On Thu, 2010-07-08 at 09:51 +0200, Guillem Jover wrote: [...] > On Sun, 2010-07-04 at 18:48:20 +0100, Ben Hutchings wrote: > > 4. During a kernel package installation, upgrade or removal, various > > boot loader hooks may be invoked (in this order): > > > > a. A postinst_hook or postrm_hook command set by the user or the > >installer in /etc/kernel-img.conf > > kfreebsd-image-* packages honour those hooks. I'll add support for > those to gnumach. That is not necessary; these are already deprecated. > > b. A hook script in /etc/initramfs/post-update.d > > Neither kfreebsd nor gnumach honour this, not needed yet though. Nor implemented at all! > > c. A hook script in /etc/kernel/postinst.d or .../postrm.d > > Neither do honour these, they need support added. I can probably make > some time to do that for both. Please do. > > To avoid unnecessary updates, the hooks invoked at step a and b may > > check whether $DPKG_MAINTSCRIPT_PACKAGE begins with 'linux-image-' and > > do nothing in this case. > > Take into account that DPKG_MAINTSCRIPT_PACKAGE is only set if running > under dpkg, dpkg-reconfigure (from debconf) does not set this nor other > variables yet. See #560317. Well, this *is* an optimisation, not required for correctness. > It would be nice to consider the other kernel package names. But even > nicer to just have a centralized place where all currently known package > patterns are listed or can be queried so that there's no need to update > multiple scripts on new kernel additions, or name convention changes. I think any package that deals with kernel images must have explicit support for the kernel type, and it can tell the expected kernel type based on the Debian architecture name. So I think this abstraction is unnecessary. I have not added any requirements for non-Linux kernels in the policy, but if you and the other maintainers can fully define how to extend it to your kernels then I'm happy to include those extensions. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse. signature.asc Description: This is a digitally signed message part
Re: How to stop building libv4l on non-Linux architectures
On Sun, 2008-11-02 at 14:16 +0100, Gregor Jasny wrote: > Hi, > > I'm the maintainer of libv4l which passed the new queue yesterday. > Obviously the package build failed on non-Linux architectures [1]. How > do I handle this situation? Should I list all supported architectures in > the control file, Either that or it can be added to wanna-build's packages-arch-specific list. Mail Lamont Jones <[EMAIL PROTECTED]> if you want that change made. > or will the Hurd and BSD porter teams add libv4l to > the NOT-FOR-US list? I believe not-for-us is intended for temporary use where a build attempt can break the buildd. Ben. signature.asc Description: This is a digitally signed message part
