Bug#1071592: fails to enable LVM on crypt during boot, rendering the system unbootable
On Wed, 22 May 2024 00:51:22 +0100 Luca Boccassi wrote:
Control: reassign -1 dracut 060+5-1
On Tue, 21 May 2024 21:47:37 +0200 Evgeni Golov
wrote:
> Package: systemd
> Version: 256~rc2-3
> Severity: important
>
> Ohai,
>
> I am filing this against systemd, as that's the package that triggers
> the issue when upgraded, but it very well might be in dracut, so
please
> re-assign as you see fit.
> Also filing this "only" as important, as it's breaking a non-default
> setup and I did not verify this on any other system.
>
> My laptop is running sid with / on LVM on crypt. I am using dracut
for
> initrd generation.
>
> With the upgrade to systemd 256 (from 255.5) it fails to boot:
> 1. asks for my passphrase
> 2. systemd-cryptsetup@.service starts
> 3. dev-mapper--.device runs forever, never reaching
completion
>
> I can get it to boot by:
> 1. rd.break=pre-mount in the bootloader to interrupt dracut
> 2. lvm lvchange -ae / in the dracut shell
>
> I am aware of #1071278 but I do have dracut 060+5-8 which is supposed
to
> have all the required fixes.
>
> Downgrading systemd to 255.5-1 and regenerating the initrd fixes the
> boot process.
It's probably the same issue with missing libraries, but I do not use
either dracut nor LVM so I cannot help, reassigning to dracut so that
you might get some help with debugging and finding out what the actual
issue is
It seems like the issue is that systemd 256 now makes /usr read-only in the
initrd environment, but dracut depends on writing to /usr.
One workaround is to set ProtectSystem=no in the initrd, so that /usr is
writable again. I got my system (also LVM on LUKS) booting with a dracut
module to write system.conf:
blee@r8 /usr/lib/dracut/modules.d/99local $ cat module-setup.sh
#!/bin/bash
# called by dracut
install() {
printf "[Manager]\nProtectSystem=no\n" >>
"${initdir}/etc/systemd/system.conf"
}
Bug#1071396: apt-move does not include the component 'non-free-firmware' when building the dists "Release" file
Package: apt-move Version: 4.2.27-6 Severity: important Tags: patch X-Debbugs-Cc: leeejobsacco...@mail.co.uk Dear Maintainer, * What led up to the situation? I ran apt-move packages and found that when I then ran apt-update it reported the following warning: mirrors/debian bookworm InRelease' doesn't have the component 'non-free-firmware' (component misspelt in sources.list?) * What exactly did you do (or not do) that was effective (or ineffective)? I edited /usr/bin/apt-move to include the 'non-free-firmware' component in the 'if' statements at lines 1302 and 1376 * What was the outcome of this action? When I re-ran apt-move pacakages the 'non-free-firmware' component was included in the "Release" file and apt update did not report the warning * What outcome did you expect instead? -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.90-1-sunset-6-20240511-00 (SMP w/32 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apt-move depends on: ii bc 1.07.1-3+b1 ii dash 0.5.12-2 ii libapt-pkg6.0 2.6.1 ii libc6 2.36-9+deb12u7 ii libgcc-s1 12.2.0-14 ii libstdc++6 12.2.0-14 Versions of packages apt-move recommends: ii apt 2.6.1 apt-move suggests no packages. -- Configuration Files: /etc/apt-move.conf changed: APTSITES="/all/" LOCALDIR=/nfs/LE-Server/packages/mirrors/debian DIST=bookworm PKGTYPE=binary FILECACHE=/nfs/LE-Server/packages/apt-bookworm_amd64/archives LISTSTATE=/var/lib/apt/lists DELETE=yes MAXDELETE=20 COPYONLY=no PKGCOMP=gzip CONTENTS=no GPGKEY= -- no debconf information -- debsums errors found: debsums: changed file /usr/bin/apt-move (from apt-move package)
Bug#722344: eog: saving multiple rotations failes, only last is saved
Package: eog Version: 43.2-1 Followup-For: Bug #722344 X-Debbugs-Cc: deb...@rocketjump.eu Hi, this bug is still present in bookworm. The steps to reproduce are trivial: 1) view several (> 2) jpg in a folder 2) rotate the first picture by clicking the rotate right button at the bottom of the pic 3) repeat the last step for all pictures 4) close eog, and select save images before closing 5) Notice that only the last picture is actually rotated, all the others are untouched. It would be nice to get this fixed, as it's easy for people to waste time on fixing the rotation only to later find out that it doesn't actually persist. Greets, Lee -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'proposed-updates'), (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages eog depends on: ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4 ii gir1.2-gtk-3.0 3.24.38-2~deb12u1 ii gir1.2-peas-1.0 1.34.0-1+b1 ii gsettings-desktop-schemas43.0-1 ii libc62.36-9+deb12u7 ii libcairo21.16.0-7 ii libexempi8 2.6.3-1 ii libexif120.6.24-1+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libgirepository-1.0-11.74.0-3 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgnome-desktop-3-2043.2-2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libhandy-1-0 1.8.1-1 ii libjpeg62-turbo 1:2.1.5-2 ii liblcms2-2 2.14-2 ii libpeas-1.0-01.34.0-1+b1 ii librsvg2-2 2.54.7+dfsg-1~deb12u1 ii librsvg2-common 2.54.7+dfsg-1~deb12u1 ii libx11-6 2:1.8.4-2+deb12u2 ii shared-mime-info 2.2-1 ii webp-pixbuf-loader 0.2.1-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages eog recommends: ii yelp 42.2-1 Versions of packages eog suggests: pn eog-plugins -- no debconf information
Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1
I have just pushed some meta-data updates, and also a change that fixes CVE-2023-4237 in this package. See the commit logs here: https://salsa.debian.org/python-team/packages/ansible/-/commits/debian/bookworm-proposed/
Bug#1070807: konsole: Konsole did not close redundant FDs when creating shell process in terminal session
Dear Maintainer, This may not be Konsole's bug. By deep dive into the problem, I found those redundant FDs were coming from kwin_wayland, the wayland implementation of KWin. Today I tried to start a Konsole Terminal in another desktop environment rather than KDE Plasma, and the redundant FDs problem did not reproduce this time. So you may close this bug ticket. So this On Thu, 09 May 2024 22:11:48 +0800 anthony wrote: > Package: konsole > Version: 4:23.08.1-1+b1 > Severity: important > X-Debbugs-Cc: lkphantom1...@gmail.com > > Dear Maintainer, > > * What led up to the situation? > The terminal did not close redundant FDs when creating shell process. > * What exactly did you do (or not do) that was effective (or > ineffective)? > * What was the outcome of this action? > The shell process has many unexpected redundant FDs, and those FDs > were inherit from konsole. > * What outcome did you expect instead? > The terminal emulator should not leave any redundant FDs for shell > process. > > Today I found my Zsh comes with 157 FDs, in common sense zsh won't > create such large amount open files. Then I tried command > 'konsole -e /bin/sleep 1', even through, the sleep process also > has 100+ FDs that shouldn't exists. > > By comparing the FDs' number, those FDs were inherit from konsole. > > I thought you may close redundant FDs before creating shell process, > or use CLOEXEC flag. > > > This is my test output in konsole: > % uname -r > 6.1.27.xeon.ll > % ls /proc/self/fd | wc -l > 157 > % ls /proc/$PPID/fd | wc -l > 179 > % cat /proc/$PPID/cmdline| tr '\0' ' ' > /usr/bin/konsole --new-tab > % > > > -- System Information: > Debian Release: trixie/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.27.xeon.ll (SMP w/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_USER > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages konsole depends on: > ii kio 5.107.0-1+b2 > ii konsole-kpart 4:23.08.1-1+b1 > ii libc6 2.37-19 > ii libkf5configcore5 5.107.0-1+b2 > ii libkf5configwidgets5 5.107.0-2+b2
Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1
On Fri, 26 Apr 2024 15:05:00 +0200 Lee Garrett wrote:
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: ansi...@packages.debian.org, deb...@rocketjump.eu
Control: affects -1 + src:ansible
Hi,
I'm requesting to bump the version of the ansible package ("ansible-community
collection") to the last minor semantic version of the v7 series in bookworm.
This version has previously spent ~10 months in testing/unstable, so I'm fairly
confident that any potential regressions would have been caught (so far none).
[ Reason ]
This incorporates the latest bugfixes from the v7 series, which update all
modules in the collection. These contain updates to handle:
- distro releases that have been released since
- web API changes that ansible can run against
- various bugfixes
- deprecation warnings that will be useful for users before they upgrade to
bookworm + 1
Most importantly due to semantic versioning, there is no user-visible change.
Any previous playbooks will continue to work without changes.
I intend to use the 7.7.0 release as a basis for security support until bookworm
LTS EOL.
[ Impact ]
(What is the impact for the user if the update isn't approved?)
If the update is not approved, users will likely report errors that have already
been fixed in the latest minor release, and I'd have to cherrypick those
changes, add roundtrip time to the process.
[ Tests ]
autopkgtests have been widely expanded from the previous 7.3.0 release, covering
more unit tests than before.
[ Risks ]
There is a small risk of regressions, but I believe the risk to be minimal as no
such regressions have been reported in the 10 months in testing/unstable.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
- upstream update to 7.7.0
Forgot to add the link with the high-level upstream changes:
https://salsa.debian.org/debian/ansible/-/blob/debian/bookworm-proposed/CHANGELOG-v7.rst
- fixes to the libvirt connection plugin that bit me
- updates to the package metadata
- widely expanded autopkgtests for more coverage
[ Other info ]
This is my first s-p-u process, let me know what I can do better for any
following s-p-u.
Bug#1069886: piuparts fails when unrelated hardware events happen on the host machine
Package: piuparts Version: 1.1.7 Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, I'm running piuparts in a schroot as part of my packaging workflow. However, when I plug in hardware on my host machine, or enable/disable things like bluetooth/LTE modem/etc, during a piuparts run it will inadvertently fail: [...] 2m51.1s ERROR: FAIL: After purging files have disappeared: /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/ not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/bEndpointAddress not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/bInterval not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/bLength not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/bmAttributes not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/direction not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/interval not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/ not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/async not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/autosuspend_delay_ms not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/control not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_active_kids not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_active_time not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_enabled not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_status not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_suspended_time not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/power/runtime_usage not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/type not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/uevent not owned /sys/devices/pci:00/:00:14.0/usb1/1-5/1-5.3/1-5.3.3/1-5.3.3.4/1-5.3.3.4.4/1-5.3.3.4.4.1/1-5.3.3.4.4.1:1.1/ep_81/wMaxPacketSize not owned 2m51.1s ERROR: FAIL: Installation, upgrade and purging tests. 2m51.5s DEBUG: Terminate schroot session '/var/run/schroot/mount/bookworm-amd64-sbuild-2ab9e614-03c3-11ef-9ce1-52540055ba9d-piuparts' 2m51.5s DEBUG: Starting command: ['schroot', '--end-session', '--chroot', 'session:bookworm-amd64-sbuild-2ab9e614-03c3-11ef-9ce1-52540055ba9d-piuparts'] 2m51.6s DEBUG: Command ok: ['schroot', '--end-session', '--chroot', 'session:bookworm-amd64-sbuild-2ab9e614-03c3-11ef-9ce1-52540055ba9d-piuparts'] 2m51.6s ERROR: piuparts run ends. E: Piuparts run failed. Since it's not immediately clear if it failed for those reasons alone, it makes piuparts less useful. It would be nice if piuparts could ignore /sys, /dev, /proc as they're not on-disk file systems anyway. Greets, Lee -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'proposed-updates'), (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages piuparts depends on: ii debootstrap 1.0.128+nmu2+deb12u1 ii debsums 3.0.2.1 ii libjs-sphinxdoc 5.3.0-4 ii lsb-release 12.0-1 ii lsof 4.95.0-1 ii mount2.38.1-5+deb12u1 ii
Bug#1069884: Document acronym "ITA" on https://www.debian.org/devel/wnpp/
Package: www.debian.org Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, it would be nice to document "ITA" on https://www.debian.org/devel/wnpp/ along with the other acronyms like O/RFA/RFH/ITP/RFP. I'm guessing it means "intent to adopt"? It's mentioned in the removing tables entries, but that's not helpful to see which tags are available. Greets, Lee
Bug#1051140: lintian in bookworm does not know about bookworm-backports
Friendly ping. It's been half a year now without response from the maintainers. Can we get an update please? On Sun, 03 Sep 2023 14:01:47 +0200 Lee Garrett wrote: Package: lintian Version: 2.116.3 Severity: important X-Debbugs-Cc: deb...@rocketjump.eu Hi, when preparing an upload for bookworm-backports, lintian in bookworm will falsely error out, diminishing it's usefulness: E: rhsrvany changes: bad-distribution-in-changes-file bookworm-backports It would be great if lintian in stable would know about bookworm-backports. Greetings, Lee -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.40-2 ii bzip2 1.0.8-5+b1 ii diffstat1.65-1 ii dpkg1.21.22 ii dpkg-dev1.21.22 ii file1:5.44-3 ii gettext 0.21-12 ii gpg 2.2.40-1.1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.15.0-1 ii libapt-pkg-perl 0.1.40+b2 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-2+b1 ii libcapture-tiny-perl0.48-2 ii libclass-xsaccessor-perl1.19-4+b1 ii libclone-perl 0.46-1 ii libconfig-tiny-perl 2.28-2 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.35-1 ii libdata-dpath-perl 0.58-2 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2+b1 pn libdigest-sha-perl ii libdpkg-perl1.21.22 ii libemail-address-xs-perl1.05-1+b1 ii libencode-perl 3.19-1+b1 ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3
Bug#1069768: The 'no-agent-forwarding' key restriction disables server alive message support
On 24.04.24 19:59, Guilhem Moulin wrote: Control: reassign -1 dropbear-bin 2022.83-1+deb12u1 Control: retitle -1: The 'no-agent-forwarding' key restriction disables server alive message support Control: tag -1 upstream On Wed, 24 Apr 2024 at 18:38:26 +0200, Guilhem Moulin wrote: On Wed, 24 Apr 2024 at 17:10:57 +0200, Guilhem Moulin wrote: It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3 -o ServerAliveInterval=1 root@yourdropbearserver`. The client should then disconnect after 3 seconds. Seems to work as expected for me: $ ssh -oLogLevel=DEBUG3 \ -oServerAliveCountMax=3 -oServerAliveInterval=1 \ -oUserKnownHostsFile=/tmp/known_hosts \ -i /tmp/test.key \ -l user -p 10022 127.0.0.1 sleep 300 […] No wait, this works in the main system but indeed at initramfs stage the client doesn't get responses to its alive probes. The above was misleading, turns out this was not due to the initramfs per se, but because its authorized_keys file had the following restrictions (which were set in my test environment per cryptsetup-initramfs' recommendations): no-port-forwarding,no-agent-forwarding,no-X11-forwarding,command="/bin/cryptroot-unlock" Lee, I assume you have the ‘no-port-forwarding’ restriction too? It appears to disable server alive message support for some reason. This is reproducible at initramfs stage as well as in the main system. my /etc/dropbear/initramfs/dropbear.conf has: DROPBEAR_OPTIONS="-s -j -k -I 180 -c /usr/bin/cryptroot-unlock" -j and -k are "disable local/remote port forwarding". Seems like we cracked the case. Nice! Is there a chance we can get that into bookworm via s-p-u?
Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts
On 24.04.24 17:10, Guilhem Moulin wrote: On Wed, 24 Apr 2024 at 16:32:09 +0200, Lee Garrett wrote: Although the dropbear man page is not explicit, I'm assuming it refers to TCP keepalive. I think this assumption is incorrect: https://sources.debian.org/src/dropbear/2024.84-1/src/common-session.c/#L497 It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3 -o ServerAliveInterval=1 root@yourdropbearserver`. The client should then disconnect after 3 seconds. Seems to work as expected for me: $ ssh -oLogLevel=DEBUG3 \ -oServerAliveCountMax=3 -oServerAliveInterval=1 \ -oUserKnownHostsFile=/tmp/known_hosts \ -i /tmp/test.key \ -l user -p 10022 127.0.0.1 sleep 300 […] debug1: Sending command: sleep 300 debug2: channel 0: request exec confirm 1 debug3: send packet: type 98 debug3: client_repledge: enter debug2: channel_input_open_confirmation: channel 0: callback done debug2: channel 0: open confirm rwindow 65536 rmax 32759 debug3: receive packet: type 99 debug2: channel_input_status_confirm: type 99 id 0 debug2: exec request accepted on channel 0 debug3: send packet: type 80 debug3: receive packet: type 82 debug3: send packet: type 80 debug3: receive packet: type 82 debug3: send packet: type 80 debug3: receive packet: type 82 debug3: send packet: type 80 debug3: receive packet: type 82 […] debug3: send packet: type 80 debug3: receive packet: type 82 debug3: receive packet: type 96 debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: chan_shutdown_write: channel 0: (i0 o1 sock -1 wfd 5 efd 6 [write]) debug2: channel 0: output drain -> closed debug3: receive packet: type 98 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug3: receive packet: type 97 debug2: channel 0: rcvd close debug2: chan_shutdown_read: channel 0: (i0 o3 sock -1 wfd 4 efd 6 [write]) debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug3: send packet: type 97 debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 [session] r0 i3/0 o3/0 e[write]/0 fd -1/-1/6 sock -1 cc -1 io 0x00/0x00) debug3: send packet: type 1 Transferred: sent 15360, received 7448 bytes, in 300.0 seconds Bytes per second: sent 51.2, received 24.8 debug1: Exit status 0 There is one packet 80/82 exchange per second until the `sleep 300` terminates. The output is similar with OpenSSH's sshd. Thanks for debugging this. Then I'll have to try and reproduce this on my remote server when I find time. Unfortuntely it might take a few days as I need the services on it for now. Thanks again for the swift response!
Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts
On 24.04.24 16:15, Guilhem Moulin wrote: Control: tag -1 unreproducible moreinfo Hi, On Wed, 24 Apr 2024 at 14:42:43 +0200, Lee Garrett wrote: After some debugging, it turns out that ServerAliveInterval != 0 will cause the ssh client to reset the connection, which dropbear will count as unlock attempt, and after three tries it will fail and drop to initramfs shell, after which it's not reachable anymore. AFAICT dropbear does support timeout messages (see -K in the manual). I'm unable to reproduce the issue anyway, do you start dropbear with -I? Can you try to start your client with -oLogLevel=DEBUG3 to see why the connection is terminated (from the client's perspective)? Also to take cryptroot out of the picture you could try using `cat -A` as the remote command. Although the dropbear man page is not explicit, I'm assuming it refers to TCP keepalive. The settings ServerAliveCountMax and ServerAliveInterval on the ssh client however explicitely refer to SSH keepalive. To quote the man page: "Sets the number of server alive messages (see below) which may be sent without ssh(1) receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session. It is important to note that the use of server alive messages is very different from TCPKeepAlive (below)." It should be trivially reproducible by running `ssh -o ServerAliveCountMax=3 -o ServerAliveInterval=1 root@yourdropbearserver`. The client should then disconnect after 3 seconds.
Bug#1069768: dropbear-initramfs becomes unresponsive after several connection attempts
Package: dropbear-initramfs Version: 2022.83-1+deb12u1 Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, I have a remote server running bookworm that is configured to use dropbear-initramfs and cryptsetup-initramfs to unlock the LUKS container. The way I unlock it is shown below: $ until ssh r...@hopper-boot.rocketjump.eu cryptroot-unlock; do sleep 3; done ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection refused ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out ssh: connect to host hopper-boot.rocketjump.eu port 22: Connection timed out Please unlock disk md2_crypt Timeout, server hopper-boot.rocketjump.eu not responding. Please unlock disk md2_crypt Timeout, server hopper-boot.rocketjump.eu not responding. Please unlock disk md2_crypt Timeout, server hopper-boot.rocketjump.eu not responding. Timeout, server hopper-boot.rocketjump.eu not responding. Timeout, server hopper-boot.rocketjump.eu not responding. Timeout, server hopper-boot.rocketjump.eu not responding. ^C^C As you can see, while rebooting the connection is refused, as sshd is already shutdown, but the server is reachable. Then the connection times out while it's still doing a POST. At some point dropbear becomes reachable, as shown by the output of "Please unlock disk md2_crypt", however the connection seems to error out after a while, and after three attempts, dropbear becomes unresponsive. This forces me to hard reset the server and try again until I catch it in the right moment. After some debugging, it turns out that ServerAliveInterval != 0 will cause the ssh client to reset the connection, which dropbear will count as unlock attempt, and after three tries it will fail and drop to initramfs shell, after which it's not reachable anymore. It would be great to prominently document that dropbear(-initramfs) does not handle the ServerAliveInterval ssh client setting. Greets, Lee -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'proposed-updates'), (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-20-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dropbear-initramfs depends on: ii busybox 1:1.35.0-4+b3 pn dropbear-bin ii initramfs-tools 0.142 ii udev 252.23-1~deb12u1 Versions of packages dropbear-initramfs recommends: ii cryptsetup-initramfs 2:2.6.1-4~deb12u2 dropbear-initramfs suggests no packages.
Bug#1005910: apt provider does not grok Deb822 sources files
Hi Marc,
On Thu, 17 Feb 2022 09:30:06 +0100 Marc Haber
wrote:
Package: ansible
Version: 2.10.7+merged+base+2.10.8+dfsg-1
Severity: normal
Hi,
when using a Deb822 style sources file in apt, such as:
$ cat /etc/apt/sources.list.d/docker-stable.sources
Types: deb
URIs: https://download.docker.com/linux/debian
Suites: bullseye
Components: stable
Signed-By: /etc/apt/docker.gpg
$
ansible code like:
- name: configure apt - remove transitional packages
apt:
name: "{{ packages }}"
state: "absent"
vars:
packages:
- iproute
fails with:
fatal: [corte]: FAILED! => {"changed": false, "msg": "E:Malformed stanza 1 in source
list /etc/apt/sources.list.d/docker-stable.sources (type), E:The list of sources could not be read."}
Can you still reproduce this issue on bookworm? I tried with
$ ansible -m apt -a 'update_cache=yes' localhost -K --become
$ ansible -m apt -a 'name=0ad state=absent' localhost -K --become
and both command ran through without issue, despite having several deb822-style
files in /etc/apt/sources.list.d/*.sources
It seems as though the ansible apt module uses python3-apt, and there the
feature was enabled in:
python-apt (2.5.3) unstable; urgency=medium
[ Nick Rosbrook ]
* deb822: allow initializing a Deb822SourceEntry from string
* all: fix PEP8 formatting
* .gitlab-ci.yml: update typing stage to use venv
-- Julian Andres Klode Thu, 23 Feb 2023 21:38:02 +0100
Expected behavior would be the ansible run to succeed.
Greetings
Marc
-- System Information:
Debian Release: bookworm/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'stable-security'), (500,
'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.16.9-zgws1 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages ansible depends on:
ii openssh-client1:8.7p1-4
ii python3 3.9.8-1
ii python3-cryptography 3.4.8-1
ii python3-distutils 3.9.10-1
ii python3-dnspython 2.2.0-2
ii python3-httplib2 0.20.2-2
ii python3-jinja23.0.3-1
ii python3-netaddr 0.8.0-2
ii python3-packaging 21.3-1
ii python3-paramiko 2.8.1-1
ii python3-pycryptodome 3.11.0+dfsg1-3
ii python3-yaml 5.4.1-1+b1
Greets,
Lee
Bug#1042906: ansible: please package new upstream version 8.x
Hi, I'll try to upload a new version of ansible and ansible-core within the next week. On 14.04.24 10:00, Daniel Baumann wrote: retitle 1042906 please package new upstream version 9.x thanks Hi Lee, any updates since last year? Ansible is currently at 9.x and I'd really like to be able to use a recent enough version of ansible via debian packages. Is there anything I could help you with? Regards, Daniel
Bug#1068601: Acknowledgement (selinux-policy-default: /var with nosuid and SELinux enabled breaks dpkg)
The following dpkg.te seems to have solved the problem for me.
```
module dpkg 1.0;
require {
type dpkg_script_t;
type dpkg_t;
class process2 nosuid_transition;
}
```
On Sun, Apr 7, 2024, at 2:42 PM, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1068601:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068601.
>
> 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.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
> bl...@volian.org
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
> Debian SELinux maintainers
>
> If you wish to submit further information on this problem, please
> send it to 1068...@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.
>
> --
> 1068601: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068601
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>
Bug#1068601: selinux-policy-default: /var with nosuid and SELinux enabled breaks dpkg
Package: selinux-policy-default
X-Debbugs-Cc: bl...@volian.org
Version: 2:2.20240202-1
Severity: important
Hello,
I have been messing around with configuring Debian with CIS controls and using
SELinux.
The first problem I've encountered is that having `/var` configured with
`nosuid` option causes dpkg to break for scripts. An example of the error
message with `apt install vim`.
```
dpkg (subprocess): unable to execute new vim-runtime package pre-installation
script (/var/lib/dpkg/tmp.ci/preinst): Permission denied
dpkg: error processing archive
/var/cache/apt/archives/vim-runtime_2%3a9.1.0199-1_all.deb (--unpack):
new vim-runtime package pre-installation script subprocess returned error exit
status 2
dpkg (subprocess): unable to execute new vim-runtime package post-removal
script (/var/lib/dpkg/tmp.ci/postrm): Permission denied
dpkg: error while cleaning up:
new vim-runtime package post-removal script subprocess returned error exit
status 2
```
`audit2why -a` gives me
```
type=AVC msg=audit(1712517197.064:359): avc: denied { nosuid_transition } for
pid=5633 comm="dpkg" scontext=unconfined_u:unconfined_r:dpkg_t:s0-s0:c0.c1023
tcontext=unconfined_u:unconfined_r:dpkg_script_t
:s0-s0:c0.c1023 tclass=process2 permissive=0
```
and then `audit2why -a` gives me
```
#= dpkg_t ==
allow dpkg_t dpkg_script_t:process2 nosuid_transition;
```
I think due to the importance of dpkg in the Debian ecosystem this should
probably be allowed in the global policy.
Also it seems that the salsa repository for refpolicy is not up-to-date with
the package that is being distributed. Salsa still shows refpolicy 2022, but
I'm seeing 2024 installed on my system. If this could be resolved I'd like to
fork the repo and tinker with the policy.
Thanks,
Blake
-- System Information:
Debian Release: trixie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.7.9-amd64 (SMP w/4 CPU threads; PREEMPT)
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: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Permissive - Policy name: default
Versions of packages selinux-policy-default depends on:
ii libselinux1 3.5-2+b1
ii libsemanage2 3.5-1+b3
ii libsepol23.5-2
ii policycoreutils 3.5-2
ii selinux-utils3.5-2+b1
Versions of packages selinux-policy-default recommends:
ii checkpolicy 3.5-1
pn setools
Versions of packages selinux-policy-default suggests:
pn logcheck
pn syslog-summary
-- no debconf information
Bug#1059030: closed by Safir Secerovic (Fixed in version 1.0-1)
This still seems to be an issue ion stable On 3/25/24 08:12, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the goverlay package: #1059030: goverlay missing dependency libglu1-mesa It has been closed by Safir Secerovic . Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Safir Secerovic by replying to this email.
Bug#1053565: RFS: openvpn3-client/21+dfsg-1 [ITP] -- virtual private network daemon (version 3)
Package: sponsorship-requests Followup-For: Bug #1053565 X-Debbugs-Cc: ajq...@debian.org Hi Marc, Thank you for your efforts in packaging this package into Debian. I noticed that you conducted a thorough license check and re-uploaded the package into mentors. However, there are still some lintian warnings/errors present in the `debian/copyright` file. Please ensure to check this on the webpage after uploading, or preferably, run a local lintian check before uploading or committing. Additionally, Tobi suggested that the Python component might be better suited in a dedicated Python module package. What are your thoughts on this? Best regards, -Andrew
Bug#1065320: linux-image-6.1.0-18-amd64: 6.1.0-18 kernel enters ACPI Error loop during boot & requires power cycle
Package: src:linux Version: 6.1.76-1 Severity: critical Justification: breaks the whole system X-Debbugs-Cc: leeejobsacco...@mail.co.uk Dear Maintainer, * What led up to the situation? Trying to boot the system with the 6.1.0-18 kernel * What exactly did you do (or not do) that was effective (or ineffective)? I tried adding 'boot_delay=1000' boot option to slow the console scroll rate, to enable better recording of the error messages. I tried rebooting the previous 6.1.0-17 kernel. * What was the outcome of this action? After adding the 'boot_delay=1000' option the boot process progressed no further than "Loading initial ramdisk ..." (left for several minutes - required power cycle). The system boots sucessfully on the previous 6.1.0-17 kernel * What outcome did you expect instead? I expected the system to successfully boot. * Additional observations This system also normally includes 'hpet=disable' and 'acpi_enforce_resources=lax' boot options but removing these made no difference. Although I was not able to boot the system with the 'boot_delay=1000' option and obtain clear photographs of the console output - the ones I've attached suffer from 'overprinting' - it does seem clear that ACPI errors are being reported. There appear to be two distinct phases to this problem. Initially, ACPI seems to be reporting errors for "GPE", as shown in the first attached photograph, but after ~10 seconds or so, ACPI then switches to continuously reporting an error for PM_TIMER, as shown in the second attached photograph. At this point a power cycle is required. Purging and reinstalling the package made no difference. Atm, only three kernels are installed on this system but I have had more in the past as I normally compile my own kernels from the corresponding Debian source package. My own 6.1.76-1 kernel also suffers from the same problem, whereas my own 6.1.69-1 kernel boots and runs Ok. Comparing the kernel configs for 6.1.0-17 and 6.1.0-18 showed just one functional change - an additional Compile-time checks and compiler option, which did not seem relevant to this problem. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: ASUSTeK COMPUTER INC. product_name: E203NA product_version: 1.0 chassis_vendor: ASUSTeK COMPUTER INC. chassis_version: 1.0 bios_vendor: American Megatrends Inc. bios_version: E203NA.312 board_vendor: ASUSTeK COMPUTER INC. board_name: E203NA board_version: 1.0 ** Network interface configuration: *** /etc/network/interfaces: source /etc/network/interfaces.d/* auto lo iface lo inet loopback ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge [8086:5af0] (rev 0b) Subsystem: ASUSTeK Computer Inc. Celeron N3350/Pentium N4200/Atom E3900 Series Host Bridge [1043:1980] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- Kernel driver in use: proc_thermal Kernel modules: processor_thermal_device_pci_legacy 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 500 [8086:5a85] (rev 0b) (prog-if 00 [VGA controller]) Subsystem: ASUSTeK Computer Inc. HD Graphics 500 [1043:1980] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Capabilities: [70] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE+ FLReset+ DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- DevCap2: Completion Timeout: Not Supported, TimeoutDis- NROPrPrP- LTR- 10BitTagComp- 10BitTagReq- OBFF Not Supported, ExtFmt- EETLPPrefix- EmergencyPowerReduction Not Supported, EmergencyPowerReductionInit- FRS- AtomicOpsCap: 32bit- 64bit- 128bitCAS- DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis- LTR- 10BitTagReq- OBFF Disabled, AtomicOpsCtl: ReqEn- Capabilities: [ac] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee00018 Data: Capabilities: [d0] Power Management version 2 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0
Bug#1061683: qemu-guest-agent.service does not restart on upgrade, loosing connectivity
Package: qemu-guest-agent
Version: 1:7.2+dfsg-7+deb12u3
Severity: normal
X-Debbugs-Cc: deb...@rocketjump.eu
Hi,
today I noticed one of my VMs was not accessible via the guest agent. Turns out
that during upgrade it was stopped, but not restarted again. Since it can be
used for automation, I believe it's crucial that qemu-ga service tries harder to
stay alive.
Terminal logs below.
--->8->8->8->8->8->8->8->8->8->8--
root@comms:~# systemctl status qemu-guest-agent.service
○ qemu-guest-agent.service - QEMU Guest Agent
Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static)
Active: inactive (dead) since Sun 2023-12-10 06:36:40 CET; 1 month 18 days
ago
Duration: 1month 3w 16h 24min 38.992s
Main PID: 205124 (code=exited, status=0/SUCCESS)
CPU: 1min 46.804s
Nov 30 17:42:36 comms qemu-ga[205124]: info: guest-exec-status called, pid:
619187
Nov 30 17:42:36 comms qemu-ga[205124]: info: guest-exec-status called, pid:
619187
Nov 30 17:42:37 comms qemu-ga[205124]: info: guest-exec-status called, pid:
619187
Nov 30 17:42:38 comms qemu-ga[205124]: info: guest-exec-status called, pid:
619187
Nov 30 17:42:38 comms qemu-ga[205124]: info: guest-exec called: "/bin/sh -c rm
-f -r /root/.ansible/tmp/ansible-tmp-1701362549.8043833-135706-120368687298004/
> /dev/null 2>
Nov 30 17:42:38 comms qemu-ga[205124]: info: guest-exec-status called, pid:
619913
Dez 10 06:36:40 comms systemd[1]: Stopping qemu-guest-agent.service - QEMU
Guest Agent...
Dez 10 06:36:40 comms systemd[1]: qemu-guest-agent.service: Deactivated
successfully.
Dez 10 06:36:40 comms systemd[1]: Stopped qemu-guest-agent.service - QEMU Guest
Agent.
Dez 10 06:36:40 comms systemd[1]: qemu-guest-agent.service: Consumed 1min
46.804s CPU time.
root@comms:~# systemctl start qemu-guest-agent.service
root@comms:~# systemctl status qemu-guest-agent.service
● qemu-guest-agent.service - QEMU Guest Agent
Loaded: loaded (/lib/systemd/system/qemu-guest-agent.service; static)
Active: active (running) since Sat 2024-01-27 22:32:06 CET; 2s ago
Main PID: 1263386 (qemu-ga)
Tasks: 2 (limit: 9475)
Memory: 1.8M
CPU: 28ms
CGroup: /system.slice/qemu-guest-agent.service
└─1263386 /usr/sbin/qemu-ga
Jan 27 22:32:06 comms systemd[1]: Started qemu-guest-agent.service - QEMU Guest
Agent.
root@comms:~# cat /lib/systemd/system/qemu-guest-agent.service
[Unit]
Description=QEMU Guest Agent
BindsTo=dev-virtio\x2dports-org.qemu.guest_agent.0.device
After=dev-virtio\x2dports-org.qemu.guest_agent.0.device
[Service]
ExecStart=-/usr/sbin/qemu-ga
Restart=always
RestartSec=0
[Install]
root@comms:~# zless /var/log/apt/history.log.1.gz
Start-Date: 2023-12-10 06:36:40
Commandline: /usr/bin/unattended-upgrade
Upgrade: qemu-guest-agent:amd64 (1:7.2+dfsg-7+deb12u2, 1:7.2+dfsg-7+deb12u3),
qemu-utils:amd64 (1:7.2+dfsg-7+deb12u2, 1:7.2+dfsg-7+deb12u3)
End-Date: 2023-12-10 06:36:42
--->8->8->8->8->8->8->8->8->8->8--
Looking at the maintainer scripts, it looks like it gets stopped by this
section in the .preinst:
# End automatically added section
# Automatically added by dh_installsystemd/13.11.4
if [ -z "${DPKG_ROOT:-}" ] && [ "$1" = upgrade ] && [ -d /run/systemd/system ]
; then
deb-systemd-invoke stop 'qemu-guest-agent.service' >/dev/null || true
fi
# End automatically added section
And nothing ever starts it again. My next guess was that the systemd unit might
not have been enabled, so I tried that:
root@comms:~# systemctl enable qemu-guest-agent.service
Synchronizing state of qemu-guest-agent.service with SysV service script with
/lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable qemu-guest-agent
The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
.wants/, .requires/, or .upholds/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
instance name specified.
It seems like it's only enabled by the udev device trigger, which is never
triggered on upgrade.
I think it's missing a `systemctl start qemu-guest-agent` in .postinstall, do
you agree?
Greets,
Lee
-- System Information:
Debian Release: 12.4
APT prefers stable-updates
APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990,
'proposed-updates'), (990, 'stable'
Bug#1061553: Duplicate uuids in password-gorilla password store
Package: password-gorilla Version: 1.6.0~git20180203.228-1 Severity: normal Tags: upstream X-Debbugs-Cc: bell...@snarkjaeger.ch Dear Maintainer, The duplicate uuids do not appear to affect the operation of password-gorilla itself, but may affect the working of utilities on other platforms that use the same password store file format and provide the same functionality. I encountered the problem after copying a password database generated by password-gorilla to an android smartphone and used it with the PasswdSafe app. Duplicate uids in the file resulted in the android app displaying incorrect information for some entries and copying incorrect information to the clipboard. Problem is known and is fixed in a later version of password-gorilla. Using later version of password-gorilla corrects uuid generation and repairs password database files that are affected by the problem. I have confirmed that using a repaired password database file for the android PasswdSafe app produces the expected display and clipboard copy of the information requested. password-gorilla version 1.6.0~git20180203.228-1 aka 1.6.0 beta1 is now quite old, a more recent "1.6.0 beta-2" version is available. Request that this newer version is packaged into the next Debian release. Background password-gorilla is an implementation of the functionality of the Password Safe utility originally implemented on Windows; the functionality has been implemented for other platforms including the PasswdSafe app on Android. (The current version of the Windows utility (3.65.0) recognises and repairs duplicated uuids.) For android PasswdSafe discussion of the problem, see https://sourceforge.net/p/passwdsafe/discussion/1067588/ (PasswdSafe on SourceForge ... Discussion ... Help ... "problem with psafe3 file from password gorilla".) For password-gorilla description of problem and correction see https://github.com/zdia/gorilla/issues/203 Problem is fixed in password gorilla 1.6.0 beta-2 which can be downloaded as a system-independent "kit" file from https://gorilla.dp100.com/downloads/ It can be run using the appropriate tclkit executable from https://gorilla.dp100.com/downloads/tclkit/ and this is the method I used to confirm that the problem as I encountered it is fixed in version 1.6.0 beta-2. I imagine that the same procedure that was used to package the beta1 version for Debian distribution will also work for beta-2. Regards Peter Lee (bell...@snarkjaeger.ch) -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-15-generic (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages password-gorilla depends on: ii itcl3 3.4.3-3.1 ii tcl 8.6.11+1build2 ii tcllib 1.20+dfsg-1 ii tk 8.6.11+1build2 ii tklib 0.7+20210111-1 password-gorilla recommends no packages. password-gorilla suggests no packages. -- no debconf information
Bug#1060847: planets: Typo in package description
Package: planets Version: 0.1.13-20+b5 Severity: minor There is a minor typo in the package's description. Excerpt from `apt-cache show planets`: "The user interface is aimed at being simple enough for a fairly young kid to enjoy it, their is a special kid-mode for this purpose." Notice that "their" should be "there" instead. Fixed sentence: "The user interface is aimed at being simple enough for a fairly young kid to enjoy it. There is a special kid-mode for this purpose." -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64)
Bug#1060845: ghostscript: Add AppArmor profile
Package: ghostscript Version: 10.0.0~dfsg-11+deb12u3 Severity: wishlist Please consider shipping an AppArmor profile in the "ghostscript" package. It might be prudent to add an AppArmor profile to reduce the potential damage of Ghostscript bugs because: 1. Ghostscript is commonly used to process untrusted input (e.g. before PDF files are sent to a printer). 2. A relatively large number of security vulnerabilities have been found in Ghostscript over the years [1]. [1]: https://security-tracker.debian.org/tracker/source-package/ghostscript -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ghostscript depends on: ii libc6 2.36-9+deb12u3 ii libgs10 10.0.0~dfsg-11+deb12u3 ghostscript recommends no packages. ghostscript suggests no packages. -- no debconf information
Bug#1060277: pdfproctools: typo in setpdfmetadata man page
Package: pdfproctools Version: 1.9.4-1 Severity: minor Dear Maintainer, There is a typo in man page of setpdfmetadata: title Subject Sets the document subject to the given value. It should probably be "subject Subject" instead of "title Subject". -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-17-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pdfproctools depends on: ii ghostscript 10.0.0~dfsg-11+deb12u3 ii libpdf-api2-perl 2.044-1 ii perl 5.36.0-7+deb12u1 ii qpdf 11.3.0-1+deb12u1 pdfproctools recommends no packages. pdfproctools suggests no packages.
Bug#1059702: apparmor-profiles: Firefox profile should confine firefox-esr
Package: apparmor-profiles Version: 3.0.8-3 Severity: wishlist The Firefox profile 'usr.lib.firefox.firefox' does not confine the firefox-esr binary (/usr/lib/firefox-esr/firefox-esr). The AppArmor profile for Firefox should include support for the firefox-esr binary, since firefox-esr is the default Firefox for Debian stable. -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-16-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages apparmor-profiles depends on: ii apparmor 3.0.8-3 apparmor-profiles recommends no packages. apparmor-profiles suggests no packages. -- no debconf information
Bug#833278: firefox-esr: lack of apparmor profile
On Wed, 4 Dec 2019 02:15:16 +0300 dinar qurbanov wrote:
> it is in apparmor-profiles package:
> https://packages.debian.org/stretch/all/apparmor-profiles/filelist
For Debian bookworm, an AppArmor profile is also available in the
apparmor-profiles package, but that profile is obsolete. It confines
binaries that match /usr/lib/firefox{,-[0-9]*}/firefox{,*[^s][^h]}
[1], which would not match the current location of the firefox-esr
binary which is at /usr/lib/firefox-esr/firefox-esr.
Debian should definitely ship an AppArmor profile with the firefox-esr
package. Web browsers are widely installed and have lots of security
vulnerabilities.
[1]:
https://salsa.debian.org/apparmor-team/apparmor/-/blob/debian/3.0.8-3/profiles/apparmor/profiles/extras/usr.lib.firefox.firefox#L21
Bug#947002: wxmaxima version 19.07.0 onwards cannot display properly exponents
I cannot reproduce this problem in wxMaxima version 22.12.0 of Debian Bookworm (current Debian stable). Is the problem fixed?
Bug#1059563: wxmaxima: Blank image when copying/saving selection to image
Package: wxmaxima Version: 22.12.0-1 Severity: normal In wxmaxima, when I right-click on a cell, then click on "Copy as Image", then paste the image into another application (LibreOffice, for example), the pasted image is blank (completely white). Similarly, if I select some cell(s) and try to save those cell(s) as a PNG image via "Edit" > "Save Selection to Image..." in the menu bar, the saved PNG image is blank (all white). -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-16-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages wxmaxima depends on: ii libc6 2.36-9+deb12u3 ii libgcc-s1 12.2.0-14 ii libstdc++6 12.2.0-14 ii libwxbase3.2-1 3.2.2+dfsg-2 ii libwxgtk-webview3.2-1 3.2.2+dfsg-2 ii libwxgtk3.2-1 3.2.2+dfsg-2 ii maxima 5.46.0-11 Versions of packages wxmaxima recommends: ii maxima-doc 5.46.0-11 Versions of packages wxmaxima suggests: ii fonts-jsmath 0.090709+0-4 ii ibus-gtk3 1.5.27-5 ii texlive-latex-extra 2022.20230122-4 -- no debconf information
Bug#1059030: goverlay missing dependency libglu1-mesa
Package: goverlay Version: 0.9.1-1 Severity: important Dear Maintainer, Attempting to open Goverlay to try out the packlage as I'm fairly new to trying out mangohud. After trying to launch it via a graphical application launcher (in this case rofi) I got the result of no action. So as a good linux user I fire up ye old faithful terminal and attempt to run goverlay from there netting this response: joshua@desktop:~$ goverlay [FORMS.PP] ExceptionOccurred Sender=Exception Exception=Could not load library: libGLU.so.1 Stack trace: $005F720B Exception at 005F720B: Exception: Could not load library: libGLU.so.1. After a quick apt search libglu I saw that libglu1-mesa was not installed and as a curious I just install it and now goverlay launches fine. Checking both testing and unstable branches I see that it's called there as a dependency. So since this fix was simple can someone add libglu1-mesa as a depency for this package? I would work on submitting the patch myself but I'll be honest and say I don't know the first thing about working with a deb file. *** End of the template - remove these template lines *** -- System Information: Debian Release: 12.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/12 CPU threads; PREEMPT) 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: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages goverlay depends on: ii libc6 2.36-9+deb12u3 ii libgl1 1.6.0-1 ii libqt5pas1 2.6+2.2.0+dfsg1-3 ii libx11-6 2:1.8.4-2+deb12u2 ii mangohud 0.6.8-2 ii mesa-utils 8.5.0-1 ii vulkan-tools 1.3.239.0+dfsg1-1 Versions of packages goverlay recommends: ii gamescope 3.11.49-1 ii git 1:2.39.2-1.1 ii vkbasalt 0.3.2.8-1 goverlay suggests no packages. -- no debconf information
Bug#1058657: python3-apt: undefined symbol: PyAptWarning
This bug can be reproduced with just a single import statement ``` import apt_inst ```
Bug#1057744: nmap: bring back zenmap
Package: nmap Version: 7.93+dfsg1-1 Severity: wishlist Some time ago, zenmap was removed due to being stuck back on python 2, but as of nmap 0.94 [1] it has been brought up to date to use python 3 and gobject, so hopefully it can now be brought back to Debian? [1] https://github.com/nmap/nmap/blob/e47b742669e6aadcab8aaa16d123d8fa4832fe5d/CHANGELOG#L13
Bug#1056601: No module named
Hi Daniel!
On 23.11.23 20:08, Daniel Leidert wrote:
Package: ansible
Version: 7.7.0+dfsg-3
Severity: normal
When trying to use the community.general.ssh_config module, I receive:
An exception occurred during task execution. To see the full traceback, use
-vvv. The error was: ModuleNotFoundError: No module named 'paramiko' fatal:
[localhost]: FAILED! => {"changed": false, "msg": "Failed to import the
required Python library (PARAMIKO) on [hostname]'s Python /usr/bin/python3.
Please read the module documentation and install it in the appropriate
location. If the required library is installed, but Ansible is using the wrong
Python interpreter, please consult the documentation on
ansible_python_interpreter"}
Indeed. Did you try installing paramiko on the host you're executing it? This is
documented in the upstream docs:
https://docs.ansible.com/ansible/latest/collections/community/general/ssh_config_module.html
Since this is most of the time not the host that has ansible installed, changing
any dependencies on the package won't make any sense.
The name in Debian for this module is python3-paramiko.
By the way:
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'oldstable-updates'), (500, 'oldstable-security'), (500, 'unstable'), (500,
'testing'), (500, 'stable'), (500, 'oldstable')
We generally recommend against mixing releases, this is not supported and will
bite you sooner or later. It's better to just run unstable and removing any
residue package from older releases.
Regards,
Lee
Bug#1055616: ansible-core: ansible.builtin.setup does not include facts from facter.
Hi Andy, On 10.11.23 20:31, andrew bezella wrote: On Fri, 2023-11-10 at 12:39 +0100, Lee Garrett wrote: Hi Andrew, hello - On 08.11.23 22:40, andrew bezella wrote: [...] i was eventually able to build an updated version of bookworm's ansible-core .deb including commit id 4b0d014. this task was made more difficult by the current FTBFS status of ansible-core but the patch allowed ansible.builtin.setup to include facts from facter: Can you elaborate please? AFAICS ansible-core builds fine in stable and sid. it wouldn't build in pbuilder and it shows up on the "Packages in bookworm/amd64 which failed to build from source" page[1]. but from the changelog it looks like you found and fixed the locale issue that i was running up against: ERROR: Ansible requires the locale encoding to be UTF-8; Detected None. Indeed! I didn't notice it before because the reproducible build daemons apparently set a different locale than the regular build daemons. But it should be fixed now. i spent a bunch of time fiddling w/pbuilder to find the "right" answer but eventually just brute-forced it[2]. your solution is much better! thank you for the prompt turnaround. i would suggest/ask that the facter fix be included in bookworm, too; the lack of expected facts can have unexpected and significant impact on a playbook's run. I'm working on the upload right now. It should hopefully be available in bookworm-proposed-updates in the next few days. thanks again! andy 1. https://tests.reproducible-builds.org/debian/bookworm/amd64/index_FTBFS.html 2. https://bugs.launchpad.net/ubuntu/+source/pbuilder/+bug/1947424/comments/10 Greetings, Lee
Bug#1055616: ansible-core: ansible.builtin.setup does not include facts from facter.
Hi Andrew,
On 08.11.23 22:40, andrew bezella wrote:
Package: ansible-core
Version: 2.14.3-1
Severity: normal
Dear Maintainer,
i installed ansible-core and facter 4.3.0-2 in bookworm. when testing
i found that the facts from facter were not being included by the
setup module:
% ansible -b localhost -m ansible.builtin.setup -a 'filter=facter_*'
[WARNING]: No inventory was parsed, only implicit localhost is available
localhost | SUCCESS => {
"ansible_facts": {},
"changed": false
}
this issue has appeared upstream and was resolved by:
setup module, retry facter to handle --puppet errors by bcoca · Pull Request
#80645 · ansible/ansible · GitHub
https://github.com/ansible/ansible/pull/80645
Thank you for the bug report! I've been able to reproduce the bug and will
prepare an upload for sid and bookworm shortly.
i was eventually able to build an updated version of bookworm's
ansible-core .deb including commit id 4b0d014. this task was made
more difficult by the current FTBFS status of ansible-core but the
patch allowed ansible.builtin.setup to include facts from facter:
Can you elaborate please? AFAICS ansible-core builds fine in stable and sid.
% ansible -b localhost -m ansible.builtin.setup -a 'filter=facter_*'
[WARNING]: No inventory was parsed, only implicit localhost is available
localhost | SUCCESS => {
"ansible_facts": {
"facter_disks": {
"sda": {
[...]
"facter_timezone": "UTC",
"facter_virtual": "physical"
},
"changed": false
}
thanks in advance for addressing this.
andy
Greetings,
Lee
Bug#1054230: Please change permissions on /var/lib/libvirt/images/
Package: libvirt-daemon-system Version: 9.0.0-4 Severity: wishlist X-Debbugs-Cc: deb...@rocketjump.eu Hi, Currently, the permissions for /var/lib/libvirt/images are root:root u=rwx,go=x. It would be nice to change those to root:libvirt ug=rwx,o=x. This should not change anything from the security standpoint, as users of the libvirt group can already interact with libvirtd and add/remove/modify VMs. The upside would be that virt-v2v can run without root permissions, as it directly writes to that dir. I have verified that changing the permissions allows virt-v2v to run rootless. For completeness, this is the command line I've tested it with: virt-v2v -i ova -o libvirt -of qcow2 -oo compressed -oc 'qemu:///system' win11.zip -on win11trial Regards, Lee -- System Information: Debian Release: 12.2 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvirt-daemon-system depends on: ii adduser 3.134 ii debconf [debconf-2.0] 1.5.82 ii gettext-base0.21-12 ii iptables1.8.9-2 ii libvirt-clients 9.0.0-4 ii libvirt-daemon 9.0.0-4 ii libvirt-daemon-config-network 9.0.0-4 ii libvirt-daemon-config-nwfilter 9.0.0-4 ii libvirt-daemon-system-systemd 9.0.0-4 ii logrotate 3.21.0-1 ii polkitd 122-3 Versions of packages libvirt-daemon-system recommends: ii dmidecode3.4-1 ii dnsmasq-base [dnsmasq-base] 2.89-1 ii iproute2 6.1.0-3 ii mdevctl 1.2.0-3+b1 ii parted 3.5-3 Versions of packages libvirt-daemon-system suggests: ii apparmor3.0.8-3 pn auditd pn nfs-common pn open-iscsi pn pm-utils ii systemd 252.17-1~deb12u1 pn systemtap pn zfsutils -- Configuration Files: /etc/default/libvirt-guests changed [not included] /etc/libvirt/qemu.conf [Errno 13] Permission denied: '/etc/libvirt/qemu.conf' -- debconf information excluded
Bug#1054220: Off-by-one when selecting days in activity window
Package: hamster-time-tracker
Version: 3.0.2-4
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu
Hi,
steps to reproduce:
- click on the + icon ("add activity") in the main window
- on the start time, clik on the arrow next to the date
- (a calendar pops up)
- click on e.g. Wednesday, October 18
- notice that the cmdline sets it to 2023-10-17, a whole day wrong
This also happens when editing previous activities to update them. Clicking back
and forth on the calendar will make the offset increase, being ±2 days, then ±3
days, etc.
I suspected it might be related to locale, but running `LC_ALL=C hamster` did
not change the outcome of the bug.
severity "important" as this tool is probably used by many freelancers to track
time, and wrong timetracking results in loss of income or overbilling.
Regards,
Lee
-- System Information:
Debian Release: 12.2
APT prefers stable-updates
APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-13-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages hamster-time-tracker depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.40.0-4
ii gir1.2-gtk-3.0 3.24.38-2~deb12u1
ii libjs-jquery 3.6.1+dfsg+~3.5.14-1
ii libjs-jquery-ui 1.13.2+dfsg-1
ii python3 3.11.2-1+b1
ii python3-cairo1.20.1-5+b1
ii python3-dbus 1.3.2-4+b1
ii python3-distutils3.11.2-3
ii python3-gi 3.42.2-3+b1
ii python3-xdg 0.28-2
Versions of packages hamster-time-tracker recommends:
ii gnome-shell-extension-hamster 0.10.0+git20210628-4
ii yelp 42.2-1
hamster-time-tracker suggests no packages.
-- no debconf information
Bug#1053777: Man pages causes troff to warn about use of `CB` font
Package: pandoc Version: 2.17.1.1-3 Severity: normal Dear Maintainer, I was building one of my programs to upload and I came across a new warning that lintian doesn't like. W: nala: groff-message troff::5: warning: cannot select font 'CB' [usr/share/man/man8/nala.8.gz:1] It looks like this is fixed upstream in 3.1.7. I notice now that the Debian version is quite behind upstream. Is there any plans to update it to current? I found some similar bug reports such as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040975 Thanks, Blake -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.5-x64v3-xanmod1 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: default Versions of packages pandoc depends on: ii libc62.37-12 ii libffi8 3.4.4-1 ii libgmp10 2:6.3.0+dfsg-2 ii liblua5.3-0 5.3.6-2 ii libyaml-0-2 0.2.5-1 ii pandoc-data 2.17.1.1-3 ii zlib1g 1:1.2.13.dfsg-3 pandoc recommends no packages. Versions of packages pandoc suggests: pn citation-style-language-styles pn context pn ghc pn groff pn libjs-katex pn libjs-mathjax pn librsvg2-bin pn nodejs pn pandoc-citeproc ii perl5.36.0-9 pn php pn python pn r-base-core pn ruby pn texlive-latex-extra pn texlive-latex-recommended pn texlive-luatex pn texlive-xetex pn wkhtmltopdf -- no debconf information
Bug#1052405: libvirtd floods journal with unhelpful message
Package: libvirt-daemon Version: 9.0.0-4 Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, when running a Windows 11 VM, and provisioning it via ansible, the journal is getting flooded with > 50 messages per second: Sep 21 15:31:29 batou libvirtd[402313]: Domain id=1 name='win11trial' uuid=4d871bc4-364f-47d7-a498-005bf10ee6d6 is tainted: custom-ga-command Sep 21 15:31:29 batou libvirtd[402313]: Domain id=1 name='win11trial' uuid=4d871bc4-364f-47d7-a498-005bf10ee6d6 is tainted: custom-ga-command Sep 21 15:31:29 batou libvirtd[402313]: Domain id=1 name='win11trial' uuid=4d871bc4-364f-47d7-a498-005bf10ee6d6 is tainted: custom-ga-command Sep 21 15:31:29 batou libvirtd[402313]: Domain id=1 name='win11trial' uuid=4d871bc4-364f-47d7-a498-005bf10ee6d6 is tainted: custom-ga-command A search on the upstream documentation does not explain what this means, and it seems it was reported on various other sites (reddit, stackoverflow, etc.) without an answer to it. Would be nice to have documented what this means, if I need to take action, and how to disable the warning if it turns out to not be harmful. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libvirt-daemon depends on: ii libacl1 2.3.1-3 ii libblkid1 2.38.1-5+b1 ii libc6 2.36-9+deb12u1 ii libdevmapper1.02.1 2:1.02.185-2 ii libgcc-s1 12.2.0-14 ii libglib2.0-02.74.6-2 ii libparted2 3.5-3 ii libpcap0.8 1.10.3-1 ii libpciaccess0 0.17-2 ii libselinux1 3.4-1+b6 ii libtirpc3 1.3.3+ds-1 ii libudev1252.12-1~deb12u1 ii libvirt-daemon-driver-qemu 9.0.0-4 ii libvirt09.0.0-4 ii libxml2 2.9.14+dfsg-1.3~deb12u1 Versions of packages libvirt-daemon recommends: ii libvirt-daemon-driver-lxc 9.0.0-4 pn libvirt-daemon-driver-vbox pn libvirt-daemon-driver-xen ii libxml2-utils 2.9.14+dfsg-1.3~deb12u1 ii lvm22.03.16-2 ii mount 2.38.1-5+b1 ii netcat-openbsd 1.219-1 ii qemu-system-x86 [qemu-kvm] 1:7.2+dfsg-7+deb12u1 Versions of packages libvirt-daemon suggests: pn libvirt-daemon-driver-storage-gluster pn libvirt-daemon-driver-storage-iscsi-direct pn libvirt-daemon-driver-storage-rbd pn libvirt-daemon-driver-storage-zfs ii libvirt-daemon-system 9.0.0-4 pn numad -- no debconf information
Bug#1050906: reject non-conforming mail with helpful message when sending to d-d-a
Hello Cord, On 17.09.23 12:02, Cord Beermann wrote: tags 1050906 wontfix severity 1050906 wishlist thanks Hallo! Du (Lee Garrett) hast geschrieben: >From a user experience it's currently a bit cumbersome, as I'll send a mail, wait 15 minutes to notice that it hasn't arrived, change a few things and resend, wait another 15 minutes, etc. Which is quite an ineffective workflow. Rejecting based on Mail content is discouraged by a RfC. I was curious about that and re-read the current RFC related to SMTP. It clearly states that the preference is ACCEPT > REJECT > BOUNCE > DISCARD. [0] To quote: "If they cannot be delivered, and cannot be rejected by the SMTP server during the SMTP transaction, they should be "bounced" (returned with non-delivery notification messages) as described above." This also aligns with the best current practice as propagated from IRC #postfix admins: mantras: 1. do not accept mail that you do not intend to deliver. 2. do not drop mail. 3. do not use wildcards or catchalls. 4. do not forward mail to outside/third party systems Accepting then discarding the mail would violate #1 and #2 of those mantras. Discarding is only preferred over bouncing when the mail clearly contains "hostile content" (spam, malware, etc.). I would not count a malformed signature as such. In fact, discarding is strongly discouraged in RFC 5321: "As discussed in Section 7.8 and Section 7.9 below, dropping mail without notification of the sender is permitted in practice. However, it is extremely dangerous and violates a long tradition and community expectations that mail is either delivered or returned. If silent message-dropping is misused, it could easily undermine confidence in the reliability of the Internet's mail systems. So silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate." I have also not found anything that could be read as rejecting mail based on content is discouraged. That would also be very surprising as spam filtering and rejection of such mail is widespread practice. If we would reject misdirected mails to our lists we would produce 2 backscatter mails daily to mostly innocent netizens. As mentioned in the previous mail, rejecting during SMTP dialog will not result in backscatter originating from Debian's MX. In contemporary setups, the MUA will open a SMTP submission connection, the submission MX will keep the SMTP dialog open and connect to the Debian MX, receive a reject, and backpropagate it to the MUA. In practice the actual rejection message will be displayed in the MUA, and the submission will fail. If there is a temporary error (4xx), the submission MX might still queue the mail, but in that case any DSN will originate from the submission MX, outside of Debian's MX. And DSNs generated by other people's MX are IMHO not Debian's problem domain. So in the current state of Mail-Federation which is mostly driven by spamming monopolists I don't see a working solution. Yours, Cord, Debian Listmaster of the day [0] https://datatracker.ietf.org/doc/html/rfc5321#section-6.2 Best regards, Lee
Bug#1050906: reject non-conforming mail with helpful message when sending to d-d-a
Hi Cord, On 17.09.23 12:02, Cord Beermann wrote: tags 1050906 wontfix severity 1050906 wishlist thanks Hallo! Du (Lee Garrett) hast geschrieben: >From a user experience it's currently a bit cumbersome, as I'll send a mail, wait 15 minutes to notice that it hasn't arrived, change a few things and resend, wait another 15 minutes, etc. Which is quite an ineffective workflow. Rejecting based on Mail content is discouraged by a RfC. If we would reject misdirected mails to our lists we would produce 2 backscatter mails daily to mostly innocent netizens. Rejecting ingress mails at the SMTP level can't and won't create backscatter mails. You're probably thinking of bouncing mails? So in the current state of Mail-Federation which is mostly driven by spamming monopolists I don't see a working solution. Yours, Cord, Debian Listmaster of the day
Bug#1052125: nala cannot install the debreate package
I was able to reproduce this on my system. First this is the error that happens when installing. This is what crashes Nala because of the formatter. ``` Traceback (most recent call last): File "/usr/bin/debreate", line 230, in main() File "/usr/bin/debreate", line 27, in main import globals.paths File "/usr/share/debreate/globals/paths.py", line 16, in import libdbr.paths File "/usr/share/debreate/lib/libdbr/paths.py", line 18, in from . import sysinfo File "/usr/share/debreate/lib/libdbr/sysinfo.py", line 37, in if not __os_name: ^ NameError: name '__os_name' is not defined ``` This portion happens with apt as well, although apt doesn't crash. If you use --raw-dpkg switch with Nala it will complete. I have already fixed this crash upstream but haven't released yet. I would say you should likely report this to the debreate devs, even getting the install to complete with apt, the same error is thrown when I try to run the program.
Bug#1051943: Document requirements for sending mails to mailing lists which require GPG signature
Package: lists.debian.org Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, it would be nice to have a checklist of things to check for sending mails to mailing lists that require a GPG signature. So far it is at least: - No whitespace or unsigned text (#1050915), excluding Thunderbird as mail client - Requiring re-signing the mail content on every new delivery attempt (#1051941) - Informing that invalid mails get blackholed, and not rejected (#1050906) - Info on where the keys are sourced from, to be able to check for e.g. expired keys - Document where to ask when mails still don't go through (#debian-lists on irc.oftc.net) Ideally this should then be linked from the respective overview pages to easily be found, e.g. https://lists.debian.org/debian-devel-announce/ Greetings, Lee
Bug#1051941: replay cache accepts signed mail before it goes through to mailing list
Package: lists.debian.org Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, when sending a malformed mail to a mailing list requiring a valid PGP signature, the replay cache will add signature to the cache, but then get rejected in a later step. This results in any later attempts to send the signed mail to silently fail (#1050906), even though it would otherwise have a valid signature and be correctly formed. It would be nice if the signature verification check would be last in the milter list to mitigate this issue. Regards, Lee
Bug#1051770: move services and binaries for AD DC setup to package samba-ad-dc
On Tue, 12 Sep 2023 14:24:09 +0300 Michael Tokarev wrote: Control: tag -1 + moreinfo 12.09.2023 14:14, Lee Garrett wrote: > Source: samba > Severity: minor > X-Debbugs-Cc: deb...@rocketjump.eu > > Hi, > > I believe it would be a good idea to move the binaries and services required for > AD DC operation to the package samba-ad-dc. Currently it's possible to run such > a setup without installing the package, as it's just a metapackage. Sure it is a meta-package, and it is described as such. > Moving the binaries/services over would have the benefit of being able to drop > the support of this package separately from the samba server, as it currently is > for oldstable and older. Which binaries/services do you mean, specially? I for one know just one: it is samba.service (and the init script) which starts samba-ad-dc, that's just two files. I'm thinking /etc/init.d/samba-ad-dc /lib/systemd/system/samba-ad-dc.service /usr/sbin/samba /mjt
Bug#1051770: move services and binaries for AD DC setup to package samba-ad-dc
Source: samba Severity: minor X-Debbugs-Cc: deb...@rocketjump.eu Hi, I believe it would be a good idea to move the binaries and services required for AD DC operation to the package samba-ad-dc. Currently it's possible to run such a setup without installing the package, as it's just a metapackage. Moving the binaries/services over would have the benefit of being able to drop the support of this package separately from the samba server, as it currently is for oldstable and older. Greetings, Lee -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-12-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#921526: geany crashes when deleting files in Tree Browser
This seems to be fixed in the bookworm release. On Wed, 06 Feb 2019 15:19:24 +0100 Lee Garrett wrote: Package: geany Version: 1.33-1 Severity: important Hi, geany crashes when deleting files in Tree Browser. Steps to reproduce: 1) Open a geany project 2) Enable the side bar with View -> Show Sidebar 3) Switch to the "Tree Browser" tab 4) Double-click on a file to open it 5) Right-click on the file in the Tree Browser 6) Select "delete" At this point geany with crash with following shell output: --->8-->8-->8-->8-->8-->8-->8-->8-->8-->8--- (geany:7652): Gtk-WARNING **: 15:16:21.819: Theme parsing error: gtk-widgets.css:186:14: not a number (geany:7652): Gtk-WARNING **: 15:16:21.819: Theme parsing error: gtk-widgets.css:186:14: Expected a string. (geany:7652): Gtk-WARNING **: 15:16:21.824: Theme parsing error: gtk-widgets.css:2749:24: not a number (geany:7652): Gtk-WARNING **: 15:16:21.824: Theme parsing error: gtk-widgets.css:2749:24: Expected a string. (geany:7652): Gtk-WARNING **: 15:16:21.824: Theme parsing error: gtk-widgets.css:2940:14: not a number (geany:7652): Gtk-WARNING **: 15:16:21.824: Theme parsing error: gtk-widgets.css:2940:14: Expected a string. (geany:7652): Gtk-WARNING **: 15:16:21.824: Theme parsing error: gtk-widgets.css:2946:17: Expected a string. (geany:7652): Gtk-WARNING **: 15:16:21.827: Theme parsing error: gtk-widgets.css:4083:14: not a number (geany:7652): Gtk-WARNING **: 15:16:21.827: Theme parsing error: gtk-widgets.css:4083:14: Expected a string. (geany:7652): Gtk-WARNING **: 15:16:21.827: Theme parsing error: gtk-widgets.css:4088:17: Expected a string. (geany:7652): Gtk-WARNING **: 15:16:21.828: Theme parsing error: gtk-widgets.css:4729:14: not a number (geany:7652): Gtk-WARNING **: 15:16:21.828: Theme parsing error: gtk-widgets.css:4729:14: Expected a string. (geany:7652): Gtk-WARNING **: 15:16:21.829: Theme parsing error: xfce.css:47:16: not a number (geany:7652): Gtk-WARNING **: 15:16:21.829: Theme parsing error: xfce.css:47:16: Expected a string. (geany:7652): Gtk-WARNING **: 15:16:21.829: Theme parsing error: lightdm-gtk-greeter.css:16:14: not a number (geany:7652): Gtk-WARNING **: 15:16:21.829: Theme parsing error: lightdm-gtk-greeter.css:16:14: Expected a string. (geany:7652): Gtk-WARNING **: 15:16:21.829: Theme parsing error: lightdm-gtk-greeter.css:26:14: not a number (geany:7652): Gtk-WARNING **: 15:16:21.829: Theme parsing error: lightdm-gtk-greeter.css:26:14: Expected a string. (geany:7652): Gtk-WARNING **: 15:16:21.830: Theme parsing error: lightdm-gtk-greeter.css:40:16: not a number (geany:7652): Gtk-WARNING **: 15:16:21.830: Theme parsing error: lightdm-gtk-greeter.css:40:16: Expected a string. (geany:7652): Gtk-WARNING **: 15:16:21.830: Theme parsing error: lightdm-gtk-greeter.css:96:14: Expected a string.
Bug#1051140: Bug #1051140: lintian in bookworm does not know about bookworm-backports
Indeed, however the bug is about fixing it in stable. On 03.09.23 16:45, Joachim Wiedorn wrote: Hello Lee, you can fix the problem by yourself: Open file /usr/share/lintian/data/changes-file/known-dists and add one line with "bookworm". --- Have a nice day. Joachim (Germany)
Bug#1051142: bookworm dput-ng does not know about bookworm-backports
Package: dput-ng Version: 1.35 Severity: important X-Debbugs-Cc: deb...@rocketjump.eu Hi, when trying to upload a package to bookworm-backports, it's impossible to do with dput-ng from bookworm: $ dput rhsrvany_1.1-2~bpo12+1_source.changes Uploading rhsrvany using ftp to ftp-master (host: ftp.upload.debian.org; directory: /pub/UploadQueue/) running allowed-distribution: check whether a local profile permits uploads to the target distribution `bookworm-backports' not in the codename group It would be nice if dput-ng would know about bookworm-backports. Greetings, Lee -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dput-ng depends on: ii python3 3.11.2-1+b1 ii python3-dput 1.35 dput-ng recommends no packages. Versions of packages dput-ng suggests: ii dput-ng-doc 1.35 pn python3-twitter -- no debconf information
Bug#1051140: lintian in bookworm does not know about bookworm-backports
Package: lintian Version: 2.116.3 Severity: important X-Debbugs-Cc: deb...@rocketjump.eu Hi, when preparing an upload for bookworm-backports, lintian in bookworm will falsely error out, diminishing it's usefulness: E: rhsrvany changes: bad-distribution-in-changes-file bookworm-backports It would be great if lintian in stable would know about bookworm-backports. Greetings, Lee -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lintian depends on: ii binutils2.40-2 ii bzip2 1.0.8-5+b1 ii diffstat1.65-1 ii dpkg1.21.22 ii dpkg-dev1.21.22 ii file1:5.44-3 ii gettext 0.21-12 ii gpg 2.2.40-1.1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.15.0-1 ii libapt-pkg-perl 0.1.40+b2 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-2+b1 ii libcapture-tiny-perl0.48-2 ii libclass-xsaccessor-perl1.19-4+b1 ii libclone-perl 0.46-1 ii libconfig-tiny-perl 2.28-2 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.35-1 ii libdata-dpath-perl 0.58-2 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2+b1 pn libdigest-sha-perl ii libdpkg-perl1.21.22 ii libemail-address-xs-perl1.05-1+b1 ii libencode-perl 3.19-1+b1 ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-3 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-2 ii libipc-run3-perl0.048-3 ii libjson-maybexs-perl1.004004-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.144-1 ii libperlio-gzip-perl 0.20-1+b1 ii libperlio-utf8-strict-perl 0.010-1 ii libproc-processtable-perl 0.634-1+b2 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.003+ds-1 ii libsereal-encoder-perl 5.003+ds-1 ii libsort-versions-perl 1.62-3 ii libsyntax-keyword-try-perl 0.28-1 ii libterm-readkey-perl2.38-2+b1 ii libtext-levenshteinxs-perl 0.03-5+b1 ii libtext-markdown-discount-perl 0.16-1 ii libtext-xslate-perl 3.5.9-1+b2 ii libtime-duration-perl 1.21-2 ii libtime-moment-perl 0.44-2+b1 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-2 ii liburi-perl 5.17-1 ii libwww-mechanize-perl 2.16-1 ii libwww-perl 6.68-1 ii libxml-libxml-perl 2.0207+dfsg+really+2.0134-1+b1 ii libyaml-libyaml-perl0.86+ds-1 ii lzip [lzip-decompressor]1.23-5 ii lzop1.04-2 ii man-db 2.11.2-2 ii patchutils 0.4.2-1 ii perl [libencode-perl] 5.36.0-7 ii t1utils 1.41-4 ii unzip 6.0-28 ii xz-utils5.4.1-0.2 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.40-2 ii libtext-template-perl 1.61-1 -- no debconf information
Bug#1042906: ansible: please package new upstream version 8.x
Hi Dominik, indeed! I'm currently letting the version of ansible/ansible-core in unstable linger a little bit longer to get some more testing, before pushing it as a stable-update. As soon as that is done, I'll package the latest for unstable again. Greets, Lee On 02.08.23 17:13, Dominik George wrote: Source: ansible Version: 7.3.0+dfsg-1 Severity: wishlist Hi Lee, Ansible upstream is currently at 8.2. In order to not having to resort to pip install, an update of Debian's ansible package would be much appreciated. Cheers, Nik
Bug#1050915: truncate unsigned parts of signed mails to d-d-a
Package: lists.debian.org Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, currently, when using Thunderbird to send OpenPGP/MIME signed mails to d-d-a, the mail gets silently blackholed (#1050906). It seems like the reason is that there is a small piece of text before the actual MIME-encoded data: "This is an OpenPGP/MIME signed message (RFC 4880 and 3156)" Would be nice if the tool in question could just truncate the unsigned bits instead and accept the mail, assuming there's a valid signature. Greetings, Lee
Bug#1050906: reject non-conforming mail with helpful message when sending to d-d-a
Package: lists.debian.org Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, every once in a while I'd like to send a mail to d-d-a, where the mail is required to be signed. The only description is "Only messages signed by a Debian developer will be accepted by this list." Apparently the restriction is more than that, and it would be nice to reject the mail on a SMTP level with a helpful message instead of blackholing it. >From a user experience it's currently a bit cumbersome, as I'll send a mail, wait 15 minutes to notice that it hasn't arrived, change a few things and resend, wait another 15 minutes, etc. Which is quite an ineffective workflow. Regards, Lee
Bug#1042754: tor: don't autostart the service on installation
Hi anonymous user, On Mon, 31 Jul 2023 11:25:54 + svsdzj+3p1rxwpwgcq8c@cs.email wrote: Package: tor Version: 0.4.7.13-1 Severity: grave Dear Maintainer, please do not autostart the tor system service immediately after installing it using `apt install tor`. Current behavior reveals that the user installed the tor package, because connections to the tor network start immediately after the package is installed. This is problematic for a great many reasons. If apt is configured Which are those reasons that warrant RC status of this bug? If I install tor, I'm bound to use it, otherwise I wouldn't do it. to use https sources, then it is unlikely a network observer would know that the tor package was being downloaded (unless they can correlate the size of the download with the package size of tor and dependencies, and even that is not a definitive proof). This has already been proven feasible, since the byte sizes of the packages are public knowledge. Also, a network observer will see you have installed when you use it. So I don't see a privacy/security breach here. Users don't expect the tor service to start immediately after installing it, nor do they expect it to start automatically on every boot of their system. If users even want to use the tor service, then they generally configure it first before autostarting it (to setup bridges for example). Indeed, in the case of a setting up a tor bridge, not autostarting might be good idea. However, this can trivially be done by masking the service (e.g. `systemctl mask tor.service`) before installation. You can also provide a /etc/tor/torrc before installing the package, and that will be used after installation. I want to point out that users are not informed about nor asked for any consent to these immediate outside connections to the tor network. No privacy policy or warnings are presented to the user after `apt install tor`, the service simply starts and connects to tor with no indication that this is happening. I'd argue that users do expect it, as it is the way all other daemons on Debian are started when installed. This has been the default for a long time. Can you back up that claim somehow? The service should be shipped in a disabled state, so that it does not start on system boot, nor should the service start immediately after installing tor. If users wish to run the service on the system level automatically on every boot then they can do so by doing `systemctl enable tor.service`. If the tor maintainer really wishes to keep the automatic start of tor service on installation as default behavior, then they should at least create a debconf interface that asks the users if that is what they really wish to happen, so that users can give their informed consent. That would not be a feasible option, as this is considered "debconf abuse" [0]. The other problem is that it wouldn't be shown in non-interactive sessions, using for example puppet, ansible or Chef to install it. [0] https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#do-not-abuse-debconf Additionally, many users simply start the tor executable directly, with configuration files in their home directory, when they need it instead of automatically. I'm not convinced this is a common usage pattern. However, if you can convince the maintainer it is, it might be worth splitting the package in tor-bin and tor-server packages, the former containing the binary, and the latter containing the service files starting the daemon. This would be a separate bug report, though. When users start the service manually, they are at least presented with this information: [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous Please do not autostart the tor system service immediately after installing it using `apt install tor`. All in all I believe this could be implemented if you can bring up convincing arguments why this is dangerous behaviour. In that case it would not be started, and the steps to get it to autostart would be documented in /usr/share/doc/tor/README.Debian. Since I don't believe this is falls in the severity of "grave" as defined in [1] (the package works for most people, it does not cause data loss nor introduces security holes on the system), I'm changing the bug severity. [1] https://www.debian.org/Bugs/Developer#severities Greetings, Lee
Bug#1049392: golang-1.21: FTBFS if dh-golang is installed
On Tue, 15 Aug 2023, Shengjing Zhu wrote: So why would you install dh-golang? It's not listed in golang-1.21's Build-Depends. To build other packages. Building Go and building packages that use Go on the same system doesn't seem weird to me. Is your view that source packages only need to be buildable in isolated chroots/containers that have just essential and their build-deps installed? While the policy manual doesn't seem to be explicit on this, the existence of the Build-Conflicts field seems to imply that the expectation is any breakage is explicitly declared there, and would provide a reasonable solution to this IMO. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824495 has a long discussion on the merits of different possible policy stances on this. https://lists.debian.org/debian-devel/2019/02/msg00204.html continues that discussion, though some of the mesages were also CC'd to the bug. -- -- Matt "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick GPG fingerprint: 0061 15DF D282 D4A9 57CE 77C5 16AF 1460 4A3C C4E9
Bug#1049392: golang-1.21: FTBFS if dh-golang is installed
Source: golang-1.21 Version: 1.21.0-1 Severity: important Tags: ftbfs Context: trying to build local golang-1.21 packages against stable (bookworm) If dh-golang is installed, building the golang toolchain itself fails tests, specifically TestCgoLib in src/cmd/nm/nm_cgo_test.go: --- FAIL: TestCgoLib (2.19s) nm_test.go:264: go tool nm: exit status 1 open /tmp/TestGoLib2084668406/gopath/src/mylib/mylib.a: unrecognized object file After much digging and adding printf-y debugging output to the go toolchain, I eventually tracked this down to dh-golang copying CFLAGS (and related) env vars to CGO_CFLAGS (etc.). This notably includes the `-ffile-prefix-map` flag, which the go toolchain doesn't like, which causes it to put a "preferlinkext" sigil file in the `.a` file the test generates, which then makes the `go tool nm` program under test barf, because it doesn't know what that flag file is. I've reported the issue with `go tool nm` upstream: https://github.com/golang/go/issues/62036 However, I don't think `dh-golang` should be getting pulled in when building the Go toolchain itself, should it, at least not for setting CGO flags since I don't think the toolchain uses CGO, so this is only messing with tests? This also affects golang-1.20, and based on my analysis of the root cause in the upstream issue, I believe will affect golang-1.19 too, but I have not directly confirmed that. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'testing'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/16 CPU threads; PREEMPT) 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: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1042768: Stop shipping scripts that don't work with irssi >= 1.4
Source: irssi-scripts
Version: 20220704
Severity: important
X-Debbugs-Cc: deb...@rocketjump.eu
Hi,
irssi 1.4 in bookworm ships with a new rendering system compared to 1.2.3 from
bullseye, breaking a few scripts in the process [0]. A list of affected scripts
is listed in the 1.4.1 news entry [1].
I propose to update to the latest irssi-scripts snapshot, and then remove any
remaining scripts still using Irssi::command('^format [...]), and add a news
entry for the next stable-update.
Regards,
Lee
[0] https://irssi.org/posts/#major-news-in-irssi-14-coming-from-irssi-123
grep for "The display system now renders formats on the fly"
[1] https://irssi.org/NEWS/#news-v1-4-1
-- System Information:
Debian Release: 12.1
APT prefers stable-updates
APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#1042002: missing suggests/recommends
Package: virt-v2v Version: 2.2.0-1 Severity: minor X-Debbugs-Cc: deb...@rocketjump.eu Hello Hilko, I've been using virt-v2v to convert Windows vmware images to libvirt. It is missing a suggests or recommends on nbdkit, rhsrvany (which I'm currently packaging, see #996850), and libnbd-bin. The latter I only found out by running it in debug mode, the regular error message was not helpful. Would be nice if virt-v2v could check for the nbdcopy binary, and suggest installing libnbd-bin. Regards, Lee -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-10-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages virt-v2v depends on: ii libc62.36-9+deb12u1 ii libglib2.0-0 2.74.6-2 ii libguestfs0 1:1.48.6-2 ii libjansson4 2.14-2 ii libnbd0 1.14.2-1 ii libosinfo-1.0-0 1.10.0-2 ii libpcre2-8-0 10.42-1 ii libvirt0 9.0.0-4 ii libxml2 2.9.14+dfsg-1.3~deb12u1 virt-v2v recommends no packages. virt-v2v suggests no packages. -- no debconf information
Bug#996850: ITP: rhsrvany -- Windows tools used by virt-v2v
Hi Ryan, is there any update on the packaging progress? Greets, Lee On Tue, 19 Oct 2021 10:48:35 -0500 Ryan Pavlik wrote: Package: wnpp Severity: wishlist Owner: Ryan Pavlik X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: rhsrvany Version : 0.20210127 Upstream Author : Richard W.M. Jones, Red Hat Inc. * URL : https://github.com/rwmjones/rhsrvany * License : GPL-2+ Programming Lang: C Description : Windows tools used by virt-v2v This package contains open-source replacements for proprietary Windows tools, SrvAny (RHSrvAny) and pnp_wait. They are used by the virt-v2v tool when converting Windows virtual machines. This is required for virt-v2v (see https://bugs.debian.org/962293) which was formerly part of libguestfs in Buster and now the subject of its own RFP bug linked above. The draft of that package is in the libvirt team, and if this package is accepted, I'd anticipate joining that team for team maintenance and sponsorship. The code itself is quite stable, with a limited purpose and having seen little need for changes in the past several years, so I anticipate packaging maintenance load to be low.
Bug#116879: ssh-keygen -d undocumented switch
It looks like this bug is obsolete as the switch was removed. Closing this bug as such.
Bug#964941: base-files: please maintain base-files in a VCS such as git on salsa.d.o
Bump. I'm trying to understand why /var/local/ is root:staff (#1039973), and a VCS would really help with that. It would also make it easier for you to accept patches for bugs.
Bug#1038113: New upstream available
Source: triplea Severity: wishlist X-Debbugs-Cc: deb...@rocketjump.eu Hello fine Debian Java maintainers, triplea has had a few updates since the last upload. Current stable is 2.5.22294. Can we get some love for this package? Thanks in advance! ~ lee -- System Information: Debian Release: 12.0 APT prefers stable-security APT policy: (990, 'stable-security'), (990, 'stable'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1037126: ansible-core: Patch to fix URI Module find json sub type
Hi Bernhard, I acknowledge this bug, and will issue a point release update once it has been merged upstream. Thanks for the report! Greets, Lee On 05.06.23 15:21, Bernhard Turmann wrote: Source: ansible-core Source-Version: 2.14.3-1 Severity: important Tags: fixed-upstream, patch, upstream Dear Maintainer, the attached patch applied in upstream commit [0] will fix ansible-core 2.14.3-1 in Debian 12 Bookworm having an issue with the URI module recognizing JSON with some API endpoints correctly. I am using this module in many tasks with the CEPH Dashboard API and confirm the patch is fixing it successfully. Without the patch, all these tasks are failing after installing a fresh Debian Bookworm. Note: The ansible version in Bullseye was working fine in this regard. Upstream has an open PR [1] against stable-2.14, but not merged yet. I would have opened a Merge Request on Salsa, but I just registered and waiting for approval. [0] https://github.com/ansible/ansible/commit/0c7361d9acf7c8966a09f67de2a8679ef86fd856 [1] https://github.com/ansible/ansible/pull/80870 With Best Regards Berni
Bug#1004301: please add more information
Hi, I indeed have only one webcam (on a Lenovo Thinkpad T490). I think the 2nd instance might be the IR mode of the camera. Weirdly enough, cheese lists 4 (!) instances of the camera, all named "Integrated Camera (V4L2)", two showing a true color image, and showing a greyscale image (I'm guessing IR). I've tried to reproduce the bug, and now it doesn't seem possible anymore. Qtqr now correclty works, and does not produce a backtrace. I guess it was somewhere in the underlying Qt5 libraries, and they got upgraded in the mean time. As such, I'm fine with closing this bug. Thanks! Greetings, Lee On 31.05.23 17:19, georgesk wrote: Hi, thank you for your bug report. You are telling that when you "Decode from webcam", two webcams with the same name and identification are listed in a select widget. Have you more than one physical webcam? Please can you install another application using webcams, for example "cheese" and test whether it reports also such a duplicate webcam? So far, I could not reproduce the bug. Thank you in advance. Georges.
Bug#1036752: bat: manpage is missing, README.debian is missing
Package: bat Version: 0.22.1-2 Severity: normal X-Debbugs-Cc: kjoon...@gmail.com Dear Maintainer, After the bat binary was renamed from batcat to bat and back to batcat, the man page is no longer installed: /usr/share/man/man1/batcat.1.gz bookworm output: $ dpkg -L bat /. /usr /usr/bin /usr/bin/batcat /usr/share /usr/share/doc /usr/share/doc/bat /usr/share/doc/bat/changelog.Debian.gz /usr/share/doc/bat/changelog.gz /usr/share/doc/bat/copyright /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/bat Compare bullseye output: $ dpkg -L bat /. /usr /usr/bin /usr/bin/batcat /usr/share /usr/share/doc /usr/share/doc/bat /usr/share/doc/bat/README.Debian /usr/share/doc/bat/changelog.Debian.arm64.gz /usr/share/doc/bat/changelog.Debian.gz /usr/share/doc/bat/copyright /usr/share/lintian /usr/share/lintian/overrides /usr/share/lintian/overrides/bat /usr/share/man /usr/share/man/man1 /usr/share/man/man1/batcat.1.gz -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (500, 'testing-security'), (500, 'testing') Architecture: arm64 (aarch64) Kernel: Linux 5.17.0-1-arm64 (SMP w/8 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: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages bat depends on: ii libc62.36-9 ii libgcc-s112.2.0-14 ii libgit2-1.5 1.5.1+ds-1 bat recommends no packages. bat suggests no packages. -- no debconf information
Bug#1036471: installation-reports: Bookworm RC3 installs in MBR but hangs in UEFI, goes to gray screen
Package: installation-reports Severity: normal X-Debbugs-Cc: lewu...@retiredtechie.com (Please provide enough information to help the Debian maintainers evaluate the report efficiently - e.g., by filling in the sections below.) Boot method: ISO Image version: debian-bookworm-DI-rc3-amd64-netinstall Date: 21 May 2023 3:00 PM EST Machine: VirtualVox version 7.0.6 Partitions: None, system does not install, so storage disk is not partioned or formated Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E] Detect network card:[ ] Configure network: [ ] Detect media: [ ] Load installer modules: [ ] Clock/timezone setup: [ ] User/password setup:[ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: Attempted to install bookwork rc3 as guest on in Virtual machine (Virtual Box); 4 CPUS, 4 GB RAM, 20 GB drive, bridge network, UEFI enabled. Host compiuter MSI Raider GE76 running Windows 11. Boot menu comes up. When selecting install option, goes to gray screen with flashing cursor in nupper left corner. Was able to install without issue using same setup, but with UEFI disabled (legacy mode). Please make sure that any installation logs that you think would be useful are attached to this report. (You can find them in the installer system in /var/log/ and later on the installed system under /var/log/installer.) Please compress large files using gzip. -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="12 (bookworm) - installer build 20230427" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux debian12 6.1.0-7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.20-2 (2023-04-08) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02) lspci -knn: 00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000] lspci -knn: 00:01.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE [8086:7111] (rev 01) lspci -knn: Kernel driver in use: ata_piix lspci -knn: Kernel modules: ata_piix, ata_generic lspci -knn: 00:02.0 VGA compatible controller [0300]: VMware SVGA II Adapter [15ad:0405] lspci -knn: Subsystem: VMware SVGA II Adapter [15ad:0405] lspci -knn: 00:03.0 Ethernet controller [0200]: Intel Corporation 82540EM Gigabit Ethernet Controller [8086:100e] (rev 02) lspci -knn: Subsystem: Intel Corporation PRO/1000 MT Desktop Adapter [8086:001e] lspci -knn: Kernel driver in use: e1000 lspci -knn: Kernel modules: e1000 lspci -knn: 00:04.0 System peripheral [0880]: InnoTek Systemberatung GmbH VirtualBox Guest Service [80ee:cafe] lspci -knn: 00:05.0 Multimedia audio controller [0401]: Intel Corporation 82801AA AC'97 Audio Controller [8086:2415] (rev 01) lspci -knn: Subsystem: Dell Device [1028:0177] lspci -knn: 00:06.0 USB controller [0c03]: Apple Inc. KeyLargo/Intrepid USB [106b:003f] lspci -knn: Kernel driver in use: ohci-pci lspci -knn: Kernel modules: ohci_pci lspci -knn: 00:07.0 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 08) lspci -knn: 00:0b.0 USB controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller [8086:265c] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: Kernel modules: ehci_pci lspci -knn: 00:0d.0 SATA controller [0106]: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] [8086:2829] (rev 02) lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci usb-list: usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 6.1.0-7-amd64 ehci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub usb-list: usb-list: Bus 02 Device 01: OHCI PCI host controller [1d6b:0001] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:Manufacturer: Linux 6.1.0-7-amd64 ohci_hcd usb-list:Interface 00: Class 09(hub ) Subclass 00 Protocol 00 Driver hub lsmod: Module Size Used by lsmod: fuse 176128 0 lsmod: dm_mod184320 0 lsmod: md_mod192512 0 lsmod: xfs 1945600 0 lsmod: jfs 221184 0 lsmod: btrfs1777664 0 lsmod: xor24576 1 btrfs lsmod: raid6_pq 122880 1 btrfs lsmod: zstd_compress
Bug#1035891: openjdk-17-jre-headless: Crashes when ulimit -v is in effect
Package: openjdk-17-jre-headless Version: 17.0.6+10-1~deb11u1 Severity: important Tags: upstream Dear Maintainer, On a certain multi-user system, I have the following lines in /etc/profile ... ulimit -d 99 ulimit -v 389 In other words, almost 4G virtual memory per process, of which 1G data segment. (Physical RAM is currently 16G.) But with those settings, and the Java runtime default memory alocation, Java does not start. Even "java -help" or "java -version" fails with a memory error! $ java -version Error occurred during initialization of VM Could not allocate compressed class space: 1073741824 bytes Now, I can pass an argument to limit Java heap size, and it works: $ java -Xmx1500m -version openjdk version "17.0.6" 2023-01-17 OpenJDK Runtime Environment (build 17.0.6+10-Debian-1deb11u1) OpenJDK 64-Bit Server VM (build 17.0.6+10-Debian-1deb11u1, mixed mode, sharing) But there's a point where it gets weird: $ java -Xmx1750m -version openjdk version "17.0.6" 2023-01-17 OpenJDK Runtime Environment (build 17.0.6+10-Debian-1deb11u1) OpenJDK 64-Bit Server VM (build 17.0.6+10-Debian-1deb11u1, mixed mode, sharing) $ java -Xmx1800m -version [0.019s][warning][os,thread] Failed to start thread "Unknown thread" - pthread_create failed (EAGAIN) for attributes: stacksize: 1024k, guardsize: 0k, detached. Error occurred during initialization of VM $ java -Xmx1900m -version Error occurred during initialization of VM Could not allocate compressed class space: 1073741824 bytes Or if I adjust the "ulimit -v" limit downward, the safe-start point of the Java VM goes down, but not one-for-one... $ ulimit -v 369 $ java -Xmx1750m -version Error occurred during initialization of VM Could not allocate compressed class space: 1073741824 bytes $ java -Xmx1650m -version openjdk version "17.0.6" 2023-01-17 OpenJDK Runtime Environment (build 17.0.6+10-Debian-1deb11u1) OpenJDK 64-Bit Server VM (build 17.0.6+10-Debian-1deb11u1, mixed mode, sharing) Upstream bug https://bugs.openjdk.org/browse/JDK-8071445 . Last comment: > This is not critical for JDK 7. As the filer stated, there is an obvious > workaround to lower the maximum heap size. However, when we decide the > default maximum heap, it would be good to look at the ulimit and set a lower > maximum heap size if that limit is set. But the "obvious workaround" is not always straightforward when using applications or tools built on Java (e.g., Eclipse or Gradle). The JDK already checks whether it's in a Docker container and adjusts its memory allocation strategy accordingly, see https://www.oracle.com/java/technologies/javase/8u191-relnotes.html#JDK-8146115 . If no memory-tuning arguents are passed in and "ulimit -v" is in effect (getrlimit(RLIMIT_AS, ...) ), the JDK should find a memory structure that fits within the available memory, or give a friendlier error-message if it can't. (If -Xms and -Xmx both set, and the initial allocation would succeed but the maximum allocation would fail, maybe Java should print a warning.) -- System Information: Debian Release: 11.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldoldstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-15-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 openjdk-17-jre-headless depends on: ii ca-certificates-java 20190909 ii java-common 0.72 ii libasound21.2.4-1.1 ii libc6 2.31-13+deb11u6 ii libcups2 2.3.3op2-3+deb11u2 ii libfontconfig12.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1+deb11u1 ii libgcc-s1 10.2.1-6 ii libharfbuzz0b 2.7.4-1 ii libjpeg62-turbo 1:2.0.6-4 ii liblcms2-22.12~rc1-2 ii libnss3 2:3.61-1+deb11u3 ii libpcsclite1 1.9.1-1 ii libstdc++610.2.1-6 ii util-linux2.36.1-8+deb11u1 ii zlib1g1:1.2.11.dfsg-2+deb11u2 openjdk-17-jre-headless recommends no packages. Versions of packages openjdk-17-jre-headless suggests: ii fonts-dejavu-extra2.37-2 pn fonts-indic ii fonts-ipafont-gothic 00303-21 ii fonts-ipafont-mincho 00303-21 ii fonts-wqy-microhei0.2.0-beta-3.1 ii fonts-wqy-zenhei 0.9.45-8 ii libnss-mdns 0.14.1-2 -- no debconf information
Bug#1035875: Arbitrary code execution vulnerability in versions < 2.3
Package: osslsigncode Version: 2.1-1 Severity: grave Tags: security X-Debbugs-Cc: secur...@debian.org, deb...@rocketjump.eu, Debian Security Team It was reported through IRC that the current stable version of osslsigncode contains an unpatched security vulnerability: https://github.com/mtrojnar/osslsigncode/releases/tag/2.3 Unfortunately, upstream has not assigned a CVE, and a quick glance at the closed bug reports didn't reveal any further details. Regards, Lee -- System Information: Debian Release: 12.0 APT prefers testing-security APT policy: (990, 'testing-security'), (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-8-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages osslsigncode depends on: ii libc6 2.36-9 ii libcurl4 7.88.1-9 ii libssl3 3.0.8-1 osslsigncode recommends no packages. osslsigncode suggests no packages.
Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed
On Sat, 18 Mar 2023 17:06:08 +0100 Dominique Dumont wrote: On Tue, 14 Feb 2023 22:21:26 +0100 Lee Garrett wrote: > Bumped severity as this makes bts currently unusable, and probably > breaks for quite a few DDs their workflow. This does not break on my system where bts is connected to local sendmail (which is the default setup). Which hints at a workaround: have bts connect to local sendmail and have sendmail forward the mail to the SMTPS server. While this setup might work for some people, this has IMHO quite a few hefty drawbacks and requires me to maintain a MTA on my local machine. I could elaborate, but I don't think it's on-topic for this bug report. The change mentioned by Daniel affects only a setup where the host if configured via its IP address, not via a host name: See the change in SSL.pm in commit https://github.com/noxxi/p5-io-socket-ssl/commit/c0a063b70f0a3ad033da0a51923c65bd2ff118a0 While Daniel did mention this commit (which might or might not be related to the issue), bts fails on a configured SMTPS hostname which otherwise correctly validates with other MUA. Which is not the case here: $ perl -S -MDevel::SimpleTrace bts --smtp-host smtps://mail.wgdd.de usertag 1029588 + dod-test-with-tls bts: failed to open SMTPS connection to smtps://mail.wgdd.de (hostname verification failed) at main::send_mail(mail.wgdd.de) at main::mailbtsall(/usr/bin/bts:2839) at main::(/usr/bin/bts:825) Unfortunately, I can no longer investigate this issue as it looks like that my IP address is now blacklisted on Daniel's server: $ perl -MDevel::SimpleTrace scripts/bts.pl --smtp-host smtps://mail.wgdd.de usertag 1029588 + dod-test-with-tls bts.pl: failed to open SMTPS connection to smtps://mail.wgdd.de (Connection refused) at main::send_mail(mail.wgdd.de) at main::mailbtsall(scripts/bts.pl:2849) at main::(scripts/bts.pl:834) On a hunch, I would guess that Daniel's server is configured to handle STARTTLS, which is not supported by bts. But I cannot verify this. In any case this does not explain why Daniel sees bts working with libio-socket-ssl-perl 2.077 but not with 2.078. I'm sure that bts supports STARTTLS. I am using bts with my MTA on 587/tcp, which enforces STARTTLS and requires credentials (I just double-checked via swaks). With the old libio-socket-ssl-perl 2.069-1 this works, so it's clearly a regression. All the best Greetings, Lee
Bug#1032655: psi-plus segfaults
On 12.03.23 00:35, Stefan Kropp wrote: On Fri, Mar 10, 2023 at 03:45:38PM +0100, Lee Garrett wrote: psi-plus currently simply segfaults on a stock bookworm installation: $ psi-plus [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile (unknown:0, unknown) [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile (unknown:0, unknown) [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile (unknown:0, unknown) [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile (unknown:0, unknown) Segmentation fault On my bookworm system, I also get libpng warnings, but no segfault. Maybe a backtrace in gdb can help to get more information. the bug was originally reported by a user on IRC, and I could confirm that I'm seeing the same as them, so I'm assuming that some portion of users are affected (and it's not just something broken on my system). I think it should be reproducible in a minimal bookworm gnome VM. backtrace below: $ gdb psi-plus GNU gdb (Debian 13.1-2) 13.1 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from psi-plus... (No debugging symbols found in psi-plus) (gdb) run Starting program: /usr/bin/psi-plus [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x716956c0 (LWP 102344)] [New Thread 0x70e946c0 (LWP 102345)] [New Thread 0x7fffebfff6c0 (LWP 102346)] [New Thread 0x7fffeb7fe6c0 (LWP 102347)] [New Thread 0x7fffeaffd6c0 (LWP 102348)] [New Thread 0x7fffea7fc6c0 (LWP 102349)] [New Thread 0x7fffe9ffb6c0 (LWP 102350)] [Detaching after fork from child process 102351] [Detaching after fork from child process 102352] [Detaching after fork from child process 102354] [Detaching after fork from child process 102355] [Detaching after fork from child process 102357] [New Thread 0x7fffe91ff6c0 (LWP 102358)] [New Thread 0x7fffe89fe6c0 (LWP 102359)] [20230322 14:39:21] W:libpng warning: iCCP: known incorrect sRGB profile (unknown:0, unknown) [20230322 14:39:21] W:libpng warning: iCCP: known incorrect sRGB profile (unknown:0, unknown) [20230322 14:39:21] W:libpng warning: iCCP: known incorrect sRGB profile (unknown:0, unknown) [20230322 14:39:21] W:libpng warning: iCCP: known incorrect sRGB profile (unknown:0, unknown) Thread 1 "psi-plus" received signal SIGSEGV, Segmentation fault. 0x77e94a4d in XInternAtoms () from /lib/x86_64-linux-gnu/libX11.so.6 (gdb) where #0 0x77e94a4d in XInternAtoms () from /lib/x86_64-linux-gnu/libX11.so.6 #1 0x55918223 in X11WindowSystem::X11WindowSystem() () #2 0x55918805 in X11WindowSystem::instance() () #3 0x559e1884 in MainWin::MainWin(bool, bool, PsiCon*) () #4 0x558b5ba2 in PsiCon::init() () #5 0x559d36b6 in PsiMain::sessionStart() () #6 0x770dd6f0 in QObject::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x76362fae in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #8 0x770b16f8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x770b4681 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x7710a153 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #11 0x7551e7a9 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #12 0x7551ea38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #13 0x7551eacc in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x77109836 in QEventDispatcherGlib::processEvents(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #15 0x770b017b in QEventLoop::exec(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x770b82d6 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #17 0x557e4e95 in main () (gdb) list 1 ../sysdeps/unix/sysv/linux/dl-vdso-setup.c: No such file or directory. (gdb) Regards, Lee
Bug#1032418: zcfan service is not stopped on package removal
Debugging this issue I found that it's caused by #1031695 (a bug in dh_installsystemd). I've reduced this bug severity accordingly.
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hi, is there any update on fixing this issue before the bookworm release? I stumbled upon this bug report trying to fix #1032418, which is a rather grave bug. zcfan is one of the 37 packages affected. Because of this issue, dh_installsystemd does not generate a .postrm file to stop the service, so when a user installs zcfan, and after that thinkfan, zcfan is removed, but the service still runs. Since there are now two services controlling the fan speed, it will cause unpredictable behaviour and potentially HW damage. Regards, Lee
Bug#1032655: psi-plus segfaults
Package: psi-plus Version: 1.4.554-5+b2 Severity: grave X-Debbugs-Cc: deb...@rocketjump.eu Hi, psi-plus currently simply segfaults on a stock bookworm installation: $ psi-plus [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile (unknown:0, unknown) [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile (unknown:0, unknown) [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile (unknown:0, unknown) [20230310 15:43:12] W:libpng warning: iCCP: known incorrect sRGB profile (unknown:0, unknown) Segmentation fault Regards, Lee -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages psi-plus depends on: ii libc6 2.36-8 ii libgcc-s1 12.2.0-14 ii libhunspell-1.7-0 1.7.1-1 ii libidn12 1.41-1 ii libminizip1 1.1-8+b1 ii libqca-qt5-2 2.3.5-2 ii libqca-qt5-2-plugins 2.3.5-2 ii libqt5concurrent5 5.15.8+dfsg-3 ii libqt5core5a 5.15.8+dfsg-3 ii libqt5dbus5 5.15.8+dfsg-3 ii libqt5gui55.15.8+dfsg-3 ii libqt5keychain1 0.13.2-5 ii libqt5network55.15.8+dfsg-3 ii libqt5sql55.15.8+dfsg-3 ii libqt5sql5-sqlite 5.15.8+dfsg-3 ii libqt5svg55.15.8-2 ii libqt5widgets55.15.8+dfsg-3 ii libqt5x11extras5 5.15.8-2 ii libqt5xml55.15.8+dfsg-3 ii libstdc++612.2.0-14 ii libx11-6 2:1.8.4-2 ii psi-plus-common 1.4.554-5 ii zlib1g1:1.2.13.dfsg-1 Versions of packages psi-plus recommends: ii psi-plus-l10n 1.4.554-1 ii psi-plus-plugins 1.4.554-5+b2 ii psi-plus-sounds 1.4.554-5 ii sox 14.4.2+git20190427-3.4 Versions of packages psi-plus suggests: pn libgnome-keyring0 ii xdg-utils 1.1.3-4.1 -- no debconf information
Bug#1032460: unblock: thinkfan/1.3.1-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: think...@packages.debian.org, deb...@rocketjump.eu
Control: affects -1 + src:thinkfan
Hello release team,
Please unblock package thinkfan. It is a tool to control the fans of Thinkpad
laptops. zcfan is a similar tool that also handles fan control on Thinkpads. To
prevent hardware damage, only one should be installed at the same time
(#1032310).
[ Reason ]
It fixes an RC bug (#1032310).
[ Impact ]
Users could accidentally install both zcfan and thinkfan at the same time during
triage, causing unpredictable fan speed, and at worst cause hardware damage.
[ Tests ]
I have manually tested that the added "Conflicts: zcfan" works as intended.
[ Risks ]
Both thinkfan and zcfan are leaf packages. There is no risk as this change just
adds a "Conflicts" between those packages.
(Discussion of the risks involved. E.g. code is trivial or
complex, key package vs leaf package, alternatives available.)
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
$ debdiff thinkfan_1.3.1-3_amd64.deb thinkfan_1.3.1-4_amd64.deb
File lists identical (after any substitutions)
Control files: lines which differ (wdiff format)
{+Conflicts: zcfan+}
Depends: libatasmart4 (>= 0.13), libc6 (>= [-2.30),-] {+2.34),+} libgcc-s1 (>=
3.0), libstdc++6 (>= [-5.2), libyaml-cpp0.6-] {+11), libyaml-cpp0.7+} (>=
[-0.6.2)-] {+0.7.0)+}
Installed-Size: [-464-] {+472+}
Version: [-1.3.1-3-] {+1.3.1-4+}
[ Other info ]
(Anything else the release team should know.)
unblock thinkfan/1.3.1-4
Bug#1032418: zcfan service is not stopped on package removal
Package: zcfan Severity: serious X-Debbugs-Cc: deb...@rocketjump.eu Hi, while testing the Breaks: directive between zcfan and thinkfan, I noticed that the zcfan service is not stopped upon uninstall. This is not caught by piuparts, as by default the zcfan service is not started. The solution is to have a debian/rules entry like in [0]. I noticed that you're a DM, and since it's fairly late in the freeze process, I'm willing to guide your through the process of fixing the package for the bookworm release. Regards, Lee [0] https://salsa.debian.org/debian/thinkfan/-/blob/master/debian/rules#L24 Full terminal output showing the issue below: 12:59:18 [root@batou:~] 4s # apt install zcfan Reading package lists... Done Building dependency tree... Done Reading state information... Done The following NEW packages will be installed: zcfan 0 upgraded, 1 newly installed, 0 to remove and 1 not upgraded. Need to get 0 B/8.980 B of archives. After this operation, 36,9 kB of additional disk space will be used. Selecting previously unselected package zcfan. (Reading database ... 377831 files and directories currently installed.) Preparing to unpack .../zcfan_1.2.1-1+b1_amd64.deb ... Unpacking zcfan (1.2.1-1+b1) ... Setting up zcfan (1.2.1-1+b1) ... Processing triggers for man-db (2.11.2-1) ... Scanning processes... Scanning candidates... Scanning processor microcode... Scanning linux images... Running kernel seems to be up-to-date. The processor microcode seems to be up-to-date. No services need to be restarted. No containers need to be restarted. User sessions running outdated binaries: randall @ session #2: gdm-wayland-ses[1967] randall @ user manager service: firefox-esr[3254], gnome-session-b[2019], gnome-shell[2048], systemd[1784], thunderbird[2932] No VM guests are running outdated hypervisor (qemu) binaries on this host. 12:59:27 [root@batou:~] 4s # systemctl status zcfan ○ zcfan.service - Zero-configuration fan control for ThinkPad Loaded: loaded (/lib/systemd/system/zcfan.service; enabled; preset: enabled) Active: inactive (dead) since Mon 2023-03-06 12:58:59 CET; 36s ago Duration: 1min 9.982s Process: 17359 ExecStart=/usr/bin/zcfan (code=exited, status=0/SUCCESS) Main PID: 17359 (code=exited, status=0/SUCCESS) CPU: 275ms Mär 06 12:57:49 batou zcfan[17359]: [CFG] At 90C fan is set to maximum Mär 06 12:57:49 batou zcfan[17359]: [CFG] At 80C fan is set to medium Mär 06 12:57:49 batou zcfan[17359]: [CFG] At 70C fan is set to low Mär 06 12:57:49 batou zcfan[17359]: [FAN] Temperature now 51C, fan set to off Mär 06 12:58:23 batou zcfan[17359]: [FAN] Temperature now 71C, fan set to low Mär 06 12:58:26 batou zcfan[17359]: [FAN] Temperature now 50C, fan set to off Mär 06 12:58:59 batou zcfan[17359]: [FAN] Quit requested, reenabling thinkpad_acpi fan control Mär 06 12:58:59 batou systemd[1]: Stopping zcfan.service - Zero-configuration fan control for ThinkPad... Mär 06 12:58:59 batou systemd[1]: zcfan.service: Deactivated successfully. Mär 06 12:58:59 batou systemd[1]: Stopped zcfan.service - Zero-configuration fan control for ThinkPad. 12:59:35 [root@batou:~] 3 # systemctl start zcfan 12:59:39 [root@batou:~] # systemctl status zcfan ● zcfan.service - Zero-configuration fan control for ThinkPad Loaded: loaded (/lib/systemd/system/zcfan.service; enabled; preset: enabled) Active: active (running) since Mon 2023-03-06 12:59:39 CET; 3s ago Main PID: 18995 (zcfan) Tasks: 1 (limit: 28396) Memory: 264.0K CPU: 21ms CGroup: /system.slice/zcfan.service └─18995 /usr/bin/zcfan Mär 06 12:59:39 batou systemd[1]: Started zcfan.service - Zero-configuration fan control for ThinkPad. Mär 06 12:59:39 batou zcfan[18995]: [CFG] At 90C fan is set to maximum Mär 06 12:59:39 batou zcfan[18995]: [CFG] At 80C fan is set to medium Mär 06 12:59:39 batou zcfan[18995]: [CFG] At 70C fan is set to low Mär 06 12:59:39 batou zcfan[18995]: [FAN] Temperature now 50C, fan set to off 12:59:43 [root@batou:~] # apt purge zcfan Reading package lists... Done Building dependency tree... Done Reading state information... Done The following
Bug#1032276: Running as server spams the logs with "Console input too long!"
Package: quakespasm Version: 0.95.1+dfsg-1 Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, when using quakespasm as server (via the quake-server package), the daemon spams the following message at about ~160 messages per second until I terminate the daemon. Mar 02 14:10:33 batou quake-server[1026]: Console input too long! Mar 02 14:10:33 batou quake-server[1026]: Console input too long! Mar 02 14:10:33 batou quake-server[1026]: Console input too long! Mar 02 14:10:33 batou quake-server[1026]: Console input too long! Mar 02 14:10:33 batou quake-server[1026]: Console input too long! Mar 02 14:10:33 batou quake-server[1026]: Console input too long! Mar 02 14:10:33 batou quake-server[1026]: Console input too long! Mar 02 14:10:33 batou quake-server[1026]: Console input too long! Mar 02 14:10:33 batou quake-server[1026]: Console input too long! [...] This is a default installation together with quake-registered installed, and no further config customization. I had it installed for testing purposes. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages quakespasm depends on: ii libc6 2.36-8 ii libflac12 1.4.2+ds-2 ii libgl1 1.6.0-1 ii libmad0 0.15.1b-10.1+b1 ii libmikmod3 3.3.11.1-7 ii libopusfile00.12-4 ii libsdl2-2.0-0 2.26.3+dfsg-1 ii libvorbisfile3 1.3.7-1 quakespasm recommends no packages. quakespasm suggests no packages. -- no debconf information
Bug#1032077: `dch --lts` targets stretch instead of buster
Package: devscripts Version: 2.22.2 Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, running `dch --lts` will set the target distribution to stretch. However, the current LTS release is buster [0]. [0] https://wiki.debian.org/LTS -- Package-specific info: --- /etc/devscripts.conf --- Empty. --- ~/.devscripts --- BTS_SMTP_HOST="smtp.rocketjump.eu:587" DEBSIGN_KEYID="2FE2 163F 611C 80BE 2BF5 EE62 48D1 9F46 BC99 C9B7" -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages devscripts depends on: ii dpkg-dev 1.21.20 ii fakeroot 1.29-1 ii file 1:5.44-3 ii gnupg 2.2.40-1 ii gpgv 2.2.40-1 ii libc6 2.36-8 ii libfile-dirlist-perl 0.05-3 ii libfile-homedir-perl 1.006-2 ii libfile-touch-perl0.12-2 ii libfile-which-perl1.27-2 ii libipc-run-perl 20220807.0-1 ii libmoo-perl 2.005005-1 ii libwww-perl 6.67-1 ii patchutils0.4.2-1 ii perl 5.36.0-7 ii python3 3.11.2-1 ii sensible-utils0.0.17+nmu1 ii wdiff 1.2.2-5 Versions of packages devscripts recommends: ii apt 2.5.6 ii curl7.87.0-2 ii dctrl-tools 2.24-3+b1 ii debian-keyring 2022.12.24 ii dput-ng [dput] 1.35 pn equivs ii libdistro-info-perl 1.5 ii libdpkg-perl1.21.20 ii libencode-locale-perl 1.05-3 pn libgit-wrapper-perl pn libgitlab-api-v4-perl ii liblist-compare-perl0.55-2 ii liblwp-protocol-https-perl 6.10-1 pn libsoap-lite-perl ii libstring-shellquote-perl 1.04-3 ii libtry-tiny-perl0.31-2 ii liburi-perl 5.17-1 ii licensecheck3.3.5-1 ii lintian 2.116.3 ii man-db 2.11.2-1 ii patch 2.7.6-7 ii pristine-tar1.50 ii python3-apt 2.5.2+b1 ii python3-debian 0.1.49 ii python3-magic 2:0.4.26-3 ii python3-requests2.28.1+dfsg-1 pn python3-unidiff ii python3-xdg 0.28-2 ii strace 6.1-0.1 ii unzip 6.0-27 ii wget1.21.3-1+b2 ii xz-utils5.4.1-0.2 Versions of packages devscripts suggests: ii adequate 0.15.7 pn at ii autopkgtest 5.28 pn bls-standalone ii build-essential 12.9 pn check-all-the-things pn cvs-buildpackage ii debhelper 13.11.4 ii diffoscope234 ii disorderfs0.5.11-3 pn dose-extra pn duck pn elpa-devscripts ii faketime 0.9.10-2.1 pn gnuplot pn how-can-i-help ii libauthen-sasl-perl 2.1600-3 pn libdbd-pg-perl ii libfile-desktopentry-perl 0.22-3 ii libnet-smtps-perl 0.10-2 pn libterm-size-perl ii libtimedate-perl 2.3300-2 pn libyaml-syck-perl ii mailutils [mailx] 1:3.15-3+b2 ii mmdebstrap1.3.1-3 pn mozilla-devscripts pn mutt ii openssh-client [ssh-client] 1:9.2p1-2 ii piuparts 1.1.7 ii postgresql-client 15+247 ii postgresql-client-15 [postgresql-client] 15.2-1 pn pristine-lfs ii quilt 0.67+really0.66-1 pn ratt pn reprotest pn svn-buildpackage pn w3m -- no debconf information
Bug#1031835: quilt will create spurious files from certain patches on push/pop
Package: quilt Version: 0.67+really0.66-1 Severity: important X-Debbugs-Cc: deb...@rocketjump.eu Hi, some patches imported by quilt may be patch series, which create a file in one diff, but remove it again in another. In those cases quilt will correctly keep the file from existing on `quilt push`. However, on `quilt pop` the spurious file will be created. I have a minimal reproducer here: ---8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--- 23:01:22 [randall@batou:~/tmp] $ find . ./tmp.patch 23:01:23 [randall@batou:~/tmp] $ cat tmp.patch --- /dev/null +++ b/spurious_file @@ -0,0 +1 @@ +some content here --- a/spurious_file +++ /dev/null @@ -1 +0,0 @@ -some content here 23:01:28 [randall@batou:~/tmp] $ quilt import tmp.patch Importing patch tmp.patch (stored as tmp.patch) 23:01:32 [randall@batou:~/tmp] $ quilt push; quilt pop Applying patch tmp.patch patching file spurious_file patching file spurious_file Now at patch tmp.patch Removing patch tmp.patch Restoring spurious_file No patches applied 23:01:39 [randall@batou:~/tmp] $ find . ./.pc ./.pc/.version ./.pc/.quilt_series ./.pc/.quilt_patches ./spurious_file ./tmp.patch ./debian ./debian/patches ./debian/patches/tmp.patch ./debian/patches/series 23:01:43 [randall@batou:~/tmp] $ cat spurious_file some content here 23:01:48 [randall@batou:~/tmp] $ rm spurious_file 23:03:07 [randall@batou:~/tmp] $ quilt push --refresh; quilt pop Applying patch tmp.patch patching file spurious_file patching file spurious_file Refreshed patch tmp.patch Now at patch tmp.patch Removing patch tmp.patch Restoring spurious_file No patches applied 23:03:23 [randall@batou:~/tmp] $ cat spurious_file some content here ---8<--8<--8<--8<--8<--8<--8<--8<--8<--8<--- As you can see above, "spurious_file" is created after `quilt push; quilt pop`, even though it shouldn't exist (it's created on "pop"). This even persists when refreshing the patch, where it should at least drop both diffs completely. I've set the severity to important, as it breaks with the user's expectation, and potentially could cause spurious files ending up in source packages that shouldn't. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages quilt depends on: ii bsdextrautils 2.38.1-4 ii bzip2 1.0.8-5+b1 ii diffstat1.65-1 ii ed 1.19-1 ii gettext 0.21-11 ii patch 2.7.6-7 ii perl5.36.0-7 ii sensible-utils 0.0.17+nmu1 Versions of packages quilt recommends: ii less 590-1.1 Versions of packages quilt suggests: pn default-mta | mail-transport-agent ii graphviz2.42.2-7+b3 pn procmail -- no debconf information
Bug#1031409: Add wireguard support
Package: gnome-control-center Version: 1:43.4.1-1 Severity: minor Tags: patch X-Debbugs-Cc: deb...@rocketjump.eu Hi, Since network-manager supports wireguard, and gnome-control-center is the default connection editor in gnome, it would be nice to add wireguard support as already merged upstream: https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1364 Greets, Lee -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-3-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnome-control-center depends on: ii accountsservice 22.08.8-5 ii apg 2.2.3.dfsg.1-5+b2 ii colord1.4.6-2.1 ii desktop-base 12.0.2 ii desktop-file-utils0.26-1 ii gnome-control-center-data 1:43.4.1-1 ii gnome-desktop3-data 43.1-1 ii gnome-settings-daemon 43.0-4 ii gsettings-desktop-schemas 43.0-1 ii libaccountsservice0 22.08.8-5 ii libadwaita-1-01.2.1-2 ii libc6 2.36-8 ii libcairo2 1.16.0-7 ii libcolord-gtk4-1 0.3.0-3 ii libcolord21.4.6-2.1 ii libcups2 2.4.2-1+b2 ii libepoxy0 1.5.10-1 ii libfontconfig12.14.1-4 ii libgcr-base-3-1 3.41.1-1+b1 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.5-1 ii libgnome-bg-4-2 43.1-1 ii libgnome-bluetooth-ui-3.0-13 42.5-3 ii libgnome-desktop-4-2 43.1-1 ii libgnome-rr-4-2 43.1-1 ii libgnutls30 3.7.8-5 ii libgoa-1.0-0b 3.46.0-1 ii libgoa-backend-1.0-1 3.46.0-1 ii libgsound01.0.3-2 ii libgtk-3-03.24.36-3 ii libgtk-4-14.8.3+ds-2 ii libgtop-2.0-112.40.0-2 ii libgudev-1.0-0237-2 ii libibus-1.0-5 1.5.27-4 ii libkrb5-3 1.20.1-1 ii libmalcontent-0-0 0.11.0-4 ii libmm-glib0 1.20.4-1 ii libnm01.40.10-1 ii libnma-gtk4-0 1.10.6-1 ii libpango-1.0-01.50.12+ds-1 ii libpangocairo-1.0-0 1.50.12+ds-1 ii libpolkit-gobject-1-0 122-3 ii libpulse-mainloop-glib0 16.1+dfsg1-2+b1 ii libpulse0 16.1+dfsg1-2+b1 ii libpwquality1 1.4.5-1+b1 ii libsecret-1-0 0.20.5-3 ii libsmbclient 2:4.17.5+dfsg-2 ii libsnapd-glib-2-1 1.63-5 ii libudisks2-0 2.9.4-4 ii libupower-glib3 0.99.20-2 ii libwacom9 2.5.0-1 ii libx11-6 2:1.8.3-3 ii libxi62:1.8-1+b1 ii libxml2 2.9.14+dfsg-1.1+b3 ii webp-pixbuf-loader0.0.5-5 Versions of packages gnome-control-center recommends: ii cracklib-runtime 2.9.6-5+b1 ii cups-pk-helper0.2.6-1+b1 ii gkbd-capplet 3.28.1-1 ii gnome-bluetooth-sendto42.5-3 ii gnome-online-accounts 3.46.0-1 ii gnome-remote-desktop 43.3-1 ii gnome-user-docs 43.0-1 ii gnome-user-share 43.0-1 ii iso-codes 4.12.0-1 ii libcanberra-pulse 0.30-10 pn libnss-myhostname ii libspa-0.2-bluetooth 0.3.65-2 ii malcontent-gui0.11.0-4 ii network-manager-gnome 1.30.0-2 ii polkitd 122-3 ii power-profiles-daemon 0.12-1+b1 pn realmd ii rygel 0.42.0-2 ii rygel-tracker 0.42.0-2 ii system-config-printer-common 1.5.18-1 Versions of packages gnome-control-center suggests: ii gnome-software 43.3-1 pn gstreamer1.0-pulseaudio ii pkexec 122-3 ii x11-xserver-utils7.7+9+b1 -- debconf-show failed
Bug#995156: easy-rsa: vars Autodetection
I'm bumping the bug severity because currently it will ignore security-relevant settings like keysize and algo, and the defaults are pretty weak.
Bug#1029588: bts: Changes in libio-socket-ssl-perl 2.078 make bts fail to send mail to mail-server via SSL/TLS - hostname verification failed
Bumped severity as this makes bts currently unusable, and probably breaks for quite a few DDs their workflow.
Bug#1030290: python3-gtts: Outdated, no longer works
Package: python3-gtts Version: 2.0.3-4 Severity: important The current version of this package no longer works: gtts.tts - WARNING - Unable to get language list: 'NoneType' object is not subscriptable Usage: gtts-cli [OPTIONS] Try 'gtts-cli -h' for help. Error: Unable to find token seed! Did https://translate.google.com change? Searching upstream finds e.g. https://github.com/pndurette/gTTS/issues/354 suggesting that this is fixed upstream and the package just needs an update. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable'), (490, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT) 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: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python3-gtts depends on: ii python33.11.1-2 ii python3-bs44.11.1-3 ii python3-click 8.1.3-2 ii python3-gtts-token 1.1.3-3 ii python3-pkg-resources 65.6.3-1 ii python3-requests 2.28.1+dfsg-1 ii python3-six1.16.0-4 python3-gtts recommends no packages. python3-gtts suggests no packages. -- no debconf information
Bug#1030173: Document breaking changes in NEWS.Debian
On 31/01/2023 22:08, Vincent Bernat wrote: On 2023-01-31 21:44, Lee Garrett wrote: with release 2.6 haproxy has dropped the "ssl-engine" keyword by default. Would be nice to document that in NEWS.Debian so it gets shown by tools such as apt-listchanges during upgrade from bullseye to bookworm. In my case haproxy failed to start with my bullseye config since it still had the "ssl-engine" keyword in it. I understand this would be useful, but it opens me to get bugs like "NEWS.Debian says something about ssl-engine, but not about some other change". I would need to make a summary of upstream's CHANGELOG file. This seems a tedious task. I've written a NEWS file for you: haproxy (2.6.8-2) unstable; urgency=medium Starting with haproxy 2.6, the "ssl-engine" keyword has been removed. You will need to remove this setting for your previous config to continue to work. Previously, clients sending an invalid request header like "Version: rtsp/1.1" would still get their request being served. Starting with haproxy 2.6, this will result in a 502 response. If you depend on the old, buggy behaviour, set "option accept-invalid-http-requests" in the relevant config section. -- Lee Garrett Tue, 31 Jan 2023 22:57:05 +0100
Bug#1030173: Document breaking changes in NEWS.Debian
On 31/01/2023 22:08, Vincent Bernat wrote: On 2023-01-31 21:44, Lee Garrett wrote: with release 2.6 haproxy has dropped the "ssl-engine" keyword by default. Would be nice to document that in NEWS.Debian so it gets shown by tools such as apt-listchanges during upgrade from bullseye to bookworm. In my case haproxy failed to start with my bullseye config since it still had the "ssl-engine" keyword in it. I understand this would be useful, but it opens me to get bugs like "NEWS.Debian says something about ssl-engine, but not about some other change". I would need to make a summary of upstream's CHANGELOG file. This seems a tedious task. I wouldn't list all changes there, only those that break existing setups. So stuff where admins need to get active. AFAICS there are only three backwards-incompatible changes [0]: - "ssl-engine" being dropped - openssl 0.9.8 support being dropped (irrelevant, as the package is built against a newer version) - previously, clients sending an invalid "Version: rtsp/1.1" header would still get their request served, this is now caught and a 502 served. The old behaviour can be enabled with "option accept-invalid-http-request" All other changes add new options, or improve on existing behaviour, so nothing that breaks existing config during upgrade. I'm fine with writing a NEWS.Debian for you as I think users would benefit from it. I think the ssl-engine drop is a bigger speedbump, as configs with that setting will silently fail on upgrade, as there doesn't seem to be any validation of it when it gets restarted. I only noticed a bit later as some of my services weren't reachable. [0] https://www.mail-archive.com/haproxy@formilux.org/msg42371.html, grep for "potentially user-visible changes"
Bug#1030173: Document breaking changes in NEWS.Debian
Package: haproxy Version: 2.6.8-1 Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, with release 2.6 haproxy has dropped the "ssl-engine" keyword by default. Would be nice to document that in NEWS.Debian so it gets shown by tools such as apt-listchanges during upgrade from bullseye to bookworm. In my case haproxy failed to start with my bullseye config since it still had the "ssl-engine" keyword in it. Thanks for maintaining haproxy! - Lee -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages haproxy depends on: ii adduser3.118 ii dpkg 1.20.12 ii init-system-helpers1.60 ii libc6 2.31-13+deb11u5 ii libcrypt1 1:4.4.18-4 ii libgcc-s1 10.2.1-6 ii liblua5.3-05.3.3-1.1+b1 pn libopentracing-c-wrapper0 ii libpcre2-8-0 10.36-2+deb11u1 ii libssl1.1 1.1.1n-0+deb11u3 pn libssl3 ii libsystemd0247.3-7+deb11u1 ii lsb-base 11.1.0 ii zlib1g 1:1.2.11.dfsg-2+deb11u2 haproxy recommends no packages. Versions of packages haproxy suggests: pn haproxy-doc pn vim-haproxy
Bug#1029803: command-not-found breaks dist-upgrade bullseye → bookworm
Package: command-not-found Version: 20.10.1-1 Severity: grave Tags: patch X-Debbugs-Cc: deb...@rocketjump.eu, k...@debian.org Hi Julian, (this is somewhat related to #968757 and #954249) (kibi CCed) Steps to reproduce (on an bullseye installation) 1) Install command-not-found 2) Edit /etc/apt/sources.list to deb http://deb.debian.org/debian/ bookworm main contrib non-free non-free-firmware (note the new component non-free-firmware) 3) run `apt update` # apt update Hit:1 http://deb.debian.org/debian bullseye InRelease Hit:2 http://deb.debian.org/debian-security bullseye-security InRelease Hit:3 http://deb.debian.org/debian bullseye-updates InRelease Hit:4 http://deb.debian.org/debian bullseye-backports InRelease Hit:5 https://packages.chef.io/repos/apt/stable bullseye InRelease Hit:6 http://deb.debian.org/debian bookworm InRelease Hit:7 http://deb.debian.org/debian sid InRelease Hit:8 http://deb.debian.org/debian experimental InRelease Traceback (most recent call last): File "/usr/lib/cnf-update-db", line 26, in col.create(db) File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 95, in create self._fill_commands(con) File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 143, in _fill_commands self._parse_single_contents_file(con, f, fp.stdout) File "/usr/share/command-not-found/CommandNotFound/db/creator.py", line 282, in _parse_single_contents_file priority = component_priorities[component] KeyError: 'non-free-firmware' Reading package lists... Done E: Problem executing scripts APT::Update::Post-Invoke-Success 'if /usr/bin/test -w /var/lib/command-not-found/ -a -e /usr/lib/cnf-update-db; then /usr/lib/cnf-update-db > /dev/null; fi' E: Sub-process returned an error code This is already fixed in unstable, but in it's current form this will break the upgrade path from bullseye to bookworm. The fix is trivial, adding `'non-free-firmware': 60,` to CommandNotFound/db/creator.py is enough. I propose doing a p-u to fix it. Greets, Lee -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages command-not-found depends on: ii apt-file 3.2.2 ii lsb-release 11.1.0 ii python3 3.9.2-3 ii python3-apt 2.2.1 command-not-found recommends no packages. Versions of packages command-not-found suggests: pn snapd -- no debconf information -- debsums errors found: debsums: changed file /usr/share/command-not-found/CommandNotFound/db/creator.py (from command-not-found package)
Bug#1028405: ansible-core: autopkgtest regresses with new python3-defaults (python 3.11)
IIRC this was added because the last python transition (3.9->3.10) broke
the autopkgtests, so I've added it. As this seems to work this time
around, I acknowledge the NMU.
On Tue, 10 Jan 2023 08:21:09 -0800 Steve Langasek
wrote:
Package: ansible-core
Version: 2.14.1-1
Severity: serious
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu lunar ubuntu-patch
Hi Lee,
The ansible-core autopkgtests fail now that /usr/bin/python3 is python 3.11:
[...]
autopkgtest [08:17:06]: test unit: [---
FATAL: Running under Python version 3.11 instead of 3.10.
FATAL: Command "/usr/bin/env
ANSIBLE_TEST_CONTENT_ROOT=/tmp/autopkgtest-lxc.8ik95lf6/downtmp/build.jHa/src
PYTHONPATH=/tmp/ansible-test-iin32i73 /usr/bin/python3 /usr/bin/ansible-test units
--containers '{}' --truncate 0 --color no --host-path test/results/.tmp/host-n2w5rzai
--metadata test/results/.tmp/metadata-_yj0am3d.json" returned exit status 1.
autopkgtest [08:17:07]: test unit: ---]
[...]
(https://ci.debian.net/data/autopkgtest/unstable/amd64/a/ansible-core/29976247/log.gz)
This comes down to a hard-coded "--python 3.11" option in the autopkgtest
which seems superfluous.
I have uploaded the attached patch to Ubuntu to unblock the python3-defaults
transition there.
Cheers,
--
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
Bug#1029137: Use dh sequencer in debian/rules
Source: rp-pppoe Severity: normal Tags: newcomer X-Debbugs-Cc: deb...@rocketjump.eu This bug report is tagged "newcomer" as it a good bug where you can learn about debian/rules and dh. debian/rules currently uses a rather lengthy hand-written sequencer for debhelper tools. Current practice is to use a much shorter one as described at file:///usr/share/doc/maint-guide/html/dreq.en.html#rules https://www.debian.org/doc/manuals/maint-guide/dreq.en.html#rules Where needed, use execute_after_dh_, execute_before_dh_, or even override_dh_ to recreate the original flow as closely as possible. In the second step you could then trim away any commands that are there for historical reasons and not needed. -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-0.deb11.6-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1028473: dictionaries-common: problem in russian dict. Word '��� ��' contains illegal characters.
Package: dictionaries-common Version: 1.29.3 Followup-For: Bug #1028473 X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com Thank you for the reply. If these dictionaries are installed, where are they located? I've searched /usr/lib/ispell and many other places can only find american and british dictionaries on my machine. Also where does the "contains illegal characters" message actually come from? Whatever the source of that messgae, I'm having trouble tracking it down. A techincal explaination about why the message is harmless would also be interesting for me. Perhaps the message itself and the logic that produces it could be improved to provide a nicer user experience.
Bug#1028245: nala: missing dependency
Hi thanks for using Nala and reporting bugs. This has been fixed upstream actually. We're currently working through a bug that is causing Nala to get removed from the testing repos. Once we fix that and release then this will be fixed, On Sun, Jan 8, 2023, at 2:13 PM, dimit...@stinpriza.org wrote: > Package: nala > Version: 0.12.0 > Severity: important > > happy new year! > > seems that nala fails if python3-debian is not installed. error : > > $ doas nala update > Traceback (most recent call last): > File "/usr/bin/nala", line 5, in > from nala.__main__ import main > File "/usr/lib/python3/dist-packages/nala/__main__.py", line 31, in > import nala.fetch as _fetch # pylint: disable=unused-import > File "/usr/lib/python3/dist-packages/nala/fetch.py", line 66, in > from debian.deb822 import Deb822 # isort:skip > ModuleNotFoundError: No module named 'debian' > > > installing python3-debian fixes this and nala runs as it should.. > but package is not listed as nala dependency.. > > thanks, > d. > > -- System Information: > Debian Release: bookworm/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.10.142-antix.2-amd64-smp (SMP w/4 CPU threads; PREEMPT) > Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE > Locale: LANG=el_GR.UTF-8, LC_CTYPE=el_GR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US > Shell: /bin/sh linked to /usr/bin/dash > Init: runit (via /run/runit.stopit) > > Versions of packages nala depends on: > ii apt2.5.4.0nosystemd1 > ii python33.10.6-3+b1 > ii python3-anyio 3.6.2-1 > ii python3-apt2.5.0 > ii python3-httpx 0.23.1-1 > ii python3-pexpect4.8.0-4 > ii python3-rich 13.0.0-1 > ii python3-tomli 2.0.1-2 > ii python3-typer 0.7.0-1 > ii python3-typing-extensions 4.3.0-2 > > Versions of packages nala recommends: > ii python3-socksio 1.0.0-2 > > nala suggests no packages. > > -- no debconf information >
Bug#1028473: dictionaries-common: problem in russian dict. Word '��� ��' contains illegal characters.
Package: dictionaries-common Version: 1.29.3 Severity: minor X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com Dear Maintainer, About two weeks ago on a fresh install of Debian Bookworm from a daily installer build I came accross a dictionary error related to the installation of synaptic. The relavent output is Setting up synaptic (0.91.2) ... Processing triggers for dictionaries-common (1.29.3) ... ispell-autobuildhash: Processing 'american' dict. ispell-autobuildhash: Processing 'brasilero' dict. ispell-autobuildhash: Processing 'british' dict. ispell-autobuildhash: Processing 'catala' dict. ispell-autobuildhash: Processing 'danish' dict. ispell-autobuildhash: Processing 'espa-nol' dict. ispell-autobuildhash: Processing 'lietuviu' dict. ispell-autobuildhash: Processing 'ngerman' dict. ispell-autobuildhash: Processing 'polish' dict. ispell-autobuildhash: Processing 'portugues' dict. ispell-autobuildhash: Processing 'russian' dict. Word '��� ��' contains illegal characters. ispell-autobuildhash: Processing 'swiss' dict. It looks to be an error in a dictionary file but I never selected any language except English so this is default behavior and as far as I can tell I do not even have the russian dictionary installed at all. My best guess is that this is a issue in dictionaries-common/dc-deconf-select.pl and/or related files related to dpkg triggers. If you'd like more details about this just suggest what extra info you'd like and I can try to supply it. Cheers, Jason -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dictionaries-common depends on: ii debconf [debconf-2.0] 1.5.81 ii emacsen-common 3.0.5 ii libtext-iconv-perl 1.7-8 dictionaries-common recommends no packages. Versions of packages dictionaries-common suggests: ii aspell0.60.8-4+b1 ii ispell3.4.05-1 ii wamerican [wordlist] 2020.12.07-2 -- debconf information: dictionaries-common/ispell-autobuildhash-message: * dictionaries-common/default-ispell: american (American English) * dictionaries-common/default-wordlist: american (American English) dictionaries-common/selecting_ispell_wordlist_default: dictionaries-common/invalid_debconf_value: dictionaries-common/debconf_database_corruption: dictionaries-common/old_wordlist_link: true
Bug#1028033: xfce4 package incorrectly reporting version 4.16 instead of 4.18
Package: xfce4 Version: 4.16 Severity: normal X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com Dear Maintainer, The xfce4 package still thinks xfce 4.16 is being used even though it is now 4.18. I use Synaptic and it shows that the xfce4 package reports 4.16 as both the "Installed" and "Latest Version". This system was installed through a daily installer after the change to 4.18 so all vestiges of 4.16 should be gone. I picked "XFCE" as my desktop during an expert net install. The task-xfce-desktop package is reporting itself as version 3.70. I'd guess it's just a minor packaging error where a versioning number was forgotten to be changed. Cheers, Jason -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages xfce4 depends on: ii libxfce4ui-utils 4.18.0-1 ii thunar 4.18.0-1 ii xfce4-appfinder 4.18.0-1 ii xfce4-panel 4.18.0-1 ii xfce4-pulseaudio-plugin 0.4.5-1 ii xfce4-session4.18.0-1 ii xfce4-settings 4.18.0-1 ii xfconf 4.18.0-1 ii xfdesktop4 4.18.0-1 ii xfwm44.18.0-1 Versions of packages xfce4 recommends: ii desktop-base 12.0.2 ii tango-icon-theme 0.8.90-11 ii thunar-volman 4.18.0-1 ii xfce4-notifyd 0.6.5-1 ii xorg 1:7.7+23 Versions of packages xfce4 suggests: ii xfce4-goodies4.14.0 ii xfce4-power-manager 4.18.0-1 -- no debconf information
Bug#1027841: desktop-base: Please provide UHD images for Debian 12 (emerald theme)
Package: desktop-base Version: 12.0.2 Severity: wishlist Updating some systems to Bookworm to try things out, I noticed the new desktop theme is blurry on many systems compared to Bullseye, becaues the Bullseye default "Homeworld" theme came with images (esp. SVGs) targeting several resolutions above 1080p-ish, while Emerald tops out at 1920x1080/1200. It feels especially sad to have _vector_ images do blurry pixel-oriented upscaling -- GNOME at least seems to render the SVG at its target resolution and then do a raster scaling to the screen resolution. That's not this package's fault, but it can certainly provide copies of the SVGs that target the higher res with very minimal editing. For example, this tiny edit is enough to make the 1920x1080 render crisply at 3840x2160, when combined with corresponding changes to the metadata file(s): --- /usr/share/desktop-base/emerald-theme/wallpaper/contents/images/1920x1080.svg 2022-12-23 12:31:20.0 -0500 +++ /usr/share/desktop-base/emerald-theme/wallpaper/contents/images/3840x2160.svg 2023-01-03 17:18:55.791977381 -0500 @@ -1,6 +1,7 @@ http://www.w3.org/2000/svg; xmlns:xlink="http://www.w3.org/1999/xlink; x="0px" y="0px" + scale-x="0.5" width="3840" height="2160" viewBox="0 0 1920 1080" style="enable-background:new 0 0 1920 1080;" xml:space="preserve">
Bug#1027301: desktop-base: Positioning of the "Debian 12" logo on GRUB2 splashscreen makes GRUB2 text hard to read
Package: desktop-base Version: 12.0.2 Severity: important X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com Dear Maintainer, While the GRUB2 menu is being displayed, there's a "Debian 12" logo on the splashscreen in the lower lefthand corner. GRUB2 however displays text there (including the countdown timer message) and it is very hard to read because of the logo. This may depend on the user's screen resolution. I'm using 1440p and the the positioning conflict is maximally bad there. The logo would be much better positioned if it were on the lower LEFT-hand side. Cheers, Jason PS I used yesterday's daily Bookworm net installer so the issue is as current as it could be. PPS I noticed below in the auto generated message from reportbug that desktop-base is suggesting xfce 4.16. That should also be changed because we recently updated testing to 4.18. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.0.0-6-amd64 (SMP w/24 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages desktop-base depends on: ii fonts-quicksand 0.2016-2.1 ii librsvg2-common 2.54.5+dfsg-1 Versions of packages desktop-base recommends: ii plymouth-label 22.02.122-2 Versions of packages desktop-base suggests: ii xfce4 4.16 -- no debconf information
Bug#1027133: man page contains non-existant sha3deep
Package: hashdeep Version: 4.4-7 Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, the man pages contain a reference to sha3deep: sha3deep - Compute and compare SHA-3-256 message digests However, this binary is not installed. Creating a symlink named "sha3deep" to the binary does not work around the issue: 10:31:05 [root@batou:/usr/local/bin] # ln -s ../../bin/md5deep sha3deep 10:31:09 [root@batou:/usr/local/bin] # ./sha3deep sha3deep: Unknown algorithm: sha3 Try `sha3deep -h` for more information. So it seems like the binary doesn't support SHA3-256, and the line should be removed in the man page. Greetings, Lee -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.2 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages hashdeep depends on: ii libc6 2.31-13+deb11u5 ii libgcc-s1 10.2.1-6 ii libstdc++6 10.2.1-6 hashdeep recommends no packages. hashdeep suggests no packages. -- no debconf information
Bug#1026944: upstream homepage returns 404
Package: ksmtuned Version: broken link to upstream homepage Severity: minor X-Debbugs-Cc: deb...@rocketjump.eu Hi, d/control points to https://git.centos.org/summary/rpms!qemu-kvm, which returns 404. I tried finding the new upstream homepage, but a quick google search didn't find it. Regards, Lee -- System Information: Debian Release: 11.6 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 6.0.2 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ksmtuned depends on: ii libc6 2.31-13+deb11u5 Versions of packages ksmtuned recommends: ii qemu-system-x86 [qemu-kvm] 1:5.2+dfsg-11+deb11u2 ksmtuned suggests no packages.
Bug#982842: Regarding Debian bug #982842, "open-iscsi: do not use iscsistart in the boot process"
On 12/2/22 11:23, Eric Mackay wrote: Greetings Heinrich and Lee, Reaching out to both of you directly because I'm not sure that replies on the Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982842 were actually propagated I made a merge request to the Debian open-iscsi package that adds this feature: https://salsa.debian.org/linux-blocks-team/open-iscsi/-/merge_requests/14 But the maintainers don't seem to see the importance of using an iscsi root, and/or the shortcomings of iscsistart. Would appreciate any further comments on the bug or the merge request, as I'm hoping to move this along. Even if they're negative comments :) Hi All: Sorry it took me a while to get around to replying to this. First, responses to the bug report, i.e.: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982842 Ritesh Raj Sarraf says: Yes. But usually, you don't need the iscsid daemon in initrd. Because most usual cases, users would be mapping data LUNs only. This is not my experience at all. Our distribution only supports having root or /usr on iscsi at initrd time. If it is a "data lun" (e.g. /usr/local or /alt) there is no reason to mount it at initrd time -- it can wait until we have the full root filesystem up, since that's much simpler. he goes on to say: Only in exceptional cases, where you have root on iSCSI, you need to establish the connections early. And to do that we used iscsistart, which would establish only a single connection, effectively making it prone to hangs if that single connection went down. Using iscsistart is a "shortcut" to having the daemon present. Many iscsiroot users these days are using multipathing, with two independant paths to the root disc using iscsi, and these cases get a bit complicated for iscsistart, which is completely synchronous. For example, iscsiadm/iscsid have the ability to send login requests but not wait for them to return, potentially making login to slow targets (or over slow networks) faster. Lastly, he says: The other reason I can recollect is that you could have a very large number of LUNs mapped to your initiator along with your root LUN. If you push everything to be processed in initrd: This is not how it works in open-iscsi. Only LUNs marked as "onboot" are handled in the initrd. Generally, LUNs marked "automatic" are brought up when the system comes up, and LUNs marked as "manual" are only brought up manually by the administrator. In the bug report, Heinrich Schuchardt asked: My current configuration is: iscsid.conf:40: # node.startup = automatic nodes/iqn.2000-01.de.xypron:pine-a64-lts/192.168.0.1,3260,1/default:4: node.startup = manual nodes/iqn.2000-01.de.xypron:pine-a64-lts/192.168.0.1,3260,1/default:52: node.conn[0].startup = manual File /etc/iscsi/iscsi.initramfs specifies the root device. HWADDR="01:02:03:04:05:06" ISCSI_TARGET_NAME="iqn.2000-01.de.xypron:pine-a64-lts" ISCSI_TARGET_IP="192.168.0.1" ISCSI_TARGET_PORT="3260" ISCSI_TARGET_GROUP="1" ISCSI_USERNAME="user" ISCSI_PASSWORD="password" Where would "onboot" fit into the image? What makes a target an "onboot" target? Do you simply mean the one specified in /etc/iscsi/iscsi.initramfs? Debian uses a different method than SUSE when it comes to setting up the initrd/initramfs. Nodes can have 3 "startup" values, as mentioned above: onboot, manual, or automatic. The one that matters most at runtime is "automatic", since those are the ones that iscsi.service logs into automatically, for you, when the system starts (if you have the service enabled). So not having the node show up as "startup=onboot" is okay, because the initrd knows already it is a boot iscsi target, and because iscsid will refuse to terminate the session, since it was started from "firmware". (But, side note: it's also helpful to set "safe_logout" in iscsid.conf on systems with iscsi root discs.) As far as the feature request: https://salsa.debian.org/linux-blocks-team/open-iscsi/-/merge_requests/14 It seems fairly reasonable to me, though I'm not the one that gets to implement this feature, if the request is accepted. :) It seems like it does not change the default behavior, so there is little risk of breakage. I would be more than happy to offer advice and/or help, if needed, since I have a special place of dislike in my heart for iscsistart. -- Lee Duncan open-iscsi co-maintainer
Bug#1023688: incorrect syntax in patch
The modification to fcgiwrap.socket doesn’t appear to use values recognised by systemd. I believe the configuration: Mode=0660 SocketUser=www-data SockerGroup=www-data Should actually be: SocketMode=0660 SocketUser=www-data SocketGroup=www-data
Bug#1025335: ansible-core: autopkgtests need to depend on python3-pytest-forked
On 06/12/2022 22:54, Scott Talbert wrote: On December 2, 2022 2:54:19 PM EST, Lee Garrett wrote: On 02/12/2022 19:15, Scott Talbert wrote: Source: ansible-core Version: 2.14.0-1 Severity: important ansible-core's autopkgtests need to add a Depends on python3-pytest-forked. python3-pytest-xdist used to depend on -forked, but it no longer does. See, for example: https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28872265/log.gz Thanks! Will update it in the next release. Also, ansible needs to same update. If you could make these updates in the relatively short term it would be appreciated. pytest-xdist can't migrate otherwise. And done. Thanks for catching it! Thanks, Scott
Bug#1025335: ansible-core: autopkgtests need to depend on python3-pytest-forked
On 02/12/2022 19:15, Scott Talbert wrote: Source: ansible-core Version: 2.14.0-1 Severity: important ansible-core's autopkgtests need to add a Depends on python3-pytest-forked. python3-pytest-xdist used to depend on -forked, but it no longer does. See, for example: https://ci.debian.net/data/autopkgtest/testing/amd64/a/ansible-core/28872265/log.gz Thanks! Will update it in the next release.
