[PATCH kernel-wedge 0/3]
I'm intending to commit the following changes and upload a new version
of kernel-wedge. Let me know if you see any problems with them.
Ben.
Ben Hutchings (3):
gen-deps: Ignore default dependencies that are overridden
per-architecture
List the unpackaged modules
install-files: Include modules.{builtin,order} in Linux kernel-image
udebs
commands/find-unpackaged | 35 +++
commands/find-unpackaged.txt |5 +
commands/gen-deps|4
commands/install-files | 32 +++-
debian/changelog | 10 ++
5 files changed, 77 insertions(+), 9 deletions(-)
create mode 100755 commands/find-unpackaged
create mode 100644 commands/find-unpackaged.txt
signature.asc
Description: Digital signature
[PATCH 1/3] gen-deps: Ignore default dependencies that are overridden per-architecture
Ignore dependencies in default package-list that are overridden by the
architecture package-list, consistent with gen-control (Closes: #678587)
The previous behaviour masked incomplete dependency lists for some of
the Linux udebs.
---
The incomplete dependencies were fixed in linux 3.2.21-2, so this
should have no immediate effect on Linux. However it is possible that
kFreeBSD has the same problem and would fail to build after this.
Ben.
commands/gen-deps |4
debian/changelog |7 +++
2 files changed, 11 insertions(+)
diff --git a/commands/gen-deps b/commands/gen-deps
index c637375..f596c4c 100755
--- a/commands/gen-deps
+++ b/commands/gen-deps
@@ -39,6 +39,10 @@ sub read_package_list
$modlistdir = "$configdir/modules/$arch";
}
next unless -e "$modlistdir/$package";
+
+ # Override previously defined dependencies
+ @out = grep(!/^$package\t/, @out);
+
foreach my $dep (@depends) {
# Skip depends that are not built for this
# architecture.
diff --git a/debian/changelog b/debian/changelog
index fece32d..6bebe43 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+kernel-wedge (2.85) UNRELEASED; urgency=low
+
+ * gen-deps: Ignore dependencies in default package-list that are
+overridden by the architecture package-list (Closes: #678587)
+
+ -- Ben Hutchings Sun, 24 Jun 2012 19:34:25 +0100
+
kernel-wedge (2.84) unstable; urgency=low
[ Joey Hess ]
signature.asc
Description: Digital signature
[PATCH 2/3] List the unpackaged modules
find-unpackaged: New sub-command lists modules not packaged in a udeb
install-files: Call find-unpackaged
---
I hope this information will help us to update the module lists. At
some point I would like to add the ability to include modules by
subdirectory, though.
Ben.
commands/find-unpackaged | 35 +++
commands/find-unpackaged.txt |5 +
commands/install-files |1 +
debian/changelog |2 ++
4 files changed, 43 insertions(+)
create mode 100755 commands/find-unpackaged
create mode 100644 commands/find-unpackaged.txt
diff --git a/commands/find-unpackaged b/commands/find-unpackaged
new file mode 100755
index 000..a7bcf6d
--- /dev/null
+++ b/commands/find-unpackaged
@@ -0,0 +1,35 @@
+#!/usr/bin/perl
+# Find unpackaged modules. Pass the kernel name and installed name
+# (normally the same).
+use strict;
+use warnings;
+use File::Find ();
+use File::Spec;
+
+my $kernel = $ARGV[0];
+my $installedname = $ARGV[1];
+
+my $moddir = "/lib/modules/$installedname";
+my $sourcedir = $ENV{SOURCEDIR} || '';
+
+my %unpackaged;
+my $dir = "$sourcedir$moddir";
+File::Find::find(
+sub {
+ $unpackaged{File::Spec->abs2rel($File::Find::name, $dir)} = 1
+ if /\.k?o$/;
+},
+$dir);
+for my $dir (glob("debian/*-modules-$kernel-di$moddir")) {
+File::Find::find(
+ sub {
+ delete $unpackaged{File::Spec->abs2rel($File::Find::name, $dir)}
+ if /\.k?o$/;
+ },
+ $dir);
+}
+
+print "These modules from $kernel are unpackaged:\n";
+for my $path (sort(keys(%unpackaged))) {
+print "\t\t$path\n";
+}
diff --git a/commands/find-unpackaged.txt b/commands/find-unpackaged.txt
new file mode 100644
index 000..5aae086
--- /dev/null
+++ b/commands/find-unpackaged.txt
@@ -0,0 +1,5 @@
+find-unpackaged kernel-name
+
+List modules that are not packaged in a udeb. Pass the kernel name.
+
+Always return 0.
diff --git a/commands/install-files b/commands/install-files
index 039a812..2241b1b 100755
--- a/commands/install-files
+++ b/commands/install-files
@@ -129,6 +129,7 @@ while () {
doit("kernel-wedge", "copy-modules", $kernelversion, $flavour,
$installedname);
doit("kernel-wedge", "find-dups", "$kernelversion-$flavour");
+ doit("kernel-wedge", "find-unpackaged", "$kernelversion-$flavour",
$installedname);
doit("kernel-wedge", "strip-modules", "$kernelversion-$flavour");
}
close KVERS;
diff --git a/debian/changelog b/debian/changelog
index 6bebe43..1959853 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,6 +2,8 @@ kernel-wedge (2.85) UNRELEASED; urgency=low
* gen-deps: Ignore dependencies in default package-list that are
overridden by the architecture package-list (Closes: #678587)
+ * find-unpackaged: New sub-command lists modules not packaged in a udeb
+ * install-files: Call find-unpackaged
-- Ben Hutchings Sun, 24 Jun 2012 19:34:25 +0100
signature.asc
Description: Digital signature
[PATCH 3/3] install-files: Include modules.{builtin,order} in Linux kernel-image udebs
---
libkmod expects these files to be present. However they are not
being installed in the s390 tape image packages, so this probably
should be made conditional. That might be a bug in the linux package
though. Bastian?
Ben.
commands/install-files | 31 ++-
debian/changelog |1 +
2 files changed, 23 insertions(+), 9 deletions(-)
diff --git a/commands/install-files b/commands/install-files
index 2241b1b..eddd5d2 100755
--- a/commands/install-files
+++ b/commands/install-files
@@ -11,6 +11,8 @@ sub doit {
my $hostarch=`dpkg-architecture -qDEB_HOST_ARCH`;
chomp $hostarch;
+my $hostos=`dpkg-architecture -qDEB_HOST_ARCH_OS`;
+chomp $hostos;
my $configdir = ($ENV{KW_CONFIG_DIR} || '.');
my $fixsourcedir = $ENV{SOURCEDIR};
@@ -84,15 +86,26 @@ while () {
if (! -e "$modlistdir/kernel-image") {
# copy no kernel
}
- elsif (-e "$sourcedir/boot/vmlinux-$installedname") {
- doit("install", "-D", "-m", 644,
- "$sourcedir/boot/vmlinux-$installedname",
-
"debian/kernel-image-$kernelversion-$flavour-di/boot/vmlinux$extraname");
- }
- elsif (-e "$sourcedir/boot/vmlinuz-$installedname") {
- doit("install", "-D", "-m", 644,
- "$sourcedir/boot/vmlinuz-$installedname",
-
"debian/kernel-image-$kernelversion-$flavour-di/boot/vmlinuz$extraname");
+ elsif ($hostos eq 'linux') {
+ if (-e "$sourcedir/boot/vmlinux-$installedname") {
+ doit("install", "-D", "-m", 644,
+"$sourcedir/boot/vmlinux-$installedname",
+
"debian/kernel-image-$kernelversion-$flavour-di/boot/vmlinux$extraname");
+ }
+ elsif (-e "$sourcedir/boot/vmlinuz-$installedname") {
+ doit("install", "-D", "-m", 644,
+"$sourcedir/boot/vmlinuz-$installedname",
+
"debian/kernel-image-$kernelversion-$flavour-di/boot/vmlinuz$extraname");
+ }
+ else {
+ die "could not find kernel image";
+ }
+ doit("install", "-d",
+
"debian/kernel-image-$kernelversion-$flavour-di/lib/modules/$installedname/");
+ doit("install", "-m", 644,
+"$sourcedir/lib/modules/$installedname/modules.builtin",
+"$sourcedir/lib/modules/$installedname/modules.order",
+
"debian/kernel-image-$kernelversion-$flavour-di/lib/modules/$installedname/");
}
elsif (-e "$sourcedir/boot/kfreebsd-$installedname.gz") {
doit("install", "-D", "-m", 644,
diff --git a/debian/changelog b/debian/changelog
index 1959853..3fb4257 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,6 +4,7 @@ kernel-wedge (2.85) UNRELEASED; urgency=low
overridden by the architecture package-list (Closes: #678587)
* find-unpackaged: New sub-command lists modules not packaged in a udeb
* install-files: Call find-unpackaged
+ * install-files: Include modules.{builtin,order} in Linux kernel-image udebs
-- Ben Hutchings Sun, 24 Jun 2012 19:34:25 +0100
signature.asc
Description: Digital signature
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
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
Bug#594940: Includes binary-only and obfuscated C code
Package: kfreebsd-8 Version: 8.1-5 Severity: serious The following C files contain firmware images in binary-equivalent form but are not obviously accompanied by the corresponding source code: sys/contrib/dev/ral/rt2661_ucode.h - binaries are packaged in firmware-ralink as /lib/firmware/ralink/rt2?6*.bin sys/gnu/dev/sound/pci/csaimg.h - not packaged; not distributable since the stated licence is GPL sys/gnu/dev/sound/pci/maestro3_dsp.h - not packaged; not distributable since the stated licence is GPL sys/dev/drm/mga_ucode.h - binaries are packaged in firmware-linux-nonfree as /lib/firmware/matrox/* sys/dev/drm/r128_cce.c - binary is packaged in firmware-linux-nonfree as /lib/firmware/r128/r128_cce.bin sys/dev/drm/r600_microcode.h sys/dev/drm/radeon_microcode.h - binaries are packaged in firmware-linux-nonfree as /lib/firmware/radeon/* sys/dev/txp/3c990img.h - binary is packaged in firmware-linux-nonfree as /lib/firmware/3com/typhoon.bin sys/dev/fxp/rcvbundl.h - binaries are packaged in firmware-linux-nonfree as /lib/firmware/e100/* sys/dev/digi/*X*.h - not packaged; distributable sys/dev/sf/starfire_rx.h sys/dev/sf/starfire_tx.h - not packaged; maybe distributable sys/dev/sn/ositech.h - not packaged; distributable sys/dev/sound/pci/ds1-fw.h - not packaged; distributable sys/dev/si/si2_z280.c sys/dev/si/si3_t225.c - not packaged; maybe distributable sys/dev/cxgb/common/cxgb_ael1002.c - binaries are packaged in firmware-linux-nonfree as /lib/firmware/cxgb3/ael*.bin sys/dev/fatm/firmware.h - not packaged; not distributable sys/dev/cx/csigmafw.h - not packaged; maybe distributable sys/dev/bce/if_bcefw.h - binaries are packaged in firmware-bnx2 as /lib/firmware/bnx2/bnx2/*.fw sys/dev/usb/net/if_kuefw.h - binaries are packaged in firmware-linux-nonfree as /lib/firmware/kaweth/* sys/dev/usb/wlan/if_rumfw.h - binary is packaged in firmware-ralink as /lib/firmware/ralink/rt73.bin sys/dev/usb/wlan/if_zydfw.h - not packaged; distributable sys/dev/ti/ti_fw2.h sys/dev/ti/ti_fw.h - not packaged; maybe distributable sys/dev/ctau/ctaue1fw.h sys/dev/ctau/ctau2fw.h sys/dev/ctau/ctaufw.h sys/dev/ctau/ctaug7fw.h - not packaged; maybe distributable sys/dev/ispfw/asm_*.h - binaries are packaged in firmware-qlogic as /lib/firmware/ql*_fw.bin sys/dev/advansys/adwmcode.c - binary is packaged in firmware-linux-nonfree as /lib/firmware/advansys/mcode.bin As one of the maintainers of firmware-nonfree, I'm happy to cooperate in adding any firmware images from FreeBSD that Debian can legally distribute. Additionally, these C files contain obfuscated code: sys/dev/ce/tau32-ddk.c sys/dev/cp/cpddk.c Ben. -- System Information: Debian Release: squeeze/sid APT prefers proposed-updates APT policy: (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bsd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100830215258.11083.70389.report...@localhost
Bug#594940: Includes binary-only and obfuscated C code
Additionally, the following uuencoded files contain binary-equivalent firmware images with no accompanying source code: sys/contrib/dev/mwl/mwlboot.fw.uu sys/contrib/dev/mwl/mw88W8363.fw.uu - not packaged; distributable sys/contrib/dev/ral/rt2561.fw.uu sys/contrib/dev/ral/rt2561s.fw.uu sys/contrib/dev/ral/rt2860.fw.uu sys/contrib/dev/ral/rt2661.fw.uu sys/contrib/dev/run/rt2870.fw.uu - packaged in firmware-ralink sys/contrib/dev/npe/IxNpeMicrocode.dat.uu - not packaged; distributable sys/contrib/dev/ipw/ipw2100-1.3-i.fw.uu sys/contrib/dev/ipw/ipw2100-1.3-p.fw.uu sys/contrib/dev/ipw/ipw2100-1.3.fw.uu sys/contrib/dev/iwi/ipw2200-ibss.fw.uu sys/contrib/dev/iwi/ipw2200-bss.fw.uu sys/contrib/dev/iwi/ipw2200-sniffer.fw.uu - packaged in firmware-ip2x00 sys/contrib/dev/uath/ar5523.bin.uu - not packaged; no licence visible sys/contrib/dev/iwn/iwlwifi-5150-8.24.2.2.fw.uu sys/contrib/dev/iwn/iwlwifi-1000-128.50.3.1.fw.uu sys/contrib/dev/iwn/iwlwifi-5000-8.24.2.12.fw.uu sys/contrib/dev/iwn/iwlwifi-4965-228.61.2.24.fw.uu sys/contrib/dev/iwn/iwlwifi-6000-9.193.4.1.fw.uu sys/contrib/dev/wpi/iwlwifi-3945-2.14.4.fw.uu - packaged in firmware-iwlwifi And the following uuencoded files appear to contain x86 binary code to run on the host, without accompanying source code: sys/contrib/dev/nve/i386/nvenetlib.o.bz2.uu sys/contrib/dev/nve/amd64/nvenetlib.o.bz2.uu sys/dev/hptrr/amd64-elf.hptrr_lib.o.uu sys/dev/hptrr/i386-elf.hptrr_lib.o.uu sys/dev/hptmv/i386-elf.raid.o.uu sys/dev/hptmv/amd64-elf.raid.o.uu 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: Current and upcoming toolchain changes for jessie
On Wed, 2013-05-08 at 01:39 +0200, Matthias Klose wrote: [...] > - I didn't upload linux-libc-dev myself, but until today I didn't >see any announcement or a test rebuild done by the Debian kernel >maintainers, so I did add the note about what I did see in multiple >packages when doing a test rebuild in Ubuntu. > >And I think it's a normal change, and build failures can be reported >after a test rebuild. You may want to contact the kernel team, if >you think otherwise. [...] I must admit that it hadn't occurred to me to check this in advance. Sorry about that. If there are particular changes that cause a lot of breakage, they could be reverted temporarily. 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: 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: possible /dev/random compromise (misplaced trust in RDRAND / Padlock entropy sources)
On Sat, 2013-12-14 at 19:00 -0200, Henrique de Moraes Holschuh wrote: > On Sat, 14 Dec 2013, Steven Chamberlain wrote: > > On 14/12/13 01:08, Henrique de Moraes Holschuh wrote: > > > Yeah, I think Linux went through similar blindness braindamage sometime > > > ago, > > > but blind trust on rdrand has been fixed for a long time now, and it never > > > trusted any of the other HRNGs (or used them for anything at all without a > > > trip through "rng-tools" userspace until v3.12). > > > > I seem to remember that Ted T'so's committed the fix for this only after > > the release of Linux 3.2, so I assuemd wheezy's kernels might be still > > affected? > > I'd need to check it througoutly, but almost all important /dev/random > changes in Linux were backported to all stable kernels, and thus eventually > migrated into the Debian kernel (which is based on 3.2.y-stable plus lots of > other backports). If I understand rightly, in Linux 3.2 RDRAND (or other architectural HWRNG) was used for get_random_int() and get_random_bytes() but not for /dev/random or /dev/urandom. Linux 3.2.27 (and other stable updates) inclued a large set of security improvements for the RNG, primarily addressing lack of entropy at boot (see <https://factorable.net>). As part of this, an architectural HWRNG will be used as a extra source of entropy for /dev/random and /dev/urandom, but credited as providing only a fraction of a bit of entropy. get_random_bytes() was changed to not use an architectural HWRNG. get_random_int() and get_random_bytes_arch() will use it and it is documented that they are not suitable for cryptographic purposes. Ben. -- Ben Hutchings Knowledge is power. France is bacon. 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: 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 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: 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: 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: Bug#955210: kernel-wedge: regression causes kfreebsd-10 FTBFS
On Sat, 2020-03-28 at 13:41 +, Steven Chamberlain wrote: [...] > kfreebsd-10 FTBFS, due to probably this change in kernel-wedge: > https://salsa.debian.org/installer-team/kernel-wedge/-/commit/3827f1ee9f53540b104c592a8a2695f78d8629ed [...] On Sat, 2020-03-28 at 18:29 +, Steven Chamberlain wrote: > tags -1 + patch > thanks Sorry about that. I knew this was a relatively risky change, but thought I had test cases covering everything. Would you mind adding a regression test for this case? Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't. signature.asc Description: This is a digitally signed message part
