Bug#684134: Package 'locales' resets pre-set debconf variable 'default_environment_locale' on install
Hi Aurelien! On 26.07.24 13:11, Aurelien Jarno wrote: Hi, On 2024-07-25 00:34, Lee Garrett wrote: So when /etc/locale.gen exists, this file is read, and then the settings in the debconf database overwritten by those value. So once debconf is installed, there's no programmatic way via debconf to change the locale. A workaround is template the files /etc/locale.gen and /etc/locale.conf and then run dpkg-reconfigure locales. Yes, this works exactly as expected. debconf can be used to preconfigure the package before it gets installed. But *debconf is not a registry*. The way to change the configuration is by editing the files. This is very clear in the debconf manual: "You can also use debconf in other, standalone programs. The issue to watch out for here is that debconf is not intended to be, and must not be used as a registry. This is unix after all, and programs are configured by files in /etc, not by some nebulous debconf database (that is only a cache anyway and might get blown away). So think long and hard before using debconf in a standalone program." https://manpages.debian.org/unstable/debconf-doc/debconf-devel.7.en.html Indeed. This doesn't seem to be widely spread knowledge, though. A google search [0] mostly reveals hits from 20 years ago (and, ironically, now this bug report). Fine by me then. However, from the user perspective, this is inconsistent behaviour that depends on the order of things. Assume the following possible steps a user can take: A) install locales B) set debconf values C) run `dpkg-reconfigure --frontend=noninteractive locales` D) run `dpkg-reconfigure locales` interactively ABD -> debconf is authoritative ABC -> config files are authoritative BAC -> debconf is authoritative Given that a lot more installations nowadays are programmatically provisioned and also administered through config management, I believe this is a more important issue than 20 years ago. This however seems counterintuitive to me, as practically all other packages using debconf have the debconf database as authoritative data from which the config is written (e.g. apt-cacher-ng, ca-certificates, console-setup, iproute2, grub-efi-amd64, grub-pc, postfix, tzdata, wireshark-common, to name a few). Then those packages are buggy, please report bugs. And I really doubt about the behaviour you describe, for at least tzdata. Indeed, you are right: # debconf-get-selections | grep 'tzdata/Zones/Europe'; cat /etc/timezone tzdata tzdata/Zones/Europe select Berlin Europe/Berlin # cat | debconf-set-selections tzdata tzdata/Zones/Europe select Bratislava # debconf-get-selections | grep 'tzdata/Zones/Europe'; cat /etc/timezone tzdata tzdata/Zones/Europe select Bratislava Europe/Berlin # dpkg-reconfigure --frontend=noninteractive tzdata Current default time zone: 'Europe/Berlin' Local time is now: Fri Jul 26 16:41:02 CEST 2024. Universal Time is now: Fri Jul 26 14:41:02 UTC 2024. # debconf-get-selections | grep 'tzdata/Zones/Europe'; cat /etc/timezone tzdata tzdata/Zones/Europe select Berlin Europe/Berlin Neither /etc/locale.gen, nor /etc/locale.conf are marked as conffiles, so they shouldn't edited by users, and neither be preserved, nor authoritative on the matter. As such, I'm raising the bug severity. They are not conffiles, because there are not mandatory and thus not shipped by the package. But it's something we can change. True. I think that was what threw me off. Since they're not conffiles, I assume they should not be edited. Especially since they are overwritten when debconf is run interactively (but not when run non-interactively). In any case, as you raised the bug to serious, could you please tell me which section of the Debian policy is violated? I guess 10.7.3. would be the closest match. "These scripts must be idempotent (i.e., must work correctly if dpkg needs to re-run them due to errors during installation or removal), must cope with all the variety of ways dpkg can call maintainer scripts, must not overwrite or otherwise mangle the user’s configuration without asking, must not ask unnecessary questions (particularly during upgrades), and must otherwise be good citizens." In this case it's not idempotent (in the broader sense), depending on if debconf are set before or after package installation. But this seems like a broader issue that might need to be discussed on debian-devel. As such I'm downgrading the bug again to unblock transitions to testing. I think shipping locale.gen and locale.conf as conffiles would still be nice to have. Shall I file a seperate bug for that? I propose to remove the shown code lines from locales.config. This would make any debconf selections authoritative again. As said above this is wrong. Agreed. A compromise would be to add another debconf option that decides on which side is authoritative (either config file, or debconf), but IMHO that adds co
Bug#684134: Package 'locales' resets pre-set debconf variable 'default_environment_locale' on install
nor authoritative on the matter. As such, I'm raising the bug severity. I propose to remove the shown code lines from locales.config. This would make any debconf selections authoritative again. A compromise would be to add another debconf option that decides on which side is authoritative (either config file, or debconf), but IMHO that adds complexity without much benefit. Regards, Lee
Bug#1076343: setup-testbed will break networking in certain conditions
On 14.07.24 20:48, Lee Garrett wrote: [...] In a step not completely clear to me network-manager then gets removed in line 620 [1]. I at least can't make out any package there that network-manager depends on. I found the reason; it's because xml-core gets removed.
Bug#1076343: setup-testbed will break networking in certain conditions
Package: autopkgtest Version: 5.28 Severity: normal X-Debbugs-Cc: deb...@rocketjump.eu Hi, issue is that setup-testbed will break networking config of a VM by writing a broken config file, e.g. /etc/network/interfaces/enp0s31f6\nenx482ae3598891 with the following contents: auto enp0s31f6 enx482ae3598891 iface enp0s31f6 enx482ae3598891 iface dhcp The reason is the following: I'm calling setup-testbed from within vmdb2, which will chroot into the filesystem before executing the command. As such, $root=/ and line 429 [0] will evaluate to true. In the next step, `cd /sys/class/net; ls -d e* 2>/dev/null` is run, which returns two network interfaces on my machine: enp0s31f6 and enx482ae3598891. And a few steps later the above broken ifupdown config file will be written out. There are several problems with the code: First, it assumes that if being run with $root=/ that it's already in a VM, whereas it can be running in a chroot. The second problem is that if `ls -d e*` returns more than one line the config it creates will be broken. In a step not completely clear to me network-manager then gets removed in line 620 [1]. I at least can't make out any package there that network-manager depends on. I was able to work around this (admittedly hilarious) bug by setting AUTOPKGTEST_IS_SETUP_COMMAND=1. Regards, Lee [0] https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/setup-commands/setup-testbed?ref_type=heads#L429 [1] https://salsa.debian.org/ci-team/autopkgtest/-/blob/master/setup-commands/setup-testbed?ref_type=heads#L620 -- System Information: Debian Release: 12.6 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-22-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 autopkgtest depends on: ii apt-utils 2.6.1 ii libdpkg-perl1.21.22 ii procps 2:4.0.2-3 ii python3 3.11.2-1+b1 ii python3-debian 0.1.49 Versions of packages autopkgtest recommends: ii autodep8 0.28 ii fakeroot 1.31-1.2 Versions of packages autopkgtest suggests: pn docker.io ii fakemachine 0.0.4-1+b2 ii lxc 1:5.0.2-1+deb12u2 pn lxd ii ovmf 2022.11-6+deb12u1 pn ovmf-ia32 pn podman ii python3-distro-info 1.5+deb12u1 ii qemu-efi-aarch64 2022.11-6+deb12u1 ii qemu-efi-arm 2022.11-6+deb12u1 ii qemu-system 1:7.2+dfsg-7+deb12u6 ii qemu-utils 1:7.2+dfsg-7+deb12u6 ii schroot 1.6.13-3+b2 ii util-linux 2.38.1-5+deb12u1 ii vmdb20.27+really.0.26-1 ii zerofree 1.1.1-1 -- no debconf information
Bug#1069768: The 'no-agent-forwarding' key restriction disables server alive message support
On 09.07.24 17:24, Guilhem Moulin wrote: On Tue, 09 Jul 2024 at 14:20:59 +0200, Guilhem Moulin wrote: On Sat, 29 Jun 2024 at 15:52:49 +0200, Lee Garrett wrote: Hi Guilhem, could you give quick feedback on this? I'm also happy to prepare a NMU for bookworm if you can't find the time for it. In my view this issue doesn't warrant an (o)s-pu upload on its own, but the fix is trivial so I can do it anyway. Filed #1076015 for s-pu and #1076016 for os-pu. Thanks a bunch!
Bug#1075707: zhcon: ftbfs with GCC-14
Hi, I have 5 patches, 0001, 0002 and 0003 to make the code at https://salsa.debian.org/chinese-team/zhcon.git compiles successfully, with gcc-14 and debian 12. The 0004 and 0005 patches are my test on configure.in, but not finished yet. Since gettext deb package has m4 file related to iconv, I don't know how to use. I suspect the configure.in is not correct, when I use autoupdate && autoconf && automake, the generated ./configure is wrong when detecting iconv. -- System Information: Debian Release: 12.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-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 zhcon depends on: ii libc6 2.38-13 ii libgcc-s1 14-20240330-1 ii libgpm2 1.20.7-11 ii libstdc++6 14-20240330-1 ii libtinfo6 6.5-2 pn zhcon-data zhcon recommends no packages. zhcon suggests no packages. Regards. Rafael Lee On Wed, 03 Jul 2024 12:50:01 + Matthias Klose wrote: > Package: src:zhcon > Version: 1:0.2.6-19 > Severity: important > Tags: sid trixie > User: debian-...@lists.debian.org > Usertags: ftbfs-gcc-14 > > [This bug is targeted to the upcoming trixie release] > > Please keep this issue open in the bug tracker for the package it > was filed for. If a fix in another package is required, please > file a bug for the other package (or clone), and add a block in this > package. Please keep the issue open until the package can be built in > a follow-up test rebuild. > > The package fails to build in a test rebuild on at least amd64 with > gcc-14/g++-14, but succeeds to build with gcc-13/g++-13. The > severity of this report will be raised before the trixie release. > > The full build log can be found at: > http://qa-logs.debian.net/2024/07/01/zhcon_0.2.6-19_unstable_gccexp.log > The last lines of the build log are at the end of this report. > > To build with GCC 14, either set CC=gcc-14 CXX=g++-14 explicitly, > or install the gcc, g++, gfortran, ... packages from experimental. > > apt-get -t=experimental install g++ > > Common build failures are new warnings resulting in build failures with > -Werror turned on, or new/dropped symbols in Debian symbols files. > For other C/C++ related build failures see the porting guide at > http://gcc.gnu.org/gcc-14/porting_to.html > > [...] > winime.cpp:267:32: warning: ‘std::binder2nd<_Operation> std::bind2nd(const _Operation&, const _Tp&) [with _Operation = not_equal_to; _Tp = char*]’ is deprecated: use 'std::bind' instead [-Wdeprecated-declarations] > 267 | bind2nd(not_equal_to < char *>(), > | ~~~^~ > 268 | (char *) 0x)); > | > In file included from /usr/include/c++/14/bits/stl_function.h:1435, > from /usr/include/c++/14/functional:49, > from winime.cpp:26: > /usr/include/c++/14/backward/binders.h:172:5: note: declared here > 172 | bind2nd(const _Operation& __fn, const _Tp& __x) > | ^~~ > winime.cpp:276:17: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] > 276 | p = (char *)(mpIndex2[Index(mInput[0]) * l + Index(c)]); > | ^~~ > g++ -DHAVE_CONFIG_H -I. -I.. -DSYSCONF_DIR=\"/etc\" -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -funsigned-char -O2 -DNDEBUG -Wall -c -o zhcon-nativeinputserver.o `test -f 'nativeinputserver.cpp' || echo './'`nativeinputserver.cpp > g++ -DHAVE_CONFIG_H -I. -I.. -DSYSCONF_DIR=\"/etc\" -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -funsigned-char -O2 -DNDEBUG -Wall -c -o zhcon-inputclient.o `test -f 'inputclient.cpp' || echo './'`inputclient.cpp > g++ -DHAVE_CONFIG_H -I. -I.. -DSYSCONF_DIR=\"/etc\" -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection -funsigned-char -O2 -DNDEBUG -Wall -c -o zhcon-inputmanager.o `test -f 'inputmanager.cpp' || echo './'`inputmanager.cpp > g++ -DHAVE_CONFIG_H -I. -I.. -DSYSCONF_DIR=\"/etc\" -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash
Bug#1075858: mesa-vulkan-drivers > 24.1 should include NVK driver on amd64
Package: mesa-vulkan-drivers Version: 24.1.3-2 Severity: wishlist X-Debbugs-Cc: c...@mg8.org Dear Maintainer, * What led up to the situation? I have a GeForce RTX 3070 and I would love to be able to run games on it without NVIDIA's binary driver * What exactly did you do (or not do) that was effective (or ineffective)? I built mesa from source myself and confirmed that the NVK driver builds and installs successfully * What was the outcome of this action? libEGL fatal: DRI driver not from this Mesa build * What outcome did you expect instead? Was really hoping for working 3D accelerated rendering on my RTX 3070 -- Package-specific info: glxinfo: DISPLAY is not set. /etc/X11/X does not exist. /etc/X11/X is not a symlink. /etc/X11/X is not executable. VGA-compatible devices on PCI bus: -- 09:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA104 [GeForce RTX 3070] [10de:2484] (rev a1) 0c:00.0 VGA compatible controller [0300]: Intel Corporation DG2 [Arc A770] [8086:56a0] (rev 08) /etc/X11/xorg.conf does not exist. Contents of /etc/X11/xorg.conf.d: - total 5 -rw-r--r-- 1 root root 61 Feb 10 2021 00-maxclients.conf -rw-r--r-- 1 root root 112 Dec 2 2022 10-intel.conf /etc/modprobe.d contains no KMS configuration files. Kernel version (/proc/version): --- Linux version 6.9.7-amd64 (debian-ker...@lists.debian.org) (x86_64-linux-gnu-gcc-13 (Debian 13.3.0-1) 13.3.0, GNU ld (GNU Binutils for Debian) 2.42.50.20240625) #1 SMP PREEMPT_DYNAMIC Debian 6.9.7-1 (2024-06-27) Xorg X server log files on system: -- -rw-r--r-- 1 clee clee 103008 Aug 15 2020 /home/clee/.local/share/xorg/Xorg.1.log -rw-r--r-- 1 clee clee 30336 May 7 01:58 /home/clee/.local/share/xorg/Xorg.0.log -rw-r--r-- 1 root root 55846 Jul 6 10:05 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [ 193.160] (--) Log file renamed from "/var/log/Xorg.pid-5024.log" to "/var/log/Xorg.0.log" [ 193.160] X.Org X Server 1.21.1.11 X Protocol Version 11, Revision 0 [ 193.160] Current Operating System: Linux ikora 6.9.7-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.9.7-1 (2024-06-27) x86_64 [ 193.160] Kernel command line: initrd=\0ef4ac2994a74d269d2edfcd92e65113\6.9.7-amd64\initrd.img-6.9.7-amd64 root=ZFS=rpool/buster/debian-1 ro quiet clearcpuid=514 amd_iommu=1 iommu=pt nouveau.config=NvGspRm=1 systemd.machine_id=0ef4ac2994a74d269d2edfcd92e65113 [ 193.160] xorg-server 2:21.1.12-1 (https://www.debian.org/support) [ 193.160] Current version of pixman: 0.42.2 [ 193.160]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 193.160] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 193.160] (==) Log file: "/var/log/Xorg.0.log", Time: Sat Jul 6 10:03:25 2024 [ 193.161] (==) Using config directory: "/etc/X11/xorg.conf.d" [ 193.161] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [ 193.161] (==) No Layout section. Using the first Screen section. [ 193.161] (==) No screen section available. Using defaults. [ 193.161] (**) |-->Screen "Default Screen Section" (0) [ 193.161] (**) | |-->Monitor "" [ 193.161] (==) No device specified for screen "Default Screen Section". Using the first device section listed. [ 193.161] (**) | |-->Device "Intel Arc A770" [ 193.161] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [ 193.161] (**) Option "MaxClients" "2048" [ 193.161] (**) Allowing byte-swapped clients [ 193.161] (==) Automatically adding devices [ 193.161] (==) Automatically enabling devices [ 193.161] (==) Automatically adding GPU devices [ 193.161] (==) Automatically binding GPU devices [ 193.161] (**) Max clients allowed: 2048, resource mask: 0x3 [ 193.161] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist. [ 193.161]Entry deleted from font path. [ 193.161] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, built-ins [ 193.161] (==) ModulePath set to "/usr/lib/xorg/modules" [ 193.161] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 193.161] (II) Loader magic: 0x55b7963eaf00 [ 193.161] (II) Module ABI versions: [ 193.161]X.Org ANSI C Emulation: 0.4 [ 193.161]X.Org Video Driver:
Bug#1042768: Stop shipping scripts that don't work with irssi >= 1.4
Hi Daniel, On 31.10.23 00:37, Daniel Echeverri wrote: Hello!! Thanks for the report!. I am working in a new version of irssi-scripts that remove all deprecated scripts, and include a replacements scripts. Do you mean to create a new file debian/NEWS with [0]? Regards [0]: https://irssi.org/posts/#major-news-in-irssi-14-coming-from-irssi-123 <https://irssi.org/posts/#major-news-in-irssi-14-coming-from-irssi-123> Yes, I'm proposing that. Thanks for fixing it in unstable! I think it's also a good idea to get an update in bookworm, too, so other users upgrading don't stumble upon the same issue. Greetings, Lee
Bug#1069768: The 'no-agent-forwarding' key restriction disables server alive message support
On Wed, 24 Apr 2024 22:00:48 +0200 Lee Garrett wrote: 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? Hi Guilhem, could you give quick feedback on this? I'm also happy to prepare a NMU for bookworm if you can't find the time for it. Greets, Lee
Bug#1054544: community.zabbix plugin misses bookworm support and fails with error dict object' has no attribute 'bookworm'
On Wed, 25 Oct 2023 20:36:48 +0530 Pirate Praveen wrote: package: anisble severity: important version: 7.3.0+dfsg-1 : FAILED! => {"msg": "The task includes an option with an undefined variable. The error was: 'dict object' has no attribute 'bookworm'. 'dict object' has no attribute 'bookworm'\n\nThe error appears to be in '/usr/lib/python3/dist-packages/ansible_collections/community/zabbix/roles/zabbix_server/tasks/Debian.yml': line 86, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: \"Debian | Install gpg key\"\n ^ here\n"} I can see a newer commit adding support https://github.com/ansible-collections/community.zabbix/commit/9856769381625c7994c33a07b7e27a277f8bea86#diff-c1a1a767b71f8dcff0bb354327aba87b4b1885711f107a2b8ecb58fce7992697 It is kind of a chicken and egg problem to include bookworm support in bookworm first release. But I think we can include a patch in a stable update. I managed to fix this by installing with ansible-galaxy (2.1.0) but would be nice to fix the packaged version. I had a look at the patch, and it does not cleanly apply against ansible 7.7.0 (which should soon be in bookworm-proposed-updates). In fact, it seems as though bullseye isn't even supported [0]. Do you believe you could come up with a patch against https://salsa.debian.org/python-team/packages/ansible/-/tree/debian/bookworm?ref_type=heads that would add support for bullseye and bookworm? I unfortunately don't have a zabbix setup I could test against. Regards, Lee [0] https://salsa.debian.org/python-team/packages/ansible/-/blob/debian/bookworm/ansible_collections/community/zabbix/docs/ZABBIX_AGENT_ROLE.md?ref_type=heads#zabbix-versions
Bug#1070193: bookworm-pu: package ansible-core/2.14.16-0+deb12u1
On 16.06.24 00:25, Jonathan Wiltshire wrote: Control: tag -1 confirmed On Wed, May 01, 2024 at 05:05:05PM +0200, Lee Garrett wrote: [ Reason ] This is a bugfix-only update from ansible-core 2.14.3 to 2.14.16. This fixes three CVEs: - Address issue where ANSIBLE_NO_LOG was ignored (CVE-2024-0690) - Address issues where internal templating can cause unsafe variables to lose their unsafe designation (CVE-2023-5764) - Prevent roles from using symlinks to overwrite files outside of the installation directory (CVE-2023-5115) and various other bugfixes as seen here: https://salsa.debian.org/python-team/packages/ansible-core/-/blob/debian/bookworm-proposed/changelogs/CHANGELOG-v2.14.rst 1051 files changed, 8802 insertions(+), 159082 deletions(-) Normally I'd been looking for targetted fixes for the security issues but upstream's descriptive changelog does look quite sensible. You might want to change your version number - if 2.14.16-1 was never in sid you could use that. A +/~ revision to a version which never existed feels odd, as do -0 Debian versions (-1 being the first Debian release of this upstream version, -0 is... the zeroth?). I double-checked if it was me or the tooling that set the version number to 2.14.16-0+deb12u1, and it's even part of official policy: https://www.debian.org/doc/debian-policy/ch-controlfields.html#special-version-conventions -> stable-updates -> bullet point 3 So I'll go ahead and upload as is unless you have any reservations. Greetings, Lee
Bug#1069891: bookworm-pu: package ansible/7.7.0+dfsg-3+deb12u1
On 16.06.24 00:06, Jonathan Wiltshire wrote: Control: tag -1 moreinfo On Fri, Apr 26, 2024 at 03:05:00PM +0200, Lee Garrett wrote: 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). If upstream uses semver then 7.3 -> 7.7 implies new features. Along with a 10MiB diff this is usually a good indicator that it's inappropriate for stable. Ack, fair point. I have reviewed the upstream changelog, and the only added collection between 7.3 and 7.7 is microsoft.ad (out of ~100 collections). The trouble with a package's time spent in sid as an indicator of reliability isn't so much the package itself, but all the differences around it like library versions. We've been bitten by that assumption before now. Indeed, that has happened e.g. with the python3-jinja2 dependency in the past. However, this only happened in major version upgrades of ansible. Newer deps would warrant a bump in major version number. I should also mention that I ran this version on my bookworm machine in that timeframe, and I extensively use ansible for $work. Are there known issues for users which you can target with fixes rather than a wholesale backport? Not exactly. While "ansible" (the package) is a curated collection of smaller projects, it would theoretically be possible to redo that work by hand with stricter selection criteria. In practice however I'd have to review ~100 individual projects, which is IMHO not feasible. I'm also unsure how I'd convey that info to users, as it would neither be ansible 7.3, nor ansible 7.7 in practice, but something else entirely. Since this is a fairly large leaf package (~3.7m LoC), I'd more treat it like other large projects (libreoffice, firefox-esr, etc.) with slightly relaxed s-p-u criteria. On a sidenote: While ansible-lint and python-mitogen depend on ansible, this is just a leftover from the package split in bookworm. They should depend on ansible-core instead. If there was an easy way to leave out the few new features, I'd be happy to do so. I'm mostly worried about the upgrade path from bookworm to trixie. A lot of collections have added deprecation warnings that will notify users to migrate away from a certain collection, or use different parameters for the module. And those are mostly not included in 7.3 yet. One example is the postgresql module: https://salsa.debian.org/python-team/packages/ansible/-/blob/debian/bookworm-proposed/CHANGELOG-v7.rst#id765 There are several others in the changelog under the sections "deprecated features" in each release. As I have several large playbooks for different $work projects, upgrading ansible and only then noticing things have been removed is a major PITA. I'd much rather have the deprecation warnings pop up during a playbook run, allowing me to fix the deprecated code over time, before upgrading. We're doing our users a much better service this way. So in overall I think the bugfixes+deprecation warnings outweigh the slightly higher probability of regressions from potential new features. Otherwise maybe bookworm-backports is a better place for this, so users can choose to take slightly more risk for features, or stick with the released version and put up with known quantity bugs. That's an option, I'd see this however complementary to this s-p-u. The package soon in testing will be three major releases ahead. Thanks,
Bug#1070193: bookworm-pu: package ansible-core/2.14.16-0+deb12u1
On 16.06.24 00:25, Jonathan Wiltshire wrote: Control: tag -1 confirmed On Wed, May 01, 2024 at 05:05:05PM +0200, Lee Garrett wrote: [ Reason ] This is a bugfix-only update from ansible-core 2.14.3 to 2.14.16. This fixes three CVEs: - Address issue where ANSIBLE_NO_LOG was ignored (CVE-2024-0690) - Address issues where internal templating can cause unsafe variables to lose their unsafe designation (CVE-2023-5764) - Prevent roles from using symlinks to overwrite files outside of the installation directory (CVE-2023-5115) and various other bugfixes as seen here: https://salsa.debian.org/python-team/packages/ansible-core/-/blob/debian/bookworm-proposed/changelogs/CHANGELOG-v2.14.rst 1051 files changed, 8802 insertions(+), 159082 deletions(-) Normally I'd been looking for targetted fixes for the security issues but upstream's descriptive changelog does look quite sensible. You might want to change your version number - if 2.14.16-1 was never in sid you could use that. A +/~ revision to a version which never existed feels odd, as do -0 Debian versions (-1 being the first Debian release of this upstream version, -0 is... the zeroth?). Thanks, Will do, and thanks for the ack!
Bug#982968: ansible-pull output on terminal is buffered (not live)
Hi Ludovic, if this still affects current Debian versions please report it with upstream: https://github.com/ansible/ansible/issues If they consider it a good change I'm happy to backport it to the release currently in bookworm. Greets, Lee On Wed, 17 Feb 2021 14:53:40 +0100 Ludovic Pouzenc wrote: Source: ansible Version: 2.9.6+dfsg-1~bpo10+1 Severity: normal Dear Maintainer, Using ansible-pull command from a virtual machine console works but the progression of the work done is not displayed live. It is buffered (4kio ?) and bunch of text appears at once, "too late". It shows up also via ssh but with a less big buffer (less annoying, but happens too). For me it affects current buster and current buster-backports. I didn't see any clue upstream about solving this issue. I just report it here for now. I expect that the output should be live as when using ansible-playbook. Code appears to handle that. strace shows up many unbuffered read from forked ansible commands, but only a few big writes to terminal. Please find attached a patch that works for me on 2.9 and 2.7. I suspect that is an upstream that may be distro-agnotic bug but I didn't tried it elsewhere right now. diff --git a/ansible/utils/cmd_functions.py b/ansible/utils/cmd_functions.py index 7a0fb23..ef6cb14 100644 --- a/ansible/utils/cmd_functions.py +++ b/ansible/utils/cmd_functions.py @@ -57,6 +57,7 @@ def run_cmd(cmd, live=False, readsize=10): sys.stdout.buffer.write(dat) else: sys.stdout.write(dat) +sys.stdout.flush() stdout += dat if dat == b'': rpipes.remove(p.stdout) @@ -69,6 +70,7 @@ def run_cmd(cmd, live=False, readsize=10): sys.stdout.buffer.write(dat) else: sys.stdout.write(dat) +sys.stdout.flush() if dat == b'': rpipes.remove(p.stderr) # only break out if we've emptied the pipes, or there is nothing to I may have tested onnly 1 code path of the two that are patched above. I am unclear about python 2/3 mixing and ansible on Debian 10. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-0.bpo.5-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_OOT_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1069283: New version of arista.eos collection
Hi Simon, I've just uploaded ansible 10.0.0-1 which contains arista.eos 9.0.0. I'm closing this bug as such. Greets, Lee On Fri, 19 Apr 2024 11:51:15 +0200 =?UTF-8?Q?Simon_Sp=C3=B6hel?= wrote: Package: ansible Version: 9.4.0+dfsg-1 Dear Maintainers Thank you for updating and maintaining Ansible. Ansible in Debian contains arista.eos collection version 6.2.2. Current upstream version is 9.0.0. An update would be much appreciated. Regards Simon
Bug#1061591: rhsrvany: tests can fail on ci.debian.net due to wine32 installation
On Sat, 27 Jan 2024 00:17:50 + Michael Gilbert wrote: package: src:rhsrvany version: 1.1-2 severity: serious tag: patch runsrvany64 and runpnpwait64 autopkgtests can fail on amd64 on ci.debian.net because of foreign arch wine32 installability issues [0]. This currently prevents wine from migrating to testing [1]. The attached patch solves the problem by removing wine32 install from the scripts. wine32 isn't needed since the tests run correctly on amd64 when wine and wine64 are installed, which is the case for ci.debian.net. Best wishes, Mike [0] https://ci.debian.net/packages/r/rhsrvany/testing/amd64/42392786/ [1] https://qa.debian.org/excuses.php?package=wine Hi, I've uploaded 1.1-3 which fixes the issue by removing the tests for amd64. However, I believe the original purpose was to ensure that pushing the git branch would also run the autopkgtests (which only run on amd64 containers). Unfortunately the logs are not available anymore. Any idea what the original problem was? It would be nice to have autopkgtests run on amd64 when testing things out before uploading a package. Regards, Lee
Bug#1072013: uscan unconditionally downloads signature file
Package: devscripts Version: 2.23.4+deb12u1 Severity: important File: /usr/bin/uscan X-Debbugs-Cc: deb...@rocketjump.eu Hi, when the tarball and signature file already exists, uscan will skip downloading the tarball, but will unconditionally re-download the signature file. In my specific case upstream has opted to build a bot detection on their web page, which then instead serves a HTML file with a captcha. This causes the previous signature file (that verifies) to be replaced with a HTML file that of course does not verify anymore. Together with a related bug (#1072008) in gbp it makes it really hard to actually import a tarball with signature in such a scenario. As developers might be tempted to skip signature checks (which would be one workaround), I'm setting the severity to important. I believe that the right thing to do is to skip downloading the signature file, as it's consistent with already skipping downloading the tarball. Greets, Lee Full transcript below: ---8<--8<--8<--8<--8<--8<--8<--8<--- $ cat debian/watch version=4 opts="pgpmode=mangle,pgpsigurlmangle=s%$%.sig%,filenamemangle=s%[^?]+\?file=(.+)%$1%" \ https://dianne.skoll.ca/projects/rp-pppoe/ \ download.php\?file=rp-pppoe-(4.0).tar.gz \ debian uupdate $ gpg --verify ../rp-pppoe-4.0.tar.gz.sig ../rp-pppoe-4.0.tar.gz gpg: Signature made Mi 26 Apr 2023 21:02:53 CEST gpg:using RSA key 738E4D954052902C147D07B2685A5A5E511D30E2 gpg:issuer "dia...@skoll.ca" gpg: Good signature from "Dianne Skoll " [unknown] gpg: aka "Dianne Skoll " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 738E 4D95 4052 902C 147D 07B2 685A 5A5E 511D 30E2 $ head debian/changelog rp-pppoe (3.15-2) unstable; urgency=medium * Update upstream contact email address * Bump Standards-Version (no changes needed) * Update d/copyright * Fix lintian override * Update hardening flag according to wiki * Add hardening build flags to Makefile * Remove superfluous lintian override $ uscan -vvv uscan info: uscan (version 2.23.4+deb12u1) See uscan(1) for help uscan info: Scan watch files in . uscan debug: Found ./debian uscan info: Check debian/watch and debian/changelog in . uscan info: package="rp-pppoe" version="3.15-2" (as seen in debian/changelog) uscan info: package="rp-pppoe" version="3.15" (no epoch/revision) uscan info: ./debian/changelog sets package="rp-pppoe" version="3.15" uscan info: Found upstream signing keyring: debian/upstream/signing-key.asc uscan info: Process watch file at: debian/watch package = rp-pppoe version = 3.15 pkg_dir = . uscan debug: parse line opts="pgpmode=mangle,pgpsigurlmangle=s%$%.sig%,filenamemangle=s%[^?]+\?file=(.+)%$1%" https://dianne.skoll.ca/projects/rp-pppoe/ download.php\?file=rp-pppoe-(4.0).tar.gz debian uupdate uscan info: opts: pgpmode=mangle,pgpsigurlmangle=s%$%.sig%,filenamemangle=s%[^?]+\?file=(.+)%$1% uscan info: line: https://dianne.skoll.ca/projects/rp-pppoe/ download.php\?file=rp-pppoe-(4.0).tar.gz debian uupdate uscan info: Parsing pgpmode=mangle uscan info: Parsing pgpsigurlmangle=s%$%.sig% uscan info: Parsing filenamemangle=s%[^?]+\?file=(.+)%$1% uscan info: line: https://dianne.skoll.ca/projects/rp-pppoe/ download.php\?file=rp-pppoe-(4.0).tar.gz debian uupdate uscan debug: $self->{'pgpmode'}=mangle, $self->{'pgpsigurlmangle'}=s%$%.sig% uscan info: Last orig.tar.* tarball version (from debian/changelog): 3.15 uscan info: Last orig.tar.* tarball version (dversionmangled): 3.15 uscan debug: watch file has: $base= https://dianne.skoll.ca/projects/rp-pppoe/ $filepattern = download.php\?file=rp-pppoe-(4.0).tar.gz $lastversion = 3.15 $action = uupdate mode = http pgpmode = mangle versionmode = newer $site= https://dianne.skoll.ca $basedir = /projects/rp-pppoe/ uscan debug: line: search() uscan info: Requesting URL: https://dianne.skoll.ca/projects/rp-pppoe/ uscan debug: received content: Dianne Skoll's Web Site - RP-PPPoE - Software Projects Home Contact Software Comedy Writings Store RP-PPPoE PPPoE (Point-to-Point Protocol over Ethernet) is a protocol used by many DSL Internet Service Providers. RP-PPPoE is a free PPPoE client, relay and server for Linux. Commercial PPPoE Server Fine Point Networks sells a commercial PPPoE server based on rp-pppoe; their product is called ServPoET BMS. Download RP-PPPoE You can download RP-PPPoE here: rp-pppoe-4.0.t
Bug#1072008: gbp import-orig does not document which signature extensions it expects
Package: git-buildpackage Version: 0.9.30 Severity: important X-Debbugs-Cc: deb...@rocketjump.eu Hi, I was trying to import a newer upstream version of rp-pppoe, here's the shell session transcript: ---8<--8<--8<--8<--8<--8<--8<--8<--8<--- $ ls -l ../rp-pppoe-4.0.tar.gz* -rw-r--r-- 1 randall randall 139539 Mai 21 14:58 ../rp-pppoe-4.0.tar.gz -rw-r--r-- 1 randall randall583 Mai 20 10:32 ../rp-pppoe-4.0.tar.gz.sig $ gbp import-orig --upstream-signatures=on --upstream-tag=deleteme --verbose ../rp-pppoe-4.0.tar.gz gbp:debug: ['git', 'rev-parse', '--show-cdup'] gbp:debug: ['git', 'rev-parse', '--is-bare-repository'] gbp:debug: ['git', 'rev-parse', '--git-dir'] gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/'] gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream/latest'] gbp:debug: ['git', 'status', '--porcelain'] What is the upstream version? [4.0] gbp:debug: ['git', 'tag', '-l', 'deleteme'] gbp:debug: tar ['-C', '../tmpcjic_cw6', '-a', '-xf', '../rp-pppoe-4.0.tar.gz'] [] gbp:debug: Unpacked '../rp-pppoe-4.0.tar.gz' to '../tmpcjic_cw6/rp-pppoe-4.0' gbp:info: gbp:info: Importing '../rp-pppoe-4.0.tar.gz' to branch 'upstream/latest'... gbp:info: Source package is rp-pppoe gbp:info: Upstream version is 4.0 gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream/latest'] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream/latest'] gbp:debug: ['git', 'add', '-f', '.'] gbp:debug: ['git', 'write-tree'] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream/latest'] gbp:debug: ['git', 'commit-tree', '3017f5070cb7a09b0d79d49df8860a42e460f66e', '-p', '31d68177a90b0e56367dbd8901711fdc551ec2ad'] gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version 4.0', 'refs/heads/upstream/latest', 'b7b1dd7a852a6fe0c544d38e2baf8cff7b65cd4f', '31d68177a90b0e56367dbd8901711fdc551ec2ad'] gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar'] gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'pristine-tar'] gbp:error: ../rp-pppoe-4.0.tar.gz does not have a signature file gbp:error: Error detected, Will roll back changes. gbp:info: Rolling back branch upstream/latest by resetting it to 31d68177a90b0e56367dbd8901711fdc551ec2ad gbp:debug: ['git', 'update-ref', '-m', 'gbp import-orig: failure rollback of upstream/latest', 'refs/heads/upstream/latest', '31d68177a90b0e56367dbd8901711fdc551ec2ad'] gbp:info: Rolling back branch pristine-tar by resetting it to 3b63b1f0270f976f8b6f6d5eb27d4d7054bf50e1 gbp:debug: ['git', 'update-ref', '-m', 'gbp import-orig: failure rollback of pristine-tar', 'refs/heads/pristine-tar', '3b63b1f0270f976f8b6f6d5eb27d4d7054bf50e1'] gbp:error: Rolled back changes after import error. gbp:debug: rm ['-rf', '../tmpcjic_cw6'] [] $ gpg --verify ../rp-pppoe-4.0.tar.gz.sig ../rp-pppoe-4.0.tar.gz gpg: Signature made Mi 26 Apr 2023 21:02:53 CEST gpg:using RSA key 738E4D954052902C147D07B2685A5A5E511D30E2 gpg:issuer "dia...@skoll.ca" gpg: Good signature from "Dianne Skoll " [unknown] gpg: aka "Dianne Skoll " [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 738E 4D95 4052 902C 147D 07B2 685A 5A5E 511D 30E2 ---8<--8<--8<--8<--8<--8<--8<--8<--8<--- As you can see, the signature is valid. After digging around I found out that renaming the .sig file to .asc actually makes the above import-orig command run through. It would be great if `gbp import-orig` would check a set of extensions similar to uscan (?:asc|pgp|gpg|sig|sign) and also document those in the man page. Set to important as I believe importing signed tarballs is a crucial step in Debian packaging and maintainers should not be tempted to import it unsigned to work around bugs. 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 git-buildpackage depends on: ii devscripts 2.23.4+deb12u1 ii git1:2.39.2-1.1 ii man-db 2.11.2-2 ii python33.11.2-1+b1 ii python3-dateutil 2.8.2-2 ii python3-pkg-resources 66.1.1-1 ii python3-yaml 6.0-3+b2 ii sensible-utils 0.0.17+nmu1 Versions of packages git-buildpackage recommends: ii pristine-tar 1.50 ii py
Bug#1072006: reference gbp-import-ref(1) in gbp(1) man page
Package: git-buildpackage Version: 0.9.30 Severity: minor X-Debbugs-Cc: deb...@rocketjump.eu Hi, looking at the man page of gbp, there is no reference to import-ref, neither in the "GBP COMMANDS" section, nor in the "SEE ALSO" section. Would be great to add that there for bookworm and later. The man page for import-ref is actually shipped in the package, just not referenced anywhere. 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 git-buildpackage depends on: ii devscripts 2.23.4+deb12u1 ii git1:2.39.2-1.1 ii man-db 2.11.2-2 ii python33.11.2-1+b1 ii python3-dateutil 2.8.2-2 ii python3-pkg-resources 66.1.1-1 ii python3-yaml 6.0-3+b2 ii sensible-utils 0.0.17+nmu1 Versions of packages git-buildpackage recommends: ii pristine-tar 1.50 ii python3-requests 2.28.1+dfsg-1 ii sbuild0.85.0 Versions of packages git-buildpackage suggests: ii python3-notify2 0.3-5 ii sudo 1.9.13p3-1+deb12u1 ii unzip6.0-28 -- no debconf information
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.