Bug#1002890: nvme-cli: Uninstallable on architectures without a DMI
Package: nvme-cli Version: 1.14-1 Severity: grave Tags: patch Justification: renders package unusable Hello, On architectures without a DMI (basically all architectures except x86), attempting to install nvme-cli >= 1.14-1 results in: Setting up nvme-cli (1.16-2) ... "gen-hostnqn" not supported. Install lib uuid and rebuild. dpkg: error processing package nvme-cli (--configure): installed nvme-cli package post-installation script subprocess returned error exit status 161 This is because 1.14 refactored gen-hostnqn to try searching the DMI for a unique ID, but will fall back to a randomly generated UUID, but only if libuuid is available at build time. Adding uuid-dev to Build-Depends will fix this issue. Thank you, Ryan Finnie OpenPGP_signature Description: OpenPGP digital signature
Bug#999185: atmel-firmware: missing required debian/rules targets build-arch and/or build-indep
On Tue, 09 Nov 2021 22:28:19 +0100 Lucas Nussbaum wrote:
> Source: atmel-firmware
> Version: 1.3-4.1
> Severity: important
> Justification: Debian Policy section 4.9
> Tags: bookworm sid
> User: debian...@lists.debian.org
> Usertags: missing-build-arch-indep
>
> Dear maintainer,
>
> Your package does not include build-arch and/or build-indep targets in
> debian/rules. This is required by Debian Policy section 4.9, since 2012.
> https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules
>
> Please note that this is also a sign that the packaging of this software
> could benefit from a refresh. For example, packages using 'dh' cannot be
> affected by this issue.
>
> This mass bug filing was discussed on debian-devel@ in
> https://lists.debian.org/debian-devel/2021/11/msg00052.html .
> The severity of this bug will be changed to 'serious' after a month.
Please find attached a debdiff which converts this package to modern
debhelper. This is MVP required to produce 1) a clean lintian output and
2) a binary package-level no-op vs 1.3-4.1.
I am requesting sponsorship as I am a Debian Maintainer and do not have
full DD upload rights outside my core packages.
(I do not have a major stake in this package, other than noticing it
falling out of testing by this bug.)
Thank you,
Ryan Finnie
diff -Nru atmel-firmware-1.3/atmel-firmware.spec
atmel-firmware-1.3/atmel-firmware.spec
--- atmel-firmware-1.3/atmel-firmware.spec 2021-12-28 22:18:15.0
-0800
+++ atmel-firmware-1.3/atmel-firmware.spec 2005-05-07 13:17:12.0
-0700
@@ -9,12 +9,12 @@
# For Fedore Core 3 firmware goes in /lib/firmware
# For other distros/releases we use /usr/lib/hotplug/firmware
%define fedoramajorver %(rpm -q --queryformat='%{VERSION}' fedora-release|cut
-d. -f1)
-%define fcnew %(if [ "%{_target}" == "fedora-linux" -o %{fedoramajorver} -ge 3
];then echo 1;else echo 0;fi)
+%define fc3 %(if [ "%{fedoramajorver}" == "3" -o "%{_target}" ==
"fedora-linux" ];then echo 1;else echo 0;fi)
-%if %{fcnew}
+%if %{fc3}
%define firmware_dir /lib/firmware
-%define extraver %{release}fcnew
+%define extraver %{release}fc3
%else
%define firmware_dir /usr/lib/hotplug/firmware
%define extraver %{release}
@@ -29,7 +29,7 @@
Name: atmel-firmware
Version: 1.3
Release: %{extraver}
-License: Distributable
+Copyright: Distributable
Group: System Environment/Kernel
Vendor: Simon Kelley
Packager: Simon Kelley
diff -Nru atmel-firmware-1.3/debian/changelog
atmel-firmware-1.3/debian/changelog
--- atmel-firmware-1.3/debian/changelog 2021-12-28 22:18:15.0 -0800
+++ atmel-firmware-1.3/debian/changelog 2021-12-28 22:06:04.0 -0800
@@ -1,3 +1,12 @@
+atmel-firmware (1.3-4.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Convert package to debhelper (Closes: #999185)
+ * Convert debian/copyright to DEP-5
+ * Clean lintian (except for pedantic whitespace)
+
+ -- Ryan Finnie Tue, 28 Dec 2021 22:06:04 -0800
+
atmel-firmware (1.3-4.1) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru atmel-firmware-1.3/debian/conffiles
atmel-firmware-1.3/debian/conffiles
--- atmel-firmware-1.3/debian/conffiles 2021-12-28 22:18:15.0 -0800
+++ atmel-firmware-1.3/debian/conffiles 1969-12-31 16:00:00.0 -0800
@@ -1 +0,0 @@
-/etc/pcmcia/atmel.conf
diff -Nru atmel-firmware-1.3/debian/control atmel-firmware-1.3/debian/control
--- atmel-firmware-1.3/debian/control 2021-12-28 22:18:15.0 -0800
+++ atmel-firmware-1.3/debian/control 2021-12-28 22:06:04.0 -0800
@@ -2,10 +2,13 @@
Section: non-free/net
Priority: optional
Maintainer: Simon Kelley
-Standards-Version: 3.5.6.0
+Build-Depends: debhelper, debhelper-compat (= 13), dpkg-dev (>= 1.16.1~)
+Standards-Version: 4.6.0
+Rules-Requires-Root: no
Package: atmel-firmware
Architecture: all
+Depends: ${misc:Depends}
Suggests: wireless-tools
Conflicts: atmelwlandriver-tools
Description: Firmware for Atmel at76c50x wireless networking chips.
diff -Nru atmel-firmware-1.3/debian/copyright
atmel-firmware-1.3/debian/copyright
--- atmel-firmware-1.3/debian/copyright 2021-12-28 22:18:15.0 -0800
+++ atmel-firmware-1.3/debian/copyright 2021-12-28 22:02:30.0 -0800
@@ -1,64 +1,66 @@
-This Debian package is derived from atmel-firmware-1.2.tar.gz which is
-available on-line at:
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
-http://www.thekelleys.org.uk/atmel/atmel-firmware-1.2.tar.gz
-
-The Debian package of atmel-firmware was created by Simon Kelley.
-
-The bin files in the images were generated from header files
-included with the 2.1.1 release of the "Atmel drivers", released
-by Atmel corp in December 2002 and subsequent modifications,
-downloaded from
Bug#958607: lilo: ftbfs with GCC-10
tags 958607 + patch thanks Please see attached debdiff for a fix which drops dh-systemd. Sponsorship is requested (filing RFS), thank you. https://mentors.debian.net/package/pppconfig/ diff -Nru pppconfig-2.3.24/debian/changelog pppconfig-2.3.25/debian/changelog --- pppconfig-2.3.24/debian/changelog 2020-03-22 16:32:23.0 -0700 +++ pppconfig-2.3.25/debian/changelog 2020-11-05 14:59:44.0 -0800 @@ -1,3 +1,14 @@ +pppconfig (2.3.25) unstable; urgency=medium + + * QA upload. + * Remove dh-systemd Build-Depends, move to debhelper 10. +(Closes: #958607) + * Remove pppconfig.lintian-overrides, contained removed +override init.d-script-missing-dependency-on-remote_fs +throwing lintian E. + + -- Ryan Finnie Thu, 05 Nov 2020 14:59:44 -0800 + pppconfig (2.3.24) unstable; urgency=medium * QA upload. diff -Nru pppconfig-2.3.24/debian/compat pppconfig-2.3.25/debian/compat --- pppconfig-2.3.24/debian/compat 2010-04-21 09:49:56.0 -0700 +++ pppconfig-2.3.25/debian/compat 2020-11-05 14:54:31.0 -0800 @@ -1 +1 @@ -7 +10 diff -Nru pppconfig-2.3.24/debian/control pppconfig-2.3.25/debian/control --- pppconfig-2.3.24/debian/control 2020-03-22 16:32:19.0 -0700 +++ pppconfig-2.3.25/debian/control 2020-11-05 14:56:40.0 -0800 @@ -4,7 +4,7 @@ Maintainer: Debian QA Group Standards-Version: 3.9.2 Build-Depends-Indep: debianutils (>= 2.10.3) -Build-Depends: debhelper (>= 7), dh-systemd (>= 1.6), po4a +Build-Depends: debhelper (>= 10~), po4a Package: pppconfig Architecture: all diff -Nru pppconfig-2.3.24/debian/pppconfig.lintian-overrides pppconfig-2.3.25/debian/pppconfig.lintian-overrides --- pppconfig-2.3.24/debian/pppconfig.lintian-overrides 2014-02-15 13:25:40.0 -0800 +++ pppconfig-2.3.25/debian/pppconfig.lintian-overrides 1969-12-31 16:00:00.0 -0800 @@ -1 +0,0 @@ -pppconfig: init.d-script-missing-dependency-on-remote_fs etc/init.d/dns-clean: required-start signature.asc Description: OpenPGP digital signature
Bug#957490: lilo: ftbfs with GCC-10
On 11/5/20 3:13 PM, Joachim Wiedorn wrote: > Hello Ryan, > > I have seen your patch. > > Please notice, that I don't want to maintain this package anymore. And > because of better software nowadays (grub2) it should not get into next > Debian Release. You should check 'popcon' where you see that only a handful > of machines use this (old) software today. > > So I will orphan this package. > And I will block it, so that it won't get into Debian Bullseye. > > Is that o.k. for you? I do not have a strong opinion either way; I fixed the FTBFS as part of a series of GCC-10 FTBFS RCs which affected Finnix. In theory lilo would be of use to utility CDs like Finnix for fixing old (ancient) installations, but even that's pushing it these days. I don't think you should file an Orphan WNPP, as that assumes the software should still be in Debian, but needs a maintainer. Instead, I think you should file an ROM against ftp.debian.org to get it removed from sid. Considering you are also upstream, this makes the argument for full removal easier since it's effectively abandoned upstream. Thanks, Ryan signature.asc Description: OpenPGP digital signature
Bug#957490: lilo: ftbfs with GCC-10
tags 957490 + patch
thanks
Please see attached debdiff for a NMU ftbfs fix. Sponsorship is
requested, thank you.
diff -Nru lilo-24.2/debian/changelog lilo-24.2/debian/changelog
--- lilo-24.2/debian/changelog 2019-12-10 14:41:00.0 -0800
+++ lilo-24.2/debian/changelog 2020-10-28 11:18:45.0 -0700
@@ -1,3 +1,10 @@
+lilo (1:24.2-5.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix ftbfs with GCC-10. (Closes: #957490)
+
+ -- Ryan Finnie Wed, 28 Oct 2020 11:18:45 -0700
+
lilo (1:24.2-5) unstable; urgency=medium
* Add file debian/NEWS to point out that lilo package is deprecated
diff -Nru lilo-24.2/debian/patches/11_fix-gcc-10.patch
lilo-24.2/debian/patches/11_fix-gcc-10.patch
--- lilo-24.2/debian/patches/11_fix-gcc-10.patch1969-12-31
16:00:00.0 -0800
+++ lilo-24.2/debian/patches/11_fix-gcc-10.patch2020-10-28
11:15:28.0 -0700
@@ -0,0 +1,51 @@
+Description: Fix ftbfs with GCC-10
+
+Author: Ryan Finnie
+Bug-Debian: https://bugs.debian.org/957490
+Forwarded: no
+
+---
+
+--- a/src/raid.h
b/src/raid.h
+@@ -8,7 +8,7 @@
+ * in the source directory.
+ */
+
+-int do_md_install, ndisk, md_bios;
++extern int ndisk, md_bios;
+
+ int raid_setup(void);
+ void raid_final(void);
+--- a/src/bsect.c
b/src/bsect.c
+@@ -54,8 +54,6 @@
+ #endif
+
+
+-int boot_dev_nr;
+-
+ static BOOT_SECTOR bsect,bsect_orig;
+ static MENUTABLE menuparams;
+ static DESCR_SECTORS descrs;
+--- a/src/identify.c
b/src/identify.c
+@@ -19,7 +19,6 @@
+ #include "common.h"
+ #include "cfg.h"
+
+-char *identify;
+ static char *opt;
+ static char *first, *dflt;
+ static int idefault;
+--- a/src/raid.c
b/src/raid.c
+@@ -41,7 +41,7 @@
+ static int raid_bios[MAX_RAID+1];
+ static int device;
+ enum {MD_NULL=0, MD_PARALLEL, MD_MIXED, MD_SKEWED};
+-int do_md_install, ndisk, md_bios;
++int ndisk, md_bios;
+ static char *raid_list[MAX_RAID];
+ static int list_index[MAX_RAID];
+ static int nlist, faulty;
diff -Nru lilo-24.2/debian/patches/series lilo-24.2/debian/patches/series
--- lilo-24.2/debian/patches/series 2019-12-10 14:32:55.0 -0800
+++ lilo-24.2/debian/patches/series 2020-10-28 11:17:12.0 -0700
@@ -6,3 +6,4 @@
08_small-typos-in-manpages.patch
09_fix-manpage-lilo-conf-5.patch
10_fix-manpage-lilo-conf-5.patch
+11_fix-gcc-10.patch
signature.asc
Description: OpenPGP digital signature
Bug#897498: 2ping: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 3.6 returned exit code 13
On 05/02/2018 08:15 PM, Ryan Finnie wrote:
> Hmm, I can't reproduce this. What did the locale look like in the build
> environment? That test specifically checks for UTF-8 in $LANG and is
> skipped if not present.
>
> @unittest.skipUnless(
> (
> os.environ.get('LANG') and
> ('UTF-8' in os.environ.get('LANG'))
> ), 'UTF-8 environment required'
> )
> def test_notice_utf8(self):
> self.run_listener_client(['--notice=UTF-8 \u2603'])
>
> I've tried this with both normal locale for me (en_US.UTF-8), and LANG=C.
Ah, I was able to reproduce with LANG=invalid.UTF-8. I'll change the
test to look for locale.getlocale()[1] == 'UTF-8' (which normalizes an
invalid locale to None), but the rebuild environment should have a valid
locale setup. (Though it would be interesting to have another rebuild
test which specifically tested for invalid locale -> valid locale ->
LANG=C.)
signature.asc
Description: OpenPGP digital signature
Bug#897498: 2ping: FTBFS: dh_auto_test: pybuild --test -i python{version} -p 3.6 returned exit code 13
On 05/02/2018 01:19 PM, Lucas Nussbaum wrote:
> Source: 2ping
> Version: 4.1-1
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20180502 qa-ftbfs
> Justification: FTBFS on amd64
>> ==
>> ERROR: test_notice_utf8 (tests.test_cli.TestCLIStandard)
>> --
>> Traceback (most recent call last):
>> File "/<>/tests/test_cli.py", line 95, in test_notice_utf8
>> self.run_listener_client(['--notice=UTF-8 \u2603'])
>> File "/<>/tests/test_cli.py", line 79, in run_listener_client
>> subprocess.check_output(client_base_opts + client_opts)
>> File "/usr/lib/python3.6/subprocess.py", line 336, in check_output
>> **kwargs).stdout
>> File "/usr/lib/python3.6/subprocess.py", line 403, in run
>> with Popen(*popenargs, **kwargs) as process:
>> File "/usr/lib/python3.6/subprocess.py", line 709, in __init__
>> restore_signals, start_new_session)
>> File "/usr/lib/python3.6/subprocess.py", line 1275, in _execute_child
>> restore_signals, start_new_session, preexec_fn)
>> UnicodeEncodeError: 'ascii' codec can't encode character '\u2603' in
>> position 15: ordinal not in range(128)
Hmm, I can't reproduce this. What did the locale look like in the build
environment? That test specifically checks for UTF-8 in $LANG and is
skipped if not present.
@unittest.skipUnless(
(
os.environ.get('LANG') and
('UTF-8' in os.environ.get('LANG'))
), 'UTF-8 environment required'
)
def test_notice_utf8(self):
self.run_listener_client(['--notice=UTF-8 \u2603'])
I've tried this with both normal locale for me (en_US.UTF-8), and LANG=C.
signature.asc
Description: OpenPGP digital signature
Bug#811469: isomd5sum: FTBFS: cc: error: libcheckisomd5.a: No such file or directory
tags 811469 + moreinfo unreproducible thanks On 01/19/2016 01:00 AM, Chris Lamb wrote: > Source: isomd5sum > Version: 1:1.1.0-1 > Severity: serious > Justification: fails to build from source > User: reproducible-bui...@lists.alioth.debian.org > Usertags: ftbfs > X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org > > Dear Maintainer, > > isomd5sum fails to build from source in unstable/amd64: > > [..] > > for python in python2.7 python3.4 python3.5; do \ > mkdir -p build/$python; \ > /usr/bin/make -C build/$python -f ../../Makefile > VPATH=/home/lamby/temp/cdt.20160119095649.Xd1jzyucCA/isomd5sum-1.1.0 \ > PYTHON=$python pyisomd5sum.so; \ > done > make[2]: Entering directory > '/home/lamby/temp/cdt.20160119095649.Xd1jzyucCA/isomd5sum-1.1.0/build/python2.7' > cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat > -Werror=format-security -Wall -Werror -D_GNU_SOURCE=1 -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -fPIC -I/usr/include/python2.7 > -I/usr/include/x86_64-linux-gnu/python2.7 -c -O -o pyisomd5sum.o > /home/lamby/temp/cdt.20160119095649.Xd1jzyucCA/isomd5sum-1.1.0/pyisomd5sum.c > cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat > -Werror=format-security -Wall -Werror -D_GNU_SOURCE=1 -D_FILE_OFFSET_BITS=64 > -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -fPIC -I/usr/include/python2.7 > -I/usr/include/x86_64-linux-gnu/python2.7 -shared -g -fpic pyisomd5sum.o > libcheckisomd5.a libimplantisomd5.a -Wl,-z,relro -fPIC -o pyisomd5sum.so > cc: error: libcheckisomd5.a: No such file or directory > cc: error: libimplantisomd5.a: No such file or directory > ../../Makefile:37: recipe for target 'pyisomd5sum.so' failed > make[2]: *** [pyisomd5sum.so] Error 1 > make[2]: Leaving directory > '/home/lamby/temp/cdt.20160119095649.Xd1jzyucCA/isomd5sum-1.1.0/build/python2.7' > debian/rules:16: recipe for target 'override_dh_auto_build' failed > make[1]: *** [override_dh_auto_build] Error 2 > make[1]: Leaving directory > '/home/lamby/temp/cdt.20160119095649.Xd1jzyucCA/isomd5sum-1.1.0' > debian/rules:13: recipe for target 'build' failed > make: *** [build] Error 2 Sorry, I cannot reproduce. On an up to date sid amd64 chroot, it builds (and rebuilds) successfully, though with some warnings: [...] for python in python2.7 python3.4 python3.5; do \ mkdir -p build/$python; \ /usr/bin/make -C build/$python -f ../../Makefile VPATH=/home/ryan/tmp/811469/isomd5sum-1.1.0 \ PYTHON=$python pyisomd5sum.so; \ done make[2]: Entering directory '/home/ryan/tmp/811469/isomd5sum-1.1.0/build/python2.7' cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror -D_GNU_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -fPIC -I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7 -c -O -o pyisomd5sum.o /home/ryan/tmp/811469/isomd5sum-1.1.0/pyisomd5sum.c make[2]: Warning: Archive 'libcheckisomd5.a' seems to have been created in deterministic mode. 'libcheckisomd5.o' will always be updated. Please consider passing the U flag to ar to avoid the problem. cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Werror -D_GNU_SOURCE=1 -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 -D_LARGEFILE64_SOURCE=1 -fPIC -I/usr/include/python2.7 -I/usr/include/x86_64-linux-gnu/python2.7 -c -O -o libcheckisomd5.o /home/ryan/tmp/811469/isomd5sum-1.1.0/libcheckisomd5.c ar rv libcheckisomd5.a libcheckisomd5.o ar: creating libcheckisomd5.a a - libcheckisomd5.o make[2]: Warning: Archive 'libcheckisomd5.a' seems to have been created in deterministic mode. 'libcheckisomd5.o' will always be updated. Please consider passing the U flag to ar to avoid the problem. Full build log attached. 20160119-isomd5sum.log.gz Description: application/gzip signature.asc Description: OpenPGP digital signature
Bug#726008: runit: (recompiled) runsv SIGILL on 32-bit PowerPC CPUs
Control: retitle -1 (recompiled) runsv SIGILL on 32-bit PowerPC CPUs
Control: tags -1 + patch
# Justification: FTBFS or unusable runsv binary when recompiled
Control: severity -1 serious
On 11/24/2013 04:29 PM, Ryan Finnie wrote:
So, it's actually a bit more complicated than I first reported. As I
mentioned, 2.1.1-6.2 will FTBFS on today's toolchain on a G4. On a G5,
it will build, but when I ran it on my production setup, it ran stage 2
(a shell script whose last task is runsvdir to run gettys). The gettys
start, but then runit immediately goes on to stage 3, suggesting
runsvdir crashed (though I have not debugged it to confirm).
I built a 2011-01-16 toolchain using snapshot.debian.net (the date the
last Debian build was done) on my G5, and it does build and run
correctly. It also built on the G4, but I didn't test the resulting deb.
So yeah, it sounds like a code generation interaction issue with today's
gcc and/or dietlibc, and is just manifesting itself in different ways on
PowerPC. I'll try to do some more debugging.
So, what's happening is the `diet` binary passthrough is adding
-mpowerpc-gpopt when given -Os. -mpowerpc-gpopt appears to have
optimizations not supported on 32-bit PowerPC[0], namely FCFID.
(Reduced test output below.) This is what was causing SIGILL when
compiling on a G4; it was generating code using FCFID in taia_approx,
which would fail the test suite if built on a G4. If built on a G5, the
test suite would pass, but would the resulting binary would only work on
a 64-bit PowerPC CPU.
Attached is a patch to not let diet do -Os optimization passthrough on
PowerPC, and instead let GCC's own -Os handle it, which seems to work
fine. This is ultimately a bug in diet since it produces unusable
binaries when compiled on a G4, but even if that were fixed, diet's docs
specify -Os optimization is specific to the /host/ CPU, not /target/, so
we still need to handle it specially here.
[0] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24913
g4$ cat test.c
double
int_to_double (int *p)
{
return (double)*p;
}
double
long_long_to_double (long long *p)
{
return (double)*p;
}
g4$ diet -v -Os gcc -c test.c
gcc -include /usr/lib/diet/include/dietref.h -c test.c -isystem
/usr/lib/diet/include -D__dietlibc__ -Os -fomit-frame-pointer
-mpowerpc-gpopt -mpowerpc-gfxopt -fno-stack-protector
g4$ echo disas long_long_to_double | gdb test.o | grep fcfid
0x0028 +4: fcfid f1,f0
g4$ gcc -include /usr/lib/diet/include/dietref.h -c test.c -isystem
/usr/lib/diet/include -D__dietlibc__ -Os -fomit-frame-pointer
-fno-stack-protector
g4$ echo disas long_long_to_double | gdb test.o | grep fcfid
g4$ diet -v gcc -Os -c test.c
gcc -include /usr/lib/diet/include/dietref.h -Os -c test.c -isystem
/usr/lib/diet/include -D__dietlibc__ -fno-stack-protector
g4$ echo disas long_long_to_double | gdb test.o | grep fcfid
diff -u runit-2.1.1/debian/rules runit-2.1.1/debian/rules
--- runit-2.1.1/debian/rules
+++ runit-2.1.1/debian/rules
@@ -14,6 +14,16 @@
CFLAGS =-O2 -Wall -g
endif
+# Work around diet using -mpowerpc-gpopt when itself given -Os, as
+# -mpowerpc-gpopt generates instructions not available on 32-bit
+# PowerPC CPUs (Bug: #726008)
+ifneq (,$(findstring powerpc,$(DIET_ARCHS)))
+ ifneq (,$(findstring powerpc,$(ARCH)))
+CC =diet -v gcc
+CFLAGS =-Os
+ endif
+endif
+
# readdir64, getdents64 seems to be broken in dietlibc on sparc
ifeq (,$(findstring sparc,$(ARCH)))
CFLAGS +=-D_FILE_OFFSET_BITS=64
signature.asc
Description: OpenPGP digital signature
Bug#726008: runit: FTBFS (runsv SIGILL) on 32-bit PowerPC CPUs
On 11/23/2013 06:13 AM, Philipp Kern wrote: so this is tricky. Debian does not have any G4s left. It sounds like a code generation issue. Could you try to use an older gcc to compile this? And I guess it'd be helpful to get a disassembled version of the function, so please do disas taia_approx in gdb and include its output. Compilation will work on Debian infrastructure and the resulting binaries will work everywhere according to your analysis. If it compiles with an older gcc we have a sort of a workaround for people wanting to change the code. So, it's actually a bit more complicated than I first reported. As I mentioned, 2.1.1-6.2 will FTBFS on today's toolchain on a G4. On a G5, it will build, but when I ran it on my production setup, it ran stage 2 (a shell script whose last task is runsvdir to run gettys). The gettys start, but then runit immediately goes on to stage 3, suggesting runsvdir crashed (though I have not debugged it to confirm). I built a 2011-01-16 toolchain using snapshot.debian.net (the date the last Debian build was done) on my G5, and it does build and run correctly. It also built on the G4, but I didn't test the resulting deb. So yeah, it sounds like a code generation interaction issue with today's gcc and/or dietlibc, and is just manifesting itself in different ways on PowerPC. I'll try to do some more debugging. RF signature.asc Description: OpenPGP digital signature
Bug#726008: runit: FTBFS (runsv SIGILL) on 32-bit PowerPC CPUs
Package: runit Version: 2.1.1-6.2 Severity: serious Justification: FTBFS -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On the powerpc arch, runit fails to build, but only when booted from a 32-bit kernel (Mac Mini G4). The build freezes at the test stage: + cd compile + exec make check make[1]: Entering directory `/tmp/runit/runit-2.1.1/runit-2.1.1/compile' ./check-local chpst runit runit-init runsv runsvchdir runsvdir sv svlogd utmpset Checking chpst... Checking runit... Checking runit-init... Checking runsv... Reproducing what the check does reveals a SIGILL exit: $ gdb /tmp/runit/runit-2.1.1/runit-2.1.1/compile/runsv GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as powerpc-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /tmp/runit/runit-2.1.1/runit-2.1.1/compile/runsv...(no debugging symbols found)...done. (gdb) run /tmp/runit/runit-2.1.1/runit-2.1.1/compile/check-tmp Starting program: /tmp/runit/runit-2.1.1/runit-2.1.1/compile/runsv /tmp/runit/runit-2.1.1/runit-2.1.1/compile/check-tmp Program received signal SIGILL, Illegal instruction. 0x10002bc8 in taia_approx () (gdb) starting (gdb) bt #0 0x10002bc8 in taia_approx () #1 0x10002a80 in iopause () #2 0x1894 in main () (gdb) I ran the same build on a similar system with success: powerpc arch, 32-bit userland (Debian does not produce a 64-bit userland), but G5 system so it was a 64-bit kernel. The binaries produced on the G5 system work correctly on the G4 system. Going back to the last Debian buildd of runit on powerpc shows it was built on a 64-bit kernel, most likely a G5, which explains why it did not originally FTBFS: https://buildd.debian.org/status/fetch.php?pkg=runitarch=powerpcver=2.1.1-6.2stamp=1295216762 Kernel: Linux 2.6.26-2-powerpc64 powerpc (ppc64) - -- System Information: Debian Release: 7.1 APT prefers stable APT policy: (500, 'stable') Architecture: powerpc (ppc) Kernel: Linux 3.2.0-4-powerpc Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlJXhroACgkQKZYQqSA+yiX20QCdH+ovFa0YqU6TFn+j8O37A7de F0cAn0Zu8Y6vbc3F7JDJzosM4aCipBIg =GPK4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#477270: linux-2.6: slab-fix-bootstrap-on-memoryless-node.patch causes memory corruption
Package: linux-2.6
Version: 2.6.24-5~etchnhalf.1
Severity: grave
Tags: patch
Justification: causes non-serious data loss
slab-fix-bootstrap-on-memoryless-node.patch (commit
556a169dab38b5100df6f4a45b6553db94c1) in the etchnhalf kernel
introduces a condition that causes memory corruption in UML (as I have
experienced), ES7000 nodes (as Daniel Yeisley mention in the fix I will
mention in a moment), and possibly other scenarios. In my case,
openssl speed rsa1024 returns this:
Doing 1024 bit private rsa's for 10s: 2249 1024 bit private RSA's in 3.91s
Doing 1024 bit public rsa's for 10s: RSA verify failure
12706:error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is
not 01:rsa_pk1.c:100:
12706:error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check
failed:rsa_eay.c:708:
1 1024 bit public RSA's in 1.98s
in SKAS4 immediately, or in SKAS3 after a random amount of uptime.
Though I have yet to notice any real data loss as the result of
corruption.
Commit ec1f5eeeb5a79a0d48036de649a3498da42db565 (attached) fixes this.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-5-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
---BeginMessage---
slab: fix cache_cache bootstrap in kmem_cache_init()
Commit 556a169dab38b5100df6f4a45b6553db94c1 (slab: fix bootstrap on
memoryless node) introduced bootstrap-time cache_cache list3s for all nodes
but forgot that initkmem_list3 needs to be accessed by [somevalue + node]. This
patch fixes list_add() corruption in mm/slab.c seen on the ES7000.
Cc: Mel Gorman [EMAIL PROTECTED]
Cc: Olaf Hering [EMAIL PROTECTED]
Cc: Christoph Lameter [EMAIL PROTECTED]
Signed-off-by: Dan Yeisley [EMAIL PROTECTED]
Signed-off-by: Pekka Enberg [EMAIL PROTECTED]
Signed-off-by: Christoph Lameter [EMAIL PROTECTED]
---
diff --git a/mm/slab.c b/mm/slab.c
index bb4070e..04b308c 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -1481,7 +1481,7 @@ void __init kmem_cache_init(void)
list_add(cache_cache.next, cache_chain);
cache_cache.colour_off = cache_line_size();
cache_cache.array[smp_processor_id()] = initarray_cache.cache;
- cache_cache.nodelists[node] = initkmem_list3[CACHE_CACHE];
+ cache_cache.nodelists[node] = initkmem_list3[CACHE_CACHE + node];
/*
* struct kmem_cache size depends on nr_node_ids, which
@@ -1602,7 +1602,7 @@ void __init kmem_cache_init(void)
int nid;
for_each_online_node(nid) {
- init_list(cache_cache, initkmem_list3[CACHE_CACHE],
nid);
+ init_list(cache_cache, initkmem_list3[CACHE_CACHE +
nid], nid);
init_list(malloc_sizes[INDEX_AC].cs_cachep,
initkmem_list3[SIZE_AC + nid], nid);
---End Message---
Bug#312350: cdimage.debian.org: Release files on netinst/businesscard cds cause apt-config to try to get testing security sources
Package: cdimage.debian.org Severity: critical Justification: root security hole After grabing yesterday's i386 sarge businesscard CD (3.1r0) and installing, during base-config, apt-config thinks the system is testing, and tries to insert use the following sources line: # deb http://security.debian.org/ testing/updates main contrib Since that fails (as currently there is no testing security repository), the user is warned, and apt-setup comments out the line, and continues on with no security updates. Right now this causes any newly installed sarge installation to never grab security fixes without manual intervention, but when http://security.debian.org/dists/testing/updates eventually exists, dist-upgrades will start to try to grab testing security updates for a stable system. After a little digging, the source of the problem seems to be the Release files on the installation CD: dists/sarge/main/binary-i386/Release: Archive: testing Component: main Origin: Debian Label: Debian Architecture: i386 This manifests itself in apt-cache policy, which apt-setup uses to determine whether an installation is stable/testing/unstable. Heck, even reportbug thinks the system is testing (see below). I have reproduced this problem on i386 businesscard and netinst images (haven't tried CD sets or other arches yet). -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#312350: cdimage.debian.org: Release files on netinst/businesscard cds cause apt-config to try to get testing security sources
Looks like the announcement to debian-devel-announce was sent as I was typing this bug report. Doh. RF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
