Bug#1077005: CFLAGS+=foo etc stopped working
Package: dpkg-dev
Version: 1.22.8
Severity: important
Hi!
It seems like constructs like
include /usr/share/dpkg/buildflags.mk
CFLAGS += -DFOO
LDFLAGS += -lbar
etc somehow stopped working on buildds since dpkg 1.22.8,
although I can't reproduce it locally no matter how I try.
An example is samba package which uses this construct in
a few places, and later uses the variables like this:
CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" ./configure ...
No matter what I append to these variables, the resulting
value does not change.
I can only guess this is due to dpkg_lazy_eval which resets
values of each variable (it has `eval VAR=VAL` inside), but
the thing is that I can't reproduce it locally. Something
might be different on a buildd.
Yes, I can switch to using DEB_LDFLAGS_MAINT_APPEND etc,
but it requires quite some rearrangements/reordering of
d/rules, and it doesn't tell me why current way, which
used to work before, broke now.
This issue potentially can affect multiple packages in an
unexpected way, because CFLAGS+=foo definitely used to
work before.
And no, 1.22.9 upload does not fix the issue.
Bug#1076863: dpkg-deb: Weird errors from dpkg-deb while building some packages
On Wed, 24 Jul 2024 16:35:43 +0200 Guillem Jover wrote: So there's something wrong with the variables evaluation, - $(call dpkg_lazy_eval,DEB_VERSION_UPSTREAM,$$(dpkg_parsechangelog_run)) - $(call dpkg_lazy_eval,DEB_UPSTREAM_REVISION,$$(dpkg_parsechangelog_run)) Here was the wrong: variable is named DEB_VERSION_UPSTREAM_REVISION, not DEB_UPSTREAM_REVISION. I found this yesterday the hard way. When referencing any other version-related variable first, this issue goes away. But it doesn't really matter anymore, once this part is removed. FWIW. /mjt
Bug#1076974: [Pkg-samba-maint] Bug#1076974: samba_4.20.2+dfsg-8_riscv64-buildd.changes REJECTED
24.07.2024 23:26, Michael Tokarev wrote:
LDB_DEB_VERSION = 2:${LDB_VERSION}+samba${DEB_VERSION_UPSTREAM_REVISION}
This is #1076863 in dpkg-dev.
/mjt
Bug#1076974: [Pkg-samba-maint] Bug#1076974: samba_4.20.2+dfsg-8_riscv64-buildd.changes REJECTED
24.07.2024 23:06, Aurelien Jarno wrote:
Source: samba
Version: 4.20.2+dfsg-8
Severity: serious
On 2024-07-24 18:50, Debian FTP Masters wrote:
Version check failed:
Your upload included the binary package ldb-tools, version 2:2.9.1+samba, for
riscv64,
however testing already has version 2:2.9.1+samba4.20.2+dfsg-7.
Uploads to unstable must have a higher version than present in testing.
I know the roots of this issue, but I've no idea how this happened
or how to proceed.
ldb-tools (and other ldb-related packages, libldb2, etc) has their own
version number, in form
LDB_DEB_VERSION = 2:${LDB_VERSION}+samba${DEB_VERSION_UPSTREAM_REVISION}
earlier in d/rules I include /usr/share/dpkg/pkg-info.mk
But apparently, ${DEB_VERSION_UPSTREAM_REVISION} is empty.
Ditto for ${DEB_HOST_ARCH} and a few other variables which are used in
d/rules.
I've no idea what is going on.
/mjt
Bug#1076495: [Pkg-samba-maint] Bug#1076495: samba-common-bin: net usershare guest_ok paramter is parsed as a comment
Control: severity -1 minor 17.07.2024 11:04, debian-report...@mx.brindabella.org wrote: Package: samba-common-bin Version: 2:4.17.12+dfsg-0+deb12u1 Severity: normal Dear Maintainer, On a fresh install of Debian, user enters the following command: user@debian:~# net usershare add testing /home/user/myusershare/ guest_ok=y The resulting usershare generated by Samba is as follows: root@debian:~# cat /var/lib/samba/usershares/testing #VERSION 2 path=/home/user/myusershare/ comment=guest_ok=y usershare_acl=S-1-1-0:R guest_ok=n sharename=testing Note that the 'guest_ok=y' parameter has been parsed as a comment not as specifying guest access. This appears inconsistent with the man page for net(8), which suggests [comment] and [acl ] are *optional* parameters. The usershare is created with what are presumably default values for ACL and guest_ok. USERSHARE ADD sharename path [comment] [acl] [guest_ok=[y|n]] The only way to ensure the guest_ok=y parameter is correctly added to the usershare definition is to include both a comment and an ACL - eg: net usershare add testing /home/user/myusershare mycomment S-1-1-0:f guest_ok=y This is contrary to the man page which suggests [comment] and [acl] are optional. This requires user to know what to specify for ACL, which would The net(8) manpage says: The usershare commands are: net usershare add sharename path [comment [acl] [guest_ok=[y|n]]] - to add or change a user defined share. net usershare delete sharename - to delete a user defined share. net usershare info [--long] [wildcard sharename] - to print info about a user defined share. net usershare list [--long] [wildcard sharename] - to list user defined shares. USERSHARE ADD sharename path [comment] [acl] [guest_ok=[y|n]] Add or replace a new user defined share, with name "sharename". Note the list of all usershare commands just 4 lines above the line you quoted. Either way, please address this upstream. Thanks, /mjt
Bug#1076495: [Pkg-samba-maint] Bug#1076495: samba-common-bin: net usershare guest_ok paramter is parsed as a comment
17.07.2024 11:47, Michael Tokarev wrote: USERSHARE ADD sharename path [comment] [acl] [guest_ok=[y|n]] Actually there's just a single extra "]" in there, right after the "comment", which shouldn't be there. Note two "]"s at the end. /mjt
Bug#1076008: qemu-system-ppc: Missing NIC ?
09.07.2024 15:29, Christian Marillat пишет: On 09 juil. 2024 15:25, Michael Tokarev wrote: 09.07.2024 15:23, Christian Marillat wrote: On 09 juil. 2024 13:18, Michael Tokarev wrote: [...] I don't know what "NIC support is missing" means. Qemu can't be built without support for networking. The -nic option is obsolete for a long time, that's true, but it works still. Missing network card support. You gave no additional information here. I already read the same in your first email, and I can't understand it. I also wrote back that the above command parameters works just fine on my system with qemu 9.0.0+ds-1. There's no need for this ping-pong, - if you want the issue to be fixed, you have to provide the information requested, instead of repeating the same information as before. I expect to see the same output with 1:8.2.5+ds-2 when qemu 9 return nothing. I'll keep this bug report hanging there for now, requesting for more info about the original issue. Unless such info will be available, I'll just close it so it doesn't dusturb my work, - because in the way it now is, it's useless. Last time I'll report a bug against qemu. It's a shame. Indeed it is a shame that you can't provide info requested 3 times. Thank you for not filing more useless bug reports in the future. /mjt ristian -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1076008: qemu-system-ppc: Missing NIC ?
09.07.2024 15:23, Christian Marillat wrote: On 09 juil. 2024 13:18, Michael Tokarev wrote: [...] I don't know what "NIC support is missing" means. Qemu can't be built without support for networking. The -nic option is obsolete for a long time, that's true, but it works still. Missing network card support. You gave no additional information here. I already read the same in your first email, and I can't understand it. I also wrote back that the above command parameters works just fine on my system with qemu 9.0.0+ds-1. There's no need for this ping-pong, - if you want the issue to be fixed, you have to provide the information requested, instead of repeating the same information as before. I expect to see the same output with 1:8.2.5+ds-2 when qemu 9 return nothing. I'll keep this bug report hanging there for now, requesting for more info about the original issue. Unless such info will be available, I'll just close it so it doesn't dusturb my work, - because in the way it now is, it's useless. Thanks, /mjt
Bug#1076008: qemu-system-ppc: Missing NIC ?
09.07.2024 13:18, Michael Tokarev wrote: ..>> -net nic,model=help should display a list of available network devices. If you want this to happen, I suggest you to open bug report in the upstream qemu issue tracker. I definitely wont add debian-specific code to display help for an obsolete option in qemu. All these command line options come from the manpage. No, you're wrong: -net nic,model=help is not documented in the manpage. I stand corrected, it's me who's wrong here. This exact command is documented in the manpage: Use -net nic,model=help for a list of available devices for your target. Obviously the manpage needs correction here. It's broken for a long time. /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1076008: qemu-system-ppc: Missing NIC ?
09.07.2024 13:11, Christian Marillat wrote: On 09 juil. 2024 12:53, Michael Tokarev wrote: Control: tag -1 + moreinfo unreproducible 09.07.2024 12:09, Christian Marillat wrote: Package: qemu-system-ppc Version: 1:9.0.1+ds-1 Severity: serious Dear Maintainer, My working configuration with 1:8.2.5+ds-2 was: , | -net nic,macaddr=52:54:00:12:34:67,model=virtio -net tap ` Now with 1:9.0.1+ds-1 qemu-system-ppc64 doesn't start. Apparently NIC support is missing: I don't know what "NIC support is missing" means. Qemu can't be built without support for networking. The -nic option is obsolete for a long time, that's true, but it works still. Missing network card support. You gave no additional information here. I already read the same in your first email, and I can't understand it. I also wrote back that the above command parameters works just fine on my system with qemu 9.0.0+ds-1. There's no need for this ping-pong, - if you want the issue to be fixed, you have to provide the information requested, instead of repeating the same information as before. If the -nic option (and -net option) are obsolete why these options are still documented in the manpage ? Because -net is still supported. This is unrelated to your original problem, isn't it? .. What do you expect here? Is the problem you're reporting boils down to missing support for -net nic,model=help (for obsolete option -nic)? If yes, perhaps the bug title is wrong? -net nic,model=help should display a list of available network devices. If you want this to happen, I suggest you to open bug report in the upstream qemu issue tracker. I definitely wont add debian-specific code to display help for an obsolete option in qemu. All these command line options come from the manpage. No, you're wrong: -net nic,model=help is not documented in the manpage. /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1076008: qemu-system-ppc: Missing NIC ?
Control: tag -1 + moreinfo unreproducible 09.07.2024 12:09, Christian Marillat wrote: Package: qemu-system-ppc Version: 1:9.0.1+ds-1 Severity: serious Dear Maintainer, My working configuration with 1:8.2.5+ds-2 was: , | -net nic,macaddr=52:54:00:12:34:67,model=virtio -net tap ` Now with 1:9.0.1+ds-1 qemu-system-ppc64 doesn't start. Apparently NIC support is missing: I don't know what "NIC support is missing" means. Qemu can't be built without support for networking. The -nic option is obsolete for a long time, that's true, but it works still. The above command (with additional parameters specifying image file and other stuff) works for me just fine. , | $ sudo qemu-system-ppc64 -net nic,model=help Do not run qemu as root. | qemu-system-ppc64: warning: hub port hub0port0 has no peer | qemu-system-ppc64: warning: netdev hub0port0 has no peer | qemu-system-ppc64: warning: requested NIC (#net062, model help) was not created (not supported by this machine?) ` What do you expect here? Is the problem you're reporting boils down to missing support for -net nic,model=help (for obsolete option -nic)? If yes, perhaps the bug title is wrong? I can't get head or tail of this report. Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1076005: libdrm build-dep should be >=2.4.116
Source: xwayland Version: 24.1.0-1 Severity: normal Tags: patch xwayland Build-Depends on libdrm-dev (>= 2.4.89), but actual build-time check verifies libdrm is at least of version 2.4.116 and fails if it is not: env[PKG_CONFIG_PATH]: Called `/usr/bin/pkg-config --libs libdrm` -> 0 stdout: -ldrm --- Dependency libdrm found: NO found 2.4.114 but need: '>= 2.4.116' Dependency lookup for libdrm with method 'pkgconfig' failed: Invalid version, need 'libdrm' ['>= 2.4.116'] found '2.4.114'. (this was an attempt to build xwayland on bookworm). Please specify actual minimum required version of libdrm-dev. (Using Tags: patch without actual patch, since the change is trivial.) Thanks, /mjt
Bug#714275: qemu-system-ppc manpage and many others are copies of qemu-system-x86_64 page
Control: tag -1 + moreinfo 08.07.2024 00:53, Gordon Steemson wrote: Package: qemu-system-ppc Version: 1:8.2.1+ds-1~bpo12+1 Followup-For: Bug #714275 X-Debbugs-Cc: gstee...@gmail.com Dear Maintainer, Numerous manpages for parts of qemu (including anything to do with powerpc) are actually separate copies of the qemu-system-x86_64 manpage. And? Do you think it is a bug? If yes, why do you think it is a bug? What's your proposal here? Thanks, /mjt
Bug#1075824: qemu: CVE-2024-4467
Control: found -1 06.07.2024 00:35, Salvatore Bonaccorso wrote: .. This is fixed by qemu uploaded earlier today. Patches are already prepared for bookworm (for qemu 7.2.x series) and already verified upstream and passed the tests. Yes thanks, had only the 1:8.2.5+ds-2 initially to check. Sure, you didn't know I uploaded a fixed version already. Updated the security-tracker accordingly now. Now, I've some doubts about what to do here with other branches. For bookworm we've two choices: to upload a quick fix to -security with just the two changes from upstream, or to wait for upstream 7.2.13 version which will be released in 10 days, and push that one with this and other fixes. I prefer the second variant, but you definitely have your word here. And since this bug is old (can't find when the json thing first appeared, but it looks like it predates buster). I'll update the bug report at least. Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#700055: Please support 1366x768 resolution
04.07.2024 11:43, Anton Shepelev wrote: The problem persists eleven years later. Please, add support to this resolution. Patches welcome. Adding another "me too" isn't exactly helpful. /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1074514: README.Debian still mentions /sys/devices/system/cpu/microcode/reload (not enabled since kernel 5.19)
Package: amd64-microcode Version: 3.20240116.2+nmu1 Severity: minor It would be nice to remove this part from the README.Debian, since it is misleading. Thanks, /mjt
Bug#1074378: bind9: Bind9 SEGFAULT when enable DLZ with samba
On 6/27/24 16:33, Lucas Bocchi wrote: Package: bind9 Version: 1:9.19.24-185-g392e7199df2-1 Severity: important Dear Maintainer, BIND9 with default configs, only enabling BIND9_DLZ, appears SEGFAULT on new bind9 version to debian testing Jun 27 10:26:01 gw-fw-local named[146587]: Loading 'AD DNS Zone' using driver dlopen Jun 27 10:26:01 gw-fw-local kernel: named[146587]: segfault at 8 ip 7ff967100340 sp 7ffcf4188950 error 4 in libc.so.6[7ff96708f000+157000] likely on CPU 0 (core 0, socket 0) Jun 27 10:26:01 gw-fw-local kernel: Code: 5c 41 5d 41 5e e9 f0 fa ff ff 48 8d 3d a9 71 10 00 e8 14 e1 ff ff 0f 1f 40 00 48 8d 3d 31 71 10 00 e8 04 e1 ff ff 0f 1f 40 00 <48> 8b 50 08 48 83 e2 f8 48 01 d0 49 39 c5 0f 82 38 ff ff ff 48 8d Can you try to get a stack backtrace from named? We already had a similar bug before, https://bugzilla.samba.org/show_bug.cgi?id=14030 Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1074245: pam_pkcs11 manpage has no useful information and referes to non-existing pam_pkcs11.conf
Package: libpam-pkcs11 Version: 0.6.12-1 Severity: normal the pam_pkcs11 manpage contains no information whatsoever about how to use the module. Also, it refers to pam_pkcs11.conf manpage which is not shipped with the package. The result of all this is that the module is basically unusable. It isn't even clear where pam_pkcs11.conf file should be. Okay, examples/READMEs shipped in /usr/share/doc/libpam-pkcs11/ helps a bit, also strings and strace tools, but it's not where one looks for the info usually. Thanks, /mjt
Bug#1074223: trixie: please document samba package changes
Package: release-notes Severity: normal Tags: patch X-Debbugs-Cc: pkg-samba-de...@lists.alioth.debian.org There are a few changes in samba packaging for trixie which are worth mentioning in the release notes. The changes are mentioned in the NEWS files in the package. samba (2:4.20.1+dfsg-2) unstable; urgency=medium Active Directory Domain Controller (AD-DC) functionality has been split out of main samba (the file server) package into its own separate package named samba-ad-dc. This includes the samba binary, the startup files and a few support executables. Please additionally install samba-ad-dc package if you need AD-DC functionality on your system. -- Michael Tokarev Sun, 26 May 2024 13:44:07 +0300 samba-vfs-modules (2:4.20.2+dfsg-3) unstable; urgency=medium samba-vfs-modules package has been dropped in this release. Instead, all common vfs modules are now part of regular samba package, so are always installed (so there is not need to install samba-vfs-modules for, say, wide links = yes to work, ad-dc always works too and so on). At the same time, glusterfs and ceph vfs modules are now shipped in their own separate packages, samba-vfs-glusterfs and samba-vfs-ceph (samba-vfs-glusterfs in universe in ubuntu). If you need ceph or glusterfs functionality, please install samba-vfs-ceph and/or samba-vfs-glusterfs package(s) separately. -- Michael Tokarev Mon, 24 Jun 2024 12:48:23 +0300 While samba-vfs-modules removal is not actually very important to have in the release notes, but samba-ad-dc becoming required for the AD-DC functionality is definitely worth mentioning. Plus the split of the two vfs modules packages. It would be nice if this is mentioned for trixie. Thanks, /mjt
Bug#1061212: Please upgrade to llvm-toolchain-17
On Sat, 16 Mar 2024 15:05:34 +0100 Bastian Germann wrote: v3.1.44 should be the best upstream version for this. why do you think this is the best version? Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1074003: please switch from llvm-16 to a more recent one
Source: ghc Version: 9.4.7-5 Severity: important Please remove references to llvm-15 from ghc, switching to a more recent llvm version. Currently ghc 9.6.5 is in experimental, which already uses llvm-17. llvm-15 should go, see https://release.debian.org/transitions/html/llvm-15-rm.html - this is why this bug report is of severity: important. It is holding more recent llvm migration to testing, see #1068961 Thanks, /mjt
Bug#1073969: [Pkg-samba-maint] Bug#1073969: samba: Referenced but unset environment variable evaluates to an empty string
20.06.2024 21:45, Timo van Roermund wrote: Package: samba Version: 2:4.20.2+dfsg-2 Severity: minor Dear Maintainer, The smbd and nmbd services throw the following warnings when they get started: (smbd)[75315]: smbd.service: Referenced but unset environment variable evaluates to an empty string: SMBDOPTIONS (nmbd)[75101]: nmbd.service: Referenced but unset environment variable evaluates to an empty string: NMBDOPTIONS It's interesting I never noticed these warnings, while I (re)started the services countless number of times. This seems to be a known issue; see: https://lists.samba.org/archive/samba-technical/2023-December/138624.html Would it be possible to silence these warnings using the solution mentioned in the link above? I think the best approach here is to ship /etc/default/samba file in debian with empty settings for all these variables. I'll do it in the next upload. Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1073829: please mark the package as Multi-Arch: foreign
Package: libparse-yapp-perl
Version: 1.21-3
Severity: normal
Tags: patch
Currently there's no way to satisfy dependency on libparse-yapp-perl for a
non-native-arch
package, despite libparse-yapp-perl itself is pure perl, arch:all and does not
have any
architecture-specific dependencies. This is because it is not marked with
Multi-Arch: foreign.
The attached one-line patch makes it possible to depend on libparse-yapp-perl
for non-native
packages, and, in particular, to build-depend on it when cross-compiling.
Thanks,
/mjt
--- debian/control.orig 2024-06-19 14:15:15.638951102 +0300
+++ debian/control 2024-06-19 12:50:49.072606813 +0300
@@ -14,6 +14,7 @@
Package: libparse-yapp-perl
Architecture: all
+Multi-Arch: foreign
Depends: ${misc:Depends},
${perl:Depends}
Description: Perl module for creating fully reentrant LALR parser OO Perl
modules
Bug#1073177: apparmot profile: Failed to spawn child process “/usr/lib/thunderbird/glxtest” (Permission denied)
14.06.2024 08:19, Carsten Schoenert wrote: Hello Michael, Hi! Am 14.06.24 um 06:38 schrieb Michael Tokarev: This is because thunderbird apparmor profile does not let it to execute /usr/lib/thunderbird/glxtest. Adding that one to /etc/apparmor.d/usr.bin.thunderbird fixes the issue. would you mind to provide the data / the line you added there? Ah, sure. I'm not an expert in apparmor, I just cloned a nearby line: /usr/lib/thunderbird/glxtest ixr, That's why I haven't included it initially, - I've no idea if this is correct. I've no idea why thunderbird wants to run glxtest, but this is a different question entirely. Well, this is now somehow needed as Thunderbird is checking by this which hardware is available for using potentially video acceleration in media content that can be included in emails. I observed no visible difference before and after adding permission to execute glxtest. But since glxtest is shipped in the package, I guess it might at least be a good idea to let thunderbird to run that binary :) Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1073177: apparmot profile: Failed to spawn child process “/usr/lib/thunderbird/glxtest” (Permission denied)
Package: thunderbird Version: 1:115.11.0-1~deb12u1 Severity: normal When starting thunderbird, it displays this error messages: [GFX1-]: FireTestProcess failed: Failed to spawn child process “/usr/lib/thunderbird/glxtest” (Permission denied) [GFX1-]: No GPUs detected via PCI This is because thunderbird apparmor profile does not let it to execute /usr/lib/thunderbird/glxtest. Adding that one to /etc/apparmor.d/usr.bin.thunderbird fixes the issue. I've no idea why thunderbird wants to run glxtest, but this is a different question entirely. /mjt -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 'stable'), (500, 'proposed-updates'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 'oldstable'), (99, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.1.0-21-amd64 (SMP w/24 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (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 thunderbird depends on: ii debianutils 5.7-0.5~deb12u1 ii fontconfig 2.14.1-4 ii libasound2 1.2.8-1+b1 ii libatk1.0-0 2.46.0-5 ii libc62.36-9+deb12u7 ii libcairo-gobject21.16.0-7 ii libcairo21.16.0-7 ii libdbus-1-3 1.14.10-1~deb12u1 ii libdbus-glib-1-2 0.112-3 ii libevent-2.1-7 2.1.12-stable-8 ii libffi8 3.4.4-1 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgcc-s112.2.0-14 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libnspr4 2:4.35-1 ii libnss3 2:3.87.1-1 ii libotr5 4.1.1-5 ii libpango-1.0-0 1.50.12+ds-1 ii libstdc++6 12.2.0-14 ii libvpx7 1.12.0-1+deb12u2 ii libx11-6 2:1.8.4-2+deb12u2 ii libx11-xcb1 2:1.8.4-2+deb12u2 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxext6 2:1.3.4-1+b1 ii libxrandr2 2:1.5.2-2+b1 ii psmisc 23.6-1 ii x11-utils7.7+5 ii zenity 3.44.0-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages thunderbird recommends: ii hunspell-en-us [hunspell-dictionary] 1:2020.12.07-2 ii hunspell-ru [hunspell-dictionary] 1:7.5.0-1 Versions of packages thunderbird suggests: ii apparmor 3.0.8-3 ii fonts-lyx 2.3.7-1 ii libgssapi-krb5-2 1.20.1-2+deb12u1 -- Configuration Files: /etc/apparmor.d/usr.bin.thunderbird changed [not included] -- no debconf information
Bug#1071971: please downgrade perl dependency to perl-base
Package: lm-sensors Version: 1:3.6.0-7.1 Severity: normal Currently, lm-sensors package has Depends: perl:any. However, the only utility which uses perl - sensors-detect - is just fine with perl-base, it does not use anything from the more complete perl package. On many systems we have, perl is only pulled by lm-sensors, and on all these systems, we don't even need sensors-detect. It'd be nice to get rid of this dependency. Please note that perl-base is Essential: yes. So is sed (which is also in Depends: line), and the minimum-required version of sed (4.0.5) is long in debian (buster has sed version 4.7 already). So both extra dependencies should be removed from the Depends: line. Thanks, /mjt
Bug#707624: winbind: winbind does not recover from DC reboot etc.
Version: 2:4.8.1+dfsg-1 This issue has been fixed in 4.8.1 but the bug report is still open. Let's close it finally. /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1071565: autopkgtest: ERROR: cloud-efi.raw is too small: 131 MB. Should be greater 890 MB
Source: fai Severity: normal See for example: https://ci.debian.net/packages/f/fai/testing/amd64/46884830/ This one is currently holding qemu transition. Thanks, /mjt
Bug#1071560: undeclared runtime library depencencies
Package: gpu-burn Version: 0+git20240115+ds-2 Severity: grave gpu-burn package links with libcuda.so.1 and libcublas.so.11 but does not list them in Depends. This results in a broken, entirely unusable package after install: gpu-burn: error while loading shared libraries: libcuda.so.1: cannot open shared object file: No such file or directory It looks like dh_shlibdeps step is missing in the packaging. The fact gpu-burn does not depend on any packages at all also suggests that - at the very least it should depend on libc6. Also, this thing seems to be NVidia-specific (it doesn't work on an AMD GPU), but it's nowhere mentioned in the package description. Nvidia is definitely NOT all the graphics world. Thanks, /mjt -- gpu-burn depends on no packages. Versions of packages gpu-burn recommends: pn nvidia-smi gpu-burn suggests no packages. -- no debconf information
Bug#1071227: busybox-udeb: provides binaries that are also provided by kmod-udeb (e.g. modprobe)
16.05.2024 20:17, Philip Hands пишет: Package: busybox-udeb Severity: normal User: debian-rele...@lists.debian.org Hi, I notice that busybox-udeb provides the following binaries in /sbin: depmod insmod lsmod modinfo modprobe rmmod while kmod-udeb provides the same, except located in /usr/sbin. https://salsa.debian.org/installer-team/busybox/-/commit/a52da181d4cd0e41c04ab1d5be9130270df0f696 #1060134 fwiw. /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1068360: samba-gpupdate should be in samba-common-bin
09.04.2024 15:13, Patrick Hibbs wrote: The net command in samba-common-bin, specifically: `/usr/bin/net ads join`, allows joining the domain without having the main samba package installed. Does `net ads join` need any python stuff? sssd-ad with it's ad_update_samba_machine_account_password flag set to true in it's config will keep the machine creds up-to-date without the main samba package installed. samba-gpupdate handles downloading and managing group policies on the domain member, just like the gpupdate utility under Windows. samba-gpupdate is just a python script. It's dependencies are in python3-samba. Which samba-common-bin already depends on. That script is invoked either by winbind, the alternative for sssd systems (and not packaged in Debian) oddjob-gpupdate (https://github.com/altlinux/oddjob-gpupdate), or manually by the system admin. (The script takes arguments similar to the Windows utility.) Okay, I don't know most of this. But we come across another idea meanwhile. How about we split out another package out of samba (and samba-common[-bin]), named samba-ad? The idea is to have minimal samba-common[-bin] to contain stuff absolutely necessary for smbclient and all servers (without python deps), samba binary package (also without python deps) being a minimal stand-alone file server, samba-ad (depends on python and samba) being AD part of the story, and samba-ad-dc is the, well, AD-DC part. This way, samba-gpupdate will be part of samba-ad package, instead of samba-common[-bin]. I'm not yet know if it is doable, but at first look I think it is. If you can help to better figure out what is what, it would be great. Maybe samba-ad should not depend on samba though, to suit your needs expressed in this bug report. Personally, I have samba-gpupdate invoked as an hourly cron job. Which is pushed out to the client machines via Samba's crontab group policy extension. (So after the initial join, I have to invoke samba-gpupdate myself once, but after that, cron is configured automatically to call it based on the policy that was pulled.) Of course, this will break if the host gets put into an OU in the domain that removes the cronjob, but that can be fixed by recalling samba-gpupdate after fixing the policy on the domain side. (And can even be triggered via a script calling ssh.) Yes, this can be done too, for sure. I'd use a systemd timer for this stuff, and ship it disabled. Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1070879: please make mail-transfer-agent optional
11.05.2024 09:14, Michael Tokarev wrote: .. Please note the function gnupg uses email for is very rarely used, - it's been many years when gpg-wks-server has been built without even specifying path to sendmail binary, it's been fixed only in #1025782 in 2024. Okay, it looks like I was wrong. gpg-wks-server is the one which actually uses email (for confirmation)... Even better if gpg-wks-server itself becomes "more optional", - right now it is installed on all my (at least desktop) systems. But this is a different matter it seems (looks more like bugs in other packages who blindly depend on whole gnupg instead of certain components they actually use). but it is the other packages which wrongly require whole gnupg, including gpg-wks-server, while actually using only main part of it. I just filed #1070882 against devscripts - which seems to be the main reason all my desktop systems has gpg-wks-server which is not used by anything. Also #1070880 against dput-ng. Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1070882: please do not depend on whole gnupg suite while using gpg only
Package: devscripts Version: 2.23.7 Severity: normal devscripts Depends on gnupg (|gnupg2), which is: This package contains the full suite of GnuPG tools for cryptographic communications and data storage. The "full" means it includes things like gpg-wks-server or gpgsm which are unnecessarily installed. It looks like devscripts actually needs only the main gpg binary, which is provided by gpg package. Unless I'm mistaken, this is all what's needed. Filing this bug with 'normal' severity, because of other complications in this area, for example see #1070879. Thanks, /mjt
Bug#1070880: dput-ng wrongly depends on whole gnupg package
Package: python3-dput Version: 1.39 Severity: normal python3-dput has Depends: gnupg, which feels wrong. As stated in gnupg package description: This package contains the full suite of GnuPG tools for cryptographic communications and data storage. It seems dput-ng only needs signing command-line interface of gpg, which is provided by gpg package (the main /usr/bin/gpg binary). Or if it uses python interface, this is python3-gnupg. It definitely does not need, for example, gpg-wks-server or gpgsm or other parts of gnupg which gets unnecessarily installed. Filing this with Severity: normal instead of wishlist because of other interdependencies, - for example, see #1070879. Thanks, /mjt
Bug#1070879: please make mail-transfer-agent optional
Source: gnupg2 Version: 2.4.4-1 Severity: minor Starting 2.4.4-1, gnupg depends on mail-transfer-agent. Unfortunately, these days, less and less systems actually have email system configured, especially home/laptop/etc systems (when email is done though a web UI). We had mail-transfer-agent almost mandatory in debian for quite a while, because cron used to depend on it for emailing status of failing jobs (among others), - now cron is finally optional itself, and it's possible to install a system without email. And now it becomes mandatory once again, now coming from gnupg side. Please note the function gnupg uses email for is very rarely used, - it's been many years when gpg-wks-server has been built without even specifying path to sendmail binary, it's been fixed only in #1025782 in 2024. Please make m-t-a at least Recommends (instead of Depends), or even better, - Suggests, because about 99.99% of gnupg users will never need it but configuring mta is a real burden (and it even can't be done in many cases). Even better if gpg-wks-server itself becomes "more optional", - right now it is installed on all my (at least desktop) systems. But this is a different matter it seems (looks more like bugs in other packages who blindly depend on whole gnupg instead of certain components they actually use). Thanks, /mjt
Bug#1070848: please package version 1.21 (needed for samba ad-dc functionality)
Source: krb5 Severity: wishlist X-Debbugs-Cc: pkg-samba-ma...@lists.alioth.debian.org Please update krb5 packages to version 1.21 (currently 1.21.2 is available). This is a minimum required version for Samba AD-DC functionality when built with MIT-KRB5 implementation. Thanks, /mjt
Bug#1070801: bookworm-pu: package qemu/1:7.2+dfsg-7+deb12u6
09.05.2024 14:53, Michael Tokarev wrote: Package: release.debian.org Severity: normal Tags: bookworm User: release.debian@packages.debian.org Usertags: pu X-Debbugs-Cc: q...@packages.debian.org, pkg-qemu-de...@lists.alioth.debian.org Control: affects -1 + src:qemu [ Reason ] There were 2 qemu stable/bugfix releases (7.2.10 and 7.2.11) since the previous debian release, fixing a number of various issues. It would be nice to have these fixes in debian too, so debian users will benefit from the qemu stable series. Among others, this release fixes several (low-priority) security issues: CVE-2024-3446 CVE-2024-3447 CVE-2024-26327 CVE-2024-26328 I forgot to mention here which I already mentioned in the previous qemu pu report (#1062044). In this debian release of qemu, I removed revert of a change which supposedly broke suspend-resume cycle of qemu-based VMs and hence broke cryptsetup autopkgtests. The change in question, which is a bugfix, monitor-only-run-coroutine-commands-in-qemu_aio_context.patch, has exactly nothing to do with suspend-resume, it's a red herring. The issue depends on the guest kernel instead, - I *think* it is a memory layout issue instead. With current bookworm kernels, with or without the patch in question, this suspend-resume issue is present for current qemu and for a few older qemu releases too. So I'm dropping this revert in this release, hence making debian qemu sources to match the upstream. Thanks, /mjt
Bug#1070335: samba-dev: missing Breaks+Replaces: libwbclient-dev (<< 2:4.20)
03.05.2024 23:16, Andreas Beckmann wrote: Package: samba-dev Version: 2:4.20.0+dfsg-1~exp2 Severity: serious User: debian...@lists.debian.org Usertags: piuparts fileconflict Hi, during a test with piuparts I noticed your package fails to upgrade from 'sid' to 'experimental'. It installed fine in 'sid', then the upgrade to 'experimental' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. This error may also be triggered by having a predecessor package from 'sid' installed while installing the package from 'experimental'. Hm. I'm not sure what to do here, it's a bit interesting. The move has happened in 4.19.6-2 which were uploaded a couple days ago. The version in experimental (4.20) uploaded *before* the version in sid (4.19.6) - I uploaded new upstream version to experimental to see how it will work. For the real 4.20 upload, I'll rebase it on top of current sid version, 4.19.6-2, which does have proper breaks/replaces but in the opposite direction. So in order to fix this bug, current version of samba should be *removed* from experimental, instead of adding backwards-facing breaks/replaces. I don't plan to do another upload of 4.20 to experimental at this time, and the next upload will be to sid (hopefully) with proper history et al. So current version in experimental is sort of orphan right now. Or are you suggesting I should perform another upload to experimental just to fix this bug report? I'd rather avoid another rebase.. Thanks, /mjt
Bug#1070236: [Pkg-samba-maint] Bug#1070236: python3-samba: SyntaxError during configuration phase of package on upgrade
Control: tag -1 + moreinfo unreproducible 02.05.2024 23:36, Michael Biebl wrote: Control: reopen -1 Control: found -1 2:4.19.6+dfsg-3 So, I'm confused now. You reopened this for -3 which *fixed* both issues mentioned by you as reasons for the reopen. Does -3 actually fails for you? Thanks, /mjt
Bug#1070236: [Pkg-samba-maint] Bug#1070236: python3-samba: SyntaxError during configuration phase of package on upgrade
02.05.2024 23:36, Michael Biebl wrote: Control: reopen -1 Control: found -1 2:4.19.6+dfsg-3 On Thu, 2 May 2024 11:58:59 -0700 "Leo L. Schwab" wrote: Did you fix this one, too? --- Performing actions... Setting up python3-samba (2:4.19.6+dfsg-2) ... File "/usr/lib/python3/dist-packages/samba/ms_schema_markdown.py", line 25 try ^ SyntaxError: expected ':' I also get File "/usr/lib/python3/dist-packages/samba/ms_schema_markdown.py", line 27 except ImportError e: ^ SyntaxError: invalid syntax All this is fixed in -3. /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1070236: [Pkg-samba-maint] Bug#1070236: python3-samba: SyntaxError during configuration phase of package on upgrade
02.05.2024 18:11, Dennis Boone wrote: Package: python3-samba Version: 2:4.19.6+dfsg-2 Severity: normal X-Debbugs-Cc: d...@msu.edu Dear Maintainer, During an `apt-get upgrade` this morning, the configuration phase of python3-samba emitted this error due to a missing colon: == Configurando python3-samba (2:4.19.6+dfsg-2) ... File "/usr/lib/python3/dist-packages/samba/ms_forest_updates_markdown.py", line 27 try ^ https://salsa.debian.org/samba-team/samba/-/commit/d1e04012eec6fcc111584590f8416991eddab0e3 FWIW. /mjt
Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
Ok, I'm removing whole modutils from busybox udeb (besides depmod, this is lsmod, insmod, rmmod, and modprobe). All these are provided by kmod-udeb as far as I can see (as symlinks to kod). -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
09.04.2024 16:48, Cyril Brulebois wrote: Marco d'Itri (2024-04-09): Yes. Nowadays kmod has many more features related to compressed modules and verification of signatures. Can we agree that kmod should provide these programs for d-i? Or can the d-i maintainers just tell us what they want? I meant to come back to this after experimenting, then things happened… I picked kmod at the time because it worked, and because busybox didn't work, which I summed up in: https://salsa.debian.org/installer-team/debian-installer/-/commit/450daf0bd24ee94d4f466ab65908c079ef795145 (plus follow-up commit, woopsie https://salsa.debian.org/installer-team/debian-installer/-/commit/69777be465c5d0210d16159a456ab88535513a07 ) I'm fine with sticking to kmod regarding module support in d-i. I'm not sure we should keep support in two different modules, so dropping it from busybox would work for me. Others might have different views on this, though. So, should I disable module utils in busybox-udeb now? Wanted to spare some time on busybox, this bug report come in. Is kmod udeb ready and used in d-i already, or does it need some prep first? Thanks, /mjt -- GPG Key transition (from rsa2048 to rsa4096) since 2024-04-24. New key: rsa4096/61AD3D98ECDF2C8E 9D8B E14E 3F2A 9DD7 9199 28F1 61AD 3D98 ECDF 2C8E Old key: rsa2048/457CE0A0804465C5 6EE1 95D1 886E 8FFB 810D 4324 457C E0A0 8044 65C5 Transition statement: http://www.corpit.ru/mjt/gpg-transition-2024.txt
Bug#1068649: winbind: Should be wanted by and ordered before nss-user-lookup.target
08.04.2024 17:27, Magnus Holmgren wrote: Package: winbind Version: 2:4.17.12+dfsg-0+deb12u1 I'm not entirely sure, but I think winbind.service should include [Unit] Wants=nss-user-lookup.target Before=nss-user-lookup.target systemd.special(7) says: "All services which provide parts of the user/group database should be ordered before this target, and pull it in." and winbind does provide parts of the user/group database (as long as it's mentioned in nsswitch.conf, but typically that's the point, isn't it?). This is a grey area (to me anyway). Myself, I tend to avoid this sort of dependencies as much as possible. Since winbind itself is ordered after network.target, we're at risk to make login impossible until network is up, and network might not be up until, say, wifi is running, etc. We've had trouble with cron not running some jobs for a good while, and I just now figured out that it's because we have some jobs configured to run as Samba users, and cron started before winbind on boot and complained about invalid users. Please note how /etc/init.d/cron is set up: cron itself is ordered after winbindd. Maybe this is not a nice as systemd variant which you outlined above, but in my view it is more reliable. Or maybe not, - cron often used to run @reboot jobs to start services... which is a bad idea anyway :) But I dunno what to do here. Thanks, /mjt
Bug#1069661: samba: apparmor integration broken since change to local systemd units in 2:4.19.4+dfsg-1
Control: tag -1 + pending 22.04.2024 12:18, Alex Murray wrote: Package: samba Version: 2:4.19.5+dfsg-4 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu noble ubuntu-patch Dear Maintainer, *** /tmp/tmpz7e0qwfp/bug_body In Ubuntu, the attached patch was applied to achieve the following: When samba was updated to ship local systemd service unit files in 2:4.19.4+dfsg-1 the ExecStartPre directive was not included. As such the integration with apparmor via the update-apparmor-samba-profile script was lost. The previously used patch can be dropped as the file that is patched is now not used and instead the locally maintained systemd unit is updated to include this directive instead. Indeed, I broke this when moving to local services. Thank you for the patch. It will be part of the next upload, I just pushed it to git. /mjt
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
On Tue, 6 Feb 2024 19:37:46 +0300 Michael Tokarev wrote: 03.02.2024 12:47, Michael Tokarev wrote: >>> It looks like we broke suspend/resume in this version of qemu. >> Oops. Is that related to the cryptsetup failure, or a separate issue? > > Yes, it is related to cryptsetup autopkgtest failure. It looks > like this is the only place where suspend/resume code in qemu > is actually being used, - it's rather rare to suspend (hybernate) > a virtual machine, and cryptsetup performs testing of how the > encrypted filesystem is unlocked (or not) on resume. So, while the problematic upstream commit fixes quite a few real potential qemu lockups, it introduces a new lockup in suspend- resume-hibernate cycle. The problem isn't understood yet, and we're getting close to the 12.5 release. The problematic upstream commit (on master) is this one: https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 It has links to 2 bugs it is fixing, and there are quite a few other bugs which are fixed too. It turned out this commit was innocent. The bug most likely is somewhere in qemu, but it is triggered by the guest kernel, it looks like, not by this qemu commit. Current bookworm kernels (6.1.19 and 6.1.20) fails in this same suspend/resume test in all current versions of qemu, including the ones with this commit applied, including current qemu master, and including versions much older than that, - including original qemu as initially released with bookworm, before all updates. It is not yet clear what's going on here. But we'll have to live with that somehow, and, - I guess - have to live with the broken cryptsetup autopkgtests. I'm preparing a new upstream stable/bugfix version of qemu 7.2.x for bookworm, which will include a few CVE fixes, many other fixes all other the place, and re-introduction of this commit too, - which, as it turns out, has actually nothing to do with the broken suspend-resume. Thanks, /mjt
Bug#1069367: qemu: FTBFS on arm64: build-dependency not installable: gcc-powerpc64-linux-gnu
20.04.2024 15:33, Lucas Nussbaum wrote: [..] This is part of a mass rebuild, first building on arm64 and then on armhf and armel. So I'm not suggesting anything. :-) Aha. Is this failing because the build is trying to build arch:all packages, that can only be built on amd64? If so, the bug severity could be lowered, clearly. Well. Yes, this is exactly the case. qemu uses quite a few cross-compilers to build various firmware components. This is arch-all package qemu-system-data. Most of these cross-compilers are available on x86 _only_, including the mentioned gcc-powerpc64-linux-gnu. I especially made these deps to be in Build-Depends-Indep only, - to be able to (re)build qemu on non-x86 by using `apt --arch-only`. I can't say this is a bug to begin with, - wrt lowering its severity. If it is a bug, it's a bug in gcc, not qemu (since it is gcc which does not provide these cross-compilers on all architectures). Or in the build environment. Thanks, /mjt
Bug#1069367: qemu: FTBFS on arm64: build-dependency not installable: gcc-powerpc64-linux-gnu
Control: tag -1 + moreinfo Control: found -1 1:4.2-2 20.04.2024 15:11, Lucas Nussbaum wrote: Source: qemu Version: 1:8.2.2+ds-2 Severity: serious Justification: FTBFS Tags: trixie sid ftbfs User: lu...@debian.org Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-arm64 sbuild-build-depends-main-dummy : Depends: gcc-powerpc64-linux-gnu but it is not installable E: Unable to correct problems, you have held broken packages. I don't understand what are you suggesting to do here. Should I disable all foreign compilers and code in qemu? This way, qemu will be nearly useless. Or should you perhaps file a bug against gcc to provide powerpc64 cross-compilers for arm64? If it's this variant, why are you filing this bug report against qemu? Thanks, /mjt
Bug#1068740: qemu-user-static: q-u-s > 8.1.3 fails to run amd64 binaries or docker containers on arm64 host
10.04.2024 10:55, Steev Klimaszewski wrote: I wanted to try if 8.2.2, or 9.0 has a fix, but due to the time64 change, I cannot use packages from unstable or experimental at this time as Kali is based on Debian testing. I did try cloning the repository to build it myself in a kali sbuild chroot, however I got some unrelated error message about the xz file being corrupt. You can download qemu-user-static .deb of any version and install it in your environment - it is a self-contained package (since it is linked statically) not requiring any time64 changes. Speaking of xz file being corrupt - I'd love to know more details about this one. As of the bug itself, - it would be very interesting to see which change in 8.1.4 caused this problem (hopefully I got it right and it's been introduced in 8.1.4 - actually, introduced in master and backported to 8.1.4). Please install a build environment (minimal is enough, with libglib-dev, libz-dev, meson, python3-venv - and maybe a few others which I forgot about, - you'll know after the first try). Clone the qemu git repository, build just qemu-x86_64-static binary: ../configure --target-list=x86_64-linux-user --enable-static && make qemu-x86_64 and try bisecting between v8.1.3 and v8.1.4 (or maybe try other versions if it is not in 8.1.4 - eg, check if 8.2.0 works but 8.2.3 doesn't, etc). You'll have to re-load binfmt registration after updating the binary in /usr/bin/qemu-x86_64-static - kernel keeps old binary open. Just use `cat /usr/lib/binfmt.d/qemu-x86_64.conf > /proc/sys/fs/binfmt_misc/register' or re-run systemd-binfmt.service. It would be difficult for me to try it here since I don't have the hardware. Maybe you can create a smaller testcase as well. Thanks, /mjt
Bug#1068737: locales fails to install: locales failed to preconfigure, with exit status 2
Package: locales Version: 2.37-16 Severity: grave A fresh `debootstrap unstable' chroot plus `apt install locales`: Preconfiguring packages ... locales failed to preconfigure, with exit status 2 dpkg: error processing package locales (--configure): installed locales package post-installation script subprocess returned error exit status 2 Errors were encountered while processing: locales This is coming from this line in locales.config: DEFAULT_ENVIRONMENT="$(sed -En -e '/^LANG="?([^"]+)"?/h; g; $s//\1/p' /etc/default/locale /etc/locale.conf 2>/dev/null)" /etc/locale.conf does not exist (and it doesn't exist on my regular system too), so sed fails with "can't read: No such file or directory" error message (which is sent to /dev/null), and since whole script is run under `set -e', it exits here. This is caused by "debian/debhelper.in/locales.config: Extract default environment LANG using only sed" change in 2.37-16. Do we really need /etc/locale.conf at this time? I think it's unused for a very long time. Also see EE= assignment at the very beginning of this script.
Bug#1068360: [Pkg-samba-maint] Bug#1068360: samba-gpupdate should be in samba-common-bin
04.04.2024 10:42, Patrick Hibbs: Package: samba Version: 2:4.17.12+dfsg-0+deb12u1 Severity: wishlist X-Debbugs-Cc: hibbsncc1...@gmail.com Dear Maintainer, I noticed that the group policy tool (/usr/sbin/samba-gpupdate) in Debian is stored in the samba package. This seems to be a poor choice of placement as group policies are expected to be applied on all domain joined hosts, and you can join a domain with just the samba-common-bin and sssd-ad packages, but the samba package is only installed if the SMB file server component is required. How would you join a computer without main samba component to a domain, and how would you process group policy in this case? /mjt
Bug#1068526: samba-dsdb-modules dependencies unsatisfiable on 32-bit non-i386 architectures.
07.04.2024 05:54, Peter Green wrote: Ubuntu has already fixed this issue by removing the hardcoded dependency on libgpgme11 I fixed it in git too, but forgot to upload. http://launchpadlibrarian.net/720831431/riseup-vpn_0.21.11+ds1-5build3_0.21.11+ds1-5ubuntu1.diff.gz While poking through the ubuntu changelog, I noticed another change that looks relavent (but non-rc) http://launchpadlibrarian.net/720831431/riseup-vpn_0.21.11+ds1-5build3_0.21.11+ds1-5ubuntu1.diff.gz Both of these URLs are the same and points to an unrelated package riseup-vpn. /mjt
Bug#411059: sash: bad practice of multiple accounts with uid==0 lead to broken system
Control: title -1 nscd caches "wrong" name for accounts with the same uid Control: found -1 2.37-15 Rehashing this 17-years old bug which biten me today quite hard. On Mon, 12 Feb 2007 22:55:28 -0500 Yaroslav Halchenko wrote: Today, after unsucsessful attempt to login as sashroot, I've got somewhat broken system -- all processes running under uid=0 were reported belonging to sashroot. Due to lack of knowledge of nss internals I inquired on -devel mailing list and it seems that multiple accounts sharing uid=0 might be considered a bad practice. For more details see http://lists.debian.org/debian-devel/2007/02/msg00323.html thread. If you can prove that it is 'documented feature of nss' to resolve in some deterministic way a uid whenever multiple ones are possible, then probably this bug has to be reassigned against libc6 to which libnss_files belongs. Since this bug might drive whole system broken, I am assigning it important priority, since a big proportion of sash users probably use sashroot account feature. The problem here is that nscd caches both username and uid on each lookup, instead of caching just the lookup which has been asked, and doing the other lookup the normal way as would be done by getpwnam/getpwuid (and similar for getgrnam/getgrgid etc). For very long time we relied on multiple special accounts having the same uid, exactly like this very sashroot case. We had this for a few system/special accounts. Each name has its own password and/or ssh keys (when in use), and each does start/manage its subsystem with the right permissions. Now, with normal getpwuid(), it will return the first entry with the given uid. But in case of nscd, it returns last looked up entry with this uid instead. Eg, we have root and r_mjt, - when I run getpwnam(root), getpwuid(0) will return the same entry. But once I looked up getpwname(r_mjt), getpwuid(0) will return r_mjt instead of root from now on. Here's another incarnation of the very same theme: https://run.tournament.org.il/multiple-users-with-the-same-uid-gid/ I guess they use oracle rdbms, and for this one it is also very helpful to have 2-3 accounts with the same uid, for managing purposes. And it breaks badly with nscd too. Why this bug is marked 'wontfix'? Thanks, /mjt
Bug#1068063: sssd: FTBFS on armel, armhf (test failures with test_pam_xxx, test_user_xxx... for 2.9.x)
On Sat, 30 Mar 2024 16:59:51 +0900 Kentaro HAYASHI wrote:
Source: sssd
Severity: serious
Tags: ftbfs
Control: found -1 2.9.4-1.1
X-Debbugs-Cc: ken...@xdump.org
Dear Maintainer,
sssd fails to build on armel, armhf.
Though test suite failure was already reported, but
target version is 1.11.5.1-1, not 2.x branch. so I've filed as a new
bug to raise attension.
sssd: FTBFS on many archs due to testsuite failures
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754618
FYI:
https://buildd.debian.org/status/fetch.php?pkg=sssd=armel=2.9.4-1.1=1711454828=0
https://buildd.debian.org/status/fetch.php?pkg=sssd=armhf=2.9.4-1.1=1711455028=0
There seems to be two failures here.
1. --- 0x2 != 0x1
src/tests/cmocka/test_responder_cache_req.c:2505: error: Failure!
assert_int_equal(test_ctx->result->count, 1);
apparently there are 2 results returned while expected just one.
2. --- No entries for symbol sss_dp_get_account_recv.
src/tests/cmocka/common_mock_resp_dp.c:52: error: Could not get value to
mock function sss_dp_get_account_recv
src/tests/cmocka/test_pam_srv.c:802: note: Previously returned mock value
was declared here
void mock_account_recv(uint16_t dp_err, uint32_t dp_ret, char *msg,
acct_cb_t acct_cb, void *pvt)
{
will_return(sss_dp_get_account_recv, dp_err);
There's a similar issue: https://github.com/SSSD/sssd/issues/3302 from 2014,
"We inspected the code in question and didn't find the reason for the
failure."
and an ubuntu bug:
https://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg6044689.html
Not knowing neither sssd nor cmocka, but have to put this info
somewhere after looking at this thing :)
/mjt
Bug#1065544: [Pkg-samba-maint] Bug#1065544: Cannot install samba due to missing packages
Additionally, when reporting issues, it is at least wise to not block maintainers from replying. : host mx10.domainnames.be[116.203.84.114] said: 550 senderdomain blacklisteda (in reply to RCPT TO command) /mjt
Bug#1065469: Can't upgrade: trying to overwrite '/usr/share/doc/qemu-system-common/system/arm/aspeed.html'
05.03.2024 10:03, Andrey Rahmatullin wrote: Breaks: qemu-system-common (<< 8.2.1+ds-3~), Replaces: qemu-system-common (<< 8.2.1+ds-3~), so... what's going on here? q-s-d 8.2.2 replaces files from q-s-c 8.2.1 Can it be simply because the package has an epoch and relations should include it? AAARGH! Yes, you're exactly right. Sigh :) Fixing it now, thank you! /mjt
Bug#1065469: Can't upgrade: trying to overwrite '/usr/share/doc/qemu-system-common/system/arm/aspeed.html'
05.03.2024 09:10, Andrey Rahmatullin wrote: Package: qemu-system-data Version: 1:8.2.2+ds-1 Severity: serious Preparing to unpack .../qemu-system-data_1%3a8.2.2+ds-1_all.deb ... Unpacking qemu-system-data (1:8.2.2+ds-1) over (1:8.2.1+ds-2) ... dpkg: error processing archive /var/cache/apt/archives/qemu-system- data_1%3a8.2.2+ds-1_all.deb (--unpack): trying to overwrite '/usr/share/doc/qemu-system- common/system/arm/aspeed.html', which is also in package qemu-system-common 1:8.2.1+ds-2 Hmm. In 8.2.2 I moved common docs from arch-dependent package qemu-system-common to arch-indep package qemu-system-data. Current control fields for the latter, among others, has: Breaks: qemu-system-common (<< 8.2.1+ds-3~), Replaces: qemu-system-common (<< 8.2.1+ds-3~), so... what's going on here? q-s-d 8.2.2 replaces files from q-s-c 8.2.1 Yes, the version it replaces is a bit off (I planned to upload another 8.2.1 but uploaded 8.2.2 instead), but it should work. WTF? /mjt
Bug#1065463: debootstrap can deal with native dpkg file replacement feature
05.03.2024 03:36, Steven Shiau : Package: debootstrap Version: 1.0.134 Severity: wishlist Dear Maintainer, As mentioned here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065394#28 For the moment on Mar/5/2024 in the Debian Sid repository, libuuid1 "Provides: libuuid1t64 (= 2.39.3-9)", and an exact version of libuuid1t64 which is not in repos. libuuid1 and libuuid1t64 have "Replaces:" on each other already. debootstrap should be able to solve the libuuid1t64 dependency by installing libuuid1 only. I think we should not add complexity to debootstrap just to be able to perform a transition like this once in 20+ years. /mjt
Bug#1065349: [Pkg-samba-maint] Bug#1065349: libsmbclient0: Actually breaks part of t64 transition
Control: severity -1 important 03.03.2024 13:21, Eric Valette : Package: libsmbclient0 Version: 2:4.19.5+dfsg-3 Severity: grave Justification: renders package unusable This is wrong, in my opinion. The effect of this bug on platforms unaffected by time64_t transition is exactly the same as on platforms affected by the transition. That is, on armhf and a few other platforms, *all* relevant packages are being renamed without the compatible Provides, so all reverse-dependencies has to be rebuilt. On other platforms though (like amd64), the actual ABI isn't changed and the rebuild/rename isn't really necessary, the new library provides exactly the same ABI as the old one. The fact that the new library does not have proper Provides: just means it will be fixed a bit later when all reverse dependencies will be rebuilt, that's all. In other worlds, the package is exactly as useful as before, it's just inconvenience which will be fixed soon, nothing more. /mjt
Bug#1065276: please build loong64 packages
Source: gcc-14-cross-ports Version: 4 Severity: wishlist X-Debbugs-Cc: pkg-qemu-de...@lists.alioth.debian.org Please consider building loong64 cross-compiler too, once this architecture has become one of debian ports. In particular, this is needed to build qemu (only a tiny part so far, vdso.so helper binary for qemu-user, but it is aready nearly impossible to do without a cross-compiler). Thanks, /mjt
Bug#1065173: udns: FTBFS on armhf/armel: configure: fatal: cannot find libraries needed for sockets
01.03.2024 17:24, Emanuele Rocca wrote: Source: udns Version: 0.4-1.1 Severity: serious Tags: ftbfs User: debian-de...@lists.debian.org Usertags: time64 Dear Maintainer, udns fails to build on both armhf and armel with the time64 build flags, which are on by default. It builds fine without. Specifically, the following flags cause a failure: -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 While the package builds with these: -U_LARGEFILE_SOURCE -U_FILE_OFFSET_BITS -U_TIME_BITS Relvant part of the build logs: checking whenever the C compiler (gcc -Wall -W -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/<>=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -Wl,-z,relro) This has nothing to do with time64. The prob here is -Werror=implicit-function-declaration Where that flag is coming from? /mjt
Bug#1065188: [Pkg-samba-maint] Bug#1065188: samba: missing build-dep on libtirpc-dev (and also rpcsvc-proto)
01.03.2024 19:05, Aurelien Jarno : Source: samba Version: 2:12.3.5-4 Is it really 12.3.5-4? :) /mjt
Bug#1064634: qemu-system-x86: possible race-condition in qemu nat layer or virtio-net
25.02.2024 13:29, g1 : Package: qemu-system-x86 Version: 1:7.2+dfsg-7+deb12u5 Severity: normal X-Debbugs-Cc: g...@libero.it I believe I spotted a race condition in virtio-net or qemu/kvm (but only when virtio-net is involved). Please take it with upstream qemu, - eg, qemu-de...@nongnu.org mailing list or qemu gitlab repository issue tracking. Thanks, /mjt
Bug#1063233: qemu-system-{arch} packages provide themselves
Control: reopen -1
Control: Version -1 1:8.0+dfsg-1
On Mon, 05 Feb 2024 20:21:18 +0100 Daniel Vacek wrote:
echo 'qemu:Provides=$(if $3,qemu-kvm (=${DEB_VERSION})${comma})\
-$(patsubst %,qemu-system-% (=${DEB_VERSION})${comma}, any $2 $(foreach
q,$2,${system-alias-$q}))' \
+$(filter-out $1,$(patsubst %,qemu-system-% (=${DEB_VERSION})${comma},
any $2 $(foreach q,$2,${system-alias-$q})))' \
Actually.. neither your solution nor mine works, it's a bit more complicated
than that.
Your solution filters the whole thing with includes version info, so the
end result is:
Provides: qemu-system-any (=8.2.1), (=8.2.1), qemu-system-armel (=8.2.1)
which is obviously wrong.
Mine actually does nothing, since it tries to filter out qemu-system-bar
out of foo bar baz.
That needs additional tweaking.
/mjt
Bug#1064544: libwbclient-dev should provide more header files to be useful
Package: src:samba Version: 2:4.19.5+dfsg-1 interface defines quite some structs and functions to communicate with winbind. However, it does not define WinNT status codes, used, for example, in wbcAuthErrorInfo:nt_status. Without these, the code can not know actual reason of the error, and can't handle it properly. NT STATUS codes are declared in code/ntstatus.h. However, this file declares a few other functions which are internal to samba. So it isn't possible to just move that file to another package. /mjt
Bug#1064542: please stop Build-Depending on samba-dev, use libwbclient-dev instead
24.02.2024 01:21, Michael Tokarev: Source: freeradius Version: 3.2.3+dfsg-2 Severity: important X-Debbugs-Cc: pkg-samba-de...@lists.alioth.debian.org For a long time now, samba provides separate library libwbclient (together with development package) which is actually public (unlike the collection in samba-libs) and has stable API and ABI. As far as I can see, freeradius only needs winbindd, not whole samba. samba-dev has too much private interfaces which should not be used. Actually this turns out not to be that simple. src/modules/rlm_mschap/auth_wbclient.c includes core/ntstatus.h, which defines core WinNR status codes. Without that, is kind of useless. It looks like we have to refine which headers are included in which packages in samba. Hmm.. /mjt
Bug#1064542: please stop Build-Depending on samba-dev, use libwbclient-dev instead
Source: freeradius Version: 3.2.3+dfsg-2 Severity: important X-Debbugs-Cc: pkg-samba-de...@lists.alioth.debian.org For a long time now, samba provides separate library libwbclient (together with development package) which is actually public (unlike the collection in samba-libs) and has stable API and ABI. As far as I can see, freeradius only needs winbindd, not whole samba. samba-dev has too much private interfaces which should not be used. Thanks, /mjt
Bug#1064512: python3-samba: Tests should not be packaged
Control: severity -1 wishlist 23.02.2024 16:58, Gregor Riepl wrote: Package: python3-samba Version: 2:4.19.5+dfsg-1 Severity: normal X-Debbugs-Cc: onit...@gmail.com Dear Maintainer, It looks like the python3-samba package installs some unit tests into /usr/lib/python3/dist-packages/samba/tests If this is the case, please exclude them from the package build. There is no value in installing unit tests along with a runtime library (or, as in this case, a Python module). Lacking a way to exclude something from debian/install file, I don't have a good way to do that. The tests should not be merely excluded, it is part of samba-testsuite package. samba-testsuite itself is a very questionable package, it has other issues (like being non-reproducible as it embeds build paths in the binary and has other problems in this area) and personally I don't see a reason to ship this package in debian. If it were removed, this an other problems would just go away. But some say it is useful. I dunno :) /mjt
Bug#1064337: [Pkg-samba-maint] Bug#1064337:
21.02.2024 12:03, Michael Hudson-Doyle wrote: ... Yes, this is exactly what I had in mind, and already prepared the very same changes locally in the package git repository. > I think the ideal way forward would be to upload to experimental asap to check it builds and to let Helmut run dumat on it and then upload the > unstable patch when the transition starts in earnest (planned for Friday this week). The changes are pretty orthogonal to the differences between what > is unstable and experimental currently afaict. Yes, that's what I was thinking about, too. Still, I prefer to have 4.19 in unstable so far, not 4.20-rc. That makes sense. We definitely do not want to have to coordinate with other transitions for this, so it sounds like we (or maybe you!) should just patch the 4.19 in unstable and then you can migrate 4.20 when it suits you. I just uploaded a new release to experimental. Here are the 2 commits: https://salsa.debian.org/samba-team/samba/-/commits/debian/2%254.20.0_rc2+dfsg-3 which makes the t64 changes (note the X-Time64-Compat header, too). Exactly the same changes applies on top of 4.19 currently in unstable. I especially split it into two commits, one actual change and one d/changelog, so the two can be applied separately, - since obviously d/changelog changes wont apply cleanly and needs manual edit. So we can either do an NMU of 4.19, based on your nmu_samba_UNstable.debdiff, or I can do a regular upload once the transition starts. In some sense it would be easiest to just NMU samba like we are planning to with everything else but I don't have a strong feeling about this. Yeah, - can be done either way, that's why I'm making it easier. Thanks, /mjt
Bug#1064337: [Pkg-samba-maint] Bug#1064337:
21.02.2024 11:26, Michael Hudson-Doyle wrote: I have prepared another patch on top of what is in experimental now (attached as nmu_samba.debdiff), does it look better? I have also prepared a patch on top of what is currently in unstable, attached as nmu_samba_unstable.debdiff. It's named nmu_samba_STABLE.debdiff, though - made me confused for a bit :) Yes, this is exactly what I had in mind, and already prepared the very same changes locally in the package git repository. I think the ideal way forward would be to upload to experimental asap to check it builds and to let Helmut run dumat on it and then upload the unstable patch when the transition starts in earnest (planned for Friday this week). The changes are pretty orthogonal to the differences between what is unstable and experimental currently afaict. Yes, that's what I was thinking about, too. Still, I prefer to have 4.19 in unstable so far, not 4.20-rc. So we can either do an NMU of 4.19, based on your nmu_samba_UNstable.debdiff, or I can do a regular upload once the transition starts. Uploading what I have for experimental now, which is essentially the same as your nmu_samba.debdiff. Thanks, /mjt
Bug#1064337: [Pkg-samba-maint] Bug#1064337: samba: NMU diff for 64-bit time_t transition
20.02.2024 10:30, Andrew Bartlett : Kia Ora Steve, So long since we had a chance to work together, and I thank you for your work on Debian. Can we have a chat about this? sssd does not, as I read it, use any time_t relevant parts of ldb, and is the only external user of LDB in Debian that we know of. It is not only about Debian. The transition is here not just for packages in Debian, but also for any external 3rd-paty packages which might be installed on user systems from any external sources or built locally. Still, libldb and samba-libs are private-to-samba things (or at least semi-private), libldb isn't something which is consumed externally (even sssd *extends* libldb, not "uses" it). There should be no external consumers of it. And for sssd, we had enough changes in libldb already which breaks sssd in one way or another and needs sssd rebuild or refinement. FWIW. Do we really need libldb package? Maybe it can be a part of samba-libs? There's a thread about that on samba-technical@, but it occured to me only now, - do we *really* need a separate libldb? I'll reply on samba-technical@, this has nothing to do with this time_t transition. /mjt
Bug#1064337: [Pkg-samba-maint] Bug#1064337: samba: NMU diff for 64-bit time_t transition
Control: tag -1 - patch pending One more note: samba package in experimental is *not* yet intended for unstable, it is a pre-release of next samba version and I don't plan to upload it to unstable yet. If any work is needed, it should be done on top of 4.19. But I'm not sure how to coordinate it all yet. At the very least, I'm willing to help, can prepare things with 4.19 and upload when needed. /mjt
Bug#1064337: [Pkg-samba-maint] Bug#1064337: samba: NMU diff for 64-bit time_t transition
20.02.2024 09:30, Steve Langasek wrote: Source: samba Version: 2:4.20.0~rc2+dfsg-1 Severity: important Tags: patch pending sid trixie User: debian-...@lists.debian.org Usertags: time-t -Package: libsmbclient +Package: libsmbclient0 Well. Maybe this is ok. I still haven't seen samba-libs analysis about time_t abi, but smbclient never had a version in soname. libsmbclient is definitely a public library. -Package: libldb2 +Package: libldb2t64 And this one is definitely not needed. libldb is an internal-to-samba library, which is used by exactly one package in debian, sssd, for which you're adding Breaks. I'm already adding the same Breaks in the next version of libldb, because libldb has become incompatible with sssd *again* (the new packages of samba 4.20 is in experimental, not yet with the Breaks since I'm waiting for a rebuild of sssd). Due the nature of these libs (samba-libs and libldb), it is a stuff which is not used outside, and it does not need time_t transition. Where's the analysis of libsmbclient ABI? Thanks, /mjt
Bug#1063518: console-setup: setupcon: 1386: Syntax error: Missing '))'
09.02.2024 17:57, Thorsten Bonow :
dash << 'EOF' [15:28:53]
if $( (true) 2>/dev/null); then
echo "42"
fi
EOF
42
which only works in dash because of the added space between the command
substitution $(...) and the subshell (...).
Does dash think it has to do arithmetic expansion "$((...))"?
Yes, arithmetic, and that's what bash does too. dash does not understand
space between two closing parens though, ') )'. And this is logical - if
the opening is "((", use the same matching "))" for closing.
$(( ... )) is arithmetic expression,
$( ( ... ) ) is a subshell.
Everything else is asking for trouble like this.
But what's POSIX take on this? I couldn't find anything. Is this a bug in
dash or in setupcon?
It's a bug in setupcon.
/mjt
Bug#1063518: console-setup: setupcon: 1386: Syntax error: Missing '))'
09.02.2024 16:58, ca...@allfreemail.net Package: console-setup Followup-For: Bug #1063518 Consider making all scripts provided by console-setup shellcheck-clean, there are lots of tiny issues that can turn into big issues under the right conditions. Please do not do this. Shellcheck is a huge problem and we had large amount of bugs due to people trying to apply its suggestions. It's very difficult in many cases to spot why shellcheck is wrong (classic is the suggestion to put $var into double quotes "$var" which breaks badly if $var is supposed to contain zero or more separate words - this way, even boot scripts has become buggy leading to system becoming unbootable). Shellcheck is a very bad tool. /mjt
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
06.02.2024 12:34, Helmut Grohne: ... An option I see here is to provide ABI-duality for libselinux: -extern int matchpathcon_filespec_add(ino_t ino, int specind, const char *file); +typedef unsigned long libselinux_ino_t; +typedef uint64_t libselinux_ino64_t; +extern int matchpathcon_filespec_add(libselinux_ino_t ino, int specind, const char *file); +#if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 && sizeof(unsigned long) < 8 It's good for a sketch to show an idea but it wont work in practice, - you can't use sizeof(foo) in a preprocessor condition. That's what WORDSIZE #defines are for. But it's a minor nit. glibc already has all the support for LFS which can be used directly, by copying code from any glibc header, like eg for lseek definition... +extern int matchpathcon_filespec_add64(libselinux_ino64_t ino, int specind, const char *file); +#define matchpathcon_filespec_add matchpathcon_filespec_add64 and keeping this #define here instead of using internal in-glibc symbol redirection stuff. And ofc we need to define the compat wrapper for matchpathcon_filespec_add to the source, and the new 64bit symbol to libselinux.map, with the same arch-specific condition. /mjt
Bug#1063329: libselinux1t64: breaks system in upgrade from unstable
07.02.2024 11:06, Helmut Grohne :
..
pam seems difficult:
| extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
| extern time_t pam_misc_conv_die_time; /* cut-off time for input */
Attached is a sketch to make pam compatible.
I had a more complete and *tested* fix 2 days ago but I forgot
it was in /tmp and I rebooted the machine, so had to do it again
yesterday.
The idea is to have both die_time and die_time64, and keep them
in sync (using minimum between two values which is !=0).
This is a sketch using a #define, though better is to use symbol
versioning here and have time32 compat stuff for old programs
and 64bit time stuff for new, using redirection at the link time,
instead of the #defines which makes whole thing rather difficult
to read, - that's extra several lines of code, also to the .map
file.
What the whole thing needs is the criteria to use to enable the
trick. Right now I used #ifdef NEED_TIME64_COMPAT which should
be defined somehow, - since I don't know the precise list of
architectures where this has to be done. This is an externally-
controlled thing, there's no way to determine this directly from
the .c code (short of using architecture list in the .h file),
so it must be some symbol substituted at the package build time,
like Provides: t64:Compat (or whatever it is) is substituted in
d/control.
This is a less-intrusve-to-original-code version of the sketch,
ie, I tried to keep all changes outside of the original code as
possible, keeping all the original logic as it is.
/mjtdiff --git a/libpam_misc/include/security/pam_misc.h b/libpam_misc/include/security/pam_misc.h
index fca2422..922341c 100644
--- a/libpam_misc/include/security/pam_misc.h
+++ b/libpam_misc/include/security/pam_misc.h
@@ -21,6 +21,15 @@ extern int misc_conv(int num_msg, const struct pam_message **msgm,
#include
+#if NEED_TIME64_COMPAT
+
+extern time32_t pam_misc_conv_warn_time;
+extern time32_t pam_misc_conv_die_time;
+#define pam_misc_conv_warn_time pam_misc_conv_warn_time64
+#define pam_misc_conv_die_time pam_misc_conv_die_time64
+
+#endif
+
extern time_t pam_misc_conv_warn_time; /* time that we should warn user */
extern time_t pam_misc_conv_die_time; /* cut-off time for input */
extern const char *pam_misc_conv_warn_line; /* warning notice */
diff --git a/libpam_misc/misc_conv.c b/libpam_misc/misc_conv.c
index 908ee89..a02d491 100644
--- a/libpam_misc/misc_conv.c
+++ b/libpam_misc/misc_conv.c
@@ -30,6 +30,9 @@
time_t pam_misc_conv_warn_time = 0; /* time when we warn */
time_t pam_misc_conv_die_time = 0; /* time when we timeout */
+static void fixup_compat_time();
+static void reset_warn_time();
+
const char *pam_misc_conv_warn_line = N_("...Time is running out...\n");
const char *pam_misc_conv_die_line = N_("...Sorry, your time is up!\n");
@@ -96,6 +99,8 @@ static int get_delay(void)
expired = 0;/* reset flag */
(void) time();
+fixup_compat_time();
+
/* has the quit time past? */
if (pam_misc_conv_die_time && now >= pam_misc_conv_die_time) {
fprintf(stderr,"%s",pam_misc_conv_die_line);
@@ -107,7 +112,7 @@ static int get_delay(void)
/* has the warning time past? */
if (pam_misc_conv_warn_time && now >= pam_misc_conv_warn_time) {
fprintf(stderr, "%s", pam_misc_conv_warn_line);
- pam_misc_conv_warn_time = 0;/* reset warn_time */
+ reset_warn_time();
/* indicate remaining delay - if any */
@@ -399,3 +404,36 @@ failed_conversation:
return PAM_CONV_ERR;
}
+
+#ifdef NEED_TIME64_COMPAT
+
+#undef pam_misc_conv_warn_time
+#undef pam_misc_conv_die_time
+
+int pam_misc_conv_warn_time, pam_misc_conv_die_time;
+
+/* in compat 32/64 case, we have 2 values: time and time64.
+ We perform all operations with time64
+ But we try to keep them in sync, whiciever is smaller but !0 */
+#define fixup(t, t32) \
+if (t32 && (!t || t > t32)) t = t32; /* if t32 fires sooner */ \
+if (t < 0x7fff) t32 = t /* only if t can fit in t32 */
+
+static void fixup_compat_time() {
+fixup(pam_misc_conv_warn_time64, pam_misc_conv_warn_time);
+fixup(pam_misc_conv_die_time64, pam_misc_conv_die_time);
+}
+static void reset_warn_time() {
+ pam_misc_conv_warn_time = 0;
+ pam_misc_conv_warn_time64 = 0;
+}
+
+#else
+
+static void fixup_compat_time() {
+}
+static void reset_warn_time() {
+ pam_misc_conv_warn_time = 0;
+}
+
+#endif
Bug#1056331: qemu-user-static: fails to run any binary with message "error while loading shared libraries" on Apple Silicon
Control: tag -1 forwarded https://gitlab.com/qemu-project/qemu/-/issues/1591 FWIW.
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
06.02.2024 20:55, Adam D. Barratt : On Tue, 2024-02-06 at 20:49 +0300, Michael Tokarev wrote: .. The change isn't small per se, as the commit is rather large (mostly due to many changed tests, - it changes order of output in quite some places). Here's the diffstat: monitor/qmp.c | 17 + qapi/qmp-dispatch.c | 24 +- -- This is the relevant bit for size IMO. If you're happy with the result then please upload as soon as you're ready. Yes, I'm happy with the result. Well, - as much as one can be happy here, choosing between one bug or another, - but it is at least a status-quo and we don't have known regressions in debian stable due to this. I just re-ran upstream testsuite just to be extra sure, and am running my bunch of guests as well, everything works as expected so far. I wont try to reproduce the issues this patch (which I'm reverting) fixed, though ;) Uploaded +deb12u5 now, waiting to be picked up. Thank you for the patience and all the work! /mjt
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
06.02.2024 20:33, Adam D. Barratt: On Tue, 2024-02-06 at 19:37 +0300, Michael Tokarev wrote: problematic upstream commit (on master) is this one: https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 Technically we already froze p-u for 12.5 on Sunday evening, as previously announced. If you could get an upload just fixing that single issue with a small change uploaded today then I'd be tempted to accept it anyway. Oh. I knew we're getting late, but not *that* late. The change isn't small per se, as the commit is rather large (mostly due to many changed tests, - it changes order of output in quite some places). Here's the diffstat: monitor/qmp.c | 17 + qapi/qmp-dispatch.c | 24 +--- tests/qemu-iotests/060.out|4 ++-- tests/qemu-iotests/071.out|4 ++-- tests/qemu-iotests/081.out| 16 tests/qemu-iotests/087.out| 12 ++-- tests/qemu-iotests/108.out|2 +- tests/qemu-iotests/109|4 ++-- tests/qemu-iotests/109.out| 78 +- tests/qemu-iotests/117.out|2 +- tests/qemu-iotests/120.out|2 +- tests/qemu-iotests/127.out|2 +- tests/qemu-iotests/140.out|2 +- tests/qemu-iotests/143.out|2 +- tests/qemu-iotests/156.out|2 +- tests/qemu-iotests/176.out| 16 tests/qemu-iotests/182.out|2 +- tests/qemu-iotests/183.out|4 ++-- tests/qemu-iotests/184.out| 32 tests/qemu-iotests/185|6 +++--- tests/qemu-iotests/185.out| 45 + tests/qemu-iotests/191.out| 16 tests/qemu-iotests/195.out| 16 tests/qemu-iotests/223.out| 12 ++-- tests/qemu-iotests/227.out| 32 tests/qemu-iotests/247.out|2 +- tests/qemu-iotests/273.out|8 tests/qemu-iotests/308|4 ++-- tests/qemu-iotests/308.out|2 +- tests/qemu-iotests/tests/qsd-jobs.out |4 ++-- 30 files changed, 173 insertions(+), 201 deletions(-) (as you can see, first two are the gist of it, the rest are the consequences). I'm including a complete revert of this single commit together with all the testsuite changes, ie, exactly as it is, - while the upstream testsuite isn't used in debian directly, it still works, and I'm running it right now locally just to be sure (though it definitely worked before that commit has been initially applied, so it should be okay). Presumably the bugs being fixed by that commit already exist in bookworm's qemu, so not including the commit isn't a regression? Yes, exactly, that's why I wrote about the status-quo. Please also attach a debdiff against the previous upload. Attached.diff -Nru qemu-7.2+dfsg/debian/changelog qemu-7.2+dfsg/debian/changelog --- qemu-7.2+dfsg/debian/changelog 2024-01-30 19:15:04.0 +0300 +++ qemu-7.2+dfsg/debian/changelog 2024-02-06 20:38:06.0 +0300 @@ -1,3 +1,12 @@ +qemu (1:7.2+dfsg-7+deb12u5) bookworm; urgency=medium + + * +revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch +Revert a single upstream change in 7.2.9 which, while fixed a few qemu +lockup bugs, introduced a regression in suspend-resume-hibernate cycle +(triggered by cryptsetup autopkgtest) + + -- Michael Tokarev Tue, 06 Feb 2024 20:38:06 +0300 + qemu (1:7.2+dfsg-7+deb12u4) bookworm; urgency=medium [ Michael Tokarev ] diff -Nru qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch --- qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch 1970-01-01 03:00:00.0 +0300 +++ qemu-7.2+dfsg/debian/patches/revert-monitor-only-run-coroutine-commands-in-qemu_aio_context.patch 2024-02-06 20:36:21.0 +0300 @@ -0,0 +1,1544 @@ +From 84a139b0289470994f8a518034d69186f5ad5bb9 Mon Sep 17 00:00:00 2001 +From: Michael Tokarev +Date: Tue, 6 Feb 2024 20:35:22 +0300 +Subject: [PATCH] Revert "monitor: only run coroutine commands in + qemu_aio_context" + +This reverts commit 8ec90598e922a604c222bdbc6289bed7279dced6. +Causes a regression at least in suspend-resume-hibernate cycle, +let's revert it to restore the status quo for now. +--- + monitor/qmp.c | 17 ++ + qapi/qmp-dispatch.c | 24 + + tests/qemu-iotests/060.out| 4
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
03.02.2024 12:47, Michael Tokarev wrote: It looks like we broke suspend/resume in this version of qemu. Oops. Is that related to the cryptsetup failure, or a separate issue? Yes, it is related to cryptsetup autopkgtest failure. It looks like this is the only place where suspend/resume code in qemu is actually being used, - it's rather rare to suspend (hybernate) a virtual machine, and cryptsetup performs testing of how the encrypted filesystem is unlocked (or not) on resume. So, while the problematic upstream commit fixes quite a few real potential qemu lockups, it introduces a new lockup in suspend- resume-hibernate cycle. The problem isn't understood yet, and we're getting close to the 12.5 release. The problematic upstream commit (on master) is this one: https://gitlab.com/qemu-project/qemu/-/commit/effd60c878176bcaf97fa7ce2b12d04bb8ead6f7 It has links to 2 bugs it is fixing, and there are quite a few other bugs which are fixed too. I can add a revert of this single commit (with all tests) for debian stable (for deb12u5 release) on top of current deb12u4. I think this would be best, despite the way it goes, - first the change is added in v7.2.9.diff, and next removed in a followup revert, - because this way we follow upstream releases, and this patch will be easy to remove in subsequent update. Alternatively we probably can ignore cryptsetup autopkgtest failure, but this smells somewhat wrong, I think it's better to restore the status quo for now, even in such a weird way (applying and reverting a patch). What do you think? Sure thing, if the solution will be found in a couple of days, I'll try to push that one instead, but it also depends on the complexity and possible risks there, and timeline. Thanks, /mjt
Bug#1056331: qemu-user-static: fails to run any binary with message "error while loading shared libraries" on Apple Silicon
An extra info. The same symptoms happen to show up on ppc64el host with 64Kb page size. Again, not saying page size is the reason, but it's still a good indication. /mjt
Bug#1056331: qemu-user-static: fails to run any binary with message "error while loading shared libraries" on Apple Silicon
Adding more info here. Asahi Linux, according to some docs, uses 16Kb page size. qemu-user does not have an MMU, and the worst combination is when host page size is larger than guest page size, which is what we have here. It just doesn't work, with all promises off. I'm not saying this particular failure is due to the page size differences, but it is a huge influencing factor. /mjt
Bug#1063162: please omit single initrd.img generation if dpkg trigger for all is pending
Source: initramfs-tools Severity: minor Currently, when installing other packages together with a new kernel, initramfs image for the new kernel is generated two times: once it is kernel-activated from /etc/kernel/postinst.d/initramfs-tools, and next it is dpkg-trigger-activated by updating certain paths (eg installing or upgrading busybox, mdadm, etc, which triggers initramfs rebuilds). This is especially annoying when building images for virtual machines (like debvm-create etc), - there, initramfs is especially slow (it is already very slow as it is, but makes several times slower when run in emulated environment). The whole thing needs to be generated only once, dpkg trigger should be enough, but it is actually generated twice. For that I suggest to check in /etc/kernel/postinst.d/initramfs-tools if dpkg trigger for it is pending already, and if yes, do not generate the whole thing but create just a stub, an empty /boot/initrd.img-$kver, to be updated later when dpkg trigger is fired. That will save a lot of time in various situations, including regular user machines where initrd is often regenerated multiple times during upgrades. Thanks, /mjt
Bug#1063149: [Pkg-samba-maint] Bug#1063149: "SyntaxWarning: invalid escape sequence '\s'" errors on updating
05.02.2024 14:51, Daniel Vacek: Setting up python3-samba (2:4.19.4+dfsg-3) ... /usr/lib/python3/dist-packages/samba/tests/dns_forwarder_helpers/server.py:80: SyntaxWarning: invalid escape sequence '\s' .. I guess this could be backported till new upstream version is packaged. This is a wontfix for now. I already did similar fix before for #1057668 (added a backported patch python-fix-invalid-escape-sequences.patch). These are just warnings, a minor annoyance, nothing more. Hopefully will be fixed by the next upstream version. /mjt
Bug#1063150: [Pkg-samba-maint] Bug#1063150: python3-samba: errors when executiong update-initramfs
05.02.2024 15:17, Erwan David: Package: python3-samba Version: 2:4.19.4+dfsg-3 Severity: normal When executing update-initramfs (triggered by a mdadm upgrade), I get following errors I don't see how update-initramfs uses samba. It should be a serious bug in initramfs-tools to touch python3-samba in any way. Please investigate how exactly update-initramfs tries to run python3-samba code, and file a bug there. /usr/lib/python3/dist-packages/samba/tests/dns_forwarder_helpers/server.py:80: SyntaxWarning: invalid escape sequence '\s' m = re.match(b'^timeout\s+([\d.]+)$', data.strip()) Speaking of invalid escape sequences, these are just warnings, will eventually be fixed in a subsequent update. The warnings are not due to samba bugs really but due to python changed its rules. I'm merging this bug with #1063149, and marking both as wontfix. Thanks, /mjt
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
03.02.2024 12:43, Adam D. Barratt : .. I'm aware of the autopkgtest failure with cryptsetup, working on it now. It looks like we broke suspend/resume in this version of qemu. Oops. Is that related to the cryptsetup failure, or a separate issue? Yes, it is related to cryptsetup autopkgtest failure. It looks like this is the only place where suspend/resume code in qemu is actually being used, - it's rather rare to suspend (hybernate) a virtual machine, and cryptsetup performs testing of how the encrypted filesystem is unlocked (or not) on resume. I already found the upstream commit which broke this (in all supported versions of upstream qemu, including master), dunno yet what to do with it, - trying to reduce the cryptroot test to some manageable minimum. It'd be sad to avoid updating of qemu due to this. But let's see.. Thanks, /mjt
Bug#1062044: qemu 7.2+dfsg-7+deb12u4 flagged for acceptance
01.02.2024 11:40, Adam D Barratt : .. Package: qemu Version: 7.2+dfsg-7+deb12u4 Explanation: new upstream stable release; irtio-net: correctly copy vnet header when flushing TX [CVE-2023-6693]; fix null pointer dereference issue [CVE-2023-6683] There's a typo here, should be virtio-net. I'm aware of the autopkgtest failure with cryptsetup, working on it now. It looks like we broke suspend/resume in this version of qemu. Thanks, /mjt
Bug#1061413: dependency not satisfiable in bookworm-backports
24.01.2024 04:41, TM wrote: Package: qemu-system-x86 Version: 1:8.1.2+ds-1~bpo12+1 Hello, This package seems to require[1] seabios >1.16.3-1, which is available in testing[2]. Indeed, you're absolutely right. I completely forgot this dependency. Uploaded seabios to bpo12 just now after this your bug report, it will be in NEW for manual processing since it's the first upload to bpo12. Meanwhile please download and install seabios 1.16.3-2 from testing, this is just a firmware (bios) binary with no dependencies whatsoever, and previous qemu will work with it too. This will let you to install current qemu. Thank you for the bug report. /mjt
Bug#1053128: This is Bug 15170 on bugzilla.samba.org
Control: found -1 2:4.19.4+dfsg-2 Control: tag -1 + confirmed upstream On Thu, 5 Oct 2023 20:46:25 +0400 Dmitry Telegin wrote: I found this bug in samba: Bug 15170 - smbtree seg fault if using -N option. https://bugzilla.samba.org/show_bug.cgi?id=15170 I checked this error in CentOS Stream 9 (samba 4.18.6-100.el9) - successfully reproduced. This is still happening with 4.19.4, fwiw. /mjt
Bug#1060175: qemu-system-i386: Display 'sdl' is not available.
08.01.2024 00:53, Thorsten Glaser : Michael Tokarev dixit: Gosh. Are you serious or is this some sort of a joke (it's not 1st April yet). I’m serious. This change has been made in version 1:2.12+dfsg-2 (Apr-2018), there's a news item about it. This same news item explains the reason and how to deal with it. Hmh, NEWS items are not shown when doing a fresh install on bullseye. And even then, searching for SDL case-insensitively in that file does not even show it. ... I see. You're coming from even older, pre-historic time than I thought :) Long time ago qemu-system had SDL UI as the only available local guest UI. Later on that one has been basically replaced with GTK - SDL were difficult to maintain and it didn't support most new things. But later on, in parallel to GTK, SDL2 UI has been introduced. That one hasn't been enabled in debian qemu for quite some time, because people complained about too much extra dependencies already for a headless install (qemu already pulled in lots of X11 stuff). Only after it has become possible to split whole UI display support into a separate package, so that main qemu-system does not depend on any graphics library, I enabled SDL2 display - now in *parallel* with GTK, and with GTK being the default (since this one is much more complete and has less bugs than SDL2). Sure you can request -display sdl explicitly, maybe only if there's some bug in gtk display and you want to check if it works better with sdl, - but qemu always had good default from the available options. All this is history still, for a few debian releases it is not relevant already. For a new install, qemu-system-foo Recommends qemu-system-gui package for a reason. If you disable installing recommends, you're supposed to at least check which packages it recommends before saying some feature is missing, - maybe it's in some recommends. You're the *first* person to complain about this since the split! :) BTW, in the current package in sid, I refined an old change (don't remember if it already was in bullseye or not) which suggests to install an additional package if a requested display is known but not available, like this: $ qemu-system-x86_64 -display sdl qemu-system-x86_64: Display 'sdl' is not available. Perhaps you want to install qemu-system-gui package? (for a few places, not just for display - or else it was spewing some errors due to missing other modules). Bullseye is definitely too old to add such changes though. /mjt
Bug#1060134: kmod-udeb vs busybox-udeb: agree on who ships depmod
06.01.2024 11:40, Helmut Grohne: On Sat, Jan 06, 2024 at 09:01:12AM +0100, Helmut Grohne wrote: I also recommend to establish QA for all udebs to automatically detect, report and address such conflicts as they evidently cause undefined behaviour otherwise. That can be as simple as collecting file lists of all udebs and comparing them. This seems like a more generic problem. I downloaded all amd64 udebs and the following files (normalized to account for aliasing) pose a conflict: From this list, only a few utilities are from busybox, namely wget and module utilities (depmod/insmod/lsmod/modinfo/modprobe/rmmod). My initial plan - with regular busybox package and with busybox udeb - is to provide most things in busybox, so that other packages don't need to ship udeb packages and the whole thing (be it d-i or initrd) is small. Yes, some utils in busybox aren't as good as regular implementations. For example, I just found out busybox's xz does not perform compression, only decompression (-d option is mandatory). Or #1003757 - missing functionality in busybox ip. Still, overall, it is enough for most things. BTW, it looks like with compressed kernel modules, busybox m-i-t needs some (albiet minor) tweaks (it works but kernel produces warnings when busybox tries to load a module). Unfortunately this didn't work out for one reason or another. One of the reasons is perhaps #921556, where original util does more than needed but busybox didn't implement the unnecessary functionality. This needs to be thought about at a more general level. Including initrd stuff (if we still need it, instead of relying on mkosi-initrd). I use my own initrd for a good reason, and this one does not include 2 or even 3 libc as debian does.. /mjt
Bug#1060005: cifs-utils: Copy file with cp, hangs with a kernel NULL pointer dereference.
Control: reassign -1 src:linux 6.1.69+1 04.01.2024 18:52, Eduardo Nunes: Package: cifs-utils Version: 2:7.0-2 Severity: normal X-Debbugs-Cc: eduardo.david.nu...@gmail.com Dear Maintainer, When copying a file between directories on same mount, the operation hangs with: BUG: kernel NULL pointer dereference, address: in RIP: 0010:cifs_flush_folio+0x3f/0x100 [cifs] Debian12 6.1.0-17-amd run as guest in VirtualBox 7.0.12 and the mounted share is on the host (Windows 10). Works as expected in the same configuration but with Debian11 5.10.0-27-amd64 as guest. It looks like we've regression in 6.1.69 (6.1.0-17) kernel update. There's at least one more report like this: https://forum.manjaro.org/t/manjaro-vmware-guest-copying-in-thunar-to-cifs-mounted-windows-locations-fails/153942/2 which also mentions 6.1.69 (and an update to 6.6+ fixed the issue). 6.1.69 had at least 3 cifs-related changes, and two of them look very interesting in this context: - cifs: Fix flushing, invalidation and file size with copy_file_range() - cifs: Fix flushing, invalidation and file size with FICLONE That's copy operation which fails now. Reassigning to linux package for now.. /mjt
Bug#1060052: cifs-utils: Copy file from same cifs mount to cifs mount --> kernel NULL pointer derefernce
Control: severity -1 normal Control: merge 1060005 -1 FWIW, this is kernel bug, not cifs-utils bug, - guess it's 6.1.0-17 regression. /mjt
Bug#609231: kvm: improper handling of commandline arguments
Version: 1:7.2+dfsg-1 On Wed, 12 Jan 2011 10:53:00 +0300 Michael Tokarev wrote: severity 609231 wishlist retitle 609231 filename parser in qemu chokes on colons tags 609231 + upstream confirmed thanks 07.01.2011 18:59, Michal Suchanek wrote: Package: qemu-kvm Version: 1:0.12.5+dfsg-5 Severity: normal Apparently kvm cannot handle CD images with odd names. While I don't insist that such image names should work it points at some bug in argument handling which is something to be avoided. .. The way to use "interesting" filenames do exist now. I don't know when exactly it has been introduced, but it sure exists in bookworm version. qemu-system-x86_64 -drive file.filename=a:b:c,,d,,e,media=cdrom .. When used with -cdrom (or -hda etc) shortcuts it doesn't work, one have to use more advance -drive argument. Not as -drive file=filename again, since colons (:) are interpreted as protocol delimiters, but as file.filename=filename. Commas still needs to be escaped. Closing this bug report now. /mjt
Bug#1052670: qemu: CVE-2022-36648
Control: forward -1 https://gitlab.com/qemu-project/qemu/-/issues/1851 Control: severity -1 normal On Mon, 25 Sep 2023 23:30:54 +0200 =?UTF-8?Q?Moritz_M=C3=BChlenhoff?= wrote: Source: qemu X-Debbugs-CC: t...@security.debian.org Severity: important Tags: security Hi, The following vulnerability was published for qemu. CVE-2022-36648[0]: | The hardware emulation in the of_dpa_cmd_add_l2_flood of rocker | device model in QEMU, as used in 7.0.0 and earlier, allows remote | attackers to crash the host qemu and potentially execute code on the | host via execute a malformed program in the guest OS. https://lists.nongnu.org/archive/html/qemu-devel/2022-06/msg04469.html This has later been revisited by upstream, setting up the new reference. See also https://www.mail-archive.com/qemu-devel@nongnu.org/msg984090.html /mjt
Bug#1054104: Use hardlinks in /usr/libexec/qemu-binfmt/ instead of symlinks
Control: tag -1 + moreinfo unreproducible So, based on the previous message in this bug, I don't know is expected from debian. Adding tags for now, will close this bug report if nothing comes back. /mjt
Bug#1059457:
27.12.2023 06:55, Brian Sammon : I fear that my bug report has sounded like a criticism or an argument. I apologize for that. Nope, I haven't interpreted your report as a criticism or argument (and I've nothing at all against a criticism either). Let me try to further describe my dilemma. I want to use qemu. I read the description of qemu-system-arm, and I believe that is a package that I want to use. The packager of qemu-system-arm appears to believe that I should use qemu-system-gui, since qemu-system-arm "recommends" qemu-system-gui. I've looked into qemu-system-gui, and I can't figure out what it does. Is it a VM-launcher app? Something else? Now I agree that I shouldn't be using a package that I don't understand. So how do I learn what qemu-system-gui is, so I can decide whether to follow the recommendation of qemu-system-arm and use it? If I can't understand what qemu-system-gui is, does that mean that I'm better off using qemu without qemu-system-gui? Let's use another example. qemu-system-arm recommends (or suggests, don't remember anymore, but let's assume it is Recommends) samba. The reason is that qemu can use samba in certain mode to share a directory on the host to the guest system it is running. Does this mean samba should carry a README explaining how it is used with qemu-system-arm? If qemu-system-gui package is already installed you can just look at the list of files contained in it, - the list gives a good hint. It should, - I hope anyway - be enough to read the description already. At the very least, almost no one looks at READMEs inside packages, but some do look at the descriptions, especially before installing something. Maybe the description should be improved a bit. Your question comes from the lack of understanding what qemu itself is and how to use it. https://www.qemu.org/docs/master/system/invocation.html#hxtool-3 is the part relevant to this context - qemu-system-gui provides sdl and gtk *modules* for qemu-system-* packages (and this is obvious from the list of files in the package). And no, I don't know how to use gui with qemu-system-arm. Many arm boards don't have standard VGA devices. /mjt
Bug#1058795: installing docker.io makes all qemu guests lose internet connection
On Sat, 16 Dec 2023 14:54:32 +0100 Wolfgang Rohdewald wrote: Package: docker.io Version: 20.10.24+dfsg1-1+b3 Severity: critical Justification: breaks unrelated software Dear Maintainer, * What led up to the situation? installed docker.io with existing qemu guests in bridge mode, did not do anything else. This seems to be because docker includes some firewall rules which does not play nice with existing firewall rules. For example, in my case I use nftables, and after docker.io is installed, I had to rmmod xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter in order to make my bridge working again. It isn't only qemu guests which are broken, it's everything connected to the host bridge besides the host itself, - eg nspawn containers. /mjt
Bug#1058029: qemu-guest-agent: QEMU-GA WON'T START
Control: tag -1 + moreinfo unreproducible 11.12.2023 14:51, Y : Package: qemu-guest-agent Version: 1:8.1.2+ds-1~bpo12+1 Severity: serious Justification: 6 Dear Maintainer, The problem arose after upgrading from bullseye to bookworm. What did you upgrade, host or guest system? All was OK on bullseye, but on bookworm qemu-ga refuse to start with following messages : 1702295113.963828: debug: disabling command: guest-get-devices 1702295113.963868: critical: error opening channel '/dev/virtio-ports/org.qemu.guest_agent.0': No such file or directory 1702295113.963873: critical: failed to create guest agent channel 1702295113.963875: critical: failed to initialize guest agent channel The systemd command looks like : [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 This is the standard qga systemd unit file. This unit file tells systemd to start qemu-ga *only* if /dev/virtio-ports/org.qemu.guest_agent.0 device is present. So it is either present and qga will start okay, or it is not present, and systemd wont start it. But not both. I can't reproduce this issue, everything looks and works like it is supposed to look and work. Also, there are *lots* of bullseye VMs and hosts has been upgraded to bookworm, and qemu-ga continues to work just fine. I've no idea what to get out of all this. /mjt
