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#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#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#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#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#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#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#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#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#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#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#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#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#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
Bug#1051661: /usr/bin/qemu-system-ppc: Package not installable
Control: reassign -1 dak 11.09.2023 08:40, Christian Marillat wrote: Package: qemu-system-ppc Version: 1:8.0.4+dfsg-3+b1 Severity: serious File: /usr/bin/qemu-system-ppc Dear Maintainer, sudo apt-get install qemu-system-ppc qemu-system-data ... The following packages have unmet dependencies: qemu-system-ppc : Depends: qemu-system-data (> 1:8.1.0+ds~) but 1:8.0.4+dfsg-3 is to be installed E: Unable to correct problems, you have held broken packages. I've no idea where the bug is, but it is definitely not in qemu. qemu-system-data has been built successfully on Saturday: https://buildd.debian.org/status/package.php?p=qemu (note q-s-d is Installed but it is not propagated to the archives by something in debian infrastructure). I asked on IRC in #debian-devel, #debian-buildd and #debian-ftp about this matter yesterday but there's no conclusive answers so far. I've been referred to #915948 and #887060. I've no idea if this is dak, buildd setup, ftp/archive building prob or something else. I'll upload new qemu release today with build-tests disabled, meanwhile please don't shot the messenger :) Short history of events. qemu source package Build-Depends-Arch on qemu-system-data these days, which is an arch-all package produced by the same source. So it is sort of cyclic dependency (though I allow any previous version of q-s-d to be used, not just the one from the same version). My thought was that since arch-all build is separate, it will complete and the results installed, which will allow all other, arch-any, buildds to use this arch-all package just fine. However first upload of 8.1.0-1 faced an issue with dh "helpfully" propagating CFLAGS (with newly added -fcf-protection) to arch-all build too, where it makes no sense and resulted in bios/firmware failing to build, hence 8.1.0-1 arch-all q-s-d build was unsuccessful. I fixed it up in subsequent uploads (which required de-dh'ifying of the whole thing which took me a while), and we're now in the situation at hand: buildds are waiting for q-s-d (which was dropped from the archives) to be available, it is built and installed by arch-all buildd, but making it available in archives is holding by lack of other qemu binary packages of the same version. I'm reassigning this to dak for now. Will wait for possible more answers for a few hours more, and will make an upload w/o tests if nothing is heard. Thanks, /mjt
Bug#1051536: qemu in bookworm FTBFS, missing B-D qemu-{alpha, powerpc, powerpc64, sparc64, hppa}-linux-gnu
Control: tag -1 + moreinfo unreproducible 09.09.2023 15:03, Mikhail Gusarov: Source: qemu Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: dotted...@debian.org Some cross-compilers are not available in bookworm, so qemu can't be built: $ sudo apt build-dep qemu Reading package lists... Done Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: builddeps:qemu : Depends: gcc-alpha-linux-gnu but it is not installable Depends: gcc-powerpc-linux-gnu but it is not installable Depends: gcc-powerpc64-linux-gnu but it is not installable Depends: gcc-sparc64-linux-gnu but it is not installable Depends: gcc-hppa-linux-gnu but it is not installable E: Unable to correct problems, you have held broken packages. Since when all these packages has become unavailable? They're available for a long time, and for sure available on bookworm and trixie too. I've an update for qemu for bookworm ready, submitted to bookworm-proposed-updates, which also built successfully (which is quite expected). Smells like something's wrong on your side. If you're trying to build stuff on an architecture where these packages are not available, - either file bugs with gcc, or stop building arch-all parts of qemu (apt build-dep --no-arch-any). /mjt
Bug#1050299: [Pkg-rust-maintainers] Bug#1050299: rust-webpki: RUSTSEC-2023-0052
09.09.2023 03:07, Peter Green: async-tls has not switched upstream. On the other hand I don't see any packages in Debian using it yet. ccing mjt to see what the reason for packaging it was. async-tls isn't my baby, count_omega (=werdahias, Cc'd) asked to sponsor it on Jun-28 and I uploaded it, that's all. Thanks, /mjt
Bug#1042171: imath: FTBFS: dh_install: error: missing files, aborting
On Sun, 13 Aug 2023 11:40:11 +0200 Aurelien Jarno wrote: .. The solution to fix this is to use PYIMATH_OVERRIDE_PYTHON_INSTALL_DIR to define the installation of the Python modules instead of relying on autodetection. Can't this be done at the cmake level instead of overriding this in each package? /mjt
Bug#1039710: debian-installer: Grub installation fails and /var/log/syslog is empty
Hi everyone! Somehow I missed this whole issue, - I didn't see it until now. Will adjust my mail filters. 08.08.2023 00:49, Philip Hands wrote: Steve McIntyre writes: On Wed, Jul 12, 2023 at 11:15:57AM +0200, Cyril Brulebois wrote: Hi Michael, Cyril Brulebois (2023-06-28): Control: reassign -1 busybox-udeb 1:1.36.1-3 […] With a local build, confirmed -3 is buggy, and that reverting only busybox-udeb to -1 is sufficient to restore syslog support in the installer. Reassigning there; the GRUB thing can be filed separately once we have actual information via syslog. A fix would be appreciated, we've got reports piling up about things we have no logs for. After weeks with this breakage, I've just uploaded a minimal NMU to fix it, reverting the syslog changes since -1. I've buit and tested successfully locally. It turned out whole syslog thing in busybox is quite broken, - this is obvious when you see my initial patch which started whole this issue. Later on upstream did it in a different way which broke whole thing entirely, which I tried to fix and it seemed to be working locally, I notified upstream about the breakage and moved on, thinking it's all set. But obviously it is not. Thanks -- and I agree, it works :-) https://openqa.debian.net/tests/178534/logfile?filename=DI_syslog.txt As it happens, over the weekend it occurred to me that I might be able to pave the way to a fix for this bug by coming up with a test for the failure. Awkwardly, syslogd wants to open /dev/log and bails out if it's already in use, so I resorted to (the somewhat disgusting hack of) using podman: https://salsa.debian.org/philh/busybox/-/commit/2697f7cce81d1a70de202a30e7062dc9f64a94b1 At least it allows syslogd to run well enough to succeed or fail similarly to the behaviour seen in the bug. Gosh.. Here it is going wrong with the -3 code: https://salsa.debian.org/philh/busybox/-/jobs/4523822#L3963 (lines 3969-3975, with the last line showing the entire syslog) and here is an example of it going right: https://salsa.debian.org/philh/busybox/-/jobs/4523808#L3668 Line 3668 here, saying "PASS: syslogd-works" indicates that we succeeded in grepping the test string in /var/log/syslog The difference between these two is simply disabling CONFIG_FEATURE_REMOTE_LOG, as seen here: https://salsa.debian.org/philh/busybox/-/commit/89c253f75690dd41487b6fd6f9356a1e890a6ac2 I'm not proposing that as a fix, but it does seem to indicate where the problem may be located. I'm afraid I've failed to work out what's actually going wrong here (my C's pretty rusty). BTW At one point I thought I'd narrowed it down to the while loop here: https://salsa.debian.org/philh/busybox/-/commit/328fdfbe43cd8d9e4425c3ee1c68aadfa44ee434 but if that did work, it does no longer. Either I was mistaken about it having worked earlier (I'm at least 80% sure that's not the case) or something non-deterministic is going on ... which makes me wonder if the underlying cause might be something to do with using uninitialised data somewhere. Hopefully this will be of some use to those more familiar with the code. Oh well. So much work for so minor thing.. :( I'm sorry for missing whole thing, I'd act right away and fix whole thing in a minutes. The whole thing is.. well, quite bad. We identified a few issues, upstream syslogd is entirely broken now, remote logging isn't that important and it has just been enabled, - the fix for now is to just disable remote logging and to revert to the previous-to-breakage situation as is done in the NMU (remote logging is a niche thing in this context, while it might be useful for sure - provided it actually works.) And ping upstream. The thing is that upstream will most likely fix it in a different way anyway, as Denys likes to keep it small even if the code becomes barely readable, and he has a few common practices which he uses when changing anything. Thank you all for all this huge work. Adding podman to the tests is.. oh well... /mjt
Bug#1036110: qemu-system-*: license conflict with libsasl2
15.05.2023 20:50, Michael Tokarev wrote: 15.05.2023 19:49, Bastian Germann wrote: the qemu-system-* binaries depends on libsasl2-2, which is licensed under CMU's BSD-3-Clause-Attribution license and covered by the RSA-MD license. They have clauses in place, which are known to be incompatible with GPL (as far as I can see the mentioned binaries' license). I'm not a licensing expert. Here's a personal opinion of one of the QEMU developers (and note this attribution, not advertising): mjt: mho clause 4 attribution is satisfied by simply always providing the full corresponding source tarball alongside the binary tarball, or by including the license file text in the binary dist the attribution clause looks unpleasant, but imho it is defanged by not giving any specific rules about /how/ you must attribute them the original BSD-4 clause was a serious problem because it specifically mentioned "All advertising materials mentioning features or use of this software" IOW, it proscribed a specific rule for how you must attribute (Just another point of view here). Also for the RSA-MD license (which has stronger attribution clause), the 4 files in cyrus-sasl which are covered by it should just be deleted and replaced with equivalent implementations which is done by everyone else. /mjt
Bug#1036110: qemu-system-*: license conflict with libsasl2
15.05.2023 19:49, Bastian Germann wrote: the qemu-system-* binaries depends on libsasl2-2, which is licensed under CMU's BSD-3-Clause-Attribution license and covered by the RSA-MD license. They have clauses in place, which are known to be incompatible with GPL (as far as I can see the mentioned binaries' license). I'm not a licensing expert. Here's a personal opinion of one of the QEMU developers (and note this attribution, not advertising): mjt: mho clause 4 attribution is satisfied by simply always providing the full corresponding source tarball alongside the binary tarball, or by including the license file text in the binary dist the attribution clause looks unpleasant, but imho it is defanged by not giving any specific rules about /how/ you must attribute them the original BSD-4 clause was a serious problem because it specifically mentioned "All advertising materials mentioning features or use of this software" IOW, it proscribed a specific rule for how you must attribute (Just another point of view here).
Bug#1036110: qemu-system-*: license conflict with libsasl2
Control: tag -1 + moreinfo Control: found -1 1:3.0+dfsg-1 15.05.2023 19:49, Bastian Germann wrote: Source: qemu Version: 1:7.2+dfsg-6 Severity: serious Hi, the qemu-system-* binaries depends on libsasl2-2, which is licensed under CMU's BSD-3-Clause-Attribution license and covered by the RSA-MD license. They have clauses in place, which are known to be incompatible with GPL (as far as I can see the mentioned binaries' license). There are several possible solutions to this problem: Can you be a bit more specific please, about the "known to be incompatible" part? Known to whom? Can this knowledge be shared? 1) Build without VNC SASL support. Just get rid of the Build-Dependency libsasl2-dev. 2) Support my request at #996892. 3) Ask upstream to add a license exception for libsasl2-2, similar to the one that was required by Debian for OpenSSL for a long time. Again, can you please provide a bit more context here, which exception are you talking about, exactly? Maybe some particular wording example? It's quite sad this issue has popped up this close to the release. This condition has been here forever, marking as found in 3.0 (arbitrary). Thanks, /mjt
Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x
So, we tried to reproduce it on a different machine at IBM. The problem doesn't show itself there. I asked the debian admin team to reboot zelenka into 5.10.0-20 kernel to verify, - there was no answer so far. So I'm leaving this as it is now. If the next kernel update will not fix the issue, I'll take another look at it. /mjt
Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x
In the build logs for libguestfs, I see last successful builds were done on 5.10.0-20-s390x kernel, and on 5.10.0-21-s390x, all builds fails. 5.10.0-21-s390x is the one running on zelenka too. It looks to me like a kernel issue.. /mjt
Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x
So, many previous versions behave the same, including bullseye. However. 1. I was able to create a 512-bytes qcow2 file once in /home/mjt on zelenka. And. 2. All versions always work fine in /tmp, on a tmpfs. Is it possible that the tests were running on a tmpfs before? /mjt
Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x
Control: tag -1 + help Control: found -1 1:5.2+dfsg-11+deb11u2 05.02.2023 20:30, Michael Tokarev wrote: .. The thing is: I can't find *any* working version of qemu-img, they all hang like described. This includes 1:7.2+dfsg-1+b1 too. There's more: I installed bullseye on zelenka, and tried this qemu-img command there (1:5.2+dfsg-11+deb11u2). It hangs exactly the same way. So it looks like this problem has been there for a very long time and no one noticed it. I don't know if qemu-system-s390x hang is due to this or different, - probably different issue. Now I need a reproducer for qemu-system-s390x hang :) /mjt
Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x
04.02.2023 23:48, Hilko Bengen wrote: .. Does 7.2+dfsg-1 work? I don't have s390x environment so have no way to deal with this one. No, it doesn't. On the porterbox (zelenka.debian.org) I was only able to install 1:7.2+dfsg-1+b1 without rebuilding. Oh, I forgot about zelenka. Tried that one yesterday. The last non-failing build before[1] also used 1:7.2+dfsg-1+b1, though. This made me think that the hang might be related to a shared library that had been updated since. It is interesting. On zelenka, I can run older versions of qemu-utils, from up to version 6.2 (haven't tried older, - it refer to older versions of liburing and libnettle). I d'loaded the .deb file from snapshot.d.o, extracted it in a local dir and run qemu-img from there. The thing is: I can't find *any* working version of qemu-img, they all hang like described. This includes 1:7.2+dfsg-1+b1 too. So I really wonder if it worked before. I also tried with a few versions of glibc, - also extracting them into a local folder and running with LD_LIBRARY_PATH pointing to it, -- the same issue, qemu-img hangs. [1] https://buildd.debian.org/status/logs.php?pkg=libguestfs=s390x yet, libguestfs definitely worked before. Do we perhaps have something else which broke in between? But I really wonder how it happen that 1:7.2+dfsg-1+b1 worked, and I can't reproduce it :) I'm about to add "found: 6.2" tag to this one :)) /mjt
Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x
04.02.2023 23:19, Hilko Bengen wrote: Package: src:qemu Version: 1:7.2+dfsg-2 .. qemu-img create -f qcow2 -o preallocation=metadata blank-disk-1s.qcow2 512 would hang in what appears a tight loop (100% CPU). Does 7.2+dfsg-1 work? I don't have s390x environment so have no way to deal with this one. Thanks, /mjt
Bug#1027166: rc.local should NOT depend on network-online or anything else
Package: systemd Version: 252.2-2~bpo11+1 Severity: serious I just come across a situation where my notebook does not let me in while I'm in a place where network is not available. This is entirely wrong. After a painful debugging session, I found the debian-shipped file /lib/systemd/system/rc-local.service.d/debian.conf , which adds dependency of rc.local for network-online. Found the commit which introduced this: commit 4a26840495a297e50283a1f8def090540d15042d Author: Martin Pitt Date: Mon Jun 1 15:56:45 2015 +0200 Make rc-local.service wait for network-online.target (if it gets started) Add debian/extra/units/rc-local.service.d/wait-online.conf. This not specified by LSB, but has been behaving that way in Debian under SysV init and upstart. LP: #1451797 and found the original bugreport from 2015, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1451797 (and a new one filed in 2021, https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950906 ). On all systems, rc.local is empty by default (or doesn't exist), so it does not depend on anything at all. Only the user who modifies this file *locally* knows which dependencies are required, and this user can add their own /etc/systemd/system/rc-local.d/whatever.conf with the right deps, if needed. Adding *any* dependencies by default is entirely, utterly wrong. This way, you force completely innocent, unsuspecting people who used to put some quick thing into their rc.local to suffer from being unable to login. It definitely should not be done for all. Yes, I know rc.local is a workaround. But please don't make this workaround completely wrong. *Sigh*. Thanks, /mjt
Bug#1026387: samba-ad-provision: missing Breaks+Replaces: samba (<< 2:4.17.3+dfsg-4)
19.12.2022 16:32, Michael Tokarev wrote: .. Aargh. This is due to my attempts to upload security update without waiting for the NEW processing. It *had* proper Breaks+Replaces, but I removed it all in an attempt to clean up new package introduction. Actually it's a lie, it has nothing to do with that, it's plain stupid bug on my side. Fixed now. /mjt
Bug#1026387: [Pkg-samba-maint] Bug#1026387: samba-ad-provision: missing Breaks+Replaces: samba (<< 2:4.17.3+dfsg-4)
19.12.2022 14:29, Andreas Beckmann wrote: Package: samba-ad-provision Version: 2:4.17.3+dfsg-4 Severity: serious User: debian...@lists.debian.org Usertags: piuparts Hi, during a test with piuparts I noticed your package fails to upgrade from 'testing'. It installed fine in 'testing', then the upgrade to 'sid' fails because it tries to overwrite other packages files without declaring a Breaks+Replaces relation. Aargh. This is due to my attempts to upload security update without waiting for the NEW processing. It *had* proper Breaks+Replaces, but I removed it all in an attempt to clean up new package introduction. Meanwhile, it has been accepted, and I re-did it again. And apparently missed this part. Sigh. Thank you! /mjt
Bug#1026213: login: $HOME created as 0755 by default
On Fri, 16 Dec 2022 11:50:18 + debian user wrote: Package: login Version: 1:4.13+dfsg1-1 Severity: grave Tags: security Justification: user security hole X-Debbugs-Cc: r...@localhost.lan, Debian Security Team Dear Maintainer, please uncomment the line in /etc/login.defs that currently says: #HOME_MODE 0700 to say: HOME_MODE 0700 The current settings makes user $HOME directories be created with permissions where other users can read the contents by default. I tend to disagree, the default is just fine, all the sensitive data (eg, .bash_history, .ssh/ etc) is already protected, there's absolutely nothing wrong if the files in home dirs are accessible by default, - for example my users complain if they can't show content of their own files to other users by default. On the other hand, it is trivial to uncomment the HOME_MODE setting locally if the local policy is that users should be paranoid against each other. It is just as easy to set perms of your own home dir at any time, too. /mjt
Bug#1024852: nvidia-driver in bullseye (470.141.03-1~deb11u1) and bullseye-backports (470.103.01-1~bpo11+1) do not support Linux kernel 6.0 or later
On Sat, 26 Nov 2022 12:43:12 -0800 Alex Relis wrote: Package: nvidia-driver Version: 470.103.01-1~bpo11+1 Severity: grave Justification: renders package unusable Dear Maintainer, About a week ago, linux-image-6.0.0-0.deb11.2-amd64 was introduced in bullseye-backports. The problem is that the nvidia-driver version in both bullseye (470.141.03-1~deb11u1) and bullseye-backports (470.103.01-1~bpo11+1) (for some reason, the version in bullseye is newer which is strange) DO NOT support Linux kernel 6.0. When a user who uses a backported linux kernel and nvidia-driver upgrades their system, they will get an error message that looks like this https://imgur.com/sEVx1vc (sorry if I couldn't give you the text output; I am reporting this on behalf of a friend) This issue is reproducable and happened on two of my friends' machines. We found a current workaround that involves booting to kernel 5.1x in the Grub menu, running sudo apt purge linux-image-6.0.0-0.deb11.2-amd64 && sudo apt install -t bullseye-backports nvidia-driver && sudo reboot now. So what is the proposal there? Just do not install 6.0 kernel from backports if you need nvidia driver? According to this Phoronix article ( https://www.phoronix.com/news/NVIDIA-515.76-Linux-Driver ), nvidia-driver 515.76 or newer support Linux kernel 6.0. I believe the solution is to upgrade nvidia-driver to 515.76 or newer in bullseye-backports so that users can use their graphics card on kernel 6.0. As you state yourself, this bug is already fixed in the more recent version of the package. Why are you a) filing a bug which is already fixed in Debian, and b) why are you filing it against the bpo version of the package? It is like installing this version of driver breaks system. (especially since apt will not install this version, since a more recent version is available in bullseye already). It is a very questionable bug report, and for me as a maintainer (not of this package though) it discourages me from doing more backports (just a personal opinion/feeling). /mjt
Bug#1023654: liburing 2.3 breaks binary compatibility
08.11.2022 17:50, Michael Tokarev wrote: 08.11.2022 17:11, Guillem Jover wrote: [..] If you are really seeing samba linked against old liburing not working with the new liburing, then we'd need to dig further to see what else might be missing, but I'm currently not seeing it just by a very quick code staring. Well. I already deleted my test chroot. I can't say for 100% now that it breaks the other way around. I'll have to double-check. It took me quite quite some time especially due to other urgent things I'm doing today. I can check if 2.2-compiled samba works with 2.3-uring but a bit later today. Even if it works, it is not exactly conclusive, since samba only uses certain code paths. But ofc if it doesn't work, it *is* conclusive :) Ok, I double-verified this: samba compiled against older liburing works with liburing 2.3 after upgrading liburing2 package. So it must be just me being too tired when debugging all this. So it appears to be backwards- compatible (non-conclusive! ;)), just needs new lib for newly compiled programs. It's a rare case really, because of the rather heavy usage of inline functions for access, - so parts of the library are actually compiled into the program, and now you've more pieces to keep in sync. It's an interesting case really. Thank you! /mjt
Bug#1023654: liburing 2.3 breaks binary compatibility
08.11.2022 16:44, Guillem Jover wrote: Hi! On Tue, 2022-11-08 at 16:32:25 +0300, Michael Tokarev wrote: On Tue, 08 Nov 2022 15:51:17 +0300 Michael Tokarev wrote: Source: liburing Version: 2.3-1 Severity: grave liburing 2.3 broke binary compatibility without bumping the soname. Indeed. :/ Should make a habit of checking the header diffs, as this is not the first time this has happened. Actually this is interesting. Maybe it would be better for me to just wait till new liburing migrates to testing, and re-run samba autopkgtests, instead of filing this bugreport... (Provided it works the other way around, which I'm not sure about yet). /mjt
Bug#1023654: liburing 2.3 breaks binary compatibility
08.11.2022 17:11, Guillem Jover wrote: [..] If you are really seeing samba linked against old liburing not working with the new liburing, then we'd need to dig further to see what else might be missing, but I'm currently not seeing it just by a very quick code staring. Well. I already deleted my test chroot. I can't say for 100% now that it breaks the other way around. I'll have to double-check. It took me quite quite some time especially due to other urgent things I'm doing today. I can check if 2.2-compiled samba works with 2.3-uring but a bit later today. Even if it works, it is not exactly conclusive, since samba only uses certain code paths. But ofc if it doesn't work, it *is* conclusive :) Thanks, /mjt
Bug#1023654: liburing 2.3 breaks binary compatibility
On Tue, 08 Nov 2022 15:51:17 +0300 Michael Tokarev wrote: Source: liburing Version: 2.3-1 Severity: grave liburing 2.3 broke binary compatibility without bumping the soname. In liburing.h in 2.3, structures io_uring_cq and io_uring_sq changed their sizes. Both of these structures are parts of io_uring structure which the main part of the API. Here's the difference: @@ -43,7 +79,9 @@ @@ -56,13 +94,18 @@ size_t ring_sz; void *ring_ptr; - unsigned pad[4]; + unsigned ring_mask; + unsigned ring_entries; + + unsigned pad[2]; This does not look like it is changing the size actually, - I haven't noticed it adjusts pad[] accordingly. So this is not the issue here. But the end result is the same: samba compiled with liburing 2.2 does not work with runtime liburing 2.3, and samba compiled with liburing 2.3 does not work with runtime liburing 2.2. I'm just too tired now to dig further. /mjt
Bug#1023654: liburing 2.3 breaks binary compatibility
Source: liburing
Version: 2.3-1
Severity: grave
liburing 2.3 broke binary compatibility without bumping the soname.
In liburing.h in 2.3, structures io_uring_cq and io_uring_sq changed
their sizes. Both of these structures are parts of io_uring structure
which the main part of the API. Here's the difference:
@@ -43,7 +79,9 @@
struct io_uring_sq {
unsigned *khead;
unsigned *ktail;
+ // Deprecated: use `ring_mask` instead of `*kring_mask`
unsigned *kring_mask;
+ // Deprecated: use `ring_entries` instead of `*kring_entries`
unsigned *kring_entries;
unsigned *kflags;
unsigned *kdropped;
@@ -56,13 +94,18 @@
size_t ring_sz;
void *ring_ptr;
- unsigned pad[4];
+ unsigned ring_mask;
+ unsigned ring_entries;
+
+ unsigned pad[2];
};
...
struct io_uring {
struct io_uring_sq sq;
struct io_uring_cq cq;
...
}
So, a program which uses struct io_uring compiled with version 2.2 of the
library is completely incompatible when run with version 2.3 of the library,
and vise versa - since many user-visible members of this structure, even when
manipulated by the inline functions offered by uring.h, are completely
incompatible.
This breaks other software. For example, samba compiled against liburing 2.3
will silently break when liburing 2.2 is used at the run time, and there's no
way for apt/dpkg to tell that liburing2.so upgrade is needed. The same way,
samba compiled against liburing 2.2 breaks when liburing is upgraded to 2.3,
but in a different way.
Bug#1023501: busybox-static: version 1:1.35.0-3 breaks boot on hppa
Control: tag -1 + confirmed On Sat, 5 Nov 2022 21:18:58 +0100 Robert Luberda wrote: severity 1023501 grave retitle 1023501 busybox-static: version 1:1.35.0-3 breaks boot on hppa and amd64 found 1023501 1:1.35.0-3 notfound 1023501 1:1.35.0-2 On Sat, 05 Nov 2022 13:31:51 + John David Anglin wrote: > Package: busybox-static > Version: 1:1.35.0-2 > Severity: normal > > Dear Maintainer, > > With 1:1.35.0-3, boot ends in initramfs: > > Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. > Begin: Running /scripts/local-premount ... done. > Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... mdadm: No arrays found in config file or automatically > done. > Begin: Running /scripts/local-block ... mdadm: No arrays found in config file or automatically > > > > - Missing modules (cat /proc/modules; ls /dev) > > ALERT! LABEL=ROOT2 does not exist. Dropping to a shell! I had the same issue on amd64. Removing mdadm package did not help. Downgrading busybox-static to 1.35.0-2 fixed the issue. Now this is interesting. In -3, I included these changes: commit ac478f88b64d5884d5e81bcd8f8344f0ec72df6a Author: Michael Tokarev Date: Mon Oct 17 12:52:23 2022 +0300 deb,static: enable blkid applet (useful for rescue purposes) commit d371992b4a0394f02cd29cb9cb946080414f8afb Author: Michael Tokarev Date: Mon Oct 17 13:00:16 2022 +0300 deb,static: enable findfs applet (useful for rescue purposes) Both really are useful for rescue purposes, I've hit this - the lack of blkid and findfs in busybox - several times, and finally decided to enable them.. It's a minimal version, it can help in many situations. But it turns out debian initramfs generator includes its own blkiid, which is more advanced than busybox's. For regular (non-static) build, busybox adds links to itself for applets it have but which aren't provided by other tools already. However, for the static build, it has CONFIG_PREFER_APPLETS=y (in order to be more useful when the filesystem is damaged/incomplete), so it ignores external implementation of these utilities. And we end up in this situation. And for the static build, it is even more interesting to have these utils available. *sigh* I'll disable one of them for -static build for now, to work around this issue (have to check which one is to blame, most likely blkid). But.. *sigh* :) Thanks, /mjt
Bug#1013259: samba-libs: Possible policy violation (now with libndr.so.2 => libndr.so.3)
Hmm. Other sssd packages are also affected by this. Not only sssd-ad but sssd-ipa and sssd-ad-common. Added the Breaks for these in Bullseye (and also in Ubuntu Jammy, which has exactly the same problem). Will be in the next upload. /mjt
Bug#1013259: samba-libs: Possible policy violation (now with unnecessary soname bump libndr.so.2 => libndr.so.3)
01.11.2022 13:14, Ralph Boehme wrote: On 11/1/22 09:15, Michael Tokarev via samba-technical wrote: Control: tag -1 + upstream Original context was at http://bugs.debian.org/1013259 , but whole thing *now* has is about completely unnecessary soname bump of libndr in 4.17 due to debugging refinements. to me this looks like a packaging bug. It indeed is, I fixed it already. The question remains though: why the .3 bump happened in the first place, due to a change just in a debug helper routine, which was trivial to avoid (like I've shown in the patches just posted to the list). The problem here is that there are just too many interdependencies between various libraries, and to me anyway, it is important to keep sonames when possible (and easy to do like in this case!). For example: libndr.so NEEDED libgenrand-samba4.so which is an internal samba library. So you can't easily provide *two* libndr.so.2 and libndr.so.3 on the system, unless you *also* install two different sets of internal libs. So on any soname bump, a real recompile of all users is needed. That's the reason to be more careful when doing soname bumps.. Thanks, /mjt
Bug#1013259: samba-libs: Possible policy violation (now with unnecessary soname bump libndr.so.2 => libndr.so.3)
Control: tag -1 + upstream Original context was at http://bugs.debian.org/1013259 , but whole thing *now* has is about completely unnecessary soname bump of libndr in 4.17 due to debugging refinements. 01.11.2022 11:07, Michael Tokarev wrote: 01.11.2022 10:59, Michael Tokarev wrote: .. And this revealed one more issue here, now with samba 4.17. Where, the same libndr.so again, has changed soname from libndr.so.2 to libndr.so.3! And it looks like *this* is what you're talking about now, once 4.17 with this new libndr.so.3 hits unstable. *Sigh*. So now, samba-libs breaks not only bullseye sssd-ad, but also *bookworm* sssd-ad! So: samba-libs 4.13: libndr.so.1 samba-libs 4.15: libndr.so.2 samba-libs 4.17: libndr.so.3 and this is what we're facing now, 4.16=>4.17 update breaks things again. and this new breakage went unnoticed, and I knew nothing about the soname change before this very moment. Andrew, can you share some info about the new 2=>3 soname bumb in 4.17? I wonder if we should provide old libndr.so.1 and libndr.so.2 interface in samba-libs forever... this shouldn't be that difficult. This has come in 7b9f87b877bd385e8cec893cd282d4b3fc00206d: Author: Pavel Filipenský Date: Wed Jun 22 11:13:34 2022 +0200 librpc:ndr: Update ndr_print_debug() and add macro NDR_PRINT_DEBUG_LEVEL Bumping the ABI to 3.0.0 This is enhancement of NDR_PRINT_DEBUG macro with following new features: * debug level can be specified (NDR_PRINT_DEBUG always uses level 1) * the trace header shows the location and function of the caller instead of function 'ndr_print_debug', which is not really useful. Signed-off-by: Pavel Filipenský Reviewed-by: Andreas Schneider Is it not possible to keep the soname after this change? I'm reviewing the changes now.. And it is/was definitely possible and was even trivial to do. The only real change there is: -void ndr_print_debug(ndr_print_fn_t fn, const char *name, void *ptr); +bool ndr_print_debug(int level, ndr_print_fn_t fn, const char *name, void *ptr, const char *location, const char *function); In order to avoid soname bump, a new function should be created, say, ndr_print_debug_level(), with a new signature, and old function will become a trivial wrapper around the new one. This way, only the single new signature should be added to the ABI file, and that's it. C'mon... there's really no reason to bump the soname just to refine debugging output.. I can produce a patch to do just that, so the ABI will become compatible with previous releases. But what to do with samba-4.17.[012] which were released with libndr.so.3 already? I'll sure revert this patch to librpc/ABI/ in Debian (after refining the ndr_print_debug stuff)... Anyway, I'll submit both changes, and let's see how it goes. Thanks, /mjt
Bug#1013259: [Pkg-samba-maint] Bug#1013259: samba-libs: Possible policy violation (now with libndr.so.2 => libndr.so.3)
01.11.2022 10:59, Michael Tokarev wrote: .. And this revealed one more issue here, now with samba 4.17. Where, the same libndr.so again, has changed soname from libndr.so.2 to libndr.so.3! And it looks like *this* is what you're talking about now, once 4.17 with this new libndr.so.3 hits unstable. *Sigh*. So now, samba-libs breaks not only bullseye sssd-ad, but also *bookworm* sssd-ad! So: samba-libs 4.13: libndr.so.1 samba-libs 4.15: libndr.so.2 samba-libs 4.17: libndr.so.3 and this is what we're facing now, 4.16=>4.17 update breaks things again. and this new breakage went unnoticed, and I knew nothing about the soname change before this very moment. Andrew, can you share some info about the new 2=>3 soname bumb in 4.17? I wonder if we should provide old libndr.so.1 and libndr.so.2 interface in samba-libs forever... this shouldn't be that difficult. This has come in 7b9f87b877bd385e8cec893cd282d4b3fc00206d: Author: Pavel Filipenský Date: Wed Jun 22 11:13:34 2022 +0200 librpc:ndr: Update ndr_print_debug() and add macro NDR_PRINT_DEBUG_LEVEL Bumping the ABI to 3.0.0 This is enhancement of NDR_PRINT_DEBUG macro with following new features: * debug level can be specified (NDR_PRINT_DEBUG always uses level 1) * the trace header shows the location and function of the caller instead of function 'ndr_print_debug', which is not really useful. Signed-off-by: Pavel Filipenský Reviewed-by: Andreas Schneider Is it not possible to keep the soname after this change? I'm reviewing the changes now.. /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
Ok. This package appears to lack some love. Bugs are never closed (I just closed a few bugreports which were fixed years ago), migration status apparently is never checked, bugs actually are not watched/handled (these 2 bugs are here for quite some time already). I pinged the maintainer but he didn't respond. I just uploaded virglrenderer package with current issues fixed, so things can be unblocked. Longterm, I'm fine to move this package under qemu umbrella (especially since it is relevant mostly for qemu these days). Thanks, /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
According to the FAQ at
https://people.freedesktop.org/~dbn/pkg-config-guide.html#faq :
My library z uses libx internally, but does not expose libx data types in its
public API.
What do I put in my z.pc file?
Again, add the module to Requires.private if it supports pkg-config. In this
case,
the compiler flags will be emitted unnecessarily, but it ensures that the
linker
flags will be present when linking statically.
So it is a common practice to add stuff to Requires.private, and it is not a
good idea
to ask upstream not to do that. With meson (as it is a case here), it
generates this
Requires.private automatically.
So it looks like removing this tag at install time is the way to go after all,
unless meson grows an easy way to omit these.
An alternative is to maintain "proper" Depends for the foo-dev package.
("proper" is in quotes, because it is only needed to satisfy pkg-config
wishes).
*sigh*.
/mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
18.10.2022 09:41, Michael Tokarev wrote: .. At least once I come across a case where pkgconfig --cflags were actually needed - because this library's header file actually included some other header file. And iirc, it was an upstream bug, the dependency should have been listed as non-private-something in the .pc file. /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
18.10.2022 00:17, Michael Biebl wrote: .. Patching the upstream provided .pc file in Debian feels odd, tbh. Are you sure Requires.private is only relevant for static linking? Isn't this what Libs.private is for. Yes it feels odd indeed. The problem here is often due to lack of understanding how the .pc files work, which parts should go where. Myself I don't know either how it should be done. I asked about this several times in different places but each time the answers were different. So I ended up working in case-by-case basis: when a .pc file gets new Libs.private or Requires.private, I evaluate how this new library is actually being used, - and in all cases so far it was entirely internal thing not exposed in any way to the users of the said library, *unless* we want static linking (where regular debian shlib mechanism does not work, obviously). Here's just one example of this in one of my packages: https://salsa.debian.org/qemu-team/spice/-/blob/master/debian/rules#L31 (this one comes from #803926) Neither includes nor dynamic libs are needed to build stuff with libsamba-server, the only case where it's needed is when we try to build something statically, so that all libraries used by (non-existing by now) libspice-server.a are needed during link time. At least once I come across a case where pkgconfig --cflags were actually needed - because this library's header file actually included some other header file. 18.10.2022 05:27, Adrian Bunk wrote: > The same command with all packages installed outputs: > > $ pkg-config --cflags virglrenderer > -I/usr/include/virgl -I/usr/include/libdrm > $ > > This would be required if headers under /usr/include/libdrm were > included by /usr/include/virgl/virglrenderer.h, but that isn't > the case. Exactly. And this is the case in many other situations too (eg my spice example above). In this very case, all extra dependencies are config-time stuff internal to virglrenderer, it does not change abi/api of its users. It is just that virglrenderer will be able (or not) to use extra features when asked. Even the header files with available options aren't being generated at build time, - it will return ENOSYS-like error at runtime when asked for an optional feature which is not compiled in. The interface of the library does not change in any way. I just don't know how it *should* be done. Maybe pkgconfig should not insist on something.private when asked for cflags? Thanks, /mjt
Bug#1019485: libvirglrenderer-dev should depend on libva-dev
16.10.2022 08:04, Adrian Bunk wrote: ... With 0.10.3-1 vulkan is a new requirement, breaking the qemu build again: https://buildd.debian.org/status/fetch.php?pkg=qemu=amd64=1%3A7.1%2Bdfsg-2%2Bb1=1665894634=0 The complete list is currently: $ pkg-config --cflags virglrenderer Package epoxy was not found in the pkg-config search path. Perhaps you should add the directory containing `epoxy.pc' to the PKG_CONFIG_PATH environment variable Package 'epoxy', required by 'virglrenderer', not found Package 'libdrm', required by 'virglrenderer', not found Package 'gbm', required by 'virglrenderer', not found Package 'vulkan', required by 'virglrenderer', not found Package 'libva', required by 'virglrenderer', not found Package 'libva-drm', required by 'virglrenderer', not found $ In practice, most/all of the -dev build dependencies also have to become dependencies of libvirglrenderer-dev. Actually this is an interesting question and a quite common issue. This package does not provide a static library. All the mentioned packages are listed in Requires.private pkgconfig tag: Version: 0.10.3 Requires.private: epoxy >= 1.5.4, libdrm >= 2.4.50, gbm >= 0.0.0, x11, vulkan, libva, libva-drm The thing is: these are needed by a static-link library (dynamic .so libs are already handled by debian package dependencies). They're not used when building other software with libvirglrenderer. It is only pkg-config which fails to find them, for actual usage these are not needed. I used to remove Requires.private: tags from the .pc files in such cases, entirely, because it makes no sense in this context. And it makes build just a bit faster too. But indeed, many maintainers tend to add lots'a stuff to Depends. I'd remove the Requires.private here as well. What do you guys think? /mjt
Bug#1021371: gnome-control-center doesn't start, saying libsamdb-common.so.0 requires version `LDB_2.2.4'
07.10.2022 18:53, Simon McVittie wrote:
On Fri, 07 Oct 2022 at 18:08:41 +0300, Michael Tokarev wrote:
In debian samba package, there's a strict versioned dependency of libldb2
for samba package - actually samba-dsdb-modules - the only package which
actually *uses* libldb.
I'm not sure that's completely accurate? ldb-tools, python3-ldb,
python3-samba, samba, samba-libs, etc. also depend on libldb2 (perhaps
with more -Wl,--as-needed they wouldn't, I haven't looked at whether they
actually reference symbols from libldb2).
What I mean is that most of these only use a few common entry points of
libldb which does not change much and for which symvers mechanism provides
good results. Except of particular situation with this very version at hand.
Outside the samba source package, several binaries from src:sssd also
have dependencies on libldb2, although again I haven't checked whether
they actually reference individual symbols or whether they just have an
unnecessary DT_NEEDED entry.
sssd is one more package which uses libldb "heavily".
The problem here and with samba-dsdb-modules is that both provides *plugins*
for libldb, and we don't have a mechanism similar to symvers for plugins.
But it looks like other samba packages does have libldb2 dependency.
It looks like I need to take a look at how libldb2 is used by samba-libs,
maybe some libs should be moved between packages.
The reason I like using debian/shlibs.local for this, instead of
explicitly writing out "libldb2 (= ${binary:Version})" in d/control,
is that it's automatic: every time one of your binary packages picks up
a dependency on libldb2 from ${shlibs:Depends}, it will *automatically*
be a strictly versioned dependency. Even if you've split libraries between
binary packages in a way that didn't really match what you intended (like
if you didn't intend for samba-libs to depend on libldb2 at all), the
failure mode is that there's a strict dependency (possibly unnecessary,
but never wrong) rather than a loosely-versioned dependency (which can
result in making mismatches possible).
Only particular packages needs strict deps, there's no need to depend
on exact version for other packages.
I make as many mistakes as anyone else, so I like to use tools that will
prevent unintended situations from happening :-)
the dependency is
libldb2 (<< 2:2.2.4~), libldb2 (>= 2:2.2.3-2~deb11u2~)
(so it conflicts even with next minor version of libldb2)
If both the packages are Architecture: any, then I don't think there's
a particularly good reason to use this version-range style with (>=)
and (<<) - you might as well just eliminate all flexibility by using
(= ${binary:Version}), since libldb2:amd64 (= x) is going to be available
if and only if samba-dsdb-modules:amd64 (= x) is also available. After all,
they both came out from the same sbuild run and got installed in the
archive by the same .changes file...
Or if you're doing tricky things with different versions for different
binary packages, as with libldb2, it seems better to represent that as
an exact dependency on "the version of libldb2 that was produced by this
exact build of src:samba".
This is only needed for samba-dsdb-modules (and in parts for sssd - it
uses only a subset of libldb plugins functionality which seems to be
mroe or less stable).
And once again, I just moved libldb to build from samba source, before
it used its own source package.
On Fri, 07 Oct 2022 at 18:19:34 +0300, Michael Tokarev wrote:
With debian bullseye version of samba things are even more interesting.
This is because ldb-2.2.4 has never ever been released to begin with.
It was a bugfix within 4.13 series of samba - backported to 4.13 samba
long after 4.13 has been end-of-lined. The actual symbols in ldb are
present in 4.16 (ldb 2.5.x), but not 2.2.4 version.
And actually it brings a new question. When we upgrade a library in a
stable debian release, and this upgrade brings new symbol version, but
already existing version of this library in testing does not have this
version.. what do do? Should we omit the version bump in the stable
series?
This is quite a weird situation to be in, and I would tend to say that
upstreams that track their public ABIs this carefully (or their downstream
maintainers, if it was Debian that did this backport) should generally
not be backporting new ABI to stable-branches at all. Several of the
upstreams I follow have a fairly strict policy of stable-branches not
adding new ABI *at all*, not even for bug fixes. However, I realise that's
not necessarily always possible.
Existing ABI in the library did not let a significant security issue to
be fixed, - new symbol had to be introduced (actually several), and samba
switched to use these new symbols. And those new symbols has been backported
to old samba version by the upstream. Once again, in bullseye, libldb is
built by its own source package.
Maybe we did it
Bug#1021371: gnome-control-center doesn't start, saying libsamdb-common.so.0 requires version `LDB_2.2.4'
07.10.2022 18:08, Michael Tokarev wrote: ... Removing the symver LDB_2.2.4 from libldb.so.2 was an ABI break, so libldb2 should have versioned Breaks against dependent packages that use the old symver. It looks as though only the samba and maybe sssd source packages will be affected by this. I talked about this with upstream samba. It is their decision to break old stuff like this, by dropping intermediate library versions without actually changing any functions/symbols. I don't know why this is done like that, from my PoV it is plain wrong. With debian bullseye version of samba things are even more interesting. This is because ldb-2.2.4 has never ever been released to begin with. It was a bugfix within 4.13 series of samba - backported to 4.13 samba long after 4.13 has been end-of-lined. The actual symbols in ldb are present in 4.16 (ldb 2.5.x), but not 2.2.4 version. And actually it brings a new question. When we upgrade a library in a stable debian release, and this upgrade brings new symbol version, but already existing version of this library in testing does not have this version.. what do do? Should we omit the version bump in the stable series? /mjt
Bug#1021371: gnome-control-center doesn't start, saying libsamdb-common.so.0 requires version `LDB_2.2.4'
Control: tag -1 + confirmed
07.10.2022 11:38, Simon McVittie wrote:
...
# smbclient --help
smbclient: /usr/lib/x86_64-linux-gnu/libldb.so.2: version `LDB_2.2.4' not found
(required by /usr/lib/x86_64-linux-gnu/samba/libsamdb-common.so.0)
Workaround: also upgrade samba-libs to the version from testing, or fully
upgrade to testing.
Removing the symver LDB_2.2.4 from libldb.so.2 was an ABI break, so libldb2
should have versioned Breaks against dependent packages that use the old
symver. It looks as though only the samba and maybe sssd source packages
will be affected by this.
I talked about this with upstream samba. It is their decision to break old
stuff like this, by dropping intermediate library versions without actually
changing any functions/symbols. I don't know why this is done like that,
from my PoV it is plain wrong.
When I packaged 4.17 version (currently in experimental), I created a patch
which adds missing intermediate versions (added during maintenance of 4.16
series) to 4.17, but later on dropped it. It will be the same with 4.16->
4.17 upgrade. See
https://salsa.debian.org/samba-team/samba/-/commit/363ec9c9cf107536b94bfd0d5bd623644413b165
In debian samba package, there's a strict versioned dependency of libldb2
for samba package - actually samba-dsdb-modules - the only package which
actually *uses* libldb. For a bullseye version of samba-dsdb-modules
package, the dependency is
libldb2 (<< 2:2.2.4~), libldb2 (>= 2:2.2.3-2~deb11u2~)
(so it conflicts even with next minor version of libldb2).
But it looks like other samba packages does have libldb2 dependency.
It looks like I need to take a look at how libldb2 is used by samba-libs,
maybe some libs should be moved between packages.
Also, when a single source package builds multiple libraries, it's usually
a lot more robust if the dependencies between those libraries are strict
(libfoo Depends: libbar (= ${binary:Version}) so that users are forced
to upgrade either everything or nothing from that source package. This
The only real user of libldb2 in samba is samba-dsdb-modules. And exactly
due to this reason I switched from the ugly "between" version like I
demonstrated above to exact version. libldb2 builds from samba package
since bookworm version (4.16), in bullseye libldb was in its own package.
is because the upstream developer will never have tested with mismatched
versions, and code in the same source package often uses private/internal
interfaces that are not formally part of the API/ABI, or relies on
internal implementation details that might change in a newer version.
I weren't aware that libldb2 is linked to from samba-libs. Now I do, and
ofc I'll take care of this. Either by adding countless patches adding
missing versions which upstream refuses to add for some unknown reason
like I initially did for 4.17 version, or by rearranging libraries into
different packages so that libldb isn't used by samba-libs, or maybe
upstream will do their part and add those versions itself, I dunno.
Thanks,
/mjt
Bug#1020776: qemu-system-data in bullseye-backports is too old
On 26.09.2022 17:39, Justin Ossevoort wrote: Package: qemu-system-data Version: 1:5.2+dfsg-11+deb11u2 Severity: grave Justification: renders package unusable X-Debbugs-Cc: deb...@internetionals.nl Dear Maintainer, The latest packages in Debian Bullseye Backports depend on qemu-system-data (>> 1:7.1+dfsg~) But the current version in the Debian APT archives (and according to https://packages.debian.org/bullseye-backports/qemu-system-data) is: qemu-system-data (1:7.0+dfsg-2~bpo11+2) the current q-s-d hasn't been built - that's why it can't be installed. As Diederik correctly noted, this is because of the wrong dependency on gcc-alpha which does not exist on bullseye. Apparently I forgot to re- generate d/control in +bpo11+2 upload so the change didn't propagate to it, keeping q-s-d unbuildable. I'll fix this (with a 3-char change in d/control) when I'll return, hopefully next week. /mjt
Bug#993014: cifs-utils non-parallel FTBFS
27.08.2022 03:35, Santiago Vila пишет: Hi. Now that this is finally fixed in sid, here is a proposed diff for bullseye, including changelog. Heh. The changelog includes entry by me.. it is not fair for your contribution, I think.. :) BTW, should we drop the .1 from -3.1+deb11u2 release number? Thanks, /mjt
Bug#993014: Processed: Re: cifs-utils non-parallel FTBFS
25.08.2022 11:49, L. van Belle wrote: ... The shown fix, commit aeaa786aceb0ea781ded2c151fb68f6b34880ad4 is the patch I added. and cifs-utils 7.0 also fails to build without that patch with parallel=1 It's difficult to follow. Commit aeaa786aceb0ea781ded2c151fb68f6b34880ad4 is wrong by its own because it adds dependency on install-sbinPROGRAMS while it should add dependency on install-root_sbinPROGRAMS (which creates the necessary directory). So that commit just adds unnecessary complexity but does not fix the problem in any way. Was it you who added this commit to upstream samba? I didn't notice this difference either, before closing this bug. I thought I verified the single-job build locally but it turned out my -j1 has been overridden by later -j8 on the same command line. Oh well. Technically this dependency is wrong too because the symlink itself does not need the installation of the binary, it needs only the directory. The right fix would be to create directory in its own target and refer in both install- and hook- to that target but I don't know if it is solvable in terms of regular make. GNU make has order-only targets which fits here nicely. But install-root_sbinPROGRAMS target as whole is generated by automake, together with the mkdir call. So the only way to "fix" this is to add similar mkdir into the hook rule, as Sanvilla did in his patch. Now, you wrote above that cifs-utils 7.0 "also fails to build without this patch", but this patch is included in 7.0. This is even more confusing.. :) Anyway. I'm changing install-sbinPROGRAMS to install-root_sbinPROGRAMS there to do what aeaa786aceb0ea781ded2c151fb68f6b34880ad4 has meant to do. This will fix this issue "the way upstream wanted it to be fixed", so to say. Oh well. /mjt
Bug#993014: cifs-utils non-parallel FTBFS
Control: tag -1 + pending 22.08.2022 17:11, L. van Belle wrote: I can confirm the patch works. I've tested on a Debian Bullseye build with cifs-utils 7.0 from https://ftp.samba.org/pub/linux-cifs/cifs-utils/ I refreshed patch 001. Added the patch shown buy Helmut. And I builded against Debian Bullseye with parallel=7 and parallel=1 Here's the upstream commit which fixes the problem: commit aeaa786aceb0ea781ded2c151fb68f6b34880ad4 Author: lizhe Date: Tue May 26 11:54:11 2020 +0800 cifs-utils: fix probabilistic compiling error When we compile cifs-utils, we may probabilistic encounter install error like: cd ***/sbin && ln -sf mount.cifs mount.smb3 ***/sbin: No such file or directory The reason of this problem is that if we compile cifs-utils using multithreading, target 'install-sbinPROGRAMS' may be built after target 'install-exec-hook' of the main Makefile. Target 'install-sbinPROGRAMS' will copy the executable file 'mount.cifs' to the $(ROOTSBINDIR), which target 'install-exec-hook' will do the 'ln' command on. This patch add the dependency of target 'install-exec-hook' to ensure the correct order of the compiling. Signed-off-by: lizhe diff --git a/Makefile.am b/Makefile.am index a95782d..8a17e73 100644 --- a/Makefile.am +++ b/Makefile.am @@ -117,7 +117,7 @@ endif SUBDIRS = contrib -install-exec-hook: +install-exec-hook: install-sbinPROGRAMS (cd $(DESTDIR)$(ROOTSBINDIR) && ln -sf mount.cifs mount.smb3) install-data-hook: I think both are wrong but both do the job. Now, the question is: do we need to fix this for bullseye? It smells like there's no need to, no? Thanks, /mjt
Bug#929983: bug 929983: ipxe-qemu: virtio booting no longer works after upgrade to buster
Control: severity -1 normal 08.05.2022 02:18, Thorsten Glaser wrote: .. In this bugreport, I see it is/was broken with -machine pc-1.1. There's no indication if it is broken with other machine types. As of qemu 5.2 (bullseye) machine types below pc-1.3 are deprecated, and in 7.0 (current bookworm) they're removed. This is rather bad, this will break existing VMs on upgrade with almost certainly zero clues why. these machine definitions are more than 10 years old. qemu can not keep them the way it were 10 years ago (and as we observed in this bugreport, this makes it bitrot). That wasn't an easy decision but the line must be drawn somewhere, we can't support really old stuff forever. Please note that in qemu, these machine types are kept mostly in order to make the VMs migratable from one version of qemu to another (which in practice quite often does not work anyway). During reboot it is possible to switch to a more recent machine. I know some operating systems can not tolerate hardware changes though, - at least linux is not one of them. Do you agree with this assessment of the bug you reported? If so, let's tag this bug with buster and bullseye as indeed I conclude it's not a bug in bookworm then. I'd rather consider this a second RC bug in bookworm, if so. I don't see why it is marked with this severity. To me it definitely is a "normal" bug (if not "minor" due to too old hw definitions). It works by default, and even in rare situations when it doesn't, there are easy workarounds (switch to another NIC for example). Or do you refer to the qemu dropping ancient machine types instead of this netbooting thing? If that's the case, such bug will be "wontfix" for sure. I'm lowering severity of this bug to "normal" now. Please feel free to set it to other value and provide the reasons why do you think this way. I'm currently in a really bad situation to look at anything in detail (waiting for my brain to remember the luks password of my work laptop), please excuse brevity. I hope you'll succeed there. It's sad when this happen. Thanks! /mjt
Bug#929983: bug 929983: ipxe-qemu: virtio booting no longer works after upgrade to buster
06.05.2022 19:49, Mike Gabriel wrote: .. at least the bugtitle is far to unprecise. Here, I test Debian Edu bullseye really heavily and integrate FAI in Debian Edu. The FAI installer and also the diskless machines I very often boot via iPXE/QEMU. In Debian 11 (and probably beyond), PXE booting in QEMU works, for BIOS legacy VMs as well as for UEFI based VMs. In this bugreport, I see it is/was broken with -machine pc-1.1. There's no indication if it is broken with other machine types. As of qemu 5.2 (bullseye) machine types below pc-1.3 are deprecated, and in 7.0 (current bookworm) they're removed. /mjt
Bug#929983: bug 929983: ipxe-qemu: virtio booting no longer works after upgrade to buster
05.05.2022 13:47, Paul Gevers wrote: Hi all, [CC-ing src:debian-edu and src:qemu as they pull in src:ipxe-qemu into the key package set, so I consider them stakeholders in this RC bug.] On Fri, 12 Mar 2021 19:29:55 +0100 (CET) Thorsten Glaser wrote: So we now know without fail that there’s a change in the ipxe-qemu binary package, introduced between jessie and stretch, that breaks netbooting on virtio NICs for at least some qemu machine models in use by libvirt guests. Is there any progress on this front? It would be a shame if we have to -ignore the bug again for bookworm. Well, there's no progress in there, - I weren't aware of this issue is still occurs on bookworm. I don't have a netboot environment handy to test it, either. Help? /mjt
Bug#927747: bind9_dlz backend is entirely broken in Debian
Control: severity -1 normal On Wed, 8 May 2019 22:35:53 +0200 "Steinar H. Gunderson" wrote: On Wed, May 08, 2019 at 10:02:46PM +0200, Mathieu Parent wrote: > Downgrading the severity as the AppArmor side is already fixed it seems in sid. serious and grave are of equal severity; serious is for Policy violations (e.g. package doesn't install), grave is for functionality issues (e.g. program segfaults on start). For some reason it is common to misuse severity. A "package is unusable in almost all configurations" or at least "unusable in default configuration" isn't always equal to "package is unusable *for me*". In this case, if dlz_backend is broken, it does not mean samba is entirely broken. A particular configuration of it - sure. For one, we run a samba AD without dlz_backend and without bind to begin with, and it works just fine.. Thanks, /mjt
Bug#1009204: vdirsyncer: diff for NMU version 0.18.0-6.1
Control: tags 1009204 + patch Control: tags 1009204 + pending Dear maintainer, I've prepared an NMU for vdirsyncer (versioned as 0.18.0-6.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. I also prepared a repository update at https://salsa.debian.org/mjt/vdirsyncer , tag debian/0.18.0-6.1 , branch nmu-0.18.0-6.1, at 324bef8b , which you can import to the main repository. Regards. diff -Nru vdirsyncer-0.18.0/debian/changelog vdirsyncer-0.18.0/debian/changelog --- vdirsyncer-0.18.0/debian/changelog 2022-02-23 01:34:53.0 +0300 +++ vdirsyncer-0.18.0/debian/changelog 2022-04-18 17:39:33.0 +0300 @@ -1,3 +1,12 @@ +vdirsyncer (0.18.0-6.1) unstable; urgency=medium + + * Non-maintainer upload. + * add python3-all dependency to d/tests/control: the test is written +so it iterates over all python3 versions but does not depend on +all pythons. Closes: #1009204 + + -- Michael Tokarev Mon, 18 Apr 2022 17:39:33 +0300 + vdirsyncer (0.18.0-6) unstable; urgency=medium * avoid checking flaky test test_fuzzing; diff -Nru vdirsyncer-0.18.0/debian/tests/control vdirsyncer-0.18.0/debian/tests/control --- vdirsyncer-0.18.0/debian/tests/control 2022-02-23 01:23:14.0 +0300 +++ vdirsyncer-0.18.0/debian/tests/control 2022-04-18 17:39:21.0 +0300 @@ -7,4 +7,5 @@ python3-pytest, python3-pytest-cov, python3-pytest-localserver, + python3-all, vdirsyncer,
Bug#1009385: communication
[Resending whole thing. I think it is is important to have it publicly available and to reach you, so adding it to the bugreport too. Apparently team+dns@tracker.d.o isn't working and there's no archives] I want to follow up on the todays ldns incident. I think it was quite interesting. The whole thing of me pushing the 1.7.1-2.1 NMU was not noticed by the current maintainer of ldns package. I don't know why, but after uploading to DELAYED/2, I thought I'd ask Santiago directly, because strangely I did see his reply to other emails but not to my upload. And indeed, he replied he didn't receive my nmudiff emails about the delayed upload. So next, instead of me ensuring the comminication is working correctly, I switched to mostly private email exchange between me and Santiago. We discussed many things, he reviewed my changes, we discussed possible master branch rewrite (the top two commits by Robert), I've asked Robert about his opinion on these 2 commits, -- this all has been done in private email exchange. I was wrong here not to add some Cc to team+dns@ or some bugreport, or anything. On the contrary, the discussion spinned off the python3.10 ftbfs bug, but I replied to Santiago in private, because that discussion has nothing to do with that bugreport really. So initially it was me who made whole thing absolutely unknown to all the dns team, whole team was absolutely unaware about the happenings in there. I apologize for this discussion going on entirely in private. The problem was not because of my incompetence or me being unaware, no, *that*'d be understandable. The thing was that I had this thought many times, I had this feeling every time I replied, that this whole thing should be made public, but I didn't do anything with that, -- the usual "I don't have time right now for this" played its game. And sure thing, Daniel did the best he thought it is, without any knowledge about all the happenings behind the scenes. Hopefully the whole thing is much better now. Yes it required master branch rewrite, because of *my* NMU which went out of order. And it was still the same single rewrite after Daniel changes. Now, to sum it up: mjt-1.8 branch *was* ready for the upload (tho I was more comfortable with another 1.7 upload too). Now I need to review it before it can be merged (now it's just fast-forward, but please let me one more chance for mjt-1.8 branch rewrite if I'll find anything in there which needs a rebase - I'm not asking about master branch rewrite here). I kept it separate from master for 2 reasons now: first I need to review it myself, and second, if by a chance we'll have to fix the 1.7.1-3 upload, we wont need another rewrite. [While I experimented with team+dns@tracker.d.o, I also force-pushed mjt-1.8 branch again, fixing changelog so it will not include already listed entries, and adding two more commits to there. I'm still not entirely sure what I have in there is what I actually want it to be, so I still have to re-review my own changes - whenever they're making sense on top of Daniel's changes. Please be patient there] Thank you all for the patience. This was a good lesson for everyone, I think. /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
BTW, Daniel, please re-tag 1.7.1-3 - this is what's at the tip of master now. I hope anyway :) Thanks, /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
Fixed my branch on the ldns repo, rebasing it on top of now-okay master. If we ever need one more 1.7 release it will be easier to rebase now with the conflicts resolved. I have to review my branch again, I think something might not be right there after the rebase on top of dkg's changes. I will do this tomorrow. Please don't rush it the next time. People were discussing things for quite some days already, and you aren't even an uploader. Just don't do that again. There's no harm done, we are all people and we all do mistakes. I did it too, by doing an NMU without the 2 commits which were pending in master. Thanks, /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
Okay guys. I thought about this a bit more. One wrong action by one developer does not make the environment unhealthy. I fixed the mess done to the master branch. I think - provided this wont happen again - it's okay to work on this to fix the rest of the mess done. I'm doing this right now. Thanks, /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
13.04.2022 21:19, Daniel Kahn Gillmor wrote: .. reviewed and i'll push that to salsa as a "debian/experimental" branch later today, if either of you want to take a look at what i'm considering for release. The whole thing was ready, polished, everything addressed. If you wanted another 1.7.1 upload that's fine, just add one more commit after my nmu. It was not done in the master branch for a very good reason. Please feel free to use any of my changes you like. Please don't add me to uploaders. This is not how I think package maintenance should be done. I don't want to work in such an unhealthy environment. Thanks, /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
13.04.2022 21:29, Michael Tokarev wrote: The only prob is that the master branch on the ldns repository is seriously messed up. Also you've made similar commits as I did, but in an incomplete way (like the watch file update). Thanks, /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
13.04.2022 21:19, Daniel Kahn Gillmor wrote: Hi Michael and Santiago-- I've now uploaded ldns 1.7.1-3 with the associated fix for 1009385. I'm reviewing Michael's changes for 1.8.1, and they're looking good to me. Thank you for all that work, Michael! I think we should consider uploading 1.8.1 into experimental while we wait for 1.7.1-3 to propagate to testing. I don't see a reason to use experimental here, since ldns is not a very popular package, it wont do much good in experimental. The only prob is that the master branch on the ldns repository is seriously messed up. It was for a reason I asked how to resolve this situation. You made it significantly worse. /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
On 13.04.2022 16:44, Santiago Ruano Rincón wrote: .. So what do we do now? I think the best is to include this fix as 1.7.1-3 (provided it actually fixes the issue) for now, instead of uploading 1.8. Why just don't uploading 1.8.1? Well, we know 1.7 (sort of) works while 1.8 might cause surprizes. What else is missing, other than the now fixed autodep8-python3? I don't know anything else what's missing (besides adding another Closes: by 1.8 for this new bug) And rewrite the history for this one too ;) No if we go for your 1.8.1 upload :-) Am I wrong? It's still the same rewrite really, no matter which way to go: either add one commit before the 2 commits in there or one, it's exactly the same thing now. No, you aren't wrong. I can handle that later today (hopefully). Thanks! /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
[Just a quick follow-up] On 13.04.2022 15:52, Santiago Ruano Rincón wrote: [...] It seems it was fixed on 1.8.0. https://github.com/NLnetLabs/ldns/commit/4d2057f0b5220487882be1b19c302833b84cffe3 Wonderful.. :) Thank you Santiago! So, the prob should've be there after just any recompile of ldns, including the bin-NMU upload to rebuild it with python3.10. *sigh*. So what do we do now? I think the best is to include this fix as 1.7.1-3 (provided it actually fixes the issue) for now, instead of uploading 1.8. And rewrite the history for this one too ;) Thanks, /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
13.04.2022 10:09, Michael Tokarev wrote: .. But let's try. How this utility is used in building of dns-root-data? Lemme take a look at this package. If you can provide me some minimal testcase to produce just the DS record which differs, it will be nice. I don't have time for this today. Thinking about this further, since there was absolutely no code changes in ldns itself, - how about building dns-root-data with ldns 1.7.1-2 and 1.7.1-2.1 WITHOUT ANYTHING ELSE CHANGING, and comparing the results? The thing is that it just can not be this change. Yes it can be a change in some other tool. Like libssl I already wrote about, or maybe gcc generating different code, or something different. And since I don't have any idea about how ldns works, and don't even know what a DS record is, that would be difficult and definitely time- consuming for me to understand all this. If it's an issue with gcc code generation, we'll have to address this upstream most likely. Or maybe it's fixed in 1.8 already. Thanks, /mjt
Bug#1009385: libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data [was: Re: Bug#1009385: dns-root-data: FTBFS: root-anchors.ds root.ds differ]
13.04.2022 09:50, Daniel Kahn Gillmor wrote: Control: reassign 1009385 libldns3 1.7.1-2.1 Control: retitle 1009385 libldns3 1.7.1-2.1 changes output of ldns-key2ds, causing FTBFS on dns-root-data Control: affects 1009385 + dns-root-data X-Debbugs-Cc: Michael Tokarev Control: tags 1009385 + help Lucas, thanks for flagging this! The build failure below appears to happen when libldns3 1.7.1-2.1 is installed. It does not fail with libldns3 1.7.1-2+b1. The output of ldns-key2ds has changed between these two versions. yikes! Michael, it looks like it was this particular upload for ldns: That's lovely indeed :) Yes, the fix itself does not change anything in the code, it merely allows the package to be configured --with-python when python version is 3.19. More, it does not change anything in the C-language code of ldns, at all, and neither the python version nor even the python presence changes this part. Now, I know right to nothing about ldns internals, including the crypto part. I'm just a happy user of ldnsutils, and I've choosen this package just because it was holding my other packages transition with this python3 thing. This is also the reason why I come with a really minimal, non- intrusive change here. But let's try. How this utility is used in building of dns-root-data? Lemme take a look at this package. If you can provide me some minimal testcase to produce just the DS record which differs, it will be nice. Might it be due to some other changes in the related packages, - like, openssl/libssl change which now produces (slightly?) different output? There's also an 1.8.1 version of ldns ready for the upload - I'm waiting for the other maintainers to acknowlege it and for the python3 transition to actually happen before breaking other toys :) Thanks, /mjt
Bug#1008638: ldns: diff for NMU version 1.7.1-2.1
Control: tags 1008638 + patch Control: tags 1008638 + pending Dear maintainer, I've prepared an NMU for ldns (versioned as 1.7.1-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. This is a second try, - I found my mistake when attempted to check the return code of the autoconf test. Fixed it now. The change is a one-liner. Regards. diff -Nru ldns-1.7.1/debian/changelog ldns-1.7.1/debian/changelog --- ldns-1.7.1/debian/changelog 2020-06-24 15:08:14.0 +0300 +++ ldns-1.7.1/debian/changelog 2022-04-07 16:03:29.0 +0300 @@ -1,3 +1,15 @@ +ldns (1.7.1-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * add fix-wrong-python-distutils-configure-check.diff to fix the +incorrect distutils package check (it should be checking the +return code not the emptiness of the output). This fixes FTBFS +with new python (3.10) and allows the python3.10 transition to +happen, but it is not fixing the actual issiue with ldns using +distutils which should be addressed later. Closes: #1008638 + + -- Michael Tokarev Thu, 07 Apr 2022 16:03:29 +0300 + ldns (1.7.1-2) unstable; urgency=low * Team upload. diff -Nru ldns-1.7.1/debian/patches/fix-wrong-python-distutils-configure-check.diff ldns-1.7.1/debian/patches/fix-wrong-python-distutils-configure-check.diff --- ldns-1.7.1/debian/patches/fix-wrong-python-distutils-configure-check.diff 1970-01-01 03:00:00.0 +0300 +++ ldns-1.7.1/debian/patches/fix-wrong-python-distutils-configure-check.diff 2022-04-07 16:03:29.0 +0300 @@ -0,0 +1,22 @@ +Subject: fix the wrong distutils python check in configure +From: Michael Tokarev +Date: Thu, 07 Apr 2022 17:22:05 +0300 + +The check is implemented in the wrong way: instead of checking for +the return value of an attempt to import the given module (which is 0), +it is checking the returned _text_. And with python3.10, this module +is deprecated, so python gives a warning. It is not fatal but the +wrong test made it so by checking for the output to be empty. + +Fix it by checking for the error code instead of checking emptiness +of output. + +diff --git a/ax_python_devel.m4 b/ax_python_devel.m4 +index 87e7c8c..6a7cd3e 100644 +--- a/ax_python_devel.m4 b/ax_python_devel.m4 +@@ -139,3 +139,3 @@ variable to configure. See ``configure --help'' for reference. + ac_distutils_result=`$PYTHON -c "import distutils" 2>&1` +- if test -z "$ac_distutils_result"; then ++ if test $? -eq 0; then + AC_MSG_RESULT([yes]) diff -Nru ldns-1.7.1/debian/patches/series ldns-1.7.1/debian/patches/series --- ldns-1.7.1/debian/patches/series2020-06-03 23:55:03.0 +0300 +++ ldns-1.7.1/debian/patches/series2022-04-07 16:03:29.0 +0300 @@ -1 +1,2 @@ Makefile-remove-install-libldns-pc.patch +fix-wrong-python-distutils-configure-check.diff
Bug#1008638: ldns: diff for NMU version 1.7.1-2.1
Control: tags 1008638 + patch Control: tags 1008638 + pending Dear maintainer, I've prepared an NMU for ldns (versioned as 1.7.1-2.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Regards. diff -Nru ldns-1.7.1/debian/changelog ldns-1.7.1/debian/changelog --- ldns-1.7.1/debian/changelog 2020-06-24 15:08:14.0 +0300 +++ ldns-1.7.1/debian/changelog 2022-04-07 16:03:29.0 +0300 @@ -1,3 +1,15 @@ +ldns (1.7.1-2.1) unstable; urgency=medium + + * Non-maintainer upload. + * add skip-wrong-python-distutils-configure-check.diff to skip the +incorrect distutils package check (it should be checking the +return code not the emptiness of the output). This fixes FTBFS +with new python (3.10) and allows the python3.10 transition to +happen, but it is not fixing the actual issiue with ldns using +distutils which should be addressed later. Closes: #1008638 + + -- Michael Tokarev Thu, 07 Apr 2022 16:03:29 +0300 + ldns (1.7.1-2) unstable; urgency=low * Team upload. diff -Nru ldns-1.7.1/debian/patches/series ldns-1.7.1/debian/patches/series --- ldns-1.7.1/debian/patches/series2020-06-03 23:55:03.0 +0300 +++ ldns-1.7.1/debian/patches/series2022-04-07 16:03:17.0 +0300 @@ -1 +1,2 @@ Makefile-remove-install-libldns-pc.patch +skip-wrong-python-distutils-configure-check.diff diff -Nru ldns-1.7.1/debian/patches/skip-wrong-python-distutils-configure-check.diff ldns-1.7.1/debian/patches/skip-wrong-python-distutils-configure-check.diff --- ldns-1.7.1/debian/patches/skip-wrong-python-distutils-configure-check.diff 1970-01-01 03:00:00.0 +0300 +++ ldns-1.7.1/debian/patches/skip-wrong-python-distutils-configure-check.diff 2022-04-07 16:03:29.0 +0300 @@ -0,0 +1,33 @@ +Subject: disable + +--- a/ax_python_devel.m4 2019-07-26 18:07:44.0 +0300 b/ax_python_devel.m4 2022-04-07 16:02:18.383039533 +0300 +@@ -135,17 +135,17 @@ + # + # Check if you have distutils, else fail + # +- AC_MSG_CHECKING([for the distutils Python package]) +- ac_distutils_result=`$PYTHON -c "import distutils" 2>&1` +- if test -z "$ac_distutils_result"; then +- AC_MSG_RESULT([yes]) +- else +- AC_MSG_RESULT([no]) +- AC_MSG_ERROR([cannot import Python module "distutils". +-Please check your Python installation. The error was: +-$ac_distutils_result]) +- PYTHON_VERSION="" +- fi ++# AC_MSG_CHECKING([for the distutils Python package]) ++# ac_distutils_result=`$PYTHON -c "import distutils" 2>&1` ++# if test -z "$ac_distutils_result"; then ++# AC_MSG_RESULT([yes]) ++# else ++# AC_MSG_RESULT([no]) ++# AC_MSG_ERROR([cannot import Python module "distutils". ++#Please check your Python installation. The error was: ++#$ac_distutils_result]) ++# PYTHON_VERSION="" ++# fi + + # + # Check for Python include path
Bug#953530: [Pkg-samba-maint] Bug#953530: samba-common-bin: post-install fails with "lock directory /run/samba does not exist"
23.03.2022 16:38, Diederik de Haas wrote: On woensdag 23 maart 2022 06:54:57 CET Axel Beckert wrote: Gian Piero Carrubba wrote: Init: sysvinit (via /sbin/init) Diederik de Haas wrote: I do not have a /run/samba/ directory on my Bookworm system/server. I don't think it's relevant, but it (still?) has sysv-init as init. I think, I see a pattern here: My three affected hosts have sysvinit, too (on purpose). Yeah, that's a pattern :-) Looking a bit further and I found https://bugs.debian.org/975422 through https://salsa.debian.org/samba-team/samba/-/commit/0c3b2056764cd1a566766c3e1764d7c312eab5d7 titled: "Ensure systemd-tmpfiles is called before testparm (Closes: #975422)" How about just mkdir -p /run/samba at the place of #DEBHELPER# in there ? /mjt
Bug#1005642: possible gross file corruption due to windows client cache poisoning
Package: samba Version: 2:4.13.13+dfsg-1~deb11u2 Severity: critical Tags: patch upstream Please see https://lists.samba.org/archive/samba/2022-February/239548.html and https://lists.samba.org/archive/samba/2022-February/239577.html for the description of the problem and how serious can it be, this bugreport: https://bugzilla.samba.org/show_bug.cgi?id=14928 for the actual bug and the fixes. 3 patches mentioned at the end of the samba.org bugreport are needed for bullseye version of samba to fix this (not counting first patch which modifies the tests, and the last patch which just fixes comments - I mean the actual code changes needed for the fix). First code fix has a chunk for tests/ which also needs to be deleted for 4.13. With these 3 patches, and adding nt_time_to_unix_timespec_raw@SAMBA_UTIL_0.0.1 to d/libwbclient0.symbols, our problem with windows profile corruption immediately went away. Gosh, that was gross... Thanks, /mjt
Bug#997082: qemu: FTBFS: usb.c:200:23: error: array subscript ‘device_descriptor_t[0]’ is partly outside array bounds of ‘u8[8]’ {aka ‘unsigned char[8]’} [-Werror=array-bounds]
23.10.2021 19:33, Lucas Nussbaum wrote:
Source: qemu
Version: 1:6.1+dfsg-6
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-20211023 ftbfs-bullseye
Hi,
During a rebuild of all packages in sid, your package failed to build
on amd64.
Relevant part (hopefully):
powerpc64-linux-gnu-gcc $EXTRACFLAGS -m32 -mcpu=604 -msoft-float -fno-builtin-bcopy -fno-builtin-log2 -Os -g
-DNATIVE_BITWIDTH_EQUALS_HOST_BITWIDTH -USWAP_ENDIANNESS -Wall -Wredundant-decls -Wshadow -Wpointer-arith
-Wstrict-prototypes -Wmissing-declarations -Wundef -Wendif-labels -Wstrict-aliasing -Wwrite-strings
-Wmissing-prototypes -Wnested-externs -Werror -MMD -MP -MT target/drivers/usbohci_rh.o -MF
'target/drivers/usbohci_rh.d' -I/<>/roms/openbios/include
-I/<>/roms/openbios/kernel/include -I./target/include -c -o target/drivers/usbohci_rh.o
/<>/roms/openbios/drivers/usbohci_rh.c
/<>/roms/openbios/drivers/usb.c: In function ‘get_descriptor’:
/<>/roms/openbios/drivers/usb.c:200:23: error: array subscript
‘device_descriptor_t[0]’ is partly outside array bounds of ‘u8[8]’ {aka ‘unsigned char[8]’}
[-Werror=array-bounds]
200 | if (dd->bMaxPacketSize0 != 0)
| ^~
/<>/roms/openbios/drivers/usb.c:181:12: note: while referencing
‘buf’
181 | u8 buf[8];
|^~~
This is interesting. And I'm not really sure what to do with this.
The code is right, and gcc is too picky there. The thing is,
while the buffer is indeed smaller than the size of the structure
to which it is casted there, but the actual code does not access
past the buffer, bMaxPacketSize0 is byte #7 (counting from 0) there
which is exactly the last byte of buf[] array.
I haven't seen this warning before, it must be some new gcc
addition, and gcc is being too smart there :)
I agree the code is cloudy there, it can have been written
more clearly. So I can't say this is really a bug in gcc,
it is like classic "variable can be used uninitialized" while
it actually is not, for example because all relevant switch(){}
statements leads to return but gcc can not figure it out.
Thanks,
/mjt
Bug#990417: openjdk-11-jre-headless: running java in qemu s390 gives a SIGILL
Control: severity -1 normal Lowering severity of this bug to normal. It definitely is not grave in my book, - this is a regular emulation bug which can't emulate some specific code. Or else every emulation bug should be marked "grave" as it affects "other software". BTW, I for one can't reproduce it, but this is just because I don't know how to run a S390X VM. Maybe if someone can provide instructions (how to install and run it) I'd be able to do that. For now this bug will be here without any action from my side - I just don't know what I can do. Also, checking whenever it is still present in 6.1 version will be nice too. Thanks, /mjt
Bug#993658: qemu-user-static does not work through binfmt since 6.0
04.09.2021 14:33, Vincent Bernat wrote: > Package: qemu-user-static > Version: 1:6.1+dfsg-4 > Severity: critical > Hey! Since 6.0, qemu-user-static does not seem to work properly through binfmt. I am a bit lost on how to diagnose that: ... When invoked through binfmt, the binaries seem to go from "I display something wrong" to "I will wipe your entire home". That's what happened to me when using cowbuilder. The chroot was not able to be Ouch. setup correctly and during the clean phase, cowbuilder did not detect the bind mount and/or was not able to undo them, rm -rfing everything that was mounted. Downgrading qemu-user-static to 1:5.2+dfsg-11 fixes the issue. ... Kernel: Linux 5.13.0-trunk-amd64 (SMP w/12 CPU threads) Can you please check if it works with not-so-fresh kernel (eg the one from bullseye)? I wont able to do this until late evening today. I'm guessing this is the upstream way to detect if we were called from binfmt subsystem (they done it within kernel) interferes with my way of doing the same without touching the kernel. Kernel side is a recent addition. Thanks! /mjt
Bug#992158: Race in ifup maybe related to brctl failure in pre-up of network interface
On Sat, 14 Aug 2021 08:28:41 + Roman Fiedler wrote: Package: bridge-utils Version: 1.7-1 Severity: serious When running "brctl addbr" and "ip link set [if] address" immediately afterwards, the second command will fail to apply the address change. This is somehow annoying as the MAC would be used in security related filtering and monitoring of the network traffic, which then fails. The configuration from "/etc/network/interfaces" reliably triggering the bug is: auto virtbr0 iface virtbr0 inet static address 192.168.1.1 netmask 255.255.255.0 pre-up brctl addbr virtbr0 pre-up ip link set virtbr0 address 86:aa:aa:aa:aa:aa pre-up ip link set virtbr0 up post-down ip link set virtbr0 down post-down brctl delbr virtbr0 How about switching from brctl to ip, once you already use it anyway? So instead of brctl addbr virtbr0, it will read ip link add virtbr0 type bridge, and ip link del virbr0, something like that. I don't know about brctl, - we stopped using this utility some 10 years ago due to numerous issues. Also I don't know whenever it's a good idea to mark this bug as serious. Thanks, /mjt
Bug#979322: libcacard: missing runtime glib2.0 dependency?
05.01.2021 13:44, Gianfranco Costamagna wrote: ... after installing it looks still missing Package 'libpcsclite', required by 'libcacard', not found Oh. I missed this one. Will do another upload. /mjt
Bug#979322: libcacard: missing runtime glib2.0 dependency?
05.01.2021 13:44, Gianfranco Costamagna wrote: Source: libcacard Version: 1:2.8.0-1 Severity: serious Hello, libglib2.0-dev looks missing on -dev package? pkg-config --short-errors --print-errors --cflags --libs "libcacard >= 2.5.1" Package 'glib-2.0', required by 'libcacard', not found I guess no one tried libcacard without qemu :) This bug is present in all versions of libcacard since the very beginning. But I really question whenever this pkgconfig error is actually an error. The thing is that libglib.so is _not_ required for linking with libcacard.so, so pkgconfig complaining isn't right. Hmm... /mjt
Bug#978131: qemu-system-x86: Segfault when starting a VM
Control: tag -1 + moreinfo Control: severity -1 normal 26.12.2020 15:10, Charles Malaheenee wrote: Package: qemu-system-x86 Version: 1:5.2+dfsg-2 Severity: grave Tags: upstream Justification: renders package unusable X-Debbugs-Cc: malahee...@gmx.fr Dear Maintainer, Not sure is it related with qemu itself, but suddenly a launch of a VM through libvirt fails with a standard error message: virsh # start board.debian.malaheenee.ca error: Failed to start domain board.debian.malaheenee.ca error: internal error: qemu unexpectedly closed the monitor Initially I thought it is because of the kernel, because last week it worked (that's why the kernel is 5.9.0-4-amd64). I can do more test if needed. Yes, some more information is definitely needed here. At least please provide your qemu command line as found in the libvirt logs. Please note this package is used by many users and you're the first to report this issue, so it must be related to some unique combination of options used by you. That's why I'm lowering severity of this bugreport. Thanks, /mjt
Bug#976919: edk2: FTBFS on ppc64el (arch:all-only src pkg): Could not detected HOST_ARCH from uname results
Control: severity -1 wishlist Control: tag -1 wishlist 09.12.2020 11:59, Lucas Nussbaum wrote: Source: edk2 Version: 2020.08-1 Severity: serious Justification: FTBFS on ppc64el Tags: bullseye sid ftbfs Usertags: ftbfs-20201209 ftbfs-bullseye ftbfs-ppc64el Hi, During a rebuild of all packages in sid, your package failed to build on ppc64el. At the same time, it did not fail on amd64. Since this is a repeating filing of the same bug but for other architecture, I'm not closing it but marking it as wontfix. Thank you for wasting your own and my time. /mjt
Bug#969074: [PATCH] d/p/lp-1894129-*: fix FTBFS (LP: #1894129 Closes: #969074)
30.11.2020 23:27, Paul Gevers wrote: Hi all, Christian, On Tue, 8 Sep 2020 15:40:11 +0200 Christian Ehrhardt wrote: Signed-off-by: Christian Ehrhardt --- ...raseReserved-override-driver-queue_p.patch | 74 ...BlockEraseReserved-skip-unless-iSCSI.patch | 39 ...e-Write-override-driver-queue_pdu-ca.patch | 71 ...e-Write-skip-InvalidDataOutSize-unle.patch | 39 ...EraseReserved-override-driver-queue_.patch | 74 ...ryptoEraseReserved-skip-unless-iSCSI.patch | 39 ...iteReserved-override-driver-queue_pd.patch | 68 +++ ...-test-tool-Use-extern-int-in-headers.patch | 58 ++ ...mdSnTooHigh-override-driver-queue_pd.patch | 68 +++ ...mdSnTooLow-override-driver-queue_pdu.patch | 69 ...ataSnInvalid-override-driver-queue_p.patch | 166 ++ ...-unused-iscsi_queue_pdu-symbol-overl.patch | 104 +++ debian/patches/series | 12 ++ 13 files changed, 881 insertions(+) Uh-oh... [] If your comfortable, can this please be uploaded? libiscsi is a key package (so won't be autoremoved) and the freeze is getting near. Let's not wait with fixing this until the latest moment. So, is it another case of poorly maintained upstream software which become a key package? Speaking of the upload, - I hoped upstream will finally catch up and release a new version (with another soversion bump as Ronni does each time wrongly, despite numerous attempts to teach him to do it properly), - but it seems it's a dead hope, so yes, we should upload the fixed version, - if new upstream release will come before freeze we can consider using it too. Lemme handle it if there's no objections. Thanks, /mjt
Bug#972789: qemu: FTBFS on arm{el,hf}: /<>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is not compatible
23.10.2020 19:50, Sebastian Ramacher wrote:
Source: qemu
Version: 1:5.1+dfsg-4
Severity: serious
Tags: ftbfs sid bullseye
Justification: fails to build from source (but built successfully in the past)
binNMUs of qemu for the libbrlapi transition failed to build on armel
and armhf:
| /<>/linux-user/m68k/signal.c:44:1: error: ‘TYPE_CANONICAL’ is
not compatible
|44 | };
| | ^
Hmm. So this looks like a gcc ICE bug. Here's the code in question:
struct target_sigframe
{
abi_ulong pretcode;
int sig;
int code;
abi_ulong psc;
char retcode[8];
abi_ulong extramask[TARGET_NSIG_WORDS-1];
struct target_sigcontext sc;
};
...
| /<>/linux-user/m68k/signal.c:44:1: internal compiler error:
‘verify_type’ failed
I'm not sure what I have to do with this, besides reassigning it to gcc.
BTW, symbol TYPE_CANONICAL is not used/referenced by qemu sources.
/mjt
Bug#964185: freetype2.pc depends on libbrotlidec.pc without a dependency on the libbrotli-dev package
On Fri, 03 Jul 2020 18:45:07 +0900 Mike Hommey
wrote:
..
> Arguably, freetype2.pc shouldn't depend on libbrotlidec.pc except with a
> Required.private, assuming one doesn't actually need to include
> libbrotli headers or link against libbrotli library (presumably, that's
> the case).
The thing is that libbrotli *is* in Requires.private, and pkg-config still
insists on it to exist.
Current (buggy) version:
$ cat /usr/lib/x86_64-linux-gnu/pkgconfig/freetype2.pc
prefix=/usr
exec_prefix=/usr
libdir=/usr/lib/x86_64-linux-gnu
includedir=/usr/include
Name: FreeType 2
URL: https://freetype.org
Description: A free, high-quality, and portable font engine.
Version: 23.2.17
Requires:
Requires.private: zlib, libpng, libbrotlidec
Libs: -L${libdir} -lfreetype
Libs.private:
Cflags: -I${includedir}/freetype2
$ _
As you can see, libbrotlidec is in Requires.private.
Should pkgconfig skip this?
/mjt
Bug#950431: qemu-system-ppc: file conflict between qemu-system-{data, ppc}
01.02.2020 18:53, Adam Borowski wrote: > Package: qemu-system-ppc > Version: 1:4.2-2 > Severity: grave > Justification: renders package uninstallable > > Hi! > Upon upgrading or a fresh install: > > Unpacking qemu-system-ppc (1:4.2-2) ... > dpkg: error processing archive «TMP»/3-qemu-system-ppc_1%3a4.2-2_amd64.deb > (--unpack): > trying to overwrite '/usr/share/qemu/skiboot.lid', which is also in package > qemu-system-data 1:4.2-2 Heh. Heh, heh, heh. I never realized we have this that bad. We never depend on qemu-skiboot package for whatever reason, so I thought there were no skiboot support at all before this, and ofcource haven't noticed the link in qemu-system-ppc... Oh well. Fixed! Thanks, /mjt
Bug#948722: qemu-block-extra, (build-)dependencies unsatisfiable on mipsel.
Control: severity -1 normal Control: tag -1 + moreinfo 12.01.2020 18:37, peter green wrote: > Package: qemu-block-extra > Version: 1:4.2-1 > Severity: serious > > The binary packages built from the ceph source package were recently removed > from mipsel, because the new version of ceph runs out of address space > during the build. Your package build-depends on libradios-dev and librbd-dev > and depends on librados2 and librbd1 which are built from the ceph source > package. So qemu-block-extra is now uninstallable and the qemu source package > is unbuildable on mipsel. Hm. For the start, I see that new ceph packages are being built on mips/mips64 right now as I write this. So things aren't that simple, at least. Next, even if we're now uninstallable on some architecture, it is definitely not our fault, so I don't see why this bugreport is of serious severity. Also, it has nothing to do with this particular version of qemu, either. And more, it has nothing to do with qemu-block-extra package, too, even if that's the only pkg which actually uses the library in question, -- we _build_-depend on librados-dev too, so it is qemu source which FTBFS on mips. So far I don't quite understand what's going on with ceph on mips, hence adding a "moreinfo" tag. We shouldn't drop optional features on different architectures easily, or else it would quickly become a mess, not understanding which features of which packages are enabled on which architecture (I speak here about general debian, not about this particular (pair of) package). > The librados-dev and librbd-dev build-dependencies are arch-qualified as > linux-any, which suggests building with rbd support is optional. If possible > please build your package without rados/rbd support on mipsel. It _is_ possible ofcourse, but it requires to list every other architecture explicitly, for the start. At least I want to be compatible with ceph here, to have the same list as ceph has in their d/control file. Thanks, /mjt
Bug#929067: Support for MDS
20.05.2019 16:07, Salvatore Bonaccorso wrote: Hi FTR, https://salsa.debian.org/qemu-team/qemu/merge_requests/6 for the related changes in unstable (and to target buster). Yeah, I comitted it the same day this issue popped up, but forgot to push it (done now). Thanks! /mjt
Bug#922461: CVE-2018-20124
Control: notfound -1 1:3.1+dfsg-4 16.02.2019 15:41, Moritz Muehlenhoff wrote: Source: qemu Severity: grave Tags: security When rdma was enabled in -3, this also made a fix for CVE-2018-20124 necessary: Yes indeed. But since this code has a ton of bugs (not only security) and is generally quite a bit too "fluxy", I disabled it entirely in -4. https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg02822.html https://git.qemu.org/?p=qemu.git;a=commit;h=0e68373cc2b3a063ce067bc0cc3edaf370752890 Note this is pvrdma, an optimized vmware-like device. RDMA is in migration, not guest visible. So I think this can be closed, or at least be made unimportant, b/c is is only applies to the source code, not to the binary (code is not compiled into binary). $ cat hw/rdma/Makefile.objs ifeq ($(CONFIG_PVRDMA),y) obj-$(CONFIG_PCI) += rdma_utils.o rdma_backend.o rdma_rm.o obj-$(CONFIG_PCI) += vmw/pvrdma_dev_ring.o vmw/pvrdma_cmd.o \ vmw/pvrdma_qp_ops.o vmw/pvrdma_main.o endif Thanks, /mjt
