Bug#993156: nvidia-driver: recommend libnvidia-encode1
Package: nvidia-driver Version: 470.57.02-2 Severity: normal X-Debbugs-Cc: mooff@awful.cooking Dear Maintainer, I think it would be appropriate to add libnvidia-encode1 to recommends for nvidia-driver. It would help to make this common GPU feature part of the standard install - and might help to offer motivation for the obs-studio and ffmpeg packages to support the NVenc encoder out of the box in Debian. Thanks a lot, I think 'apt install nvidia-driver' is the cleanest experience I've had installing a proprietary driver on any OS. mooff :-)
Bug#993155: RFA: ssh-askpass -- under X, asks user for a passphrase for ssh-add
Package: wnpp Severity: normal Control: affects -1 src:ssh-askpass I request an adopter for the ssh-askpass package. I stopped using this a while ago, so it's time to give it away. Jim Knoble no longer develops it, so while there are very few bugs, fixing those that exist is only likely to happen if the maintainer does it, or if they choose to settle on the versions that exist in e.g. OpenBSD and adopt that as upstream. Last time I looked that didn't seem to be a win, and I've not had time to look at fixing even the trivial bug about placement, which really confirma that someone else should be looking after this. The package description is: This is Jim Knoble's implementation of the ssh-askpass program, originally called x11-ssh-askpass upstream. It is built on low-level X11 libraries, and therefore has minimal dependencies. . Other ssh-askpass programs are available, some of which may integrate better into various desktop environments.
Bug#993154: Install successful but failed to load all basic software
Package: dpkg Install to Raspberry Pi 4 (4G RAM) Methodhttps://www.raspberrypi.org/forums/viewtopic.php?f=50=282839=3c56d720738b6f6768874193298c3c38 install ran 26 August 2021 using images downloaded that day. Install ran fine BUT /usr/sbin/start-stop-daemon NOT installed. so dpkg aborts with a helpful error message. Had same problem about a month or so ago but did not have problem some months ago (shortly after the above guide came out) Chris B
Bug#975023: vmdb2: qemu-debootstrap after virtual-filesystems fails,Re: vmdb2: qemu-debootstrap after virtual-filesystems fails
Hello Ryutaroh, Ryutaroh Matsumoto dijo [Sun, Aug 22, 2021 at 01:02:57PM +0900]: > Hi, Diederik > > I redid vmdb run and again got errors as attached. > qemu-user-static are from bullseye and sid. > Both trial failed. I uploaded vmdb2 0.24, which incorporates upstream commit bc42e2a, which merges qemu-debootstrap into debootstrap. Could you check if the issue persists?
Bug#993152: cinnamon: Printer icon is shown. No printers installed ..Setting is "when printer exist"
Package: cinnamon Version: 4.8.6-2 Severity: minor X-Debbugs-Cc: eduard.fili...@rhea.si Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads) Locale: LANG=sl_SI.UTF-8, LC_CTYPE=sl_SI.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cinnamon depends on: ii cinnamon-common 4.8.6-2 ii cinnamon-control-center 4.8.2-1 ii cinnamon-desktop-data4.8.1-2 ii cinnamon-screensaver 4.8.1-3 ii cinnamon-session 4.8.0-3 ii cinnamon-settings-daemon 4.8.5-1 ii cjs 4.8.2-1 ii cups-pk-helper 0.2.6-1+b1 ii dbus 1.12.20-2 ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii gir1.2-accountsservice-1.0 0.6.55-3 ii gir1.2-caribou-1.0 0.4.21-7.1 ii gir1.2-clutter-1.0 1.26.4+dfsg-2 ii gir1.2-cmenu-3.0 4.8.3-1 ii gir1.2-cogl-1.0 1.22.8-2 ii gir1.2-cvc-1.0 4.8.1-2 ii gir1.2-gdkpixbuf-2.0 2.42.2+dfsg-1 ii gir1.2-gkbd-3.0 3.26.1-1 ii gir1.2-glib-2.0 1.66.1-1+b1 ii gir1.2-gnomedesktop-3.0 3.38.5-3 ii gir1.2-gtk-3.0 3.24.24-4 ii gir1.2-gtkclutter-1.01.8.4-4 ii gir1.2-keybinder-3.0 0.3.2-1.1 ii gir1.2-nemo-3.0 4.8.6-2 ii gir1.2-nm-1.01.30.0-2 ii gir1.2-nma-1.0 1.8.30-1 ii gir1.2-notify-0.70.7.9-3 ii gir1.2-pango-1.0 1.46.2-3 ii gir1.2-polkit-1.00.105-31 ii gir1.2-soup-2.4 2.72.0-2 ii gir1.2-timezonemap-1.0 0.4.6-2 ii gir1.2-upowerglib-1.00.99.11-2 ii gir1.2-xapp-1.0 2.0.7-1 ii gkbd-capplet 3.26.1-1 ii gnome-backgrounds3.38.0-1 ii gnome-themes-extra 3.28-1 ii gsettings-desktop-schemas3.38.0-2 ii iso-flags-png-320x2401.0.2-1.1 ii libatk-bridge2.0-0 2.38.0-1 ii libatk1.0-0 2.36.0-2 ii libc62.31-13 ii libcairo21.16.0-5 ii libcinnamon-desktop4 4.8.1-2 ii libcinnamon-menu-3-0 4.8.3-1 ii libcjs0 4.8.2-1 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libgirepository-1.0-11.66.1-1+b1 ii libgl1 1.3.2-1 ii libglib2.0-0 2.66.8-1 ii libglib2.0-bin 2.66.8-1 ii libgstreamer1.0-01.18.4-2.1 ii libgtk-3-0 3.24.24-4 ii libmuffin0 4.8.1-1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libstartup-notification0 0.12-6+b1 ii libx11-6 2:1.7.2-1 ii libxfixes3 1:5.0.3-2 ii libxml2 2.9.10+dfsg-6.7 ii mesa-utils 8.4.0-1+b1 ii muffin 4.8.1-1 ii nemo 4.8.6-2 ii network-manager-gnome1.20.0-3 ii policykit-1-gnome0.105-7 ii python3 3.9.2-3 ii python3-dbus 1.2.16-5 ii python3-distro 1.5.0-1 ii python3-gi 3.38.0-2 ii python3-gi-cairo 3.38.0-2 ii python3-pampy1.8.4-2 ii python3-pexpect
Bug#993131: webext-keepassxc-browser: Chromium error: "Failed to load extension from: . Manifest file is missing or unreadable"
Am Freitag, dem 27.08.2021 um 19:13 +0200 schrieb Nicola Davide Mannarelli: > Package: webext-keepassxc-browser > Version: 1.7.9.1+repack1-2 > Severity: normal > Tags: upstream > X-Debbugs-Cc: li...@ndmnet.eu > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > -- System Information: > Debian Release: 11.0 > APT prefers stable-security > APT policy: (500, 'stable-security'), (500, 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_GB:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages webext-keepassxc-browser depends on: > ii keepassxc 2.6.2+dfsg.1-1 > > Versions of packages webext-keepassxc-browser recommends: > ii chromium 90.0.4430.212-1 > ii firefox-esr 78.13.0esr-1~deb11u1 > > webext-keepassxc-browser suggests no packages. Hello Nicola, I cannot reproduce the bug, that's my test system: fuddl@debian:~$ LC_ALL=C apt list --installed webext-keepassxc-browser chromium keepassxc Listing... Done chromium/unstable,unstable,now 90.0.4430.212-1 amd64 [installed] keepassxc/unstable,unstable,now 2.6.2+dfsg.1-1 amd64 [installed,automatic] webext-keepassxc-browser/unstable,unstable,now 1.7.9.1+repack1-2 all [installed] Chromium loads KeePassXC-Browser from the Debian package (In the extension's settings it states "Loaded from: /usr/share/webext/keepassxc-browser") and it works as expected. Can you please share more information? Cheers, Bruno signature.asc Description: This is a digitally signed message part
Bug#993151: cinnamon: Nemo has inconvenient font color for selected file/folder in 2plate preview when changing plate
Package: cinnamon Version: 4.8.6-2 Severity: minor X-Debbugs-Cc: eduard.fili...@rhea.si Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads) Locale: LANG=sl_SI.UTF-8, LC_CTYPE=sl_SI.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cinnamon depends on: ii cinnamon-common 4.8.6-2 ii cinnamon-control-center 4.8.2-1 ii cinnamon-desktop-data4.8.1-2 ii cinnamon-screensaver 4.8.1-3 ii cinnamon-session 4.8.0-3 ii cinnamon-settings-daemon 4.8.5-1 ii cjs 4.8.2-1 ii cups-pk-helper 0.2.6-1+b1 ii dbus 1.12.20-2 ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii gir1.2-accountsservice-1.0 0.6.55-3 ii gir1.2-caribou-1.0 0.4.21-7.1 ii gir1.2-clutter-1.0 1.26.4+dfsg-2 ii gir1.2-cmenu-3.0 4.8.3-1 ii gir1.2-cogl-1.0 1.22.8-2 ii gir1.2-cvc-1.0 4.8.1-2 ii gir1.2-gdkpixbuf-2.0 2.42.2+dfsg-1 ii gir1.2-gkbd-3.0 3.26.1-1 ii gir1.2-glib-2.0 1.66.1-1+b1 ii gir1.2-gnomedesktop-3.0 3.38.5-3 ii gir1.2-gtk-3.0 3.24.24-4 ii gir1.2-gtkclutter-1.01.8.4-4 ii gir1.2-keybinder-3.0 0.3.2-1.1 ii gir1.2-nemo-3.0 4.8.6-2 ii gir1.2-nm-1.01.30.0-2 ii gir1.2-nma-1.0 1.8.30-1 ii gir1.2-notify-0.70.7.9-3 ii gir1.2-pango-1.0 1.46.2-3 ii gir1.2-polkit-1.00.105-31 ii gir1.2-soup-2.4 2.72.0-2 ii gir1.2-timezonemap-1.0 0.4.6-2 ii gir1.2-upowerglib-1.00.99.11-2 ii gir1.2-xapp-1.0 2.0.7-1 ii gkbd-capplet 3.26.1-1 ii gnome-backgrounds3.38.0-1 ii gnome-themes-extra 3.28-1 ii gsettings-desktop-schemas3.38.0-2 ii iso-flags-png-320x2401.0.2-1.1 ii libatk-bridge2.0-0 2.38.0-1 ii libatk1.0-0 2.36.0-2 ii libc62.31-13 ii libcairo21.16.0-5 ii libcinnamon-desktop4 4.8.1-2 ii libcinnamon-menu-3-0 4.8.3-1 ii libcjs0 4.8.2-1 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1 ii libgirepository-1.0-11.66.1-1+b1 ii libgl1 1.3.2-1 ii libglib2.0-0 2.66.8-1 ii libglib2.0-bin 2.66.8-1 ii libgstreamer1.0-01.18.4-2.1 ii libgtk-3-0 3.24.24-4 ii libmuffin0 4.8.1-1 ii libpango-1.0-0 1.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libstartup-notification0 0.12-6+b1 ii libx11-6 2:1.7.2-1 ii libxfixes3 1:5.0.3-2 ii libxml2 2.9.10+dfsg-6.7 ii mesa-utils 8.4.0-1+b1 ii muffin 4.8.1-1 ii nemo 4.8.6-2 ii network-manager-gnome1.20.0-3 ii policykit-1-gnome0.105-7 ii python3 3.9.2-3 ii python3-dbus 1.2.16-5 ii python3-distro 1.5.0-1 ii python3-gi 3.38.0-2 ii python3-gi-cairo 3.38.0-2 ii python3-pampy1.8.4-2 ii python3-pexpect
Bug#993150: rust-simplelog: set TERM in debian/rules to avoid build failures
Package: rust-simplelog
Version: 0.7.4-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu impish ubuntu-patch
Hi Sylvestre,
The rust-simplelog package has been failing to build in Ubuntu with the
following error:
tests::test stdout
thread 'tests::test' panicked at 'called `Option::unwrap()` on a `None` value',
/usr/src/rustc-1.41.0/src/libcore/macros/mod.rs:15:40
stack backtrace:
0: ::fmt
1: core::fmt::write
2: std::io::Write::write_fmt
3: std::io::impls::>::write_fmt
4: std::panicking::default_hook::{{closure}}
5: std::panicking::default_hook
6: std::panicking::rust_panic_with_hook
7: rust_begin_unwind
8: core::panicking::panic_fmt
9: core::panicking::panic
10: core::option::Option::unwrap
at /usr/src/rustc-1.41.0/src/libcore/macros/mod.rs:15
11: simplelog::tests::test
at src/lib.rs:117
12: simplelog::tests::test::{{closure}}
at src/lib.rs:88
13: core::ops::function::FnOnce::call_once
at /usr/src/rustc-1.41.0/src/libcore/ops/function.rs:232
14: as core::ops::function::FnOnce>::call_once
15: __rust_maybe_catch_panic
16: test::run_test_in_process
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose
backtrace.
This happens because the Ubuntu build environment sets TERM=unknown, whereas
Debian I believe sets it to TERM=linux.
The attached patch overrides TERM in debian/rules, to ensure consistent
build/test results regardless of the environment.
Thanks for considering.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru rust-simplelog-0.7.4/debian/rules rust-simplelog-0.7.4/debian/rules
--- rust-simplelog-0.7.4/debian/rules 2020-04-22 04:26:38.0 -0700
+++ rust-simplelog-0.7.4/debian/rules 2021-08-27 18:22:02.0 -0700
@@ -1,4 +1,7 @@
#!/usr/bin/make -f
+
+export TERM=linux
+
%:
dh $@ --buildsystem cargo
Bug#992989: Acknowledgement (avahi-daemon CPU usage increases over time)
On 2021-08-25 7:27 p.m., Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. You can follow progress on this Bug here: 992989: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992989. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): Utopia Maintenance Team If you wish to submit further information on this problem, please send it to 992...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. So... I messed up and raised the same bug twice, thinking the e-mail didn't go out. Since #993051 has slightly updated text, this one can be rejected.
Bug#987008: Grub fails to find LVM volume after previous LV rename
Dear maintainer, I have also run into this bug, in the same version of grub (2.02+dfsg1-20+deb10u4). As *any* change to the LVM configuration can trigger the bug, rendering the system unbootable, this is a ticking bomb for users of LVM. IMO the severity of this bug should be increased to critical. I did some investigation, and the cause is an incorrect computation of mda_end when the metadata area wraps around. The following patch fixes the problem: --- Index: grub2-2.02+dfsg1/grub-core/disk/lvm.c === --- grub2-2.02+dfsg1.orig/grub-core/disk/lvm.c +++ grub2-2.02+dfsg1/grub-core/disk/lvm.c @@ -253,7 +253,7 @@ error_parsing_metadata: p = q = (char *)ptr; - if (grub_add ((grub_size_t)metadatabuf, (grub_size_t)mda_size, )) + if (grub_add (ptr, (grub_size_t)grub_le_to_cpu64 (rlocn->size), )) goto error_parsing_metadata; mda_end = (char *)ptr; I checked the sources of grub2-2.04 in bullseye, and the code in question looks exactly the same, so this same bug is also present in bullseye and testing. Kind regards, Rogier.
Bug#993140: resolvconf: `$ resolvconf -u` never run, empty /run/resolvconf/resolv.conf
Package: resolvconf Version: 1.87 Severity: important Dear Maintainer, on every boot: - /usr/lib/tmpfiles.d/resolvconf.conf via systemd-tmpfiles-setup.service creates /run/resolvconf/postponed-update - /lib/systemd/system/resolvconf.service runs `$ resolvconf --enable-updates`. If these two events would happen in this order, `$ resolvconf --enable-updates` would remove the `postponed-update` file and update `/run/resolvconf/resolv.conf`. But at least on my system `resolvconf.service` runs before `systemd-tmpfiles-setup.service`. Just creating the `postponed-update` file while updates are enabled does not trigger an update. Thus the empty /run/resolvconf/resolv.conf (also written through systemd-tmpfiles) is never overwritten, leaving the system without the ability to resolve DNS names, until `$ resolvconf -u` is run. This can probably be fixed by adding the following line to the Unit-Section of resolvconf.service: After=systemd-tmpfiles-setup.service I do not believe that will introduce any cycles, but I've also not looked into that. Some more information: This is on a VPS upgraded from buster to bullseye (but still running the buster kernel) On my system I have resolved this issue using this Service, creating the `postponed-update`-file before starting resolvconf.service: # SPDX-FileCopyrightText: 2021 Timon Reinold # SPDX-License-Identifier: GPL-3.0-or-later [Unit] Description=Shedule resolvconf update DefaultDependencies=no Before=resolvconf.service [Service] ExecStart=/sbin/resolvconf -u [Install] WantedBy=sysinit.target but I fear that might exhibit the same SE-Linux issue the commit 159e3214 introducing this issue fixed. The `After=`-Line mentioned above should be preferred. -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'master'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0 (SMP w/4 CPU threads) Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages resolvconf depends on: ii debconf [debconf-2.0] 1.5.77 ii lsb-base 11.1.0 resolvconf recommends no packages. resolvconf suggests no packages. -- Configuration Files: /etc/resolvconf/resolv.conf.d/base changed [not included] -- debconf information: resolvconf/reboot-recommended-after-removal: * resolvconf/downup-interfaces: resolvconf/link-tail-to-original: false * resolvconf/linkify-resolvconf: true
Bug#915541: Removal of upstream "--will-cite" functionality has been reverted
Hi Andreas and other maintainers, It appears that upload 20210322+ds-1 for package parallel reverts the change made in NMU upload 20161222-1.1. Is that intentional? Ian Turner
Bug#993149: sagemath FTBFS with eclib 20210625-1
Source: sagemath
Version: 9.2-2
Severity: serious
Tags: ftbfs bookworm sid
https://buildd.debian.org/status/package.php?p=sagemath=sid
...
[sagelib-9.2] build/cythonized/sage/libs/eclib/wrap.cpp: In function ‘int
mw_saturate(mw*, bigint*, char**, long int, int)’:
[sagelib-9.2] build/cythonized/sage/libs/eclib/wrap.cpp:185:23: error: cannot
convert ‘bigint’ {aka ‘NTL::ZZ’} to ‘long int&’
[sagelib-9.2] 185 | int s = m->saturate(*index, v, sat_bd, odd_primes_only);
[sagelib-9.2] | ^~
[sagelib-9.2] | |
[sagelib-9.2] | bigint {aka NTL::ZZ}
[sagelib-9.2] In file included from /usr/include/eclib/descent.h:27,
[sagelib-9.2] from
build/cythonized/sage/libs/eclib/mwrank.cpp:693:
...
Bug#993071: kmail: symbol lookup error: /lib/x86_64-linux-gnu/libKF5Libkleo.so.5: undefined symbol: _ZN5GpgME6UserID9SignatureltERKS1_
On Fri, Aug 27, 2021 at 09:49:02AM +0200, Johannes Rohr wrote: > Package: kmail > Version: 4:21.08.0-1 > Severity: grave > Justification: renders package unusable > > As of today's upgrades, kmail fails to start: > > kmail: symbol lookup error: /lib/x86_64-linux-gnu/libKF5Libkleo.so.5: > undefined symbol: _ZN5GpgME6UserID9SignatureltERKS1_ >... > Versions of packages kmail depends on: >... > ii libgpgmepp6 1.16.0-1 >... > ii libkf5libkleo5 [libkf5libkleo5-21.08] 4:21.08.0-1 >... What is the output of ldd /lib/x86_64-linux-gnu/libKF5Libkleo.so.5 | grep gpgmepp ? cu Adrian
Bug#993044: libxcrypt breaks existing password hashes
On Thu, Aug 26, 2021 at 01:33:21PM -0600, Sam Hartman wrote: > package: libxcrypt > version: 1:4.4.22-1 > severity: serious > justification: breaks login > > See bug #992848. > Because of the way libpam0g calls libxcrypt any existing sha256 hash > will be rejected at login as expired. > I'm going to fix this in pam using the linux-pam upstream fix, but > libxcrypt should not migrate to testing before the fixed pam is in > testing. > > This bug is intended to block that migration. > Feel free to do something else that blocks the migration. > If this bug is still open when libpam migrates, I'll close it. Shouldn't this bug be closed with an upload that adds a Breaks/Conflicts against the non-updated libpam0g? Otherwise the same problem would be present for bullseye->bookworm upgrades. And other users in bullseye have to be checked as well for being affected by this breakage, baed on the autopkgtest at least dovecot looks like having the same problem. cu Adrian
Bug#993147: libstatgrab FTBFS: ./configure: line 7892: syntax error near unexpected token `ac_fn_check_decl'
This is fixed in libstatgrab 0.92.1:
https://github.com/libstatgrab/libstatgrab/releases/tag/LIBSTATGRAB_0_92_1
Or this specific patch should fix it too:
https://github.com/libstatgrab/libstatgrab/commit/1205aed6593b83f69297512b89c7813d77be89d4
Tim.
On Fri, Aug 27, 2021 at 11:34:36PM +0200, Helmut Grohne wrote:
> Source: libstatgrab
> Version: 0.92-2
> Severity: serious
> Tags: ftbfs
>
> libstatgrab fails to build from source in unstable. The relevant part of
> the build log is:
>
> | dh build --with autoreconf
> | dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
> |dh_update_autotools_config
> |dh_autoreconf
> | libtoolize: putting auxiliary files in '.'.
> | libtoolize: copying file './ltmain.sh'
> | libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
> | libtoolize: copying file 'm4/libtool.m4'
> | libtoolize: copying file 'm4/ltoptions.m4'
> | libtoolize: copying file 'm4/ltsugar.m4'
> | libtoolize: copying file 'm4/ltversion.m4'
> | libtoolize: copying file 'm4/lt~obsolete.m4'
> | configure.ac:54: warning: The macro `AC_PROG_CC_C99' is obsolete.
> | configure.ac:54: You should run autoupdate.
> | ./lib/autoconf/c.m4:1659: AC_PROG_CC_C99 is expanded from...
> | configure.ac:54: the top level
> | configure.ac:65: warning: The macro `AC_HEADER_STDC' is obsolete.
> | configure.ac:65: You should run autoupdate.
> | ./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
> | configure.ac:65: the top level
> | configure.ac:66: warning: The macro `AC_HEADER_TIME' is obsolete.
> | configure.ac:66: You should run autoupdate.
> | ./lib/autoconf/headers.m4:743: AC_HEADER_TIME is expanded from...
> | configure.ac:66: the top level
> | configure.ac:95: warning: The macro `AC_TYPE_GID_T' is obsolete.
> | configure.ac:95: You should run autoupdate.
> | m4/ax_types.m4:21: AC_TYPE_GID_T is expanded from...
> | configure.ac:95: the top level
> | configure.ac:156: warning: The macro `AC_LANG_C' is obsolete.
> | configure.ac:156: You should run autoupdate.
> | ./lib/autoconf/c.m4:72: AC_LANG_C is expanded from...
> | m4/ax_win32.m4:5: AX_WIN32 is expanded from...
> | configure.ac:156: the top level
> | configure.ac:1461: warning: The macro `AC_PROG_LD' is obsolete.
> | configure.ac:1461: You should run autoupdate.
> | m4/libtool.m4:3341: AC_PROG_LD is expanded from...
> | m4/ax_visibility.m4:9: AX_CHECK_VISIBILITY is expanded from...
> | configure.ac:1461: the top level
> | configure.ac:1691: warning: The macro `AC_LANG_C' is obsolete.
> | configure.ac:1691: You should run autoupdate.
> | ./lib/autoconf/c.m4:72: AC_LANG_C is expanded from...
> | m4/ax_win32.m4:5: AX_WIN32 is expanded from...
> | lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
> | configure.ac:1691: the top level
> | configure.ac:1691: warning: $as_echo is obsolete; use AS_ECHO(["message"])
> instead
> | lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
> | lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
> | ./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
> | ./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
> | m4/ax_pthread.m4:88: AX_PTHREAD is expanded from...
> | lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
> | lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
> | m4/ax_win32.m4:5: AX_WIN32 is expanded from...
> | lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
> | configure.ac:1691: the top level
> | configure.ac:1838: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
> | configure.ac:1838: You should run autoupdate.
> | m4/libtool.m4:99: AC_PROG_LIBTOOL is expanded from...
> | configure.ac:1838: the top level
> | configure.ac:53: installing './compile'
> | configure.ac:18: installing './missing'
> | examples/Makefile.am: installing './depcomp'
> |dh_auto_configure
> | dh_auto_configure: warning: Compatibility levels before 10 are deprecated
> (level 9 in use)
> | ./configure --build=x86_64-linux-gnu --prefix=/usr
> --includedir=\${prefix}/include --mandir=\${prefix}/share/man
> --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
> --disable-option-checking --disable-silent-rules
> --libdir=\${prefix}/lib/x86_64-linux-gnu
> --libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode
> --disable-dependency-tracking
> | checking for a BSD-compatible install... /usr/bin/install -c
> | checking whether build environment is sane... yes
> | checking for a race-free mkdir -p... /bin/mkdir -p
> | checking for gawk... no
> | checking for mawk... mawk
> | checking whether make sets $(MAKE)... yes
> | checking whether make supports nested variables... yes
> | checking whether to enable maintainer-specific portions of Makefiles... no
> | checking build system type... x86_64-pc-linux-gnu
> | checking host system type... x86_64-pc-linux-gnu
> | checking for gcc... gcc
> | checking whether the C compiler works... yes
> | checking for C compiler default output file name... a.out
> | checking for suffix
Bug#993087: gpaste: Not compatible with gnome-shell 3.38
I haven't tried the new version. I filed this bug based on this file only: https://github.com/Keruspe/GPaste/blob/master/src/gnome-shell/metadata.json.in Looking a little closer, this file looks like the only thing that changed. https://github.com/Keruspe/GPaste/blob/master/src/gnome-shell/prefs.js My guess is that enables the gear button in gnome-shell-extension-prefs to work. But I think gpaste offers a better way to access settings. gir1.2-gtk-4.0 isn't yet in unstable but since gnome-shell 40 depends on it, it will be in unstable soon and you probably don't even need to depend on it directly. Feel free to close this bug if you want. Thanks, Jeremy Bicha
Bug#993148: linux-image-5.10.0-8-amd64: [drm:radeon_cs_ioctl [radeon]] *ERROR* Failed to sync rings: -35
Package: src:linux
Version: 5.10.46-4
Severity: important
Dear Maintainer,
this happened when I lauched mpv with DRI_PRIME=1, as usual. Also, this
X.Org session *could* be using the modesetting driver, as I temporarily
switched to it from the usual radeon driver, still I don't remember
exactly if I restarted X.Org since that. Running a compositing WM
(Compiz).
The last thing I saw was an mpv window with a small video in the topleft
corner, and a garbage in the rest of area. Then the graphics had
completely frozen, couldn't even switch to another VT after Alt+SysRq+R.
I connected via SSH to see what's happening, and found out that journald
rapidly fills the disk with repeating messages (saved an excerpt only):
rm:radeon_cs_ioctl [radeon]] *ERROR* Failed to sync rings: -35
rm:radeon_cs_ioctl [radeon]] *ERROR* Failed to sync rings: -35
deon :01:00.0: ring 5 stalled for more than 802164msec
deon :01:00.0: GPU lockup (current fence id 0x00039ae0 last fence
id 0x0003>
rm:radeon_cs_ioctl [radeon]] *ERROR* Failed to sync rings: -35
rm:radeon_cs_ioctl [radeon]] *ERROR* Failed to sync rings: -35
rm:radeon_cs_ioctl [radeon]] *ERROR* Failed to sync rings: -35
`modprobe -r radeon` and `modprobe -r drm` weren't working either.
`cat /sys/kernel/debug/dri/0/radeon_gpu_reset` had no effect: the screen
blinked and still was showing the same still image, and the dmesg spam
continued. So I had to vacuum the journald logs and reboot the system.
-- Package-specific info:
** Version:
Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP
Debian 5.10.46-4 (2021-08-03)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64
root=UUID=026f3e19-643c-4c14-ab6f-61b61a178bdf ro radeon.dpm=1 radeon.audio=0
loglevel=4 swapaccount=1 crashkernel=384M-:128M
systemd.unified_cgroup_hierarchy=1 crashkernel=384M-:128M
** Tainted: PCOE (13313)
* proprietary module was loaded
* staging driver was loaded
* externally-built ("out-of-tree") module was loaded
* unsigned module was loaded
** Kernel log:
[ 61.935949] [drm] UVD initialized successfully.
[ 61.937083] [drm] ib test on ring 0 succeeded in 0 usecs
[ 61.937165] [drm] ib test on ring 3 succeeded in 0 usecs
[ 62.610467] [drm] ib test on ring 5 succeeded
[ 62.611839] [drm] Radeon Display Connectors
[ 62.642389] switching from power state:
[ 62.642402] ui class: none
[ 62.642404] internal class: boot
[ 62.642414] caps: video
[ 62.642423] uvdvclk: 0 dclk: 0
[ 62.642430] power level 0sclk: 3 mclk: 3 vddc: 900
vddci: 0
[ 62.642435] power level 1sclk: 3 mclk: 3 vddc: 900
vddci: 0
[ 62.642440] power level 2sclk: 3 mclk: 3 vddc: 900
vddci: 0
[ 62.642442] status: c b
[ 62.642451] switching to power state:
[ 62.642454] ui class: performance
[ 62.642457] internal class: none
[ 62.642463] caps: single_disp video
[ 62.642472] uvdvclk: 0 dclk: 0
[ 62.642477] power level 0sclk: 15700 mclk: 2 vddc: 900
vddci: 0
[ 62.642481] power level 1sclk: 4 mclk: 5 vddc: 900
vddci: 0
[ 62.642486] power level 2sclk: 75000 mclk: 8 vddc: 1120
vddci: 0
[ 62.642488] status: r
[ 62.650547] [drm] Initialized radeon 2.50.0 20080528 for :01:00.0 on
minor 1
[ 65.934102] SGI XFS with ACLs, security attributes, realtime, quota, no
debug enabled
[ 66.103044] XFS (sda5): Deprecated V4 format (crc=0) will not be supported
after September 2030.
[ 66.290799] XFS (sda5): Mounting V4 Filesystem
[ 68.825924] XFS (sda5): Ending clean mount
[ 68.826043] xfs filesystem being mounted at /media/virt supports timestamps
until 2038 (0x7fff)
[ 78.757811] [drm] PCIE GART of 1024M enabled (table at 0x0014C000).
[ 78.757939] radeon :01:00.0: WB enabled
[ 78.757946] radeon :01:00.0: fence driver on ring 0 use gpu addr
0x4c00
[ 78.757950] radeon :01:00.0: fence driver on ring 3 use gpu addr
0x4c0c
[ 78.759468] radeon :01:00.0: fence driver on ring 5 use gpu addr
0x0005c418
[ 78.776079] [drm] ring test on 0 succeeded in 1 usecs
[ 78.776091] [drm] ring test on 3 succeeded in 3 usecs
[ 78.952928] [drm] ring test on 5 succeeded in 1 usecs
[ 78.952938] [drm] UVD initialized successfully.
[ 78.953005] [drm] ib test on ring 0 succeeded in 0 usecs
[ 78.953084] [drm] ib test on ring 3 succeeded in 0 usecs
[ 79.634496] [drm] ib test on ring 5 succeeded
[ 79.642419] switching from power state:
[ 79.642430] ui class: none
[ 79.642433] internal class: boot
[ 79.642442] caps: video
[ 79.642452] uvdvclk: 0 dclk: 0
[ 79.642459] power level 0sclk: 3 mclk: 3 vddc: 900
vddci: 0
[ 79.642464] power level 1sclk: 3 mclk: 3 vddc: 900
vddci: 0
[ 79.642468] power level 2
Bug#993049: bullseye-pu: package rpki-trust-anchors/20210817-1+deb11u1
On Aug 27, "Adam D. Barratt" wrote: > The version number for a stable upload needs to be lower than the > version currently in unstable. As a no-change rebuild, the convention > would be 20210817-1~deb11u1, in the same style as backports. > > With that change in mind, please go ahead. Done. But I have also mistakenly uploaded the old +deb11u1 package, sorry. -- ciao, Marco signature.asc Description: PGP signature
Bug#993147: libstatgrab FTBFS: ./configure: line 7892: syntax error near unexpected token `ac_fn_check_decl'
Source: libstatgrab
Version: 0.92-2
Severity: serious
Tags: ftbfs
libstatgrab fails to build from source in unstable. The relevant part of
the build log is:
| dh build --with autoreconf
| dh: warning: Compatibility levels before 10 are deprecated (level 9 in use)
|dh_update_autotools_config
|dh_autoreconf
| libtoolize: putting auxiliary files in '.'.
| libtoolize: copying file './ltmain.sh'
| libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
| libtoolize: copying file 'm4/libtool.m4'
| libtoolize: copying file 'm4/ltoptions.m4'
| libtoolize: copying file 'm4/ltsugar.m4'
| libtoolize: copying file 'm4/ltversion.m4'
| libtoolize: copying file 'm4/lt~obsolete.m4'
| configure.ac:54: warning: The macro `AC_PROG_CC_C99' is obsolete.
| configure.ac:54: You should run autoupdate.
| ./lib/autoconf/c.m4:1659: AC_PROG_CC_C99 is expanded from...
| configure.ac:54: the top level
| configure.ac:65: warning: The macro `AC_HEADER_STDC' is obsolete.
| configure.ac:65: You should run autoupdate.
| ./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
| configure.ac:65: the top level
| configure.ac:66: warning: The macro `AC_HEADER_TIME' is obsolete.
| configure.ac:66: You should run autoupdate.
| ./lib/autoconf/headers.m4:743: AC_HEADER_TIME is expanded from...
| configure.ac:66: the top level
| configure.ac:95: warning: The macro `AC_TYPE_GID_T' is obsolete.
| configure.ac:95: You should run autoupdate.
| m4/ax_types.m4:21: AC_TYPE_GID_T is expanded from...
| configure.ac:95: the top level
| configure.ac:156: warning: The macro `AC_LANG_C' is obsolete.
| configure.ac:156: You should run autoupdate.
| ./lib/autoconf/c.m4:72: AC_LANG_C is expanded from...
| m4/ax_win32.m4:5: AX_WIN32 is expanded from...
| configure.ac:156: the top level
| configure.ac:1461: warning: The macro `AC_PROG_LD' is obsolete.
| configure.ac:1461: You should run autoupdate.
| m4/libtool.m4:3341: AC_PROG_LD is expanded from...
| m4/ax_visibility.m4:9: AX_CHECK_VISIBILITY is expanded from...
| configure.ac:1461: the top level
| configure.ac:1691: warning: The macro `AC_LANG_C' is obsolete.
| configure.ac:1691: You should run autoupdate.
| ./lib/autoconf/c.m4:72: AC_LANG_C is expanded from...
| m4/ax_win32.m4:5: AX_WIN32 is expanded from...
| lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
| configure.ac:1691: the top level
| configure.ac:1691: warning: $as_echo is obsolete; use AS_ECHO(["message"])
instead
| lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
| lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
| ./lib/autoconf/general.m4:2249: AC_CACHE_VAL is expanded from...
| ./lib/autoconf/general.m4:2270: AC_CACHE_CHECK is expanded from...
| m4/ax_pthread.m4:88: AX_PTHREAD is expanded from...
| lib/m4sugar/m4sh.m4:692: _AS_IF_ELSE is expanded from...
| lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
| m4/ax_win32.m4:5: AX_WIN32 is expanded from...
| lib/m4sugar/m4sh.m4:699: AS_IF is expanded from...
| configure.ac:1691: the top level
| configure.ac:1838: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
| configure.ac:1838: You should run autoupdate.
| m4/libtool.m4:99: AC_PROG_LIBTOOL is expanded from...
| configure.ac:1838: the top level
| configure.ac:53: installing './compile'
| configure.ac:18: installing './missing'
| examples/Makefile.am: installing './depcomp'
|dh_auto_configure
| dh_auto_configure: warning: Compatibility levels before 10 are deprecated
(level 9 in use)
| ./configure --build=x86_64-linux-gnu --prefix=/usr
--includedir=\${prefix}/include --mandir=\${prefix}/share/man
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-option-checking --disable-silent-rules
--libdir=\${prefix}/lib/x86_64-linux-gnu
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking
| checking for a BSD-compatible install... /usr/bin/install -c
| checking whether build environment is sane... yes
| checking for a race-free mkdir -p... /bin/mkdir -p
| checking for gawk... no
| checking for mawk... mawk
| checking whether make sets $(MAKE)... yes
| checking whether make supports nested variables... yes
| checking whether to enable maintainer-specific portions of Makefiles... no
| checking build system type... x86_64-pc-linux-gnu
| checking host system type... x86_64-pc-linux-gnu
| checking for gcc... gcc
| checking whether the C compiler works... yes
| checking for C compiler default output file name... a.out
| checking for suffix of executables...
| checking whether we are cross compiling... no
| checking for suffix of object files... o
| checking whether the compiler supports GNU C... yes
| checking whether gcc accepts -g... yes
| checking for gcc option to enable C11 features... none needed
| checking whether gcc understands -c and -o together... yes
| checking whether make supports the include directive... yes (GNU style)
| checking dependency style of gcc... none
| checking dependency style of gcc... (cached) none
|
Bug#990305: Introduce ARC support in Perl cross-compiling for Debian
Hi Niko, TL;DR: This is a kludge, not a solution. On Fri, Aug 27, 2021 at 10:38:12PM +0300, Niko Tyni wrote: > I assume "tested in rebootstrap build" means the package builds, but > did anybody test the resulting packages? I certainly did not. In particular, the main line of rebootstrap does not cross build perl. > I'm copying Helmut. Do you have any suggestions? Should I just take this > in and leave it to porters to worry about breakage? I don't have an opinion here. Personally, I do not consider the way perl performs cross builds sustainable. That is the reason why rebootstrap still does not cross build perl to this date. I still believe that the way to cross build perl is to make Configure (mostly) work for cross builds. The biggest step towards that has already been performed by generating Configure from source. Thank you. I believe that we can now rework it (and in part this has already happened upstream) to need less and less run tests. At some point, we'll reach a small and maintainable set of test results that does not have to be regenerated with every perl release. > BTW, our development is currently targeting 5.34 so somebody needs to > port this. I'm not sure if there will be another 5.32 upload before > we get 5.34 in unstable. That is why I find it unsustainable. If you deem the effort for updating those files for arc ok, so be it. >From my pov, it would be sufficient to start shipping them for arc once it becomes a ports architecture using the usual machinery. Helmut
Bug#970635: moosic: new upstream now supports Python 3
On 2021-05-30 at 19:53, The Wanderer wrote: > On 2021-05-30 at 09:33, The Wanderer wrote: > >> There is now a 'wip' branch on the relevant GitHub repository, >> which includes a commit dropping this. I haven't pushed it to the >> primary branch yet, because I'm still not certain how to properly >> test the result; I'm reasonably certain that it is / will be fine, >> but "reasonably certain" shouldn't be enough to move forward on >> when there's an alternative. Now that the new stable release of Debian has been out for a couple of weeks: any status on this? That potential new moosic release (without examples/completion, and with the new play-one command) is still pending testing of the result; I have no reason to expect it to not work, and certainly haven't managed to find anything that does break with it gone, but I don't know what would constitute a valid test of whether there is anything that fails to work without it but did work with it. [Re the bug that manifests when one of the playback commands in the moosic config file would give "No such file or directory":] > Once I've either found and fixed the bug or (much less likely) > assured myself it's not going to manifest in plausibly-real-world > user scenarios, In the somewhat-extensive meantime, I have done the latter of these. I still don't know what causes the buggy behavior, but I've confirmed that it already seems to exist in the previously packaged version, and I don't believe it's going to manifest in real-world usage. As such, I don't consider this a blocker for moving forward. (For reference, the buggy behavior is that even when moosicd is already running, moosic will in some cases fail to detect it - more specifically, the moosic internal client-server command 'no_op' will fail - and will therefore try to start a new instance of the daemon.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw signature.asc Description: OpenPGP digital signature
Bug#993146: rust-crossbeam-deque: CVE-2021-32810
Source: rust-crossbeam-deque X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for rust-crossbeam-deque. CVE-2021-32810[0]: | crossbeam-deque is a package of work-stealing deques for building task | schedulers when programming in Rust. In versions prior to 0.7.4 and | 0.8.0, the result of the race condition is that one or more tasks in | the worker queue can be popped twice instead of other tasks that are | forgotten and never popped. If tasks are allocated on the heap, this | can cause double free and a memory leak. If not, this still can cause | a logical bug. Crates using `Stealer::steal`, `Stealer::steal_batch`, | or `Stealer::steal_batch_and_pop` are affected by this issue. This has | been fixed in crossbeam-deque 0.8.1 and 0.7.4. https://rustsec.org/advisories/RUSTSEC-2021-0093.html If you fix the vulnerability please also make sure to include the CVE (Common Vulnerabilities & Exposures) id in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2021-32810 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-32810 Please adjust the affected versions in the BTS as needed.
Bug#984800: Remove dependency on cgroup-tools
Control: title -1 mininet: support for cgroup v2 El 08/03/21 a las 15:30, Santiago Ruano Rincón escribió: > Source: mininet > Version: 2.3.0-1 > Severity: serious > Tags: upstream > > Hi Tomasz, > > cgroup-tools (src:libcgroup) is now tagged to be autoremoved from > testing due to https://bugs.debian.org/959022 > > mininet should have to get rid of any cgroup-tools/cgroup1-related > stuff. Now that libcgroup 2.0 has landed in unstable, mininet could use it to support cgroup2. Cheers, -- Santiago signature.asc Description: PGP signature
Bug#993132: python3-fife: prints "is"/"is not" used-with-a-literal warnings at install time
This is a real bug. "is" is identity (pointer) comparison, like comparing char* in C using "==", so it is usually wrong for anything that isn't a singleton object such as None. On Fri, 27 Aug 2021 at 13:16:55 -0400, The Wanderer wrote: > Setting up python3-fife (0.4.2-3) ... > /usr/lib/python3/dist-packages/fife/extensions/fife_settings.py:301: > SyntaxWarning: "is not" with a literal. Did you mean "!="? > if module is not "FIFE": My understanding is that this is genuinely a functional bug: non-trivial strings in Python are usually allocated separately, so this is like doing "if (module == "FIFE")" in C, and in practice they will usually compare unequal, even if module is another string containing the letters "FIFE". > /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/curvegraph.py:164: > SyntaxWarning: "is" with a literal. Did you mean "=="? > if coordinates is None or len(coordinates) is 0: In CPython, the reference C implementation of Python, integers in a certain range (I think it's something like -1 to 100) are "interned", so comparison with "is" will do what the programmer intends - but that's an implementation detail that might change in a future version, and should not be relied on. Larger integers are allocated and freed on-demand, so they will usually compare unequal with "is", even if the numerical value is equal. Relying on this implementation detail is not portable to other implementations such as PyPy, and is considered to be bad style even in CPython. Conversely, None is a special singleton object, so comparing with "is None" or "is not None" is correct (and is considered to be good style). smcv
Bug#988312: libslf4j-java: misses liblog4j1.2-java as a dependency
Hi Emmanuel, On Mon, 10 May 2021 12:41:36 +0200 Emmanuel Bourg wrote: > Le 2021-05-10 11:23, Pierre Gruet a écrit : > > > Version 1.7.30-1 of libslf4j does not declare liblog4j1.2-java as a > > dependency, > > it is only declared within the "Suggests:" field in debian/control. > > > > Yet the classes of liblog4j1.2-java are needed by many classes in > > slf4j-migrator.jar, slf4j-log4j12.jar, log4j-over-slf4j.jar. > > log4j:log4j is > > also a declared dependency with scope runtime in slf4j-log4j12/pom.xml. > > For this reason, other projects depending on the artifact slf4j-log4j12 > > fail to > > resolve log4j:log4j:1.2.x. > > The dependency on log4j is only suggested because it's optional. The > right > solution I think it to move slf4j-log4j12 into its own > libslf4j-log4j12-java > package with a hard dependency on liblog4j1.2-java. I have just given it a try, it is quite easy to create a second binary package libslf4j-log4j12-java that depends on libslf4j-java and on liblog4j1.2-java, yet I tried to use ratt and it attempts to rebuild more than 850 packages. I am unsure the binary package split is worth running this number of builds and then touching all the reverse-dependencies that need it. Does keeping one binary package libslf4j-java and having it depend on liblog4j1.2-java (instead of just suggesting it) really seem unreasonable to you? After all, the log4j-1.2.jar file is really needed in the classpath when using the artifact slf4j-log4j12. > > Emmanuel Bourg > > Thanks again for your advice on this, -- Pierre
Bug#992609: careless upload of Erlang v24 without a transition tracking with the release team (was: rabbitmq-server fails to start after erlang v24 update)
Hi, Sorry my previous message was weird. On 27-08-2021 22:11, Paul Gevers wrote: > On 27-08-2021 21:58, Antonio Terceiro wrote: >> One thing that happens when you do this type of change without >> coordination is that all CI pipelines on unstable where rabbitmq-server >> is installed are now broken. For example all merge requests against >> debci at the moment have their tests in "failed" status. This creates >> unnecessary noise for a lot of people. > > rabbitmq-server already got an update, so unstable should be fine (if > not, shout (or better, file bugs)). I expect you mean testing, as I > think that the point is that erlang already migrated before the issue > was detected, otherwise an RC bug would have prevented the migration. > > That's why it was suggested earlier that rabbitmq-server should grow an > autopkgtest as that have would prevented the migration. What I should have said: we could have prevented migration of erlang until the reverse dependencies were ready by having an RC bug on erlang. That would have been totally appropriate if it would have lasted an reasonable time. I *think* rabbitmq-server has problems migrating now *because* erlang migrated, but that should clear up once the references are tested again. However, it *also* has issues with being uninstallable. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#993145: qemu-system-x86_64: ../../util/qemu-sockets.c:1348: socket_sockaddr_to_address_unix: Assertion `salen >= sizeof(su->sun_family) + 1 && salen <= sizeof(struct sockaddr_un)' failed.
Package: qemu-system-x86
Version: 1:6.1+dfsg-1
Severity: normal
A VM that I created with either virt-manager or virtinst sometime ago now
crashes when I attempt to start it under QEMU 6.1.
2021-08-27 20:12:17.236+: starting up libvirt version: 7.6.0, package: 1
(Andrea Bolognani Thu, 19 Aug 2021 21:16:21 +0200), qemu
version: 6.1.0Debian 1:6.1+dfsg-1, kernel: 5.13.0-trunk-amd64, hostname:
xps13.dannf
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin \
HOME=/var/lib/libvirt/qemu/domain-6-debian10 \
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain-6-debian10/.local/share \
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain-6-debian10/.cache \
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain-6-debian10/.config \
/usr/bin/qemu-system-x86_64 \
-name guest=debian10,debug-threads=on \
-S \
-object
'{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain-6-debian10/master-key.aes"}'
\
-machine
pc-q35-5.0,accel=kvm,usb=off,vmport=off,dump-guest-core=off,memory-backend=pc.ram
\
-cpu
Skylake-Client-IBRS,ss=on,vmx=on,pdcm=on,hypervisor=on,tsc-adjust=on,clflushopt=on,umip=on,md-clear=on,stibp=on,arch-capabilities=on,ssbd=on,xsaves=on,pdpe1gb=on,ibpb=on,ibrs=on,amd-stibp=on,amd-ssbd=on,skip-l1dfl-vmentry=on,pschange-mc-no=on,hle=off,rtm=off
\
-m 1024 \
-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":1073741824}' \
-overcommit mem-lock=off \
-smp 2,sockets=2,cores=1,threads=1 \
-uuid b1d79aa3-8f43-4f46-b7a4-8332543f320b \
-no-user-config \
-nodefaults \
-chardev socket,id=charmonitor,fd=39,server=on,wait=off \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot menu=on,strict=on \
-device
pcie-root-port,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2
\
-device pcie-root-port,port=0x11,chassis=2,id=pci.2,bus=pcie.0,addr=0x2.0x1 \
-device pcie-root-port,port=0x12,chassis=3,id=pci.3,bus=pcie.0,addr=0x2.0x2 \
-device pcie-root-port,port=0x13,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x3 \
-device pcie-root-port,port=0x14,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x4 \
-device pcie-root-port,port=0x15,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x5 \
-device pcie-root-port,port=0x16,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x6 \
-device pcie-root-port,port=0x17,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x7 \
-device pcie-pci-bridge,id=pci.9,bus=pci.8,addr=0x0 \
-device pcie-root-port,port=0x18,chassis=10,id=pci.10,bus=pcie.0,addr=0x3 \
-device qemu-xhci,p2=15,p3=15,id=usb,bus=pci.2,addr=0x0 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.3,addr=0x0 \
-blockdev
'{"driver":"file","filename":"/var/lib/libvirt/images/debian10.raw","node-name":"libvirt-3-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-3-format","read-only":false,"driver":"raw","file":"libvirt-3-storage"}'
\
-device
virtio-blk-pci,bus=pci.4,addr=0x0,drive=libvirt-3-format,id=virtio-disk0,bootindex=1
\
-blockdev
'{"driver":"file","filename":"/var/lib/libvirt/images/debian10-seed.img","node-name":"libvirt-2-storage","auto-read-only":true,"discard":"unmap"}'
\
-blockdev
'{"node-name":"libvirt-2-format","read-only":false,"driver":"raw","file":"libvirt-2-storage"}'
\
-device
virtio-blk-pci,bus=pci.7,addr=0x0,drive=libvirt-2-format,id=virtio-disk1 \
-device ide-cd,bus=ide.0,id=sata0-0-0 \
-netdev tap,fd=41,id=hostnet0,vhost=on,vhostfd=42 \
-device
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:XX:XX:XX:XX,bus=pci.1,addr=0x0
\
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev socket,id=charchannel0,fd=43,server=on,wait=off \
-device
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0
\
-device usb-tablet,id=input0,bus=usb.0,port=1 \
-audiodev id=audio1,driver=spice \
-vnc 127.0.0.1:0,audiodev=audio1 \
-spice port=5901,addr=127.0.0.1,disable-ticketing=on,seamless-migration=on \
-device
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,vgamem_mb=16,max_outputs=1,bus=pcie.0,addr=0x1
\
-device virtio-gpu-pci,id=video1,max_outputs=1,bus=pci.10,addr=0x0 \
-chardev spicevmc,id=charredir0,name=usbredir \
-device usb-redir,chardev=charredir0,id=redir0,bus=usb.0,port=2 \
-chardev spicevmc,id=charredir1,name=usbredir \
-device usb-redir,chardev=charredir1,id=redir1,bus=usb.0,port=3 \
-device virtio-balloon-pci,id=balloon0,bus=pci.5,addr=0x0 \
-object '{"qom-type":"rng-random","id":"objrng0","filename":"/dev/urandom"}' \
-device virtio-rng-pci,rng=objrng0,id=rng0,bus=pci.6,addr=0x0 \
-sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
-msg timestamp=on
char device redirected to /dev/pts/27 (label charserial0)
qemu-system-x86_64: ../../util/qemu-sockets.c:1348:
socket_sockaddr_to_address_unix: Assertion `salen >=
Bug#839082: RFA: netcf --cross-platform network configuration library
I suggest removing the netcf package because the libvirt package just dropped it as a dependency. That was the last reverse dependency. The package has not found an adopter for almost 5 years. On Mon, 03 Oct 2016 18:24:52 + Lorenzo Faletra wrote: Hi, i have seen that netcf is the latesr version available at fedorahosted.org/released/netcf i am not a debian maintainer yet mut i would like to adopt and monitor the package for updates. is there anything i can do to help you maintaining it in the future?
Bug#990305: Introduce ARC support in Perl cross-compiling for Debian
On Fri, Jun 25, 2021 at 08:59:44AM +, Evgeniy Didin wrote: > Package: perl > Version: 5.32.1-4 > > Currently ARC CPU is not supported in Perl cross-compiling for Debian due to > missing files in debian/cross/ directory. > To enable cross-compiling for ARC the patch was prepared and located here: > https://salsa.debian.org/EvgeniyD/perl/-/commit/b7a9cd6499a91b59585394b1cad10cbdbd4512a4 > > I am not attaching the patch to this report because the size is more than > thousand lines. > > I am using Debian GNU/Linux 9.13 release, kernel - 3.10.0-693.11.6.el7.x86_64 > > This patch was tested in rebootstrap build. Hi, thanks for the report. I'm happy if the cross build hack in src:perl is useful but I'm not quite sure what to do about this. Eyeballing the patch, I think that cross building with this config would result in a broken package due to at least missing -DDEBIAN in ccflags. Also, -DAPPLLIB_EXP="/usr/lib/aarch64-linux-gnu/perl-base" looks wrong, and possibly breaks the perl-base package when used without perl et al. I doubt these are the only problems. I assume "tested in rebootstrap build" means the package builds, but did anybody test the resulting packages? I'm copying Helmut. Do you have any suggestions? Should I just take this in and leave it to porters to worry about breakage? BTW, our development is currently targeting 5.34 so somebody needs to port this. I'm not sure if there will be another 5.32 upload before we get 5.34 in unstable. -- Niko Tyni nt...@debian.org
Bug#978858: libthai: diff for NMU version 0.1.28-4.1
Control: tags 978858 + patch Control: tags 978858 + pending Dear maintainer, I've prepared an NMU for libthai (versioned as 0.1.28-4.1) and uploaded it to DELAYED/5. Please feel free to tell me if I should delay it longer. Regards, Boyuan Yang diff -Nru libthai-0.1.28/debian/changelog libthai-0.1.28/debian/changelog --- libthai-0.1.28/debian/changelog 2021-03-03 04:35:57.0 -0500 +++ libthai-0.1.28/debian/changelog 2021-08-27 16:08:50.0 -0400 @@ -1,3 +1,12 @@ +libthai (0.1.28-4.1) unstable; urgency=high + + * Non-maintainer upload. + * d/p/0001-configure.ac-remove-duplicate-AC_CONFIG_MACRO_DIR.patch: +Add upstream patch to fix FTBFS against autoconf 2.70+. +(Closes: #978858) + + -- Boyuan Yang Fri, 27 Aug 2021 16:08:50 -0400 + libthai (0.1.28-4) unstable; urgency=medium [ Theppitak Karoonboonyanan ] diff -Nru libthai-0.1.28/debian/patches/0001-configure.ac-remove-duplicate- AC_CONFIG_MACRO_DIR.patch libthai-0.1.28/debian/patches/0001-configure.ac- remove-duplicate-AC_CONFIG_MACRO_DIR.patch --- libthai-0.1.28/debian/patches/0001-configure.ac-remove-duplicate- AC_CONFIG_MACRO_DIR.patch 1969-12-31 19:00:00.0 -0500 +++ libthai-0.1.28/debian/patches/0001-configure.ac-remove-duplicate- AC_CONFIG_MACRO_DIR.patch 2021-08-27 16:07:02.0 -0400 @@ -0,0 +1,27 @@ +From: Ross Burton +Date: Mon, 23 Mar 2020 21:51:31 + +Subject: configure.ac: remove duplicate AC_CONFIG_MACRO_DIR + +Autoconf 2.70 will fatally error out if AC_CONFIG_MACRO_DIR is called more than once: + +| configure.ac:25: error: AC_CONFIG_MACRO_DIR can only be used once + +Bug-Debian: https://bugs.debian.org/978858 +Applied-Upstream: https://github.com/tlwg/libthai/commit/764c1750c18fc3fe4005fcb5b912ce9e39bc2b7f +--- + configure.ac | 2 -- + 1 file changed, 2 deletions(-) + +diff --git a/configure.ac b/configure.ac +index 88275b4..4f5c258 100644 +--- a/configure.ac b/configure.ac +@@ -22,8 +22,6 @@ AC_SUBST(LT_CURRENT) + AC_SUBST(LT_REVISION) + AC_SUBST(LT_AGE) + +-AC_CONFIG_MACRO_DIR([m4]) +- + DOXYGEN_REQ_VER=1.8.8 + + dnl Checks for programs. diff -Nru libthai-0.1.28/debian/patches/series libthai- 0.1.28/debian/patches/series --- libthai-0.1.28/debian/patches/series1969-12-31 19:00:00.0 -0500 +++ libthai-0.1.28/debian/patches/series2021-08-27 16:07:02.0 -0400 @@ -0,0 +1 @@ +0001-configure.ac-remove-duplicate-AC_CONFIG_MACRO_DIR.patch signature.asc Description: This is a digitally signed message part
Bug#992609: careless upload of Erlang v24 without a transition tracking with the release team (was: rabbitmq-server fails to start after erlang v24 update)
Hi Antonio, Thomas, On 27-08-2021 21:58, Antonio Terceiro wrote: > One thing that happens when you do this type of change without > coordination is that all CI pipelines on unstable where rabbitmq-server > is installed are now broken. For example all merge requests against > debci at the moment have their tests in "failed" status. This creates > unnecessary noise for a lot of people. rabbitmq-server already got an update, so unstable should be fine (if not, shout (or better, file bugs)). I expect you mean testing, as I think that the point is that erlang already migrated before the issue was detected, otherwise an RC bug would have prevented the migration. That's why it was suggested earlier that rabbitmq-server should grow an autopkgtest as that have would prevented the migration. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#992609: careless upload of Erlang v24 without a transition tracking with the release team (was: rabbitmq-server fails to start after erlang v24 update)
On Sun, Aug 22, 2021 at 07:14:30PM +0300, Sergei Golovan wrote: > Hi Thomas, > > On Sun, Aug 22, 2021 at 6:55 PM Thomas Goirand wrote: > > > > Hi Damir, Sergei, the release team, > > > > First of all, thanks for your bug report, Damir. > > > > Debian Bullseye was released on the 14th of Aug. Then Erlang v24 was > > uploaded on the 17th. Looking at: > > > > https://release.debian.org/transitions/ > > > > I cannot see any transition thingy opened for Erlang. This means that > > Erlang was carelessly uploaded to Unstable: > > Uploading new major version of Erlang does not require a transition. > No application needs to be rebuilt against it, and only a minority > breaks (those which use removed deprecated features, and they have to > be updated or patched anyway). I'm sorry that elixir and rabbit-mq > break. > > > > > 1/ Without informing the release team, and defining a schedule for the > > Erlang transition > > I insist that a transition is not necessary. It's OK to break things, and you do not have to wait forever, but you need to give people enough time to react before the packages they work/depend on become instantly broken. One thing that happens when you do this type of change without coordination is that all CI pipelines on unstable where rabbitmq-server is installed are now broken. For example all merge requests against debci at the moment have their tests in "failed" status. This creates unnecessary noise for a lot of people. > > 2/ Without rebuilding any reverse dependency, and more specifically, > > without caring about RabbitMQ which is kind of a high profile server > > application. > > > > Now, we have Erlang v24 in Unstable which looks like a good target for > > RabbitMQ 3.9.4, however, this new version needs a new Elixir release, as > > it has a bound of ">= 1.10.4 and < 1.13.0". Elixir as in unstable (ie: > > 1.10.3) doesn't work, even when trying to convince RabbitMQ it's ok. > > Well, I would say that Elixir in Debian is not in a good shape. It > lags way behind upstream (which is already 1.12.2, quite a few > releases ahead). > > > > > There isn't much I can do now. I'm opening a bug against Elixir, and > > I'll have to wait for it to be solved... > > > > This isn't the first time something like this happen. Could we please > > bring some sanity in the way we do things? Sergei, could you please > > revert your upload of Erlang v24 in Unstable, and open a release team > > bug to get a transition tracker thingy, which is the only sane way to do > > things in Debian? > > > > Not amused... > > I've uploaded Erlang 24 to experimental months ago. If you know that > your software breaks on Erlang upgrade, you could do something > already. experimental is not a communication channel. You need to tell maintainers of your reverse dependencies that this breakage is coming via bug reports in advance, it's not reasonable to expect people to monitor experimental. signature.asc Description: PGP signature
Bug#993144: inetutils: Please package new version 2.1
Source: inetutils Version: 2:2.0-1 Severity: normal Control: tags -1 +bookworm Dear Debian inetutils maintainer, A new release of inetutils (v2.1) is available at https://ftp.gnu.org/gnu/inetutils/inetutils-2.1.tar.xz . Please consider packaging the new version. Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Bug#993134: buster-pu: package shiro/1.3.2-4+deb10u1
On Fri, Aug 27, 2021 at 08:33:44PM +0100, Adam D. Barratt wrote: > On Fri, 2021-08-27 at 13:45 -0400, Roberto C. Sanchez wrote: > > I have prepared an update for shiro in buster. This has been > > coordinated with the package maintainer and at the recommendation of > > the > > security team and with their concurrence, it is being proposed for > > the > > next buster point release. > > +shiro (1.3.2-4+deb10u1) buster; urgency=medium > + > + * Non-maintainer upload by the Security Team. > > fwiw, I at least find it a little confusing to have debdiffs claim to > be uploads by the Security Team when they were neither produced (so far > as I can tell) nor uploaded by that team, nor released via the security > archive. > Quite right. I originally prepared the uploads as security updates, but then changed course to the point release route. Would you like to REJECT the uploads and I can upload again with a fixed changelog? Regards, -Roberto -- Roberto C. Sánchez
Bug#993049: bullseye-pu: package rpki-trust-anchors/20210817-1+deb11u1
Control: tags -1 + confirmed On Fri, 2021-08-27 at 00:23 +0200, Marco d'Itri wrote: > rpki-trust-anchors is a data package containing public keys, similar > to > dns-root-data, which are used by RPKI validators (cfrpki, > fort-validator, rpki-client, stayrtr). > A stable update is needed because an https URL was finally added to > the > LACNIC trust anchor. This allows the software currently in stable to > use > https to download the certificates instead of the problematic and > deprecated rsync method. > Also, the same package from testing which I have rebuilt here gained > a new debconf translation. +rpki-trust-anchors (20210817-1+deb11u1) bullseye; urgency=medium + + * Rebuilt for the stable distribution. + + -- Marco d'Itri Fri, 27 Aug 2021 00:21:41 +0200 + +rpki-trust-anchors (20210817-1) unstable; urgency=medium The version number for a stable upload needs to be lower than the version currently in unstable. As a no-change rebuild, the convention would be 20210817-1~deb11u1, in the same style as backports. With that change in mind, please go ahead. Regards, Adam
Bug#993143: kconfig-frontends FTBFS: autoreconf: error: cannot create scripts/.autostuff/scripts: No such file or directory
Source: kconfig-frontends Version: 4.11.0.1+dfsg-5 Severity: serious Tags: ftbfs kconfig-frontends fails to build from source in unstable. A build ends with: |dh_autoreconf | aclocal: warning: couldn't open directory 'scripts/.autostuff/m4': No such file or directory | autoreconf: error: cannot create scripts/.autostuff/scripts: No such file or directory | libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'scripts/.autostuff/scripts'. | libtoolize: copying file 'scripts/.autostuff/scripts/ltmain.sh' | libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'scripts/.autostuff/m4'. | libtoolize: copying file 'scripts/.autostuff/m4/libtool.m4' | libtoolize: copying file 'scripts/.autostuff/m4/ltoptions.m4' | libtoolize: copying file 'scripts/.autostuff/m4/ltsugar.m4' | libtoolize: copying file 'scripts/.autostuff/m4/ltversion.m4' | libtoolize: copying file 'scripts/.autostuff/m4/lt~obsolete.m4' | configure.ac:210: warning: AC_PROG_LEX without either yywrap or noyywrap is obsolete | ./lib/autoconf/programs.m4:716: _AC_PROG_LEX is expanded from... | ./lib/autoconf/programs.m4:709: AC_PROG_LEX is expanded from... | configure.ac:210: the top level | configure.ac:36: installing 'scripts/.autostuff/scripts/ar-lib' | configure.ac:36: installing 'scripts/.autostuff/scripts/compile' | configure.ac:38: installing 'scripts/.autostuff/scripts/config.guess' | configure.ac:38: installing 'scripts/.autostuff/scripts/config.sub' | configure.ac:23: installing 'scripts/.autostuff/scripts/install-sh' | configure.ac:23: installing 'scripts/.autostuff/scripts/missing' | Makefile.am: installing 'scripts/.autostuff/scripts/depcomp' | configure.ac: installing 'scripts/.autostuff/scripts/ylwrap' | dh_autoreconf: error: autoreconf -f -i returned exit code 1 | make: *** [debian/rules:6: build] Error 25 | dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 Helmut
Bug#993142: ITP: flake8-comprehensions -- flake8 plugin that helps you write better list/set/dict comprehensions.
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: flake8-comprehensions Version : 3.6.1 Upstream Author : Adam Johnson * URL : https://github.com/adamchainz/flake8-comprehensions * License : MIT Programming Lang: Python Description : flake8 plugin that helps you write better list/set/dict comprehensions. Package adds check for the flake8 linter related to list/set/dict comprehensions. Examples are: Unnecessary generator, Unnecessary list comprehension, Unnecessary call, etc.
Bug#993141: simple-cdd: default.downloads is missing packages used by debian-installer
Package: simple-cdd Version: 0.6.8 Severity: important User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: raph...@offensive-security.com, debian...@lists.debian.org While diagnosing a failure to boot an encryted install, I discovered that simple-cdd was not properly adding cryptsetup-initramfs and I fixed that directly: https://salsa.debian.org/debian/simple-cdd/-/commit/eb0d1d8960e22dd1c087b15a505b1503d76088a3 FWIW, I fixed a similar issue in debian-cd: https://salsa.debian.org/images-team/debian-cd/-/commit/8d2bd4aa2e29fedbf9e224e6ce56bb6feae2b36a However when I analyzed debian-cd's sort_deps.amd64.log I noticed that the mirror generated by simple-cdd is lacking other packages that debian-cd tries to include for the benefits of debian-installer with multiple lines like those: WARNING: 'cryptsetup-initramfs' does not appear to be available ... (ignored) Among the missing packages I believe you might want to add those: - pcmciautils - discover - dosfstools - btrfs-progs - open-iscsi - multipath-tools-boot - wireless-tools - ppp - pppoeconf - pptp-linux - wpasupplicant - rdnssd - installation-report - alsa-utils - brltty - espeakup - grub-efi-amd64-signed - shim-signed The following are also reported as missing but they no longer exist in unstable so they are not really relevant: - btrfs-tools - ufsutils - zfsutils - loop-aes-utils - apt-transport-https - linux-image-2.6-amd64 Those might be candidates to be dropped from debian-cd's listings? (cc to debian...@lists.debian.org) -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages simple-cdd depends on: ii dctrl-tools 2.24-3+b1 ii debian-cd 3.1.35 ii lsb-release 11.1.0 ii python3 3.9.2-3 ii python3-simple-cdd 0.6.8 ii reprepro5.3.0-1.2 ii rsync 3.2.3-4 ii wget1.21-1+b1 Versions of packages simple-cdd recommends: ii dose-distcheck 6.0.1-2 Versions of packages simple-cdd suggests: ii qemu-system-x86 [qemu-kvm] 1:5.2+dfsg-11 -- no debconf information -- Raphaël Hertzog
Bug#993134: buster-pu: package shiro/1.3.2-4+deb10u1
On Fri, 2021-08-27 at 13:45 -0400, Roberto C. Sanchez wrote: > I have prepared an update for shiro in buster. This has been > coordinated with the package maintainer and at the recommendation of > the > security team and with their concurrence, it is being proposed for > the > next buster point release. +shiro (1.3.2-4+deb10u1) buster; urgency=medium + + * Non-maintainer upload by the Security Team. fwiw, I at least find it a little confusing to have debdiffs claim to be uploads by the Security Team when they were neither produced (so far as I can tell) nor uploaded by that team, nor released via the security archive. Regards, Adam
Bug#986527: Patches for flaky build and cython unavailability
I started updating sagemath to version 9.4, which is the first version that supports pari 2.13 (which is already in Debian and causes a large part of the failing doctests). I got stuck for now because we need an update of singular (see #992003). Best, Tobias On 8/27/21 7:37 PM, Paul Gevers wrote: > Hi, > > Just for the record, I did a rebuild of the package for two transitions > that are ongoing, and it failed on all architectures. > > Paul >
Bug#993139: ITP: flake8-class-newline -- flake8 Extension to lint for a method newline after a Class definition
Package: wnpp Severity: wishlist Owner: Jose Luis Rivero X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: flake8-class-newline Version : 1.6.0 Upstream Author : Alexander van Eck * URL : https://github.com/AlexanderVanEck/flake8-class-newline * License : MIT Programming Lang: Python Description : flake8 Extension to lint for a method newline after a Class definition flake8 Extension to lint for a method newline after a Class definition PEP8 says we should surround every class method with a single blank line. See https://www.python.org/dev/peps/pep-0008/#blank-lines However flake8 is ambiguous about the first method having a blank line above it. This plugin was made to enforce the blank line just after the method declaration.
Bug#993138: rabbitmq-server: uninstallable - typo in Depends: ?
On Fri, Aug 27, 2021 at 03:40:55PM -0300, Antonio Terceiro wrote: > Package: rabbitmq-server > Version: 3.8.9-3 Messed up the version, already fixed in a separate control message. This applies only to 3.9.4-1 (currently in sid) signature.asc Description: PGP signature
Bug#993138: rabbitmq-server: uninstallable - typo in Depends: ?
Package: rabbitmq-server Version: 3.8.9-3 Severity: serious Tags: patch Justification: Policy 3.5 Dear Maintainer, 8<8<8<- root@a3ed993375fb:/# apt update && apt install rabbitmq-server Get:1 http://deb.debian.org/debian sid InRelease [165 kB] Get:2 http://deb.debian.org/debian sid/main amd64 Packages [8778 kB] Fetched 8944 kB in 7s (1283 kB/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done 36 packages can be upgraded. Run 'apt list --upgradable' to see them. Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: rabbitmq-server : Depends: erlang-crypto (>= 1:24.4) but it is not going to be installed Depends: erlang-eldap (>= 1:24.4) but it is not going to be installed Depends: erlang-inets (>= 1:24.4) but it is not going to be installed Depends: erlang-mnesia (>= 1:24.4) but it is not going to be installed Depends: erlang-os-mon (>= 1:24.4) but it is not going to be installed Depends: erlang-parsetools (>= 1:24.4) but it is not going to be installed Depends: erlang-public-key (>= 1:24.4) but it is not going to be installed Depends: erlang-runtime-tools (>= 1:24.4) but it is not going to be installed Depends: erlang-ssl (>= 1:24.4) but it is not going to be installed Depends: erlang-syntax-tools (>= 1:24.4) but it is not going to be installed Depends: erlang-tools (>= 1:24.4) but it is not going to be installed Depends: erlang-xmerl (>= 1:24.4) but it is not going to be installed E: Unable to correct problems, you have held broken packages. 8<8<8<- ISTM that the version constraint in Depends: has a typo (24.4 when it should be 24.0). I'm about to upload the attached patch as this is currently breaking debci salsa CI. -- System Information: Debian Release: 11.0 APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=pt_BR:pt:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rabbitmq-server depends on: ii adduser 3.118 ii erlang-base 1:24.0.5+dfsg-2 ii erlang-crypto 1:24.0.5+dfsg-2 ii erlang-eldap 1:24.0.5+dfsg-2 ii erlang-inets 1:24.0.5+dfsg-2 ii erlang-mnesia 1:24.0.5+dfsg-2 ii erlang-os-mon 1:24.0.5+dfsg-2 ii erlang-parsetools 1:24.0.5+dfsg-2 ii erlang-public-key 1:24.0.5+dfsg-2 ii erlang-runtime-tools 1:24.0.5+dfsg-2 ii erlang-ssl1:24.0.5+dfsg-2 ii erlang-syntax-tools 1:24.0.5+dfsg-2 ii erlang-tools 1:24.0.5+dfsg-2 ii erlang-xmerl 1:24.0.5+dfsg-2 ii locales-all 2.31-13 ii logrotate 3.18.1-2 ii lsb-base 11.1.0 ii python3 3.9.2-3 ii socat 1.7.4.1-3 rabbitmq-server recommends no packages. rabbitmq-server suggests no packages. -- no debconf information From 7b61f0cf4d0f7bf262fea90370442c5edbae0e24 Mon Sep 17 00:00:00 2001 From: Antonio Terceiro Date: Fri, 27 Aug 2021 15:33:04 -0300 Subject: [PATCH] Depends: fix typo in erlang version --- debian/changelog | 8 debian/control | 24 2 files changed, 20 insertions(+), 12 deletions(-) diff --git a/debian/changelog b/debian/changelog index 98cf24c..5f04ea8 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +rabbitmq-server (3.9.4-1.1) unstable; urgency=medium + + * Non-maintainer upload. + * Depends: fix typo in erlang version that makes rabbitmq-server +uninstallable (s/1:24.4/1:24.0/) + + -- Antonio Terceiro Fri, 27 Aug 2021 15:30:41 -0300 + rabbitmq-server (3.9.4-1) unstable; urgency=medium * New upstream release: diff --git a/debian/control b/debian/control index 4c2e509..0d27b1a 100644 --- a/debian/control +++ b/debian/control @@ -46,18 +46,18 @@ Architecture: all Depends: adduser, erlang-base | erlang-base-hipe, - erlang-crypto (>= 1:24.4), - erlang-eldap (>= 1:24.4), - erlang-inets (>= 1:24.4), - erlang-mnesia (>= 1:24.4), - erlang-os-mon (>= 1:24.4), -
Bug#986527: Patches for flaky build and cython unavailability
Hi, Just for the record, I did a rebuild of the package for two transitions that are ongoing, and it failed on all architectures. Paul OpenPGP_signature Description: OpenPGP digital signature
Bug#993137: Always opens files in separate application instances when it shouldn't
Package: nautilus
Version: 3.38.2-1
Tags: patch
Severity: important
Justification: breaks common usage patterns and standards compliance
Dear maintainers,
I've found that Nautilus always opens each selected file in a separate
application instance even though the latter's desktop file Exec record
contains %F or %U. This leads to the following issues.
1. This behavior breaks a common usage pattern when user selects
multiple files and wants to open them in a single application.
For example:
* User wants to watch selected video files.
With Nautilus 3.38, only one of them ends up in the play queue of
GNOME's default video player (Totem) because opening each application
instance overwrites the queue.
It is even worse when using a player which allows simultanious
instances leading to multiple videos playing at once.
Same with audio files.
* User wants to view selected images.
With current behavior, each image opens in a separate Eye of GNOME
window instead of opening the first one in a single window and cycling
through the other ones.
2. Current behavior doesn't meet the Freedesktop.org desktop files
standard[1].
3. As explained in the upstream bug report[2], this annoying behavior
was introduced for development testing purposes only:
"This was introduced to ensure compatibility with Flatpak. At the time
there was no API to allow grouping files by their type or somesuch and
opening them all at once."
"It has nothing to do with how many users use "flatpaks". It's about
using nautilus in a Flatpak. Which only developers do as nautilus is
not meant to be used as a sandboxed application, but as a system
application."
So this change was introduced for development testing purposes only,
and Nautilus is not and never meant to be used sandboxed by end user.
At the same time, this change breaks common usage patterns for people
who are not Nautilus developers i.e. an overwhelming majority of users.
4. This problematic change was reverted in a subsequent MR[3] which
unfortunately didn't make it into version 3.38.
Given all above, could you consider backporting the fix into Nautilus
in Debian 11 (stable), please? The patch in question, available for
download from the aforementioned MR, applies cleanly to the version in
stable and works flawlessly, providing both the correct behavior for
end users *and* Flatpak support.
The patch is also attached to this message for your convenience.
[1]
https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s07.html
[2] https://gitlab.gnome.org/GNOME/nautilus/-/issues/117
[3] https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/518
--
Regards,
Алексей Шилин
diff --git a/src/nautilus-mime-actions.c b/src/nautilus-mime-actions.c
index 1a3abff387b19c82e37d2c4179e3a62e033f3438..ecccd8efcddc93d7b1169fab0fee5d1d6a154446 100644
--- a/src/nautilus-mime-actions.c
+++ b/src/nautilus-mime-actions.c
@@ -60,6 +60,12 @@ typedef struct
char *uri;
} LaunchLocation;
+typedef struct
+{
+GAppInfo *application;
+GList *uris;
+} ApplicationLaunchParameters;
+
typedef struct
{
NautilusWindowSlot *slot;
@@ -83,8 +89,7 @@ typedef struct
{
ActivateParameters *activation_params;
GQueue *uris;
-GQueue *unhandled_uris;
-} ApplicationLaunchParameters;
+} ApplicationLaunchAsyncParameters;
/* Microsoft mime types at https://blogs.msdn.microsoft.com/vsofficedeveloper/2008/05/08/office-2007-file-format-mime-types-for-http-content-streaming-2/ */
struct
@@ -239,6 +244,20 @@ static void activate_callback (GList *files,
gpointer callback_data);
static void activation_mount_not_mounted (ActivateParameters *parameters);
+static gboolean
+is_sandboxed (void)
+{
+static gboolean ret;
+
+static gsize init = 0;
+if (g_once_init_enter ())
+{
+ret = g_file_test ("/.flatpak-info", G_FILE_TEST_EXISTS);
+g_once_init_leave (, 1);
+}
+
+return ret;
+}
static void
launch_location_free (LaunchLocation *location)
@@ -340,19 +359,27 @@ launch_locations_from_file_list (GList *list)
}
static ApplicationLaunchParameters *
-application_launch_parameters_new (ActivateParameters *activation_params,
- GQueue *uris)
+application_launch_parameters_new (GAppInfo *application,
+ GList*uris)
{
ApplicationLaunchParameters *result;
result = g_new0 (ApplicationLaunchParameters, 1);
-result->activation_params = activation_params;
-result->uris = uris;
-result->unhandled_uris = g_queue_new ();
+result->application = g_object_ref (application);
+result->uris = g_list_copy_deep (uris, (GCopyFunc) g_strdup, NULL);
return result;
}
+static void
Bug#993136: automake's autopkg tests are failing with autoconf 2.71
Package: src:automake-1.16 Version: 1:1.16.3-2 Severity: serious Tags: sid bookworm automake's autopkg tests are failing with autoconf 2.71, blocking the autoconf migration to testing. FAIL: t/deprecated-acinit.sh FAIL: t/init.sh https://ci.debian.net/packages/a/automake-1.16/testing/amd64/
Bug#993135: inetutils autopkg tests fail with autoconf 2.71
Package: src:inetutils Version: 2:2.0-1 Severity: serious Tags: sid bookworm inetutils autopkg tests fail with autoconf 2.71, blocking the autoconf migration to testing. https://ci.debian.net/packages/i/inetutils/testing/amd64/ autopkgtest [01:15:10]: test test-root-commands: - - - - - - - - - - results - - - - - - - - - - test-root-commands FAIL stderr: configure.ac:230: warning: The macro `AC_TRY_LINK' is obsolete. autopkgtest [01:15:10]: test test-root-commands: - - - - - - - - - - stderr - - - - - - - - - - configure.ac:230: warning: The macro `AC_TRY_LINK' is obsolete. configure.ac:230: You should run autoupdate. ./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from... am/libcurses.m4:163: IU_LIB_CURSES is expanded from... configure.ac:230: the top level configure.ac:356: warning: The macro `AC_TRY_LINK' is obsolete. configure.ac:356: You should run autoupdate. ./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from... am/krb5.m4:33: IU_CHECK_KRB5 is expanded from... configure.ac:356: the top level configure.ac:594: warning: The macro `AC_TRY_LINK' is obsolete. configure.ac:594: You should run autoupdate. ./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from... configure.ac:594: the top level configure.ac:615: warning: The macro `AC_HEADER_STDC' is obsolete. configure.ac:615: You should run autoupdate. ./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from... configure.ac:615: the top level configure.ac:616: warning: The macro `AC_HEADER_TIME' is obsolete. configure.ac:616: You should run autoupdate. ./lib/autoconf/headers.m4:743: AC_HEADER_TIME is expanded from... configure.ac:616: the top level configure.ac:656: warning: The macro `AC_TYPE_SIGNAL' is obsolete. configure.ac:656: You should run autoupdate. ./lib/autoconf/types.m4:776: AC_TYPE_SIGNAL is expanded from... configure.ac:656: the top level configure.ac:767: warning: The macro `AC_TRY_LINK' is obsolete. configure.ac:767: You should run autoupdate. ./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from... am/check_weak_refs.m4:31: IU_CHECK_WEAK_REFS is expanded from... configure.ac:767: the top level configure.ac:771: warning: The macro `AC_FUNC_SETVBUF_REVERSED' is obsolete. Remove it and all references to SETVBUF_REVERSED. ./lib/autoconf/functions.m4:1766: AC_FUNC_SETVBUF_REVERSED is expanded from... configure.ac:771: the top level configure.ac:904: warning: The macro `AC_DECL_SYS_SIGLIST' is obsolete. configure.ac:904: You should run autoupdate. ./lib/autoconf/specific.m4:40: AC_DECL_SYS_SIGLIST is expanded from... configure.ac:904: the top level configure.ac:956: warning: The macro `AC_TRY_COMPILE' is obsolete. configure.ac:956: You should run autoupdate. ./lib/autoconf/general.m4:2847: AC_TRY_COMPILE is expanded from... configure.ac:956: the top level autopkgtest [01:15:10]: summary test-commandsFAIL stderr: configure.ac:230: warning: The macro `AC_TRY_LINK' is obsolete. test-root-commands FAIL stderr: configure.ac:230: warning: The macro `AC_TRY_LINK' is obsolete.
Bug#993115: [Pkg-utopia-maintainers] Bug#993115: firewalld: missing test dependencies
Control: tags -1 + moreinfo Am 27.08.21 um 15:46 schrieb Gianfranco Costamagna: Source: firewalld Version: 1.0.1-1 Severity: serious tags: patch Hello, looks some tests needs nftables and ipset installed inside the chroot the following patch makes them pass all. diff -Nru firewalld-1.0.1/debian/tests/control firewalld-1.0.1/debian/tests/control --- firewalld-1.0.1/debian/tests/control2021-08-17 23:25:15.0 +0200 +++ firewalld-1.0.1/debian/tests/control2021-08-27 15:16:04.0 +0200 @@ -3,6 +3,7 @@ ipset, libglib2.0-bin, libxml2-utils, + nftables, Restrictions: needs-root, isolation-machine Tests: integration-tests @@ -10,6 +11,8 @@ network-manager, sudo, policykit-1, + nftables, + ipset Restrictions: needs-root, isolation-machine Tests: smoke I know Debian infrastructure doesn't support isolation-machine (yet), so I'm not totally confident about the severity of this bug, but since its trivial to fix, better fix it and leave autopkgtests to user working. I did run the autopkgtest suite before uploading (log attached), so I'm surprised it fails for you. Can you send me your autopkgtest log? Michael autopkgtest [17:19:19]: starting date: 2021-08-27 autopkgtest [17:19:19]: version 5.16 autopkgtest [17:19:19]: host pluto; command line: /usr/bin/autopkgtest -o logs-qemu firewalld -- qemu /mnt/share/chroot/autopkgtest-sid.img qemu-system-x86_64: warning: 9p: degraded performance: a reasonable high msize should be chosen on client/guest side (chosen msize is <= 8192). See https://wiki.qemu.org/Documentation/9psetup#msize for details. autopkgtest [17:19:31]: testbed dpkg architecture: amd64 autopkgtest [17:19:33]: testbed running kernel: Linux 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) autopkgtest [17:19:34]: apt-source firewalld Get:1 http://deb.debian.org/debian sid/main firewalld 1.0.1-1 (dsc) [2405 B] Get:2 http://deb.debian.org/debian sid/main firewalld 1.0.1-1 (tar) [2041 kB] Get:3 http://deb.debian.org/debian sid/main firewalld 1.0.1-1 (diff) [9460 B] gpgv: unknown type of key resource 'trustedkeys.kbx' gpgv: keyblock resource '/tmp/dpkg-verify-sig.DC1QbOoT/trustedkeys.kbx': General error gpgv: Signature made Tue Aug 17 21:36:10 2021 UTC gpgv:using RSA key 09B3AC2ECB169C904345CC546AE1DF0D608F22DC gpgv: Can't check signature: No public key dpkg-source: warning: failed to verify signature on ./firewalld_1.0.1-1.dsc autopkgtest [17:19:44]: testing package firewalld version 1.0.1-1 autopkgtest [17:19:44]: build not needed autopkgtest [17:19:45]: test standard-tests: preparing testbed Reading package lists... Building dependency tree... Reading state information... Correcting dependencies...Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done Done Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done The following additional packages will be installed: firewalld firewalld-tests gir1.2-glib-2.0 gir1.2-nm-1.0 ipset iptables libgirepository-1.0-1 libglib2.0-0 libglib2.0-bin libglib2.0-data libicu67 libip6tc2 libipset13 libmpdec3 libnetfilter-conntrack3 libnfnetlink0 libnm0 libpolkit-agent-1-0 libpolkit-gobject-1-0 libpython3-stdlib libpython3.9-stdlib libxml2 libxml2-utils media-types policykit-1 python3 python3-dbus python3-firewall python3-gi python3-nftables python3.9 Suggested packages: python3-doc python3-tk python3-venv python-dbus-doc python3-dbus-dbg python3.9-venv python3.9-doc Recommended packages: python3-cap-ng shared-mime-info xdg-user-dirs ca-certificates The following NEW packages will be installed: firewalld firewalld-tests gir1.2-glib-2.0 gir1.2-nm-1.0 ipset iptables libgirepository-1.0-1 libglib2.0-0 libglib2.0-bin libglib2.0-data libicu67 libip6tc2 libipset13 libmpdec3 libnetfilter-conntrack3 libnfnetlink0 libnm0 libpolkit-agent-1-0 libpolkit-gobject-1-0 libpython3-stdlib libpython3.9-stdlib libxml2 libxml2-utils media-types policykit-1 python3 python3-dbus python3-firewall python3-gi python3-nftables python3.9 0 upgraded, 31 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. Need to get 17.1 MB of archives. After this operation, 82.7 MB of additional disk space will be used. Get:1 http://deb.debian.org/debian sid/main amd64 libglib2.0-0 amd64 2.68.4-1 [1390 kB] Get:2 http://deb.debian.org/debian sid/main amd64 libgirepository-1.0-1 amd64 1.68.0-2 [96.8 kB] Get:3 http://deb.debian.org/debian sid/main amd64 gir1.2-glib-2.0 amd64 1.68.0-2 [152 kB] Get:4 http://deb.debian.org/debian sid/main amd64 libnm0 amd64 1.30.6-1 [447 kB] Get:5 http://deb.debian.org/debian sid/main amd64 gir1.2-nm-1.0 amd64 1.30.6-1 [102 kB] Get:6 http://deb.debian.org/debian sid/main amd64 libip6tc2 amd64 1.8.7-1 [35.0 kB] Get:7 http://deb.debian.org/debian
Bug#992798:
Thanks for providing the MR, Michael, There's just one thing missing so the MR can close this bugreport; it needs to drop the shellcheck autopkgtest. Would you like to amend this change to your MR? Thanks, -- Samuel Henrique
Bug#954093: desktop-base: Integration with KDE Plasma on Debian 11 no longer works
Sorry to spam everyone, but does anybody know how I unsubscribe from these lists? Thanks Simon -Original Message- From: Lisandro Damián Nicanor Pérez Meyer Sent: Friday, 27 August 2021 14:27 To: Cyril Brulebois ; Aurélien COUDERC Cc: Laura Arjona Reina ; 954...@bugs.debian.org; Debian KDE ML Subject: Re: Bug#954093: desktop-base: Integration with KDE Plasma on Debian 11 no longer works Hi! On Fri, 6 Aug 2021 at 10:32, Cyril Brulebois wrote: > loop += debian-kde@ in case they can offer some help regarding this > issue which affects their desktop environment. I have never digged into this, so I am CCing Aurélien who did the code. What I do see is that the code will only try to set the theme if the user has the default theme in use, and that's something we always tried to keep. Now the code seems to only handle the wallpaper, I don't know if we currently have the manpower to do better. -- Lisandro Damián Nicanor Pérez Meyer https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fperezmeyer.com.ar%2Fdata=04%7C01%7Csimon.jaynes%40bt.com%7C7582e183e15c43c3bd3e08d9695e6865%7Ca7f356889c004d5eba4129f146377ab0%7C0%7C0%7C637656676469607803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=Ij3AUh8Hzyn4pD0gaQ8LSE53qpzv4eeuTx9vhHuz5xY%3Dreserved=0
Bug#993132: python3-fife: prints "is"/"is not" used-with-a-literal warnings at install time
Package: python3-fife Version: 0.4.2-3 Severity: normal Dear Maintainer, When I installed python3-fife as a dependency from another package, I saw the following printed in the console: Setting up python3-fife (0.4.2-3) ... /usr/lib/python3/dist-packages/fife/extensions/fife_settings.py:301: SyntaxWarning: "is not" with a literal. Did you mean "!="? if module is not "FIFE": /usr/lib/python3/dist-packages/fife/extensions/fife_settings.py:435: SyntaxWarning: "is" with a literal. Did you mean "=="? if module is "FIFE": /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/animationicon.py:193: SyntaxWarning: "is not" with a literal. Did you mean "!="? if anim is not "": /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/curvegraph.py:164: SyntaxWarning: "is" with a literal. Did you mean "=="? if coordinates is None or len(coordinates) is 0: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/linegraph.py:157: SyntaxWarning: "is" with a literal. Did you mean "=="? if coordinates is None or len(coordinates) is 0: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/pointgraph.py:157: SyntaxWarning: "is" with a literal. Did you mean "=="? if coordinates is None or len(coordinates) is 0: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1038: SyntaxWarning: "is" with a literal. Did you mean "=="? if len(margin) is 4: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1044: SyntaxWarning: "is" with a literal. Did you mean "=="? elif len(margin) is 3: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1050: SyntaxWarning: "is" with a literal. Did you mean "=="? elif len(margin) is 2: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1056: SyntaxWarning: "is" with a literal. Did you mean "=="? elif len(margin) is 1: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1068: SyntaxWarning: "is" with a literal. Did you mean "=="? if len(padding) is 4: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1074: SyntaxWarning: "is" with a literal. Did you mean "=="? elif len(padding) is 3: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1080: SyntaxWarning: "is" with a literal. Did you mean "=="? elif len(padding) is 2: /usr/lib/python3/dist-packages/fife/extensions/pychan/widgets/widget.py:1086: SyntaxWarning: "is" with a literal. Did you mean "=="? elif len(padding) is 1: /usr/lib/python3/dist-packages/fife/extensions/serializers/xmlmap.py:640: SyntaxWarning: "is not" with a literal. Did you mean "!="? if data['s_ref'] is not -1: /usr/lib/python3/dist-packages/fife/extensions/serializers/xmlmap.py:663: SyntaxWarning: "is not" with a literal. Did you mean "!="? if data['s_ref'] is not -1: /usr/lib/python3/dist-packages/fife/extensions/serializers/xmlmap.py:686: SyntaxWarning: "is not" with a literal. Did you mean "!="? if data['s_ref'] is not -1: /usr/lib/python3/dist-packages/fife/extensions/serializers/xmlmapsaver.py:301: SyntaxWarning: "is not" with a literal. Did you mean "!="? if info.getSubdivisions() is not 32: Setting up unknown-horizons (2019.1-3) ... /usr/lib/python3/dist-packages/horizons/extscheduler.py:72: SyntaxWarning: "is" with a literal. Did you mean "=="? if obj.loops > 0 or obj.loops is -1: I'm not sufficiently familiar with either the language or the codebase to be sure about whether these represent harmless warnings (in which case this bug should be "minor") or could produce actual unintended behavior, although I think the former is more likely; however, either way, having this output appear isn't the best user-facing appearance. Please adjust the package such that this type of output does not appear at the point of package installation. -- System Information: Debian Release: 11.0 APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (500, 'testing-debug'), (500, 'stable-security') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/12 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages python3-fife depends on: ii libboost-filesystem1.74.0 1.74.0-9 ii libc6 2.31-13 ii libfifechan0.1.5 0.1.5-2 ii libgcc-s1 10.2.1-6 ii libgl1 1.3.2-1 ii libglew2.1 2.1.0-4+b1 ii libopenal1 1:1.19.1-2 ii libpng16-161.6.37-3 ii libpython3.9 3.9.2-1 ii libsdl2-2.0-0 2.0.14+dfsg2-3 ii libsdl2-image-2.0-02.0.5+dfsg1-2 ii libsdl2-ttf-2.0-0 2.0.15+dfsg1-1 ii libstdc++6 10.2.1-6 ii libtinyxml2.6.2v5 2.6.2-4 ii libvorbisfile3 1.3.7-1 ii python33.9.2-3 ii
Bug#993131: webext-keepassxc-browser: Chromium error: "Failed to load extension from: . Manifest file is missing or unreadable"
Package: webext-keepassxc-browser Version: 1.7.9.1+repack1-2 Severity: normal Tags: upstream X-Debbugs-Cc: li...@ndmnet.eu Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages webext-keepassxc-browser depends on: ii keepassxc 2.6.2+dfsg.1-1 Versions of packages webext-keepassxc-browser recommends: ii chromium 90.0.4430.212-1 ii firefox-esr 78.13.0esr-1~deb11u1 webext-keepassxc-browser suggests no packages.
Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used
The documentation is definitely lacking - I've been trying to work out why my configuration broke since upgrading to Buster 3 months ago! Even with the loglevel set to "debug", the logs were utterly unhelpful. Let's Encrypt is the most popular source of signed certificates and the upstream documentation at https://www.cups.org/doc/encryption.html explicitly says: "CUPS also supports certificates created and managed by the popular Let's Encrypt certificate service, which are stored in the /etc/letsencrypt/live directory."
Bug#991025: merkaartor build depends on both libqt5webkit5-dev and qtwebengine5-dev but uses neither
Hello Bas, thanks for letting me know that version 0.19 is now out. I will package it by the week-end. Best wishes, Jerome On 27/08/2021 17:34, Sebastiaan Couwenberg wrote: Jérôme, Are you going to fix this issue and the related issue about not migrating to testing (#993126), e.g. while packaging the 0.19.0 release? If not, merkaartor will be removed from Debian again. Kind Regards, Bas -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B OpenPGP_signature Description: OpenPGP digital signature
Bug#993130: sensible-editor: 31: Maximum function recursion depth (1000) reached
Package: sensible-utils Version: 0.0.16 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 $ dch -i -D unstable /usr/bin/sensible-editor: 31: Maximum function recursion depth (1000) reached dch: fatal error at line 1742: Error editing debian/changelog $ env | grep -i -e editor -e visual EDITOR=nano VISUAL=nano - -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (900, 'unstable') Architecture: i386 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en Shell: /bin/sh linked to /bin/dash Init: unable to detect - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEyJACx3qL7GpObXOQrh+Cd8S017YFAmEpDPIACgkQrh+Cd8S0 17Zxig//R9X9Hc4kvQmZkawtE5cQ9RRONUmvxxtUnjdpnEGd0D2d/ctoCuCbkYW7 8nZsHsAHFXtLwNGMG9n8BKPPd84O+QU+HpEayK6qMWt8IsYIk88oW+el2tNBEgqD 03ZLXly+DQeC7FV+O6RsY4KKRt6/iN4kmavmrw4ELAU3W7TXglA+/ploKZWEJOrn 8IYTMDQpcWngcRqHzBZ/IySEo6xm3fJsrTbuKxCNN1ufXBmUk06aCWB8dNA8nz6S VTAHSC6fEeahB5zt1//3i4ZisrU3dtukbkAtXw+EemkeXH400teggJT/1nXniKSM stTNhqFDOywWun8VgDPdOTMp4S+T1jDlXx+nVDbAahdZM30HiAjMoQ9ulr89pxRR Et4BXWhZ4PnEy179PZfv1x7Vj/9xPt35V0tBUMy/9V4DJkYdaKkxNIMo7ISPZmue y3ZS8xv9gf0mt+Wmvr5XlPJessFCIqFF0xmN0sBzKyRyTKAiWpYn3x/gq+DQyhZH +8EpImuOSPwX/IxcT2ARFpEYiDEg8dbPNIrz01jTELXCUo/idyoZuO8eTyAj/FJP JExJDUjWAJ6CQaUqWCQCFHxy/d7/QXLM4oBIrgBAWj9LywRO+SCZEKUJfsxEczLX krD1n93AtoIPO+UlFwUl8+tf35S+yfIaoX3Q8IWp0Y6d3nGLj6o= =wOVm -END PGP SIGNATURE-
Bug#993129: redis-tools 3:3.2.6-3+deb9u6 has broken dependencies
Package: redis-tools Version: 3:3.2.6-3+deb9u5 Severity: grave Justification: renders package unusable Dear Maintainer, * What led up to the situation? Attempting norma apt upgrade attempts to update redis-tools, but requires newer libc and libjemalloc2 which isn't present in strech * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? apt is in a broken state * What outcome did you expect instead? package to upgrade without issue -- System Information: Debian Release: 9.13 APT prefers oldoldstable-debug APT policy: (500, 'oldoldstable-debug'), (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-0.bpo.14-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages redis-tools depends on: ii libc6 2.24-11+deb9u4 ii libjemalloc1 3.6.0-9.1 redis-tools recommends no packages. Versions of packages redis-tools suggests: pn ruby-redis -- no debconf information
Bug#598112: Gnome and tightvncserver
Control: tags -1 = unreproducible,moreinfo Hi David, On Sun, 26 Sep 2010 16:35:15 +0200 David Moerike wrote: > Package: tightvncserver > Version: 1.3.9-6.1+b1 > Severity: important > > [...] > Connecting from a 32 bit machine with Remmina or with xtightvncviewer to this > machine (amd64 architecture) does not work. > > However, when, before creation of the .vnc dir of the local user, > > in the script /usr/bin/tightvncserver, Line 77: > > "/etc/X11/Xsession\n"); > > is replaced with: > > "gnome-terminal\n"); > > it connects, the Gnome Terminal appears, and at least some applications work. > > The bug is only in Squeeze in amd64 architecture (maybe some others). > It is not in i386 architecture - connecting from the 64 bit machine to the > tightvncserver on the machine with the i386 architecture works fine. > > David Moerike > > One cannot use tightvncserver any more to display a Gnome desktop nowadays, so I tested your scenario - i386 xtightvncveiwer on Buster/amd64 tightvncserver on Bullseye - by accessing a Mate desktop. Everything worked fine for me, I encountered no issues. Is this bug still reproducible for you? If yes, how? Sven -- GPG Fingerprint 3DF5 E8AA 43FC 9FDF D086 F195 ADF5 0EDA F8AD D585 signature.asc Description: This is a digitally signed message part
Bug#991025: merkaartor build depends on both libqt5webkit5-dev and qtwebengine5-dev but uses neither
Jérôme, Are you going to fix this issue and the related issue about not migrating to testing (#993126), e.g. while packaging the 0.19.0 release? If not, merkaartor will be removed from Debian again. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1
Bug#888589: simple-scan: Does not set resolution on CanoScan LIDE 200
Hi, reporter mailbox doesn't exists anymore. Closed. CU Jörg -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype: joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. signature.asc Description: This is a digitally signed message part
Bug#993071: kmail: symbol lookup error: /lib/x86_64-linux-gnu/libKF5Libkleo.so.5: undefined symbol: _ZN5GpgME6UserID9SignatureltERKS1_
Am 27.08.21 um 15:32 schrieb Patrick Franz: > Hi Johannes, > > I cannot reproduce the issue on an up-to-date unstable. > kmail starts as expected. > > Do you maybe still have an older version of some package running that > causes the error ? I have upgraded from bullseye to sid with apt -t unstable dist-upgrade, so everything should be at the latest available version. I just did another apt update && apt upgrade just to be sure. The message "undefined symbol: _ZN5GpgME6UserID9SignatureltERKS1_" suggests that there is a problem between libkleo and gpgme, but both are at their latest available versions. Cheers, Johannes > >
Bug#993092: RFS: lebiniou/3.61.1-2 -- user-friendly, powerful music visualization / VJing tool
On 8/27/21 4:22 PM, Tobias Frost wrote: On Fri, 27 Aug 2021 13:44:47 +0200 Olivier Girondel wrote: * debian/control: Add Breaks: lebiniou-data (<< 3.61.0) (Closes: #992912). There's a typo in the bug number: I guess you want to close this one: #992919. I just uploaded a new package. Thanks, -- Olivier Girondel
Bug#993075: libnsl-dev: rpcsvc/nis.h includes no longer available rpc/rpc.h
On 27/08/2021 11.35, Aurelien Jarno wrote: sendmail should be updated to get the correct cflags. I'll try to work on a patch. Many thanks for the very quick fix! Andreas
Bug#993128: libvpx6: Unable to use camera or share screen on WebRTC conferences
Package: libvpx6 Version: 1.10.0-1 Severity: important Tags: a11y Dear Maintainer, When we try do use camera or share screen on WebRTC like, Jitsi, GoogleMeeting, it's not working. Running Chromium on terminal we can see many error messages: ERROR:video_stream_encoder.cc(1729)] Failed to encode frame. Error code: -7 Downgrading to version 1.9.0-1 it's working again. Thank's -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvpx6 depends on: ii libc6 2.31-17 libvpx6 recommends no packages. libvpx6 suggests no packages. -- no debconf information
Bug#993074: recommonmark: New upstream version 0.7.1 available.
Hi, On 8/27/21 5:06 AM, Tobias Frost wrote: > Source: recommonmark > Severity: wishlist > > Upstream has released 0.7.1 on Dec 17 2020. > Please consider updating it. > > PS: Upstream deprecates itself. However, there are reverse dependencies... > Maybe that needs to be tackled instead of updating.. I can take a look on the r-depends * python3-seqcluster * formiko * python3-jupyter-sphinx-theme Maybe it's a good idea ITP MyST-Parser? Should we try to remove recommonmark? -- Emmanuel Arias @eamanu yaerobi.com OpenPGP_0xFA9DEC5DE11C63F1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Bug#987577: kismet: new upstream version
* Christoph Anton Mitterer [Mon Apr 26, 2021 at 03:00:06AM +0200]: > 2020-04-R3 is out :-) And in the meanwhile 2021-08-R1 was released, see https://www.kismetwireless.net/release/kismet-2021-08-R1/ + https://github.com/kismetwireless/kismet/releases Would be great if someone could take care of the packaging, probably #954636 would be solved then as well? regards -mika- signature.asc Description: Digital signature
Bug#993092: RFS: lebiniou/3.61.1-2 -- user-friendly, powerful music visualization / VJing tool
On 8/27/21 4:22 PM, Tobias Frost wrote: On Fri, 27 Aug 2021 13:44:47 +0200 Olivier Girondel wrote: * debian/control: Add Breaks: lebiniou-data (<< 3.61.0) (Closes: #992912). There's a typo in the bug number: I guess you want to close this one: #992919. Indeed, my bad. Thanks. Regards, -- Olivier
Bug#992293: gimp: Can't select invert, crashing, lagging
Package: gimp Version: 2.10.22-4 Followup-For: Bug #992293 X-Debbugs-Cc: agdelfu...@mailnesia.com Dear Maintainer, Turns out that some settings I was trying out for GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub were likely the culprit for the gimp issue. After I removed the option and did a sudo update-grub and rebooted, gimp's behavior was working very well and fast like before. The options that gimp didn't seem to like proceed. irqpoll acpi=off noapic nolapic
Bug#993127: src:openmsx-catapult: fails to migrate to testing for too long: new autopkgtest fals
Source: openmsx-catapult Version: 16.0-1 Severity: serious Control: close -1 17.0-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:openmsx-catapult has been trying to migrate for 63 days [2]. Hence, I am filing this bug. You added an autopkgtest to your package, however it fails everywhere. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=openmsx-catapult OpenPGP_signature Description: OpenPGP digital signature
Bug#993126: src:merkaartor: fails to migrate to testing for too long: RC bug (ftbfs)
Source: merkaartor Version: 0.18.4+ds-5 Severity: serious Control: close -1 0.19.0~rc1+ds-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 991025 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:merkaartor has been trying to migrate for 74 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=merkaartor OpenPGP_signature Description: OpenPGP digital signature
Bug#993125: src:pcp: fails to migrate to testing for too long: RC bug
Source: pcp Version: 5.2.6-1 Severity: serious Control: close -1 5.3.2-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Control: block -1 by 990223 Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:pcp has been trying to migrate for 77 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=pcp OpenPGP_signature Description: OpenPGP digital signature
Bug#993104: src:wims-lti: fails to migrate to testing for too long: depends on package not allowed in testing
Hello Paul, thank you for this opened/closed bug report. I looked at bug #923347: it will most probably never be fixed. I shall try to patch wims-lti to use some other python package to interact with the database. Best regards, Georges. Paul Gevers a écrit : > Source: wims-lti > Version: 0.4.4-4 > Severity: serious > Control: close -1 0.4.4.1-5 > Tags: sid bookworm > User: release.debian@packages.debian.org > Usertags: out-of-sync > > Dear maintainer(s), > > As recently announced [1], the Release Team now considers packages that > are out-of-sync between testing and unstable for more than 60 days as > having a Release Critical bug in testing. Your package src:wims-lti has > been trying to migrate for 155 days [2]. Hence, I am filing this bug. > > You added a new dependency on a package that's not allowed to migrate to > testing due to security reasons: mysql-connector-python. > > If a package is out of sync between unstable and testing for a longer > period, this usually means that bugs in the package in testing cannot be > fixed via unstable. Additionally, blocked packages can have impact on > other packages, which makes preparing for the release more difficult. > Finally, it often exposes issues with the package and/or > its (reverse-)dependencies. We expect maintainers to fix issues that > hamper the migration of their package in a timely manner. > > This bug will trigger auto-removal when appropriate. As with all new > bugs, there will be at least 30 days before the package is auto-removed. > > I have immediately closed this bug with the version in unstable, so if > that version or a later version migrates, this bug will no longer affect > testing. I have also tagged this bug to only affect sid and bookworm, so > it doesn't affect (old-)stable. > > If you believe your package is unable to migrate to testing due to > issues beyond your control, don't hesitate to contact the Release Team. > > Paul > > [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html > [2] https://qa.debian.org/excuses.php?package=wims-lti > > -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: PGP signature
Bug#993124: simutrans FTCBFS: uses the build architecture pkg-config
Source: simutrans Version: 122.0-1 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs simutrans fails to cross build from source, because it uses the build architecture pkg-config. While the upstream build system allows substituting pkg-config, it does not do so in a standard way, which is why dh_auto_build doesn't handle it already. The attached patch implements it in simutrans' way. Please consider applying it. Helmut diff --minimal -Nru simutrans-122.0/debian/changelog simutrans-122.0/debian/changelog --- simutrans-122.0/debian/changelog2021-08-16 16:26:30.0 +0200 +++ simutrans-122.0/debian/changelog2021-08-27 16:11:34.0 +0200 @@ -1,3 +1,10 @@ +simutrans (122.0-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Fix FTCBFS: Use the host architecture pkg-config. (Closes: #-1) + + -- Helmut Grohne Fri, 27 Aug 2021 16:11:34 +0200 + simutrans (122.0-1) unstable; urgency=medium * Team upload. diff --minimal -Nru simutrans-122.0/debian/rules simutrans-122.0/debian/rules --- simutrans-122.0/debian/rules2021-08-16 13:39:25.0 +0200 +++ simutrans-122.0/debian/rules2021-08-27 16:11:34.0 +0200 @@ -8,6 +8,8 @@ export DEB_BUILD_MAINT_OPTIONS=hardening=+all +include /usr/share/dpkg/buildtools.mk + export CFLAGS = $(shell dpkg-buildflags --get CFLAGS) export CCFLAGS = $(CFLAGS) export CXXFLAGS = $(shell dpkg-buildflags --get CXXFLAGS) @@ -19,8 +21,8 @@ dh $@ override_dh_auto_build: - dh_auto_build - dh_auto_build --sourcedirectory=makeobj + dh_auto_build -- SDL2_CONFIG="$(PKG_CONFIG) sdl2" + dh_auto_build --sourcedirectory=makeobj -- PNG_CONFIG="$(PKG_CONFIG) libpng" override_dh_auto_clean: dh_quilt_patch
Bug#993123: frog FTCBFS: hard codes the build architecture pkg-config
Source: frog
Version: 0.20-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
frog fails to cross build from source, because configure.ac hard codes
the build architecture pkg-config in one place (after correctly
detecting the host architecture one). Simply using the correct
substitution variable makes frog cross buildable. Please consider
applying the attached patch.
Helmut
--- frog-0.20.orig/configure.ac
+++ frog-0.20/configure.ac
@@ -137,7 +137,7 @@
CXXFLAGS="$CXXFLAGS $ucto_CFLAGS"
LIBS="$ucto_LIBS $LIBS"
-UCTO_VERSION=`pkg-config --modversion ucto`
+UCTO_VERSION=`$PKG_CONFIG --modversion ucto`
UCTO_INT="${UCTO_VERSION//.}" # no dots
UCTO_INT=$((10#$UCTO_INT))# no leading 0 (that's octal)
AC_DEFINE_UNQUOTED( [UCTO_INT_VERSION],
Bug#993122: pev FTCBFS: does not pass cross tools to make
Source: pev Version: 0.81-4 Tags: patch User: debian-cr...@lists.debian.org Usertags: ftcbfs pev fails to cross build from source, because it does not pass cross tools to make. The easiest way of doing so - using dh_auto_build - makes pev cross buildable. Please consider applying the attached patch. Helmut diff --minimal -Nru pev-0.81/debian/changelog pev-0.81/debian/changelog --- pev-0.81/debian/changelog 2021-08-21 13:50:00.0 +0200 +++ pev-0.81/debian/changelog 2021-08-27 16:04:29.0 +0200 @@ -1,3 +1,9 @@ +pev (0.81-5) UNRELEASED; urgency=medium + + * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1) + + -- Helmut Grohne Fri, 27 Aug 2021 16:04:29 +0200 + pev (0.81-4) unstable; urgency=medium * QA upload. diff --minimal -Nru pev-0.81/debian/rules pev-0.81/debian/rules --- pev-0.81/debian/rules 2021-08-21 13:50:00.0 +0200 +++ pev-0.81/debian/rules 2021-08-27 16:04:04.0 +0200 @@ -5,7 +5,7 @@ dh_auto_clean $(RM) src/lib/libfuzzy/edit_dist.o src/lib/libfuzzy/fuzzy.o override_dh_auto_build: - $(MAKE) prefix=/usr pluginsdir=/usr/lib/pev/plugins + dh_auto_build -- prefix=/usr pluginsdir=/usr/lib/pev/plugins override_dh_auto_install: $(MAKE) prefix=/usr pluginsdir=/usr/lib/pev/plugins \ DESTDIR=$(CURDIR)/debian/pev install
Bug#993121: src:debarchiver: fails to migrate to testing for too long: maintainer built arch:all
Source: debarchiver Version: 0.11.5+nmu1 Severity: serious Control: close -1 0.11.6 Tags: sid bookworm pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:debarchiver has been trying to migrate for 93 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=debarchiver OpenPGP_signature Description: OpenPGP digital signature
Bug#993120: ITP: python-oslo.metrics -- OpenStack Oslo Metrics API
Package: wnpp Severity: wishlist Owner: Thomas Goirand X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: python-oslo.metrics Version : 0.0.3 Upstream Author : OpenStack Foundation * URL : https://opendev.org/openstack/oslo.metrics * License : Apache-2.0 Programming Lang: Python Description : OpenStack Oslo Metrics API This Oslo metrics API supports collecting metrics data from other Oslo libraries and exposing the metrics data to monitoring system. Note: This is a new dependency of python3-oslo.messaging
Bug#993092: RFS: lebiniou/3.61.1-2 -- user-friendly, powerful music visualization / VJing tool
On Fri, 27 Aug 2021 13:44:47 +0200 Olivier Girondel wrote: > * debian/control: Add Breaks: lebiniou-data (<< 3.61.0) (Closes: > #992912). There's a typo in the bug number: I guess you want to close this one: #992919. -- tobi
Bug#992034: installation-guide: Include a note on how to change init system during install
Hi, Justin Rye wrote (Fri, 27 Aug 2021 07:38:17 +0100): > Holger Wansing wrote: > > I wonder if "the easiest time to select an alternative init system is > > during the > > installation process" is correct English. > > > > Maybe better "the best time ... " ? > > > > Asking debian-l10n-english for advise. > > > > @debian-l10n-english: > > Hi all, could someone please comment on the merge request > > mentioned above? > > There's nothing wrong with the English of "the easiest time to do X is > during Y"; "best" is also okay but asserts something different (which > is slightly more a matter of subjective opinion). Ok. Moreover, when thinking about this implementation, I'm quite uncomfortable with adding such paragraph into the "Using individual components" section, since this "change-init-system part" is no "installer component" like the others in this section (say: there is no 'change-init-system udeb'). Therefore, I would be in favor of adding a separate section for such things as section 6.5 after the "Loading missing firmware" section, like this: snip== diff --git a/build/templates/docstruct.ent b/build/templates/docstruct.ent index dd3e8d273..81702c32d 100644 --- a/build/templates/docstruct.ent +++ b/build/templates/docstruct.ent @@ -126,6 +126,8 @@ + + diff --git a/en/using-d-i/using-d-i.xml b/en/using-d-i/using-d-i.xml index 3561ced2d..fe9c4628e 100644 --- a/en/using-d-i/using-d-i.xml +++ b/en/using-d-i/using-d-i.xml @@ -446,6 +446,7 @@ report installer software problems to developers later. + snap== Plus adding a new file en/using-d-i/misc-adaptions.xml: + + + + + Miscellaneous adaptions + +You may make custom adaptions of the installation process, to make it fit +your needs: + + + Installing an alternative init system + + uses systemd as its default init system. However, other init +systems (such as sysvinit and OpenRC) are supported, and the +easiest time to select an alternative init system is during the +installation process. For detailed instructions on how to do so, +please see the https://wiki.debian.org/Init#Changing_the_init_system_-_at_installation_time;>Init +page on the Debian wiki. + + + + @debian-l10n-english: How does this look like for you (especially the first part, since review for the second part has already been done) ? @debian-boot: any objections against this solution? Holger -- Holger Wansing PGP-Fingerprint: 496A C6E8 1442 4B34 8508 3529 59F1 87CA 156E B076
Bug#991920: please demote pkg-config to Recommends
On Thu, Aug 05, 2021 at 10:21:30PM +0200, Michael Banck wrote: > I've run "dracut --no-kernel" in a minimal lxc container, once with > pkg-config and once without and then diffoscope'd the two generated > initrds. Most of what diffoscope complains about are timestamp > differences in directories and symlinks which I don't know how to get > rid of, but there's some changes in etc/conf.d/systemd.conf that I have > attached. Not sure whether those are problematic? To clarify, the above was done on bullseye, on a usrmerge system. I see the same path changes in /etc/conf.d/systemd.conf if I try that on a real bullseye system. On a non-usrmerge buster system, diffoscope sees no such path differences between a dracut run with or without pkg-config. > │ ├── etc/conf.d/systemd.conf > │ │ @@ -1,3 +1,3 @@ > │ │ -systemdutildir="/lib/systemd" > │ │ -systemdsystemunitdir="/lib/systemd/system" > │ │ +systemdutildir="/usr/lib/systemd" > │ │ +systemdsystemunitdir="/usr/lib/systemd/system" > │ │ systemdsystemconfdir="/etc/systemd/system" > │ ├── usr/lib/systemd/system/ctrl-alt-del.target > │ │┄ symlink > │ │ @@ -1 +1 @@ > │ │ -destination: ../../../../lib/systemd/system/reboot.target > │ │ +destination: reboot.target Michael -- Michael Banck Projektleiter / Senior Berater Tel.: +49 2166 9901-171 Fax: +49 2166 9901-100 Email: michael.ba...@credativ.de credativ GmbH, HRB Mönchengladbach 12080 USt-ID-Nummer: DE204566209 Trompeterallee 108, 41189 Mönchengladbach Geschäftsführung: Dr. Michael Meskes, Sascha Heuer, Geoff Richardson, Peter Lilley Unser Umgang mit personenbezogenen Daten unterliegt folgenden Bestimmungen: https://www.credativ.de/datenschutz
Bug#993119: src:hp-search-mac: fails to migrate to testing for too long: maintainer built arch:all
Source: hp-search-mac Version: 0.1.4+nmu1 Severity: serious Control: close -1 0.1.5 Tags: sid bookworm pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:hp-search-mac has been trying to migrate for 98 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=hp-search-mac OpenPGP_signature Description: OpenPGP digital signature
Bug#993111: [Pkg-javascript-devel] Bug#993111: /usr/share/javascript/popper.js is an empty directory
Quoting Yadd (2021-08-27 15:44:58)
> Strange, there is a debian/libjs-popper.js.maintscript which contains
>
> dir_to_symlink /usr/share/javascript/popper.js \
> ../nodejs/popper.js/dist 1.14.6+ds2-1~
>
> and /usr/share/nodejs/popper.js contains:
> total 188
> drwxr-xr-x 2 4096 18 janv. 2021 esm
> -rw-r--r-- 1 86081 18 janv. 2021 popper.js
> -rw-r--r-- 1 36201 18 janv. 2021 popper.min.js
> -rw-r--r-- 1 34054 18 janv. 2021 popper-utils.js
> -rw-r--r-- 1 18547 18 janv. 2021 popper-utils.min.js
> drwxr-xr-x 2 4096 18 janv. 2021 umd
>
> What is wrong in maintscript ?
I don't know what failed, but to catch accidents like this I can dearly
recommend to always compare against previous release to ensure that
changes are as expected, by running this (e.g. just after lintian and
just before dput):
debdiff --wt ${OLD}_amd64.changes ${NEW}_amd64.changes | less -R
- Jonas
--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
[x] quote me freely [ ] ask before reusing [ ] keep private
signature.asc
Description: signature
Bug#984901: open-ath9k-htc-firmware upload is now release-critical
Control: retitle -1 RFS: open-ath9k-htc-firmware/1.4.0-106-gc583009+dfsg1-2 [RC] -- firmware for AR7010 and AR9271 USB wireless adapters Thanks to the Reproducible Builds folks for notifying me, the current package is FTBFS due to the Binutils 2.37 upload to unstable. Fortunately my package already addressed this, so I've just switched the changelog to unstable. signature.asc Description: This is a digitally signed message part
Bug#993111: [Pkg-javascript-devel] Bug#993111: /usr/share/javascript/popper.js is an empty directory
Le 27/08/2021 à 15:44, Yadd a écrit : > Control: tags -1 + confirmed > > Le 27/08/2021 à 15:04, Enrico Zini a écrit : >> Package: libjs-popper.js >> Version: 1.16.1+ds-3 >> Severity: serious >> >> Hello, >> >> the assets of libjs-popper.js do not appear under /usr/share/javascript. >> The only thing that is packaged there is `popper.js` as an empty >> directory. >> >> This is currently breaking all software that loads popper.js assets from >> its packaged version (and by extension all software that uses bootstrap4 >> in the same way) > > Strange, there is a debian/libjs-popper.js.maintscript which contains > > dir_to_symlink /usr/share/javascript/popper.js \ > ../nodejs/popper.js/dist 1.14.6+ds2-1~ > > and /usr/share/nodejs/popper.js contains: > total 188 > drwxr-xr-x 2 4096 18 janv. 2021 esm > -rw-r--r-- 1 86081 18 janv. 2021 popper.js > -rw-r--r-- 1 36201 18 janv. 2021 popper.min.js > -rw-r--r-- 1 34054 18 janv. 2021 popper-utils.js > -rw-r--r-- 1 18547 18 janv. 2021 popper-utils.min.js > drwxr-xr-x 2 4096 18 janv. 2021 umd > > What is wrong in maintscript ? Found and fixed
Bug#993117: debian-cd: F2FS support
Package: debian-cd Severity: wishlist X-Debbugs-Cc: roman.hor...@debian-linux.cz Hello, Please add the option to select the F2FS file system in the disk partitioning menu. This filesystem seems to me to be reliable enough, not less than the much slower Btrfs. Besides, it is optimized for use on modern solid-state drives. -- System Information: Debian Release: Sid/Experimental APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.13.0-trunk-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages debian-cd depends on: ii apt2.3.8 ii bc 1.07.1-2+b2 ii bzip2 1.0.8-4 ii cpp4:10.2.1-1 ii curl 7.74.0-1.3+b1 ii dctrl-tools [grep-dctrl] 2.24-3+b1 ii dpkg-dev 1.20.9 pn libcompress-zlib-perl pn libdigest-md5-perl ii libdpkg-perl 1.20.9 pn libfile-slurp-perl pn libyaml-libyaml-perl pn lynx ii make 4.3-4.1 ii perl [libdigest-sha-perl] 5.32.1-5 pn tofrodos ii wget 1.21-1+b1 pn xorriso | genisoimage Versions of packages debian-cd recommends: ii dosfstools 4.2-1 pn hfsutils pn isolinux pn mtools pn syslinux-common
Bug#993111: /usr/share/javascript/popper.js is an empty directory
Control: tags -1 + confirmed Le 27/08/2021 à 15:04, Enrico Zini a écrit : > Package: libjs-popper.js > Version: 1.16.1+ds-3 > Severity: serious > > Hello, > > the assets of libjs-popper.js do not appear under /usr/share/javascript. > The only thing that is packaged there is `popper.js` as an empty > directory. > > This is currently breaking all software that loads popper.js assets from > its packaged version (and by extension all software that uses bootstrap4 > in the same way) Strange, there is a debian/libjs-popper.js.maintscript which contains dir_to_symlink /usr/share/javascript/popper.js \ ../nodejs/popper.js/dist 1.14.6+ds2-1~ and /usr/share/nodejs/popper.js contains: total 188 drwxr-xr-x 2 4096 18 janv. 2021 esm -rw-r--r-- 1 86081 18 janv. 2021 popper.js -rw-r--r-- 1 36201 18 janv. 2021 popper.min.js -rw-r--r-- 1 34054 18 janv. 2021 popper-utils.js -rw-r--r-- 1 18547 18 janv. 2021 popper-utils.min.js drwxr-xr-x 2 4096 18 janv. 2021 umd What is wrong in maintscript ?
Bug#993116: src:simplesamlphp: fails to migrate to testing for too long: maintainer built arch:all
Source: simplesamlphp Version: 1.19.0-1 Severity: serious Control: close -1 1.19.1-1 Tags: sid bookworm pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:simplesamlphp has been trying to migrate for 109 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=simplesamlphp OpenPGP_signature Description: OpenPGP digital signature
Bug#993115: firewalld: missing test dependencies
Source: firewalld Version: 1.0.1-1 Severity: serious tags: patch Hello, looks some tests needs nftables and ipset installed inside the chroot the following patch makes them pass all. diff -Nru firewalld-1.0.1/debian/tests/control firewalld-1.0.1/debian/tests/control --- firewalld-1.0.1/debian/tests/control2021-08-17 23:25:15.0 +0200 +++ firewalld-1.0.1/debian/tests/control2021-08-27 15:16:04.0 +0200 @@ -3,6 +3,7 @@ ipset, libglib2.0-bin, libxml2-utils, + nftables, Restrictions: needs-root, isolation-machine Tests: integration-tests @@ -10,6 +11,8 @@ network-manager, sudo, policykit-1, + nftables, + ipset Restrictions: needs-root, isolation-machine Tests: smoke I know Debian infrastructure doesn't support isolation-machine (yet), so I'm not totally confident about the severity of this bug, but since its trivial to fix, better fix it and leave autopkgtests to user working. cheers, Gianfranco
Bug#991989: libclang-13-dev: dead symlink to shared library
control: fixed -1 1:13.0.0~+rc1-2 control: close -1 Hello, I did check 1:13.0.0~+rc1-2 and the link is not dead anymore. ls -l /usr/lib/llvm-13/lib/libclang-13.so lrwxrwxrwx 1 root root 39 Aug 19 16:13 /usr/lib/llvm-13/lib/libclang-13.so -> ../../x86_64-linux-gnu/libclang-13.so.1 ls -l /usr/lib/llvm-13/lib/../../x86_64-linux-gnu/libclang-13.so.1 lrwxrwxrwx 1 root root 17 Aug 19 16:13 /usr/lib/llvm-13/lib/../../x86_64-linux-gnu/libclang-13.so.1 -> libclang-13.so.13 ls -l /usr/lib/llvm-13/lib/../../x86_64-linux-gnu/libclang-13.so.13 lrwxrwxrwx 1 root root 21 Aug 19 16:13 /usr/lib/llvm-13/lib/../../x86_64-linux-gnu/libclang-13.so.13 -> libclang-13.so.13.0.0 ls -l /usr/lib/llvm-13/lib/../../x86_64-linux-gnu/libclang-13.so.13.0.0 -rw-r--r-- 1 root root 32732928 Aug 19 16:13 /usr/lib/llvm-13/lib/../../x86_64-linux-gnu/libclang-13.so.13.0.0 I'm closing it On Sat, 7 Aug 2021 18:11:54 +0200 =?UTF-8?Q?Christian_G=C3=B6ttsche?= wrote: > Package: libclang-13-dev > Version: 1:13.0.0~+rc1-1~exp1 > Severity: important > > The shared library symlink at '/usr/lib/llvm-13/lib/libclang-13.so' is > a dead symlink to '../../x86_64-linux-gnu/libclang-13.so.1'. > The existing targets are > - /usr/lib/x86_64-linux-gnu/libclang-13.so > - /usr/lib/x86_64-linux-gnu/libclang-13.so.13 > - /usr/lib/x86_64-linux-gnu/libclang-13.so.13.0.0 > > This causes for example 'Include What You Use' to fail to build: > > > CMake Error at /usr/lib/llvm-13/lib/cmake/clang/ClangTargets.cmake:706 > (message): > The imported target "libclang" references the file > > "/usr/lib/llvm-13/lib/libclang-13.so.13.0.0" > > but this file does not exist. Possible reasons include: > > * The file was deleted, renamed, or moved to another location. > > * An install or uninstall procedure did not complete successfully. > > * The installation package was faulty and contained > > "/usr/lib/llvm-13/lib/cmake/clang/ClangTargets.cmake" > > but not all the files it references. > > Call Stack (most recent call first): > /usr/lib/cmake/clang-13/ClangConfig.cmake:20 (include) > CMakeLists.txt:20 (find_package) > > > -- Configuring incomplete, errors occurred! > >
Bug#992798: initramfs-tools: please drop shellcheck autopkgtest
tags 992798 + patch thanks Hi, * Paul Gevers [Mon Aug 23, 2021 at 05:41:20PM +0200]: > Source: initramfs-tools [...] > Control: affects -1 src:shellcheck > Dear maintainer(s), > With a recent upload of shellcheck the autopkgtest of initramfs-tools > fails in testing when that autopkgtest is run with the binary packages > of shellcheck from unstable. It passes when run with only packages from > testing. In tabular form: >passfail > shellcheck from testing0.7.2-2 > initramfs-toolsfrom testing0.140 > all others from testingfrom testing [...] I took care of this and created a MR which addresses those shellcheck issues: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/50 It's worth mentioning, that shellcheck v0.7.2 includes a regression, see https://github.com/koalaman/shellcheck/issues/2217 regards -mika- signature.asc Description: Digital signature
Bug#993071: kmail: symbol lookup error: /lib/x86_64-linux-gnu/libKF5Libkleo.so.5: undefined symbol: _ZN5GpgME6UserID9SignatureltERKS1_
Hi Johannes, I cannot reproduce the issue on an up-to-date unstable. kmail starts as expected. Do you maybe still have an older version of some package running that causes the error ? -- Med vänliga hälsningar Patrick Franz
Bug#954093: desktop-base: Integration with KDE Plasma on Debian 11 no longer works
Hi! On Fri, 6 Aug 2021 at 10:32, Cyril Brulebois wrote: > loop += debian-kde@ in case they can offer some help regarding this > issue which affects their desktop environment. I have never digged into this, so I am CCing Aurélien who did the code. What I do see is that the code will only try to set the theme if the user has the default theme in use, and that's something we always tried to keep. Now the code seems to only handle the wallpaper, I don't know if we currently have the manpower to do better. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/
Bug#993114: jo: New upstream version 1.4 available
Package: jo Version: 1.3-2 Severity: wishlist Hi, jo 1.4 was relased on 2020-07-18, see https://github.com/jpmens/jo/releases Thanks for maintaining jo! :) regards -mika- signature.asc Description: Digital signature
Bug#993113: src:openboard-extras-nonfree: fails to migrate to testing for too long: non-free not built on buildd
Source: openboard-extras-nonfree Version: 1.5.4+nonfree1-1 Severity: serious Control: close -1 1.5.4+nonfree1-2 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:openboard-extras-nonfree has been trying to migrate for 120 days [2]. Hence, I am filing this bug. Your package is in non-free. Packages there are not auto-build on buildd's. Hence, you'll have to upload the binaries too (which can be done in a separate upload). If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=openboard-extras-nonfree OpenPGP_signature Description: OpenPGP digital signature
Bug#993112: src:clues-emacs: fails to migrate to testing for too long: maintainer built arch:all
Source: clues-emacs Version: 1.0.1-2.1 Severity: serious Control: close -1 1.0.1-3 Tags: sid bookworm pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:clues-emacs has been trying to migrate for 130 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=clues-emacs OpenPGP_signature Description: OpenPGP digital signature
Bug#993111: /usr/share/javascript/popper.js is an empty directory
Package: libjs-popper.js Version: 1.16.1+ds-3 Severity: serious Hello, the assets of libjs-popper.js do not appear under /usr/share/javascript. The only thing that is packaged there is `popper.js` as an empty directory. This is currently breaking all software that loads popper.js assets from its packaged version (and by extension all software that uses bootstrap4 in the same way) Enrico -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-0.bpo.7-amd64 (SMP w/4 CPU threads) Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE=en_IE:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libjs-popper.js depends on: ii javascript-common 11+nmu1 Versions of packages libjs-popper.js recommends: pn node-jquery libjs-popper.js suggests no packages. -- no debconf information
Bug#993110: src:themole: fails to migrate to testing for too long: maintainer built arch:all
Source: themole Version: 0.3-2 Severity: serious Control: close -1 0.3-3 Tags: sid bookworm pending User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:themole has been trying to migrate for 137 days [2]. Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. Your package is only blocked because the arch:all binary package(s) aren't built on a buildd. Unfortunately the Debian infrastructure doesn't allow arch:all packages to be properly binNMU'ed. Hence, I will shortly do a no-changes source-only upload to DELAYED/15, closing this bug. Please let me know if I should delay or cancel that upload. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=themole OpenPGP_signature Description: OpenPGP digital signature
Bug#993109: src:gdisk: fails to migrate to testing for too long: ftbfs on s390x
Source: gdisk Version: 1.0.6-1.1 Severity: serious Tags: sid bookworm ftbfs User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:gdisk has been trying to migrate for 142 days [2] (yes I know, mostly during the freeze). Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=gdisk OpenPGP_signature Description: OpenPGP digital signature
Bug#993108: src:pyspread: fails to migrate to testing for too long: RC bug (autopkgtest failure)
Source: pyspread Version: 1.99.5-1 Severity: serious Control: close -1 1.99.7-1 Tags: sid bookworm User: release.debian@packages.debian.org Usertags: out-of-sync Dear maintainer(s), As recently announced [1], the Release Team now considers packages that are out-of-sync between testing and unstable for more than 60 days as having a Release Critical bug in testing. Your package src:pyspread has been trying to migrate for 149 days [2] (yes, I know, mostly during the freeze). Hence, I am filing this bug. If a package is out of sync between unstable and testing for a longer period, this usually means that bugs in the package in testing cannot be fixed via unstable. Additionally, blocked packages can have impact on other packages, which makes preparing for the release more difficult. Finally, it often exposes issues with the package and/or its (reverse-)dependencies. We expect maintainers to fix issues that hamper the migration of their package in a timely manner. This bug will trigger auto-removal when appropriate. As with all new bugs, there will be at least 30 days before the package is auto-removed. I have immediately closed this bug with the version in unstable, so if that version or a later version migrates, this bug will no longer affect testing. I have also tagged this bug to only affect sid and bookworm, so it doesn't affect (old-)stable. If you believe your package is unable to migrate to testing due to issues beyond your control, don't hesitate to contact the Release Team. Paul [1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html [2] https://qa.debian.org/excuses.php?package=pyspread OpenPGP_signature Description: OpenPGP digital signature
Bug#993076: ITP: tilemaker -- Generates vector tiles from OpenStreetMap data
Package: wnpp Severity: wishlist Owner: Felix Delattre * Package name: tilemaker Version : 2.0.0 Upstream Author : Richard Fairhurst * URL : https://github.com/systemed/tilemaker * License : FTWPL Programming Lang: C++ Description : Generates vector tiles from OpenStreetMap data tilemaker generates vector tiles without from OpenStreetMap planet and diff files without any complex stack or need for database. It uses the schema of OpenMapTiles by default, but other configuration can be provided. The package will be maintained in the Debian GIS team.
