Bug#1072522: cozy: File conflict with blackbox-terminal/0.14.0-3: /usr/share/icons/hicolor/scalable/actions/settings-symbolic.svg
Package: cozy Severity: serious Version: 1.3.0-2 Control: affects -1 blackbox-terminal Hi Manuel, installing cozy fails if blackbox-terminal (at least at version 0.14.0-3) is also installed due to a file conflict at /usr/share/icons/hicolor/scalable/actions/settings-symbolic.svg (and potentially further files as dpkg always only reports the first occurrence): Preparing to unpack .../11-cozy_1.3.0-2_all.deb ... Unpacking cozy (1.3.0-2) ... dpkg: error processing archive /tmp/apt-dpkg-install-RrJabH/11-cozy_1.3.0-2_all.deb (--unpack): trying to overwrite '/usr/share/icons/hicolor/scalable/actions/settings-symbolic.svg', which is also in package blackbox-terminal 0.14.0-3 The probably easiest and cleanest way to fix this is to rename the file. Best way would be if neither package would use such a generic file name. (X-Debbugs-Cc'ed the blackbox-terminal maintainers.) -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled
Bug#1067025: dokuwiki: Please package the new upstream version 2024-02-06a "Kaos"
Hi Daniel, Daniel Baumann wrote one month ago: > any news or ETA on this? No. I can work on this earliest after the next Lintian release. (Which I hope to get done during Pentecoste.) > do you need help? I fear so. Actually I've taken over Debian's dokuwiki after I NMUed it because it was horribly out of date and had open RC bugs. But I currently can't invest as much time in Debian as I probably should and there are more pressing issues like a new Lintian release and some RC bugs in other packages of mine. Not sure about Anton. Haven't heard from him in a while with regards to DokuWiki, but he seems generally active in Debian. So if you want to join Debians DokuWiki team as another uploader, feel free to add yourself and work on the package. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1071199: O: wicd -- wired and wireless network manager written in Python
Package: wnpp Severity: normal X-Debbugs-Cc: w...@packages.debian.org, txg...@gmail.com, z...@fsfe.org, a...@bastelmap.de, b...@debian.org Control: affects -1 + src:wicd Let's face it, neither me nor Giap Tran haven't done anything on wicd since 2019 — beside moving it from unstable to experimental due to the rather incomplete upstream state of the Python 3 port. I even forgot to push a commit for years. (I just pushed things now and merged Bastian's changes from Salsa. → https://salsa.debian.org/debian/wicd) Looking at https://git.launchpad.net/wicd/log/ it seems that since then yet another dev (Andreas Messer) tried himself on wicd upstream and stopped again. (The last dev I had contact with was Guido Serra.) (I've X-Debbugs-Cc'ed all mentioned persons.) I actually haven't looked yet if the code as of October 2022 (just documentation changes afterwards) actually works as the last device where I used wicd on for wifi connections (an Asus EeePC 900) got very unreliable due to fan failure. And I haven't fixed that yet. The package is currently only available in Debian Experimental (see https://tracker.debian.org/pkg/wicd) and its description is: Wicd is a general-purpose network configuration server which aims to provide a simple but flexible interface for connecting to networks. Its features include: * wide variety of settings; * ability to connect to (and maintain profiles for) both wired and wireless networks; * support for many encryption schemes, including WEP, WPA, WPA2 and custom schemes; * wireless-tools compatibility; * tray icon showing network activity and signal strength; * lack of GNOME dependencies (although it does require GTK+), making it easy to use in Xfce, Fluxbox, Openbox, Enlightenment, etc. In case there's nobody stepping up for adoption within a month or two or so, I'll probably request removal from Debian. It's in bad shape for long enough and I have enough other packages which need my time.
Bug#1071007: sherlock has an undeclared file conflict on /usr/lib/python3/dist-packages/__init__.py
Control: affects -1 - pycrc Control: clone -1 -2 -3 Control: reassign -2 pycrc 0.10.0-2 Control: retitle -1 sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py Control: retitle -2 pycrc: Must not ship /usr/lib/python3/dist-packages/__init__.py Control: reassign -3 lintian 2.117.0 Control: severity -3 wishlist Control: retitle -3 lintian: Should warn if a package ships /usr/lib/python*/dist-packages/__init__.py Hi Helmut, Helmut Grohne wrote: > This bug report has been automatically filed with no human intervention. > The source code is available at https://salsa.debian.org/helmutg/dumat. Ok, this explains why you didn't notice that this is actually a separate bug in each of these packages. :-) > sherlock has an undeclared file conflict. This may result in an unpack > error from dpkg. > > The file /usr/lib/python3/dist-packages/__init__.py is contained in the > packages > * pycrc/0.10.0-2 as present in trixie|unstable > * sherlock/0.14.3+git20240511.b83f5be-1 as present in unstable My Python foo isn't that well versed, but as far as I understand actually no package must ship an __init__.py file at (more or less) root level (i.e. directly in /usr/lib/python*/dist-packages/ or — since usrmerge also — /lib/python*/dist-packages/). Accordingly cloning the bug report for pycrc as it must not ship that file either. And cloning it a second time as wishlist bug report against Lintian so that these cases get caught much earlier. Might be implemented as extension of python-module-has-overly-generic-name (as the module name seems the empty string in that case ;-) which so far already catches cases like e.g. /usr/lib/python3/dist-packages/doc/__init__.py. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1070295: cgroupfs-mount: Fails to upgrade or remove if elogind is running: "umount: /sys/fs/cgroup/elogind: target is busy."
Package: cgroupfs-mount Severity: serious Version: 1.4+nmu1 Hi, cgroupfs-mount fails to upgrade from 1.4 to 1.4+nmu1 for me (elogind + sysvinit) as follows: Setting up cgroupfs-mount (1.4+nmu1) ... Unmounting cgroupfs hierarchyumount: /sys/fs/cgroup/elogind: target is busy. invoke-rc.d: initscript cgroupfs-mount, action "restart" failed. dpkg: error processing package cgroupfs-mount (--configure): installed cgroupfs-mount package post-installation script subprocess returned error exit status 1 Trying to remove the package fails in the same way: Removing cgroupfs-mount (1.4+nmu1) ... Unmounting cgroupfs hierarchyumount: /sys/fs/cgroup/elogind: target is busy. invoke-rc.d: initscript cgroupfs-mount, action "stop" failed. dpkg: error processing package cgroupfs-mount (--remove): installed cgroupfs-mount package pre-removal script subprocess returned error exit status 1 Stopping elogind before trying to unmount /sys/fs/cgroup/elogind solves the issue. P.S.: Given that Christian's NMU doesn't even touch the maintainer scripts, I suspect that this issue is also present in version 1.4. I though didn't notice it before then, so it might be related to recent elogind changes, hence Cc'ing the Debian Init System Diversity Team, too. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.12-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled
Bug#1066438: backuppc-rsync: FTBFS: lib/compat.c:154:16: error: too few arguments to function ‘gettimeofday’
Control: tag -1 + patch Hi Andreas, Andreas Hasenack wrote: > This fixes the build: > > --- a/configure.ac > +++ b/configure.ac > @@ -852,6 +852,7 @@ fi > > AC_CACHE_CHECK([if gettimeofday takes tz > argument],rsync_cv_HAVE_GETTIMEOFDAY_TZ,[ > AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include > +#include > #include ]], [[struct timeval tv; exit(gettimeofday(, > NULL));]])],[rsync_cv_HAVE_GETTIMEOFDAY_TZ=yes],[rsync_cv_HAVE_GETTIMEOFDAY_TZ=no])]) > if test x"$rsync_cv_HAVE_GETTIMEOFDAY_TZ" != x"no"; then > AC_DEFINE(HAVE_GETTIMEOFDAY_TZ, 1, [Define to 1 if gettimeofday() > takes a time-zone arg]) Thanks a lot! I was always trying to add that include line into actual C files. It didn't occur to me that I need to add it to configure. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1068043: BinNMU 1.11-1+b1 depends on both, libmspack0 and libmspack0t64, and is hence uninstallable (at least on armhf)
Package: cabextract Version: 1.11-1 Severity: serious X-Debbugs-Cc: a...@debian.org >From aptitude's dependency view on armhf: iFA (pin --\ cabextract 0 72.7 kB 1.11-1 1.11-1+b1 --\ Depends (3) --- libc6 (>= 2.34) --- libmspack0 (>= 0.9.1-1) --- libmspack0t64 (>= 0.4) (UNSATISFIED) As libmspack0t64 breaks libmspack0 they can't be installed together. This is likely caused by hardcoding a dependency on libmspack0 in debian/control: https://sources.debian.org/src/cabextract/1.11-1/debian/control/#L10 -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'testing'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: armhf (armv7l) Kernel: Linux 6.6.15-armmp-lpae (SMP w/4 CPU threads) Kernel taint flags: TAINT_CRAP Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages cabextract depends on: ii libc6 2.37-15.1 ii libmspack0 0.11-1 cabextract recommends no packages. cabextract suggests no packages. -- no debconf information
Bug#1067534: Manual deps on lib* need updating for the time64 transition
Control: tag -1 + pending Hi Andrey, thanks for bringing this up. Andrey Rakhmatullin wrote: > All subpackages have manually specified deps like libqt5core5a, all of them > need updating to lib*t64 ones. I though disagree with the phrase "all subpackages". As far as I can see there are solely two dependencies of only one binary package (namely qutebrowser) affected: libqt5core5a and libqt5dbus5. I neither see a package called libqt5webkit5t64 nor a package called. libqt5webenginecore5t64. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1067110: xymon: Upgrade process hangs with zombie in postinst
Package: xymon Severity: serious Version: 4.3.30-2 Tags: pending Due to a superfluous leftover debconf initialisation in xymon.postinst not being removed with the cleaning up of old transition code, upgrading xymon (but not xymon-client) resulted in a hanging upgrade process as well as in a xymon.postinst zombie process. A fix is committed locally and I'll upload soon, but it still needs some more testing how to handle further, but more harmless leftovers from that incomplete code removal. Filing this bug mostly due to several transitions (well, mostly t64 transitions) being listed on https://tracker.debian.org/pkg/xymon to make clear why an upload is currently necessary. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.13-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled
Bug#1065435: [Aptitude-devel] Bug#1065435: aptitude: FTBFS on armhf and armel (probably -Werror=implicit-function-declaration related)
Hi Steinar and Christoph,
Steinar H. Gunderson wrote:
> struct timeval
> {
> #ifdef __USE_TIME_BITS64
> __time64_t tv_sec;/* Seconds. */
> __suseconds64_t tv_usec; /* Microseconds. */
> #else
> __time_t tv_sec; /* Seconds. */
> __suseconds_t tv_usec;/* Microseconds. */
> #endif
> };
> #endif
>
> But the fix is straightforward, no? Just change the offending test to
> something like
>
> CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
>
> and it should work no matter what type c.tv_usec is. Or, if you prefer
> brace-initialization (which would prevent you from ever writing in a too-big
> value, like 999 or something):
>
> CPPUNIT_ASSERT_EQUAL(decltype(c.tv_usec){99}, c.tv_usec);
>
> /* Steinar */
Thanks for the patch!
Christoph Biedl wrote:
> Therefore, any progress on this?
Not before the patch (hints) from Steinar. (Although there's also a
recent merge request mentioning some FTBFS fix, but it's unclear if
this issue is meant or something else. Will have to look into it,
too.)
> Do you need help?
I'm happy about any help with aptitude as we currently don't really
have any active upstream developer. C++ is not something that I'm
particularly good at.
> I didn't get very far at a first glance, aptitude's build
> dependencies are currently uninstallable, at least in arm{el,hf}.
I got my sid armhf Raspi fixed today (it stopped booting a while ago,
seemed to have been a usrmerge related issue), so I can now test
patches locally on armhf again.
Will try to get an upload done based on Steinar's patch instructions
soon-ish. But I first need to get the Raspi uptodate with the current
state of Sid.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1065554: [Aptitude-devel] Bug#1065554: aptitude: the TUI silently breaks a "Recommends"
Hi Vincent, Vincent Lefevre wrote: > > I've seen also already seen this, but so far it always was for a > > reason here: > > > > * On multiarch hosts, amd64 and i386 weren't in sync and there were > > Breaks against any version not being the same version. > > This is not a multiarch host yet. That was already mentioned in the original bug report's footer, yes. Otherwise I would have asked. :-) > > * An initial solution pulls in a package which Breaks the package in > > question and that pulled in package later (manually or due to other > > conflicts by manual changes) gets set to "keep uninstalled", but the > > effect of its Breaks is not reverted. > > I cannot see any Breaks of at-spi2-core. Yes, I've checked that, too. That's also why I mentioned them: These cases don't apply and hence it's NOT one of the two common cases, where it's more obvious (albeit not necessarily good) that this happens. [I removed the additional details, but they might come in handy later, so thanks!] > > But in your case neither of that seems to be case. So it indeed might > > be a bug in this case. > > Do you need the bundle? Actually that would be interesting, as I have a vague idea how it might have been triggered and would like to experiment a bit if I can find a simpler reproducer. BTW, do I remember right that you have APT::Install-Recommends set "false"? Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1065554: [Aptitude-devel] Bug#1065554: aptitude: the TUI silently breaks a "Recommends"
Hi Vincent, Vincent Lefevre wrote: > The aptitude TUI silently breaks a "Recommends": I've seen also already seen this, but so far it always was for a reason here: * On multiarch hosts, amd64 and i386 weren't in sync and there were Breaks against any version not being the same version. * An initial solution pulls in a package which Breaks the package in question and that pulled in package later (manually or due to other conflicts by manual changes) gets set to "keep uninstalled", but the effect of its Breaks is not reverted. But in your case neither of that seems to be case. So it indeed might be a bug in this case. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1065435: aptitude: FTBFS on armhf and armel (probably -Werror=implicit-function-declaration related)
Source: aptitude
Version: 0.8.13-5
Severity: serious
Tags: ftbfs
X-Debbugs-Cc: a...@debian.org, z...@debian.org
Citing from https://buildd.debian.org/status/package.php?p=aptitude:
BinNMU changelog for aptitude on amd64, arm64, armel, armhf, i386, mips64el,
ppc64el, riscv64, s390x, alpha, hppa, hurd-i386, ia64, loong64, m68k, powerpc,
ppc64, sh4, sparc64 and x32:
Rebuild for time_t
Tail of log for aptitude on armel:
/usr/include/cppunit/TestAssert.h:161:6: note: candidate: ‘template
void CppUnit::assertEquals(const T&, const T&, SourceLine, const std::string&)’
161 | void assertEquals( const T& expected,
| ^~~~
/usr/include/cppunit/TestAssert.h:161:6: note: template argument
deduction/substitution failed:
../../tests/test_misc.cc:187:5: note: deduced conflicting types for parameter
‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long int’})
187 | CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
| ^
make[3]: *** [Makefile:869: test_misc.o] Error 1
make[3]: Leaving directory '/<>/build/tests'
make[2]: *** [Makefile:1169: check-am] Error 2
make[2]: Leaving directory '/<>/build/tests'
/bin/sh: 1: ./cppunit_test: not found
make[1]: *** [debian/rules:39: override_dh_auto_test-arch] Error 127
make[1]: Leaving directory '/<>'
make: *** [debian/rules:22: binary-arch] Error 2
Tail of log for aptitude on armhf:
/usr/include/cppunit/TestAssert.h:161:6: note: candidate: ‘template
void CppUnit::assertEquals(const T&, const T&, SourceLine, const std::string&)’
161 | void assertEquals( const T& expected,
| ^~~~
/usr/include/cppunit/TestAssert.h:161:6: note: template argument
deduction/substitution failed:
../../tests/test_misc.cc:187:5: note: deduced conflicting types for parameter
‘const T’ (‘long int’ and ‘__suseconds64_t’ {aka ‘long long int’})
187 | CPPUNIT_ASSERT_EQUAL(static_cast(99), c.tv_usec);
| ^
make[3]: *** [Makefile:869: test_misc.o] Error 1
make[3]: Leaving directory '/<>/build/tests'
make[2]: *** [Makefile:1169: check-am] Error 2
make[2]: Leaving directory '/<>/build/tests'
/bin/sh: 1: ./cppunit_test: not found
make[1]: *** [debian/rules:39: override_dh_auto_test-arch] Error 127
make[1]: Leaving directory '/<>'
make: *** [debian/rules:22: binary-arch] Error 2
Given the time and the architectures failing, this is probably related
to dpkg switching on -Werror=implicit-function-declaration on these
architectures (see https://bugs.debian.org/1065371 and a good summary
of a similar case in https://bugs.debian.org/1065431 against lintian).
-- Package-specific info:
Terminal: xterm-256color
$DISPLAY is set.
which aptitude: /usr/bin/aptitude
aptitude version information:
aptitude 0.8.13
Compiler: g++ 13.2.0
Compiled against:
apt version 6.0.0
NCurses version 6.4
libsigc++ version: 2.12.1
Gtk+ support disabled.
Qt support disabled.
Current library versions:
NCurses version: ncurses 6.4.20240113
cwidget version: 0.5.18
Apt version: 6.0.0
aptitude linkage:
linux-vdso.so.1 (0x7ffc0a3eb000)
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
(0x7f8fca645000)
libapt-pkg.so.6.0 => /lib/x86_64-linux-gnu/libapt-pkg.so.6.0
(0x7f8fc9e0)
libncursesw.so.6 => /lib/x86_64-linux-gnu/libncursesw.so.6
(0x7f8fca1c6000)
libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6
(0x7f8fca191000)
libsigc-2.0.so.0 => /lib/x86_64-linux-gnu/libsigc-2.0.so.0
(0x7f8fca188000)
libcwidget.so.4 => /lib/x86_64-linux-gnu/libcwidget.so.4
(0x7f8fca084000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0
(0x7f8fc9c8a000)
libboost_iostreams.so.1.83.0 =>
/lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 (0x7f8fca06a000)
libxapian.so.30 => /lib/x86_64-linux-gnu/libxapian.so.30
(0x7f8fc9a0)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6
(0x7f8fc960)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f8fc9921000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x7f8fca03b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f8fc941e000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f8fc9c85000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x7f8fc9c8)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f8fc9c61000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0
(0x7f8fc990e000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f8fc98d1000)
liblz4.so.1 => /lib/x86_64-linux-gnu/liblz4.so.1 (0x7f8fc98ab000)
libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x7f8fc935d000)
libudev.so.1 => /lib/x86_64-linux-gnu/libudev.so.1 (0x7f8fc9878000)
libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0
(0x7f8fc927b000)
libgcrypt.so.20 =>
Bug#1012289: RFH: lintian -- Debian package checker
Hi Bill, Bill Allombert wrote: > By the way, what happened to lintian.debian.org ? Seems as if someone (not me, just noticed it today when "private/refresh-data" failed…) pulled the plug on at least the DNS name. Probably because it hasn't been updated since Felix' try to rewrite it, which AFAIK was never finished, but the old thing also no more worked. (There's probably a lot of legacy code in "lib/Lintian/Output" related to one of these two website generations, maybe even both.) IMHO it's generally a good thing, except that it would have been better to redirect it to the according UDD pages instead. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1012289: RFH: lintian -- Debian package checker
Hi, Bastien Roucariès wrote: > Le dimanche 4 février 2024, 14:02:58 UTC Bill Allombert a écrit : > > Areyou still available as lintian maintainer ? It sure would need an upload. > I can > > I am doing some pull request update By coincidence I started to work on Lintian today (well, actually yesterday) again, too, but saw these two mails only afterwards. Mostly fixed the systemd/udev/usrmerge related test suite failures as well as merged some of the open merge requests. Let's try together to get a release done soon. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1000044: ccze: depends on obsolete pcre3 library
Control: tag -1 + pending Hi Yavor, sorry for the late reply, but I only managed to continue on this now as I'm on holidays now. Yavor Doganov wrote: > Here it is -- no memory leaks and I could not obtain crash or abort > with the logs I've tested. Note that while my original patch > introduced some leaks, it also fixes some in the original code. Thanks again for these patches! They indeed work much better than before this set of patches. I though got another crash on this line: Dec 24 06:43:16 c6 kernel: net_ratelimit: 1 callbacks suppressed I think I managed to fix it and will also upload, but I'd be happy for a short review of yours: Backtrace is as follows: Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `ccze -A'. Program terminated with signal SIGABRT, Aborted. #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) bt #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x7fe6a065715f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x7fe6a0609472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x7fe6a05f34b2 in __GI_abort () at ./stdlib/abort.c:79 #4 0x7fe6a05f41ed in __libc_message (fmt=fmt@entry=0x7fe6a076678c "%s\n") at ../sysdeps/posix/libc_fatal.c:150 #5 0x7fe6a0660a75 in malloc_printerr (str=str@entry=0x7fe6a076422c "free(): invalid pointer") at ./malloc/malloc.c:5658 #6 0x7fe6a06627f4 in _int_free (av=, p=, have_lock=have_lock@entry=0) at ./malloc/malloc.c:4432 #7 0x7fe6a066516f in __GI___libc_free (mem=) at ./malloc/malloc.c:3367 #8 0x7fe6a05b6467 in ccze_syslog_process (offsets=0x558834ff3170) at ./src/mod_syslog.c:97 #9 ccze_syslog_handle (str=, length=, rest=0x7fffc99b28c8) at ./src/mod_syslog.c:134 #10 0x558833642a2f in ccze_plugin_run (pluginset=pluginset@entry=0x558834fefd30, subject=subject@entry=0x558834fe59c0 "Dec 24 06:43:16 c6 kernel: net_ratelimit: 1 callbacks suppressed", subjlen=64, rest=rest@entry=0x7fffc99b28c8, type=type@entry=CCZE_PLUGIN_TYPE_FULL, handled=handled@entry=0x7fffc99b28a4, status=0x7fffc99b28a8) at ./src/ccze-plugin.c:327 #11 0x558833640616 in ccze_main () at ./src/ccze.c:706 #12 main (argc=, argv=) at ./src/ccze.c:756 Commenting out the "free (process);" in line 97 of src/mod_syslog.c via the pcre2.patch seems to have fixed that: https://salsa.debian.org/debian/ccze/-/commit/11b90155a6559e2121836483c2acacf35d8fca3b Do you think that change would have any other impact? At least no more crashes, so I'll upload anyway. But if you find some drawbacks, please tell me. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#999921: xymon: depends on obsolete pcre3 library
Hi Yavor, Yavor Doganov wrote: > Please find a patch which I've been testing for a while with no ill > effects AFAICT. However, I'm not familiar at all with this package so > it's possible that I've missed something. I also couldn't test all > available functionality. Thanks a lot also for that patch! I have enough servers and clients around to test the patch. (And thanks in general that you seemingly crawl through all these annoying PCRE3→2 bugs and provide patches. Much appreciated!) Upstream said, they're having it on their roadmap, too, but I haven't seen anything in that direction yet in the upstream SVN repo. (And I'm tracking trunk.) So I'll also forward the patch there, maybe first notify them, then test it and then forward it. > Unfortunately the patch does not apply cleanly to the latest upstream > release (4.4-alpha) but I am ready and willing to rebase it, whenever > you decide to package it. Just let me know. Also on my todo list, but that's first planned for experimental, not yet unstable. So I wouldn't say no to a rebased patch set for 4.4alpha as that's where upstream is currently working on. Will likely work on these (and ccze) over the holidays. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1058942: gawk: Inconsistent parsing of "\|\|" and "||" (two pipes) in -F option
Package: gawk
Version: 1:5.2.1-2 1:5.1.0-1
Hi,
I initially ran into this issue on Debian 11 Bullseye, but I can also
reproduce it in Debian Unstable as of now:
We do have logs which separate fields with "||", i.e. two pipe
characters. (Yeah, likely not ideal, but that's given. :-)
With mawk I can parse them easily:
$ echo 'a||b' | mawk -F'\|\|' '{print $1"X"$2}'
aXb
(backslashes because multicharacter $FS is considered to be a regular
expression and hence the special character pipe needs to be
escaped. mawk also argues otherwise — IMHO correctly.)
gawk though behaves strange and especially inconsistently:
$ echo 'a||b' | gawk -F'\|\|' '{print $1"X"$2}'
gawk: warning: escape sequence `\|' treated as plain `|'
a||bX
Ok, so '\|' should be written as just '|'? Unexpected, but ok. Let's do
that:
$ echo 'a||b' | gawk -F'||' '{print $1"X"$2}'
a||bX
No more argues, but the output is as wrong as before. It's also not that
it treated the pipe as regular expression (in which case it would
probably match any empty string twice and should probably output
something like "a|").
I though would have kinda expected that "||" is considered to be a
regular expression and hence would require the backslash.
Using e.g.
$ echo 'a||b' | gawk 'FS="\|\|" {print $1"X"$2}'
gawk: cmd. line:1: warning: escape sequence `\|' treated as plain `|'
a||bX
seems to make no difference.
What does work as expected with gawk (and mawk) is though this:
$ echo 'a||b' | gawk -F'[|][|]' '{print $1"X"$2}'
aXb
Interestingly, if only a single pipe character is used as delimited it
works as expected again:
$ echo 'a|b' | gawk -F'\|' '{print $1"X"$2}'
gawk: warning: escape sequence `\|' treated as plain `|'
aXb
$ echo 'a|b' | gawk -F'|' '{print $1"X"$2}'
aXb
So the bug seems to only appear if at least two pipes are used as
delimiter. (It behaves the same way with three pipes as with two pipes.)
Part of the bug or a separate bug might be that it argues even in the
two character version (hence expected to be a regexp) about "\|" being
interpreted as plain "|" which from my point of view is only correct in
the one-letter (plus espaping) variant '\|', but not for '\|\|'.
Counter examples:
$ echo 'afbgc' | awk -F 'f|g' '{print $1, $2, $3}'
a b c
$ echo 'afbgc' | awk -F 'f\|g' '{print $1, $2, $3}'
awk: warning: escape sequence `\|' treated as plain `|'
a b c
$ echo 'af|gc' | awk -F 'f\|g' '{print $1, $2}'
awk: warning: escape sequence `\|' treated as plain `|'
a |
In the last example it IMHO should not have replaced the "\|" with just
a "|" which is also not "plain" but a special character which was meant
to be escaped. The wanted output was "a c".
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'),
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1,
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages gawk depends on:
ii libc6 2.37-13
ii libgmp10 2:6.3.0+dfsg-2
ii libmpfr6 4.2.1-1
ii libreadline8 8.2-3
ii libsigsegv2 2.14-1
gawk recommends no packages.
Versions of packages gawk suggests:
pn gawk-doc
-- no debconf information
Bug#1057688: [Aptitude-devel] Bug#1057688: aptitude: Stray input on window click when running under tmux
Hi Sven,
Sven Joachim via Aptitude-devel wrote:
> Debian ncurses maintainer here, bringing the ncurses upstream developer
> into the loop.
Thanks for that!
> In addition to aptitude, mouse support is also broken in dialog(1) under
> tmux.
>
> > Maybe this bug should instead be assigned to ncurses?
>
> Probably should be reassigned to ncurses-base, but let's first see what
> Thomas has to say about it.
JFTR: If it turns out as a bug which indeed needs not (only) to be
fixed in ncurses, it's likely not in aptitude but in libcwidget4. (The
separation stems from times where aptitude still also had a GUI
frontend.)
P.S.: Thanks to Thomas for fixing the recent ncurses issues (htop,
etc.) so quickly at upstream!
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1000044: ccze: depends on obsolete pcre3 library
Control: tag -1 - pending Hi Yavor, Yavor Doganov wrote: > Please find a patch attached (I was not able to test all plugins). Thanks again for that huge patch. I've pushed it and several other changes to Salsa. A local test on my /var/log/syslog immediately ran into a segfault, though, so I guess, that's one of the plugins you couldn't test. Culprit is this line, actually the first line in my current /var/log/syslog: Dec 3 06:38:28 c6 syslog-ng[26651]: Configuration reload request received, reloading configuration; Example for a minimal reproducer: $ echo 'Dec 3 06:38:28 c6 syslog-ng[26651]: Configuration reload request received, reloading configuration;' | ccze -A free(): invalid pointer [1]17679 done echo | 17680 IOT instruction (core dumped) ccze -A A backtrace of the core dump gave the following output: #0 __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 #1 0x77d1c15f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78 #2 0x77cce472 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 #3 0x77cb84b2 in __GI_abort () at ./stdlib/abort.c:79 #4 0x77cb91ed in __libc_message (fmt=fmt@entry=0x77e2b78c "%s\n") at ../sysdeps/posix/libc_fatal.c:150 #5 0x77d25a75 in malloc_printerr (str=str@entry=0x77e2922c "free(): invalid pointer") at ./malloc/malloc.c:5658 #6 0x77d277f4 in _int_free (av=, p=, have_lock=have_lock@entry=0) at ./malloc/malloc.c:4432 #7 0x77d2a16f in __GI___libc_free (mem=mem@entry=0x55566c08) at ./malloc/malloc.c:3367 #8 0x77c7b393 in ccze_syslog_process (offsets=0x5556e170) at ./src/mod_syslog.c:63 #9 ccze_syslog_handle (str=, length=, rest=0x7fffd9a8) at ./src/mod_syslog.c:126 #10 0xaa1f in ccze_plugin_run (pluginset=pluginset@entry=0x5556ad30, subject=subject@entry=0x555609c0 "Dec 3 06:38:28 c6 syslog-ng[26651]: Configuration reload request received, reloading configuration;", subjlen=100, rest=rest@entry=0x7fffd9a8, type=type@entry=CCZE_PLUGIN_TYPE_FULL, handled=handled@entry=0x7fffd984, status=0x7fffd988) at ./src/ccze-plugin.c:327 #11 0x8696 in ccze_main () at ./src/ccze.c:706 #12 main (argc=, argv=) at ./src/ccze.c:753 Seems to be the "free(process)" in line 63 of src/mod_syslog.c. But neither commenting it out (which might have caused a memory leak) nor replacing it with "pcre2_substring_free(process)" (as present elsewhere shortly afterwards is this file) did fix the segfault. It just started to look different, so the latter might be part of the fix, but in that case it's is not the complete fix . I currently assume that any line starting with a date and then a process name with process id in brackets will trigger this as it's the parsing of the process id inside the brackets where the crash happens. So in case you have an idea how to fix this, I'd be happy. (As mentioned elsewhere already, this migration is a huge PCRE upstream mess and I'm glad about any help as this is not my only package affected.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1034398: ccze: Project homepage on github no longer exists / abandoned upstream?
Control: tag -1 + pending
Hi Nika,
Michael Prokop wrote:
> https://github.com/madhouse/ccze throws a 404,
Yeah, I know. I think this was a reaction on Microsoft buying Github.
> maybe https://git.madhouse-project.org/archive/ccze
> is the proper place to refer to nowadays,
Thanks for that link! I knew it was on
https://git.madhouse-project.org/algernon/ccze before and then
suddenly vanished there, too, which was very weird …
> but it looks like the project was abandoned / is unmaintained from
> upstream?
… because when I took over the package from Gergely (upstream and
previous package maintainer), he promised me to still fix severe
issues like security issues. Completely removing the source code repo
did not fit into that statement. So it's just another case showing
that changing URLs for repos is a really bad idea. But I guess Forgejo
doesn't have a repo flag "archived" so Gergely helped himself that
way.
Wanted to contact him for the PCRE2 migration (and my motivation on
this was rather low as that whole PCRE2 "migration" was a real mess at
PCRE upstream), but Yavor was quicker with sending in a patch.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1000044: ccze: depends on obsolete pcre3 library
Hi Yavor, Yavor Doganov wrote: > Please find a patch attached Thanks a lot! > (I was not able to test all plugins). Better than nothing. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1057044: xymon: ntpdate no longer supports the -p option
Hi Carsten, Carsten Leonhardt wrote: > ntpdate emits a warning when called with the -p option. I've attached a > patch to drop that option from xymonserver.cfg. Thanks. Sounds kinda familiar. > If you prefer, I can also commit directly to salsa. Fine for me, thanks! > Subject: [PATCH] xymon: update xymonserver.cfg: ntpdate no longer > supports the "-p" option (cf. #926877). Oh, #926877 was my bug report. Maybe that's why it sounds familiar. %-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1042845: libembperl-perl: FTBFS with Perl 5.38: test failures
Hi,
gregor herrmann wrote:
> On Tue, 01 Aug 2023 22:41:12 +0200, Axel Beckert wrote:
> > > I assume the diagnostics have changed again and it's just the tests that
> > > need adjusting, but I haven't checked properly.
> > Will look into it, but may take a while.
>
> Now would be a good time :)
Yep. Got mail about the auto removal a week ago or so. (I'm subscribed
via rss2email to my Debian Maintainer Dashboard.)
> As the perl 5.38 transition is immanent, the bug's severity has been
> raised to serious; and bot dam and me failed to understand the test
> system so I guess this is now your turn :)
Upstream might have been faster this time than I am these days: 3.0.0
is out: https://metacpan.org/dist/Embperl
http://matrix.cpantesters.org/?dist=Embperl+3.0.0 doesn't look too
well for 5.38, though. I will see.
Most if not all our changes seem to have been merged according to the
changelog.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1055463: sysvinit-core: Please entirely remove SysVinit
Hi, Patrik Schindler wrote: > After I've upgraded my server to Bookworm today, I'll now do a rollback from > backup because of numerous issues with many services not coming up > anymore. Works fine for me, especially in Bookworm. Running servers as well as workstations with it. > For this reason, I propose to remove SysVinit completely from the next Debian > release, You are trolling us, right? The opposite is the proper implication from what you've described. Debian is about choice, not about spoon-feeding users and leaving them without choice in many places like at least one well-known Debian derivative does. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1054108: apt-listchanges: Shows ancient NEWS for falkon and src:libdrm packages
Package: apt-listchanges
Version: 4.2
Severity: normal
Hi Jonathan,
two other cases of ancient NEWS items being show, this time with
apt-listchanges 4.2 and when upgrading falkon from 23.08.1-1 to
23.08.2-1 and multiple src:libdrm packages from 2.4.115-1 to 2.4.116-1:
$ dpkg -l 'libdrm*'
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Tr
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=---===
ii libdrm-amdgpu1:amd64 2.4.115-1amd64Userspace interface
ii libdrm-amdgpu1:i386 2.4.115-1i386 Userspace interface
ii libdrm-common 2.4.115-1all Userspace interface
ii libdrm-dev:amd64 2.4.115-1amd64Userspace interface
ii libdrm-intel1:amd64 2.4.115-1amd64Userspace interface
ii libdrm-intel1:i3862.4.115-1i386 Userspace interface
ii libdrm-nouveau2:amd64 2.4.115-1amd64Userspace interface
ii libdrm-nouveau2:i386 2.4.115-1i386 Userspace interface
ii libdrm-radeon1:amd64 2.4.115-1amd64Userspace interface
ii libdrm-radeon1:i386 2.4.115-1i386 Userspace interface
ii libdrm2:amd64 2.4.115-1amd64Userspace interface
ii libdrm2:i386 2.4.115-1i386 Userspace interface
ii libdrm2-dbgsym:amd64 2.4.115-1amd64debug symbols for l
I got shown three NEWS entries, one from a few days ago (correct), one
from 2018 (falkon) and one from 2007, seemingly for libdrm2, but I
suspect that at least the multiarch setup (libdrm2:amd64 vs
libdrm2:i386, see above) might have played a role:
--- News for falkon ---
falkon (3.0.0-3) unstable; urgency=medium
===
Falkon is a replacement for the former package Qupzilla. If you, or some
other user of this computer were using Qupzilla formerly, it is possible
to restore bookmarks which were gathered with Qupzilla, so they become
available for Falkon users.
Here is a method for user John Doe, in shell language:
# USER_HOME=/home/johnDoe;
# cp ${USER_HOME}/.config/qupzilla/profiles/default/bookmarks.json \
${USER_HOME}/.config/falkon/profiles/defaults/
Please notice that doing so will erase any previous file
${USER_HOME}/.config/falkon/profiles/defaults/bookmarks.json
-- Georges Khaznadar Tue, 03 Apr 2018 18:26:55 +0200
[Inbetween was NEWS for xca 2.5.0-1 which was current as I upgraded from
2.4.0-2+b1]
--- News for libdrm2 ---
libdrm (2.3.0-4) experimental; urgency=low
* We are now shipping libdrm with the default permissions set to 666,
rather than the upstream default of 660. If you have untrusted users,
you should configure the X server to explicitly use a mode of 660 in
the xorg.conf.
-- David Nusinow Wed, 18 Apr 2007 22:44:21 -0400
-- Package-specific info:
==> /etc/apt/listchanges.conf <==
[apt]
frontend=pager
email_address=root
confirm=0
save_seen=/var/lib/apt/listchanges
which=news
email_format=text
headers=true
reverse=false
capture_snapshots=auto
snapshot_dir=/var/lib/apt/listchanges-snapshots
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'),
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1,
'buildd-experimental')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled
Versions of packages apt-listchanges depends on:
ii apt 2.7.6
ii cdebconf [debconf-2.0] 0.271
ii debconf [debconf-2.0] 1.5.82
ii python3 3.11.4-5+b1
ii python3-apt 2.6.0
ii python3-debconf 1.5.82
ii sensible-utils 0.0.20
ii ucf 3.0043+nmu1
apt-listchanges recommends no packages.
Versions of packages apt-listchanges suggests:
ii alacritty [x-terminal-emulator]0.12.2-2+b1
ii chromium [www-browser] 118.0.5993.70-1
ii cool-retro-term [x-terminal-emulator] 1.2.0+ds2-1+b1
ii dillo [www-browser]3.0.5-7+b1
ii edbrowse [www-browser] 3.7.7-5
ii elinks [www-browser] 0.16.1.1-4
ii eterm [x-terminal-emulator]0.9.6-7.1
ii falkon [www-browser] 23.08.1-1
ii firefox [www-browser] 118.0.2-1
ii firefox-esr [www-browser] 115.3.0esr-1+b1
ii gnome-console [x-terminal-emulator]45.0-1
ii gnome-terminal [x-terminal-emulator] 3.50.0-1
ii hv3 [www-browser] 3.0~fossil20110109-8
ii kitty [x-terminal-emulator]
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi Emanuele, Emanuele Rocca wrote: > On 2023-10-10 01:45, Axel Beckert wrote: > > I tried that, installer ran through fine, grub boots from disk after > > installation, kernel loads initramfs and then falls into the initramfs > > prompt and fractions of a second later (sometimes even beforehand) the > > whole screen goes black and then nothing helps then pressing the power > > button for about 10 seconds. > > This sounds like you might have missed the wiki step "Add qnoc-sc8280xp > module to initramfs": > https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s I indeed missed that first, but fixed it via rescue mode of the d-i image. > OK then once you chroot into the installed system you should be able to > check if qnoc-sc8280xp is in /etc/initramfs-tools/modules. If not, > > echo qnoc-sc8280xp >> /etc/initramfs-tools/modules Was already in there. > To triple-check that the needed module is in there: > > zstdcat /initrd.img | cpio -itv | grep qnoc-sc8280xp.ko Was also already in there. Additionally there are quite some messages about things being pending due to waiting for something else from that kernel module seconds before the screen blanks. Can send pictures I made of it, in case they could be helpful. And since you've mentioned /initrd.img instead of /boot/initrd.img (as I have a single filesystem installation for now), I also added a symlink at /initrd.img pointing to /boot/initrd.img. But it didn't change anything either. (I later noticed that this likely was unnecessary as GRUB also looks for kernel and initrd.img under /boot and for a versioned file anyways.) > In any case, the daily netinst image should now work! Indeed. Had to use that to check the above today as the mini.iso no more works due to the updated kernel in sid. > There's no need to manually copy any firmware and similar > shenanigans. Well, still quite some shenanigans left for now. > If you have the time, please follow the > InstallingDebianOn/Thinkpad/X13s page again from the begingging to > the end (quite a few things have changed) and let me know if that > works for you. Haven't done a reinstallation for now. (And I'm actually not that keen on it currently, but I will have to do it at some point, because I forgot to enable disk encryption. But I'd first like to understand what's wrong as I seem to have followed all steps.) Via d-i's rescue mode I have also updated the kernel to 6.5.0-2, but the symptoms stay: Lots of "pending/waiting for" message by qnoc-sc8280xp and then a dark, blank screen and nothing happens anymore. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi Emanuele, Axel Beckert wrote: > Emanuele Rocca wrote: > > On 2023-05-04 11:53, Axel Beckert wrote: > > > Sure. I intend to run Debian Unstable on it anyway > > > > Now you can. :-) > > Hmmm, I tried a few days ago (October 1st) with the image from > https://cdimage.debian.org/cdimage/daily-builds/sid_d-i/current/arm64/iso-cd/ > and it hang with a message saying something about "generating empty > device tree" or so. And that image didn't contain the dtb files to copy while the mini.iso from d-i.d.o did. > > https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s > > Ah, I see, there's much more than just the installer image needed. I tried that, installer ran through fine, grub boots from disk after installation, kernel loads initramfs and then falls into the initramfs prompt and fractions of a second later (sometimes even beforehand) the whole screen goes black and then nothing helps then pressing the power button for about 10 seconds. The same happens if I start the recovery mode from the grub menu when booting from the disk. arm64.nopauth is in there. And I can easily install tons of packages when I boot from the installer USB stick into the rescue mode and chroot into the installation on disk. Even installing the recommended packages did not change anything with regards to the screen going black about 12 seconds after booting. I also tried to disable any console font changes via dpkg-reconfigure -plow console-setup console-setup-linux but to no avail. Any ideas what could have gone wrong or how I can fix this? I feel I'm _soooo_ close. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1053725: apt-listchanges: Shows NEWS for package tor from 2008
Hi Jonathan, Jonathan Kamens wrote: > OK, this will be fixed in 4.1. Yay, thanks! > Description of the bug and fix, copied from the commit message: > > Bug: > * Main package a has both changelog and NEWS. > * Subpackage a-sub has identical changelog but no NEWS. > * Both a and a-sub version 1 are installed but not in database. > * apt goes to upgrade a and a-sub to version 2. > * apt-listchanges parses a-sub first, records installed entries under > package a instead of a-sub, since we were using the package name in > the changelog entry to determine where in the seen DB to record > entries. Ouch, that seemed rather non-trivial to figure out and reproduce. > I added a unit test for this case which now passes, and all other unit tests > continue to pass with the change described above. Perfect! > Note that the database is entirely replaced when upgraded from pre-4.0 to > 4.x because its format and what we're storing in it are completely > different. Ok, wasn't sure how relevant its content is. Just tried to help. :-) > ># EASY-INSTALL-ENTRY-SCRIPT: > > 'apt-listchanges==3.27','console_scripts','apt-listchanges' > > Thanks, fixed this as well. Great! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1053725: apt-listchanges: Shows NEWS for package tor from 2008
Hi Jonathan. Jonathan Kamens wrote: > Not the same bug. #1053696 only applies to changelog entries, not NEWS > entries, since the latter can't be downloaded via apt. Good point. I'm glad that I filed my bug report despite Russ' bug report. > I am thus far unable to reproduce this. Still investigating. Anything I can help? This is a Sid installation running more or less permanently (besides reboots :-) since May 2016. So the apt-listchanges database might have seen a few packages. Then again, it seems rather short for > 14'000 installed packages. I've attached my /var/lib/apt/listchanges file. (State after having shown that NEWS entry from 2008, though.) BTW, while trying to figure out where that db could be I noticed that despite 4.0 is installed according to "dpkg -l apt-listchanges", the tool itself contains a different version number: ~ → head -2 /usr/bin/apt-listchanges #!/usr/bin/python3 # EASY-INSTALL-ENTRY-SCRIPT: 'apt-listchanges==3.27','console_scripts','apt-listchanges' HTH! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE listchanges Description: application/data
Bug#1053725: apt-listchanges: Shows NEWS for package tor from 2008
Package: apt-listchanges Version: 4.0 Severity: normal Hi, after the upgrade to 4.0, apt-listchanges showed me this ancient NEWS when upgrading tor from 0.4.8.6-1 to 0.4.8.7-1. Reading changelogs... Done apt-listchanges: News - --- News for tor --- tor (0.2.0.26-rc-1) experimental; urgency=critical * weak cryptographic keys It has been discovered that the random number generator in Debian's openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable. See Debian Security Advisory number 1571 (DSA-1571) for more information: http://lists.debian.org/debian-security-announce/2008/msg00152.html If you run a Tor server using this package please see /var/lib/tor/keys/moved-away-by-tor-package/README.REALLY -- Peter Palfrader Tue, 13 May 2008 12:49:05 +0200 (press q to quit) (In this case it even was an especially embarassing topic for Debian...) Might be related or the same as #1053696 by Russ (X-Debbugs-Cc'ed). -- Package-specific info: ==> /etc/apt/listchanges.conf <== [apt] frontend=pager email_address=root confirm=0 save_seen=/var/lib/apt/listchanges which=news email_format=text headers=true reverse=false -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages apt-listchanges depends on: ii apt 2.7.6 ii cdebconf [debconf-2.0] 0.271 ii debconf [debconf-2.0] 1.5.82 ii python3 3.11.4-5+b1 ii python3-apt 2.6.0 ii python3-debconf 1.5.82 ii sensible-utils 0.0.20 ii ucf 3.0043+nmu1 apt-listchanges recommends no packages. Versions of packages apt-listchanges suggests: ii alacritty [x-terminal-emulator]0.12.2-2+b1 ii chromium [www-browser] 117.0.5938.149-1 ii cool-retro-term [x-terminal-emulator] 1.2.0+ds2-1+b1 ii dillo [www-browser]3.0.5-7+b1 ii edbrowse [www-browser] 3.7.7-5 ii elinks [www-browser] 0.16.1.1-4 ii eterm [x-terminal-emulator]0.9.6-7.1 ii falkon [www-browser] 23.08.1-1 ii firefox [www-browser] 118.0-1+b1 ii firefox-esr [www-browser] 115.3.0esr-1+b1 ii gnome-console [x-terminal-emulator]45.0-1 ii gnome-terminal [x-terminal-emulator] 3.50.0-1 ii hv3 [www-browser] 3.0~fossil20110109-8 ii kitty [x-terminal-emulator]0.26.5-5 ii konqueror [www-browser]4:22.12.3-2 ii konsole [x-terminal-emulator] 4:23.08.1-1 ii lilyterm [x-terminal-emulator] 0.9.9.4+git20150208.f600c0-5+b1 ii links [www-browser]2.29-1+b1 ii links2 [www-browser] 2.29-1+b1 ii luakit [www-browser] 1:2.3.3-1 ii lxterminal [x-terminal-emulator] 0.4.0-2 ii lynx [www-browser] 2.9.0dev.12-1 ii midori [www-browser] 7.0-2.1+b1 ii netrik [www-browser] 1.16.1-4 ii netsurf [www-browser] 3.6-3.2 ii netsurf-gtk [www-browser] 3.10-3.1 ii postfix [mail-transport-agent] 3.8.2-1 ii pterm [x-terminal-emulator]0.79-1 ii python3-gi 3.46.0-1 ii qterminal [x-terminal-emulator]1.3.0-1 ii qutebrowser [www-browser] 2.5.4-1 ii rxvt-unicode [x-terminal-emulator] 9.31-1 ii sakura [x-terminal-emulator] 3.8.7-1 ii stterm [x-terminal-emulator] 0.9-1 ii surf [www-browser] 2.1+git20221016-5 ii terminator [x-terminal-emulator] 2.1.3-1 ii terminology [x-terminal-emulator] 1.13.0-2 ii termit [x-terminal-emulator] 3.1-3 ii tilix [x-terminal-emulator]1.9.5-2 ii w3m [www-browser] 0.5.3+git20230121-2 ii xfce4-terminal [x-terminal-emulator] 1.1.0-2 ii xterm [x-terminal-emulator]385-1 ii yakuake [x-terminal-emulator] 23.08.1-1 ii zutty [x-terminal-emulator]0.14.6.20230701+dfsg1-2 -- debconf information: * apt-listchanges/confirm: false apt-listchanges/no-network: false * apt-listchanges/email-format: text * apt-listchanges/email-address: root * apt-listchanges/headers: true * apt-listchanges/save-seen: true * apt-listchanges/which: news * apt-listchanges/reverse: false *
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi Emanuele, Emanuele Rocca wrote: > On 2023-05-04 11:53, Axel Beckert wrote: > > Sure. I intend to run Debian Unstable on it anyway > > Now you can. :-) Hmmm, I tried a few days ago (October 1st) with the image from https://cdimage.debian.org/cdimage/daily-builds/sid_d-i/current/arm64/iso-cd/ and it hang with a message saying something about "generating empty device tree" or so. > https://wiki.debian.org/InstallingDebianOn/Thinkpad/X13s Ah, I see, there's much more than just the installer image needed. Thanks for that hint! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1051673: deal.ii: uploader email address maybe invalid (Matthias Maier)
Hi Ansgar, Ansgar wrote: > On Mon, 2023-09-11 at 10:32 +0200, Ben Tris wrote: > > The email address for uploader Matthias Maier is now > > this is not found in qa. > > I don't understand what the problem here should be? The mail address > should be valid. I suspect an issue with https://qa.debian.org/developer.php having an issue with e-mail addresses with capital letters and Ben misinterpreting that as an issue with the package despite the issue is somewhere else. All bugs he filed were about e-mail addresses with capital letters. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1051328: grub-common: wrong-path-for-interpreter /usr/bin/sh != /bin/sh [etc/grub.d/25_bli]
Hi Julian, Julian Andres Klode wrote: > > For some reason, possibly usrmerge-triggered, since 2.12~rc1-7 > > /etc/grub.d/25_bli sports the following non-standard shebang line: > > > > #!/usr/bin/sh > > > > as lintian also reports: > > > > → lintian grub-common_2.12\~rc1-9_amd64.deb > > E: grub-common: wrong-path-for-interpreter /usr/bin/sh != /bin/sh > > [etc/grub.d/25_bli] > > Merged-usr has been mandatory since bookworm Nevertheless the Debian Policy nowhere mentions /usr/bin/sh but only /bin/sh. > it has been addressed in the upstream git branch and will be fixed > in the final 2.12 release. Ok, that's good to hear. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?
Control: severity -1 important Hi, John Zaitseff wrote: > The latest (Sid) version of emacs-common now depends on > "dconf-gsettings-backend | gsettings-backend", which in turn > eventually installs dbus-daemon -- which is problematic in a Debian > build chroot environment. Can that dependency be downgraded to > Recommends or Suggests? Or put the dependency back into those packages which actually require dbus. Because the current dependency setup causes dbus and other completely unnecessary desktop stuff to be pulled in on servers and VMs where just emacs-nox is installed despite emacs-nox is meant for non desktop systems. (And please remember that the "d" in "dbus" stands for "desktop".) John Zaitseff wrote: > After a bit of digging around through the package source code, this > is as a result of using the binaries from the "pgtk" build of Emacs > for common binaries -- since "other builds' emacsclients cannot > connect to pgtk under Wayland". *sigh* > Given that that is a good reason, IMHO, for using the binaries in > that way, feel free to close this bug report. No, this is a rather severe degradation of emacs-nox's usability and needs to be fixed, either by splitting off these components into a new package emacs-common-pgtk or simlar if Wayland causes such problems for other variants or by solving it in another way which causes less issues for the other variants, too —- like e.g. putting these dependencies in other packages with emacs-common just sporting them in Recommends or Suggests. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1051328: grub-common: wrong-path-for-interpreter /usr/bin/sh != /bin/sh [etc/grub.d/25_bli]
Package: grub-common File: /etc/grub.d/25_bli Version: 2.12~rc1-7 Version: 2.12~rc1-9 Severity: serious For some reason, possibly usrmerge-triggered, since 2.12~rc1-7 /etc/grub.d/25_bli sports the following non-standard shebang line: #!/usr/bin/sh as lintian also reports: → lintian grub-common_2.12\~rc1-9_amd64.deb E: grub-common: wrong-path-for-interpreter /usr/bin/sh != /bin/sh [etc/grub.d/25_bli] Interestingly only this single file seems to be affected. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages grub-common depends on: ii gettext-base0.21-13 ii libc6 2.37-7 ii libdevmapper1.02.1 2:1.02.185-2 ii libefiboot1 37-6 ii libefivar1 37-6 ii libfreetype62.13.2+dfsg-1 ii libfuse3-3 3.14.0-4 ii liblzma55.4.4-0.1 Versions of packages grub-common recommends: pn os-prober Versions of packages grub-common suggests: ii console-setup 1.222 ii desktop-base 12.0.6+nmu1 pn grub-emu ii mtools 4.0.43-1 pn multiboot-doc ii xorriso1.5.4-4 -- no debconf information
Bug#1051192: solid-auth, liblog-any-perl: solid-auth became uninstallable after liblog-any-perl dropped liblog-any-adapter-perl Provides
Hi gregor, gregor herrmann wrote: > > > I noticed that liblog-any-adapter-perl was removed in 2015, and, more > > > importantly, I checked with `apt-cache rdepends > > > liblog-any-adapter-perl' which, unless I was blind, didn't show > > > anything. > > I can confirm that — looks like a bug around virtual packages: > > Thanks for double-checking! You're welcome. > > → grep-aptavail -FDepends -P liblog-any-adapter-perl | fgrep > > liblog-any-adapter-perl > > Nice, I always forget the syntax. Didn't get it right on the first try, either. :-) > With different output: > > % grep-aptavail -FDepends -P liblog-any-adapter-perl -s Source,Package,Depends I had -S in my mind, but that's the opposite of -P and hence got weird results. :-) > > Should we do this in solid-auth, too, or just use solely > > liblog-any-perl? > > I'd go for only liblog-any-perl everywhere as is gone … The longer I think about the more I tend towards that direction, too. gregor herrmann wrote: > These 4 are fixed in git to only use liblog-any-perl (but not > uploaded as there is no practical problem). […] > Done for src:libweb-solid-auth-perl, and uploaded. Perfect. Thanks a lot! > Hm, and I found more in git: > > % grep liblog-any-adapter-perl */debian/control > liblog-any-adapter-screen-perl/debian/control: liblog-any-perl | > liblog-any-adapter-perl , > liblog-any-adapter-screen-perl/debian/control: liblog-any-perl | > liblog-any-adapter-perl, > librdf-linkeddata-perl/debian/control: liblog-any-adapter-perl, > librdf-linkeddata-perl/debian/control: liblog-any-adapter-perl, > > Not found by grep-aptavail? Next weirdness … I think I managed to solve that mystery: > Oh, look, the latter has fresh autopkgtest failures on ci.d.n. O.o I think something went wrong here as the commit message doesn't fit at all with the changes: https://salsa.debian.org/perl-team/modules/packages/librdf-linkeddata-perl/-/commit/6955989b1474f72cb75c33aa3f0cde418c82ff68 Then again, that was 6 years ago. Ah, that were solely build-dependencies, not run-time dependencies. At least that mystery is solved. :-) Anyway, thanks for your efforts and sorry that I currently can't help that much with the actual work. (Lagging behind with fixing RC bugs in my non-team packages, too…) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1051192: solid-auth,liblog-any-perl: solid-auth became uninstallable after liblog-any-perl dropped liblog-any-adapter-perl Provides
Hi gregor, gregor herrmann wrote: > > after the upload of liblog-any-perl/1.717-1, solid-auth/0.91-1 became > > uninstallable as it depends on liblog-any-adapter-perl which is no more > > provided by liblog-any-perl since 1.717-1. > > Oops, sorry for that. Well, aptitude automatically suggested to hold back liblog-any-perl. :-) > I noticed that liblog-any-adapter-perl was removed in 2015, and, more > importantly, I checked with `apt-cache rdepends > liblog-any-adapter-perl' which, unless I was blind, didn't show > anything. I can confirm that — looks like a bug around virtual packages: → apt-rdepends liblog-any-adapter-perl Reading package lists... Done Building dependency tree... Done Reading state information... Done liblog-any-adapter-perl → apt-cache rdepends liblog-any-adapter-perl → Weird. > > I'm not sure, but I assume, this is best fixed in > > src:libweb-solid-auth-perl. An according revert in liblog-any-perl would > > fix the issue as well, though. > > A fix in libweb-solid-auth-perl seems more appropriate to me; unless > we have more hidden dependencies … As far as I can see, solid-auth should be the last one. All others already have it as last part of a list of alternative dependencies, so no issue: → grep-aptavail -FDepends -P liblog-any-adapter-perl | fgrep liblog-any-adapter-perl Depends: perl:any, libboolean-perl, libclone-perl, libdata-visitor-perl, libfailures-perl, libhttp-message-perl, libjson-perl, liblog-any-perl | liblog-any-adapter-perl, libmime-types-perl, libmoo-perl, libsafe-isa-perl, libstrictures-perl, libtype-tiny-perl, liburi-namespacemap-perl, liburi-perl, liburi-template-perl, libxml-regexp-perl Depends: perl:any, liblog-any-perl | liblog-any-adapter-perl Depends: perl:any, liblog-any-perl | liblog-any-adapter-perl, liblog-dispatch-perl Depends: perl:any, liblog-any-perl | liblog-any-adapter-perl Depends: libfile-libmagic-perl, libjson-perl, liblog-any-adapter-log4perl-perl, liblog-any-adapter-perl, liblog-log4perl-perl, libpath-tiny-perl, libstring-escape-perl, libweb-solid-auth-perl, perl:any → Should we do this in solid-auth, too, or just use solely liblog-any-perl? Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1051192: solid-auth,liblog-any-perl: solid-auth became uninstallable after liblog-any-perl dropped liblog-any-adapter-perl Provides
Package: solid-auth,liblog-any-perl Severity: serious Control: found -1 liblog-any-perl/1.717-1 Control: found -1 solid-auth/0.91-1 Hi, after the upload of liblog-any-perl/1.717-1, solid-auth/0.91-1 became uninstallable as it depends on liblog-any-adapter-perl which is no more provided by liblog-any-perl since 1.717-1. I'm not sure, but I assume, this is best fixed in src:libweb-solid-auth-perl. An according revert in liblog-any-perl would fix the issue as well, though. -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled
Bug#1042463: lintian does not accept overrides in the syntax used on ftp-master
Control: tag -1 + moreinfo Hi Julian, Julian Andres Klode wrote: > lintian in the archive needs to restore support for the old override > format, or ftpmaster needs to be updated to the new lintian. We had a lengthy discussion about the override format changes made by Felix (see https://bugs.debian.org/1007002) and there's no way back (including "backwards compatibility") unless someone volunteers to implement a fix for this. (I won't do that as mentioned in this thread. See also below for some reasoning.) > Normal source-only uploads do not trigger the issue usually, but > there surely have been people adopting their overrides to the new > format who now get stuck (like me) at binary-NEW with a reject when > having to do a binary upload. Please give an explicit example. I'm not sure if you and me think of the same "new" and "old" format. → Tagged as "moreinfo". As mentioned in #1007002 there's a script in the migrate-overrides branch of https://salsa.debian.org/lintian/lintian/ which can automatically migrate tags in override files. But so far it only knows a few of the very annoying tags — which is also the reason it's not in the package yet. But I'm willing to extend that script and maybe even implement a mode for ftp-masters if I get an example of a file which needs to be migrated (including file name and maybe default path). But for that I need old real-life examples. (Maybe ftp-masters can give me the file/list Julian mentioned or tell me where to find it?) > For an orderly transition, lintian needs to […] Please tell this the previous lintian lead developer who decided and implemented this inmidst of tons of other invasive changes (like rewriting Lintian's internal module structure) without doing a release for months or doing a release after one of these invasive changes. It's anything but a simple "git revert" to get the old format back. And a compatibility mode would require implementing the old override format in the new framework from scratch. Short said: IMHO we should do a forward escape instead of trying to implement a very work-intensive backwards compatibility. For which we don't seem to have the resources anyway unless someone volunteers. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1050522: wdm: FTBFS: fatal error: pango/pango.h: No such file or directory
Control: tag -1 + confirmed pending Hi Aurelien, Aurelien Jarno wrote: > wdm fails to build from source. From my build log on amd64: Thanks for the bug report! > | /usr/include/WINGs/WINGsP.h:8:10: fatal error: pango/pango.h: No such file > or directory > | 8 | #include I can reproduce in a clean chroot. But it does not happen when building in my Sid workstation. So it looks like a missing respectively now separate build dependency. Just tested: Adding a build-dependency on libpango1.0-dev suffices to get it building in a clean chroot again. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1042911: Breaks Emacs 29.1 upgrade: muse-split.el:41:2: Error: Cannot open load file: No such file or directory, assoc
Package: elpa-muse Version: 3.20+dfsg-7 Severity: serious X-Debbugs-Cc: a...@debian.org Control: affects -1 emacs emacs-gtk emacs-lucid emacs-nox emacs-pgtk Since upgrading to Emacs 29.1, byte-(re-)compilation fails as follows: […] Install elpa-muse for emacs install/muse-3.20: Handling install of emacsen flavor emacs install/muse-3.20: byte-compiling for emacs In toplevel form: cgi.el:71:2: Warning: Package cl is deprecated cgi.el:87:13: Warning: Unknown defun property ‘character’ In cgi-decode-string: cgi.el:94:4: Warning: ‘do’ is an obsolete alias (as of 27.1); use ‘cl-do’ instead. cgi.el:101:15: Warning: ‘incf’ is an obsolete alias (as of 27.1); use ‘cl-incf’ instead. cgi.el:108:17: Warning: ‘incf’ is an obsolete alias (as of 27.1); use ‘cl-incf’ instead. In cgi-decode: cgi.el:124:6: Warning: ‘flet’ is an obsolete macro (as of 24.3); use either ‘cl-flet’ or ‘cl-letf’. In cgi-arguments: cgi.el:161:13: Warning: ‘loop’ is an obsolete alias (as of 27.1); use ‘cl-loop’ instead. In end of data: cgi.el:197:16: Warning: the function ‘calendar-current-date’ might not be defined at runtime. In toplevel form: htmlize-hack.el:12:13: Warning: ‘loop’ is an obsolete alias (as of 27.1); use ‘cl-loop’ instead. htmlize-hack.el:17:8: Warning: ‘reduce’ is an obsolete function (as of 27.1); use ‘cl-reduce’ instead. In muse-backlink-insert-hook-func: muse-backlink.el:264:12: Warning: ‘font-lock-fontify-buffer’ is for interactive use only; use ‘font-lock-ensure’ or ‘font-lock-flush’ instead. In end of data: muse-backlink.el:313:33: Warning: the function ‘muse-make-link’ might not be defined at runtime. In toplevel form: muse-colors.el:60:2: Warning: custom-declare-variable `muse-colors-autogen-headings' docstring has wrong usage of unescaped single quotes (use \= or different quoting) muse-colors.el:94:2: Warning: custom-declare-variable `muse-colors-inline-image-method' docstring has wrong usage of unescaped single quotes (use \= or differ ent quoting) In muse-colors-region: muse-colors.el:577:10: Warning: ‘inhibit-point-motion-hooks’ is an obsolete variable (as of 25.1); use ‘cursor-intangible-mode’ or ‘cursor-sensor-mode’ instea d In muse-unhighlight-region: muse-colors.el:732:10: Warning: ‘inhibit-point-motion-hooks’ is an obsolete variable (as of 25.1); use ‘cursor-intangible-mode’ or ‘cursor-sensor-mode’ instea d In muse-colors-lisp-tag: muse-colors.el:775:30: Warning: ‘muse-looking-back’ called with 1 argument, but requires 2 or 3 In muse-docbook-markup-paragraph: muse-docbook.el:233:41: Warning: ‘muse-looking-back’ called with 1 argument, but requires 2 or 3 In toplevel form: muse-html.el:67:2: Warning: custom-declare-variable `muse-html-style-sheet' docstring wider than 80 characters muse-html.el:96:2: Warning: custom-declare-variable `muse-xhtml-style-sheet' docstring wider than 80 characters muse-html.el:399:2: Warning: custom-declare-variable `muse-html-meta-content-encoding' docstring has wrong usage of unescaped single quotes (use \= or differe nt quoting) muse-html.el:421:2: Warning: custom-declare-variable `muse-html-src-allowed-modes' docstring has wrong usage of unescaped single quotes (use \= or different q uoting) In muse-html-markup-paragraph: muse-html.el:490:6: Warning: ‘muse-looking-back’ called with 1 argument, but requires 2 or 3 In muse-html-src-tag: muse-html.el:670:16: Warning: ‘font-lock-fontify-buffer’ is for interactive use only; use ‘font-lock-ensure’ or ‘font-lock-flush’ instead. ../../elpa-src/muse-3.20/cgi.el: Warning: Unknown defun property ‘character’ ../../elpa-src/muse-3.20/cgi.el: Warning: ‘do’ is an obsolete alias (as of 27.1); use ‘cl-do’ instead. ../../elpa-src/muse-3.20/cgi.el: Warning: ‘incf’ is an obsolete alias (as of 27.1); use ‘cl-incf’ instead. ../../elpa-src/muse-3.20/cgi.el: Warning: ‘incf’ is an obsolete alias (as of 27.1); use ‘cl-incf’ instead. ../../elpa-src/muse-3.20/cgi.el: Warning: ‘incf’ is an obsolete alias (as of 27.1); use ‘cl-incf’ instead. ../../elpa-src/muse-3.20/cgi.el: Warning: ‘flet’ is an obsolete macro (as of 24.3); use either ‘cl-flet’ or ‘cl-letf’. ../../elpa-src/muse-3.20/cgi.el: Warning: ‘loop’ is an obsolete alias (as of 27.1); use ‘cl-loop’ instead. ../../elpa-src/muse-3.20/muse-ipc.el: Warning: ‘return-from’ is an obsolete alias (as of 27.1); use ‘cl-return-from’ instead. ../../elpa-src/muse-3.20/muse-ipc.el: Warning: ‘return-from’ is an obsolete alias (as of 27.1); use ‘cl-return-from’ instead. In toplevel form: muse-ipc.el:50:2: Warning: custom-declare-variable `muse-ipc-ignore-done' docstring has wrong usage of unescaped single quotes (use \= or different quoting) muse-ipc.el:80:2: Warning: ‘defun*’ is an obsolete alias (as of 27.1); use ‘cl-defun’ instead. In muse-ipc-server-filter: muse-ipc.el:93:6: Warning: ‘return-from’ is an obsolete alias (as of 27.1); use ‘cl-return-from’ instead. In muse-journal-generate-pages: muse-journal.el:186:24: Warning: value returned from
Bug#1042907: Breaks Emacs 29.1 upgrade: haskell.el:30:2: Error: Eager macro-expansion failure: (error "Misplaced t or ‘otherwise’ clause")
Package: elpa-haskell-mode Version: 17.2-5 Severity: serious X-Debbugs-Cc: a...@debian.org Control: affects -1 emacs emacs-gtk emacs-lucid emacs-nox emacs-pgtk After upgrading Emacs to 29.1, byte-(re-)compiling fails as follows: […] Install elpa-haskell-mode for emacs install/haskell-mode-17.2snapshot: Handling install of emacsen flavor emacs install/haskell-mode-17.2snapshot: byte-compiling for emacs ../../elpa-src/haskell-mode-17.2snapshot/haskell-cabal.el: Warning: Case 'before will match ‘quote’. If that’s intended, write (before quote) instead. Otherwise, don’t quote ‘before’. ../../elpa-src/haskell-mode-17.2snapshot/haskell-cabal.el: Warning: Case 'after will match ‘quote’. If that’s intended, write (after quote) instead. Otherwise, don’t quote ‘after’. ../../elpa-src/haskell-mode-17.2snapshot/haskell-cabal.el: Warning: Case 'single will match ‘quote’. If that’s intended, write (single quote) instead. Otherwise, don’t quote ‘single’. ../../elpa-src/haskell-mode-17.2snapshot/haskell-process.el: Warning: Case 'ghci will match ‘quote’. If that’s intended, write (ghci quote) instead. Otherwise, don’t quote ‘ghci’. ../../elpa-src/haskell-mode-17.2snapshot/haskell-process.el: Warning: Case 'cabal-repl will match ‘quote’. If that’s intended, write (cabal-repl quote) instead. Otherwise, don’t quote ‘cabal-repl’. ../../elpa-src/haskell-mode-17.2snapshot/haskell-process.el: Warning: Case 'stack-ghci will match ‘quote’. If that’s intended, write (stack-ghci quote) instead. Otherwise, don’t quote ‘stack-ghci’. ../../elpa-src/haskell-mode-17.2snapshot/haskell-commands.el: Warning: Case 'unknown-command will match ‘quote’. If that’s intended, write (unknown-command quote) instead. Otherwise, don’t quote ‘unknown-command’. ../../elpa-src/haskell-mode-17.2snapshot/haskell-commands.el: Warning: Case 'option-missing will match ‘quote’. If that’s intended, write (option-missing quote) instead. Otherwise, don’t quote ‘option-missing’. ../../elpa-src/haskell-mode-17.2snapshot/haskell-commands.el: Warning: Case 'interactive-error will match ‘quote’. If that’s intended, write (interactive-error quote) instead. Otherwise, don’t quote ‘interactive-error’. In toplevel form: ghci-script-mode.el:20:2: Error: Eager macro-expansion failure: (error "Misplaced t or ‘otherwise’ clause") In haskell-cabal-classify-line: haskell-cabal.el:363:2: Warning: docstring wider than 80 characters haskell-cabal.el:363:2: Warning: docstring has wrong usage of unescaped single quotes (use \= or different quoting) In haskell-cabal-enum-targets: haskell-cabal.el:496:2: Warning: docstring wider than 80 characters In haskell-cabal-listify: haskell-cabal.el:701:12: Warning: Case 'before will match ‘quote’. If that’s intended, write (before quote) instead. Otherwise, don’t quote ‘before’. haskell-cabal.el:701:12: Warning: Case 'after will match ‘quote’. If that’s intended, write (after quote) instead. Otherwise, don’t quote ‘after’. haskell-cabal.el:701:12: Warning: Case 'single will match ‘quote’. If that’s intended, write (single quote) instead. Otherwise, don’t quote ‘single’. In haskell-cabal-line-filename: haskell-cabal.el:926:2: Warning: docstring wider than 80 characters In haskell-blank-line-p: haskell-collapse.el:46:9: Warning: ‘point-at-eol’ is an obsolete function (as of 29.1); use ‘line-end-position’ or ‘pos-eol’ instead. In haskell-hide-toggle-all: haskell-collapse.el:95:19: Warning: ‘point-at-bol’ is an obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ instead. In toplevel form: haskell-commands.el:652:12: Error: Misplaced t or ‘otherwise’ clause In toplevel form: haskell-compile.el:42:2: Warning: custom-declare-variable `haskell-compile-cabal-build-command' docstring wider than 80 characters haskell-compile.el:49:2: Warning: custom-declare-variable `haskell-compile-cabal-build-alt-command' docstring wider than 80 characters haskell-compile.el:56:2: Warning: custom-declare-variable `haskell-compile-stack-build-command' docstring wider than 80 characters haskell-compile.el:63:2: Warning: custom-declare-variable `haskell-compile-stack-build-alt-command' docstring wider than 80 characters haskell-compile.el:70:2: Warning: custom-declare-variable `haskell-compile-command' docstring wider than 80 characters haskell-compile.el:83:2: Warning: custom-declare-variable `haskell-compiler-type' docstring wider than 80 characters In haskell-completions-grab-pragma-prefix: haskell-completions.el:146:2: Warning: docstring has wrong usage of unescaped single quotes (use \= or different quoting) In haskell-completions-grab-identifier-prefix: haskell-completions.el:216:2: Warning: docstring has wrong usage of unescaped single quotes (use \= or different quoting) In haskell-completions-grab-prefix: haskell-completions.el:267:2: Warning: docstring has wrong usage of unescaped single quotes (use \= or different quoting) In haskell-completions--simple-completions:
Bug#1042900: Breaks Emacs 29.1 upgrade: pointback.el:34:2: Error: Cannot open load file: No such file or directory, assoc
Package: elpa-pointback Version: 0.2-4 Severity: serious X-Debbugs-Cc: a...@debian.org Control: affects -1 emacs emacs-gtk emacs-lucid emacs-nox emacs-pgtk Since the upgrade to Emacs 29.1-1, byte (re-)compilation fails as follows: […] Install elpa-pointback for emacs install/pointback-0.2: Handling install of emacsen flavor emacs install/pointback-0.2: byte-compiling for emacs In toplevel form: pointback.el:34:2: Error: Cannot open load file: No such file or directory, assoc ERROR: install script from elpa-pointback package failed dpkg: error processing package emacs-gtk (--configure): installed emacs-gtk package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of emacs: […] -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages elpa-pointback depends on: ii dh-elpa-helper 2.0.17 ii emacsen-common 3.0.5 Versions of packages elpa-pointback recommends: iu emacs 1:29.1+1-2 ih emacs-gtk [emacs] 1:29.1+1-2 elpa-pointback suggests no packages. -- no debconf information
Bug#1042845: libembperl-perl: FTBFS with Perl 5.38: test failures
Hi Niko, Niko Tyni wrote: > This package fails to build from source with Perl 5.38 (currently in > experimental.) Thanks for the bug report. > I assume the diagnostics have changed again and it's just the tests that > need adjusting, but I haven't checked properly. Will look into it, but may take a while. >cat: test/tmp/httpd.pid: No such file or directory That one looks familiar, but IIRC was a red herring. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1041299: rawloader: multiple undeclared file conflicts
Hi! Helmut Grohne wrote: > rawloader contains multiple undeclared file conflicts > > usr/bin/identify is contained in graphicsmagick-imagemagick-compat. Please note that /usr/bin/identify is also included in imagemagick-6.q16 and imagemagick-6.q16hdri and is handled by update-alternatives by these two packages: imagemagick-6.q16: /usr/bin/identify-im6.q16 imagemagick-6.q16hdri: /usr/bin/identify-im6.q16hdri lrwxrwxrwx 1 root root 26 May 5 2017 /usr/bin/identify -> /etc/alternatives/identify* So even though these do not directly ship this binary, a conflict would be needed there, too, unless it is renamed. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1038203: iptables-netflow-dkms: module fails to build for Linux 6.4: error: implicit declaration of function 'register_sysctl_paths'
Control: forwarded -1 https://github.com/aabc/ipt-netflow/issues/220 Hi Andreas, Andreas Beckmann wrote: > /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c: In function > 'ipt_netflow_init': > /var/lib/dkms/ipt-netflow/2.6/build/ipt_NETFLOW.c:5688:33: error: implicit > declaration of function 'register_sysctl_paths'; did you mean > 'register_sysctl_table'? [-Werror=implicit-function-declaration] > 5688 | netflow_sysctl_header = > register_sysctl_paths(netflow_sysctl_path, netflow_sysctl_table); register_sysctl_paths has been removed from the kernel: https://github.com/torvalds/linux/commit/0199849acd07d07e2a8e42757653ca8b14a122f5 Based on https://github.com/kalamlacki/ipt-netflow/commit/2a1d250a701405b81fdf3548b4b9c12bf266a306 and https://github.com/kalamlacki/ipt-netflow/commit/373b58781a0fc99fcb354ea3b5e4f3a006a71ab6 I've created a patch which does not hardcode the new variant but which is backwards compatible. Will push and upload soon. Thanks for the bug report. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1033222: libgl1-mesa-dri: Segmentation fault with nouveau_dri.so
Hi Christophe,
Christophe Lohr wrote:
> Xorg is carshing with a segfault:
>
> (EE) Backtrace:
> (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55c365ce4cf9]
> (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f00ef25af90]
> (EE) 2: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
> (nouveau_drm_screen_create+0x4406c) [0x7f00ed75999c]
> (EE) 3: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
> (nouveau_drm_screen_create+0x1e4c9) [0x7f00ed733df9]
> (EE) 4: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so
> (nouveau_drm_screen_create+0x266) [0x7f00ed715b96]
> (EE) unw_get_proc_name failed: no unwind info found [-10]
> ../..
> Fatal server error:
> (EE) Caught signal 11 (Segmentation fault). Server aborting
>
> any workaround meantime? ;-)
I think I've run into the same or at least a very similar issue (see
https://bugs.debian.org/1040254, reported against
xserver-xorg-video-nouveau) and my fix was (unfortunately) to switch
from xserver-xorg-video-nouveau to the non-free binary-only driver
xserver-xorg-video-nvidia with nvidia-kernel-dkms.
(Using nvidia-open-kernel-dkms instead of nvidia-kernel-dkms did not
suffice for me as it had other issues, it made X show up on only one
screen and without any xrandr or nvidia-settings capabilities.)
HTH
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1025419: libunwind 1.6.2-2 upgrade makes xorg crash on startup
Hi, Thomas Glanzmann wrote: > the issue is already fixed upstream in libunwind. And that fix seems to have been backported in 1.6.2-3 (now in stable, testing and unstable), see https://bugs.debian.org/1026217 So this bug report likely can be closed as fixed in libunwind/1.6.2-3 or (force-) merged with #1026217. (But I'd like to have a second pair of eyes agreeing that these two issues are indeed the same before merging or closing.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1040254: xserver-xorg-video-nouveau: Regression: Crashes with "(EE) Caught signal 11 (Segmentation fault). Server aborting" upon start after dist-upgrade from Bullseye to Bookworm
Package: xserver-xorg-video-nouveau Severity: grave Version: 1:1.0.17-2 Dear Maintainer, > What led up to the situation? I've dist-upgraded a 7 years old HP workstation with an "NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1)" graphics card from Debian 11 to 12. It was previously working fine with the nouveau driver and three screens attached. After the dist-upgrade, X crashes immediately and reproducibly with segfault upon start. Tried IIRC two times with wdm and once with startx. The following log is from the last try with wdm _before_ using a different driver: X.Org X Server 1.21.1.7 X Protocol Version 11, Revision 0 Current Operating System: Linux emehari 6.1.0-9-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.27-1 (2023-05-08) x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.1.0-9-amd64 root=/dev/mapper/vgssd-root ro kaslr pti=on slab_nomerge page_poison=1 slub_debug=FPZ xorg-server 2:21.1.7-3 (https://www.debian.org/support) Current version of pixman: 0.42.2 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: "/var/log/Xorg.0.log", Time: Tue Jun 27 23:06:34 2023 (==) Using config directory: "/etc/X11/xorg.conf.d" (==) Using system config directory "/usr/share/X11/xorg.conf.d" nvc0_screen_create:1072 - Base screen init failed: -19 (EE) (EE) Backtrace: (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55dc10b2ad29] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f895105af90] (EE) 2: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so (nouveau_drm_screen_create+0x4406c) [0x7f894f36c2fc] (EE) 3: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so (nouveau_drm_screen_create+0x1e4c9) [0x7f894f346759] (EE) 4: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so (nouveau_drm_screen_create+0x266) [0x7f894f3284f6] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 5: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so (?+0x0) [0x7f894eaaaf76] (EE) 6: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so (__driDriverGetExtensions_d3d12+0x61dab4) [0x7f894f0c8ff4] (EE) 7: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so (__driDriverGetExtensions_d3d12+0x1a93) [0x7f894eaacfd3] (EE) 8: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so (__driDriverGetExtensions_d3d12+0xa1a5) [0x7f894eab56e5] (EE) 9: /usr/lib/x86_64-linux-gnu/libgbm.so.1 (gbm_format_get_name+0xf2e) [0x7f895079beae] (EE) 10: /usr/lib/x86_64-linux-gnu/libgbm.so.1 (gbm_format_get_name+0x16f8) [0x7f895079c678] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 11: /usr/lib/x86_64-linux-gnu/libgbm.so.1 (?+0x0) [0x7f895079a74c] (EE) 12: /usr/lib/x86_64-linux-gnu/libgbm.so.1 (gbm_create_device+0x44) [0x7f895079a884] (EE) 13: /usr/lib/xorg/modules/libglamoregl.so (glamor_egl_init+0x61) [0x7f89507d43c1] (EE) unw_get_proc_name failed: no unwind info found [-10] (EE) 14: /usr/lib/xorg/modules/drivers/modesetting_drv.so (?+0x0) [0x7f8951949733] (EE) 15: /usr/lib/xorg/Xorg (InitOutput+0x952) [0x55dc109fa4c2] (EE) 16: /usr/lib/xorg/Xorg (InitFonts+0x1ce) [0x55dc109bb4de] (EE) 17: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x8a) [0x7f895104618a] (EE) 18: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x85) [0x7f8951046245] (EE) 19: /usr/lib/xorg/Xorg (_start+0x21) [0x55dc109a4b71] (EE) (EE) Segmentation fault at address 0x20 (EE) Fatal server error: (EE) Caught signal 11 (Segmentation fault). Server aborting Switching to xserver-xorg-video-nvidia with nvidia-kernel-dkms (but not nvidia-open-kernel-source — which made X show up on only one screen without any xrandr or nvidia-settings capabilities) fixed the issue. Hence reporting this against the nouveau driver as replacing it fixed the issue. (Feel free to reassign this bug to e.g. xserver-xorg-core/2:21.1.7-3 or libgl1-mesa-dri/22.3.6-1+deb12u1 or similar if you think the bug is nevertheless rather in there.) There was no xorg.conf besides the system-provided /etc/xorg.conf.d/* files present. Now there is one needed due to the three-headed monkey, eh three-headed screen setup. So basically nouveau with that graphics card (and maybe my screen setup which includes two rotated screens, see below) is impossible due to a severe regression in (likely) the noveau driver. I would have expected that I could just use the much preferred free nouveau driver as with Bullseye. Hardware is an "HP EliteDesk 800 G2 TWR" with an "NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1)" graphics card: # lspci | fgrep VGA 01:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1) I can also reinstall xserver-xorg-video-nouveau if wanted to e.g. provide an additional backtrace with gdb or strace the execution in case that would offer more insight than the backtrace from Xorg.0.log respectively
Bug#1040197: elpa-ghub: Fails to upgrade from 3.5.6-1 to 3.6.0-2 due to dropped but still required dependency on elpa-treepy
Package: elpa-ghub Version: 3.6.0-2 Severity: serious Hi, somewhere between elpa-ghub 3.5.6-1 and 3.6.0-2, it dropped the dependency on elpa-treepy despite it still seems necessary. It might be that this was some automatic thing as this change was not mentioned in debian/changelog. Here's a summary of the upgrade failure: ~ # egrep 'treepy|ghub' /var/log/apt/term.log Preparing to unpack .../elpa-ghub_3.6.0-2_all.deb ... Remove elpa-ghub for emacs remove/ghub-0: Handling removal of emacsen flavor emacs Unpacking elpa-ghub (3.6.0-2) over (3.5.6-1) ... Removing elpa-treepy (0.1.2-2) ... Remove elpa-treepy for emacs remove/treepy-0.1.1: Handling removal of emacsen flavor emacs Setting up elpa-ghub (3.6.0-2) ... Install elpa-ghub for emacs install/ghub-3.6.0: Handling install of emacsen flavor emacs install/ghub-3.6.0: byte-compiling for emacs buck.el:37:1: Error: Cannot open load file: No such file or directory, treepy ghub-graphql.el:26:1: Error: Cannot open load file: No such file or directory, treepy ghub.el:1012:1: Error: Cannot open load file: No such file or directory, treepy glab.el:37:1: Error: Cannot open load file: No such file or directory, treepy gogs.el:37:1: Error: Cannot open load file: No such file or directory, treepy gtea.el:37:1: Error: Cannot open load file: No such file or directory, treepy ERROR: install script from elpa-ghub package failed dpkg: error processing package elpa-ghub (--configure): installed elpa-ghub package post-installation script subprocess returned error exit status 1 elpa-ghub -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (990, 'unstable'), (980, 'unstable-debug'), (600, 'testing'), (111, 'buildd-unstable'), (111, 'buildd-experimental'), (110, 'experimental'), (105, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Kernel: Linux 6.3.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-ghub depends on: ii dh-elpa-helper 2.0.16 ii emacsen-common 3.0.5 Versions of packages elpa-ghub recommends: ii emacs 1:28.2+1-15 ii emacs-gtk [emacs] 1:28.2+1-15 elpa-ghub suggests no packages. -- no debconf information
Bug#999918: [Pkg-zsh-devel] Bug#999918: Bug#999918: Bug#999918: zsh: depends on obsolete pcre3 library
Hi Bastian, Bastian Germann wrote: > zsh builds without libpcre3-dev installed. Yeah, I know. Did that before. > Please consider dropping the dependency until the next version is > released. Nope. That's only my last resort. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1036933: screen-udeb: Should screen really be installed setgid utmp?
Hi,
Sven Joachim wrote:
> Recently I noticed that the screen program in the screen-udeb
> package is installed setgid utmp, and I wonder if this actually
> makes any sense.
I suspect that setgid utmp indeed is not needed the installer context
from a general viewpoint, but screen is rather picky about its
permissions, especially setgid and setuid. (See below.) So our
decision back then was based on the following:
Screen has two supported ways to edit /var/log/wtmp:
A) via setgid utmp
B) via libutempter
Because we didn't want to pull in another library (libutempter) into
the installer when we created screen-udeb (and hence adding the need
to provide a libutempter udeb as well as libutempter freezes before
installer releases, etc.), we decided continue to use (A) for the
screen-udeb while the remainder of the screen package switched from
(A) to (B).
> While I do not have much experience with the installer, I would expect
> it to run all programs as root anyway, so there should be no need for
> setgid there.
Good point. Then again, it shouldn't do any harm for the very same
reason, right?
Screen is particular picky about its and /run/screen's permissions and
it might refuse to work if they're not set to one of the supported
permission combinations. See /usr/share/doc/screen/README.Debian.gz
So changing them definitely needs some additional tests. In general,
I'd prefer to avoid that, especially in the udeb where it does no
harm.
> Having screen installed setgid sets up a secure execution environment
> that precludes the use of certain environment variables, see the
> "Secure-execution mode" section in ld.so(8). Recently ncurses has also
> started to restrict such programs, see #1034372.
Thanks for that pointer, wasn't aware of that kind of feature. But I
fail to see how
https://invisible-island.net/ncurses/NEWS.html#index-t20230408 is
related.
https://invisible-island.net/ncurses/NEWS.html#index-t20230418 and
https://invisible-island.net/ncurses/NEWS.html#index-t20230423 look
more related, though. Maybe a typo in #1034372, 08 vs 18?
Anyway, IMHO ncurses should not care about setuid/setgid when already
called under root. It makes sense under any other user, though.
> Hopefully none of this matters much. I have CC'ed debian-boot, as the
> people working on the installer will be much more qualified to give
> advice than I am.
Cyril Brulebois wrote:
> Given the first sentence of this last paragraph, it looks like we're not
> considering doing anything for Bookworm at this time
That's also the reason why I didn't reply back in May: We were way to
deep into the Bookworm freeze to do anything on that front IMHO. And
the installer just worked fine with regards to its screen usage.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1005512: irqtop: Errors in man pages
Hi Helge, thanks for the bug report! Helge Kreutzmann wrote: > Finally the issues I'm reporting have accumulated over time and are > not always discovered by me, so sometimes my description of the > problem my be a bit limited - do not hesitate to ask so we can clarify > them. Yeah, I think that's the place where things went a bit wrong. > Man page: irqtop.1 > Issue:ethtool → B(8) I'm sorry, but this is a groff-written man page, but your suggested change seems POD syntax. > "show extra eth stats (from ethtool)" That line now renders in man like this: "show extra eth stats (from B(8))" I don't think that's wanted. Besides we render htop(1) and friends under "SEE ALSO" also without any special formatting. So I'll make it simply "ethtool(8)". > Man page: irqtop.1 > Issue:enouth → enough "enouth" neither is nor ever was in this Debian package. > "Show per-cpu statistics by specified mode. Available modes are: B, " > "B, B. The default option B detects the width of " > "window, then shows the per-cpu statistics if the width of window is large " > "enouth to show a full line of statistics." Neither is this text. A quick search on codesearch.debian.net reveals that this is part of the man page from the _other_ tool named irqtop, the one from util-linux: https://sources.debian.org/src/util-linux/2.38.1-5/sys-utils/irqtop.1.adoc/?hl=29#L29 Which is not yet shipped in a binary package in Debian as I didn't manage to start the migration between the two irqtops timely before the Bookworm freeze. Please report that error against src:util-linux. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1037264: bug#64058: [PATCH] wc: Fix crashes due to incomplete AVX2 enumeration
Control: tag 1037264 + patch
Hi Pádraig,
On Wed, Jun 14, 2023 at 11:46:58AM +0100, Pádraig Brady wrote:
> On 14/06/2023 05:14, Paul Eggert wrote:
> > Thanks for the bug report. I installed the attached patch into coreutils
> > on Savannah. It builds on your idea with several other changes:
> >
> > * There's a similar issue with cksum.c and pclmul.
> >
> > * configure.ac can be simplified, since it seems there's no point
> > compiling these instructions if __builtin_cpu_supports doesn't work.
> >
> > * This lets us simplify the source code a bit more.
> >
> > Please let me know if the attached patch works for you.
>
> __builtin_cpu_supports() looks to have sufficient support in
> Arch + compiler versions for our needs, so that's good.
>
> Paul you removed the "avx" check from cksum.c. Was that intended?
>
> > PS. Does the attached cksum.c / pclmul change fix any user-visible
> > misbehavior? If so, what should we put into the NEWS file?
>
> We have an illegal instruction issue with cksum under Xen DomU
> which may be related, as discussed at: https://bugs.debian.org/1037264
>
> Axel does the attached patch change anything for you?
Yes! This patch helps! Thanks a lot! :-)
Cc'ing the Debian bug report again (and doing a nearly fullquote for
that) and tagging Debian's bug report as containing a patch. (Given
it's high bug report number it should do any harm in GNU's BTS even if
it uses the same control syntax…)
> diff --git a/src/cksum.c b/src/cksum.c
> index 85afab0ac..881d90413 100644
> --- a/src/cksum.c
> +++ b/src/cksum.c
> @@ -160,29 +160,16 @@ static bool
> pclmul_supported (void)
> {
> # if USE_PCLMUL_CRC32
> - unsigned int eax = 0;
> - unsigned int ebx = 0;
> - unsigned int ecx = 0;
> - unsigned int edx = 0;
> -
> - if (! __get_cpuid (1, , , , ))
> -{
> - if (cksum_debug)
> -error (0, 0, "%s", _("failed to get cpuid"));
> - return false;
> -}
> -
> - if (! (ecx & bit_PCLMUL) || ! (ecx & bit_AVX))
> -{
> - if (cksum_debug)
> -error (0, 0, "%s", _("pclmul support not detected"));
> - return false;
> -}
> + bool pclmul_enabled = 0 < __builtin_cpu_supports ("pclmul")
> +&& 0 < __builtin_cpu_supports ("avx");
>
>if (cksum_debug)
> -error (0, 0, "%s", _("using pclmul hardware support"));
> +error (0, 0, "%s",
> + (pclmul_enabled
> +? _("using pclmul hardware support")
> +: _("pclmul support not detected")));
>
> - return true;
> + return pclmul_enabled;
> # else
>if (cksum_debug)
> error (0, 0, "%s", _("using generic hardware support"));
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1037264: cksum crashes intermittently with "Illegal instruction" on some Xen DomU
Hi, Pádraig Brady wrote: > At this stage it would be good to get the output from `cpuid -1` Ok, I've attached the output of "cpuid -1" from both affected DomUs (the outputs slightly differ) as well as of the unaffected hosting server (same CPU) for comparison. cpuid-domu1.txt and cpuid-domu2.txt is the output on the two affected DomUs (VMs) and cpuid-dom0.txt is the output on the (Debian 11) Xen hosting server. One more note: The Xen version running on the hosting server is 4.14.5+94-ge49571868d-1 (the one from Debian 11), in case that's of interest. HTH! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE cpuid-domu1.txt.gz Description: application/gzip cpuid-domu2.txt.gz Description: application/gzip cpuid-dom0.txt.gz Description: application/gzip signature.asc Description: PGP signature
Bug#1037264: cksum crashes intermittently with "Illegal instruction" on some Xen DomU
instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction […] This intensity happens on that DomU with both, with and without the patch and it doesn't seem to make a difference if e.g. debug symbols are installed or not. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE signature.asc Description: PGP signature
Bug#1037264: cksum crashes intermittently with "Illegal instruction" on some Xen DomU
Hi Kristoffer, Kristoffer Brånemyr wrote: > But I think it's a bit suspicious that it only crashes sometimes.If > there was some instruction which causes this, should it not happen > everytime? Good point. > Can you reproduce the problem running cksum in gdb? Yes: # dd if=/dev/urandom count=1 2> /dev/null | gdb -ex run -ex bt -batch cksum [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGILL, Illegal instruction. 0x5556ccf5 in cksum_pclmul (fp=0x77faca80 <_IO_2_1_stdin_>, crc_out=0x7fffe8d0, length_out=0x7fffe8c8) at src/cksum_pclmul.c:59 59 src/cksum_pclmul.c: No such file or directory. #0 0x5556ccf5 in cksum_pclmul (fp=0x77faca80 <_IO_2_1_stdin_>, crc_out=0x7fffe8d0, length_out=0x7fffe8c8) at src/cksum_pclmul.c:59 #1 0xabb0 in crc_sum_stream (stream=0x77faca80 <_IO_2_1_stdin_>, resstream=0x7fffe9f0, length=0x7fffe9e8) at src/cksum.c:269 #2 0x7eaa in digest_file (filename=filename@entry=0x5556d14f "-", bin_result=bin_result@entry=0x7fffe9f0 '/' , "\377", missing=missing@entry=0x7fffe9e0, length=length@entry=0x7fffe9e8, binary=) at src/digest.c:945 #3 0x71c7 in main (argc=1, argv=) at src/digest.c:1504 Does this help? Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1037264: cksum crashes intermittently with "Illegal instruction" on some Xen DomU
Package: coreutils Version: 9.1-1 Severity: important X-Debbugs-Cc: a...@debian.org Control: affects -1 aptitude-robot On a Xen DomU running Debian 12, cksum intermittently crashes as follows: # while :; do dd if=/dev/urandom count=1 2> /dev/null | cksum ; done 1758277878 512 2101634611 512 Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction 2704754638 512 Illegal instruction 4028135672 512 2625667858 512 Illegal instruction Illegal instruction Illegal instruction 3923394050 512 3125973555 512 Illegal instruction Illegal instruction Illegal instruction 4259853375 512 Illegal instruction Illegal instruction 81698826 512 Illegal instruction 3571110616 512 Illegal instruction 1587881588 512 Illegal instruction Illegal instruction Illegal instruction 2814380057 512 Illegal instruction Illegal instruction 2944809052 512 Illegal instruction 2902358677 512 Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction 935279575 512 Illegal instruction 456315694 512 Illegal instruction 469377998 512 Illegal instruction Illegal instruction Illegal instruction Illegal instruction 2550807941 512 Illegal instruction 3392916458 512 Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction 2092884162 512 Illegal instruction 3196356363 512 Illegal instruction 1701279083 512 Illegal instruction 1118990197 512 Illegal instruction 1455432166 512 Illegal instruction Illegal instruction 3772213637 512 Illegal instruction 3359021443 512 Illegal instruction 1472208906 512 Illegal instruction Illegal instruction Illegal instruction 530110239 512 1124879907 512 Illegal instruction 2364080335 512 Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction 1306677535 512 Illegal instruction 2367703624 512 Illegal instruction Illegal instruction Illegal instruction Illegal instruction 3730416712 512 Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction Illegal instruction 265751591 512 3833668362 512 Illegal instruction Illegal instruction 1086945333 512 Illegal instruction Illegal instruction 3420907443 512 Illegal instruction Illegal instruction Illegal instruction […] I was only able to reproduce this on a single host so far, hence no RC severity. (But feel free to bump to RC. :-) I tried and could NOT reproduce it on: * Debian 11 amd64 on real hardware (Intel(R) Core(TM) i7-6700 CPU; AMD EPYC 7313P 16-Core Processor; many more) * Debian 12 amd64 on real hardware (Intel(R) Core(TM) i7-6700T CPU; AMD EPYC 7742
Bug#999918: [Pkg-zsh-devel] Bug#999918: Bug#999918: zsh: depends on obsolete pcre3 library
Control: tag -1 + fixed-upstream Hi Jeremy, Jeremy Bícha wrote: > It looks like this was fixed upstream with > https://github.com/zsh-users/zsh/commit/b62e91134 Ah, nice. Thanks for the hint! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1036524: unblock: dokuwiki/0.0.20220731.a-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: dokuw...@packages.debian.org, a...@debian.org Control: affects -1 + src:dokuwiki Please unblock package dokuwiki/0.0.20220731.a-2 It fixes a XSS security issue (#1036279) for which upstream has released a hotfix for two upstream releases including the release "Igor" which is the one currently in Debian Sid/Bookworm. (There has happened a new major upstream release since the beginning of the freeze. See https://www.dokuwiki.org/changes for details) The Debian Security Team considers this issue to be of grave severity. [ Reason ] A cross-server-side (XSS) issue has been detected in DokuWiki's RSS feed generator. This is the security update to fix it. [ Impact ] DokuWiki installations will be exposed to an XSS security issue in the RSS feed generator in Debian 12 Bookworm, at least at release time. Given that the Debian Security Team considers the issue grave, it might be that the security team publishes more or less the same package as just uploaded also as DSA for Bookworm if it's not migrating to testing before the release. (Haven't asked them, though. I just based this on the severity they've given to the issue.) [ Tests ] * Ran for 2 days on a DokuWiki instance which I run on Debian Testing. * Tested viewing, editing and the RSS feed generation on that site. [ Risks ] The upstream fix is small-ish, but not straight forward and contains order changes where it's at least not obvious for me why. It though clearly adds some additional escaping to the code. (The version bump patch is though straight forward.) [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] I've included the whole difference between 2022-07-31a and 2022-07-31b in the upload (see the upstream diff at https://github.com/dokuwiki/dokuwiki/compare/release-2022-07-31a...release-2022-07-31b#files_bucket) in two patches (as they were split over two commits upstream) including the version and message version bump. Reasoning behind the latter is that security scanners potentially won't argue about about this being 2022-07-31a and being vulnerable to that XSS issue despite it isn't. So this is defacto an upgrade to the upstream hotfix version 2022-07-31b — which contains nothing but the XSS fix and a version bump. I've not used the upstream tar ball for the hotfix for that release as it dropped about 136 files from the tar ball. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036279#14 for the whole list of missing files. So please unblock dokuwiki/0.0.20220731.a-2 diff -Nru dokuwiki-0.0.20220731.a/debian/changelog dokuwiki-0.0.20220731.a/debian/changelog --- dokuwiki-0.0.20220731.a/debian/changelog2022-11-14 04:24:11.0 +0100 +++ dokuwiki-0.0.20220731.a/debian/changelog2023-05-21 15:01:45.0 +0200 @@ -1,3 +1,12 @@ +dokuwiki (0.0.20220731.a-2) unstable; urgency=high + + * Cherry pick upstream 2022-07-31b hotfix patches for the Igor release: ++ ba76f875: fix XSS in RSS syntax ++ b7fcf218: hotfix release for Igor +Closes: #1036279 + + -- Axel Beckert Sun, 21 May 2023 15:01:45 +0200 + dokuwiki (0.0.20220731.a-1) unstable; urgency=medium * Salvage package. (Closes: #1008649) diff -Nru dokuwiki-0.0.20220731.a/debian/patches/cherrypick_b7fcf218_hotfix_release_for_igor.patch dokuwiki-0.0.20220731.a/debian/patches/cherrypick_b7fcf218_hotfix_release_for_igor.patch --- dokuwiki-0.0.20220731.a/debian/patches/cherrypick_b7fcf218_hotfix_release_for_igor.patch 1970-01-01 01:00:00.0 +0100 +++ dokuwiki-0.0.20220731.a/debian/patches/cherrypick_b7fcf218_hotfix_release_for_igor.patch 2023-05-18 22:59:00.0 +0200 @@ -0,0 +1,30 @@ +From b7fcf218f1b2e858e7d41809d7dd291fc8a898f3 Mon Sep 17 00:00:00 2001 +From: Guy Brand +Date: Tue, 16 May 2023 12:49:38 +0200 +Subject: [PATCH] hotfix release a for Igor + +--- + VERSION | 2 +- + doku.php | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +diff --git a/VERSION b/VERSION +index 7658b60750..2800ff9b24 100644 +--- a/VERSION b/VERSION +@@ -1 +1 @@ +-2022-07-31a "Igor" ++2022-07-31b "Igor" +diff --git a/doku.php b/doku.php +index 50e3726327..f5117ee5eb 100644 +--- a/doku.php b/doku.php +@@ -11,7 +11,7 @@ + // update message version - always use a string to avoid localized floats! + use dokuwiki\Extension\Event; + +-$updateVersion = "53"; ++$updateVersion = "53.1"; + + // xdebug_start_profiling(); + diff -Nru dokuwiki-0.0.20220731.a/debian/patches/cherrypick_ba76f875_fix_xss_in_rss_syntax.patch dokuwiki-0.0.20220731.a/debian/patches/cherrypick_ba76f875_fix_xss_in_rss_syntax.patch --- dokuwiki-0.0.20220731.a/debian/patches/cherrypick_ba76f875_fix_xss_in_rss_syntax.patch 1970-01-01 01:00:00.0
Bug#1036384: dillo: Open file dialog pops up in /tmp
Control: severity -1 minor Control: tag -1 upstream Hi, José Luis González wrote: > When I pop up the Open file dialog it always opens in /tmp, forcing you > to change to home, which is where it should open. Where it should open is actually very subjective. And most open dialogs don't open in $HOME either but usually where you opened a file the last time. Which dillo does btw. to. (Ok, maybe not after it has been closed and started again.) /tmp/ is not the best choice but IMHO a valid one. At least I manually open HTML files in a browser most times in /tmp/ and not in $HOME. (And not, the fact that dillo does that is not a patch of mine, just coincidence. And probably the reason why I never noticed it.) Additionally there is the short cut Alt-H to directly jump to your home directory. > Besides, if I click on FLTK's shortcut for /, right up the Filename > text entry, it only displays kernel fs dirs: sys, proc, dev, run, and > subdirs of these. Indeed. But it actually shows all mount points (including /home/ for me). Which is maybe not expected, but kinda makes sense. It also includes / itself and when you click on that you get all files and directories in there. > The whole issue is a very serious usability issue. No, it's not. From my point of view both issues are actually very minor. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1036279: XSS in RSS syntax
manager/_test/csv_import.test.php - lib/plugins/usermanager/_test/mocks.class.php - vendor/aziraphale/email-address-validator/.gitignore - vendor/aziraphale/email-address-validator/composer.json - vendor/geshi/geshi/.editorconfig - vendor/geshi/geshi/.gitignore - vendor/geshi/geshi/composer.json - vendor/kissifrot/php-ixr/.editorconfig - vendor/kissifrot/php-ixr/.gitignore - vendor/kissifrot/php-ixr/composer.json - vendor/marcusschwarz/lesserphp/.gitignore - vendor/marcusschwarz/lesserphp/composer.json - vendor/openpsa/universalfeedcreator/.editorconfig - vendor/openpsa/universalfeedcreator/.gitattributes - vendor/openpsa/universalfeedcreator/.gitignore - vendor/openpsa/universalfeedcreator/composer.json - vendor/phpseclib/phpseclib/appveyor.yml - vendor/phpseclib/phpseclib/composer.json - vendor/simplepie/simplepie/composer.json - vendor/splitbrain/php-archive/.gitignore - vendor/splitbrain/php-archive/composer.json - vendor/splitbrain/php-cli/.gitignore - vendor/splitbrain/php-cli/composer.json - vendor/splitbrain/slika/.gitattributes - vendor/splitbrain/slika/.gitignore - vendor/splitbrain/slika/composer.json - vendor/splitbrain/slika/composer.lock So I'll likely just add the patch. I assume the release team is happier that way, too. P.S.: > https://huntr.dev/bounties/c6119106-1a5c-464c-94dd-ee7c5d0bece0/ Do you know if this content behind this link will become public at some time? Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1036246: unblock: iptables-netflow/2.6-4
Hi Sebastian, Axel Beckert wrote: > Please unblock iptables-netflow/2.6-4. Sorry, but I saw only now that you already granted an unblock today (well, actually yesterday in CEST as it's already past mightnight). I waited with the unblock request until I was able to test a full upgrade of a production-grade server using this package to make sure that it was properly working under production settings. (And for multiple, work and private reasons, this wasn't possible before this night.) Anyway, I've put quite some effort into testing this properly so shortly before the release, so you might want to have a look nevertheless. :-) P.S.: And thanks for also unblocking debsums recently. There I was waiting for some more feedback from Andreas, but noticed that it migrated to testing even before I started writing an unblock request. :-) P.P.S.: Please tell me if in future I should write unblock requests more earlier after the upload to spare the release team their own look at it. So far my mode of operation was to only file the unblock request if the package proved itself in unstable for a few days at least. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1036246: unblock: iptables-netflow/2.6-4
00 fix building on old kernels Link: https://github.com/aabc/ipt-netflow/pull/196 diff --git a/compat.h b/compat.h index 6be9d6b..847117f 100644 --- a/compat.h +++ b/compat.h @@ -782,7 +782,14 @@ struct module *find_module(const char *name) #endif #ifndef HAVE_NF_CT_EVENT_NOTIFIER_CT_EVENT +/* + * nat event callback parameter is constified in 5.15+ + * but it prevents module building with previous kernel versions + */ +# define NF_CT_EVENT struct nf_ct_event # define ct_event fcn +#else +# define NF_CT_EVENT const struct nf_ct_event #endif #endif /* COMPAT_NETFLOW_H */ diff --git a/ipt_NETFLOW.c b/ipt_NETFLOW.c index e042fe6..82805bc 100644 --- a/ipt_NETFLOW.c +++ b/ipt_NETFLOW.c @@ -4597,7 +4597,7 @@ static void rate_timer_calc( #ifdef CONFIG_NF_NAT_NEEDED #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,31) static struct nf_ct_event_notifier *saved_event_cb __read_mostly = NULL; -static int netflow_conntrack_event(const unsigned int events, const struct nf_ct_event *item) +static int netflow_conntrack_event(const unsigned int events, NF_CT_EVENT *item) #else static int netflow_conntrack_event(struct notifier_block *this, unsigned long events, void *ptr) #endif So please unblock iptables-netflow/2.6-4 diff -Nru iptables-netflow-2.6/debian/.gitignore iptables-netflow-2.6/debian/.gitignore --- iptables-netflow-2.6/debian/.gitignore 2023-01-20 11:27:09.0 +0100 +++ iptables-netflow-2.6/debian/.gitignore 1970-01-01 01:00:00.0 +0100 @@ -1,10 +0,0 @@ -/dkms -/files -/debhelper-build-stamp -/.debhelper/ -/*.debhelper.log -/*.p*.debhelper -/*.substvars -/iptables-netflow-dkms/ -/irqtop/ -/tmp/ diff -Nru iptables-netflow-2.6/debian/changelog iptables-netflow-2.6/debian/changelog --- iptables-netflow-2.6/debian/changelog 2023-01-20 11:27:09.0 +0100 +++ iptables-netflow-2.6/debian/changelog 2023-05-10 18:22:39.0 +0200 @@ -1,3 +1,11 @@ +iptables-netflow (2.6-4) unstable; urgency=medium + + * Acknowledge NMU. Thanks Andreas! + * Cherry-pick upstream commit 0901f028 "fix building on old kernels". + (Closes: #1035511) + + -- Axel Beckert Wed, 10 May 2023 18:22:39 +0200 + iptables-netflow (2.6-3.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru iptables-netflow-2.6/debian/patches/cherry-pick_0901f028_fix_building_on_old_kernels.patch iptables-netflow-2.6/debian/patches/cherry-pick_0901f028_fix_building_on_old_kernels.patch --- iptables-netflow-2.6/debian/patches/cherry-pick_0901f028_fix_building_on_old_kernels.patch 1970-01-01 01:00:00.0 +0100 +++ iptables-netflow-2.6/debian/patches/cherry-pick_0901f028_fix_building_on_old_kernels.patch 2023-05-10 17:21:46.0 +0200 @@ -0,0 +1,40 @@ +commit 0901f028617acca350132a65293ab80a480bf233 +Author: Vadim Fedorenko +Date: Mon Mar 28 21:59:10 2022 +0300 + +fix building on old kernels + +Link: https://github.com/aabc/ipt-netflow/pull/196 + +diff --git a/compat.h b/compat.h +index 6be9d6b..847117f 100644 +--- a/compat.h b/compat.h +@@ -782,7 +782,14 @@ struct module *find_module(const char *name) + #endif + + #ifndef HAVE_NF_CT_EVENT_NOTIFIER_CT_EVENT ++/* ++ * nat event callback parameter is constified in 5.15+ ++ * but it prevents module building with previous kernel versions ++ */ ++# define NF_CT_EVENT struct nf_ct_event + # define ct_event fcn ++#else ++# define NF_CT_EVENT const struct nf_ct_event + #endif + + #endif /* COMPAT_NETFLOW_H */ +diff --git a/ipt_NETFLOW.c b/ipt_NETFLOW.c +index e042fe6..82805bc 100644 +--- a/ipt_NETFLOW.c b/ipt_NETFLOW.c +@@ -4597,7 +4597,7 @@ static void rate_timer_calc( + #ifdef CONFIG_NF_NAT_NEEDED + #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,31) + static struct nf_ct_event_notifier *saved_event_cb __read_mostly = NULL; +-static int netflow_conntrack_event(const unsigned int events, const struct nf_ct_event *item) ++static int netflow_conntrack_event(const unsigned int events, NF_CT_EVENT *item) + #else + static int netflow_conntrack_event(struct notifier_block *this, unsigned long events, void *ptr) + #endif diff -Nru iptables-netflow-2.6/debian/patches/series iptables-netflow-2.6/debian/patches/series --- iptables-netflow-2.6/debian/patches/series 2023-01-20 11:27:09.0 +0100 +++ iptables-netflow-2.6/debian/patches/series 2023-05-10 17:21:58.0 +0200 @@ -4,3 +4,4 @@ dont-hardcode-current-gcc.patch cherry-pick_66e43041_namespace_sk_error_report.patch cherry-pick_6a55739a_fix_build_on_v5.15.patch +cherry-pick_0901f028_fix_building_on_old_kernels.patch
Bug#1035976: [Aptitude-devel] Bug#1035976: Bug#1035976: aptitude dies with SEGV
Hi Harald, Harald Dunkel wrote: > apparently it is not sufficient to just add the entry to sources.list.d. > I had to update the local cache to make aptitude die. Ok, another try: # pbuilder update --autocleanaptcache # pbuilder login ## apt install aptitude wget gpg ca-certificates ## wget -O- https://apt.releases.hashicorp.com/gpg | gpg --dearmor -o /etc/apt/trusted.gpg.d/hashicorp-archive-keyring.gpg ## echo "deb https://apt.releases.hashicorp.com bookworm main" > /etc/apt/sources.list.d/hashicorp.list ## apt update Hit:1 http://debian.ethz.ch/debian sid InRelease Get:2 https://apt.releases.hashicorp.com bookworm InRelease [12.9 kB] Get:3 https://apt.releases.hashicorp.com bookworm/main amd64 Packages [84.4 kB] ## aptitude TUI comes up. No crash. > > * Do you have any custom settings for settings influencing aptitude's > >package display like "Aptitude::UI::Package-Display-Format" or > >"Aptitude::UI::Default-Grouping"? > > No, I just have > > # cat .aptitude/config Looks harmless indeed. > > * Under which locale settings does it happen for you? > > On some systems I have set LANG=C or LANG=en_US.UTF-8, but I can reproduce > this using > > # locale > LANG= > LANGUAGE= > LC_CTYPE="POSIX" > LC_NUMERIC="POSIX" > LC_TIME="POSIX" > LC_COLLATE="POSIX" > LC_MONETARY="POSIX" > LC_MESSAGES="POSIX" > LC_PAPER="POSIX" > LC_NAME="POSIX" > LC_ADDRESS="POSIX" > LC_TELEPHONE="POSIX" > LC_MEASUREMENT="POSIX" > LC_IDENTIFICATION="POSIX" > LC_ALL= > > I doubt that this is related to the locale. Thanks. I indeed think we can rule that out, too. Then again, I'm out of ideas now, except for looking with strace where the crash happens. > > If you neither use any of these settings nor use a non-english locale, > > is there any chance that you can install these packages (for > > bookworm/sid, otherwise run "find-dbgsym-packages aptitude" from the > > debian-goodies package) on one of the affected machines: > > > > strace aptitude-dbgsym libapt-pkg6.0-dbgsym > > libboost-iostreams1.74.0-dbgsym libbz2-1.0-dbgsym libc6-dbg > > libcap2-dbgsym libcwidget4-dbgsym libelogind0-dbgsym libgcc-s1-dbgsym > > libgcrypt20-dbgsym libgpg-error0-dbgsym liblz4-1-dbgsym > > liblzma5-dbgsym libncursesw6-dbgsym libsigc++-2.0-0v5-dbgsym > > libsqlite3-0-dbgsym libstdc++6-dbgsym libtinfo6-dbgsym libudev1-dbgsym > > libuuid1-dbgsym libxapian30-dbgsym libxxhash0-dbgsym libzstd1-dbgsym > > zlib1g-dbgsym > > > > libelogind0? This breaks systemd. Ah, sorry, didn'y notice that. Wanted to avoid that you need to install debian-goodies for find-dbgsym-packages so I ran "find-dbgsym-packages --all aptitude" on one of my systems. Seems as if the output actually depends on which alternatives have been chosen on the local system. Of course libsystemd0-dbgsym is fine as well if you have libsystemd0 installed. (I also doubt that all of these are really necessary. Probably "aptitude-dbgsym libapt-pkg6.0-dbgsym libboost-iostreams1.74.0-dbgsym libcwidget4-dbgsym libgcc-s1-dbgsym libncursesw6-dbgsym libsigc++-2.0-0v5-dbgsym libxapian30-dbgsym" already suffice to cover everything which might be involved in such a crash, especially since it does not happen when downloading or accessing the package lists.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035976: [Aptitude-devel] Bug#1035976: aptitude dies with SEGV
Control: tag -1 + unreproducible moreinfo Hi Harald, Harald Dunkel wrote: > For testing I scanned all additional repositories in my sources.list.d. > It dies about > > deb [arch=amd64 > signed-by=/etc/apt/trusted.gpg.d/hashicorp-archive-keyring.gpg] > https://apt.releases.hashicorp.com bookworm main > > see https://www.hashicorp.com/official-packaging-guide. Sorry to bother you again, but while this looked very good as potential cause (or actually still does), I can't reproduce it inside a Sid pbuilder chroot. So I assume there's another detail which is required, too, to reproduce it. Some more ideas to check: * Do you have any custom settings for settings influencing aptitude's package display like "Aptitude::UI::Package-Display-Format" or "Aptitude::UI::Default-Grouping"? * Under which locale settings does it happen for you? If you neither use any of these settings nor use a non-english locale, is there any chance that you can install these packages (for bookworm/sid, otherwise run "find-dbgsym-packages aptitude" from the debian-goodies package) on one of the affected machines: strace aptitude-dbgsym libapt-pkg6.0-dbgsym libboost-iostreams1.74.0-dbgsym libbz2-1.0-dbgsym libc6-dbg libcap2-dbgsym libcwidget4-dbgsym libelogind0-dbgsym libgcc-s1-dbgsym libgcrypt20-dbgsym libgpg-error0-dbgsym liblz4-1-dbgsym liblzma5-dbgsym libncursesw6-dbgsym libsigc++-2.0-0v5-dbgsym libsqlite3-0-dbgsym libstdc++6-dbgsym libtinfo6-dbgsym libudev1-dbgsym libuuid1-dbgsym libxapian30-dbgsym libxxhash0-dbgsym libzstd1-dbgsym zlib1g-dbgsym And then run "strace -o aptitude-1035976.strace aptitude" and send me that file? (Probably best in compressed form.) Because that's what I just wanted to do if I would have been able to reproduce it. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035976: [Aptitude-devel] Bug#1035976: aptitude dies with SEGV
Hi Harald, Harald Dunkel wrote: > For testing I scanned all additional repositories in my sources.list.d. > It dies about > > deb [arch=amd64 > signed-by=/etc/apt/trusted.gpg.d/hashicorp-archive-keyring.gpg] > https://apt.releases.hashicorp.com bookworm main Thanks for figuring out that. Will see if I can figure out more. > I don't know who is to blame here, but I hope this helps I currently asssume that there is some field unset in their repo meta data, which aptitude's GUI (and only the GUI) expects to be set unconditionally. I guess stracing will reveal some more details. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035976: [Aptitude-devel] Bug#1035976: aptitude dies with SEGV
Control: found -1 0.8.13-3
Control: tag -1 + moreinfo
Hi Harald,
Harald Dunkel wrote:
> Running aptitude without arguments in a ssh session to a remote
> host I see the "loading cache" message as usual, but then it dies
> with
>
> Ouch! Got SIGSEGV, dying..
> Segmentation fault
>
> aptitude update, upgrade etc work without problems, AFAICT.
I assume this happens primarily as root on the remote host.
> I can reproduce this on several remote hosts running Bullseye or
> Testing,
Marking as found in 0.8.13-3 then.
> so it must be related to my environment somehow (Testing
> on a desktop PC), but it doesn't tell.
Ack. Doesn't look like a repo issue. Except maybe, if there's a common
non-debian APT repo involved.
Oh, and since about when is this happening? I assume this showed up
only recently, not for years. :-)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035511: iptables-netflow-dkms: fails to upgrade from bullseye: fails to build a module for the bullseye kernel
Control: tag -1 + patch pending
Hi Andreas,
Axel Beckert wrote:
> Looking through upstream's commits, I suspect cherrypicking this
> upstream commit might fix it:
>
> https://github.com/aabc/ipt-netflow/commit/0901f028617acca350132a65293ab80a480bf233
Yep, cherry-picking that one fixed it. Looks like a regression
introduced by 6a55739a ("Fix build on v5.15 (ct_event)") which I
cherry-picked in 2.6-3.
So thanks again for the report. Upload should happen in the next few
hours.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035511: iptables-netflow-dkms: fails to upgrade from bullseye: fails to build a module for the bullseye kernel
Hi Andreas, Andreas Beckmann wrote: > On 10/05/2023 16.32, Axel Beckert wrote: > > BUILD_EXCLUSIVE_* would be my currently slightly preferred approach as > > it's likely much simpler to implement and its impact is more clear, > > but not necessarily "smaller". Currently trying to figure out how it > > actually works. > > its a regex, like (untested): > # 6.1+ > BUILD_EXCLUSIVE_KERNEL="([7-9]|6\.[1-9]|6\.[1-9][0-9])\..*" Thanks for the prompt and helpful reply! > > > this will be easier from bookworm+1 onwards). > > > > Ok. Well, I'll see. > > BUILD_EXCLUSIVE_KERNEL_MIN="6.1" Indeed easier. :-) > My preference would be to fix the module to build with the bullseye > kernel, Thanks for that comment as well. > Whenever that breaks again after an update to the kernel in > bullseye, it probably breaks the module in bullseye, too. Chances are there, but at least this breakage doesn't seem to have happend in Bullseye. Looking through upstream's commits, I suspect cherrypicking this upstream commit might fix it: https://github.com/aabc/ipt-netflow/commit/0901f028617acca350132a65293ab80a480bf233 commit 0901f028617acca350132a65293ab80a480bf233 Author: Vadim Fedorenko Date: Mon Mar 28 21:59:10 2022 +0300 fix building on old kernels Link: https://github.com/aabc/ipt-netflow/pull/196 diff --git a/compat.h b/compat.h index 6be9d6b..847117f 100644 --- a/compat.h +++ b/compat.h @@ -782,7 +782,14 @@ struct module *find_module(const char *name) #endif #ifndef HAVE_NF_CT_EVENT_NOTIFIER_CT_EVENT +/* + * nat event callback parameter is constified in 5.15+ + * but it prevents module building with previous kernel versions + */ +# define NF_CT_EVENT struct nf_ct_event # define ct_event fcn +#else +# define NF_CT_EVENT const struct nf_ct_event #endif #endif /* COMPAT_NETFLOW_H */ diff --git a/ipt_NETFLOW.c b/ipt_NETFLOW.c index e042fe6..82805bc 100644 --- a/ipt_NETFLOW.c +++ b/ipt_NETFLOW.c @@ -4597,7 +4597,7 @@ static void rate_timer_calc( #ifdef CONFIG_NF_NAT_NEEDED #if LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,31) static struct nf_ct_event_notifier *saved_event_cb __read_mostly = NULL; -static int netflow_conntrack_event(const unsigned int events, const struct nf_ct_event *item) +static int netflow_conntrack_event(const unsigned int events, NF_CT_EVENT *item) #else static int netflow_conntrack_event(struct notifier_block *this, unsigned long events, void *ptr) #endif Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035511: iptables-netflow-dkms: fails to upgrade from bullseye: fails to build a module for the bullseye kernel
affect some future kernels at some point in the future and _might_ cause a very similar issue for late upgraders again. Not sure if any of that makes any of the two solutions "the better one", but I have a slight preference to the variant with the quite clear impact.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035839: closed by Debian FTP Masters (reply to Rafael Laboissière ) (Bug#1035839: fixed in jed 1:0.99.20~pre.178+dfsg-4)
Hi Rafael, Debian Bug Tracking System wrote: > jed (1:0.99.20~pre.178+dfsg-4) unstable; urgency=medium > . >* d/jed-common.preinst: Avoid non-fatal abortion of the script. > Thanks to Axel Beckert for the fix (Closes: #1035839) Thanks! Just wanted to confirm that I could now upgrade jed and jed-common without issues from 1:0.99.20~pre.178+dfsg-1 to 1:0.99.20~pre.178+dfsg-4. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035839: jed-common: Fails to upgrade: new jed-common package pre-installation script subprocess returned error exit status 1
Package: jed-common Version: 1:0.99.20~pre.178+dfsg-3 Severity: serious Hi, I'm sorry to say, but it now fails elsewhere to upgrade from 1:0.99.20~pre.178+dfsg-1 to 1:0.99.20~pre.178+dfsg-3: Preparing to unpack .../01-jed_1%3a0.99.20~pre.178+dfsg-3_amd64.deb ... Unpacking jed (1:0.99.20~pre.178+dfsg-3) over (1:0.99.20~pre.178+dfsg-1) ... Preparing to unpack .../02-jed-common_1%3a0.99.20~pre.178+dfsg-3_all.deb ... dpkg: error processing archive /tmp/apt-dpkg-install-UN0WZQ/02-jed-common_1%3a0.99.20~pre.178+dfsg-3_all.deb (--unpack): new jed-common package pre-installation script subprocess returned error exit status 1 […] Errors were encountered while processing: /tmp/apt-dpkg-install-UN0WZQ/02-jed-common_1%3a0.99.20~pre.178+dfsg-3_all.deb […] dpkg: dependency problems prevent configuration of jed: jed depends on jed-common (= 1:0.99.20~pre.178+dfsg-3); however: Version of jed-common on system is 1:0.99.20~pre.178+dfsg-1. dpkg: error processing package jed (--configure): dependency problems - leaving unconfigured I think that cause is this line in combination with "set -e" test -d $txtdir && rm -rf $txtdir If the directory does not exist, it returns false because the test failed. And due to the (totally legit) "set -e" it aborts there with exit code not equal zero. You likely need to replace it with a full if clause: if [ -d $txtdir ] ; then rm -rf $txtdir ; fi Such code will not have this side effect. -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'testing-security'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages jed-common depends on: pn slsh jed-common recommends no packages. Versions of packages jed-common suggests: ii emacs-gtk [info-browser] 1:28.2+1-14 ii info [info-browser] 6.8-6+b1 iu jed [info-browser]1:0.99.20~pre.178+dfsg-3 ii konqueror [info-browser] 4:22.12.3-1 ii pinfo [info-browser] 0.6.13-1.3 -- no debconf information -- debsums errors found: debsums: changed file /usr/share/doc/jed-common/changelog.Debian.gz (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/abbrev.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/color.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/compile.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/dfa.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/edt.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/emacs.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/filelock.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/fold.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/hooks.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/ide-mode.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/jed_faq.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/linux-keys.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/menus.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/mouse.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/pc-keys.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/program.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/recentx.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/rgrep.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/rmail.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/script.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/sessions.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/syntax.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/undo.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/utf8.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/wjed.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/wordstar.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/xjed.txt (from jed-common package) debsums: missing file
Bug#1035780: jed-common: Fails to upgrade: unable to install new version of '/usr/share/jed/doc/txt/abbrev.txt': No such file or directory
Package: jed-common Version: 1:0.99.20~pre.178+dfsg-2 Severity: serious jed-common fails to upgrade from 1:0.99.20~pre.178+dfsg-1 to 1:0.99.20~pre.178+dfsg-2 for me as follows: Preparing to unpack .../4-jed-common_1%3a0.99.20~pre.178+dfsg-2_all.deb ... Unpacking jed-common (1:0.99.20~pre.178+dfsg-2) over (1:0.99.20~pre.178+dfsg-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-OeNOOg/4-jed-common_1%3a0.99.20~pre.178+dfsg-2_all.deb (--unpack): unable to install new version of '/usr/share/jed/doc/txt/abbrev.txt': No such file or directory […] dpkg: dependency problems prevent configuration of jed: jed depends on jed-common (= 1:0.99.20~pre.178+dfsg-2); however: Version of jed-common on system is 1:0.99.20~pre.178+dfsg-1. dpkg: error processing package jed (--configure): dependency problems - leaving unconfigured […] Errors were encountered while processing: jed -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'testing-security'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages jed-common depends on: ii slsh 2.3.3-3 jed-common recommends no packages. Versions of packages jed-common suggests: ii emacs-gtk [info-browser] 1:28.2+1-14 ii info [info-browser] 6.8-6+b1 iu jed [info-browser]1:0.99.20~pre.178+dfsg-2 ii konqueror [info-browser] 4:22.12.3-1 ii pinfo [info-browser] 0.6.13-1.3 -- no debconf information -- debsums errors found: debsums: changed file /usr/share/doc/jed-common/changelog.Debian.gz (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/abbrev.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/color.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/compile.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/dfa.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/edt.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/emacs.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/filelock.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/fold.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/hooks.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/ide-mode.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/jed_faq.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/linux-keys.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/menus.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/mouse.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/pc-keys.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/program.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/recentx.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/rgrep.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/rmail.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/script.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/sessions.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/syntax.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/undo.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/utf8.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/wjed.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/wordstar.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/xjed.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/xrenderfont.txt (from jed-common package) debsums: missing file /usr/share/doc/jed-common/txt/yankpop.txt (from jed-common package)
Bug#1035734: Acknowledgement (Does not search for terms in latin1 encoding anymore)
Hi, Klaus Ethgen wrote: > I found the bug. Great. Sorry for my just sent reply then. Saw your second mail only after sending it. > The bug is in the color code. Oh, ok, that's probably my code then, yes. > The replacement of $SEARCH in the new display function can never match > for latin1 chars as it is still UTF-8. So either use the original search > string here or convert it back to local locale. Ok, will have a closer look. Don't see the right place for a fix on a first glance. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035734: Does not search for terms in latin1 encoding anymore
Control: tag -1 + moreinfo Hi Mowgli, Klaus Ethgen wrote: > I usually have latin1-Encoding everywhere. The output of translate is > good but the input does not allow latin1-umlauts like ä, ö, ü, ... I can > input them but they always returns nothing. Interesting, thanks for the bug report. > Older versions worked well but I cannot say, when the incompatibility > was implemented. At least version 0.6 worked well. Can you check which Debian package of 0.6? All recent (non-comment) UTF-8 related changes I see in the git log seemed to have been in 0.6-6 and 0.6-7. Which actually were long ago (2005). Just a thought: Could it be that this change in Debian's locales could have caused some unexpected side effect on already configured non-UTF-8 locales? locales (2.31-14) unstable; urgency=low * Starting with locales 2.31-14, non UTF-8 locales are deprecated and not offered anymore in the debconf dialog, except for the ones already configured. Nevertheless users of non UTF-8 locales are encouraged to switch their system to an UTF-8 locale. Please note that iconv still supports conversion to and from non UTF-8 charset. For instance reading a file using an ISO-8859-15 charset can be done with: iconv --from-code=ISO-8859-15 foobar.txt -- Aurelien Jarno Tue, 17 Aug 2021 16:27:59 +0200 > The strange thing is, that I see no reason for the bug. Even when I do > `bash -x /usr/bin/translate ...` it DOES iconv my input. But if I just > do `/usr/bin/translate ...`, it doesn't. This bug is a full riddle for > me. […] > Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Or could this LC_CTYPE with C.UTF-8 be the reason? Because this would likely cause $UTF8 to be set in the script: UTF8=0 if locale 2>&1 | grep -E -q "UTF-8?$"; then UTF8=1 fi Actually I just now noticed a typo in that regexp. It likely should be "UTF-?8$" and not "UTF-8?$" (i.e. the dash is optional, not the digit eight). That typo is now fixed in git. (I though don't think that this typo caused your issue. It could have caused issues the other way around: Not properly detected UTF-8 locales.) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035679: [Pkg-zsh-devel] Bug#1035679: zsh: can misprocess continue in a loop
Control: tag -1 + fixed-upstream confirmed Control: found -1 5.0.7-5 Hi Brian, brian m. carlson wrote: > If a continue occurs in an && chain inside a loop, the continue is not > effective. For example, if you save the following as foo.sh: Thanks for the bug report. > This breaks the Git testsuite under zsh's sh mode, Hmmm, actually, your example code shows "set" for me even without sh emulation mode: → zsh continue.sh set → zsh --emulate sh continue.sh set > which was formerly passing. When was "formerly", i.e. in which package or upstream version? > There's a patch upstream at > https://github.com/zsh-users/zsh/commit/12e5db145b098a62ff11b88eea26f473ea2ecdcf. Actually the lines changed in the upstream fix were last changed in the year 2000. And I was able to reproduce this issue in zsh 5.0.7 from Debian 8 Jessie (now ELTS). So it's in there for probably at least 23 years and clearly not a recent regression — if it's a regression at all. (I kinda doubt it with my current state of knowledge.) So I suspect that the Git testsuite only recently started to use "continue &&" recently? Then actually only find only a single occurence of "continue &&" (which is not "--continue &&" or suchlike) and that one seems to be a comment: t/t3418-rebase-continue.sh: : skip and continue && And the test which contains that (suspected) comment was added in 2018 in commit d5bc6f292ab0a1715ff021f5854ac5a81c2b88b0. > It would be great if this could be backported to zsh in Debian, Can do, but for Bookworm this is likely too late as we're now in the last stage of the freeze with the release planned for in one month and this change clearly changes a longtime zsh behaviour. > since the release cycle tends to be long Well, 5.9 is out for quite a while already. So I think we can expect a new release before the the Debian 13 release. ;-) But yeah, I think we can cherry-pick this from upstream after the Bookworm release. > and it prevents the shell from being effectively used as a POSIX sh. Well, zsh's POSIX mode is officially declared as being incomplete and it's IIRC also not recommended to actually use it or at least not rely on it. Also upstream's statements like "probably ought to be regarded as a bug" and "However, it's not logically wrong, either." sound as if it's more a bug by goodwill, not by conviction. And I must admit that "continue &&" as bash, ksh and all others process it IMHO makes less sense than how zsh used to do it. That's probably what upstream meant with "it's not logically wrong". But let's follow upstream here. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Hi Emanuele, Emanuele Rocca wrote: > On 2023-05-03 08:16, Axel Beckert wrote: > > Machine: Thinkpad X13s (ARM) > > Sorry, I've realized only after sending my previous message and having a > coffee that this is about the X13s. :) :-) > The X13s is unfortunately not supported by Linux 6.1 that Bookworm will > ship with. Oh, ok. I see. > Hopefully 6.4 will include all the needed patches. xnox's image uses 6.2 so far, i.e. also something newer than 6.1. > > But Dimitri's Ubuntu Installer Live image lunar-desktop-arm64.iso from > > https://people.canonical.com/~xnox/ubuntu-concept/full/daily-live/current/ > > as of 2023-03-07 20:08 booted fine without these issues. > > > > It would be nice if Dimitri (xnox@d.o, Cc'ed) could tell us which fix > > has been applied by him (or Ubuntu) to this image so that we can fix > > this issue also in Debian, maybe even before the release of Bookworm. > > If that image works, then it includes quite a few of out of tree kernel > patches. I see. I kinda hoped it would just be some not enabled drivers or bugs in the .dtb file or so as the D-I RC2 announcement mentioned the X13s explicitly (admittelly only with flash-kernel having gotten support for it). > As per [1] they are unfortunately not going to be applied to > the Debian kernel, we have to wait for upstream inclusion. Sure. I intend to run Debian Unstable on it anyway, so I can wait. :-) Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035483: debsums: false positives on removed conffiles retaining a remove-on-upgrade entry in Conffiles
Axel Beckert wrote: > Thanks for the bug report. Actually this is not new, but I seem to > unfortunately have forgotton about it: https://bugs.debian.org/993714 > — hence merging. Actually its even more embarrassing: A patch for that is already in Git, albeit a bit less elegant and maybe less performant: https://salsa.debian.org/perl-team/modules/packages/debsums/-/commit/d267a1b6fe538c45d8b2c87a8df65638f2d778af But together with other commits. So what is in the default branch is unsuitable for a freeze exception. So any upload will likely come from a bookworm-specific branch and maybe should be a 3.0.2.1 release instead of the prospective 3.0.3 in the default branch. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035483: debsums: false positives on removed conffiles retaining a remove-on-upgrade entry in Conffiles
Control: tag -1 + patch
Control: forcemerge -1 993714
Hi Andreas,
Andreas Beckmann wrote:
> # debsums -ac --ignore-obsolete pkg-config ; echo $?
> debsums: missing file /etc/dpkg/dpkg.cfg.d/pkg-config-hook-config (from
> pkg-config:amd64 package)
> 2
>
> while after a fresh install in bookworm the Conffiles entry is
> different:
>
> Conffiles:
> /etc/dpkg/dpkg.cfg.d/pkg-config-hook-config newconffile remove-on-upgrade
>
> and debsums does not complain:
>
> # debsums -ac --ignore-obsolete pkg-config ; echo $?
> 0
Thanks for the bug report. Actually this is not new, but I seem to
unfortunately have forgotton about it: https://bugs.debian.org/993714
— hence merging.
> I assume that dpkg is correct and debsums is at fault here ...
Probably, yes.
> A quick fix that works for me (and piuparts) is in line 268
>
> -grep { not ($ignore_obsolete and / obsolete$/) }
> +grep { not ($ignore_obsolete and /
> (obsolete|remove-on-upgrade)$/) }
Thanks for the patch.
Regarding the impact of both, the issue as well as the patch, I
checked how widespread it already is:
https://codesearch.debian.net/search?q=remove-on-upgrade+path%3Adebian%2F=1
shows only these packages:
chromium
crowdsec
crowdsec-custom-bouncer
crowdsec-firewall-bouncer
debhelper
dpkg-repack
freedombox
lintian
phog
pkgconf
qcontrol
resolvconf
sxmo-utils
wyrd
If I drop the "path:debian/", it also shows dpkg. But e.g. lintian
listed above only mentions it in debian/changelog. Same counts for
dpkg-repack and debhelper. So about a dozen of potentially affected
packages.
So currently the overall impact seems not that big, neither for the
bug nor for the proposed fix.
But since piuparts might report failures because of that, I do see the
reasoning for the RC severity despite the previous bug report was just
"normal" — probably the reason why I forgot about it. :-/
Admittedly I'm not keen on modifying debsums behaviour at this stage
of the freeze. Then again, your patch is small and clear.
I'll see that I make some testing and then an upload with that patch
and request a freeze exception latest at the upcoming weekend.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1035477: installation-reports: grub or kernel of D-I image hangs on Thinkpad X13s after "EFI stub: Exiting boot services..."
Package: installation-reports Severity: normal Tags: d-i X-Debbugs-Cc: Axel Beckert , Dimitri Ledkov , Debian ARM Mailing List , Manuel Traut Boot method: USB Image version: https://cdimage.debian.org/cdimage/bookworm_di_rc2/arm64/iso-cd/debian-bookworm-DI-rc2-arm64-netinst.iso Date: 2023-05-03, several times between noon and evening (CEST) Machine: Thinkpad X13s (ARM) Partitions: didn't come that far Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card:[ ] Configure network: [ ] Detect media: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: [Note: Had to disable Secure Boot, to be able to boot from my USB 3.0 stick (plugged into the Thinkpad USB-C docking station). Before disabling Secure Boot I could choose it as boot device but I was always immediately returned to the device's boot device selection menu.] After choosing either "expert install" (first and prefered try) or "graphical expert install" (second try and second choice) I saw these three lines and then nothing more happened: EFI stub: Booting Linux Kernel... EFI stub: Using DTB from configuration table EFI stub: Exiting boot services... Waited 10 minutes at least, i.e. left it alone, did something else and came back later. Even adding the "debug" kernel parameter didn't bring up any more details on what's happening. Ubuntu seems to have had the same problem with Kinetic according to https://www.reddit.com/r/thinkpad/comments/vh1xse/comment/is1pq78/ But Dimitri's Ubuntu Installer Live image lunar-desktop-arm64.iso from https://people.canonical.com/~xnox/ubuntu-concept/full/daily-live/current/ as of 2023-03-07 20:08 booted fine without these issues. It would be nice if Dimitri (xnox@d.o, Cc'ed) could tell us which fix has been applied by him (or Ubuntu) to this image so that we can fix this issue also in Debian, maybe even before the release of Bookworm. (I only read in the recent D-I RC2 annoucement that there is already some support for the X13s, so I haven't tried it beforehand.) -- Package-specific info: [Stripped as — for obvious reasons — the bug report has been written on a different device.]
Bug#1034132: unblock: dpmb/0~2023.03.11
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: d...@packages.debian.org Control: affects -1 + src:dpmb Please unblock package dpmb/0~2023.03.11 DPMB = Debian Packaging Management (E-)Book [ Reason ] Content of the e-book has been updated for the Bookworm release, describing changes like non-free-firmware, Stretch being now ELTS, vrms has been renamed to check-dfsg-status, etc. Sections about package management related packages which are no more in any supported Debian release have been removed from the book. [ Impact ] Without the update, changes in Bookworm won't be covered in Bookworm. [ Tests ] The e-book (and package) built fine on Sid in three different types of environment: locally, local minimal pbuilder chroot as well as on the buildd. Buildd-built HTML, EPUB and PDF variants have been skimmed through for proper formatting. (HTML with Chromium, EPUB and PDF with mupdf.) The Mobi version for Kindle devices hasn't been checked as I don't have a Kindle device. But is converted from the EPUB version using Calibre's ebook-convert. [ Risks ] Other book content has been updated or expanded, too. Changed or added content might have introduced typos or other content issues. [ Checklist ] [x] all (non-content) changes are documented in the d/changelog [x] I made all (non-content) changes and I approve them [x] attach debdiff against the package in testing [ Other info ] debdiff of the non-content changes: diff -Nru dpmb-0~2021.03.01/debian/changelog dpmb-0~2023.03.11/debian/changelog --- dpmb-0~2021.03.01/debian/changelog 2021-03-01 00:56:34.0 +0100 +++ dpmb-0~2023.03.11/debian/changelog 2023-03-12 00:34:38.0 +0100 @@ -1,3 +1,16 @@ +dpmb (0~2023.03.11) unstable; urgency=medium + + * The Debian 12 Bookworm Edition. ++ Covers non-free-firmware archive section. ++ Debian 9 Stretch is now ELTS. + * Bracketize sole lintian override so far. + * Add lintian override for very-long-line-length-in-source-file on +binary file and handwritten Markdown files with a few long semantic +HTML oneliners. + * Declare compliance with Debian Policy 4.6.2. (No changes needed.) + + -- Axel Beckert Sat, 11 Mar 2023 23:34:38 + + dpmb (0~2021.03.01) unstable; urgency=medium * New snapshot diff -Nru dpmb-0~2021.03.01/debian/control dpmb-0~2023.03.11/debian/control --- dpmb-0~2021.03.01/debian/control2021-02-03 04:27:56.0 +0100 +++ dpmb-0~2023.03.11/debian/control2023-03-12 00:32:59.0 +0100 @@ -10,7 +10,7 @@ dblatex, texlive-lang-german, xmlto -Standards-Version: 4.5.1 +Standards-Version: 4.6.2 Homepage: https://www.dpmb.org/ Vcs-Git: https://github.com/dpmb/dpmb.git Vcs-Browser: https://github.com/dpmb/dpmb diff -Nru dpmb-0~2021.03.01/debian/lintian-overrides dpmb-0~2023.03.11/debian/lintian-overrides --- dpmb-0~2021.03.01/debian/lintian-overrides 2016-06-29 23:15:14.0 +0200 +++ dpmb-0~2023.03.11/debian/lintian-overrides 2023-03-12 00:20:22.0 +0100 @@ -1,2 +1,2 @@ # Feature request against doc-base, see https://bugs.debian.org/730240 -debian-paketmanagement-buch: doc-base-file-unknown-format debian-paketmanagement-buch:14 epub +debian-paketmanagement-buch: doc-base-file-unknown-format epub [usr/share/doc-base/debian-paketmanagement-buch.debian-paketmanagement-buch:14] diff -Nru dpmb-0~2021.03.01/debian/source/lintian-overrides dpmb-0~2023.03.11/debian/source/lintian-overrides --- dpmb-0~2021.03.01/debian/source/lintian-overrides 1970-01-01 01:00:00.0 +0100 +++ dpmb-0~2023.03.11/debian/source/lintian-overrides 2023-03-12 00:28:25.0 +0100 @@ -0,0 +1,6 @@ +# Binary file +dpmb source: very-long-line-length-in-source-file 1296 > 512 [praxis/apt-cache/apt-cache.dia:2] + +# Handwritten Markdown with a few long semantic HTML oneliners +dpmb source: very-long-line-length-in-source-file * > 512 [README.mdwn:64] +very-long-line-length-in-source-file * > 512 [LICENSE.md:3] Full debdiff attached. So please unblock dpmb/0~2023.03.11 Thanks in advance! dpmb_0~2021.03.01_0~2023.03.11.dsc.debdiff.xz Description: application/xz
Bug#1033623: [Aptitude-devel] Bug#1033623: aptitude TUI does not provide a way to invoke "safe-upgrade" command
Control: severity -1 wishlist Control: tag -1 + confirmed Hi, Piotr Dąbrowski wrote: > There is no way to invoke "safe-upgrade" command from aptitude TUI. Indeed. Never noticed (or missed that) so far in like two decades of using aptitude. I though agree that there are cases where this might helpful. > Maybe a new menu item and a shortcut should be added for "safe-upgrade"? Yes, that's a good idea. Maybe I or Y (just beside U on most keyboard layouts). > Or "U" replaced with "safe-upgrade", while "full-upgrade" given a new > shortcut? I don't think that's a good idea as it breaks current TUI workflows and the muscle memory of users. > Or a dialog could ask which type of upgrade the user wants to > invoke? Neither that, for the same reason. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1033487: apt: apt-get says "This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details." but apt-secure(8) doesn't tell where or how
Package: apt Version: 2.6.0 Control: found -1 1.8.2.3 "apt-get update" says: E: Repository 'https://debian.ethz.ch/debian experimental InRelease' changed its 'Codename' value from 'experimental' to 'rc-buggy' N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details. But apt-secure(8) does not explain how to actually accept it: INFORMATION CHANGES A Release file contains beside the checksums for the files in the repository also general information about the repository like the origin, codename or version number of the release. This information is shown in various places so a repository owner should always ensure correctness. Further more user configuration like apt_preferences(5) can depend and make use of this information. Since version 1.5 the user must therefore explicitly confirm changes to signal that the user is sufficiently prepared e.g. for the new major release of the distribution shipped in the repository (as e.g. indicated by the codename). IMHO either the message from apt-get or at least the apt-secure(8) man page should explain, a) that (only) "apt update" (and neither apt-get nor aptitude) provides an interactive prompt to accept that change, and b) that apt-get can accept that change via the --allow-releaseinfo-change option. (And yeah, aptitude lacks that option as of now.) Had a user nearly going nuts because of not finding out how to fix this due to not being mentioned in the message nor in the referenced man page. (He didn't look into the apt-get man page as that one wasn't referenced.) -- System Information: Debian Release: 12.0 APT prefers unstable APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'), (500, 'testing-security'), (500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1, 'buildd-experimental') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages apt depends on: ii adduser3.132 ii base-passwd3.6.1 ii debian-archive-keyring 2023.2 ii gpgv 2.2.40-1 ii gpgv1 1.4.23-1.1+b1 ii libapt-pkg6.0 2.6.0 ii libc6 2.36-8 ii libelogind0 [libsystemd0] 246.10-1debian1 ii libgcc-s1 12.2.0-14 ii libgnutls303.7.9-1 ii libseccomp22.5.4-1+b3 ii libstdc++6 12.2.0-14 Versions of packages apt recommends: ii ca-certificates 20230311 Versions of packages apt suggests: ii apt-doc 2.6.0 ii aptitude0.8.13-5+abe+test1+bug1032654 ii dpkg-dev1.21.21 ii gnupg 2.2.40-1 ii gnupg1 1.4.23-1.1+b1 ii gnupg2 2.2.40-1 ii powermgmt-base 1.37 ii wajig 4.0.3 -- no debconf information
Bug#1033357: [Aptitude-devel] Bug#1033357: aptitude: TUI does not display all error messages
Control: severity -1 important Control: tag -1 confirmed Hi Vincent, Vincent Lefevre wrote: > I've got the following error message from the TUI (with 'u' to update): > > ┌──┐ > │E: Failed to download some files > ▒│ > │W: Failed to fetch > ▒│ > │ https://ftp.debian.org/debian/dists/experimental/InRelease: > ▒│ > │E: Some index files failed to download. They have been ignored, or old ones > ▒│ > │ used instead. > ▒│ > │[ Ok ] > │ > └──┘ > > However, "aptitude update" (like "apt update") is more informative: > > [...] > Get: 31 https://ftp.debian.org/debian experimental InRelease [101 kB] > E: Repository 'https://ftp.debian.org/debian experimental InRelease' changed > its 'Codename' value from 'experimental' to 'rc-buggy' > E: Failed to download some files > W: Failed to fetch > https://ftp.debian.org/debian/dists/experimental/InRelease: > E: Some index files failed to download. They have been ignored, or old ones > used instead. Ran into this today, too. I think we had this already when bullseye switched from testing to stable or so and I think there's a bug report for this, too, already. Will search later for that one. Interestingly compared to your last bug repoirt this time I think the severity is higher, as this is an error which doesn't let you to properly continue without proper explanation. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1032829: [Pkg-zsh-devel] Bug#1032829: zsh: error completing "sbuild --extra-package="
Sven Joachim wrote: > > Line 127 of /usr/share/zsh/functions/Completion/Debian/_sbuild has > > mismatched quotes at the end. > > Attached patch fixes that problem, Ah, sorry, oversaw your reply when I wrote my previous mail. > I have also sent it to the zsh-workers mailing list. Thanks! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1032829: [Pkg-zsh-devel] Bug#1032829: zsh: error completing "sbuild --extra-package="
Control: tag -1 + upstream Hi Sven, Sven Joachim wrote: > Typing "sbuild --extra-package=" and pressing TAB signals an error: > > , > | % sbuild --extra-package= > | (eval):1: unmatched " > | _arguments:465: command not found: _ > | % sbuild --extra-package= > ` > > Line 127 of /usr/share/zsh/functions/Completion/Debian/_sbuild has > mismatched quotes at the end. Indeed. Would this change fix the issue? -'--extra-package=[make a package or directory available to the resolver]:package:_files -g "*deb(-.)' \ +'--extra-package=[make a package or directory available to the resolver]:package:_files -g "*deb(-.)"' \ Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1032654: [Aptitude-devel] Bug#1032654: aptitude: missing message about the Debian bookworm change concerning non-free-firmware
dn't and from the code it also seems that this option has no influence on how aptitude uses apt's DumpErrors(). Anyway, despite I uncovered some more severe issues while trying to understand how apt's and aptitude's message handling works internally, I strongly disagree about the severity of the initial bug report (at least those parts which were clear enough) and agree with the apt developers that the message about the Debian bookworm change concerning non-free-firmware is only a notice, not a warning. And I don't expect that Manuel (and surely not me myself) will change something in the way aptitude handles messages from apt for bookworm as it likely will be way more invasive than is good at this stage of the freeze. Hence tagging it as wontfix, too. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1032144: New sudo warning: /etc/sudoers.d/xymon:12:12: Syntax-Fehler
Hi, Christoph Berg wrote: > The latest sudo version triggers this warning: > > # sudo -l > /etc/sudoers.d/xymon:12:12: Syntax-Fehler > xymon ALL=(list) SETENV:NOPASSWD: /usr/lib/xymon/client/ext/mailman >^~~~ > > Removing that line makes the problem go away. > We should fix that for bookworm. JFYI: The upload to fix this was unnecessary in the end: According to https://tracker.debian.org/news/1425949/accepted-sudo-1913p3-1-source-into-unstable/ this issue has been fixed as regression in a sudo with yesterday's upload of 1.9.13p3-1. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1030991: lintian: checking intel-mkl takes 18 hours
Hi Andreas,
Axel Beckert wrote:
> Andreas Beckmann wrote:
> > Checking intel-mkl (pre-built binaries in non-free) with lintian is very
> > slow. A full build (i.e. source+all+any) on amd64 takes nearly 18 hours
> > to check with
> > lintian -i -E -L ">=pedantic" -v intel-mkl_2020.4.304-4_amd64.changes
> > on my local machine (8 cores, 64 GB, tmpfs on /tmp, storage on nvme).
Took about 4 hours here (with about the same specs, but a quite recent
CPU: i7-11700 with 8 cores, 16 threads, 64 GB RAM and all NVMe
storage, including /tmp/), but still far too long.
> I'll check if --perf-debug brings up anything helpful.
Here's the break down on any check that took more than 10 seconds,
sorted by Lintian check:
Binary checks:
Check binaries/corrupted for binary:libmkl-computational-dev_2020.4.304-4_amd64
done (2494.134s)
Check binaries/corrupted for binary:libmkl-interface-dev_2020.4.304-4_amd64
done (104.566s)
Check binaries/corrupted for binary:libmkl-threading-dev_2020.4.304-4_amd64
done (34.574s)
Check binaries/hardening for binary:libmkl-computational-dev_2020.4.304-4_amd64
done (2233.613s)
Check binaries/hardening for binary:libmkl-interface-dev_2020.4.304-4_amd64
done (98.522s)
Check binaries/hardening for binary:libmkl-threading-dev_2020.4.304-4_amd64
done (34.621s)
Check binaries/obsolete/crypt for
binary:libmkl-computational-dev_2020.4.304-4_amd64 done (2206.171s)
Check binaries/obsolete/crypt for
binary:libmkl-interface-dev_2020.4.304-4_amd64 done (99.777s)
Check binaries/obsolete/crypt for
binary:libmkl-threading-dev_2020.4.304-4_amd64 done (34.487s)
Check libraries/static for binary:libmkl-computational-dev_2020.4.304-4_amd64
done (2176.996s)
Check libraries/static for binary:libmkl-interface-dev_2020.4.304-4_amd64 done
(124.188s)
Check libraries/static for binary:libmkl-threading-dev_2020.4.304-4_amd64 done
(38.784s)
Check libraries/static/link-time-optimization for
binary:libmkl-computational-dev_2020.4.304-4_amd64 done (2062.453s)
Check libraries/static/link-time-optimization for
binary:libmkl-interface-dev_2020.4.304-4_amd64 done (106.561s)
Check libraries/static/link-time-optimization for
binary:libmkl-threading-dev_2020.4.304-4_amd64 done (34.848s)
Check libraries/static/no-code for
binary:libmkl-computational-dev_2020.4.304-4_amd64 done (2209.059s)
Check libraries/static/no-code for
binary:libmkl-interface-dev_2020.4.304-4_amd64 done (128.671s)
Check libraries/static/no-code for
binary:libmkl-threading-dev_2020.4.304-4_amd64 done (42.731s)
Source check:
Check debian/control/field/rules-requires-root for
source:intel-mkl_2020.4.304-4 done (499.496s)
So basically the long-taking tests all took about the same time for
each package. So I assume they all had the same issues for each
package, just to different amounts:
* 2000-2500s for libmkl-computational-dev
* 100-130s for libmkl-interface-dev
* 30-45s for libmkl-threading-dev
So I've ran Lintian under a profiler on the smallest of these
packages.
perl -d:NYTProf lintian/bin/lintian libmkl-threading-dev_2020.4.304-4_amd64.deb
And indeed, all three checks stayed approximately the same time in
Lintian::Index::Item::elf_by_member() which took up to 158 seconds
(under the profiler) in 162407 calls.
So if we want to speed up analysing binaries with large .a files (up
to 640 MB in this case), we should clearly speed elf_by_member().
And inside it, it's this line which took all but 1 second of it:
my %copy = %{$self->index->elf_storage_by_member->{$self->name} // {} };
So basically copying data in RAM around seems to be the main cause for
taking so long on these binary packages.
Accordingly I've made this temporary local change to check what it
would be without copying around that data:
diff --git a/lib/Lintian/Index/Item.pm b/lib/Lintian/Index/Item.pm
index 7ef6c0994..87d766cbe 100644
--- a/lib/Lintian/Index/Item.pm
+++ b/lib/Lintian/Index/Item.pm
@@ -1434,9 +1434,10 @@ sub elf_by_member {
return ();
}
-my %copy = %{$self->index->elf_storage_by_member->{$self->name} // {} };
+#my %copy = %{$self->index->elf_storage_by_member->{$self->name} // {} };
-return \%copy;
+#return \%copy;
+return $self->index->elf_storage_by_member->{$self->name} // {};
}
=item pointer
(Patch and all tests based on the 2.116.3 release.)
Not copying that data and just returning the original cuts the run
time down from 5m 7s to 1m 56s, i.e. by about 60%.
On the largest package (libmkl-computational-dev) it went down even a
much bigger percentage, from close to 3 hours (178 minutes) down to only 3
minutes and 32 seconds.
The question is now: Do we really need a separate copy of that data
for each call? Sure, if it's modified afterwards, this makes sense.
But I have no idea where this might happen.
So I've run the test suite on the above mentioned modification and to
my surprise it passed.
Bug#1032186: [Pkg-raspi-maintainers] Bug#1032186: raspi-firmware: Can make removing a kernel image fail and causing "apt upgrade" to fail early, too
Hi Diederik, Diederik de Haas wrote: > On Wednesday, 1 March 2023 12:48:49 CET Axel Beckert wrote: > > A patch (without the proper indentation probably wanted for readability) > > which seems to have helped for me: […] > https://salsa.debian.org/debian/raspi-firmware/-/merge_requests/32 contains a > variation of your patch. Thanks! Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1032186: raspi-firmware: Can make removing a kernel image fail and causing "apt upgrade" to fail early, too
Package: raspi-firmware
Severity: serious
Tags: patch
Hi,
if /boot/firmware is (nearly) full, raspi-firmware prevents (!)
uninstalling a kernel image, because it still insists on copying stuff
to /boot/firmware upon kernel image removal.
An additional condition might be that another kernel image is present
and not fully configured for the same reason (not enough
diskspace). It's unlcear for me, if this additional condition is
required for this issue to reproduce.
In general you can run into such an issue within months if you have
automatic updates enabled and don't clear up old kernels
automatically. (And yes, in my case the VFAT partition is rather small
as this is a very old installation.
# df -h /boot/firmware/
Filesystem Size Used Avail Use% Mounted on
/dev/mmcblk0p1 121M 121M 2.0K 100% /boot/firmware
# dpkg --purge linux-image-6.1.0-1-armmp-lpae
(Reading database ... 350731 files and directories currently installed.)
Removing linux-image-6.1.0-1-armmp-lpae (6.1.4-1) ...
/etc/kernel/postrm.d/initramfs-tools:
update-initramfs: Deleting /boot/initrd.img-6.1.0-1-armmp-lpae
/etc/kernel/postrm.d/z50-raspi-firmware:
cp: error writing '/boot/firmware/vmlinuz-6.1.0-2-armmp-lpae': No space left
on device
run-parts: /etc/kernel/postrm.d/z50-raspi-firmware exited with return code 1
dpkg: error processing package linux-image-6.1.0-1-armmp-lpae (--purge):
installed linux-image-6.1.0-1-armmp-lpae package post-removal script
subprocess returned error exit status 1
Errors were encountered while processing:
linux-image-6.1.0-1-armmp-lpae
# ls -l /boot/firmware/{initrd.img,vmlinuz}-*
-rwxr-xr-x 1 root root 25319457 Oct 13 08:32
/boot/firmware/initrd.img-5.19.0-2-armmp-lpae
-rwxr-xr-x 1 root root 25268327 Dec 7 08:29
/boot/firmware/initrd.img-6.0.0-5-armmp-lpae
-rwxr-xr-x 1 root root 25266000 Jan 18 08:21
/boot/firmware/initrd.img-6.0.0-6-armmp-lpae
-rwxr-xr-x 1 root root 5210624 Oct 24 00:52
/boot/firmware/vmlinuz-5.19.0-2-armmp-lpae
-rwxr-xr-x 1 root root 5267968 Dec 7 08:29
/boot/firmware/vmlinuz-6.0.0-5-armmp-lpae
-rwxr-xr-x 1 root root 5267968 Dec 27 08:05
/boot/firmware/vmlinuz-6.0.0-6-armmp-lpae
-rwxr-xr-x 1 root root 5370368 Jan 18 08:21
/boot/firmware/vmlinuz-6.1.0-1-armmp-lpae
-rwxr-xr-x 1 root root 3817472 Mar 1 05:31
/boot/firmware/vmlinuz-6.1.0-2-armmp-lpae
# dpkg --audit
The following packages have been unpacked but not yet configured.
They must be configured using dpkg --configure or the configure
menu option in dselect for them to work:
linux-headers-armmp-lpae Header files for Linux armmp-lpae configuration
(meta
linux-image-armmp-lpae Linux for ARMv7 multiplatform compatible SoCs
supportin
The following packages are only half configured, probably due to problems
configuring them the first time. The configuration should be retried using
dpkg --configure or the configure menu option in dselect:
initramfs-tools generic modular initramfs generator (automation)
linux-headers-6.1.0-2-armmp-lpae Header files for Linux 6.1.0-2-armmp-lpae
linux-image-6.1.0-2-armmp-lpae Linux 6.1 for ARMv7 multiplatform compatible
So
raspi-firmware Raspberry Pi family GPU firmware and bootloaders
The following packages are only half installed, due to problems during
installation. The installation can probably be completed by retrying it;
the packages can be removed using dselect or dpkg --remove:
linux-image-6.1.0-1-armmp-lpae Linux 6.1 for ARMv7 multiplatform compatible
So
In the end, this also causes apt to abort rather early and not upgrade
or install anything anymore since then. This is also the reason why only
outdated kernel are (partially) installed.
So please stop copying stuff to /boot/firmware on kernel image removal
or purging. There will be an occasion for that at a later time anyway.
A patch (without the proper indentation probably wanted for readability)
which seems to have helped for me:
diff --git a/kernel/postinst.d/z50-raspi-firmware
b/kernel/postinst.d/z50-raspi-firmware
index 1d3ae16..d898847 100755
--- a/kernel/postinst.d/z50-raspi-firmware
+++ b/kernel/postinst.d/z50-raspi-firmware
@@ -115,6 +115,7 @@ else
dtb_path="/usr/lib/linux-image-${latest_kernel#/boot/vmlinuz-}"
fi
+if [ "$1" != "remove" ]; then
if [ "$KERNEL" = "auto" ] ; then
for dtb in "${dtb_path}"/bcm*.dtb; do
[ -e "${dtb}" ] || continue
@@ -128,6 +129,7 @@ if [ "$KERNEL" = "auto" ] ; then
cp "$latest_kernel" /boot/firmware/
cp "$latest_initrd" /boot/firmware/
fi
+fi
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (500, 'unstable-debug'),
(500, 'buildd-unstable'), (110, 'experimental'), (1, 'experimental-debug'), (1,
'buildd-experimental')
merged-usr: no
Architecture: armhf
Kernel: Linux 6.0.0-5-armmp-lpae (SMP)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Bug#1032144: New sudo warning: /etc/sudoers.d/xymon:12:12: Syntax-Fehler
Control: tag -1 + confirmed pending
Hi Christoph,
thanks for this bug report.
Christoph Berg wrote:
> The latest sudo version triggers this warning:
>
> # sudo -l
> /etc/sudoers.d/xymon:12:12: Syntax-Fehler
> xymon ALL=(list) SETENV:NOPASSWD: /usr/lib/xymon/client/ext/mailman
>^~~~
I wonder what exactly is the syntax error here.
> Removing that line makes the problem go away.
On a first glance this seems to happen if Mailman (for which the list
user is) is not installed, but sudo is installed. But then again, the
user list seems on all my boxes. And for the line before that, it
doesn't argue about the user backuppc which surely doesn't exist on
most systems.
Then again, this line is untouched since 2012 when we switched the
user from hobbit to xymon, i.e. the position where the syntax error is
claimed is even older.
So I wonder: Did sudo's syntax change?
And yes, it did. It seems to have introduced a "list" keyword:
2022-12-26
[…]
Bump SUDOERS_GRAMMAR_VERSION to 50 for the new list pseudo-command.
郎
eems to have been introduced in Testing yesterday with the migration
of sudo 1.9.13p1-1.
And indeed, if I change "list" to e.g. "listx", the error goes away.
> We should fix that for bookworm.
Ack. So the question is how to fix it.
The man page reads:
A user name, user-ID, group, group-ID, netgroup, nonunix_group or
nonunix_gid may be enclosed in double quotes to avoid the need
for escaping special characters.
I guess this probably also counts for keywords. Let's see and use
double quotes around "list" (sic!):
Yep, changing it to
xymon ALL=("list") SETENV:NOPASSWD: /usr/lib/xymon/client/ext/mailman
will make the error go away.
Will prepare an upload.
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1032048: d3-dsv-tools: Dangling symlinks in /usr/bin/
Package: d3-dsv-tools Version: 1.1.1-8 Severity: grave Justification: renders package unusable $ symlinks -tv /usr/bin* | fgrep dangling dangling: /usr/bin/csv2json -> ../share/nodejs/d3-dsv/bin/dsv2json.js dangling: /usr/bin/csv2tsv -> ../share/nodejs/d3-dsv/bin/dsv2dsv.js dangling: /usr/bin/dsv2dsv -> ../share/nodejs/d3-dsv/bin/dsv2dsv.js dangling: /usr/bin/json2csv -> ../share/nodejs/d3-dsv/bin/json2dsv.js dangling: /usr/bin/json2dsv -> ../share/nodejs/d3-dsv/bin/json2dsv.js dangling: /usr/bin/tsv2csv -> ../share/nodejs/d3-dsv/bin/dsv2dsv.js dangling: /usr/bin/json2tsv -> ../share/nodejs/d3-dsv/bin/json2dsv.js dangling: /usr/bin/dsv2json -> ../share/nodejs/d3-dsv/bin/dsv2json.js dangling: /usr/bin/tsv2json -> ../share/nodejs/d3-dsv/bin/dsv2json.js Looking at where those files actually might be, I figured that the symlinks probably should point to the same target without the .js suffix — or that those files need to be renamed: /usr/share/nodejs/d3-dsv/bin/dsv2dsv /usr/share/nodejs/d3-dsv/bin/dsv2json /usr/share/nodejs/d3-dsv/bin/json2dsv -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (600, 'testing') merged-usr: yes Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages d3-dsv-tools depends on: ii node-d3-dsv 1.1.1-8 ii nodejs 18.13.0+dfsg1-1 d3-dsv-tools recommends no packages. d3-dsv-tools suggests no packages. -- no debconf information
Bug#1030991: lintian: checking intel-mkl takes 18 hours
Control: tag -1 + confirmed
Hi Andreas,
Andreas Beckmann wrote:
> Checking intel-mkl (pre-built binaries in non-free) with lintian is very
> slow. A full build (i.e. source+all+any) on amd64 takes nearly 18 hours
> to check with
> lintian -i -E -L ">=pedantic" -v intel-mkl_2020.4.304-4_amd64.changes
> on my local machine (8 cores, 64 GB, tmpfs on /tmp, storage on nvme).
Thanks for that bug report. Knowing such examples to test is always
good to know. Performance is one thing we managed to get much better
in the past ¾ year or so, especially thanks to Bastien. But there is
obviously (and not only known since this bug report) place for
improvement. :-)
> I don't know where all the time is spent ...
Well, 549 MB of source package... :-)
I'll check if --perf-debug brings up anything helpful. Well, yes, but
I would have gathered that otherwise, too:
Warning in processable ../libmkl-threading-dev_2020.4.304-4_amd64.deb:
MLDBM error: Second level tie failed, "No space left on device" at
/usr/share/perl5/MLDBM.pm line 144.
So, new try.
>From the output I already see that these checks took quite a while
(that's where output stopped for quite a while:
Running check: debian/control/field/rules-requires-root on
source:intel-mkl_2020.4.304-4 ...
Running check: documentation/manual on
binary:libmkl-meta-threading_2020.4.304-4_amd64 ...
Anyway, will wait what I get at the end. Everything with "done (0."
can be ignored. :-)
Anyway, tagging as confirmed as I can already see now that it will
take a while. :-)
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1031859: false positive of embedded expat library leads to ftp-master rejection
Control: severity -1 minor Hi Matthias, Matthias Klose wrote: > > > The packages are confiured --with-system-expat, and all have proper > > > dependencies > > > on libexpat1. > > > > > > The same bogus messages can be found for python3.11 at > > > https://udd.debian.org/lintian/?packages=python3.11 > > yes, see https://github.com/python/cpython/blob/main/Modules/pyexpat.c Thanks for that hint. So Python upstream copied a bunch of error messages verbatim from libexpat since Python 3.11. 奈 (I verified that this got added in 3.11 and that 3.10.0 and 3.10.10 doesn't emit these tags.) So this means that this test works as it should and detected that fact. In that case: 1) this is by no means an RC-critical as it only affects a single package (well, actually pypy, too, probably for similar reasons) and does not mean that the check itself is broken. In contrary! Hence downgrading the severity to minor, as there's a small chance that we can find an libexpat string that the Python upstream devs haven't copied verbatim into their code. 郎 (If we don't find one occasionally, I will close this bug report as wontfix.) 2) You should just add a lintian override as this is a very special circumstance only appearing in two python-related packages and nowhere else and the cause is a very weird behaviour of the upstream developers. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1031625: gdb: Should the upstream snapshot currently in unstable be shipped in bookworm?
Hi Adrian, Adrian Bunk wrote: > Is the upstream snapshot that was binNMUed into unstable better > than 12.1 currently in bookworm, or should bookworm stay at 12.1? JFTR: This was not an "binNMU", it was an "NMU". Confused me initially and had to look at https://tracker.debian.org/pkg/gdb to understand it. Hence writing this hint. Regards, Axel -- ,''`. | Axel Beckert , https://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
Bug#1031267: debmany: shell injection
Control: tag -1 + patch pending
Hi Jakub,
found time to analyse this closer.
Axel Beckert wrote:
> Given that the full path including the exploit code is always shown to
> the user before the exploit actually runs, I consider the impact
> rather low:
>
> ┌┤ Select a file (file:./injection.deb)
> ├┐
> │
>│
> │ usr/share/doc/$(cowsay${IFS}pwned>/dev/tty;sleep${IFS}inf)/changelog.gz
> changelog.gz │
> │
>│
> │
>│
> │
>│
> └┘
And this even though $manpages (which holds a space separated list of
all files to offer) is — on purpose — unquoted when passing to the
selection program.
But the real culprit is the use of eval in lines 415, 422 and 424:
414 debug "Opening manpage file: "`printf "$mancmdline" "$PWD/$file"` #
comment
415 eval $(printf "$mancmdline" "$PWD/$file")
416 cd - >/dev/null
417 else
418 # other file (usr/share/doc)
419 debug "Opening other file: "`printf "$othercmdline" "$PWD/$return"`
# comment
420 if [[ "$return" =~ \.gz$ ]]
421 then
422 eval $(printf "gzip -dc $PWD/$return | $othercmdline")
423 else
424 eval $(printf "$othercmdline" "$PWD/$return")
425 fi
Eval is evil. Once again.
My first thought was to just exclude all files with shell special
characters, especially '$(' and friends. But
apt-file search -n \$\( | fgrep /usr/share/doc/
shows that these are actually used (and fail with debmany due to the
issue reported by Jakub):
sdlbasic: /usr/share/doc/sdlbasic/english/sections/commands/Maths/hex$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/chr$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/insert$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/lCase$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/lTrim$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/left$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/mid$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/replace$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/replaceSubstr$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/reverse$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/right$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/space$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/str$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/string$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/trim$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/typeOf$().html
sdlbasic:
/usr/share/doc/sdlbasic/english/sections/commands/Strings/uCase$().html
Additionally there are tons of files with just $ or any kind of brackets.
Just quoting them "properly" inside the eval and printf won't help as
you can always escape from there by just ending the according
quotation by adding a closing quote character into your file path.
In case of the ".gz" case in your example, it's easier to fix as you
can simply move "gzip -dc $PWD/$return |" out of the eval/printf.
But in the other cases it's less simple.
So I came up with the following fix which uses command instead of
eval, and bash pattern substitution to replace %s with the file name
instead letting printf inside an $() doing the substitution:
diff --git a/debmany/debmany b/debmany/debmany
index 7eeb68b..dfea6e9 100755
--- a/debmany/debmany
+++ b/debmany/debmany
@@ -96,6 +96,19 @@ Examples: debmany foo.deb show manpages from a local
package file foo.deb
fi
}
+replace_percent_s_and_execute() {
+ replacement="$1"
+ shift
+ declare -a cmdarr
+ cmdarr=($@)
+ debug "cmdarr before; ${cmdarr[@]}"
+ for i in ${!cmdarr[@]}; do
+cmdarr[$i]="${cmdarr[$i]/\%s/$replacement}"
+ done
+ debug "cmdarr after; ${cmdarr[@]}"
+ command "${cmdarr[@]}"
+}
+
while [ $# -gt 0 ]
do
case $1 in
@@ -377,6 +390,7 @@ else
dpkg --fsys-tarfile "$file" | tar --wildcards -xf - $mandirs 2
Bug#1031552: translate: iconv issue
Control: tag -1 + confirmed pending
Hi Markus,
thanks for the bug report.
Markus Reschke wrote:
> In a shell with ISO-8859-1/latin1 encoding
Please note that with the upcoming Debian 12 release, non-UTF-8
locales are deprecated and no more offered to be configured via
debconf on new installations or upon reconfiguration. (Already
configured non-UTF-8 locales stay untouched, though.) Additionally,
all non-UTF-8 users are encouraged to switch to a UTF-8 locale.
Editing /etc/locale.gen and then regenerating my locales I was though
able to still create some non-UTF-8 locales on my system for trying to
reproduce this.
I nevertheless would like to fix this issue in translate for Debian 12.
> translate triggers an iconv issue
> for some words, resulting in the output ending with:
> iconv: illegal input sequence at position 560
> or some other position.
Hmmm, I'd have preferred a more explicit example. But in the end I
found one:
* Start an ISO-Latin based xterm with
env `locale | sed -e s/C\.UTF-8/de-DE@euro/` lxterm
* In that xterm call:
env `locale | sed -e s/C\.UTF-8/de-DE@euro/` translate -i common
Then the last output line is:
Agrarpolitik {f} | Gemeinsame Agrarpolitik /GAP/ :: agricultural policy |
Common Agricultural Policy /CAP/
And the first missing line is:
Akeleien {pl} (Aquilegia) (botanische Gattung) [bot.] | Gemeine
Akelei {f}; Gewöhnliche Akelei {f}; Waldakelei {f} (Aquilegia vulgaris) ::
columbines; granny’s bonnets (botanical genus) | common
columbine; European columbine; European crowfoot; granny’s bonnet
>From there on, indeed no other line is sent to STDOUT.
Additionally it emits rather early the error message:
iconv: illegal input sequence at position 1702
> This can be fixed by adding a '-c' to the translate script:
>echo $OPT "$1" | iconv -c -f UTF-8 -t $CHARSET
Adding -c indeed fixes this issue. And for some reason the "ö" in
"Gewöhnliche" is still shown despite the iconv man page suggested
something else (namely that the character is not displayed at all --
which scared me a bit).
So I'll add that to both iconv calls in translate.
Thanks again, also for the hint on "-c".
Regards, Axel
--
,''`. | Axel Beckert , https://people.debian.org/~abe/
: :' : | Debian Developer, ftp.ch.debian.org Admin
`. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5
`-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE
