Bug#1061076: kbtin: FTBFS with stack-clash-protection on armhf due to valgrind segfault
On Wed, Jan 17, 2024 at 04:29:10PM +0100, Emanuele Rocca wrote: > Source: kbtin > Severity: serious > Usertags: 32bit-stackclash > kbtin currently fails to build from source on armhf. The failure is due > to an incompatibility between valgrind and stack-clash-protection on > 32bit arm reported upstream at: > https://bugs.kde.org/show_bug.cgi?id=479699 Thanks for the report (and fix). I've applied it in git. However... during testing, while the package now builds fine on armhf (and armel amd64 ...), I see it makes valgrind crash on arm64 with: Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x92 valgrind: m_debuginfo/readdwarf.c:2822 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed. and likewise this doesn't appear to be a problem with kbtin itself -- it's just a regular C program that does nothing weird. While these bugs are unrelated (other than both being failures due to valgrind not liking new toolchains), it makes no sense to upload the fix right now. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ I was born a dumb, ugly and work-loving kid, then I got swapped on ⢿⡄⠘⠷⠚⠋⠀ the maternity ward. ⠈⠳⣄
Bug#1049884: birdtray: FTBFS on armhf, armel, mipsel due to thunderbird build-dep
On Mon, Aug 21, 2023 at 10:38:52AM +0200, Emanuele Rocca wrote: > Hi Adam, Hi Em! > On 2023-08-16 05:14, Adam Borowski wrote: > > This is not a regression, thus why would it be a bug? > > Well FTBFS is a bug isn't it? :-) A FTBFS on an architecture that has built before (and hasn't been RMed) is a bug, and one that's policied as high severity. A FTBFS that's not a regression is a wishlist, a porting opportunity. And here it's not even a build failure but a failure to install b-deps. Obviously we'd prefer thunderbird:armhf to be a thing, but unless/until it can be fixed, talk about thunderbird addons on armhf is quite moot. And the way b-deps are written, the moment thunderbird:armhf hits incoming its addons get enabled in wanna-build, with no human action needed. > > There's nothing in birdtray itself that would prevent it from being built on > > these architectures the moment problems in thunderbird are resolved > > Why does birdtray build-depend on thunderbird? It seems to build > perfectly fine in a clean armhf chroot without it. Build yes, work no. The result would be a pointless package you can't use; adding this (otherwise superfluous) build-dependency avoids having a non-installable package in the archive. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ An imaginary friend squared is a real enemy. ⠈⠳⣄
Bug#1042252: pmdk: diff for NMU version 1.13.1-1.1
On Fri, Aug 11, 2023 at 02:02:36PM +0300, Adrian Bunk wrote: > I've prepared an NMU for pmdk (versioned as 1.13.1-1.1) and uploaded > it to DELAYED/2. Please feel free to tell me if I should cancel it. > +pmdk (1.13.1-1.1) unstable; urgency=low > + > + * Non-maintainer upload. > + * Ignore check-manpages failure until Pandoc creates manpages > +that are accepted by the latest groff. (Closes: #1042252) > + > + -- Adrian Bunk Fri, 11 Aug 2023 13:28:04 +0300 It's okay. I waited for the problem to be fixed in pandoc and/or groff, as pmdk is merely an user of these tools, but apparently this takes a while. Thus, papering over the failing test for now is a good idea. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ⢿⡄⠘⠷⠚⠋⠀ ./configure --host=zx-spectrum --build=pdp11 ⠈⠳⣄
Bug#1041207: debootstrap: bad NMU produces buildds not supported by dpkg _and_ CTTE
Package: debootstrap Version: 1.0.128+nmu3 Severity: grave bluca's NMU on 2023-07-15 makes debootstrap produce chroots using the aliased-dirs scheme. While it's currently the default scheme for non-buildd systems, it is both not supported by dpkg (with no solution in sight), but is also likely to produce packages that are explicitely forbidden by a recent CTTE ruling that disallows moving files between directories aliased by the current usrmerge scheme. Quoting the still unsolving issues is pointless (you can read about them in massive threads in a number of places) as bluca seems to be ignoring them completely. But, what matters here is the CTTE ruling in #1035831 -- for the time being, packages must not move files between locations affected by the aliasing. Packages built in an usrmerged chroot place such files under /usr while built without usrmerge into whatever place they were installed to -- which is a direct breach of the ruling. Thus, that change needs to be reverted for now, and all packages built with 1.0.128+nmu3 need to be either rebuilt or at least checked for such a violation (as most are unaffected). Meow! -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-rc1-00036-gc493f11e457d (SMP w/64 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages debootstrap depends on: ii wget 1.21.3-1+b2 Versions of packages debootstrap recommends: ii arch-test 0.21-1 ii debian-archive-keyring 2023.3 ii gnupg 2.2.40-1.1 Versions of packages debootstrap suggests: ii binutils 2.40.90.20230705-1 pn squid-deb-proxy-client ii ubuntu-archive-keyring 2020.06.17.1-1 ii ubuntu-keyring [ubuntu-archive-keyring] 2020.06.17.1-1 ii xz-utils 5.4.1-0.2 ii zstd 1.5.5+dfsg2-1 -- no debconf information
Bug#1041206: python-clickhouse-driver: FTBFS if source is included: aborting due to unexpected upstream changes
Source: python-clickhouse-driver Version: 0.2.5-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi! With any build type that includes the source, your package fails with: dpkg-source: info: local changes detected, the modified files are: python-clickhouse-driver-0.2.5/clickhouse_driver/bufferedreader.c python-clickhouse-driver-0.2.5/clickhouse_driver/bufferedwriter.c python-clickhouse-driver-0.2.5/clickhouse_driver/columns/largeint.c python-clickhouse-driver-0.2.5/clickhouse_driver/varint.c dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/python-clickhouse-driver_0.2.5-1.diff.aYpmik dpkg-source: info: Hint: make sure the version in debian/changelog matches the unpacked source tree Full build log attached. Meow! -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-rc1-00036-gc493f11e457d (SMP w/64 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) sbuild (Debian sbuild) 0.85.2 (11 March 2023) on valinor.angband.pl +==+ | python-clickhouse-driver (amd64) Sat, 15 Jul 2023 16:07:40 + | +==+ Package: python-clickhouse-driver Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: full I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-2168482a-634b-4d8e-b5d4-42b1136edf8b' with '<>' I: NOTICE: Log filtering will replace 'build/python-clickhouse-driver-QFihkK/resolver-njOJ3X' with '<>' +--+ | Update chroot| +--+ Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. +--+ | Fetch source files | +--+ Check APT - Checking available source versions... Download source files with APT -- Reading package lists... NOTICE: 'python-clickhouse-driver' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/debian/python-clickhouse-driver.git Please use: git clone https://salsa.debian.org/debian/python-clickhouse-driver.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 297 kB of source archives. Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main python-clickhouse-driver 0.2.5-1 (dsc) [2200 B] Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main python-clickhouse-driver 0.2.5-1 (tar) [292 kB] Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main python-clickhouse-driver 0.2.5-1 (diff) [3228 B] Fetched 297 kB in 0s (4024 kB/s) Download complete and in download only mode I: NOTICE: Log filtering will replace 'build/python-clickhouse-driver-QFihkK/python-clickhouse-driver-0.2.5' with '<>' I: NOTICE: Log filtering will replace 'build/python-clickhouse-driver-QFihkK' with '<>' +--+ | Install package build dependencies | +--+ Setup apt archive - Merged Build-Depends: debhelper-compat (= 13), dh-python, cython3, python3-all-dev, python3-setuptools, python3-sphinx, python3-tzlocal, build-essential, fakeroot Filtered Build-Depends: debhelper-compat (= 13), dh-python, cython3, python3-all-dev, python3-setuptools, python3-sphinx, python3-tzlocal, build-essential, fakeroot dpkg-deb: building package 'sbuild-build-depends-main-dummy' in '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. Ign:1 copy:/<>/apt_archive ./ InRelease Get:2 copy:/<>/apt_archive ./ Release [609 B] Ign:3 copy:/<>/apt_archive ./ Release.gpg Get:4 copy:/<>/apt_archive ./ Sources [707 B] Get:5 copy:/<>/apt_archive ./ Packages [739 B] Fetched 2055 B in 0s (0 B/s) Reading package lists... Reading package lists... Install main build dependencies (apt-based resolver)
Bug#1041203: FTBFS: InvalidRequirement: Expected end or semicolon
Source: macs Version: 2.2.7.1-6 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi! I'm afraid your package fails to build, with: pkg_resources.extern.packaging._tokenizer.ParserSyntaxError: Expected end or semicolon (after name and no valid version specifier) numpy>=>=1.17 Full log attached. Meow! -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-rc1-00036-gc493f11e457d (SMP w/64 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) sbuild (Debian sbuild) 0.85.2 (11 March 2023) on valinor.angband.pl +==+ | macs (amd64) Sat, 15 Jul 2023 15:59:52 + | +==+ Package: macs Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-6c3ec2b5-ebd2-4821-9c2c-b590aa40ebd9' with '<>' I: NOTICE: Log filtering will replace 'build/macs-QwMUa0/resolver-kV6wWG' with '<>' +--+ | Update chroot| +--+ Get:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease [199 kB] Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main Sources.diff/Index [63.6 kB] Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 Packages.diff/Index [63.6 kB] Get:4 http://apt-rosy.angband.pl:3142/debian unstable/main Sources T-2023-07-15-1409.27-F-2023-07-15-1409.27.pdiff [38.2 kB] Get:4 http://apt-rosy.angband.pl:3142/debian unstable/main Sources T-2023-07-15-1409.27-F-2023-07-15-1409.27.pdiff [38.2 kB] Get:5 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 Packages T-2023-07-15-1409.27-F-2023-07-15-1409.27.pdiff [14.4 kB] Get:5 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 Packages T-2023-07-15-1409.27-F-2023-07-15-1409.27.pdiff [14.4 kB] Fetched 379 kB in 1s (275 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... The following packages will be upgraded: libtool 1 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 517 kB of archives. After this operation, 0 B of additional disk space will be used. Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 libtool all 2.4.7-6 [517 kB] debconf: delaying package configuration, since apt-utils is not installed Fetched 517 kB in 0s (16.6 MB/s) (Reading database ... (Reading database ... 5% (Reading database ... 10% (Reading database ... 15% (Reading database ... 20% (Reading database ... 25% (Reading database ... 30% (Reading database ... 35% (Reading database ... 40% (Reading database ... 45% (Reading database ... 50% (Reading database ... 55% (Reading database ... 60% (Reading database ... 65% (Reading database ... 70% (Reading database ... 75% (Reading database ... 80% (Reading database ... 85% (Reading database ... 90% (Reading database ... 95% (Reading database ... 100% (Reading database ... 14595 files and directories currently installed.) Preparing to unpack .../libtool_2.4.7-6_all.deb ... Unpacking libtool (2.4.7-6) over (2.4.7-5) ... Setting up libtool (2.4.7-6) ... Processing triggers for man-db (2.11.2-2) ... +--+ | Fetch source files | +--+ Check APT - Checking available source versions... Download source files with APT -- Reading package lists... NOTICE: 'macs' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/med-team/macs.git Please use: git clone https://salsa.debian.org/med-team/macs.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 136 MB of source archives. Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main macs 2.2.7.1-6 (dsc) [2102 B] Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main macs 2.2.7.1-6 (tar) [135 MB] Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main macs 2.2.7.1-6 (diff) [1268 kB] Fetched 136 MB in 0s (336 MB/s) Download complete and in download only mode I: NOTICE: Log filtering will replace
Bug#1040621: binutils-mipsen: missing shlib dependencies
Source: binutils-mipsen Version: 10+c3 Severity: grave Justification: renders package unusable mips* binutils tools crash on startup: $ mips64el-linux-gnuabi64-as mips64el-linux-gnuabi64-as: error while loading shared libraries: libsframe.so.0: cannot open shared object file: No such file or directory The culprit is: $ ldd /usr/lib/x86_64-linux-gnu/libopcodes-2.40.50-mips64el.20230611.so libsframe.so.0 => not found which would be prevented by package relationships/DAK/etc, had the dependency on libsframe be included in binaries you produce. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.2-00035-g5920c330f094 (SMP w/64 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#1040513: wireplumber: non-installable due to hardcoded Depends: dbus-user-session
Package: wireplumber Version: 0.4.14-3 Severity: grave Hi! In version 0.4.14-3, you added a hard dependency on a specific session model of dbus, rather than the virtual package defined by the Policy (dbus-session-bus). This makes it non-installable on any box where a dependency of that package is non-functional or unwanted. As of policy 4.3.0, the expected dependency is: default-dbus-session-bus | dbus-session-bus We have two implementations of in Debian: * dbus-user-session: + works with wayland - no multiseat support - requires systemd * dbus-x11 - requires x11 + allows multiple sessions + portable even to non-linux I confirm that, as of 0.4.14-2 wireplumber works well with dbus-x11, and earlier versions did so for quite a while too. Meow! -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.4.2-00035-g5920c330f094 (SMP w/64 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages wireplumber depends on: ii init-system-helpers 1.65.2 ii libc6 2.37-4 ii libglib2.0-0 2.74.6-2 ii libpipewire-0.3-0 0.3.73-1 ii libwireplumber-0.4-0 0.4.14-2 ii pipewire 0.3.73-1 Versions of packages wireplumber recommends: ii pipewire-pulse 0.3.73-1 Versions of packages wireplumber suggests: pn libspa-0.2-bluetooth pn wireplumber-doc -- no debconf information
Bug#1022222: valgrind-if-available shouldn't stop providing valgrind on mipsel
Control: severity -1 normal (I intended to avoid having to argue by implementing specific objective tests that valgrind has to meet to be declared available, but I did not manage to get that done. Thus, arguing...) On Sat, Oct 22, 2022 at 12:12:40PM +0300, Adrian Bunk wrote: > Package: valgrind-if-available > Severity: serious > valgrind-if-available (3.18.1-1-1) unstable; urgency=medium > ... > * Drop mipsel as valgrind disagrees about blah blah baseline Loongson. > This is wrong, and it makes at least qtmir FTBFS. (as said already elsewhere) Failing to build because valgrind is not available means you're using the package wrong: it may or may not pull in valgrind, and the set of architectures can and will change without any warning. The whole purpose of this metapackage is to track valgrind's availability so 100+ individual packages don't need to. Ie, instead of: if arch in (foo bar baz quux) build --valgrind=yes else build --valgrind=no you do: if `which valgrind >/dev/null` build --valgrind=yes else build --valgrind=no > If there is any problem with valgrind on mipsel > it should be discussed and resolved in valgrind first, > if valgrind is available then valgrind-if-available > has to provide it. No, this particular problem is that valgrind doesn't work on _some_ mipsel machines. This doesn't make valgrind itself useless, but makes it unsuitable for being ran as a part of automated testsuites. As our buildds appear to be all Loongsons, coding some complex machinery to detect the subarch at runtime would be a waste of time. Flat out saying "disable valgrind tests on mipsel" is easier and works good enough for now. > It is also unclear what the baseline problem is this changelog > entry is referring to, there is no open bug in the valgrind package > mentioned and the closest I could find was a bug that was fixed (sic) > 5 years ago. It fails at least in 3.19 (unstable) and 3.20 (experimental): https://buildd.debian.org/status/fetch.php?pkg=valgrind-if-available=mipsel=3.19.0-1-1=1667563987=0 ==1833049== Memcheck, a memory error detector ==1833049== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==1833049== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info ==1833049== Command: /tmp/___ ==1833049== VEX: Unsupported baseline Found: Loongson-baseline Cannot continue. Good-bye vex storage: T total 0 bytes allocated vex storage: P total 0 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==1833049==at 0x5804FB44: ??? (in /usr/libexec/valgrind/memcheck-mips32-linux) ==1833049==by 0x5804FA2C: ??? (in /usr/libexec/valgrind/memcheck-mips32-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 1833049) ==1833049==at 0x401B920: __start (in /lib/mipsel-linux-gnu/ld.so.1) ==1833049==by 0x7EB7B088: ??? client stack range: [0x7EB78000 0x7EB7BFFF] client SP: 0x7EB7B090 valgrind stack range: [0x42878000 0x42977FFF] top usage: 5512 of 1048576 It appears that no one, both upstream and _in Debian_, cares enough about mipsel to fix bugs or even report them, thus I don't expect it to be solved anytime soon -- or, probably, ever, as mipsel is not long for this world. But, as the trivial solution would be removing support for mipsel completely from valgrind, I think users are better served by being provided something that works on at least _some_ hardware. > It is also suprising if this is really a mipsel-only issue as the > changelog claims, I would have expected any issues to also show > up on mips64el. This very same test works fine on mips64el. > Therefore please report any issues with valgrind on mipsel as bugs > against src:valgrind, but in any case please make valgrind-if-available > always provide valgrind on all architectures where it is available. Seems we understand "available" differently: * for you, it means "shipped at all", * for me, it means "works for a typical set of tasks". valgrind on mipsel is functional on old hardware but dies even on "hello world" on Loongson. I consider this availability to be lacking. My plans for this bug are: * s/available/available and functional/ in the description * run all tests even on marginal archs, but don't fail the build if it's an expected failure Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Only flat-earthers have a problem folding a fitted sheet. ⢿⡄⠘⠷⠚⠋⠀ I instead shape it into a ball. ⠈⠳⣄
Bug#1032041: FTBFS: error: ‘size_t’ does not name a type
Source: arm-compute-library Version: 20.08+dfsg-5 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi! I'm afraid your package fails to build, with: In file included from src/core/ITensorPack.cpp:24: ./arm_compute/core/ITensorPack.h:89:5: error: ‘size_t’ does not name a type 89 | size_t size() const; | ^~ ./arm_compute/core/ITensorPack.h:29:1: note: ‘size_t’ is defined in header ‘’; did you forget to ‘#include ’? 28 | #include +++ |+#include 29 | Full log attached. Meow! -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (490, 'testing'), (250, 'unstable'), (201, 'experimental') merged-usr: no Architecture: arm64 (aarch64) Kernel: Linux 6.1.0-3-arm64 (SMP w/6 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 /bin/dash Init: sysvinit (via /sbin/init) sbuild (Debian sbuild) 0.85.0 (04 January 2023) on rhun +==+ | arm-compute-library (arm64) Sat, 25 Feb 2023 23:54:14 + | +==+ Package: arm-compute-library Distribution: unstable Machine Architecture: arm64 Host Architecture: arm64 Build Architecture: arm64 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-arm64-sbuild-edf3fc6f-42f6-4973-91ef-878c3886c3bc' with '<>' I: NOTICE: Log filtering will replace 'build/arm-compute-library-q3qKDi/resolver-psabH1' with '<>' +--+ | Update chroot| +--+ Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. +--+ | Fetch source files | +--+ Check APT - Checking available source versions... Download source files with APT -- Reading package lists... NOTICE: 'arm-compute-library' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/wookey/arm-compute-library Please use: git clone https://salsa.debian.org/wookey/arm-compute-library to retrieve the latest (possibly unreleased) updates to the package. Need to get 1941 kB of source archives. Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main arm-compute-library 20.08+dfsg-5 (dsc) [2339 B] Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main arm-compute-library 20.08+dfsg-5 (tar) [1924 kB] Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main arm-compute-library 20.08+dfsg-5 (diff) [14.7 kB] Fetched 1941 kB in 0s (27.9 MB/s) Download complete and in download only mode I: NOTICE: Log filtering will replace 'build/arm-compute-library-q3qKDi/arm-compute-library-20.08+dfsg' with '<>' I: NOTICE: Log filtering will replace 'build/arm-compute-library-q3qKDi' with '<>' +--+ | Install package build dependencies | +--+ Setup apt archive - Merged Build-Depends: debhelper-compat (= 12), dh-exec (>= 0.3), scons (>= 2.4), doxygen, graphviz, build-essential, fakeroot Filtered Build-Depends: debhelper-compat (= 12), dh-exec (>= 0.3), scons (>= 2.4), doxygen, graphviz, build-essential, fakeroot dpkg-deb: building package 'sbuild-build-depends-main-dummy' in '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. Ign:1 copy:/<>/apt_archive ./ InRelease Get:2 copy:/<>/apt_archive ./ Release [609 B] Ign:3 copy:/<>/apt_archive ./ Release.gpg Get:4 copy:/<>/apt_archive ./ Sources [670 B] Get:5 copy:/<>/apt_archive ./ Packages [702 B] Fetched 1981 B in 0s (57.8 kB/s) Reading package lists... Reading package lists... Install main build dependencies (apt-based resolver) Installing build dependencies Reading package lists... Building dependency tree... Reading state information... The following additional packages will be installed: dh-exec doxygen fontconfig fontconfig-config fonts-dejavu-core graphviz libabsl20220623 libann0 libaom3 libavif15 libbrotli1 libbsd0 libcairo2 libcdt5 libcgraph6 libclang-cpp14 libclang1-14 libdatrie1 libdav1d6 libde265-0 libdeflate0 libedit2
Bug#1032032: FTBFS: error: AM_INIT_AUTOMAKE expanded multiple times
Source: fenix-plugins Version: 0.0.20070803-8 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi! I'm afraid your package fails to build; I see a lot of autoconf warnings, then they get fatal: Makefile.am: installing './depcomp' configure.ac:12: error: AM_INIT_AUTOMAKE expanded multiple times /usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from... configure.ac:11: the top level /usr/share/aclocal-1.16/init.m4:29: AM_INIT_AUTOMAKE is expanded from... configure.ac:12: the top level autom4te: error: /usr/bin/m4 failed with exit status: 1 aclocal: error: /usr/bin/autom4te failed with exit status: 1 autoreconf: error: aclocal failed with exit status: 1 dh_autoreconf: error: autoreconf -f -i agua-1.0 exec-0.4a fgfx-1.0 fire-1.0 fsock-1.0 image-1.0 mixer-1.0 mpeg-1.0 net-1.0 tcpsock-2.0 ttf-1.0 returned exit code 1 It appears the package is not compatible with new autotools; they have been updated quite a while ago but as the package is 32-bit only the failure wasn't noticed during usual QA efforts. I've verified the fail on i386 and armhf. Full log attached. Meow! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.2.0-00034-g2ff294a21c8d (SMP w/64 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) sbuild (Debian sbuild) 0.85.0 (04 January 2023) on valinor.angband.pl +==+ | fenix-plugins (i386) Sun, 26 Feb 2023 01:31:02 + | +==+ Package: fenix-plugins Distribution: unstable Machine Architecture: amd64 Host Architecture: i386 Build Architecture: i386 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-i386-sbuild-f27f2fb3-5a2c-41fa-94ad-2023f47260fb' with '<>' I: NOTICE: Log filtering will replace 'build/fenix-plugins-gpzT6Q/resolver-zNf5Pt' with '<>' +--+ | Update chroot| +--+ Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. +--+ | Fetch source files | +--+ Check APT - Checking available source versions... Download source files with APT -- Reading package lists... NOTICE: 'fenix-plugins' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/games-team/fenix-plugins.git Please use: git clone https://salsa.debian.org/games-team/fenix-plugins.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 7775 kB of source archives. Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main fenix-plugins 0.0.20070803-8 (dsc) [2749 B] Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main fenix-plugins 0.0.20070803-8 (tar) [7766 kB] Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main fenix-plugins 0.0.20070803-8 (diff) [6336 B] Fetched 7775 kB in 0s (262 MB/s) Download complete and in download only mode I: NOTICE: Log filtering will replace 'build/fenix-plugins-gpzT6Q/fenix-plugins-0.0.20070803' with '<>' I: NOTICE: Log filtering will replace 'build/fenix-plugins-gpzT6Q' with '<>' +--+ | Install package build dependencies | +--+ Setup apt archive - Merged Build-Depends: debhelper-compat (= 12), zlib1g-dev, libsdl1.2-dev, libsdl-image1.2-dev, libsdl-net1.2-dev, libsdl-mixer1.2-dev, libsmpeg-dev, libfreetype6-dev, fenix, fenix-dev, build-essential, fakeroot Filtered Build-Depends: debhelper-compat (= 12), zlib1g-dev, libsdl1.2-dev, libsdl-image1.2-dev, libsdl-net1.2-dev, libsdl-mixer1.2-dev, libsmpeg-dev, libfreetype6-dev, fenix, fenix-dev, build-essential, fakeroot dpkg-deb: building package 'sbuild-build-depends-main-dummy' in '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. Ign:1 copy:/<>/apt_archive ./
Bug#1027364: golang-github-go-co-op-gocron: FTBFS (missing build-depends on tzdata)
Control: close 1027364 On Sat, Jan 28, 2023 at 04:31:25PM +0100, Santiago Vila wrote: > retitle 1027364 golang-github-go-co-op-gocron: FTBFS (missing build-depends > on tzdata) > reopen 1027364 > found 0.5.0-2 > thanks > > Adam, please don't close bugs just because they say "bullseye" in the title. > In most cases, I really meant "bullseye and later". I've just re-tested: Distribution: bullseye Host Architecture: amd64 Source-Version: 0.5.0-2 Status: successful So the package does build ok. Do you have an example of a build environment that is not explicitly declared "totally broken" by the Policy (§2.5)? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#1027905: not reproducible in a valid sbuild chroot
Control: tags -1 +unreproducible Control: severity -1 wishlist Hi! You've done a MBF despite _negative_ consensus in several discussions (debian-devel, debootstrap, policy, ...); folks seem to be in agreement that either the Policy doesn't require building in an environment that is explicitly "totally broken" (§2.5), or at least that the issue is not RC. Thus: is there a way to reproduce this failure without intentionally removing tzdata? If not, I believe this bug should be closed -- and, if the change has already been applied in git, that it should be reverted. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#1029430: it's not tzdata
Control: tag -1 -patch Hi! The alleged patch doesn't fix the FTBFS. Besides the non-bug (per numerous discussions on debian-devel and elsewhere) of non-depending on a required package "tzdata", the package fails from an actual build failure even in a non-sabotaged build chroot. I'm thus untagging "patch". Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#919348: bring it in for Bookworm?
Hi! Would you be willing to reconsider for Bookworm? While you do have reservations about xfce4-screensaver, the question is not whether it's perfect, but how it fares against alternatives. And lightm-locker is so buggy it's outright useless for a good deal of users while reports for xfce4-screensaver are better. Thus even if not default, it'd be good to have it as an alternative -- at least installable. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#1021079: NMU w/o ppc64el?
On Mon, Jan 16, 2023 at 08:26:37AM +0200, Konstantinos Margaritis wrote: > On 15/1/23 03:33, Adam Borowski wrote: > > Hi! > > As you're apparently too busy to either fix ppc or suggest a different plan, > > I'd make a NMU dropping ppc64el for now so the package can be released with > > Bookworm. > > > > Please say if I shouldn't. > It is true that I am busy during this period, which may explain the lack of > communication. Now regarding vectorscan w/o ppc64le, I have 2 serious bugs I > want to fix before a new version upload (5.4.9), one is on Arm (a regression > compared to x86) and the other is the failure on ppc64le. How long do I have > to make an upload and ensure bookworm release? If that is too soon, then I > will make an upload asap myself disabling ppc64le until I fix this locally. Feb 12 is the cut-off; the package must be in testing at that time. Then if you have autopkgtests (vectorscan does), there's two more months before hard freeze. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#1021079: NMU w/o ppc64el?
Hi! As you're apparently too busy to either fix ppc or suggest a different plan, I'd make a NMU dropping ppc64el for now so the package can be released with Bookworm. Please say if I shouldn't. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Let's make a Debian conference in Yalta, Ukraine. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#1021079: disable the ppc64el binary for now?
Hi! As the window for new packages to [re-]enter bookworm will close soon, and fixing vectorscan on ppc doesn't appear to be coming, what about disabling that arch for now? It is described as "in development", thus it's not surprising it's not working yet. It'd be shame for the package to miss bookworm. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos? ⠈⠳⣄
Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)
Control: severity -1 wishlist Control: tags -1 +wontfix On Sun, Jan 01, 2023 at 11:49:26PM +0100, Santiago Vila wrote: > [ Thanks for fixing the bug in unstable so fast ] ... too fast, in fact. Per the discussion on debian-policy, it's not a bug, and this way I have a redundant dependency which actually is a bug (for a good reason: it makes it harder to reorganize unrelated packages). I've thus reverted the change -- in git, not worth a separate upload. > > I'm all for fixing bugs in stable that: > > * are obviously bugs (rather than a point of debate) > > You are the only one debating this, but it should really not be a point of > debate. Per debian-policy, indeed. Good that the debate has been resolved. [...] > [ In fact, I wonder why you bothered to add the missing B-D if you really > believe it > is not a bug. Because I considered doing so to be less effort than arguing. Which has proven to be premature. [...] > I think it is important to honor the promises we made to the users. We > promised a stable release without FTBFS bugs, and we are almost delivering > it, but not completely. > > In the end, it boils down to where do we draw the line. You think having > a reduced number of packages which FTBFS according to Policy is ok. I think > the only acceptable number of FTBFS bugs to have in a stable release is zero, > and I am working towards such goal. Here I agree, but inventing new bugs where there's no FTBFS is not helpful. "FTBFS" means the package actually fails to build from source, using any of build machinery present in the archive, on a realistic hardware/kernel/setup, for a distribution the given bug is marked as affecting. Thus, for example: a FTBFS with a future version of gcc or with buildflags that are not enabled yet is not a RC bug, becoming serious only once such a compiler/configuration is actually uploaded to unstable. Likewise, a change to the build environment where tzdata is no longer available, would be RC only in unstable but not in bullseye. > So the only thing I ask is that you do not insist that this is not a bug > when I reopen it for bullseye. Since I will be the one doing the work, > I think I should be allowed to use the BTS to track those bugs. Okay, I'm not closing the bug for bullseye. I did though reduce the severity to wishlist as it's (per the debian-policy discussion) neither RC nor even contravening bullseye's nor current unstable's policy, and the change is opposed by a number of people. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Bestest pickup line: ⢿⡄⠘⠷⠚⠋⠀ "Cutie, your name must be Suicide, cuz I think of you every day." ⠈⠳⣄
Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)
On Sun, Jan 01, 2023 at 01:53:31PM +0100, Santiago Vila wrote: > Adam Borowski escribió: > > nor any of people running archive rebuilds so far. > > FWIW: I am one of those people running archive rebuilds. > I rebuilt the entire bullseye distribution, and I'm trying > to make it FTBFS bug free, as mandated by both Debian Policy > and Release Policy. Bullseye has been a non-moving target for two years, thus changing requirements packages there are expected to meet is grossly belated. There are cases where adding such a requirement is worth the effort (eg. new hardware, or a hitherto unknown type of bugs), but I don't see how something with no practical benefit qualifies. This doesn't mean I intend to stop your efforts for releases currently in development -- I've already fixed this very bug in unstable (even though I disagree with the premise). But doing this for stable... come on... On Sun, Jan 01, 2023 at 01:46:06PM +0100, Santiago Vila wrote: > El 1/1/23 a las 12:58, Adam Borowski escribió: > > Control: tags -1 +unreproducible moreinfo > > I don't think the unreproducible tag applies here. > > To reproduce, just try to build it in a chroot which does > not include tzdata. If debootstrap does not do that by default, > then it follows that you should not simply accept debootstrap's defaults. No tool in Bullseye produces such build chroots, and this is what matters here. There's no practical benefit of retroactively changing packages: neither security rebuilds nor packages built by the users themselves will lack tzdata (the former because of build tools, the latter because of how Policy 2.5 defines "required"). Thus: I argue this is not a bug, and that even if it actually is a bug, there are no practical benefits of fixing it in _stable_. We are free to redefine requirements for future releases, of course. > This is Policy 4.2: > > > If build-time dependencies are specified, it must be possible to build the > > package and produce working binaries on a system with only essential and > > build-essential packages installed and also those required to satisfy the > > build-time relationships > (including any implied relationships). > > So yes, this is undoubtedly a bug, because tzdata is not build-essential. It is. It is merely not included in the _informational_ list shipped by a metapackage by that name; it explicitly says: # This package is NOT the definition of what packages are # build-essential; the real definition is in the Debian Policy Manual. # This package contains merely an informational list, which is all # most people need. However, if this package and the manual disagree, # the manual is correct. And Policy 4.2 which you just quoted says: # (including any implied relationships) I'd say that the Policy declaring systems that lack Priority:required packages to be broken fulfills this clause. > I could agree that everything would be easier if debootstrap was fixed once > and forever: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837060 > > If you can push for that bug to be fixed for bookworm, that would certainly > help. It seems that multiple debootstrap maintainers disagree -- and so do I. But, as I said before, I have no real objections to changing this for Bookworm. Making an upload to add the B-Dependency was less effort than arguing, and I've already one so, thus complying with whatever rule wins. > > I have nothing against adding such a B-Dependency in unstable: this is where > > new development is supposed to be done, preparing a new upload costs but a > > few mins of my time. On the other hand, updating stable requires extensive > > process and wastes the time of me, the Release Team, of people preparing the > > new point release announcement, of users testing and deploying the update. > > Of course fixing bugs takes a little bit of time, but it may also be argued > that > not fixing this kind of bugs produces weird effects which makes some people > to lose > some of their time (for example, me building the whole archive trying to keep > stable free > from any kind of FTBFS bugs). These bugs are caused only by your intentional change to build chroots you use. You can save that time by not doing that _active_ step for past releases. > If, despite having a trivial fix for the bug, you decide > not to fix it in stable and leave the fix for others, I will have less time > for other things > which I also want to fix. I know that some people will not agree, but I > believe fixing > FTBFS bugs in stable should be primarily a responsibility of the affected > maintainers. > Offloading the work to those particularly interested in stable does not scale > well. I'm all for fixing bugs in stable that: * are obviously bugs (rather than a point of
Bug#1027380: safeclib: FTBFS in bullseye (missing build-depends on tzdata)
Control: tags -1 +unreproducible moreinfo On Fri, Dec 30, 2022 at 07:04:09PM +0100, Santiago Vila wrote: > Package: src:safeclib > Version: 3.5-3 > Severity: serious > Tags: ftbfs patch > During a rebuild of all packages in bullseye, your package failed to build: > FAIL: t_gmtime_s > FAIL: t_localtime_s > PASS: t_getenv_s > PASS: t_bsearch_s > PASS: t_qsort_s I can't reproduce the failure using any of common menthods of creating a build chroot. Neither could the buildds nor any of people running archive rebuilds so far. Is there any way _relevant for bullseye_ that would produce the build chroot without a Priority:required package such as tzdata? If not, I don't believe this is a bug for stable. Not merely a serious bug, not a bug at all -- it can't happen on buildds nor on user systems. I have nothing against adding such a B-Dependency in unstable: this is where new development is supposed to be done, preparing a new upload costs but a few mins of my time. On the other hand, updating stable requires extensive process and wastes the time of me, the Release Team, of people preparing the new point release announcement, of users testing and deploying the update. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Quis trollabit ipsos trollos? ⠈⠳⣄
Bug#1016953: fixed upstream
Control: tags -1 +fixed-upstream I see this is fixed upstream, thus you can unrevert to the current version. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Your snowflakes have nothing on my socks drawer. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#1020765: Does Debian 11.x 32 bit support NVDIMM?
Control: severity -1 normal Control: tags -1 +moreinfo On Tue, Oct 04, 2022 at 05:57:12PM +, Williams, Dan J wrote: > On Mon, 26 Sep 2022 08:26:56 + Winnie Yue wrote: > > Package: ndctl > > Version: 71.1-1 > > Severity: serious > > For Debian 11.5 32 bit, I got below info: > > But I found that Debian 11.5 32 bit vm couldn’t recognize the NVDIMM device: > > # dmesg | grep -i bios-e820 | grep persistent > > [ 0.00] BIOS-e820: [mem 0x00024000-0x00043fff] > > persistent (type 7) > > Note that this is not sufficient for advertising NVDIMM resources. A > Type-7 memory range still requires an ACPI NFIT to advertise the memory > range. Thanks Dan for this bit, I've missed it. Winnie: please try passing the proper ACPI data; your email address suggests that your VM is one I don't know how to operate. > That said, why are you trying to run a 32-bit environment. If you need a > 32-bit userspace you can still use a 64-bit kernel. 32-bit x86 is not > well looked after by the kernel community in general these days. That's another point; time spent validating a 32-bit kernel isn't that useful. I was really shocked it can use NVDIMM at all. In the userland, you can't count on the stack other than the very lowest level (ie, ndctl). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ It's time to migrate your Imaginary Protocol from version 4i to 6i. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#1020978: FTBFS: *** DH_PHP_VERSIONS cannot be empty. Stop.
Source: tideways Version: 5.0.4-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi! I'm afraid your package fails to build: Command: dpkg-buildpackage --sanitize-env -us -uc -b -rfakeroot dpkg-buildpackage: info: source package tideways dpkg-buildpackage: info: source version 5.0.4-2 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Ondřej Surý dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 fakeroot debian/rules clean sed: can't read debian/control.in: No such file or directory DH_PHP_VERSIONS_DEFAULT := "" DH_PHP_VERSIONS_OVERRIDE := "" AVAILABLE_PHP_VERSIONS := "8.1" /usr/share/dh-php/pkg-pecl.mk:50: *** DH_PHP_VERSIONS cannot be empty. Stop. dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 2 Meow! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-rc7-00050-g3dbd74b86e01 (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#1020977: FTBFS: *** DH_PHP_VERSIONS cannot be empty. Stop.
Source: php-facedetect Version: 1.1.0-19-g135c72a-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi! I'm afraid your package fails to build: Command: dpkg-buildpackage --sanitize-env -us -uc -b -rfakeroot dpkg-buildpackage: info: source package php-facedetect dpkg-buildpackage: info: source version 1.1.0-19-g135c72a-2 dpkg-buildpackage: info: source distribution unstable dpkg-buildpackage: info: source changed by Ondřej Surý dpkg-source --before-build . dpkg-buildpackage: info: host architecture amd64 fakeroot debian/rules clean sed: can't read debian/control.in: No such file or directory DH_PHP_VERSIONS_DEFAULT := "" DH_PHP_VERSIONS_OVERRIDE := "" AVAILABLE_PHP_VERSIONS := "8.1" /usr/share/dh-php/pkg-pecl.mk:50: *** DH_PHP_VERSIONS cannot be empty. Stop. dpkg-buildpackage: error: fakeroot debian/rules clean subprocess returned exit status 2 Meow! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-rc7-00050-g3dbd74b86e01 (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#1020973: FTBFS: distutils.errors.DistutilsClassError: command class [...] must subclass Command
Source: devscripts
Version: 2.22.2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi!
I'm afraid your package fails to build:
python3 setup.py clean -a
/<>/scripts/setup.py:5: DeprecationWarning: The distutils package
is deprecated and slated
for removal in Python 3.12. Use setuptools or check PEP 632 for potential
alternatives
from distutils.command.clean import clean as BaseCleanCommand
/usr/lib/python3/dist-packages/_distutils_hack/__init__.py:18: UserWarning:
Distutils was imported befo
re Setuptools, but importing Setuptools also replaces the `distutils` module in
`sys.modules`. This may
lead to undesirable behaviors or errors. To avoid these issues, avoid using
distutils directly, ensure
that setuptools is installed in the traditional way (e.g. not an editable
install), and/or make sure t
hat setuptools is always imported before distutils.
warnings.warn(
/usr/lib/python3/dist-packages/_distutils_hack/__init__.py:33: UserWarning:
Setuptools is replacing dis
tutils.
warnings.warn("Setuptools is replacing distutils.")
Traceback (most recent call last):
File "/<>/scripts/setup.py", line 37, in
setup(
File "/usr/lib/python3/dist-packages/setuptools/__init__.py", line 87, in
setup
return distutils.core.setup(**attrs)
File "/usr/lib/python3/dist-packages/setuptools/_distutils/core.py", line
172, in setup
ok = dist.parse_command_line()
File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line
479, in parse_command_line
args = self._parse_command_opts(parser, args)
File "/usr/lib/python3/dist-packages/setuptools/dist.py", line 1107, in
_parse_command_opts
nargs = _Distribution._parse_command_opts(self, parser, args)
File "/usr/lib/python3/dist-packages/setuptools/_distutils/dist.py", line
545, in _parse_command_opts
raise DistutilsClassError(
distutils.errors.DistutilsClassError: command class must subclass Com
mand
make[2]: *** [Makefile:143: clean] Error 1
Meow!
-- Package-specific info:
--- /etc/devscripts.conf ---
Empty.
--- ~/.devscripts ---
DEBCHANGE_RELEASE_HEURISTIC=log
DEBSIGN_KEYID=FD9CE2D8D7754B78AB279BBD2C3B436FEAC68101
DSCVERIFY_KEYRINGS="~/.gnupg/pubring.gpg"
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
(120, 'experimental'), (1, 'experimental-debug')
merged-usr: no
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.0.0-rc7-00050-g3dbd74b86e01 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Bug#1020970: elpa-evil: fails to install: wrong-number-of-arguments
Package: elpa-evil Version: 1.14.0-1 Severity: grave Justification: non-installable Hi! I'm afraid your package fails to install: Setting up elpa-evil (1.14.0-1) ... tsort: -: input contains a loop: tsort: emacsen-common tsort: elpa-goto-chg tsort: -: input contains a loop: tsort: elpa-undo-tree tsort: emacsen-common Install elpa-queue for emacs install/queue-0.2: Handling install of emacsen flavor emacs install/queue-0.2: byte-compiling for emacs Install elpa-undo-tree for emacs install/undo-tree-0.8.1: Handling install of emacsen flavor emacs install/undo-tree-0.8.1: byte-compiling for emacs Install emacsen-common for emacs emacsen-common: Handling install of emacsen flavor emacs Install elpa-goto-chg for emacs install/goto-chg-1.7.3: Handling install of emacsen flavor emacs install/goto-chg-1.7.3: byte-compiling for emacs Install elpa-evil for emacs install/evil-1.14.0: Handling install of emacsen flavor emacs install/evil-1.14.0: byte-compiling for emacs Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) In toplevel form: evil-command-window.el:36:1: Error: Wrong number of arguments: (3 . 4), 2 Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) In toplevel form: evil-commands.el:29:1: Error: Wrong number of arguments: (3 . 4), 2 In evil-add-to-alist: evil-common.el:128:18: Warning: ‘evil-add-to-alist’ is an obsolete function (as of 1.13.1); use ‘evil--add-to-alist’ instead. You may need to recompile code with evil macros. In evil-with-view-list: evil-common.el:3922:11: Warning: docstring wider than 80 characters In toplevel form: evil-core.el:181:31: Warning: defcustom for ‘evil-mode’ fails to specify containing group evil-core.el:181:31: Warning: defcustom for ‘evil-mode’ fails to specify containing group In toplevel form: evil-ex.el:596:1: Error: Wrong number of arguments: (3 . 4), 2 Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) In toplevel form: evil-integration.el:35:1: Error: Wrong number of arguments: (3 . 4), 2 In toplevel form: evil-jumps.el:38:1: Warning: custom-declare-variable `evil-jumps-cross-buffers' docstring wider than 80 characters evil-jumps.el:58:1: Warning: custom-declare-variable `evil-jumps-ignored-file-patterns' docstring wider than 80 characters evil-jumps.el:71:1: Warning: defvar `evil--jumps-buffer-targets' docstring wider than 80 characters Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) In toplevel form: evil-keybindings.el:35:1: Error: Wrong number of arguments: (3 . 4), 2 Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) In toplevel form: evil-maps.el:29:1: Error: Wrong number of arguments: (3 . 4), 2 In evil-repeat-force-abort-p: evil-repeat.el:242:8: Warning: docstring wider than 80 characters In evil-repeat-motion: evil-repeat.el:349:8: Warning: docstring wider than 80 characters Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) In toplevel form: evil-search.el:30:1: Error: Wrong number of arguments: (3 . 4), 2 Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) Eager macro-expansion failure: (wrong-number-of-arguments (3 . 4) 2) In toplevel form: evil.el:133:1: Error: Wrong number of arguments: (3 . 4), 2 ERROR: install script from elpa-evil package failed dpkg: error processing package elpa-evil (--configure): installed elpa-evil package post-installation script subprocess returned error exit status 1 Meow! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-rc7-00050-g3dbd74b86e01 (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages elpa-evil depends on: ii dh-elpa-helper 2.0.12 ii elpa-goto-chg 1.7.3-1 ii elpa-undo-tree 0.8.1-1 ii emacs 1:28.1+1-4 ii emacs-gtk [emacs] 1:28.1+1-4 ii emacsen-common 3.0.4 Versions of packages elpa-evil recommends: ii emacs 1:28.1+1-4 ii emacs-gtk [emacs] 1:28.1+1-4 elpa-evil suggests no packages. -- no debconf information
Bug#1020259: sysvinit-core: missing manpage takeover handling
On Mon, Sep 19, 2022 at 12:56:16AM +0200, Thorsten Glaser wrote: > On Mon, 19 Sep 2022, Andreas Beckmann wrote: > > > usr/share/man/es/man8/runlevel.8.gz > > How can that be? They are diverted from preinst, positively this one. I can't reproduce either; sample run: https://angband.pl/tmp/piu_sysvinit-core.html Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄ `
Bug#1019553: FTBFS: ts_file_io
On Tue, Sep 13, 2022 at 01:52:46PM +0200, Jean Baptiste Favre wrote: > Hello Adam, > Thanks for your report. > I've unable to reproduce the build failure as of now, using both a docker > image and sbuild on my laptop (amd64 only). > > The failing test simply tries to open /etc/hosts (which should be present > inside chroot), read it and look for the string localhost inside. Not sure why it's present on your sbuild but not in mine, but in bookworm netbase (which generates /etc/hosts if none has been providen from the outside) is no longer pulled in by build-essential. Thus, an explicit Build-Depends: netbase would ensure /etc/hosts is there. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Bestest pickup line: ⢿⡄⠘⠷⠚⠋⠀ "Cutie, your name must be Suicide, cuz I think of you every day." ⠈⠳⣄
Bug#1018043: zutils: statically linked
On Fri, Sep 02, 2022 at 01:50:28PM +0200, Daniel Baumann wrote: > tag 1018043 pending > thanks ♥ > On 8/24/22 17:40, Adam Borowski wrote: > > This package has a massive size > > massive is relative.. it's 490KB. 4591 kB here... > there was a reason (see #608484), but I guess with merged-usr this isn't > a problem anymore anyway. merged-usr is unrelated here: we have dropped support for booting the system without /usr /etc /var mounted several years ago; merged usr is about moving things around replacing them with symlinks. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ʀᴜꜱꜱɪᴀɴᴇꜱ ᴇᴜɴᴛ ᴅᴏᴍᴜꜱ ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#1018043: zutils: statically linked
Package: zutils Version: 1.11-5, 1.12~pre2-1 Severity: serious Justification: Policy 10.1 Hi! This package has a massive size, as it's pointlessly statically built. Not only this violates a "must" requirement of the Policy, it also does so for no benefit at all: in the case libraries it's linked with would be subverted/corrupted, both the compressor and the actual tool invoked won't be able to run anyway. On the other hand, any security hole in any library the program links with potentially requires a recompile. Even glibc itself receives several CVEs per year; they are in functions you almost surely don't use but the binary doesn't provide this information anymore -- requiring the Security Team to analyze what is going on. That's why the Policy hates this seemingly minor issue so much. Meow! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') merged-usr: no Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.3-00017-g519775569157 (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages zutils depends on: ii libc6 2.35-0experimental1 ii libgcc-s1 12.2.0-1 ii libstdc++6 12.2.0-1 Versions of packages zutils recommends: ii bzip2 1.0.8-5 ii lzip 1.23-4 ii xz-utils 5.2.5-2.1 ii zstd 1.5.2+dfsg-1 zutils suggests no packages. -- no debconf information
Bug#1017239: valgrind suppressions
Control: block -1 by 1018035 It'd be much better to fix the suppressions in src:valgrind rather than in dependers. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ You're alive. But that's just a phase. ⠈⠳⣄
Bug#1017441: marked as done (debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles)
Control: reopen -1 On Tue, Aug 16, 2022 at 05:09:03PM +, Debian Bug Tracking System wrote: > Your message dated Tue, 16 Aug 2022 19:06:12 +0200 > with message-id <429a5094-bef5-3b75-bfce-684319dfa...@debian.org> > and subject line Re: Bug#1017441: debhelper: building src:shadow wrongly > makes passwd depend on systemd | systemd-tmpfiles > has caused the Debian Bug report #1017441, > regarding debhelper: building src:shadow wrongly makes passwd depend on > systemd | systemd-tmpfiles > to be marked as done. > From: Michael Biebl > Am 16.08.22 um 16:13 schrieb Luca Boccassi: > > This looks entirely correct to me. You can install the -standalone > > variant if you prefer a slightly smaller footprint, which is provided > > exactly for those non-default use cases. > > > > Indeed, the passwd package installs a tmpfiles config and the generated > maintainer scripts do call systemd-tmpfiles, so the generated dependency is > correct. > The standalone binaries, as mentioned can be used for more minimal > environments, when a smaller disk footprint is desired. That said, > installing the systemd package inside a container is totally fine as well. > > Anyway, nothing to fix here, thus closing. Please go away. Your autoclosure of bugs regardless of severity is not helpful, and you keep trolling even severity:critical ones for years. Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ You're alive. But that's just a phase. ⠈⠳⣄
Bug#1017441: debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles
On Tue, Aug 16, 2022 at 03:13:35PM +0100, Luca Boccassi wrote: > On Tue, 16 Aug 2022 13:13:53 +0200 Johannes Schauer Marin Rodrigues > > The package passwd=1:4.11.1+dfsg1-2 in the archive does not have the > > dependency on "systemd | systemd-tmpfiles" and was compiled with > > debhelper 13.6. > > > > This currently installs systemd on a systems that don't need it, > which > > is especially bad for minimal and embedded systems and/or containers. > > Thus setting the severity to serious. Feel free to adjust. > This looks entirely correct to me. You can install the -standalone > variant if you prefer a slightly smaller footprint, which is provided > exactly for those non-default use cases. No, the "passwd" package does not need systemd (nor its -standalone subset as evidenced by currently working fine). And the added dependency has the tiny little effect of effectively dropping three official architectures plus a number of unofficial but known to be worked on. Breaking machines that fail to boot with systemd, or are configured in a way that doesn't work with it is also not nice. And minimal/embedded systems really don't want the extra 460KB -standalone binary, either. The regression here is commit 0e313c2f58df0f8ce6389380d735767dfaa936ab; I've read changelogs of all packages that have since gained this automatic dependency¹, and it appears none have a mention of relying on tmpfiles on !systemd, with one exception -- tomcat9 -- which manually depends on systemd-tmpfiles thus doesn't need the debhelper change. The stated reason for the change, roundcube (#1013969) hasn't been uploaded yet thus it still works fine via cron. If the maintainer wants to migrate to systemd ways, he can add the dependency on systemd-tmpfiles by hand, just like tomcat9 does. That'd be a regression but oh well. Thus, it doesn't appear like a revert would have any downsides. Meow! [¹]. grep-aptavail -F Depends systemd-tmpfiles -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Collisions shmolisions, let's see them find a collision or second ⢿⡄⠘⠷⠚⠋⠀ preimage for double rot13! ⠈⠳⣄
Bug#1017441: it also makes packages non-installable
Beside forcing a switch to systemd (or systemd-tmpfiles if the admin knows about this option, which is not given in any messages), this wrong dependency also makes Required packages non-installable on: * hurd * kfreebsd * musl ports (prepared by helmut as a part of rebootstrap, and by others) * derivatives Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ You're alive. But that's just a phase. ⠈⠳⣄
Bug#1016996: libnl-3-200-udeb: uninstallable, depends on non-udeb sgml-base
On Thu, Aug 11, 2022 at 02:00:59AM +0200, Cyril Brulebois wrote:
> The set of packages you uploaded contains uninstallable udebs, as they
> depend on sgml-base, which doesn't exist in the installer context
> (there's no udeb for it.
> This is not your fault, that's debhelper's #1015263:
Yeah but I shouldn't have let the bad dependency through.
My sponsoring workflow automates this kind of checks for regular packages
but fails to check udebs, and I thus don't have in mind to look by hand.
Apologies.
But then, we do have _someone_ to spot and fix such problems :þ
> +libnl3 (3.7.0-0.2) unstable; urgency=medium
> +
> + * Non-maintainer upload.
> + * Dodge debhelper's #1015263 by resetting misc:Depends via
> +DEB_DH_GENCONTROL_ARGS_libnl{,-genl}-3-200-udeb to avoid pulling
> +sgml-base.
> +
> + -- Cyril Brulebois Wed, 10 Aug 2022 23:43:51 +
> +# Dodge debhelper's #1015263, pulling sgml-base for udebs:
> +DEB_DH_GENCONTROL_ARGS_$(udeb_libnl) = -- -Vmisc:Depends=
> +DEB_DH_GENCONTROL_ARGS_$(udeb_libnl_genl) = -- -Vmisc:Depends=
Thanks!
Meow.
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ What kind of a drug are "base" and "red pill"? I think acid is
⢿⡄⠘⠷⠚⠋⠀ LSD, which would make base... ? Judging from the behaviour of
⠈⠳⣄ those "based and redpilled", something nasty.
Bug#1014805: breaks users' systems
Control: reassign -1 udev Control: retitle -1 udev: Please drop systemd from Depends > Control: reassign -1 sysvinit-core > Control: retitle -1 sysvinit-core: please depend on > systemd-standalone-sysusers, systemd-standalone-tmpfiles > > On Fri, 2022-07-22 at 21:19 +0200, Adam Borowski wrote: > > And if you want a real package first, -standalone is a clear winner > > here. > > That sounds too fragile for packages involved in debootstrap. It seems > more reasonable to have sysvinit-core pull it in for those who care as > was suggested earlier. Sorry, there is no way to do so in sysvinit. Sysvinit itself doesn't depend on udev thus it _really_ doesn't want a 450KB extra in tiny containers -- and there are many other inits: runit-init, all those dumb-init finit-sysv pid1 tiny, see my .sig; then it's fully valid and supported to run without any init at all. The fix must be done in the package that regressed -- ie, udev. And I really don't appreciate adding 450KB to small containers; reducing their size is something many of us is fighting for for many years. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .globl _start;.data;rc: .ascii "/etc/init.d/rcS\0";.text;_start ⣾⠁⢠⠒⠀⣿⡁ mov $57,%rax;syscall;cmp $0,%rax;jne child;parent:;mov $61,%rax ⢿⡄⠘⠷⠚⠋⠀ mov $-1,%rdi;xor %rsi,%rsi;xor %rdx,%rdx;syscall;jmp parent;child: ⠈⠳⣄ mov $59,%rax;mov $rc,%rdi;xor %rsi,%rsi;xor %rdx,%rdx;syscall
Bug#1013910: src:mlucas: invalid maintainer address
On Mon, Jun 27, 2022 at 10:41:58AM +0200, Ansgar wrote: > Source: mlucas > Version: 20.1.1-1 > Severity: serious > The maintainer address for src:mlucas is obviously invalid: > > Maintainer: Alex Vong Well, besides the doofus sponsor who *somehow* managed to not notice this change, let's CC the _previous_ maintainer. Alex: the new address' "alexvong1995-AT-protonmail-DOT-com" server can't be contacted -- it fails with: drill -t mx nospam.invalid ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN drill -t nospam.invalid ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN drill -t a nospam.invalid ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN Could you perhaps take the package back, and fix build failures on most archs? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ What kind of a drug are "base" and "red pill"? I think acid is ⢿⡄⠘⠷⠚⠋⠀ LSD, which would make base... ? Judging from the behaviour of ⠈⠳⣄ those "based and redpilled", something nasty.
Bug#1011546: FTBFS: echo "You forgot to fix the VERSION in configure.ac!"
Source: tmpreaper Version: 1.6.16 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi! I'm afraid your package fails to build, with: dh_testdir ./tmpreaper -h 2>&1 | grep 'tmpreaper -- Version: '1.6.16-DEB || (echo "You forgot to fix the VERSION in configure.ac!"; exit 1) You forgot to fix the VERSION in configure.ac! make: *** [debian/rules:42: build-stamp] Error 1 Full log attached. Meow! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.18.0-00017-g251fbd8b0fa2 (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) sbuild (Debian sbuild) 0.83.1 (26 April 2022) on valinor.angband.pl +==+ | tmpreaper (amd64)Tue, 24 May 2022 16:01:14 + | +==+ Package: tmpreaper Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-a7cddd52-2cb9-4f29-a54a-d58c611b5747' with '<>' I: NOTICE: Log filtering will replace 'build/tmpreaper-XX34zY/resolver-fy7iiL' with '<>' +--+ | Update chroot| +--+ Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. +--+ | Fetch source files | +--+ Check APT - Checking available source versions... Download source files with APT -- Reading package lists... Need to get 160 kB of source archives. Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main tmpreaper 1.6.16 (dsc) [1437 B] Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main tmpreaper 1.6.16 (tar) [159 kB] Fetched 160 kB in 0s (475 kB/s) Download complete and in download only mode I: NOTICE: Log filtering will replace 'build/tmpreaper-XX34zY/tmpreaper-1.6.16' with '<>' I: NOTICE: Log filtering will replace 'build/tmpreaper-XX34zY' with '<>' +--+ | Install package build dependencies | +--+ Setup apt archive - Merged Build-Depends: debhelper (>= 5), e2fslibs-dev, po-debconf, libmount-dev, build-essential, fakeroot Filtered Build-Depends: debhelper (>= 5), e2fslibs-dev, po-debconf, libmount-dev, build-essential, fakeroot dpkg-deb: building package 'sbuild-build-depends-main-dummy' in '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. Ign:1 copy:/<>/apt_archive ./ InRelease Get:2 copy:/<>/apt_archive ./ Release [957 B] Ign:3 copy:/<>/apt_archive ./ Release.gpg Get:4 copy:/<>/apt_archive ./ Sources [387 B] Get:5 copy:/<>/apt_archive ./ Packages [470 B] Fetched 1814 B in 0s (129 kB/s) Reading package lists... Reading package lists... Install main build dependencies (apt-based resolver) Installing build dependencies Reading package lists... Building dependency tree... Reading state information... The following additional packages will be installed: comerr-dev libblkid-dev libext2fs-dev libmount-dev libpcre2-16-0 libpcre2-32-0 libpcre2-dev libpcre2-posix3 libselinux1-dev libsepol-dev uuid-dev Suggested packages: doc-base The following NEW packages will be installed: comerr-dev libblkid-dev libext2fs-dev libmount-dev libpcre2-16-0 libpcre2-32-0 libpcre2-dev libpcre2-posix3 libselinux1-dev libsepol-dev sbuild-build-depends-main-dummy uuid-dev 0 upgraded, 12 newly installed, 0 to remove and 0 not upgraded. Need to get 2662 kB of archives. After this operation, 9079 kB of additional disk space will be used. Get:1 copy:/<>/apt_archive ./ sbuild-build-depends-main-dummy 0.invalid.0 [896 B] Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main amd64 comerr-dev amd64 2.1-1.46.5-2 [109 kB] Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main amd64
Bug#1011530: FTBFS: fails to include system headers
Source: mac-fdisk
Version: 0.1-18
Severity: serious
Tags: ftbfs
Justification: fails to build from source
Hi!
I'm afraid that mac-fdisk fails to build with the toolchain in current
unstable. It doesn't include public headers, which results in a lot
of warnings like:
pdisk.c:156:5: warning: implicit declaration of function ‘exit’
[-Wimplicit-function-declaration]
156 | exit(err);
| ^~~~
pdisk.c:52:1: note: include ‘’ or provide a declaration of ‘exit’
pdisk.c:469:13: warning: implicit declaration of function ‘strncmp’
[-Wimplicit-function-declaration]
469 | if (strncmp(type_name, kFreeType, DPISTRLEN) == 0) {
| ^~~
pdisk.c:52:1: note: include ‘’ or provide a declaration of ‘strncmp’
dpme.h:48:25: warning: ‘strncmp’ argument 3 type is ‘int’ where ‘unsigned int’
is expected in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
dump.c:319:21: warning: incompatible implicit declaration of built-in function
‘malloc’ [-Wbuiltin-declaration-mismatch]
319 | data = (DPME *) malloc(PBLOCK_SIZE);
| ^~
dump.c:319:21: note: include ‘’ or provide a declaration of ‘malloc’
and some fatal errors:
errors.c: In function ‘fatal’:
errors.c:118:30: error: ‘sys_nerr’ undeclared (first use in this function)
118 | if (value > 0 && value < sys_nerr) {
| ^~~~
errors.c:118:30: note: each undeclared identifier is reported only once for
each func
tion it appears in
errors.c:119:37: error: ‘sys_errlist’ undeclared (first use in this function)
119 | fprintf(stderr, " (%s)\n", sys_errlist[value]);
| ^~~
Full log attached.
Meow!
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
(120, 'experimental'), (1, 'experimental-debug')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.18.0-00017-g251fbd8b0fa2 (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
sbuild (Debian sbuild) 0.83.1 (26 April 2022) on valinor.angband.pl
+==+
| mac-fdisk (i386) Tue, 24 May 2022 15:36:21 + |
+==+
Package: mac-fdisk
Distribution: unstable
Machine Architecture: amd64
Host Architecture: i386
Build Architecture: i386
Build Type: binary
I: NOTICE: Log filtering will replace
'var/run/schroot/mount/unstable-i386-sbuild-c89c94f3-c7e0-4819-8956-a172ad00da2c'
with '<>'
I: NOTICE: Log filtering will replace 'build/mac-fdisk-SIbUU1/resolver-pC5EEC'
with '<>'
+--+
| Update chroot|
+--+
Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
+--+
| Fetch source files |
+--+
Check APT
-
Checking available source versions...
Download source files with APT
--
Reading package lists...
NOTICE: 'mac-fdisk' packaging is maintained in the 'Git' version control system
at:
git://github.com/glaubitz/mac-fdisk-debian.git
Please use:
git clone git://github.com/glaubitz/mac-fdisk-debian.git
to retrieve the latest (possibly unreleased) updates to the package.
Need to get 78.1 kB of source archives.
Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main mac-fdisk 0.1-18
(dsc) [2010 B]
Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main mac-fdisk 0.1-18
(tar) [55.8 kB]
Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main mac-fdisk 0.1-18
(diff) [20.3 kB]
Fetched 78.1 kB in 0s (299 kB/s)
Download complete and in download only mode
I: NOTICE: Log filtering will replace 'build/mac-fdisk-SIbUU1/mac-fdisk-0.1'
with '<>'
I: NOTICE: Log filtering will replace 'build/mac-fdisk-SIbUU1' with
'<>'
+--+
| Install package build dependencies |
+--+
Setup apt archive
-
Merged Build-Depends: debhelper, build-essential, fakeroot
Filtered Build-Depends:
Bug#1011494: FTBFS: compat level 6 unsupported
Source: atitvout Version: 0.4-13.1 Severity: serious Tags: ftbfs Justification: fails to build from source dh_clean: error: Compatibility levels before 7 are no longer supported (level 6 requested) That's pretty self-explaining...
Bug#1011124: iotjs: is this package maintained?
Source: iotjs Version: 1.0+715-1 Severity: serious Justification: In the opinion of a QA person the package is unsuitable for release. Hi! This package appears to be unmaintained, and: * has a large set of CVEs reported. They are also untriaged and have seen no maintainer response. * blocks Python 2 removal I thus believe our users are better served by not being exposed to the package in its current state. If you disagree, please just close this bug. Meow!
Bug#1008613: usrmerge: fails to undo the damage on uninstall
Package: usrmerge Version: 25 Severity: grave Justification: causes non-serious data loss Due to a lacking *rm script that would recover the system back to a supported scheme, the system remains tainted by aliased-dirs even if the usrmerge package is uninstalled. Such a scheme is explicitly unsupported by dpkg. A proposed solution is to run dpkg-fsys-usrunmess in prerm. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.17.0-00017-g2526ae7adaeb (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages usrmerge depends on: ii debconf [debconf-2.0] 1.5.79 ii libfile-find-rule-perl 0.34-1 ii perl5.34.0-3 usrmerge recommends no packages. usrmerge suggests no packages.
Bug#998867: bumping severity
Control: severity -1 critical The current severity, "grave", is a serious understatement. As all buildd chroots that are created with buggy debootstrap are tainted, any packages built recently may assume merged usr, and thus needs to be rebuilt. Do we have a patch? If not, let's revert, today or tomorrow at the latest. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A white dwarf seeks a red giant for a binary relationship. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#995600: FTBFS: error: format not a string literal and no format arguments
Source: omega-rpg Version: 1:0.90-pa9-16 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi! I'm afraid that your package fails to build with: scr.c: In function ‘print1’: scr.c:351:5: error: format not a string literal and no format arguments [-Werror=format-security] 351 | wprintw(Msg1w,s); | ^~~ scr.c: In function ‘nprint1’: scr.c:361:7: error: format not a string literal and no format arguments [-Werror=format-security] 361 | wprintw(Msg1w,s); | ^~~ scr.c: In function ‘print2’: scr.c:374:5: error: format not a string literal and no format arguments [-Werror=format-security] 374 | wprintw(Msg2w,s); | ^~~ (repeated elebenty times) Meow! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-rc2-00041-g794e5d9c562d (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#995597: FTBFS: error: format not a string literal and no format arguments
Source: bsdgames Version: 2.17-28 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi! I'm afraid that your package fails to build: canfield/canfield/canfield.c: In function ‘instruct’: canfield/canfield/canfield.c:1650:3: error: format not a string literal and no format arguments [-Werror=format-security] 1650 | printw(*cp); | ^~ canfield/canfield/canfield.c:1663:3: error: format not a string literal and no format arguments [-Werror=format-security] 1663 | printw(*cp); | ^~ The obvious fix is to either add "%s" or use a function that doesn't do formatting. Meow! -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-rc2-00041-g794e5d9c562d (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#995480: FTBFS: error: format not a string literal and no format arguments
Source: ytree Version: 1.99pl1-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi! I'm afraid that your package fails to build with: input.c: In function ‘InputChoise’: input.c:352:3: error: format not a string literal and no format arguments [-Werror=format-security] 352 | mvprintw( LINES - 2, 1, msg ); | ^~~~ To fix: either use mvwaddstr() or add a "%s" before msg. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (120, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.15.0-rc2-00041-g794e5d9c562d (SMP w/64 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#907767: time to go, then
Control: clone -1 -2 Control: retitle -2 RM: mozplugger -- RoQA; useless; dead upstream Control: reassign -2 ftp.debian.org In Sep 2018, Adrian Bunk wrote: > As far as I can see, not a single one of the 15 (sic) browser packages > in the dependencies does both still exist in unstable and still work > with mozplugger. So what's the reason to keep it? I happen to know a group of guys (11 humans, 1 cat/god) who are good at dealing with "package X exists when it shouldn't". Have at it! drill -t any mozplugger.mozdev.org → NXDOMAIN Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can. ⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener. ⠈⠳⣄ A master species delegates.
Bug#992360: can be backported
Control: retitle -1 please backport to bullseye Control: severity -1 wishlist Hi! A package not making it to the stable release is by no means a RC bug, merely a statement of the package's quality at a time in the past. I'm adjusting severity accordingly. On the other hand, this case (and associated user frustration) can very well be solved by a backport. I've checked that it builds for Bullseye without modifications. Thus: XFCE guys, please upload to unstable and bullseye-backports! Thanks for your good work so far. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ If you ponder doing what Jesus did, remember than flipping tables ⢿⡄⠘⠷⠚⠋⠀ and chasing people with a whip is a prime choice. ⠈⠳⣄
Bug#990573: libpmem1: insufficient flushing on ARMv8.2+
Package: libpmem1
Version: 1.10-1
Severity: grave
Justification: causes data loss
[a fix is coming, filing this bug so the Release Team knows why]
Hi!
Support for arm64 in PMDK is deeply experimental. As far as I know, it has
never been tested on real hardware nor had been reviewed by someone with
adequate knowledge about ARM. Yet, enabling arm64 in our packages has been
requested multiple times, and bullseye / buster-backports do include arm64
builds. This was done with porting in mind, yet it looks like pmem-capable
ARM hardware is coming soon, and will be used in production not long after.
This makes inadequate support for new ARM chips unfortunate to say the least.
In ARMv8.0 and ARMv8.1, the only flushes available were CVAI (to make icache
= dcache, irrelevant for pmem), and CVAC ("flush to coherency"). The latter
was the deepest flush available, and implementors simply had no other option
than to have this instruction request the memory controller to send its data
to actual memory chips.
This changed in ARMv8.2, where a new instruction CVAP ("flush to
persistency") has been added, and CVAC was defined to require coherency only
between "agents" (such as CPU cores, GPU, etc) but not memory.
Yet PMDK knew only about CVAC -- despite asking around, no one of us could
get hold of an ARMv8.2 machine to implement detection/etc. Such support is
obviously not a priority for Intel nor IBM.
Only recently, I managed to get access to such a box, and implemented
flushes via CVAP. Without them, an unexpected power loss may result in
recent writes being lost. This is even worse than with disks -- a typical
filesystem will flush every 5 seconds or so, while there's no time-based
mechanism to flush CPU caches. If a machine finished its task and became
quiescent, it's possible the kernel and daemons won't actively touch more
than 16-64MB of L3 cache for hours or days.
The new flushes have been merged upstream in 1.11, I'm about to cherry-pick
to 1.10 for Bullseye.
Meow!
-- System Information:
Debian Release: 11.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.13.0-00032-g2fc675a48a0e (SMP w/64 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Versions of packages libpmem1 depends on:
ii libc6 2.31-12
ii libdaxctl1 71.1-1
ii libndctl6 71.1-1
libpmem1 recommends no packages.
libpmem1 suggests no packages.
-- no debconf information
Bug#892275: NMU in DELAYED/2
Hi! I've just prepared a NMU that drops the faulty .service, as proposed. There's no replacement yet, but window managers that implement some sort of session persistency will autostart redshift just fine; others might need manual start. If full autostart is wanted, it should be implemented using XDG instead. I'm not doing that yet, doing just the minimal change for Bullseye. The NMU is in DELAYED/2, please shout/cancel if anything. Debdiff attached. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ We domesticated dogs 36000 years ago; together we chased ⣾⠁⢠⠒⠀⣿⡁ animals, hung out and licked or scratched our private parts. ⢿⡄⠘⠷⠚⠋⠀ Cats domesticated us 9500 years ago, and immediately we got ⠈⠳⣄ agriculture, towns then cities. -- whitroth on /. diff -Nru redshift-1.12/debian/changelog redshift-1.12/debian/changelog --- redshift-1.12/debian/changelog 2021-04-21 13:34:47.0 +0200 +++ redshift-1.12/debian/changelog 2021-06-23 14:55:39.0 +0200 @@ -1,3 +1,11 @@ +redshift (1.12-4.2) unstable; urgency=medium + + * Non-maintainer upload. + * Drop broken systemd-based startup, without a replacement for now. +Closes: #892275 + + -- Adam Borowski Wed, 23 Jun 2021 14:55:39 +0200 + redshift (1.12-4.1) unstable; urgency=medium * Non-maintainer upload. diff -Nru redshift-1.12/debian/redshift-gtk.install redshift-1.12/debian/redshift-gtk.install --- redshift-1.12/debian/redshift-gtk.install 2020-12-12 17:43:43.0 +0100 +++ redshift-1.12/debian/redshift-gtk.install 2021-06-23 14:53:25.0 +0200 @@ -1,6 +1,5 @@ usr/bin/redshift-gtk usr/lib/python* -usr/lib/systemd/user/redshift-gtk.service usr/share/applications/redshift-gtk.desktop usr/share/icons usr/share/metainfo/redshift-gtk.metainfo.xml diff -Nru redshift-1.12/debian/redshift.install redshift-1.12/debian/redshift.install --- redshift-1.12/debian/redshift.install 2020-12-12 17:43:43.0 +0100 +++ redshift-1.12/debian/redshift.install 2021-06-23 14:53:15.0 +0200 @@ -1,6 +1,5 @@ etc/apparmor.d/usr.bin.redshift usr/bin/redshift -usr/lib/systemd/user/redshift.service usr/share/applications/redshift.desktop usr/share/locale usr/share/man/man1/redshift.1 diff -Nru redshift-1.12/debian/rules redshift-1.12/debian/rules --- redshift-1.12/debian/rules 2021-04-21 13:34:44.0 +0200 +++ redshift-1.12/debian/rules 2021-06-23 14:54:20.0 +0200 @@ -12,7 +12,6 @@ override_dh_auto_configure: intltoolize --force dh_auto_configure -- \ - --with-systemduserunitdir=/usr/lib/systemd/user/ \ --enable-randr --enable-vidmode \ --enable-geoclue2 --disable-geoclue \ --enable-ubuntu --enable-apparmor
Bug#892275: any comments?
Ping -- the package was scheduled to be autoremoved today. > > > > IMVHO, you should remove the redshift systemd file and let redshift > > > > start via de xdg autostart mechanism. The geoclue agent should then be > > > > started before redshift as I think it start the process using the > > > > alphabetical order. > > Maybe someone can come up with a patch that works on both, systemd and > > non-systemd systems? If thats even relevant in the first place... > As there's no non-systemd specific code in redshift at all, yet it works > fine for me, why would that systemd support be needed either? Looking deeper, it works on my boxen because XFCE autosaves the session, effectively making redshift autostart if it has ever been started by the user and not killed afterwards. I have no real knowledge how other window managers work this millenium. So... may someone educate me if there are cases when this .service file works (rather than always failing and sometimes having nasty effects)? If no, we can simply drop it for Bullseye, and have the package work for everyone the way it works for me -- which seems fine. Otherwise, the good way to go would be investigating how xdg autostart operates in different window managers. Nicoo: as the maintainer, if you have no time to fix this yourself, could you at least tell us what to do? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ Certified airhead; got the CT scan to prove that! ⠈⠳⣄
Bug#892275: redshift: Unable to connect to GeoClue
> * Paul Gevers [210526 21:49]: > > On Thu, 4 Feb 2021 14:29:55 +0100 Laurent Bigonville > > wrote: > > > IMVHO, you should remove the redshift systemd file and let redshift > > > start via de xdg autostart mechanism. The geoclue agent should then be > > > started before redshift as I think it start the process using the > > > alphabetical order. > Maybe someone can come up with a patch that works on both, systemd and > non-systemd systems? If thats even relevant in the first place... As there's no non-systemd specific code in redshift at all, yet it works fine for me, why would that systemd support be needed either? Meow. -- ⢀⣴⠾⠻⢶⣦⠀ The oldest dated printed book includes the following license grant: ⣾⠁⢠⠒⠀⣿⡁ Reverently made for universal free distribution by Wang Jie ⢿⡄⠘⠷⠚⠋⠀ on behalf of his two parents on the 15th of the 4th moon of ⠈⠳⣄ the 9th year of Xiantong [11 May 868].
Bug#981398: sa-exim: not installable with bullseye's exim4
Package: sa-exim Version: 4.2.1-19 Severity: grave Justification: renders package uninstallable Hi! Current version of sa-exim depends on exim4-localscanapi-3.1, and indeed it was compiled against that version. This makes it non-coinstallable with fully-featured (-heavy) build with exim; it is currently coinstallable with -light but only because #963251 has been fixed only partially, making -light declare the wrong version of API. Internally, it's 4.1, with obvious results. I've tested: a simple recompile of sa-exim fixes the issue. Meow! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (400, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-1-cloud-amd64 (SMP w/8 CPU threads) 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) Versions of packages sa-exim depends on: ii debconf [debconf-2.0]1.5.74 ii exim4-daemon-heavy [exim4-localscanapi-4.1] 4.94-12 ^^ after rebuilding ii libc62.31-9 ii libnetaddr-ip-perl 4.079+dfsg-1+b5 ii spamc3.4.5~pre1-3 Versions of packages sa-exim recommends: ii perl 5.32.0-6 Versions of packages sa-exim suggests: ii spamassassin 3.4.5~pre1-3
Bug#919348: many new releases since -- still "too buggy"?
Hi! Since your last report of a crash, there's been six new releases: five in the 0.1.* version series, and now one 4.16.0-1. As the new version claims a stable release, is there still a reason to keep xfce4-screensaver out of Bullseye? I've been using it happily all the time, with no borkage to report. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄ `
Bug#976918: memkind: FTBFS on ppc64el: GetArenaTest.test_TC_MEMKIND_ThreadHash failed
Control: tags -1 + moreinfo unreproducible Hi Lucas! > On Wed, Dec 09, 2020 at 09:39:08AM +0100, Lucas Nussbaum wrote: > > Source: memkind > > During a rebuild of all packages in sid, your package failed to build > > on ppc64el. At the same time, it did not fail on amd64. > > > I'm marking this bug as severity:serious since your package currently has > > ppc64el binary packages in unstable (so this is a regression). > > > [ RUN ] GetArenaTest.test_TC_MEMKIND_ThreadHash > > > test/get_arena_test.cpp:67: Failure > > > Expected: (max_collisions) <= (collisions_limit), actual: 10 vs 5 > > > [ FAILED ] GetArenaTest.test_TC_MEMKIND_ThreadHash (184 ms) Ping: > Is that fail reproducible for you? I have a possible fix, but have no way > of verifying it -- the package builds successfully on all machines I have > access to, and did build fine on buildds (no major changes to toolchain > since then). The underlying code uses an assumption on the internal working for glibc, that might possibly be invalid in some cases. Even if it happens to be wrong, correctness is not violated, there's just a performance loss. The test that fails could thus be removed -- however, I'd like to know how it did fail in the first place. No matter how I tried, I did not manage to reproduce the failure. There are also multiple ways to improve this hash (an explicit mapping, a "random" hash, etc) but as this code is used in large performance-critical parts, I'd prefer to first understand. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄ `
Bug#976918: memkind: FTBFS on ppc64el: GetArenaTest.test_TC_MEMKIND_ThreadHash failed
On Wed, Dec 09, 2020 at 01:27:11PM +0100, Adam Borowski wrote: > On Wed, Dec 09, 2020 at 09:39:08AM +0100, Lucas Nussbaum wrote: > > Source: memkind > > Version: 1.10.1-1 > > > During a rebuild of all packages in sid, your package failed to build > > on ppc64el. At the same time, it did not fail on amd64. > > > [ RUN ] GetArenaTest.test_TC_MEMKIND_ThreadHash > > > test/get_arena_test.cpp:67: Failure > > > Expected: (max_collisions) <= (collisions_limit), actual: 10 vs 5 > > > [ FAILED ] GetArenaTest.test_TC_MEMKIND_ThreadHash (184 ms) > > I can't seem to reproduce, both on plummer (ppc64el, 16 threads) and at home > (amd64, 64 threads); ran 10 and 20 attempts respectively. Hi Lucas! Is that fail reproducible for you? I have a possible fix, but have no way of verifying it -- the package builds successfully on all machines I have access to, and did build fine on buildds (no major changes to toolchain since then). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄ `
Bug#976918: memkind: FTBFS on ppc64el: GetArenaTest.test_TC_MEMKIND_ThreadHash failed
On Wed, Dec 09, 2020 at 09:39:08AM +0100, Lucas Nussbaum wrote: > Source: memkind > Version: 1.10.1-1 > During a rebuild of all packages in sid, your package failed to build > on ppc64el. At the same time, it did not fail on amd64. > > I'm marking this bug as severity:serious since your package currently has > ppc64el binary packages in unstable (so this is a regression). > > [ RUN ] GetArenaTest.test_TC_MEMKIND_ThreadHash > > test/get_arena_test.cpp:67: Failure > > Expected: (max_collisions) <= (collisions_limit), actual: 10 vs 5 > > [ FAILED ] GetArenaTest.test_TC_MEMKIND_ThreadHash (184 ms) I can't seem to reproduce, both on plummer (ppc64el, 16 threads) and at home (amd64, 64 threads); ran 10 and 20 attempts respectively. -- ⢀⣴⠾⠻⢶⣦⠀ .--[ Makefile ] ⣾⠁⢠⠒⠀⣿⡁ # beware of races ⢿⡄⠘⠷⠚⠋⠀ all: pillage burn ⠈⠳⣄ `
Bug#973846: manpages: file conflict with manpages-dev=5.08-1
Package: manpages Version: 5.09-1 Severity: grave Justification: renders package unupgradeable Hi! I'm afraid that the package fails to upgrade: Unpacking manpages (5.09-1) over (5.08-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-Vi3YLk/00-manpages_5.09-1_all.deb (--unpack): trying to overwrite '/usr/share/man/man3/queue.3.gz', which is also in package manpages-dev 5.08-1 Obviously, you need Replaces: manpages-dev (<< 5.09) Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-rc2-00014-g46c809d3dfda (SMP w/64 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages manpages-dev depends on: ii manpages 5.08-1 manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii man-db [man-browser] 2.9.3-2 -- no debconf information
Bug#967964: unison-2.48: file conflict with unison -4
Package: unison-2.48 Version: 2.48.4-5+b1 Severity: serious Justification: fails to upgrade Hi! I'm afraid there's no Replaces: stanza, resulting in: Unpacking unison-2.48 (2.48.4-5+b1) ... dpkg: error processing archive /tmp/apt-dpkg-install-Q6eH0z/4-unison-2.48_2.48.4-5+b1_amd64 .deb (--unpack): trying to overwrite '/usr/bin/unison-2.48', which is also in package unison 2.48.4-4 dpkg-deb: error: paste subprocess was killed by signal (Broken pipe) Obviously: Replaces: unison (<< 2.48.4-5~) -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-umbar-00027-gfee487f15878 (SMP w/6 CPU threads) 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) Versions of packages unison-2.48 depends on: ii libc6 2.31-3 Versions of packages unison-2.48 recommends: ii openssh-client [ssh-client] 1:8.3p1-1 Versions of packages unison-2.48 suggests: pn unison-all -- no debconf information
Bug#967012: vmem: FTBFS: FAIL: match: out0.log.match:2 did not match pattern
Control: block -1 by 964457 On Mon, Aug 03, 2020 at 01:19:42PM +0200, Lucas Nussbaum wrote: > Source: vmem > Version: 1.8-1 > Severity: serious > During a rebuild of all packages in sid, your package failed to build > on amd64. > > vmem_aligned_alloc@@LIBVMEM_1.0 > > vmem_calloc@@LIBVMEM_1.0 Another case of a test failing due to bogus decoration. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i. ⠈⠳⣄
Bug#967937: gimp-python: not installable: depends on "python"
Package: gimp-python Version: 2.10.8-2+b1 Severity: grave Justification: renders package unusable Hi! As the package "python" is no more, gimp-python can no longer be installed. It needs to either depend on "python2" (in the short term) or, preferably, be updated for py3. Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-umbar-00027-gfee487f15878 (SMP w/6 CPU threads) 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) Versions of packages gimp-python depends on: ii libbabl-0.1-0 0.1.78-1 ii libc6 2.31-3 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libgegl-0.4-0 0.4.24-1 ii libgimp2.0 2.10.18-1 ii libglib2.0-02.64.4-1 ii libgtk2.0-0 2.24.32-4 ** python (hacked away in dpkg/status) ii python-gtk2 2.24.0-6 ii python2.7 2.7.18-1 gimp-python recommends no packages. gimp-python suggests no packages. -- no debconf information
Bug#964623: pmdk: FTBFS: test failed
Control: severity -1 normal On Thu, Jul 09, 2020 at 01:27:34PM +0200, Lucas Nussbaum wrote: > Source: pmdk > Version: 1.8-1 > Severity: serious > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > pmem_check_version@@LIBPMEM_1.0 > > pmem_deep_drain@@LIBPMEM_1.0 > > pmem_deep_flush@@LIBPMEM_1.0 The binutils bug (decoration appended twice) is still there, but I've disabled this test in 1.9-1. The package then failed to build for an unrelated reason, 1.9-2 is now ok. Downgrading thus. Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i. ⠈⠳⣄
Bug#964623: pmdk: FTBFS: test failed
Control: block -1 by 964457 On Thu, Jul 09, 2020 at 01:27:34PM +0200, Lucas Nussbaum wrote: > Source: pmdk > Version: 1.8-1 > Severity: serious > Relevant part (hopefully): > > pmem_check_version@@LIBPMEM_1.0 This is caused by #964457 which appends decoration to symbols once if there should be none, or twice when there should be one. Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i. ⠈⠳⣄
Bug#965151: afdko-bin: /usr/bin/tx is already shipped by transifex-client
On Sat, Jul 18, 2020 at 03:36:48PM -0400, Boyuan Yang wrote: > X-Debbugs-CC: debian-fo...@lists.debian.org m...@debian.org > > On Thu, 16 Jul 2020 23:19:31 +0200 Andreas Beckmann > wrote: > > Package: afdko-bin > > Version: 3.4.0+dfsg1-2 > > Severity: serious > > > > Preparing to unpack .../afdko-bin_3.4.0+dfsg1-2_amd64.deb ... > > Unpacking afdko-bin (3.4.0+dfsg1-2) ... > > dpkg: error processing archive /var/cache/apt/archives/afdko- > bin_3.4.0+dfsg1-2_amd64.deb (--unpack): > >trying to overwrite '/usr/bin/tx', which is also in package > transifex-client 0.13.9-1 > > Errors were encountered while processing: > >/var/cache/apt/archives/afdko-bin_3.4.0+dfsg1-2_amd64.deb > > > > If the conflicting situation cannot be resolved then, as > > last resort, the two packages have to declare a mutual > > Conflict. > > AFAICT a mutual conflict could be the only reasonable solution. @mwei > what do you think? The policy is very clear: #10.1. # Two different packages must not install programs with different # functionality but with the same filenames. (The case of two programs # having the same functionality but different implementations is handled # via “alternatives” or the “Conflicts” mechanism. See Maintainer # Scripts and Conflicting binary packages - Conflicts respectively.) If # this case happens, one of the programs must be renamed. The # maintainers should report this to the "debian-devel" mailing list and # try to find a consensus about which program will have to be renamed. # If a consensus cannot be reached, *both* programs must be renamed. Thus, a mutual conflict is not allowed. Two random packages without a relation are not expected to conflict: there's no reason someone who hacks on some software that uses Transifex to manage their translation wouldn't also want to deal with fonts -- we're in the "breaks unrelated software" land. This issue pops up on debian-devel quite often, and the consensus is that exceptions shouldn't be given. Major cases: "node": axnode vs node.js, "git" vs gnuit. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋⠀ It's time to migrate your Imaginary Protocol from version 4i to 6i. ⠈⠳⣄
Bug#964026: libelogind0: `Provides: libsystemd0` causes unrelated packages to fail to build (unmet dependencies)
On Wed, Jul 08, 2020 at 03:44:21PM +0200, Ansgar wrote: > On Wed, 2020-07-08 at 11:04 +0200, Johannes Schauer wrote: > > What is happening here is, that aspcud chooses libelogind0 for installation > > and > > then apt decides that it refuses to install it because it doesn't want to > > remove libsystemd0 in favor of libelogind0 and by that replace an important > > package (apt would require the "yes, do as I say!" thing for that to work). > > libsystemd0 doesn't seem special though? It's `Priority: optional` and > doesn't have much else; I guess trying to uninstall libsystemd0 breaks > something else? > > I'm not really motivated to debug problems caused by elogind though. This problem can't possibly be caused by elogind. A package may cause a problem only if: 1. some of its code is actually run (preinst, postinst, payload), or 2. it's the first alternative and the solver uses "first alternative only" or is otherwise unable to use the full solutions space The docs say: 'aspcud' resolver which (in contrast to apt and aptitude) is a real solver (in the math sense) and will thus always find a solution if a solution exists. Given a set of packages A containing package X, if A - X contains a solution, A with X also does -- ie, no relations declared by X (Breaks, Conflicts, Depends, Provides, ...) may possibly invalidate that solution. And we have: * unstable: apt resolver, doesn't even consider libelogind0 * experimental: aspcud, supposed to be a full solver Thus, it looks to me like a problem in apt-cudf, almost surely not in the solver itself but in its integration with apt. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Bug#959828: requires support on systemd side
The real culprit here, is that pkg:systemd provides many many distinct interfaces, without letting any consumers say _which_ interfaces they want. Thus, all of this would be solved if systemd declared Provides:systemctl and relevant consumers depended on that. Same with systemd-revolvd, tmpfiles, etc. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Bug#954555: safeclib: FTBFS: dh_auto_test: error: make -j4 check VERBOSE=1 returned exit code 2
On Sun, Mar 22, 2020 at 09:24:01AM +0100, Lucas Nussbaum wrote: > Source: safeclib > Version: 3.5-2 > Severity: serious > Justification: FTBFS on amd64 > > FAIL: t_towfc_s > > === > > > > test_towfc_s 211 Error: towfc(U+A7C7) => A7C7 "A7C8" status=C LATIN > > CAPITAL LETTER D WITH SHORT STROKE OVERLAY > > test_towfc_s 211 Error: towfc(U+A7C9) => A7C9 "A7CA" status=C LATIN > > CAPITAL LETTER S WITH SHORT STROKE OVERLAY > > test_towfc_s 211 Error: towfc(U+A7F5) => A7F5 "A7F6" status=C LATIN > > CAPITAL LETTER REVERSED HALF H > > FAIL t_towfc_s (exit status: 6) This is a disagreement between the version of UnicodeData.txt libc has been built with, and what's shipped in the unicode-data package. The latter has been already updated for Unicode 13. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Bug#953485: binaries uploaded
On Sat, Mar 21, 2020 at 05:47:25PM +0100, Ivo De Decker wrote: > On Sat, Mar 21, 2020 at 02:43:19PM +0100, Adam Borowski wrote: > > I've uploaded binaries for amd64 arm64 armhf i386 (ie, arch in testing), so > > it should be done. > > > > Apparently the package can't be autobuilt, so it's up to me and tarzeau to > > remember to upload the binaries the next time as well. Oh well. > > You should remove the "XS-Autobuild: yes" from the control file. Not only is > it incorrect (as the package apparently cannot be autobuilt on debian > infrastructure), but doing so will also trigger the > 'source-only-upload-to-non-free-without-autobuild' lintian tag, which will > cause a source-only upload to be autorejected by dak if you forget to include > the binaries. Thanks, that autoreject sounds useful. Forwarding to the actual maintainer... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Bug#953875: new maintainer
Just so there's a public record: I've sponsored the version of runit that was rotting on mentors as-is; it included a bunch of fixes and transfer of maintainership to Lorenzo. This means, we now have a proper maintainer. Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Bug#953875: why "critical"?
Control: severity -1 normal
I don't get why this would be severity:critical.
With Recommends enabled, there are hundreds of packages that cause a
large-scale changeover of the system -- be it DE switch, installing a gig or
more of random daemons, an init system switch, or the like.
So unless the policy {lower-case} for Recommends gets changed (or rather,
its implementation all around Debian goes in line with the Policy wording),
there's no point in singling out this package.
> This is obviously not something a random user wants to do and have a
> large probability of destroying the system beyond repair.
Please file bugs for that "destroying the system beyond repair" if you can
name a case (preferably, not caused by broken Recommend chains elsewhere).
==
But, let's discuss how to fix the issue at hand.
One idea:
Recommends:
runit-sysv | systemd-sysv | runit-init,
runit-systemd | sysvinit-core | runit-init,
runit-init | sysvinit-core | systemd-sysv
This is very unwieldy but wouldn't trigger an init switch in any case.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good.
⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi
⠈⠳⣄
Bug#951522: FTBFS: wants long-removed emacs25
Source: a2ps Version: 1:4.14-4 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi! I'm afraid this package build-depends on emacs25, which is long since gone. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-rc1-00073-g6af17278568f (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init)
Bug#950431: qemu-system-ppc: file conflict between qemu-system-{data,ppc}
Package: qemu-system-ppc Version: 1:4.2-2 Severity: grave Justification: renders package uninstallable Hi! Upon upgrading or a fresh install: Unpacking qemu-system-ppc (1:4.2-2) ... dpkg: error processing archive «TMP»/3-qemu-system-ppc_1%3a4.2-2_amd64.deb (--unpack): trying to overwrite '/usr/share/qemu/skiboot.lid', which is also in package qemu-system-data 1:4.2-2 Fix is obvious... Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-00053-g164b7343ac03 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages qemu-system-ppc depends on: ii libaio1 0.3.112-5 ii libasound2 1.2.1.2-2 ii libbrlapi0.7 6.0+dfsg-4+b1 ii libc62.29-9 ii libcacard0 1:2.6.1-1 ii libcapstone3 4.0.1+really+3.0.5-1+b1 ii libepoxy01.5.4-1 ii libfdt1 1.5.1-1 ii libgbm1 19.3.3-1 ii libgcc-s1 [libgcc1] 10-20191205-1 ii libgcc1 1:9.2.1-25 ii libglib2.0-0 2.62.4-1+b1 ii libgnutls30 3.6.11.1-2 ii libibverbs1 27.0-2 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libncursesw6 6.1+20191019-1 ii libnettle7 3.5.1+really3.5.1-2 ii libnuma1 2.0.12-1+b1 ii libpixman-1-00.36.0-1 ii libpmem1 1.8-1 ii libpng16-16 1.6.37-1 ii librdmacm1 27.0-2 ii libsasl2-2 2.1.27+dfsg-2 ii libseccomp2 2.4.2-2 ii libslirp04.1.0-2 ii libspice-server1 0.14.2-4 ii libtinfo66.1+20191019-1 ii libusb-1.0-0 2:1.0.23-2 ii libusbredirparser1 0.8.0-1+b1 ii libvdeplug2 2.3.2+r586-2.2+b1 ii libvirglrenderer10.8.1-6 ii openbios-ppc 1.1.git20181001-1 ii openhackware 0.4.1+git-20140423.c559da7c-4.1 ii qemu-slof20191209+dfsg-1 ii qemu-system-common 1:4.2-2 ii qemu-system-data 1:4.2-2 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages qemu-system-ppc recommends: ii ipxe-qemu1.0.0+git-20190125.36a4c85-4 ii qemu-system-gui 1:4.2-2 ii qemu-utils 1:4.2-2 ii seabios 1.13.0-1 Versions of packages qemu-system-ppc suggests: pn qemu-block-extra pn samba pn vde2 -- no debconf information
Bug#949850: libipmctl4: broken conffile migration, making logrotate inoperative
Package: libipmctl4 Version: 02.00.00.3673+ds-2 Severity: serious The conffile migration is broken, resulting in: /etc/cron.daily/logrotate: error: ipmctl.conf:1 duplicate log entry for /var/log/ipmctl/*log error: found error in file ipmctl.conf, skipping run-parts: /etc/cron.daily/logrotate exited with return code 1 libipmctl3 had /etc/logrotate.d/ipmctl.conf libipmctl4 has /etc/logrotate.d/ipmctl and migration doesn't work, resulting in a stray copy of the owner. The conffile must go, no matter if it has been modified or not. The package had never been a part of a Debian stable release yet, but it's been released with Ubuntu Eoan, thus papering over the problem won't work. Setting severity to RC to block testing migration. Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'stable'), (150, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.13-00051-g5426abd18b11 (SMP w/6 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libipmctl4 depends on: ii libc6 2.29-9 ii libndctl6 67-1 libipmctl4 recommends no packages. libipmctl4 suggests no packages. -- no debconf information
Bug#897281: RM time
Control: clone -1 -2 Control: retitle -2 RM: doc-debian-fr -- RoQA; ancient docs Control: severity -2 normal Control: reassign -2 ftp.debian.org On 2018-05-01, Moritz Muehlenhoff wrote: > These docs have been updated the last time over 12 years ago, is this > actually still useful or rather misleading and should be removed? 19½ months later, it is clear no one cares about this package. Reassigning to our fine FTPfolks to do the last rites. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#930869: Please keep pm-utils
On Thu, Nov 14, 2019 at 09:13:51AM +0100, Andras Korn wrote: > I just stumbled on this bugreport. > > I'm a happy pm-utils user and would like the package to stick around. I use > it on dozens of computers ranging from servers to desktops to laptops. > > From reading the bugreport, there doesn't appear to be any identifiable, > specific, actionable reason for removing it, does there? There's none as far as I can tell, indeed. After a thought, even cleaning away the quirks would be counterproductive. They apply to old i386 machines that need real mode BIOS calls; while I and most of us have no such hardware to test, it's still used by some users. But keeping such i386 support is not _my_ itch to scratch, I personally wouldn't cry if those parts were trimmed away. Thus: * on old buggy hardware pm-utils works while new stuff doesn't * on old non-buggy, and on modern hardware, pm-utils works and is more convenient to use (eg. on headless boxes) Ie, this bug report is outright bogus. Without even a single identifiable actionable problem, there's nothing to fix. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#944505: FTBFS: E: Build killed with signal TERM after 150 minutes of inactivity
Source: fonts-beteckna Version: 0.5-2 Severity: serious Tags: ftbfs Justification: fails to build from source Hi! I'm afraid that fonts-beteckna fails to build: ** (process:53089): WARNING **: 22:56:10.699: GlyfData.vala:407: Point on point in TTF. Index 50 Path: 1 in 9 E: Build killed with signal TERM after 150 minutes of inactivity Same happens both on a fat amd64 and a low-end arm64. Full log attached. Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-rc6-00053-g729694c1a413 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) sbuild (Debian sbuild) 0.78.1 (09 February 2019) on valinor.angband.pl +==+ | fonts-beteckna (amd64) Sun, 10 Nov 2019 22:55:49 + | +==+ Package: fonts-beteckna Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary I: NOTICE: Log filtering will replace 'var/run/schroot/mount/unstable-amd64-sbuild-e7a44aad-019d-4522-ab69-da5957dbc7b3' with '<>' I: NOTICE: Log filtering will replace 'build/fonts-beteckna-5CJmIK/resolver-UgUo7l' with '<>' +--+ | Update chroot| +--+ Hit:1 http://apt-rosy.angband.pl:3142/debian unstable InRelease Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. +--+ | Fetch source files | +--+ Check APT - Checking available source versions... Download source files with APT -- Reading package lists... Need to get 2125 kB of source archives. Get:1 http://apt-rosy.angband.pl:3142/debian unstable/main fonts-beteckna 0.5-2 (dsc) [1884 B] Get:2 http://apt-rosy.angband.pl:3142/debian unstable/main fonts-beteckna 0.5-2 (tar) [2119 kB] Get:3 http://apt-rosy.angband.pl:3142/debian unstable/main fonts-beteckna 0.5-2 (diff) [3432 B] Fetched 2125 kB in 0s (109 MB/s) Download complete and in download only mode I: NOTICE: Log filtering will replace 'build/fonts-beteckna-5CJmIK/fonts-beteckna-0.5' with '<>' I: NOTICE: Log filtering will replace 'build/fonts-beteckna-5CJmIK' with '<>' +--+ | Install package build dependencies | +--+ Setup apt archive - Merged Build-Depends: debhelper (>= 11), birdfont, build-essential, fakeroot Filtered Build-Depends: debhelper (>= 11), birdfont, build-essential, fakeroot dpkg-deb: building package 'sbuild-build-depends-main-dummy' in '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. Ign:1 copy:/<>/apt_archive ./ InRelease Get:2 copy:/<>/apt_archive ./ Release [957 B] Ign:3 copy:/<>/apt_archive ./ Release.gpg Get:4 copy:/<>/apt_archive ./ Sources [373 B] Get:5 copy:/<>/apt_archive ./ Packages [456 B] Fetched 1786 B in 0s (161 kB/s) Reading package lists... Reading package lists... Install main build dependencies (apt-based resolver) Installing build dependencies Reading package lists... Building dependency tree... Reading state information... The following additional packages will be installed: adwaita-icon-theme birdfont bubblewrap dbus dbus-user-session dconf-gsettings-backend dconf-service dictionaries-common dmsetup emacsen-common fontconfig fontconfig-config fonts-dejavu-core fonts-roboto-unhinted glib-networking glib-networking-common glib-networking-services gsettings-desktop-schemas gtk-update-icon-cache hicolor-icon-theme hunspell-en-us iso-codes libapparmor1 libargon2-1 libaspell15 libatk-bridge2.0-0 libatk1.0-0 libatk1.0-data libatspi2.0-0 libavahi-client3 libavahi-common-data libavahi-common3 libbrotli1 libcairo-gobject2 libcairo2 libcap2 libcap2-bin libcolord2 libcryptsetup12 libcups2 libdatrie1 libdbus-1-3 libdconf1 libdevmapper1.02.1 libdrm-amdgpu1 libdrm-common libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libedit2 libegl-mesa0 libegl1
Bug#944499: FTBFS: IndexError: list index out of range
Source: fonts-alegreya-sans
Version: 2.008-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
Hi!
I'm afraid your package fails to build from source:
.
INFO:fontmake.font_project:Generating instance UFO for "Alegreya Sans Light"
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/fontmake/instantiator.py", line 314, in
generate_instance
glyph_instance = glyph_mutator.instance_at(location_normalized)
[...]
File "/usr/lib/python3/dist-packages/fontMath/mathGlyph.py", line 499, in
_processMathOneContours
points2 = contours2[index]["points"]
IndexError: list index out of range
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/bin/fontmake", line 11, in
load_entry_point('fontmake==2.0.4', 'console_scripts', 'fontmake')()
[...]
File "/usr/lib/python3/dist-packages/fontmake/instantiator.py", line 329, in
generate_instance
) from e
fontmake.instantiator.InstantiatorError: Failed to generate instance of glyph
'colonsign.BRACKET.75'.
`
On another run (full log attached) the glyph was 'longs.l' instead.
Meow!
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-rc6-00053-g729694c1a413 (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
sbuild (Debian sbuild) 0.78.1 (09 February 2019) on valinor.angband.pl
+==+
| fonts-alegreya-sans 2.008-1 (amd64) Sun, 10 Nov 2019 18:31:25 + |
+==+
Package: fonts-alegreya-sans
Version: 2.008-1
Source Version: 2.008-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary
I: NOTICE: Log filtering will replace
'var/run/schroot/mount/unstable-amd64-sbuild-6868024d-89bd-4b78-9d21-4c3a4471c7a0'
with '<>'
I: NOTICE: Log filtering will replace
'build/fonts-alegreya-sans-LiDCKh/resolver-b4Dc2K' with '<>'
+--+
| Fetch source files |
+--+
Local sources
-
/mnt/optane/f/fonts-alegreya-sans_2.008-1.dsc exists in /mnt/optane/f; copying
to chroot
I: NOTICE: Log filtering will replace
'build/fonts-alegreya-sans-LiDCKh/fonts-alegreya-sans-2.008' with
'<>'
I: NOTICE: Log filtering will replace 'build/fonts-alegreya-sans-LiDCKh' with
'<>'
+--+
| Install package build dependencies |
+--+
Setup apt archive
-
Merged Build-Depends: debhelper (>= 11), fontmake (>= 1.8.0), sfnt2woff-zopfli,
woff2, build-essential, fakeroot
Filtered Build-Depends: debhelper (>= 11), fontmake (>= 1.8.0),
sfnt2woff-zopfli, woff2, build-essential, fakeroot
dpkg-deb: building package 'sbuild-build-depends-main-dummy' in
'/<>/apt_archive/sbuild-build-depends-main-dummy.deb'.
Ign:1 copy:/<>/apt_archive ./ InRelease
Get:2 copy:/<>/apt_archive ./ Release [957 B]
Ign:3 copy:/<>/apt_archive ./ Release.gpg
Get:4 copy:/<>/apt_archive ./ Sources [394 B]
Get:5 copy:/<>/apt_archive ./ Packages [475 B]
Fetched 1826 B in 0s (21.3 kB/s)
Reading package lists...
Reading package lists...
Install main build dependencies (apt-based resolver)
Installing build dependencies
Reading package lists...
Building dependency tree...
Reading state information...
The following additional packages will be installed:
fontconfig fontconfig-config fontmake fonts-dejavu-core glyphsinfo libblas3
libbrotli1 libdbus-1-3 libdouble-conversion3 libdrm-amdgpu1 libdrm-common
libdrm-intel1 libdrm-nouveau2 libdrm-radeon1 libdrm2 libedit2 libegl-mesa0
libegl1 libevdev2 libexpat1 libfontconfig1 libfreetype6 libgbm1 libgfortran5
libgl1 libgl1-mesa-dri libglapi-mesa libglvnd0 libglx-mesa0 libglx0
libgraphite2-3 libgudev-1.0-0 libharfbuzz0b libice6 libinput-bin libinput10
libjpeg62-turbo liblapack3 liblbfgsb0 libllvm9 libmpdec2 libmtdev1
libpciaccess0 libpcre2-16-0 libpng16-16 libpython3-stdlib
libpython3.7-minimal libpython3.7-stdlib libqt5core5a libqt5dbus5 libqt5gui5
libqt5network5 libqt5widgets5 libreadline8 libsensors-config libsensors5
libsm6 libsqlite3-0 libssl1.1 libttfautohint1 libwacom-common libwacom2
libwayland-client0 libwayland-server0
Bug#944496: FTBFS: Assigning non-zero to $[ is no longer possible at tools/hex2bdf
Source: xfonts-efont-unicode Version: 0.4.2-11 Severity: serious Tags: ftbfs Justification: fails to build from source Hi! I'm afraid that the package fails to build, with a bunch of: Assigning non-zero to $[ is no longer possible at tools/hex2bdf line 17, <> line 7446. Additionally, there's some binary spew to the terminal. Full log attached. Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-rc6-00053-g729694c1a413 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) xfonts-efont-unicode_amd64.build Description: Binary data
Bug#938952: [debian Buster] [arm64 pinebook] [sysvinit-core] libsoup2.4-1 : Depends: glib-networking (>= 2.32.0) but it is not going to be installed
On Mon, Oct 07, 2019 at 10:44:12PM +0200, Thorsten Glaser wrote: > On Mon, 7 Oct 2019, Jean-Marc LACROIX wrote: > > It seems that now all is ok, because sysvinit is correctly installed on > > Debian > > 10.1 > > Yes, but the other packages are not yet ready for elogind > in Debian 10.anything and never will, because Debian 10.x > was released in April 2019, and this will not get updated. > > (Backporting elogind once everything works will help, but > not enough, because other packages hard-depend on (usually) > libpam-systemd and lack the | logind alternative.) And that's basically the only problem. elogind in buster uses a separate libelogind which makes it immune to the libsystemd alternative problem that haunts unstable. That makes grabbing libpam-elogind-compat or bolting it upon buster's libpam-elogind enough to satisfy dependencies. I don't remember if that's enough or not for policykit-1 to work adequately, though. > If you wish to use elogind, either be prepared to do > unspeakably evil things (such as editing the internal > dpkg status database, which I did to great success on > an RPi last week) or upgrade to unstable (in which the > only missing piece polkit-qt is). Editing dpkg status is bad. An equivs package (which libpam-elogind-compat essentially is) is a much cleaner option. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Sat, Sep 28, 2019 at 02:53:56AM +0200, Thorsten Glaser wrote: > On Fri, 27 Sep 2019, Mark Hindley wrote: > > > Thanks. The aim of preventing accidental removal of systemd is very > > reasonable. However, using this approach the hurdle you create even to a > > user > > who really wants to uninstall is pretty high. Few people will continue > > having > > seen the 'You are about to do something potentially harmful' warning. > > And isn’t that precisely the goal? To prevent most users from > “just hitting Enter” to switch away from the default? That's for when you're knowingly doing something very unusual, that in normal circumstances breaks your whole system. Using a different supported init system is not something that counts here. > I’d assume people wanting to install elogind to proceed > according to documentation telling them that this message > is expected (but to still review what APT wants to do!) > (or just have enough of a clue about Debian to do this > anyway) so this is what I’d suggested, independent even > of the rest of the discussion. You might be comfortable with overriding all safety barriers, but that's not something for regular users. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, Sep 27, 2019 at 03:39:43PM +0200, Julien Cristau wrote: > So one thing I think we should ensure is we don't end up uninstalling > systemd without an explicit user choice. > > The "init" package has the "Important: yes" control field which as I > understand it tells apt to behave like "Essential: yes", except for not > trying to install the package if it is not installed. > > That's not quite enough for our purposes, because apt would still be > allowed to replace systemd-sysv with sysvinit-core, but maybe > systemd-sysv could get that flag as well? That flag is not for "without an explicit user choice". It's for "you're breaking the packaging system, far more than ignoring dependencies". It's the biggest hammer dpkg has. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Thu, Sep 26, 2019 at 12:52:27PM +0200, Thorsten Glaser wrote: > On Thu, 26 Sep 2019, Mark Hindley wrote: > > It is possible to get APT to attempt a solution by specifically requesting > > 'apt > > install libelogind0 sysvinit-core'. This removes systemd-sysv and then > > fails > > Does it also request a “Yes, do as I say!” then? > > If not (or perhaps anyway) libsystemd0 should get Important: yes, as > I wrote earlier, which will force that. A very bad idea, I'd say. Switching between implementations of the same thing shouldn't require defeating the biggest "stop, you're doing something stupid" block dpkg has. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Mon, Sep 23, 2019 at 11:58:18AM -0400, Sam Hartman wrote: > Mark> #935910 is now fixed in apt 1.8.4 in unstable and with that > Mark> installed I can no longer reproduce #934491. The APT > Mark> maintainers have said that adding a Breaks for the fixed > Mark> version of apt is not useful. > > Normally in a situation like this we would wait until the next stable > release for depending on the change in apt. > It's a bit complicated because it is a bug, but Julian's idea that we > need to wait until bullseye+1 to depend on this apt fix is not an > unreasonable approach. So this avenue is right out. Fixing the GUI uninstallability regression and backporting it to Buster is urgent, waiting whole two years is not an option. We did have elogind coinstallable with libsystemd0 (before version 241.1-1+debian1) and at least for all _my_ use cases it worked well. As I'm aware, the main problem is policykit, right? There were initial ideas, not liked by its maintainer, but we can analyze further. Having some idea about other possible failures would be nice. > Mark> I have tried the approach suggested by Laurent of using > Mark> elogind with libsystemd0 and I could not get the sd-*(3) APIs > Mark> to function correctly. > What trouble did you run into? If whatever trouble (not yet named) can't be fixed on the other side of daemon, we can perhaps patch libsystemd0 itself? > As an example, if you have systemd installed, it might be running. The > combination of systemd running and libelogind0 being the systemd library > is unfortunate. Trying to boot systemd in that configuration (using > libelogind0) would presumably be quite fatal. Right, both must be coinstallable; with systemd-logind gracefully refusing to start when booted with some other init, and elogind likewise not starting when systemd-the-init is pid 1. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#940034: libelogind0: replacing a core system library and conflicting against the default init considered harmful
On Fri, Sep 20, 2019 at 09:06:57AM +0200, Laurent Bigonville wrote: > When I looked I elogind a while back I was able to build a package without > having a public libelogind0, I basically had that in my debian/rules file: > > # We only build the libelogind0 and libelogind-dev if we are building for > # Devuan or its derivatives > ifneq ($(shell dpkg-vendor --derives-from Devuan && yes), yes) > export DH_OPTIONS=--no-package=libelogind0 --no-package=libelogind-dev > endif That was the case initially, yes. It might be worth going back to. > libelogind library is only needed for applications that want to interact > with the daemon, in the ITP (#905388) bug I also noted that. > > If I'm not mistaken, libsystemd (and libelogind) are using D-Bus to > communicate with the daemon part, was it checked that the API used is > compatible? Is there documentation of the differences, if any? The API and dbus protocol are compatible (or at least are supposed to be). However, per the request of policykit's maintainer, libelogind was instead made ABI-compatible with libsystemd, and was made to replace it. > Bottom line, is libelogind even needed in the archive to achieve your goal > of having an implementation of the login1 D-Bus API not requiring systemd as > PID1? This approach was used until February, and did work well. I'm a mere user/sponsor thus I don't fully understand the reasons for switching. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, ⣾⠁⢠⠒⠀⣿⡁ 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. ⢿⡄⠘⠷⠚⠋⠀ Filter out and throw away the fruits (can dump them into a cake, ⠈⠳⣄ etc), let the drink age at least 3-6 months.
Bug#940034: elogind and the release team block
On Wed, Sep 11, 2019 at 09:15:58AM -0400, Sam Hartman wrote: > I reached out to jcristau to talk about his block hint. > Based on our IRC discussion, it sounds like he was having trouble > bringing himself to remove the hint presumably because he doesn't think > the broader issue was being dealt with. > The systemd maintainers are telling you that you need to provide > libpam-systemd. We _did_ use libpam-systemd in the past. This code was working and tested, by January 2018 (using consolekit not elogind by then), then a different version (with elogind), well-tested in Devuan then finally submitted in November 2018. The difference is the point the alternative happens at: PROGRAM -> policykit -> libpam-XXX -> logind A) PROGRAM -> policykit-systemd -> libpam-systemd -> systemd | `> policykit-elogind -> libpam-elogind -> elogind B) PROGRAM -> policykit-systemd -> libpam-systemd -> systemd | `> libpam-elogind -> elogind C) PROGRAM -> policykit-systemd -> libpam-systemd -> systemd | `> elogind The Jan 2018 version used A; the Nov 2018 version used C. Another debated option was B with dlopen. Finally (shortly before Buster freeze), it was requested to make libelogind fully ABI-compatible with libsystemd -- which elogind's upstream helped implement, but that version was not allowed into Buster. And now, we have that replacement problem. Thus... which way do you want? > Actually, they would prefer that you create an elogind that mirrors > enough of the interfaces that you can just use libpam-systemd. You said > that would not work, explaining that elogind for example doesn't have a > concept of slices. You never clearly articulated why it couldn't > emulate slices enough to pacify libpam-systemd. I don't know if it is > just that work hasn't been done or if it would be a bad idea for some > reason. Making elogind implement every single feature of systemd would effectively make it systemd. That's not the point. If I had infinite tuits, I'd implement a clean unix-logind that stubs the API to good old POSIX functionality -- if you type "who" on a 1990s' system, you'll already get the same thing the logind idea reimplements. Unlike elogind which is a trimmed copy of systemd, that'd make slices completely out of question. Same applies to any logind for non-Linux or non-GNU. I'd say we want the stubs to be as lean as possible (for simplicity, less moving parts, smaller attack surface, etc), rather than to implement every single add-on. If I wanted systemd, I know where to find it (although it doesn't even boot on my main desktop). Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Your snowflakes have nothing on my socks drawer. ⢿⡄⠘⠷⠚⠋⠀ ⠈⠳⣄
Bug#935324: FTBFS: gluster API has changed
Source: qemu
Version: 1:3.1+dfsg-8
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi!
I'm afraid that a recent incompatible change to gluster's API makes qemu
fail to build:
/<>/block/gluster.c: In function ‘qemu_gluster_do_truncate’:
/<>/block/gluster.c:1035:13: error: too few arguments to function
‘glfs_ftruncate’
1035 | if (glfs_ftruncate(fd, offset)) {
| ^~
In file included from /<>/block/gluster.c:12:
/usr/include/glusterfs/api/glfs.h:768:1: note: declared here
768 | glfs_ftruncate(glfs_fd_t *fd, off_t length, struct glfs_stat *prestat,
| ^~
See commit e014dbe74e0484188164c61ff6843f8a04a8cb9d upstream.
Meow!
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-rc5-00033-gfe0884fa397a (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
Bug#932865: python-qrtools: not installable: depends on python2 version of zbar
On Fri, Jul 26, 2019 at 11:37:32AM -0400, Boyuan Yang wrote: > I feel quite sorry for losing such a good software, but it's quite obvious > that qr-tools has a dead upstream and that no one has showed the intent to > migrate it from python2 to python3. > > If no one steps up to be the new upstream, I guess we will have to have it > removed eventually. Let's do it a while later (like by the end of this year). > On Wed, 24 Jul 2019 03:05:20 +0200 Adam Borowski wrote: > > Package: python-qrtools > > Severity: grave > > This package depends on python-zbar, which has already been removed as part > > of the python2-rm transition. This obviously makes it non-installable. Yeah, I've reported this bug to: 1. warn users that something is amiss 2. have autoremoval let zbar migrate to testing There's substantial popcon (720) thus giving the package a chance may be a good idea. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian is one big family. Including that weird uncle ⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws. ⠈⠳⣄
Bug#932865: python-qrtools: not installable: depends on python2 version of zbar
Package: python-qrtools Version: 1.4~bzr32-1 Severity: grave Justification: renders package unusable Hi! This package depends on python-zbar, which has already been removed as part of the python2-rm transition. This obviously makes it non-installable. Meow! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.1-00036-gf2c1d208af28 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages python-qrtools depends on: ii python 2.7.16-1 pn python-pil pn python-zbar pn qrencode python-qrtools recommends no packages. python-qrtools suggests no packages.
Bug#919348: is it still unfit for Bullseye?
On Sat, Jul 13, 2019 at 04:40:31PM +0200, Yves-Alexis Perez wrote: > On Thu, 2019-07-11 at 10:34 +0200, Adam Borowski wrote: > > So... is there any reason to not let xfce4-screensaver go to Bullseye? > > Any day that a human being suffers from light-locker is a bad day. > > Hi Adam, > > could you please refrain from such statements? Some people, volunteers mostly, > have taken time to actual write that software, package it etc. I find this > rude, to be honest. Well, there is no problem in software X having bugs -- any non-trivial program is buggy, and especially a novel approach like that tried by light-locker is bound to run into problems. But, pushing a thoroughly buggy piece of code, that's in my opinion not fit for release, as the default for a major desktop environment, and the only allowed by that DE's task, is not a good idea. Apologies for expressing myself too emphatically -- but with my (indeed rude) wording aside, the point stands. > > If you're afraid about yet-unknown bugs, more exposure to users early > > in the release cycle would be a good idea. > > For a locker screen, I'd really like someone to take a look at the code (even > if only the differences with gnome-screensaver). I'm afraid I have no experience at all with X coding, all I can offer is testing as a mere user. But I do run a diverse set of machines, ranging four archs (amd64 i386 x32 arm64), ages (2004-2018), types (desktops, SoC, laptops), GPUs, rc systems (sysv-rc, openrc -- with one notable omission :p), etc -- thus I believe my good opinion about xfce4-screensaver carries some weight. > The light-locker code in the process which does the locking is actually > quite simple (no complicated UI, no screensaver at all etc.) Yet the way it offloads the task to lightdm is fragile. > > On the other hand, light-locker suffers from a multitude of known > > problems (see the recent debian-devel thread), and you hate the third > > alternative, xscreensaver > > Actually no-one seems to know which package(s) is buggy. My gut feeling is > that the drivers handle vt-switches and backlight off badly, not a bug in > light-locker. But again no-one seems interested to find out. This particular problem may be indeed hard to track, but none of the alternatives (xscreensaver, xfce4-screensaver) suffer from it. Nor from the others (no visual feedback that you're logged in, pointless vt switches, not working when started not from a DM, ... [I haven't retried in a while, some of those might have been fixed]). Unless you have a particular reason to stick with light-locker, fixing it may be a waste of your time. > If you volunteer, I welcome any help on this, whether by finding the issues > with the light-locker/lightdm/DDX stack or actually making sure there's no > security issue in xfce4-screensaver. I'm afraid I have neither the tuits nor expertise to help with fixing or dedicated QA here, just testing as a part of using the product of your efforts in my daily work and hacking. And there's a reason I annoy you rather than Mate, KDE, *shudder* Gnome, or Gnustep folks :) But, in this case, I am very excited that you have a replacement for something I find to be hopelessly buggy -- and the replacement seems near-perfect. Thus, if you switch, you save a lot of time, and any bit of time you save is a bit of time you can spend catering to my other whims. :) Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned ⢿⡄⠘⠷⠚⠋ by a hacker". So what's the problem? ⠈⠳⣄
Bug#919348: is it still unfit for Bullseye?
> So we're filing an RC bug to prevent it from migrating to testing, > this can be closed once buster is frozen. So... is there any reason to not let xfce4-screensaver go to Bullseye? Any day that a human being suffers from light-locker is a bad day. If you're afraid about yet-unknown bugs, more exposure to users early in the release cycle would be a good idea. On the other hand, light-locker suffers from a multitude of known problems (see the recent debian-devel thread), and you hate the third alternative, xscreensaver (jwz's time bomb being indeed a good reason). Closing this bug should be enough...? Meow. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned ⢿⡄⠘⠷⠚⠋ by a hacker". So what's the problem? ⠈⠳⣄
Bug#930869: Asked to try and mediate this bug.
Control: severity -1 wishlist
Control: tags -1 +moreinfo
On Sun, Jun 30, 2019 at 11:26:01AM -0400, Sam Hartman wrote:
> Unfortunately, to do that, I'm going to need to ask at least one
> question that Adam is already asked.
[...]
Michael: if you have trouble naming either any particular problem, or a
viable replacement for this package, I assume there are none. If that's
incorrect, please provide more info before bumping the severity again.
The only remaining actionable part of this bug are the hacks ("quirks")
for buggy machines. Having researched the package a bit more, I see that
they talk to real-mode display BIOS -- such machines generally stopped
being manufactured roughly at the time pm-utils became unmaintained
upstream, thus I wonder whether that particular part of the code can be
said to "do more more harm then good". I'd wary before pulling the quirks
from under potentially working hardware.
But, I have no way to check that: none of 5 laptops I have even _has_ a
real-mode BIOS (three because of being non-x86, two because of level 3
UEFI without CSM). And for my non-laptops, which range from a 2004 box to
this year's stuff, pm-utils work perfectly without quirks.
So there are two questions:
* are pm-utils useful on non-quirk hardware?
• my answer is a strong "yes"
* should code for legacy hardware be kept if it can't be tested?
• this part I can't answer
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ According to recent spams, "all my email accounts are owned
⢿⡄⠘⠷⠚⠋ by a hacker". So what's the problem?
⠈⠳⣄
Bug#930869: Don't release with buster
Control: severity -1 wishlist On Thu, Jun 27, 2019 at 09:00:38PM +0200, Michael Biebl wrote: > Am 24.06.19 um 00:46 schrieb Ivo De Decker: > > acpi-support depends on it, so removal is not possible. And even if it was, > > it > > would probably be too late for that. > > > > Tagging this bug buster-ignore accordingly. > > Ok, I missed that. While this is unfortunate, I would still like to keep > this bug report as RC, so users of pm-utils are properly notified that > it is better to not use this package in buster. But, as I repeatedly asked and you did not answer: WHY would it be better to not use this package in buster? Could you please name a case where it's harmful? Or even name a replacement that fits its use case and actually works? > Hopefully we can sort this out properly in buster+1. If you demand that obsolete quirks are deleted, that can be done. But that's in no way a bug of RC severity -- "wishlist" is appropriate unless you can demonstrate a quirk that actually can cause serious damage. And about the last part... after going out of my way to try to debug a certain broken piece of software that's not my itch to scratch, I was rewarded by my new expensive machine failing to power on, with main remaining suspiction being invalid pokes specifically to power management. Fortunately, after a few hours of random panicked actions such as reseating all motherboard-mounted pieces of hardware and so on, it did finally start up. Thus no -- there's no way I'm going to try that again. If you wish for a clean-up... at this moment I can't spare any real tuits, but we're in deep freeze anyway. _Then_ I, or someone else, can consider looking at this _wishlist_ thing. I obviously care mostly about my personal use cases -- none of machines I own match any of the quirks -- thus, if per your advice as the former maintainer, the quirks should go, then I have no means to test them anyway. Not can I test support for Apple PMU (I don't know how many people have/care about powerpc Macs). But... as the quirks affect only old machines, which were already there by the time you maintained the package, what's exactly the problem with them? Especially one that would warrant urgent action. I can drop that if you wish, but the package itself is needed to suspend _my_ hardware. I'm concerned with breaking other people's toys, though... Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Packager's rule #1: upstream _always_ screws something up. This ⢿⡄⠘⠷⠚⠋⠀ is true especially if you're packaging your own project. ⠈⠳⣄
Bug#923203: pulseaudio: fails to start without manual configuration
On Sat, Jun 22, 2019 at 11:26:40AM +0200, Tobias Hansen wrote: > On 6/21/19 10:54 PM, Adam Borowski wrote: > > (patch is > > https://salsa.debian.org/pulseaudio-team/pulseaudio/merge_requests/5) > > > > On Fri, Jun 21, 2019 at 11:37:48AM +0200, Tobias Hansen wrote: > >> I just updated by system from stretch to buster and after that there was > >> no sound in GNOME because pulseaudio was not started. > >> It can be easily worked around by setting "autospawn = yes" in > >> ~/.config/pulse/client.conf but it's quite an annoying regression. > >> > >> Can this still be fixed for buster? Can we make it an RC bug? > But I am using systemd and saw this regression anyway. Let me test that patch. Then my patch can't possibly work for you, as it re-enables autospawn on !systemd only. You may have ran into some other autospawn bug. In other words: * on !systemd, PA never starts (which makes the package useless) * on systemd, PA still fails to start in some cases I don't know enough about either PA or systemd to meaningfully help you debug that case -- and my fix affects !systemd only. Meow! -- A MAP07 (Dead Simple) raspberry tincture recipe: 0.5l 95% alcohol, 1kg raspberries, 0.4kg sugar; put into a big jar for 1 month. Filter out and throw away the fruits (can dump them into a cake, etc), let the drink age at least 3-6 months.
Bug#930869: Processed: severity of 930869 is serious, retitle 930869 to Don't release with buster
On Sat, Jun 22, 2019 at 08:06:08AM +, Debian Bug Tracking System wrote: > Processing commands for cont...@bugs.debian.org: > > > severity 930869 serious > Bug #930869 [pm-utils] needs purging of quirks > Severity set to 'serious' from 'wishlist' > > retitle 930869 Don't release with buster > Bug #930869 [pm-utils] needs purging of quirks > Changed Bug title to 'Don't release with buster' from 'needs purging of > quirks'. Could you please name _any_ problem with pm-utils that would warrant emergency, 4-days-before-absolute-freeze, removal of it from Buster? Especially that you do no longer use it, while I use it daily -- and at least for me, it works, unlike a certain alternative you seem to imply, -- and I am not aware of pm-utils having regressed. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ .globl _start↵.data↵rc: .ascii "/etc/init.d/rcS\0"↵.text↵_start ⣾⠁⢰⠒⠀⣿⡁ mov $57,%rax↵syscall↵cmp $0,%rax↵jne child↵parent:↵mov $61,%rax ⢿⡄⠘⠷⠚⠋⠀ mov $-1,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall↵jmp parent↵child: ⠈⠳⣄ mov $59,%rax↵mov $rc,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall
Bug#930869: needed then
Control: severity -1 wishlist Control: retitle -1 needs purging of quirks On Fri, Jun 21, 2019 at 10:22:16PM +0200, Michael Biebl wrote: > >>> But, do we even have an alternative for suspending remotely? > >> Not really, pm-utils is not needed. > > Could you then please educate me what the replacement is? > > I'm not here to educate you. > You are too smart anyways. Thanks for kind words. No alternative means we can't remove pm-utils. You're right that the quirks are obsolete and unmaintained, and should be purged away. There's no hope for machine vendors' ACPI implementations to get into sane states within our lifetime, but handling the brokenness is done in the kernel these days. But, such clean-up is not a task for deepest parts of the freeze. For now, pm-utils works fine, at least within my use cases. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!? ⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din ⠈⠳⣄
Bug#930869: Don't release with buster
On Fri, Jun 21, 2019 at 08:53:32PM +0200, Michael Biebl wrote: > Am 21.06.19 um 20:05 schrieb Adam Borowski: > > But, do we even have an alternative for suspending remotely? > > What do you mean by that? So here we have a computer. No GUI tools. No emulation of GUI tools. And I want to suspend it (then WoL back). > > Until that is present, pm-utils is needed -- and even then, it should > > preferably be replaced by wrappers, not removed. > > Not really, pm-utils is not needed. Could you then please educate me what the replacement is? Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. ⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift ⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters ⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
Bug#930869: Don't release with buster
On Fri, Jun 21, 2019 at 07:42:00PM +0200, Michael Biebl wrote: > Package: pm-utils > Version: 1.4.1-18 > Severity: serious > > As former maintainer of pm-utils, I don't want to see pm-utils released > with buster. > pm-utils is a set of hacks/scripts which back in the days were necessary > to successfully suspend/hibernate your system. But, do we even have an alternative for suspending remotely? Until that is present, pm-utils is needed -- and even then, it should preferably be replaced by wrappers, not removed. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Autotools hint: to do a zx-spectrum build on a pdp11 host, type: ⢿⡄⠘⠷⠚⠋⠀ ./configure --host=zx-spectrum --build=pdp11 ⠈⠳⣄
Bug#930858: throw out GNU tar, too. And binutils.
> "Crash confirmed. Buthis program is not expected to be able to deal > with arbitrarily broken input. All I'm going to do about it is add a > SIGSEGV handler." > here we have an upstream maintainer explicitly saying that an > image-processing program is not suitable for use on arbitrary input So what about GNU tar where restoring an untrusted tarball, _or_ restoring a tarball as root when an user who owns any files contained within the tarballs is logged on, is not supported either? Or, btrfs-receive with the same problem (but at least you _can_ do it securely as an user, with an unobvious and still poorly documented way). Or, binutils that can't be used to analyze untrusted input either? Sometimes input validation would massively extend the amount of tuits needed, beyond the author's resources. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands ⢿⡄⠘⠷⠚⠋⠀ for Privacy. ⠈⠳⣄
Bug#911623: not RC in my opinion
Control: severity -1 important > Severity: serious > Justification: Debian Policy violation > /bin/mkfs.btrfs and /bin/fsck.btrfs are Policy and FHS violations. I don't believe this is in any way RC -- for Buster nor likely any future release. There's no functional lossage, AFAIK. fsck probably should indeed be moved away from /bin -- it's a legacy atavistic thing that's not of much use to users. Filesystems of old suffered corruption on every unexpected power loss and thus required automated fsck. That's not the case during current millenium. Among mainstream filesystems, only ext4 still ships real fsck (mostly for historic reasons), I think jfs has it trigger log replay; the rest (btrfs, xfs, f2fs, ...) ship just a stub that does nothing. There are actual repair tools but those shouldn't generally be run other than as a hail mary effort; regular checks are supposed to use online scrub instead, without downtime. Moving that stub has been requested in #798072. mkfs on the other hand is widely used by non-root users these days. On raw metal, you generally mkfs once per hardware replacement, while VMs or board images get created often. Thus, I'd rather ask for Policy change than to alter the package. This means, I don't consider the bug to be serious. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Sometimes you benefit from delegating stuff. For example, ⢿⡄⠘⠷⠚⠋⠀ this way I get to be a vegetarian. ⠈⠳⣄
