Bug#983539: false positive (.DEFAULT?) E: debian-rules-missing-required-target
Control: tags -1 - moreinfo On Mon, 2023-01-02 at 22:51 +0100, Axel Beckert wrote: > Control: tag -1 + moreinfo > > Hi John, > > > This package uses Debhelper. What I think causes the false positive is > > that, instead of using a pattern rule like > > %: > > dh $@ > > > > I use the .DEFAULT special target and also call mkdir prior, like: > > .DEFAULT: > > mkdir -p $(unpacked_dir) > > dh $@ -D$(unpacked_dir) -Bbuild > > > > The .DEFAULT special target, unlike pattern rules, is specified by POSIX, > > and as Lintian indicates this is an error, I'd very much appreciate if this > > could be fixed. > > Do I understand it right that ".DEFAULT:" is equivalent to "%:"? When it is used in this particular way with the dh sequencer, my understanding is "yes." The definition of the .DEFAULT special rule in POSIX at https://pubs.opengroup.org/onlinepubs/9799919799/utilities/make.html#tag_20_76_13_04 is what intuition would suggest: it's a rule that gets run when no other rules would apply. The GNU make syntax using the percent symbol is intended to be a more versatile and easy to read replacement for POSIX's suffix rules. The GNU make documentation at /usr/share/doc/make-doc/make.html/Implicit-Rules.html#Last-Resort or https://www.gnu.org/software/make/manual/html_node/Last-Resort.html strongly suggests that the "%: " syntax is equivalent to the ".DEFAULT: " syntax, and this is my experience. This is a GNU extension though, so it's not in any formal specification. This is why I admire the .DEFAULT syntax: it is both more portable and easier to understand. You need not agree with my stylistic opinions, but the case for this syntax choice has enough merit at least that Lintian should be able to cope. -- Homepage https://johnscott.me 着 Contact info • as a vCard: https://johnscott.me/me/me.vcf • as an LDAP directory entry: ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hi Liu, On Fri, 2024-07-26 at 17:09 +0800, Zixing Liu wrote: > > Now you're putting me under pressure. Are you in a hurry? > > No, I am not in a hurry. I just realized I might have made a mistake > by not opening a merge request on Debian Salsa since that may be a > more straightforward solution. > So, I wanted to let you know that I was fixing this mistake. OK, no worries. > Please take as much time as you need to test and upload the fix. I'm > sorry if my wording sounds like I am putting you under pressure, as > English isn't my native language, so miscommunication might have > happened there. > No, it's perfectly fine. I really appreciate your help. I currently have some motivation issues working on Debian but it's getting better now and I want to do it myself to be able to help overcome my mental barrier by forcing myself to do it. Apologies if I sounded harsh. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1077276: obsidian-icon-theme: package is abandoned
Package: obsidian-icon-theme Version: 3.5-1.1 Severity: grave Tags: upstream X-Debbugs-Cc: johnny.faul...@yahoo.com debian...@lists.debian.org debian-desk...@lists.debian.org To whom it may concern, this package is very clearly abandoned. The current version in VCS is 4.5, and such has been stuck there since 2019. Obsidian Icon Theme itself is on Version 4.15, and every other distro that packages it has had this version for almost 2 years. I cannot, in good faith, continue to let this abandonment go on, so I am filing a blocking bug until something gets done about it. -John
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hello, On Fri, 2024-07-26 at 12:14 +0800, Zixing Liu wrote: > I have also prepared > https://salsa.debian.org/debian/hfsutils/-/merge_requests/2 if you are > having issues with your local Git tree. > You can verify the merge with the version I uploaded to > https://mentors.debian.net/debian/pool/main/h/hfsutils/hfsutils_3.2.6-17.dsc. Now you're putting me under pressure. Are you in a hurry? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1074838: bcmatroska2 FTBFS mostly fixed upstream
Control: forwarded -1 https://gitlab.linphone.org/BC/public/bcmatroska2/-/commit/7e7e7d0d7037f29624b32d814e83aa2ce978c29f Control: tags -1 upstream fixed-upstream GCC 14 is right to treat the issue as an error: calling a function via a function pointer of incompatible type is undefined behavior (and I am assuming here that the function pointer is actually getting used, or else it could be replaced with NULL), and in particular the prototypes switch between passing pointers versus double pointers to different types as arguments. In theory this could cause all sorts of trouble particularly for the less common architectures or when new optimization features are added. For now, upstream has decided to simply add a cast to suppress the error. This isn't really any worse than the status quo since GCC versions before GCC 13 were happy to do the implicit conversion, but I'd nevertheless like to point out that this doesn't solve the underlying issue that GCC was correct to flag. -- Homepage https://johnscott.me 着 Contact info • as a vCard: https://johnscott.me/me/me.vcf • as an LDAP directory entry: ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1077042: gcc-14: FTBFS on m68k due to segfault compiling unwind-dw2.c
Source: gcc-14 Version: 14.1.0-5 Severity: normal Tags: upstream User: debian-...@lists.debian.org Usertags: m68k X-Debbugs-Cc: debian-...@lists.debian.org Hi, gcc-14 fails to build from source on m68k due to the compiler segfaulting when compiling unwind-dw2.c. This issue is already being tracked upstream [1], I'm just reporting this bug to raise more awareness and help track the issue within Debian. Thanks, Adrian > [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076582: initramfs-tools-core: mkinitramfs failure zstd -q -9 -T0 70 (No space left on device)
Installing initramfs-tools_0.143_all.deb and initramfs-tools-core_0.143_all.deb (plus dependency dracut-install) seems to have fixed the issue for me too (although I haven't rebooted yet). I had to run "update-initramfs -k all -u" to get it to regenerate the previous kernels, apt only managed the latest one. On an nvidia+mediatek+intel+realtek system I now have: -rw-r--r-- 1 root root 108M Jul 25 00:15 initrd.img-6.9.10-amd64 -rw-r--r-- 1 root root 108M Jul 25 00:15 initrd.img-6.9.9-amd64 Thanks! -- Simon John
Bug#1069000: Issue might be fixed in the latest secrets
On Tue, 16 Jul 2024 11:09:17 +0200 1...@gmx.us wrote: > If you can confirm, then this issue can be closed. Latest version of secrets in debian now can be used to test. > Secrets 9.6-1/unstable still fails the same way outlined previously here. Reverting to the a backup of the .kdbx file allows auth to complete successfully. -- john
Bug#1076564: pahole BTF processing seems flaky on powerpc
Hi Ben, On Mon, 2024-07-22 at 00:07 +0200, Ben Hutchings wrote: > I don't know what differences there are between these builders that > might be relevant. For kapitsa, the installed host system is powerpc while all the others run the ppc64 port. As for the hardware: kapitsa runs bare-metal (inside an LPAR) on a POWER8 machine: root@kapitsa:~# grep model /proc/cpuinfo model : IBM,8284-22A root@kapitsa:~# Both blaauw and perotto are KVMs running on watson which runs Debian's ppc64el port (little-endian): root@watson:~# grep model /proc/cpuinfo model : 8247-42L root@watson:~# root@blaauw:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@blaauw:~# root@perotto:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@perotto:~# Both debian-project-be-01 and debian-project-be-02 are KVMs running on OpenStack at OSUOSL's OpenPOWER platform: root@debian-project-be-1:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@debian-project-be-1:~# root@debian-project-be-2:~# grep model /proc/cpuinfo model : IBM pSeries (emulated by qemu) root@debian-project-be-2:~# Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076582: initramfs-tools-core: mkinitramfs failure zstd -q -9 -T0 70 (No space left on device)
I was hit by this the other day, I have a couple of systems built using Bullseye's suggested 500mb /boot for encrypted root. I now can't even fit 2 kernels. MODULES=dep makes almost no difference - 10mb smaller? I even tried reducing the ext4 reserved space from 5% to 0, which is far from ideal and still didn't free up enough space. Purging firmware-ath9k-htc firmware-carl9170 amd64-microcode firmware-amd-graphics and firmware-intel-graphics didn't help - plus if i ever want to add wifi or switch to an amd/intel graphics card i'm going to be in trouble. zstd I noticed is now being used, that should make things smaller not bigger, is that new, did something go wrong there? I use nvidia and plymouth which is the standard desktop install with a graphical cryptsetup prompt and I'm having the same problem on my intel-only laptop, so not just an nvidia thing (unless its installed but not used). I went through the pain of shrinking a LUKS root to make a bigger /boot and now I find a 1gb /boot can't fit 3 kernels! Part of the problem is the initrd.img-6.9.9-amd64.dpkg-bak and initrd.img-6.9.9-amd64.new files mean that you've got to have enough room for 3x the latest kernel, plus one of any previous kernels, so for a typical three kernel install that's now 5x 237mb plus vmlinuz and stuff, we're talking 1300mb absolute minimum. Given that the initrd's have almost tripled in size, this is going to cause chaos when Trixie becomes stable - everyone will have to reinstall with a 2gb /boot and there will be no upgrade path. Looking at some backups, its not the fault of the 6.9 kernels, just something that happened around the time of their release: -rw-r--r-- 1 root root 237M Jul 21 02:17 initrd.img-6.9.10-amd64 -rw-r--r-- 1 root root 237M Jul 19 11:59 initrd.img-6.9.9-amd64 -rw-r--r-- 1 root root 85M Jul 8 17:23 initrd.img-6.9.8-amd64 -rw-r--r-- 1 root root 85M Jul 7 23:32 initrd.img-6.9.7-amd64 -rw-r--r-- 1 root root 85M Jun 19 18:20 initrd.img-6.8.12-amd64 -rw-r--r-- 2 root root 85M Jun 7 13:32 initrd.img-6.8.11-amd64 On https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972396 there's a suggested patch to use mktemp to move the .new temp file to /tmp but that only partially helps as you still have .dpkg-bak Realistically we need a fix for whatever happened here and it can't be any of: * remove plymouth or firmware (not practical for desktop) * make /boot bigger (not upgrade friendly) * MODULES=dep (not effective) As for updating the docs and installer - my bookworm stable box has two 6.1 kernels in a 471mb /boot with room for a couple more, so -- Simon John
Bug#1076564: pahole BTF processing seems flaky on powerpc
On Sat, 2024-07-20 at 21:17 +0200, Ben Hutchings wrote: > I had a go yesterday and ran into the same problem. I couldn't > reproduce with a small kernel config (allnoconfig + BPF + DEBUG_INFO + > DEBUG_INFO_BTF) and there wasn't enough disk space to build even one of > the Debian kernel flavours. > > > Will take care of it and let you know when it's (some hours). > > Thank you! There are now 120 GB of free disk space. Let me know if that's sufficient or whether I need to clean up more, probably asking others to clean up their home directories. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076564: pahole BTF processing seems flaky on powerpc
Hi Domenico, On Fri, 2024-07-19 at 23:20 +0200, Domenico Andreoli wrote: > > > Is there anything I can do to help? > > > > From the 6.10-1~exp1: > > https://buildd.debian.org/status/fetch.php?pkg=linux=powerpc=6.10-1%7Eexp1=1721287862=1 > > file: > > > > + LLVM_OBJCOPY=powerpc-linux-gnu-objcopy pahole -J -j > > --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func > > --lang_exclude=rust .tmp_vmlinux.btf > > > > Can I have access to that .tmp_vmlinux.btf file so that I can try to > > reproduce it here? > > I don't have access to the build host (blaauw2) and I've some doubts > it would still have that file. > > Maybe our kernel team and powerpc porters have suggestions? I have root access to all powerpc/ppc64 machines (buildds and porterbox). I'm cleaning up the porterbox now, disk is quite full, then you can try to build the kernel package on perotto.debian.net or I can try it myself. I have seen the bug myself and I wanted to debug it, but the attempt was foiled by the fact that the disk on perotto is full (again). Will take care of it and let you know when it's (some hours). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076512: Info received (Bug#1076512: Info received (Bug#1076512: Acknowledgement (glibc: FTBFS on hppa - stdlib/tst-swapcontext2 test fails)))
Upstream patch: https://sourceware.org/pipermail/libc-alpha/2024-July/158419.html BZ: https://sourceware.org/bugzilla/show_bug.cgi?id=31989 Regard, Dave -- John David Anglin dave.ang...@bell.net
Bug#1076512: Info received (Bug#1076512: Acknowledgement (glibc: FTBFS on hppa - stdlib/tst-swapcontext2 test fails))
There are more problems of the same nature in glibc source: dave@atlas:~/gnu/glibc/glibc$ find . -type f|xargs grep _STACK_GROWS|grep ifdef ./malloc/memusage.c:#ifdef _STACK_GROWS_UP ./include/stackinfo.h:# ifdef _STACK_GROWS_UP ./include/stackinfo.h:# ifdef _STACK_GROWS_DOWN ./sysdeps/unix/sysv/linux/longjmp_chk.c:#ifdef _STACK_GROWS_DOWN ./include/stackinfo.h is okay but the other two usages of these defines look wron. Dave -- John David Anglin dave.ang...@bell.net
Bug#1076536: wireshark: Please ignore tests on big-endian architectures in Debian Ports
Source: wirkshark Version: 4.2.6-1 Severity: normal User: debian-powe...@lists.debian.org Usertags: powerpc ppc64 X-Debbugs-Cc: debian-powe...@lists.debian.org Hello, like on s390x, some tests are failing on powerpc, ppc64 and sparc64: > https://buildd.debian.org/status/fetch.php?pkg=wireshark=powerpc=4.2.6-1=1720790838=0 > https://buildd.debian.org/status/fetch.php?pkg=wireshark=ppc64=4.2.6-1=1720785055=0 > https://buildd.debian.org/status/fetch.php?pkg=wireshark=sparc64=4.2.6-1=1720858739=0 Could you ignore the tests on all big-endian architectures in Debian Ports? These are: - hppa - m68k - powerpc - ppc64 - sparc64 Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076512: Acknowledgement (glibc: FTBFS on hppa - stdlib/tst-swapcontext2 test fails)
It's a bug in the test. The attached patch fixes the failure on hppa.
This happened once before...
Regards,
Dave Anglin
--
John David Anglin dave.ang...@bell.net
diff --git a/stdlib/tst-swapcontext2.c b/stdlib/tst-swapcontext2.c
index f679755649..a9c1dc827c 100644
--- a/stdlib/tst-swapcontext2.c
+++ b/stdlib/tst-swapcontext2.c
@@ -85,7 +85,7 @@ do_test (void)
{
/* longjmp_chk has */
#if 0
-#ifdef _STACK_GROWS_DOWN
+#if _STACK_GROWS_DOWN
#define called_from(this, saved) ((this) < (saved))
#else
#define called_from(this, saved) ((this) > (saved))
@@ -98,7 +98,7 @@ do_test (void)
/* Arrange stacks for uctx_func1 and uctx_func2 so that called_from
is true when setjmp is called from uctx_func1 and longjmp is called
from uctx_func2. */
-#ifdef _STACK_GROWS_DOWN
+#if _STACK_GROWS_DOWN
# define UCTX_FUNC1_STACK 1
# define UCTX_FUNC2_STACK 0
#else
Bug#1076512: glibc: FTBFS on hppa - stdlib/tst-swapcontext2 test fails
Source: glibc Version: 2.39-4 Severity: normal Tags: ftbfs Dear Maintainer, Build filas here: -- FAIL: stdlib/tst-swapcontext2 original exit status 1 [31mfunc1: func3(_func1, _main, str1)[0m [31mfunc3: func4(uocp, ucp, str)[0m [31mfunc4: [31mswapcontext(_func1, _main)[0m[0m [35mmain: swapcontext(_main, _func2) [0m [34mfunc2: func3(_func2, _main, str2)[0m [34mfunc3: func4(uocp, ucp, str)[0m [34mfunc4: [34mswapcontext(_func2, _main)[0m[0m [35mmain: swapcontext(_main, _func1) [0m [31mfunc4: returning[0m [31mfunc3: returning[0m [31mfunc1: func3(_func1, _main, str1)[0m [31mfunc3: func4(uocp, ucp, str)[0m [31mfunc4: [31mswapcontext(_func1, _main)[0m[0m [35mmain: swapcontext(_main, _func2) [0m [34mfunc4: returning[0m [34mfunc3: returning[0m [34mfunc2: calling longjmp[0m Didn't expect signal from child: got `Aborted' -- +-+ | Encountered regressions that don't match expected failures. | +-+ FAIL: stdlib/tst-swapcontext2 touch /<>/stamp-dir/check_libc CHECK SUMMARY check for check_libc failed Full log is here: https://buildd.debian.org/status/fetch.php?pkg=glibc=hppa=2.39-4=1721152208=0 dave@atlas:~/gnu/glibc/objdir/stdlib$ ./tst-swapcontext2 func1: func3(_func1, _main, str1) func3: func4(uocp, ucp, str) func4: swapcontext(_func1, _main) main: swapcontext(_main, _func2) func2: func3(_func2, _main, str2) func3: func4(uocp, ucp, str) func4: swapcontext(_func2, _main) main: swapcontext(_main, _func1) func4: returning func3: returning func1: func3(_func1, _main, str1) func3: func4(uocp, ucp, str) func4: swapcontext(_func1, _main) main: swapcontext(_main, _func2) func4: returning func3: returning func2: calling longjmp *** longjmp causes uninitialized stack frame ***: terminated Didn't expect signal from child: got `Aborted' This bug is enabled by the --enable-fortify-source configure option. This needs more research to determine whether this fail is caused by a real problem (hppa is the only architecure where the stack grows upward). I think for now we should xfail the test. Regards, Dave Anglin -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 6.9.9-dirty (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hello Liu, On Mon, 2024-07-01 at 20:05 +0200, John Paul Adrian Glaubitz wrote: > > After digging through the Debian BTS, I can see the patch may fix > > #421457 in BTS. > > Maybe you can edit my changelog entry to indicate that. > > Thanks for the suggestion. I will have a look. Sorry for not getting this > fixed, > there was a lot of work to be done in June. I have started working on this now and I just realized I messed a bit up in my packaging source git tree. So, it might take me a little longer to get this properly fixed up. I will import for patch crediting you, so thanks a lot for fixing this issue! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#972396: Comment on «initramfs-tools: Installation fails (no space left on device)»
John Mullee's patch still doesn't fix the issue, as although the cpio is created in /tmp, you still have /boot/initrd.img-6.9.9-amd64.dpkg-bak So my pc upgraded from bullseye to Sid with a 500mb /boot (default luks install - no uefi) now can only fit a single kernel 6.9.9, even with MODULES=dep set we're talking 219M of space used. So I have no choice but to rebuild with >1gb /boot, unless i can figure out how to shrink luks / and grow /boot -- Simon John
Bug#1076424: ausweisapp: UI does not show
Hello Maximilian, On Tue, 2024-07-16 at 10:02 +0200, Maximilian Stein wrote: > I am using KDE on Debian testing and just tried to install and use the > ausweisapp. > > However, I cannot get a UI: When starting the program, the tray icon > appears alongside a notification that the application has been > started. Neither double clicking the tray icon nor right click + open > brings up the UI. Moreover, I tried to run `AusweisApp --show`, > without success. > > The log contains a couple of warnings: > > default 2024.07.16 09:49:52.433 13780 W (:0) >: QQmlApplicationEngine failed to > load component > default 2024.07.16 09:49:52.433 13780 W > (/qt/qml/Governikus/Init/App.qml:483) : > qrc:/qt/qml/Governikus/Init/App.qml:483:4: Type DetachedLogView unavailable > default 2024.07.16 09:49:52.433 13780 W > (/qt/qml/Governikus/FeedbackView/DetachedLogView.qml:16) : > qrc:/qt/qml/Governikus/FeedbackView/DetachedLogView.qml:16:2: Cannot override > FINAL property > > So, maybe there is a dependency missing? This is a known issue that occurs when using AusweisApp 2.2.0 with Qt 6.6.0. It will be fixed in the upcoming 2.2.1 release. If upstream doesn't release this version in a timely fashion, I am going to backport the patch that fixes the issue. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1076312: /usr/bin/filezilla: Illegal instruction generated on startup
Andreas wrote: > the sse4.1 requirement seems to have been added as a workaround for some > other problem specifically on the i386 architecture, but I will investigate > and try to provide a fix. Let me know if you want a hand or for me to look over anything: I know a thing or two about GCC, in particular with building cross toolchains with it. Also note that since the build flags are injected in both Bookworm and Trixie/Sid, you'll probably need to work on two fixes. The alleged GCC bug may have been fixed in newer GCC 13 uploads. If that's the case, I can help you bisect to set an appropriate build dependency on a fixed version. If no fixed GCC 13 appears to be packaged, the GCC maintainers could probably apply a patch to Bookworm and Trixie/Sid, and then a tight build dependency would save the day. I'll leave you to doing what you've got to do, but I'm here. -- Homepage https://johnscott.me 着 Contact info • as a vCard: https://johnscott.me/me/me.vcf • as an LDAP directory entry: ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1030657: libbpfcc-dev: Why is the list of build architectures limited?
Source: bpfcc Version: 0.26.0+ds-1 Followup-For: Bug #1030657 Hi, looking at [1], the list of architectures is still very limited. Can we at least enable bpfcc on all architectures in Debian Ports? Since Debian Ports is not an officially supported distribution, there shouldn't be any concerns with regressions and bugs once they arise. If the lack of personal time to be able to spend on this package, I would suggest creating a bug report to request for help (RFH). Thanks, Adrian > [1] https://buildd.debian.org/status/package.php?p=bpfcc=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1060195: hfsprogs: install files into /usr (DEP17)
Hello, > On Jul 13, 2024, at 12:39 PM, Chris Hofstaedtler wrote: > > On Sun, Jan 07, 2024 at 12:07:02PM +0100, Chris Hofstaedtler wrote: >> Source: hfsprogs >> Version: 540.1.linux3-5 > [..] >> Please find a patch attached to install aliased files into /usr, >> for the currently ongoing UsrMerge effort [1]. > > Friendly reminder about this bug. > > Please consider fixing it soon. Did not notice this before. Will fix it this weekend. Adrian
Bug#1076046: wxwidgets3.2: FTBFS on hppa - tests depend on python3-greenlet
Source: wxwidgets3.2 Version: 3.2.5+dfsg-1 Severity: normal Tags: ftbfs patch Dear Maintainer, The wxwidgets3.2 testsuite depends python3-httpbin. python3-httpbin depends on python3-greenlet. python3-greenlet currently has only been ported to architectures where the stack grows down. The attached patch disables the wxwidgets3.2 testsuite on hppa and removes the dependency on python3-httpbin for hppa. With this change, the wxwidgets3.2 package builds successfully on hppa: https://buildd.debian.org/status/fetch.php?pkg=wxwidgets3.2=hppa=3.2.5%2Bdfsg-1%2Bb1=1720556377=0 Please install or a similar fix. Regards, Dave Anglin -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 6.10.0-rc6+ (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) --- control.save2024-07-09 15:37:13.906265388 + +++ control 2024-07-09 15:40:35.412571357 + @@ -21,7 +21,7 @@ libwebkit2gtk-4.1-dev, libxt-dev, locales-all , - python3-httpbin , + python3-httpbin [!hppa] , xauth , xvfb , zlib1g-dev, --- rules.save 2024-07-09 15:37:21.802200659 + +++ rules 2024-07-09 15:42:41.135501422 + @@ -2,6 +2,10 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all +ifneq (,$(filter $(DEB_HOST_ARCH), hppa)) +export DEB_BUILD_OPTIONS=nocheck +endif + include /usr/share/dpkg/buildopts.mk TEST_FILTER = ~[.]
Bug#1075915: network-manager: FTBFS on hppa - check-local-tests-client test times out
Source: network-manager Version: 1.48.4-1 Severity: normal Tags: ftbfs patch Dear Maintainer, The build fails here: === 73/73 test: check-local-tests-client start time: 21:36:42 duration: 120.18s result: killed by signal 15 SIGTERM command: ASAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1 LIBTOOL='' UBSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MSAN_OPTIONS=halt_on_error=1:abort_on_error=1:print_summary=1:print_stacktrace=1 MALLOC_PERTURB_=93 /<>/src/tests/client/test-client.sh /<>/obj-hppa-linux-gnu /<> /usr/bin/python3 -- TestNmcli == Summary of Failures: 73/73 check-local-tests-clientTIMEOUT 120.18s killed by signal 15 SIGTERM Ok: 72 Expected Fail: 0 Fail: 0 Unexpected Pass:0 Skipped:0 Timeout:1 dh_auto_test: error: cd obj-hppa-linux-gnu && DEB_PYTHON_INSTALL_LAYOUT=deb LC_ALL=C.UTF-8 MESON_TESTTHREADS=4 meson test returned exit code 1 Full log is here: https://buildd.debian.org/status/fetch.php?pkg=network-manager=hppa=1.48.4-1=1720301948=0 I changed the timeout for the test to 240 seconds and the test passes: 73/73 check-local-tests-clientOK 132.97s Ok: 73 Expected Fail: 0 Fail: 0 Unexpected Pass:0 Skipped:0 Timeout:0 Full log is here: https://buildd.debian.org/status/fetch.php?pkg=network-manager=hppa=1.48.4-1=1720379156=0 Attached is a patch to change the timeout for the test. Please install. Regards, Dave Anglin -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 6.10.0-rc6+ (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Index: network-manager-1.48.4/src/tests/client/meson.build === --- network-manager-1.48.4.orig/src/tests/client/meson.build +++ network-manager-1.48.4/src/tests/client/meson.build @@ -13,7 +13,7 @@ test( env: [ 'LIBTOOL=', ], - timeout: 120, + timeout: 240, ) if enable_nm_cloud_setup
Bug#1075913: allow listing only those changes of a particular urgency or greater
Package: apt-listchanges Severity: wishlist Hello, It appears that although apt-listchanges allows sorting changelog entries based on urgency, it doesn't have a way to select or filter based on urgency. There are a few instances where I would find this very useful, but the main one is for examining changes in packages prior to deciding to install them. For example, apticron is a utility that uses apt-listchanges to nag an administrator to install updates. I use this on my virtual private server so it can tell me when I should install updates by logging in via secure shell. Especially since my server is running Trixie/testing for right now, updates are very frequent but the changes are most often unimportant to my usage. I would only like to be nagged to install updates with urgency that is high or greater. The apt-listchanges manual page specifies that one can define "profiles" in the configuration file so that, when apt-listchanges is invoked by different callers, its output can be tailored appropriately. If only apt-listchanges had a "minimum_urgency" key, I could define that changelogs for apticron should only be displayed with high or greater urgency. Please note that the version in experimental is the same, although I see it has been heavily reworked and kudos to you for taking up the package! This is also different from #939287 in that this bug is about using urgency as a filter or selector so that some changelogs don't get shown, whereas that bug is about formatting and sorting the output to help make it easy to read for humans. If you prepare a change, I'll be happy to give it a whirl before you upload it if you want a tester. Thanks, John -- Homepage https://johnscott.me 着 Contact info • as a vCard: https://johnscott.me/me/me.vcf • as an LDAP directory entry: ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
Hi Otto, On Fri, 2024-07-05 at 23:00 -0700, Otto Kekäläinen wrote: > Thanks for the tips. Unfortunately running just the single test > without any other load on the system still crashes it and system load > was otherwise zero, so it is not due to slowness. Single-core performance on SPARC is rather poor, especially on older SPARC systems like this SPARC T4. So, if this test requires reasonanbly high single-core performance, you know why it fails on SPARC. We might get a newer, faster SPARC buildd in the near future though. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#914040: Evolution failing to parse GnuPG output fixed upstream in libcamel (from src:evolution-data-server package)
Control: reassign -1 libcamel-1.2-64t64 3.50.3-1.1~exp1 Control: found -1 3.52.3-1 Control: affects -1 evolution Control: forwarded -1 https://gitlab.gnome.org/GNOME/evolution-data-server/-/issues/537 Control: tags -1 upstream fixed-upstream patch This is an issue I reported years ago about Evolution failing to display OpenPGP mails after decryption sometimes. It turns out that it's actually a race condition which is more likely to occur on machines with fewer processors. Since Evolution parses the output of GnuPG "by hand" instead of using a helper like GPGME, this code has always been fragile and upgrading GnuPG between major releases, for example, may affect the timing to affect the chance of this happening. Anywho, I was able to apply this commit cleanly to the 3.52.3-1 Debian package and it worked like a charm: https://gitlab.gnome.org/GNOME/evolution-data-server/-/commit/76c733d5 This fix is in evolution-data-server 3.53.1 which hasn't yet been packaged for Debian. I haven't tried it, but for whatever my opinion is worth, I'm leaning away from applying this in Bookworm. On the one hand the change is small and the bug is affecting other packages as well as Evolution in mysterious ways that are difficult to debug, but on the other hand I haven't seen many other reports of this same issue. Please let me know if I can be of further assistance and please consider packaging the new upstream release if you can get around to it. Thank you! -- Homepage https://johnscott.me 着 Contact info • as a vCard: https://johnscott.me/me/me.vcf • as an LDAP directory entry: ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1074766: openssh-server: upgrading to openssh-server (1:9.2p1-2+deb12u3) resets /etc/ssh/sshd_config file without any prompt
I might have an idea of what could have happened: how does the packager know that the file is different from the previous package's default version? While I upgraded other packages on another server today I noticed something in my own behaviour: when there are modifications on a package file and I'm asked what I want to do I always choose to open a terminal, then I use vimdiff to merge the differences but sometimes, depending on the amount of changes, I will pull the changes inside the new version, save that version, exit the terminal and then choose "Install the maintainer's version" (knowing that I modified it with the changes I wanted to keep)... So if the packager uses the modified file stats/content as a basis it might explain why it didn't prompt me... Could that be it? On Tue, Jul 2, 2024 at 5:50 PM John Wellesz wrote: > Hello Colin, > > Here is the output of apt/term.log: > > Log started: 2024-07-02 00:04:13 > (Reading database ... 64456 files and directories currently installed.) > Preparing to unpack .../openssh-sftp-server_1%3a9.2p1-2+deb12u3_amd64.deb > ... > Unpacking openssh-sftp-server (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2) > ... > Preparing to unpack .../openssh-server_1%3a9.2p1-2+deb12u3_amd64.deb ... > Unpacking openssh-server (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2) ... > Preparing to unpack .../openssh-client_1%3a9.2p1-2+deb12u3_amd64.deb ... > Unpacking openssh-client (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2) ... > Setting up openssh-client (1:9.2p1-2+deb12u3) ... > Setting up openssh-sftp-server (1:9.2p1-2+deb12u3) ... > Setting up openssh-server (1:9.2p1-2+deb12u3) ... > Replacing config file /etc/ssh/sshd_config with new version > rescue-ssh.target is a disabled or a static unit not running, not starting > it. > ssh.socket is a disabled or a static unit not running, not starting it. > Processing triggers for man-db (2.11.2-2) ... > Processing triggers for ufw (0.36.2-1) ... > Log ended: 2024-07-02 00:04:16 > > I've attached the sshd_config from my last week backup, I've just changed > the port number I use to a random one. > > I had the same problem on 4 different servers I upgraded last night. Maybe > it's not related to openssh-server and I just noticed the problem on this > package... > > Also note that I've recently enabled apt-listchange prompting on all these > servers: > > cat /etc/apt/listchanges.conf > [apt] > frontend=pager > which=both > email_address=root > email_format=html > confirm=true > headers=false > reverse=false > save_seen=none > no_network=false > > Here is the command I used to check and apply security updates: > > sudo apt update && sudo apt dist-upgrade -V && sudo apt autoremove -y > > Regards, > > John Wellesz > > On Tue, Jul 2, 2024 at 5:24 PM Colin Watson wrote: > >> On Tue, Jul 02, 2024 at 03:05:16PM +, John Wellesz wrote: >> > I used apt upgrade to install the security update available for >> > openssh-server >> > >> >* What was the outcome of this action? >> > >> > It overwrote /etc/ssh/sshd_config without promtping, erasing the custom >> settings >> > and almost locking me out as a result (my custom port setting was gone >> > as well as other changes I've made). >> > >> >* What outcome did you expect instead? >> > >> > I expected to receive the usual prompt when a configuration file is >> > modified asking me what I want to do but there was none. >> >> We'll need to be able to reproduce this problem before being able to do >> anything about it. (I have a modified /etc/ssh/sshd_config on my own >> stable system and it wasn't overwritten on upgrade.) >> >> Can you please provide a copy of your modified /etc/ssh/sshd_config, >> along with the output of the relevant apt run (which should be preserved >> in /var/log/apt/term.log)? >> >> -- >> Colin Watson (he/him) [cjwat...@debian.org] >> >
Bug#1075775: please package new upstream release 2.6.0 or greater to possibly support many new transit providers
Source: railway-gtk Version: 2.4.0-4 Severity: wishlist Hi friends, New versions of Railway appear to have added support for not only new transit routes, but also new services to discover transit routes. The current packaged version is geared towards rail travel in Europe, but it appears that the new version should be capable of public transportation more broadly, especially in the United States. Given that Google Maps alternatives such as OpenStreetMap are already uncommon in the US, I think this new upstream release could be a giant leap forward in breaking up the monoculture. At least for the large American bus network around me, it doesn't seem like there's any practical way to navigate it using free software. There are plans to change it, but for now public transit support in GNOME Maps is basically a patchwork that (I think) only covers a single US city. Thus I think that letting users get their feet wet with possibilities will also motivate discussions for the rest of the ecosystem to improve. I'm a Debian Maintainer for unrelated packages and have made small merge requests to GNOME packages before, so although it would be ambitious, please let me know if you'd like me to try this. Thanks -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unreleased'), (500, 'testing-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, arm64 Kernel: Linux 6.8.12-amd64 (SMP w/2 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER, TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1075730: goldencheetah: FTPFS on hppa - ‘class ANTLogger’ has no member named ‘open64’
Source: goldencheetah Version: 1:3.5-6 Severity: normal Tags: ftbfs Dear Maintainer, Build fails here: g++ -c -pipe -Wno-unused-variable -Wno-sign-compare -g -O2 -ffile-prefix-map=/<>=. -Wformat -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -Wextra -D_REENTRANT -fPIC -DGC_VIDEO_VLC -DGC_VERSION=\"3.5-DEV1810\" -DQXT_STATIC -DGC_HAVE_KML -DGC_HAVE_ICAL -DGC_HAVE_LIBUSB -DGC_HAVE_VLC -DGC_HAVE_OVERVIEW -DQT_NO_DEBUG -DQT_SVG_LIB -DQT_MULTIMEDIAWIDGETS_LIB -DQT_WEBKITWIDGETS_LIB -DQT_CHARTS_LIB -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DQT_MULTIMEDIA_LIB -DQT_WEBKIT_LIB -DQT_GUI_LIB -DQT_XML_LIB -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_CONCURRENT_LIB -DQT_SERIALPORT_LIB -DQT_BLUETOOTH_LIB -DQT_CORE_LIB -I. -IANT -ITrain -IFileIO -ICloud -ICharts -IMetrics -IGui -ICore -IPlanning -I../qwt/src -I../qxt/src -I../qtsolutions/json -I../qtsolutions/qwtcurve -I../lmfit -I../levmar -I/usr/include -I/usr/include/libical -I/usr/include -I/usr/include/vlc -I/usr/include/hppa-linux-gnu/qt5 -I/usr/include/hppa-linux-gnu/qt5/QtSvg -I/usr/include/hppa-linux-gnu/qt5/QtMultimediaWidgets -I/usr/include/hppa-linux-gnu/qt5/QtWebKitWidgets -I/usr/include/hppa-linux-gnu/qt5/QtCharts -I/usr/include/hppa-linux-gnu/qt5/QtOpenGL -I/usr/include/hppa-linux-gnu/qt5/QtWidgets -I/usr/include/hppa-linux-gnu/qt5/QtMultimedia -I/usr/include/hppa-linux-gnu/qt5/QtWebKit -I/usr/include/hppa-linux-gnu/qt5/QtGui -I/usr/include/hppa-linux-gnu/qt5/QtXml -I/usr/include/hppa-linux-gnu/qt5/QtSql -I/usr/include/hppa-linux-gnu/qt5/QtNetwork -I/usr/include/hppa-linux-gnu/qt5/QtConcurrent -I/usr/include/hppa-linux-gnu/qt5/QtSerialPort -I/usr/include/hppa-linux-gnu/qt5/QtBluetooth -I/usr/include/hppa-linux-gnu/qt5/QtCore -I. -I/usr/lib/hppa-linux-gnu/qt5/mkspecs/linux-g++ -o moc_Aerolab.o moc_Aerolab.cpp moc_ANTLogger.cpp: In static member function ‘static void ANTLogger::qt_static_metacall(QObject*, QMetaObject::Call, int, void**)’: moc_ANTLogger.cpp:86:21: error: ‘class ANTLogger’ has no member named ‘open64’; did you mean ‘open’? 86 | case 1: _t->open64(); break; | ^~ | open make[2]: *** [Makefile:271657: moc_ANTLogger.o] Error 1 Full log is here: https://buildd.debian.org/status/fetch.php?pkg=goldencheetah=hppa=1%3A3.5-6=1719870870=0 sh fails in the same way: https://buildd.debian.org/status/fetch.php?pkg=goldencheetah=sh4=1%3A3.5-6=1719731500=0 Regards, Dave Anglin -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 6.10.0-rc6+ (SMP w/4 CPU threads) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1074558: mariadb: FTBFS on sparc64: Multiple tests crash / time out
Hello Otto, On Tue, 2024-07-02 at 21:10 -0700, Otto Kekäläinen wrote: > I recently uploaded MariaDB 11.4 to Debian, and it seems it regressed > on sparc64. > > Are there any sparc64 hackers interested in taking a look? > > The build itself passed and most of the post-build passes, but some > tests cause the database to crash. Stack traces are visible in the > logs: > > https://buildd.debian.org/status/fetch.php?pkg=mariadb=sparc64=1%3A11.4.2-2=1719891893=0 > https://buildd.debian.org/status/logs.php?pkg=mariadb=sparc64 I would suggest rerun the build plus testsuite on the porterbox stadler with glibc debug packages installed in the chroot so you can get a more usable backtrace. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#972396: [PATCH] fix 'no space left on device' : use mktemp to avoid boot partition
diff --git a/update-initramfs b/update-initramfs
index 4bb8d8a..5fe7921 100755
--- a/update-initramfs
+++ b/update-initramfs
@@ -138,15 +138,16 @@ generate_initramfs()
if [ "${verbose}" = 1 ]; then
OPTS="-v ${OPTS}"
fi
+ initramfs_tmp=$(mktemp)
# shellcheck disable=SC2086
- if mkinitramfs ${OPTS} "${initramfs}.new" "${version}"; then
- mv -f "${initramfs}.new" "${initramfs}"
+ if mkinitramfs ${OPTS} "${initramfs_tmp}" "${version}"; then
+ mv -f "${initramfs_tmp}" "${initramfs}"
# Guard against an unclean shutdown
sync -f "${initramfs}"
else
mkinitramfs_return="$?"
remove_initramfs_bak
- rm -f "${initramfs}.new"
+ rm -f "${initramfs_tmp}"
echo "update-initramfs: failed for ${initramfs} with $mkinitramfs_return."
>&2
exit $mkinitramfs_return
fi
--
2.25.1
Bug#1074363: monitoring-plugins-check-smart: Don't depend on nagios-nrpe-server
A good point - I will switch this to a Recommends: which will allow installation on an icinga2 or nagios server. On Thu, 2024-06-27 at 11:57 +0200, Frederik Himpe wrote: > Source: monitoring-plugins-check-smart > Version: 6.14.1-2 > Severity: normal > > Dear Maintainer, > > check_smart.pl can be ran locally or from an icinga2 agent, without > nagios-nrpe-server, so it should not have a hard dependency on > nagios-nrpe-server. > > -- System Information: > Debian Release: 12.5 > APT prefers stable-security > APT policy: (810, 'stable-security'), (810, 'stable'), (809, > 'proposed-updates'), (710, 'oldstable-security'), (710, 'oldstable'), > (709, 'oldstable-proposed-updates'), (310, 'testing'), (200, > 'unstable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.6.32-frehi12 (SMP w/12 CPU threads; PREEMPT) > Kernel taint flags: TAINT_UNSIGNED_MODULE > Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), > LANGUAGE=en_IE:en > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled
Bug#1074766: openssh-server: upgrading to openssh-server (1:9.2p1-2+deb12u3) resets /etc/ssh/sshd_config file without any prompt
Hello Colin, Here is the output of apt/term.log: Log started: 2024-07-02 00:04:13 (Reading database ... 64456 files and directories currently installed.) Preparing to unpack .../openssh-sftp-server_1%3a9.2p1-2+deb12u3_amd64.deb ... Unpacking openssh-sftp-server (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2) ... Preparing to unpack .../openssh-server_1%3a9.2p1-2+deb12u3_amd64.deb ... Unpacking openssh-server (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2) ... Preparing to unpack .../openssh-client_1%3a9.2p1-2+deb12u3_amd64.deb ... Unpacking openssh-client (1:9.2p1-2+deb12u3) over (1:9.2p1-2+deb12u2) ... Setting up openssh-client (1:9.2p1-2+deb12u3) ... Setting up openssh-sftp-server (1:9.2p1-2+deb12u3) ... Setting up openssh-server (1:9.2p1-2+deb12u3) ... Replacing config file /etc/ssh/sshd_config with new version rescue-ssh.target is a disabled or a static unit not running, not starting it. ssh.socket is a disabled or a static unit not running, not starting it. Processing triggers for man-db (2.11.2-2) ... Processing triggers for ufw (0.36.2-1) ... Log ended: 2024-07-02 00:04:16 I've attached the sshd_config from my last week backup, I've just changed the port number I use to a random one. I had the same problem on 4 different servers I upgraded last night. Maybe it's not related to openssh-server and I just noticed the problem on this package... Also note that I've recently enabled apt-listchange prompting on all these servers: cat /etc/apt/listchanges.conf [apt] frontend=pager which=both email_address=root email_format=html confirm=true headers=false reverse=false save_seen=none no_network=false Here is the command I used to check and apply security updates: sudo apt update && sudo apt dist-upgrade -V && sudo apt autoremove -y Regards, John Wellesz On Tue, Jul 2, 2024 at 5:24 PM Colin Watson wrote: > On Tue, Jul 02, 2024 at 03:05:16PM +, John Wellesz wrote: > > I used apt upgrade to install the security update available for > > openssh-server > > > >* What was the outcome of this action? > > > > It overwrote /etc/ssh/sshd_config without promtping, erasing the custom > settings > > and almost locking me out as a result (my custom port setting was gone > > as well as other changes I've made). > > > >* What outcome did you expect instead? > > > > I expected to receive the usual prompt when a configuration file is > > modified asking me what I want to do but there was none. > > We'll need to be able to reproduce this problem before being able to do > anything about it. (I have a modified /etc/ssh/sshd_config on my own > stable system and it wasn't overwritten on upgrade.) > > Can you please provide a copy of your modified /etc/ssh/sshd_config, > along with the output of the relevant apt run (which should be preserved > in /var/log/apt/term.log)? > > -- > Colin Watson (he/him) [cjwat...@debian.org] > sshd_config Description: Binary data
Bug#1074768: openssh-server: Upgrading to openssh-server (1:9.2p1-2+deb12u3) overwrites /etc/ssh/sshd_config without prompt
Package: openssh-server Version: 1:9.2p1-2+deb12u3 Severity: important Dear Maintainer, * What led up to the situation? A security update was available for openssh-server * What exactly did you do (or not do) that was effective (or ineffective)? Upgrading to the latest available security update using apt upgrade * What was the outcome of this action? sshd config file (/etc/ssh/sshd_config) was overwritten without the usual 'what do you want to do?' prompt when a package default configuration file is modified. I noticed it because I could not log in back to the server because I changed the default port among other settings... * What outcome did you expect instead? The usual prompt allowing me to keep my changes or merge them with the package new defaults... -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-22-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-server depends on: ii adduser3.134 ii debconf [debconf-2.0] 1.5.82 ii init-system-helpers1.65.2 ii libaudit1 1:3.0.9-1 ii libc6 2.36-9+deb12u7 ii libcom-err21.47.0-2 ii libcrypt1 1:4.4.33-2 ii libgssapi-krb5-2 1.20.1-2+deb12u1 ii libkrb5-3 1.20.1-2+deb12u1 ii libpam-modules 1.5.2-6+deb12u1 ii libpam-runtime 1.5.2-6+deb12u1 ii libpam0g 1.5.2-6+deb12u1 ii libselinux13.4-1+b6 ii libssl33.0.13-1~deb12u1 ii libsystemd0252.26-1~deb12u2 ii libwrap0 7.6.q-32 ii lsb-base 11.6 ii openssh-client 1:9.2p1-2+deb12u3 ii openssh-sftp-server1:9.2p1-2+deb12u3 ii procps 2:4.0.2-3 ii runit-helper 2.15.2 ii sysvinit-utils [lsb-base] 3.06-4 ii ucf3.0043+nmu1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages openssh-server recommends: ii libpam-systemd [logind] 252.26-1~deb12u2 ii ncurses-term 6.4-4 ii xauth1:1.1.2-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn ssh-askpass ii ufw 0.36.2-1 -- debconf information excluded
Bug#1074766: openssh-server: upgrading to openssh-server (1:9.2p1-2+deb12u3) resets /etc/ssh/sshd_config file without any prompt
Package: openssh-server Version: 1:9.2p1-2+deb12u3 Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Upgrading to the latest security update * What exactly did you do (or not do) that was effective (or ineffective)? I used apt upgrade to install the security update available for openssh-server * What was the outcome of this action? It overwrote /etc/ssh/sshd_config without promtping, erasing the custom settings and almost locking me out as a result (my custom port setting was gone as well as other changes I've made). * What outcome did you expect instead? I expected to receive the usual prompt when a configuration file is modified asking me what I want to do but there was none. -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-22-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages openssh-server depends on: ii adduser3.134 ii debconf [debconf-2.0] 1.5.82 ii init-system-helpers1.65.2 ii libaudit1 1:3.0.9-1 ii libc6 2.36-9+deb12u7 ii libcom-err21.47.0-2 ii libcrypt1 1:4.4.33-2 ii libgssapi-krb5-2 1.20.1-2+deb12u1 ii libkrb5-3 1.20.1-2+deb12u1 ii libpam-modules 1.5.2-6+deb12u1 ii libpam-runtime 1.5.2-6+deb12u1 ii libpam0g 1.5.2-6+deb12u1 ii libselinux13.4-1+b6 ii libssl33.0.13-1~deb12u1 ii libsystemd0252.26-1~deb12u2 ii libwrap0 7.6.q-32 ii lsb-base 11.6 ii openssh-client 1:9.2p1-2+deb12u3 ii openssh-sftp-server1:9.2p1-2+deb12u3 ii procps 2:4.0.2-3 ii runit-helper 2.15.2 ii sysvinit-utils [lsb-base] 3.06-4 ii ucf3.0043+nmu1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages openssh-server recommends: ii libpam-systemd [logind] 252.26-1~deb12u2 ii ncurses-term 6.4-4 ii xauth1:1.1.2-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn ssh-askpass ii ufw 0.36.2-1 -- debconf information excluded
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hi, On Mon, 2024-07-01 at 12:03 -0600, Zixing Liu wrote: > On Wed, Jun 12, 2024 at 3:27 PM John Paul Adrian Glaubitz > wrote: > > > > Hello Liu, > > > > On Wed, 2024-06-12 at 15:10 -0600, Zixing Liu wrote: > > > This patch does the following: > > > > > > * d/rules: switch to use the debhelper autoreconf template. > > > - d/rules: disable parallel testing. > > > - d/hfsutils-tcltk.links: remove, this is auto-handled by debhelper > > > now. > > > * d/p/0006-Fix-memory-corruption.patch: add a patch to fix memory > > > corruption > > > issues (LP: #493273). > > > > > > > > > Thanks for considering the patch. > > > > Thanks for your patch. I'll implement your changes in the weekend. > > > > After digging through the Debian BTS, I can see the patch may fix > #421457 in BTS. > Maybe you can edit my changelog entry to indicate that. Thanks for the suggestion. I will have a look. Sorry for not getting this fixed, there was a lot of work to be done in June. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1074436: open-vm-tools version 12.4.5 has been released - please rebase
Package: open-vm-tools Version: 2:12.4.5 open-vm-tools 12.4.5 was released on June 27, 2024 - based on build 23787635. There are no new features in the open-vm-tools 12.4.5 release. This is primarily a maintenance release that addresses a few critical problems, including: - A Github pull request and associated issue has been handled. Please see the Resolved Issues section of the Release Notes. - A number of issues flagged by Coverity and ShellCheck have been addressed. - A vmtoolsd process hang related to nested logging from an RPC Channel error has been fixed. For a more complete list of issues resolved in this release, see the Resolved Issues section of the Release Notes. For complete details, see: https://github.com/vmware/open-vm-tools/releases/tag/stable-12.4.5 Release Notes are available at: https://github.com/vmware/open-vm-tools/blob/stable-12.4.5/ReleaseNotes.md The granular changes that have gone into the 12.4.5 release are in the ChangeLog at: https://github.com/vmware/open-vm-tools/blob/stable-12.4.5/open-vm-tools/ChangeLog Please rebase open-vm-tools to release 12.4.5 on supported Debian releases as appropriate. -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Bug#1073178: awscli: please update awsci and/or botocore to support urllib3 2.x
Looks like the system botocore has the fix, bit there's another one bundled with awscli that doesn't - and that's the one being used: /usr/lib/python3/dist-packages/awscli/botocore/httpsession.py /usr/lib/python3/dist-packages/botocore/httpsession.py: So looks like we need to remove the botocore bundled with awscli, i tried simply renaming /usr/lib/python3/dist-packages/awscli/botocore but then it seems awscli couldn't find the system botocore: Traceback (most recent call last): File "/usr/bin/aws", line 19, in import awscli.clidriver File "/usr/lib/python3/dist-packages/awscli/clidriver.py", line 21, in import botocore.session ModuleNotFoundError: No module named 'botocore' So something is hardcoded to look inside awscli i guess? Simply copying httpsession.py from the system botocore to the awscli one fixes this error but I'm not sure we want to just do that. On Wed, 19 Jun 2024 09:07:42 +0200 Gregor Riepl wrote: > that leads here: https://github.com/aws/aws-cli/issues/7905 > "cannot import name 'DEFAULT_CIPHERS' from 'urllib3.util.ssl_'" > > https://github.com/boto/botocore/pull/2924/files It's not mentioned in the changelog, but this commit was already included in 1.29.123: https://github.com/boto/botocore/compare/1.29.122...1.29.123 Debian sid has 1.34.46, so I'm not entirely sure why it's still broken? -- Simon John
Bug#1074146: Confirmation that Poppler's CVE-2024-6239 affects Buster and all subsequent releases
Control: found -1 poppler/0.71.0-5+deb10u3 Control: found -1 poppler/20.09.0-3.1+deb11u1 Control: found -1 poppler/22.12.0-2 Control: found -1 poppler/24.06.0-2 Since I couldn't find detailed information from upstream, I'd like to confirm that I was able to reproduce the crash on Buster, Bullseye, Bookworm, and experimental, and so the Security Tracker information is accurate. I am therefore updating the bug to indicate this as a courtesy to BTS users. Please note that the vulnerable code and its fix are exclusive to the pdfinfo utility in the poppler-utils binary package; the library is not affected. It might would be helpful if this bug were assigned to that binary package, but it's not my place to make that determination. I don't maintain this package, but do pitch in occasionally and keep a close eye on it. Thanks and please let me know if I can be of any assistance. -- Homepage https://johnscott.me 着 Contact info • as a vCard: https://johnscott.me/me/me.vcf • as an LDAP directory entry: ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#1073835: systemd: new run0 utility fails due to missing dependency
Package: systemd Version: 256-1 Severity: normal Dear Maintainer, systemd 256 introduced a 'run0' utility intended to serve a similar purpose as sudo(8) run0(1) manpage states: 'Authentication takes place via polkit[1], thus isolating the authentication prompt from the terminal (if possible).' As of now, polkitd is only a suggestion and not yet a dependency for systemd so chances are it is not installed. Trying to use run0 thus fails, eg: $ run0 ls /tmp Failed to start transient service unit: Access denied (note that run0 error message could be improved, but it is an upstream issue) -- Package-specific info: -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.8.12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages systemd depends on: ii libacl12.3.2-2 ii libapparmor1 3.0.13-2 ii libaudit1 1:3.1.2-4 ii libblkid1 2.40.1-8.1 ii libc6 2.38-13 ii libcap21:2.66-5 ii libcryptsetup122:2.7.2-2 ii libfdisk1 2.40.1-8.1 ii libmount1 2.40.1-8.1 ii libpam0g 1.5.3-7 ii libseccomp22.5.5-1 ii libselinux13.5-2+b2 ii libssl3t64 3.2.1-3 ii libsystemd-shared 256-1 ii libsystemd0256-1 ii mount 2.40.1-8.1 Versions of packages systemd recommends: ii dbus [default-dbus-system-bus] 1.14.10-4+b1 ii libzstd11.5.5+dfsg2-2 ii ntpsec [time-daemon]1.2.3+dfsg1-3 Versions of packages systemd suggests: ii libgcrypt20 1.10.3-3 ii libidn2-0 2.3.7-2 ii liblz4-1 1.9.4-2 ii liblzma5 5.6.1+really5.4.5-1 pn libtss2-rc0t64 pn libtss2-tcti-device0 pn polkitd pn systemd-boot pn systemd-container pn systemd-homed pn systemd-resolved pn systemd-userdbd Versions of packages systemd is related to: ii dbus-user-session 1.14.10-4+b1 pn dracut ii initramfs-tools0.142 ii libnss-systemd 256-1 ii libpam-systemd 256-1 ii udev 256-1 -- no debconf information
Bug#1073830: gcc-14: Missing build dependency on cargo on hurd-i386
Source: gcc-14 Version: 14.1.0-2 Severity: normal User: debian-h...@lists.debian.org Usertags: hurd-i386 X-Debbugs-Cc: debian-h...@lists.debian.org Hi, gcc-14 needs to build-depend on cargo on hurd-i386 to be able to build gccrs [1]: configure: error: cargo is required to build rust Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=gcc-14=hurd-i386=14.1.0-2=1718795837=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073590: pd-mrpeach: FTBFS on hppa - ‘x->x_sr[client]’ is a pointer
Source: pd-mrpeach Version: 0.1~svn17672-5 Severity: normal Tags: ftbfs Dear Maintainer, Build fails here: net/tcpserver.c: In function ‘tcpserver_send_buffer_avaliable_for_client’: net/tcpserver.c:542:33: error: ‘x->x_sr[client]’ is a pointer; did you mean to use ‘->’? 542 | int sockfd = x->x_sr[client].sr_fd; | ^ | -> cc -DPD -I "/usr/include/pd" -DUNIX -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -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=/<>=. -Wformat -Werror=format-security -o cmos/cd4082.pd_linux.o -c cmos/cd4082.c info: making cmos/cd4072.pd_linux.o in lib mrpeach make[1]: *** [/usr/share/pd-lib-builder//Makefile.pdlibbuilder:987: net/tcpserver.pd_linux.o] Error 1 Full log is here: https://buildd.debian.org/status/fetch.php?pkg=pd-mrpeach=hppa=0.1%7Esvn17672-6=1718659014=0 Regards, Dave Anglin -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 6.10.0-rc4 (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1073046: fixed in cups 2.4.7-3
Hi Thorsten, On Sun, 2024-06-16 at 00:19 +, Debian FTP Masters wrote: >[ Thorsten Alteholz ] >* reintroduce time_t changes that were accidentally deleted > with last upload > (thanks to Michael Hudson-Doyle for this work) >* debian/rules: no test on riscv64 (Closes: #1073046) Would be great if the testsuite could be disabled for sparc64 as well if there is no prospective fix for the testsuite failures in sight. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#955858: gparted: does not start, 'unable to init server', tmp.mount does not exist
Package: gparted Version: 1.5.0-1+b1 Followup-For: Bug #955858 X-Debbugs-Cc: contrapunc...@disroot.org Dear Maintainer, I have the same issue (cannot launch gparted from the XFCE applications menu), with the difference that when I start gparted from the command line, I get - ``` Invalid MIT-MAGIC-COOKIE-1 key (gpartedbin:16042): Gtk-WARNING **: 10:04:45.522: cannot open display: :0.0 ``` > What display server / desktop environment are you using? xorg v1:7.7+23 and xfce4 v4.18 -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gparted depends on: ii gparted-common 1.5.0-1 ii libatkmm-1.6-1v5 2.28.4-1+b1 ii libc62.38-13 ii libcairomm-1.0-1v5 1.14.5-1 ii libgcc-s114-20240330-1 ii libglib2.0-0t64 2.80.2-2 ii libglibmm-2.4-1t64 2.66.7-1 ii libgtk-3-0t643.24.42-1 ii libgtkmm-3.0-1t643.24.9-1 ii libpangomm-1.4-1v5 2.46.4-1+b1 ii libparted-fs-resize0t64 3.6-4 ii libparted2t643.6-4 ii libsigc++-2.0-0v52.12.1-2 ii libstdc++6 14-20240330-1 ii libuuid1 2.40.1-8.1 ii pkexec 124-2 gparted recommends no packages. Versions of packages gparted suggests: pn dmraid ii dmsetup2:1.02.196-1+b1 ii dosfstools 4.2-1.1 ii e2fsprogs 1.47.1-1 ii exfatprogs 1.2.2-1 pn gpart pn jfsutils pn kpartx pn mtools ii ntfs-3g1:2022.10.3-1+b1 pn reiser4progs pn reiserfsprogs pn udftools ii xfsprogs 6.8.0-2 ii yelp 42.2-1+b2 -- no debconf information
Bug#939756: mercurial: FTBFS on hppa - test-hghave.t timed out
I'm not seeing this time out with 6.7.4-1. Regards, Dave Anglin -- John David Anglin dave.ang...@bell.net
Bug#1073270: mercurial: FTBFS on hppa - test-bundle.t output changed
Source: mercurial Version: 6.7.4-1 Severity: normal Tags: ftbfs Dear Maintainer, test-bundle.t fails: test-bundle.t test-bundle.t ... # Test test-bundle.t # Running sh "/tmp/hgtests.dnrnpeia/child163/test-bundle.t.sh" # Timout reached for process 2680 # Ret was: 0 (test-persistent-nodemap.t) ok test-revert.t test-revert.t ... # Test test-revert.t # Running sh "/tmp/hgtests.dnrnpeia/child164/test-revert.t.sh" # Timout reached for process 3637 --- /<>/tests/test-bundle.t +++ /<>/tests/test-bundle.t.err @@ -1106,13 +1106,7 @@ DEBUG-UNBUNDLING: full:?? seconds (???% of total) (glob) DEBUG-UNBUNDLING: cached:?? seconds (???% of total) (glob) DEBUG-UNBUNDLING: manifests: - DEBUG-UNBUNDLING: full:?? seconds (???% of total) (glob) - DEBUG-UNBUNDLING: cached:?? seconds (???% of total) (glob) - DEBUG-UNBUNDLING: delta: ?? seconds (???% of total) (glob) - DEBUG-UNBUNDLING: cached:?? seconds (???% of total) (glob) DEBUG-UNBUNDLING: files: - DEBUG-UNBUNDLING: full:?? seconds (???% of total) (glob) - DEBUG-UNBUNDLING: cached:?? seconds (???% of total) (glob) added 3 changesets with 3 changes to 3 files new changesets 4fe08cd4693e:4652c276ac4f (3 drafts) (run 'hg update' to get a working copy) ERROR: test-bundle.t output changed !# Ret was: 0 (test-bundle.t) Full log is here: https://buildd.debian.org/status/fetch.php?pkg=mercurial=hppa=6.7.4-1=1718444852=0 test-bundle.t is the only test that fails with 6.7.4-1 when the testsuite is run on real hardware. There are more errors with qemu buildds. I don't see #929756 anymore. I saw this output when I built mercurial with dpkg-buildpackage: --- /home/dave/debian/mercurial/mercurial-6.7.4/tests/test-bundle.t +++ /home/dave/debian/mercurial/mercurial-6.7.4/tests/test-bundle.t.err @@ -1086,33 +1086,76 @@ DEBUG-UNBUNDLING: manifests: 3 ( 33%) DEBUG-UNBUNDLING: files: 3 ( 33%) DEBUG-UNBUNDLING: total-time: ?? seconds (glob) - DEBUG-UNBUNDLING: changelog: ?? seconds (???%) (glob) - DEBUG-UNBUNDLING: manifests: ?? seconds (???%) (glob) - DEBUG-UNBUNDLING: files: ?? seconds (???%) (glob) - DEBUG-UNBUNDLING: type-count: - DEBUG-UNBUNDLING: changelog: - DEBUG-UNBUNDLING: full: 3 - DEBUG-UNBUNDLING: cached: 3 (100%) - DEBUG-UNBUNDLING: manifests: - DEBUG-UNBUNDLING: full: 1 - DEBUG-UNBUNDLING: cached: 1 (100%) - DEBUG-UNBUNDLING: delta:2 - DEBUG-UNBUNDLING: cached: 2 (100%) - DEBUG-UNBUNDLING: files: - DEBUG-UNBUNDLING: full: 3 - DEBUG-UNBUNDLING: cached: 3 (100%) - DEBUG-UNBUNDLING: type-time: - DEBUG-UNBUNDLING: changelog: - DEBUG-UNBUNDLING: full:?? seconds (???% of total) (glob) - DEBUG-UNBUNDLING: cached:?? seconds (???% of total) (glob) - DEBUG-UNBUNDLING: manifests: - DEBUG-UNBUNDLING: full:?? seconds (???% of total) (glob) - DEBUG-UNBUNDLING: cached:?? seconds (???% of total) (glob) - DEBUG-UNBUNDLING: delta: ?? seconds (???% of total) (glob) - DEBUG-UNBUNDLING: cached:?? seconds (???% of total) (glob) - DEBUG-UNBUNDLING: files: - DEBUG-UNBUNDLING: full:?? seconds (???% of total) (glob) - DEBUG-UNBUNDLING: cached:?? seconds (???% of total) (glob) - added 3 changesets with 3 changes to 3 files - new changesets 4fe08cd4693e:4652c276ac4f (3 drafts) - (run 'hg update' to get a working copy) + transaction abort! + rollback completed + ** unknown exception encountered, please report by visiting + ** https://mercurial-scm.org/wiki/BugTracker + ** Python 3.11.9 (main, Apr 10 2024, 13:16:36) [GCC 13.2.0] + ** Mercurial Distributed SCM (version 6.7.4) + ** Extensions loaded: + Traceback (most recent call last): +File "/tmp/hgtests.7tftf1lf/install/bin/hg", line 59, in + dispatch.run() +File "/tmp/hgtests.7tftf1lf/install/lib/python/mercurial/dispatch.py", line 142, in run + status = dispatch(req) + ^ +File "/tmp/hgtests.7tftf1lf/install/lib/python/mercurial/dispatch.py", line 231, in dispatch + status = _rundispatch(req) + ^ +File "/tmp/hgtests.7tftf1lf/install/lib/python/mercurial/dispatch.py", line 275, in _rundispatch + ret = _runcatch(req) or 0 +^^ +File "/tmp/hgtests.7tftf1lf/install/lib/python/mercurial/dispatch.py", line 456, in _runcatch + return
Bug#1073189: awscli: ImportError: cannot import name DEFAULT_CIPHERS from urllib3.util.ssl_
Downgrading to urllib3 v1 fixed this for me, some more info here - although botocore already seems to have the fix they mention: https://github.com/aws/aws-cli/issues/7905 Package I used: https://snapshot.debian.org/package/python-urllib3/1.26.18-2/#python3-urllib3_1.26.18-2 Regards. -- Simon John
Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects
On Fri, 2024-06-14 at 10:33 +0200, Sune Stolborg Vuorela wrote: > On Friday, June 14, 2024 10:25:59 AM CEST John Paul Adrian Glaubitz wrote: > > I'm not denying that. However, a package named "qml6-module-qtquick-effects" > > doesn't sound like an interpreter to me. > > > > Thus, I don't really see how I am supposed to know as a maintainer what > > packages add Depends except for trial and error. Why not have one canonical > > "qt-interpretor" package or similar that applications can depend on? > > This is a module for a interpreted language. It is not much different than a > python package might need a hardcoded dependency on python-foo if it uses > that. or a perl package might need a hardcoded dependency on libperl-foo-bar- > baz if it uses the Foo::Bar::Baz perl module for important functionality. > > all qml*-module packages are qml (interpreted language) extensions. > > And yes. trial and error - or reading the sources - is for many interpreted > languages the only way of figuring it out. Ugh, that's truly a step backwards and way to add more burden to maintainers. I guess we'll be seeing plenty of such bug reports in the future when extensions get moved around or new ones get added. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias, On Thu, 2024-06-13 at 20:50 +0200, John Paul Adrian Glaubitz wrote: > > Do we still have to build an unregisterised compiler for powerpc > > or can we switch back to NCG (https://bugs.debian.org/1060196)? > > I have not verified that yet. Please let's stay unregisterised for now > and have me verify first whether the NGC has been fixed with 9.6.x or > newer. > > Please let's keep this bug report open and use #1073159 [1] for adding > the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS. GHC 9.6.5 still fails on powerpc with the NGC enabled: # rts/include/rts/prof/LDV.h | Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => _build/stage1/rts/build/cmm/HeapStackCheck.debug_o | Run Ghc CompileHs Stage1: rts/PrimOps.cmm => _build/stage1/rts/build/cmm/PrimOps.p_o | Run Ghc CompileHs Stage1: rts/Updates.cmm => _build/stage1/rts/build/cmm/Updates.thr_p_o | Run Ghc CompileHs Stage1: rts/Compact.cmm => _build/stage1/rts/build/cmm/Compact.thr_p_o | Run Ghc CompileHs Stage1: rts/Exception.cmm => _build/stage1/rts/build/cmm/Exception.o | Run Ghc CompileHs Stage1: rts/PrimOps.cmm => _build/stage1/rts/build/cmm/PrimOps.debug_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.debug_p_o | Run Ghc CompileHs Stage1: rts/HeapStackCheck.cmm => _build/stage1/rts/build/cmm/HeapStackCheck.p_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.thr_debug_p_o | Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => _build/stage1/rts/build/cmm/StgMiscClosures.debug_o | Run Ghc CompileHs Stage1: rts/StgMiscClosures.cmm => _build/stage1/rts/build/cmm/StgMiscClosures.p_o | Run Ghc CompileHs Stage1: rts/ContinuationOps.cmm => _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o | Run Ghc CompileHs Stage1: rts/Updates.cmm => _build/stage1/rts/build/cmm/Updates.debug_p_o | Run Ghc CompileHs Stage1: rts/StgStartup.cmm => _build/stage1/rts/build/cmm/StgStartup.thr_p_o | Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.o | Run Ghc CompileHs Stage1: rts/Exception.cmm => _build/stage1/rts/build/cmm/Exception.debug_o | Run Ghc CompileHs Stage1: rts/Apply.cmm => _build/stage1/rts/build/cmm/Apply.thr_dyn_o Command line: _build/stage0/bin/ghc -Wall -Wcompat -hisuf debug_p_hi -osuf debug_p_o -hcsuf debug_p_hc -static -prof -DDEBUG -optc-DDEBUG -hide-all-packages -no-user-package-db '-package-env -' '- package-db _build/stage1/inplace/package.conf.d' '-this-unit-id rts-1.0.2' -i -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/rts/build -i/home/glaubitz/ghc-deb-9.6.5-new/ghc- 9.6.5/_build/stage1/rts/build/autogen -i/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/rts -Irts/include -I_build/stage1/rts/build -I_build/stage1/rts/build/include -I_build/stage1/rts/build/@FFIIncludeDir@ -I_build/stage1/rts/build/@LibdwIncludeDir@ -Irts/include -Irts/@FFIIncludeDir@ -Irts/@LibdwIncludeDir@ -optP-include - optP_build/stage1/rts/build/autogen/cabal_macros.h -ghcversion-file=rts/include/ghcversion.h -outputdir _build/stage1/rts/build -fdiagnostics-color=always -Wnoncanonical-monad-instances -optc-Wno- error=inline -optP-Wno-nonportable-include-path -c rts/ContinuationOps.cmm -o _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o -O2 -H32m -this-unit-id rts -XHaskell98 -no-global-package-db - package-db=/home/glaubitz/ghc-deb-9.6.5-new/ghc-9.6.5/_build/stage1/inplace/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -haddock -Irts - I_build/stage1/rts/build '-DRtsWay="rts_debug_p"' -DFS_NAMESPACE=rts -DCOMPILING_RTS -DPROFILING -Wno-deprecated-flags -Wcpp-undef ===> Command failed with error code: 1 ghc: panic! (the 'impossible' happened) GHC version 9.6.5: PPC.Ppr.pprInstr: JMP to ForeignLabel CallStack (from HasCallStack): panic, called at compiler/GHC/CmmToAsm/PPC/Ppr.hs:591:30 in ghc:GHC.CmmToAsm.PPC.Ppr Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug Error when running Shake build system: at want, called at src/Main.hs:124:44 in main:Main * Depends on: binary-dist-dir at need, called at src/Rules/BinaryDist.hs:130:9 in main:Rules.BinaryDist * Depends on: _build/stage1/lib/package.conf.d/rts-1.0.2.conf at need, called at src/Rules/Register.hs:134:5 in main:Rules.Register * Depends on: _build/stage1/rts/build/stamp-rts-1.0.2_debug_p at need, called at src/Rules/Library.hs:144:3 in main:Rules.Library * Depends on: _build/stage1/rts/build/libHSrts-1.0.2_debug_p.a at need, called at src/Rules/Library.hs:220:5 in main:Rules.Library * Depends on: _build/stage1/rts/build/cmm/ContinuationOps.debug_p_o at cmd', called at src/Builder.hs:387:23 in main:Builder at cmdArgs, called at src/Builder.hs:540:8 in main:Builder at cmdArgs, called at src/Builder.hs:564:18 in main:Builder at cmd
Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects
On Fri, 2024-06-14 at 09:39 +0200, Sune Stolborg Vuorela wrote: > Control: severity -1 serious > > Missing dependencies are RC > > > This is a common problem with Qt6 and has been reported for a different > > dependency before, see [1]. > > It is normal for interpreted languages to have their dependencies managed > manually. This is just another version of that. I'm not denying that. However, a package named "qml6-module-qtquick-effects" doesn't sound like an interpreter to me. Thus, I don't really see how I am supposed to know as a maintainer what packages add Depends except for trial and error. Why not have one canonical "qt-interpretor" package or similar that applications can depend on? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073159: ghc: Please include --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS
Source: ghc Version: 9.4.7-5 Severity: important Tags: patch User: debian-powe...@lists.debian.org Usertags: powerpc X-Debbugs-Cc: debian-powe...@lists.debian.org Hi, after debugging the segmentation faults with the unregisterised GHC on powerpc for a long time, I finally found the culprit which is the fact that GHC is built to default to the gold linker by default. The gold linker is known to be broken on some architectures which is unlikely to change in the future as the project has been abandoned by Google [1], so it has been long disabled for several architectures in debian/rules by passing the flag --disable-ld-override in EXTRA_CONFIGURE_FLAGS. However, as I learnt today, this only affects the linker choice when building GHC but not the default linker for the actual binary packages which still defaulted to gold in /usr/lib/ghc/lib/settings. As one of the upstream developers explained to me today [2], it's necessary to pass --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS as well in order to disable gold for the binary distribution, i.e. what will end up in the Debian package. Thus, please modify debian/rules to also include the flag --disable-ld-override in EXTRA_INSTALL_CONFIGURE_FLAGS: --- debian/rules.orig 2024-06-13 11:01:23.450199875 -0700 +++ debian/rules2024-06-13 11:01:26.318242288 -0700 @@ -76,6 +76,7 @@ # See also https://bugs.debian.org/1056636 ifneq (,$(filter mips mipsel powerpc powerpcspe sparc64, $(DEB_HOST_ARCH))) EXTRA_CONFIGURE_FLAGS += --disable-ld-override + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override endif ifneq (,$(filter armhf, $(DEB_HOST_ARCH))) Also attaching a patch. Thanks, Adrian > [1] https://en.wikipedia.org/wiki/Gold_(linker) > [2] https://gitlab.haskell.org/ghc/ghc/-/issues/24986#note_570504 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 --- debian/rules.orig 2024-06-13 11:01:23.450199875 -0700 +++ debian/rules2024-06-13 11:01:26.318242288 -0700 @@ -76,6 +76,7 @@ # See also https://bugs.debian.org/1056636 ifneq (,$(filter mips mipsel powerpc powerpcspe sparc64, $(DEB_HOST_ARCH))) EXTRA_CONFIGURE_FLAGS += --disable-ld-override + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override endif ifneq (,$(filter armhf, $(DEB_HOST_ARCH)))
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Ilias, On Thu, 2024-06-13 at 21:22 +0300, Ilias Tsitsimpis wrote: > Great job! Thanks! > I completely missed the fact this needs to be passes to the bindist's > configure script as well. It took me forever to figure this out ;-). > You need to edit debian/rules here > https://sources.debian.org/src/ghc/9.4.7-5/debian/rules/#L78 > and add the following line as well: > > + EXTRA_INSTALL_CONFIGURE_FLAGS += --disable-ld-override Yes, that's what I suggested, see my patch in [1]. > I will include that in the next upload. Great, thank you. I uploaded a patched version to unreleased in the mean time. > Do we still have to build an unregisterised compiler for powerpc > or can we switch back to NCG (https://bugs.debian.org/1060196)? I have not verified that yet. Please let's stay unregisterised for now and have me verify first whether the NGC has been fixed with 9.6.x or newer. Please let's keep this bug report open and use #1073159 [1] for adding the flag --disable-ld-override to EXTRA_INSTALL_CONFIGURE_FLAGS. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1073159 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi Jeff, On Thu, 2024-06-13 at 03:50 -0400, Jeffrey Walton wrote: > > Now we just need to figure out how to actually set the default linker back > > to bfd as it was actually explicitly supposed to happen according to > > debian/rules. > > > > This will most likely also unbreak GHC on m68k. > > Good job, Adrian. That's quite a bit of work to track down the issue. Thanks. In the meantime I filed a bug upstream for this [1]. I will actually open a second bug report since this bug report is about the broken NGC on 32-bit PowerPC which is a different issue. Adrian > [1] https://gitlab.haskell.org/ghc/ghc/-/issues/24986 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1023649: ghc: FTBFS haskell-random powerpc (ghc Segmentation fault)
Hi, I finally figured out what the problem is. After realizing that the two-stage build of GHC works without problems, I realized it can be a configuration issue only and, indeed, it is. Looking at /usr/lib/ghc/lib/settings, the default linker is set to gold: "C compiler link flags", "-fuse-ld=gold" Since gold is broken on powerpc and shouldn't really be used anymore since it's basically unmaintained upstream, we must use bfd on powerpc by default. Editing the file and switching back to bfd fixes the problem for me. Now we just need to figure out how to actually set the default linker back to bfd as it was actually explicitly supposed to happen according to debian/rules. This will most likely also unbreak GHC on m68k. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073085: hfsutils: upgrade the source package to use compat level 13
Hello Liu, On Wed, 2024-06-12 at 15:10 -0600, Zixing Liu wrote: > This patch does the following: > > * d/rules: switch to use the debhelper autoreconf template. > - d/rules: disable parallel testing. > - d/hfsutils-tcltk.links: remove, this is auto-handled by debhelper now. > * d/p/0006-Fix-memory-corruption.patch: add a patch to fix memory corruption > issues (LP: #493273). > > > Thanks for considering the patch. Thanks for your patch. I'll implement your changes in the weekend. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073063: ausweisapp should depend on qml6-module-qtquick-effects
Control: severity -1 normal Hello Reinhard, On Wed, 2024-06-12 at 18:40 +0200, Reinhard Karcher wrote: > ausweisapp doesn't start the gui, because qml6-module-qtquick-effects > is not installed. It should depend on that package. > Installing qml6-module-qtquick-effects solves the problem. This is a common problem with Qt6 and has been reported for a different dependency before, see [1]. I haven't found a satisfactory solution as hard-coding a dependency as suggested in your bug report would mean that the package cannot undergo automatic transitions. I am therefore reducing the severity to normal as the package would otherwise be removed from testing. Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070018#10 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1073046: cups: FTBFS on riscv64 due to testsuite timeouts
Source: cups Version: 2.4.7-2 Severity: serious Tags: ftbfs Justification: ftbfs User: debian-ri...@lists.debian.org Usertags: riscv64 X-Debbugs-Cc: debian-ri...@lists.debian.org Hello, src:cups currently FTBFS on riscv64 due to a testsuite timeout [1]: Running command tests... Performing 5.1-lpadmin.sh: FAIL Performing 5.2-lpc.sh: PASS Performing 5.3-lpq.sh: FAIL Performing 5.4-lpstat.sh: FAIL Performing 5.5-lp.sh: FAIL Performing 5.6-lpr.sh: FAIL Performing 5.7-lprm.sh: FAIL Performing 5.8-cancel.sh: FAIL Performing 5.9-lpinfo.sh: FAIL Performing restart test: ./run-stp-tests.sh: 811: kill: No such process E: Build killed with signal TERM after 600 minutes of inactivity This issue has been observed on sparc64, so it seems reproducible. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=cups=riscv64=2.4.7-2=1718180226=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072774: Upstream bug files
Upstream bug filed here - https://github.com/openzfs/zfs/issues/16261 John
Bug#1072774: Also fails on upstream
I rebuilt the Debian package using the latest upstream (https://github.com/openzfs/zfs), and saw the same error. Log is (hopefully attached). Will raise the issue there as well. Thanks, John typescript Description: Binary data
Bug#1069498: libx86emu: FTBFS on armhf: mem.c:581:12: error: implicit declaration of function ‘inb’; did you mean ‘ins’? [-Werror=implicit-function-declaration]
Hi Guillem, On Tue, 2024-06-11 at 13:42 +0200, Guillem Jover wrote: > > I had a look at this, and it seems like this package has never really > > worked on ARM systems at all? And this was hidden due to the missing > > declarations not being an error. > > > > AFAIK, only x86 (i386 and amd64), ia64 and alpha have port I/O, other > > systems have instead memory mapped I/O, but the code in mem.c is > > unconditionally calling port I/O functions such as in*() and out*(), > > provided by glibc. > > > > Until the upstream code is ported to systems with memory mapper I/O, I > > think the "best" way to resolve this would be to restrict the > > architecture list to: > > > > any-amd64 any-i386 alpha ia64 > > The attached patch implements this. It should not affect reverse build > depending packages (only hwinfo) which is already arch restricted to > «amd64 i386». > > I'm including the arm list to confirm the above, but also in case > someone there feels like porting the library to support memory mapped > I/O? (But perhaps that's not worth the effort.) It's perfectly fine to disable libx86emu on ARM as it has already been correctly stated, there are no I/O ports on ARM so the above code won't work on ARM. I also don't expect that to change in the future, so it's not worth bothering about this in the future, especially since the upstream project hasn't been very active lately [1]. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072769: libvirt-daemon: Cannot connect to hypervisor with user session after upgrade
Actually adding /usr/sbin to $PATH doesn't fix this in all cases. If you run virt-manager from Gnome on Wayland for instance, it doesn't connect. You have to run it from the console or run virsh first to get it to use your new $PATH I guess you could also set it in ~/.config/environment.d/*.conf instead of just ~/.bashrc but that's really getting ugly, seems this needs a proper fix not a workaround. -- Simon John
Bug#1072769: libvirt-daemon: Cannot connect to hypervisor with user session after upgrade
Nice spot! Yes, adding /usr/sbin to the user's $PATH does seem to workaround it on 10.4 and explains why it works for root. It's a bit odd as installing firewalld, which uninstalls iptables, doesn't fix things, nor does setting the backend in the config file. Also should lacking the ability to mess with the firewall prevent VM's from even being listed, created or edited, aside from started? Seems that whole commit is sub-optimal, not just the iptables in $PATH line. -- Simon John
Bug#1072954: python-ijson: FTBFS on hppa - ZeroDivisionError: float division by zero
Source: python-ijson
Version: 3.3.0-1
Severity: normal
Tags: ftbfs
Dear Maintainer,
Build fails due to testsuite problems:
FAIL: test_basic_parse (test.test_benchmark.BenchmarkTests.test_basic_parse)
--
Traceback (most recent call last):
File
"/<>/.pybuild/cpython3_3.11_ijson/build/test/test_benchmark.py",
line 38, in test_basic_parse
self._test_benchmark('basic_parse')
File
"/<>/.pybuild/cpython3_3.11_ijson/build/test/test_benchmark.py",
line 33, in _test_benchmark
self._do_test_benchmark(method, "python")
File
"/<>/.pybuild/cpython3_3.11_ijson/build/test/test_benchmark.py",
line 30, in _do_test_benchmark
self.assertEqual(0, status, "out:\n%s\nerr:%s" % (out.decode('utf-8'),
err.decode('utf-8')))
AssertionError: 0 != 1 : out:
#mbytes, method, test_case, backend, time_min, time_avg, time_median, time_max,
mb_per_sec_min, mb_per_sec_avg, mb_per_sec_median, mb_per_sec_max
0.000, basic_parse, long_list, python, 0.004, 0.004, 0.004, 0.004, 0.001,
0.001, 0.001, 0.001
0.000, basic_parse, long_list, yajl2, 0.004, 0.004, 0.004, 0.004, 0.001, 0.001,
0.001, 0.001
err:Traceback (most recent call last):
File "", line 198, in _run_module_as_main
File "", line 88, in _run_code
File
"/<>/.pybuild/cpython3_3.11_ijson/build/ijson/benchmark.py", line
275, in
main()
File
"/<>/.pybuild/cpython3_3.11_ijson/build/ijson/benchmark.py", line
272, in main
run_benchmarks(args, benchmark)
File
"/<>/.pybuild/cpython3_3.11_ijson/build/ijson/benchmark.py", line
214, in run_benchmarks
stats([megabytes / duration for duration in durations])
File
"/<>/.pybuild/cpython3_3.11_ijson/build/ijson/benchmark.py", line
214, in
stats([megabytes / duration for duration in durations])
~~^~
ZeroDivisionError: float division by zero
Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=python-ijson=hppa=3.3.0-1=1717834294=0
I haven't looked this in detail but CLOCK_MONOTONIC timing is quite course
on hppa. I suspect if "duration for duration in durations" is longer the
division by zero error wouldn't occur.
Similar error occurs on hurd-i386.
Regards,
Dave Anglin
-- System Information:
Debian Release: trixie/sid
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)
Kernel: Linux 6.9.3-dirty (SMP w/4 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Bug#1072951: racket: FTBFS on hppa - illegal pb instruction
Source: racket Version: 8.13+dfsg1-2 Severity: normal Tags: ftbfs Dear Maintainer, Racket build fails here: running cs/c/ChezScheme/pb/bin/pb/scheme to build cs/c/ChezScheme/xc-tpb32b/s/cmacros.so illegal pb instruction failed in build-one in loop in module->hash illegal pb instruction make[1]: *** [Makefile:22: all] Error 1 Full log is here: https://buildd.debian.org/status/fetch.php?pkg=racket=hppa=8.13%2Bdfsg1-2=1717949065=0 Regards, Dave Anglin -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 6.9.3-dirty (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1072950: qtwayland-opensource-src: FTBFS on hppa - tst_xdgdecorationv1 fails
Source: qtwayland-opensource-src Version: 5.15.13-2 Severity: normal Tags: ftbfs Dear Maintainer, As of version 5.15.13-2, we have the following test failure: make[4]: Leaving directory '/<>/tests/auto/client/inputcontext' FAIL! : tst_xdgdecorationv1::clientSidePreferredByCompositor() '(!window.frameMargins().isNull())' returned FALSE. () Loc: [tst_xdgdecorationv1.cpp(184)] Full build log is here: https://buildd.debian.org/status/fetch.php?pkg=qtwayland-opensource-src=hppa=5.15.13-2=1717804433=0 Regards, Dave Anglin -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 6.9.3-dirty (SMP w/4 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1072940: mailtuils: FTBFS on sparc64 due to outdated symbols file
Source: mailutils Version: 1:3.17-2 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc64 X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, mailutils fails to build from source on sparc64 due to an outdated symbols file [1]: dpkg-gensymbols: warning: debian/libmailutils9t64/DEBIAN/symbols doesn't match completely debian/libmailutils9t64.symbols --- debian/libmailutils9t64.symbols (libmailutils9t64_1:3.17-2_sparc64) +++ dpkg-gensymbolsjTYNfd 2024-06-09 13:24:35.314252567 + @@ -1928,6 +1928,7 @@ mu_py_script_run@Base 1:3.17 libmu_scm.so.9 libmailutils9t64 #MINVER# * Build-Depends-Package: libmailutils-dev + _etext@Base 1:3.17-2 _mu_scm_bugreport@Base 1:3.17 _mu_scm_debug@Base 1:3.17 _mu_scm_mailer@Base 1:3.17 dh_makeshlibs: error: failing due to earlier errors make[1]: *** [debian/rules:86: override_dh_makeshlibs] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:4: binary-arch] Error 2 Thanks, Adrian > [1] https://buildd.debian.org/status/package.php?p=mailutils=sid -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072903: kiwi: please package v10.0.21 and remove the obsolete python3-mock build dependency
Hello, On Mon, 2024-06-10 at 01:17 +0200, Alexandre Detiste wrote: > please package v10.0.21 and remove the obsolete python3-mock build dependency > > > https://github.com/testing-cabal/mock > > > > mock is now part of the Python standard library, available as unittest.mock > > in Python 3.3 onward > > more information cab be find here: > > https://github.com/OSInside/kiwi/pull/2470 I have tried packaging the latest upstream version but I was unable to get the testsuite to pass successfully as setting the proper PYTHONPATH for running the testsuite did not work. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072897: rustc: Please ignore test_arc_condvar_poison on powerpc
Source: rustc
Version: 1.75.0+dfsg1-4
Severity: normal
Tags: patch
User: debian-powe...@lists.debian.org
Usertags: powerpc
X-Debbugs-Cc: debian-powe...@lists.debian.org
Hi,
the test test_arc_condvar_poison hangs on powerpc for rustc 1.75.0 [1]:
test time::tests::instant_monotonic_concurrent ... ok
test sync::mpsc::tests::stress_recv_timeout_two_threads ... ok
test sync::mutex::tests::test_arc_condvar_poison has been running for a long
time
E: Build killed with signal TERM after 150 minutes of inactivity
Please include the attached patch to ignore it for the time being.
Thanks,
Adrian
> [1]
> https://buildd.debian.org/status/fetch.php?pkg=rustc=powerpc=1.75.0%2Bdfsg1-4=1717703746=0
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Index: rustc-1.75.0+dfsg1/library/std/src/sync/mutex/tests.rs
===
--- rustc-1.75.0+dfsg1.orig/library/std/src/sync/mutex/tests.rs
+++ rustc-1.75.0+dfsg1/library/std/src/sync/mutex/tests.rs
@@ -145,6 +145,7 @@ fn test_mutex_arc_condvar() {
}
}
+#[cfg(not(target_arch = "powerpc"))]
#[test]
fn test_arc_condvar_poison() {
let packet = Packet(Arc::new((Mutex::new(1), Condvar::new(;
Bug#1057050: qt6-multimedia: Please build with EIGEN_DONT_VECTORIZE on powerpc to fix FTBFS
Hello, On Sun, 2024-06-09 at 16:39 +0200, marillat wrote: > > This can be fixed by switching off vectorization in the »eigen« using the > > preprocessor > > macro EIGEN_DONT_VECTORIZE which can be defined on the cmake command line > > using the > > cmake variable COMPILE_DEFINITIONS: > > > > --- qt6-multimedia-6.4.2/debian/rules.orig 2023-07-26 > > 17:52:13.0 +0200 > > +++ qt6-multimedia-6.4.2/debian/rules 2023-11-28 18:26:47.950137854 +0100 > > @@ -9,6 +9,10 @@ > > cmake_extra_args += -DQT_HOST_PATH=/usr > > endif > > > > +ifneq (,$(filter $(DEB_HOST_ARCH),powerpc)) > > + cmake_extra_args += -DCOMPILE_DEFINITIONS="EIGEN_DONT_VECTORIZE" > > +endif > > + > > %: > > dh $@ --with pkgkde_symbolshelper --buildsystem=cmake+ninja > > > > With the above change, cmake defines the preprocessor macro > > EIGEN_DONT_VECTORIZE and > > the build succeeds on powerpc. > > With qt6-multimedia 6.6.2 qt6-multimedia still fail to build even with > this patch. > > I'm unable to find a solution. Adrian do you have an idea ? The syntax of my proposed solution was wrong. My local tests were not performed on a clean source which is why I did not notice the suggested syntax didn't work. The proper syntax is: ifneq (,$(filter $(DEB_HOST_ARCH),powerpc)) export DEB_CXXFLAGS_MAINT_APPEND = -DEIGEN_DONT_VECTORIZE endif @Patrick: Could you update the debian/rules file please to use the above syntax? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1
Hi, On Sat, 2024-06-08 at 09:15 +0200, Chris Hofstaedtler wrote: > > > I will take care of this myself. Please remove the upload. > > Done. Thanks. > > > I will try to fix the package tomorrow. Apologies for the delay. > > I'll take this opportunity to point out #1060195, a similar bug in > hfsprogs. Thanks for the reminder. Appreciate it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1
Hello, On Fri, 2024-06-07 at 22:14 +0200, John Paul Adrian Glaubitz wrote: > On Fri, 2024-06-07 at 21:42 +0200, Chris Hofstaedtler wrote: > > I've prepared an NMU for linux-minidisc (versioned as 0.9.16-2.1) and > > uploaded it to DELAYED/14. Please feel free to tell me if I > > should delay it longer. > > I will take care of this myself. Please remove the upload. Sorry for the brevity in my previous mail. The reason I didn't fix this bug was because I missed the bug notification mail, so I wasn't aware this bug was around. I will try to fix the package tomorrow. Apologies for the delay. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1057827: linux-minidisc: diff for NMU version 0.9.16-2.1
Hello, On Fri, 2024-06-07 at 21:42 +0200, Chris Hofstaedtler wrote: > I've prepared an NMU for linux-minidisc (versioned as 0.9.16-2.1) and > uploaded it to DELAYED/14. Please feel free to tell me if I > should delay it longer. I will take care of this myself. Please remove the upload. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072774: zfs-linux: draid autopkgtests fail on s390x architecture
Package: zfs-linux Version: 2.2.4-1 Severity: normal X-Debbugs-Cc: john.ca...@canonical.com Dear Maintainer, Presently, zfs-linux fails when running draid tests from kernel-smoke-tests in debian/tests on s390x architecture with the following error: "kernel smoke test, create and destroy pool, draid1: FAILED: zpool create failed, exit code=1" I have logs available if necessary, and have access to a s390x machine to aid with testing if helpful. -- System Information: Debian Release: bookworm/sid APT prefers jammy-updates APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), (100, 'jammy-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-35-generic (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1072769: libvirt-daemon: Cannot connect to hypervisor with user session after upgrade
Package: libvirt-daemon Version: 10.4.0-1 Severity: important Dear Maintainer, I just did a Sid dist-upgrade and apart from a bunch of t64 packages, it upgraded libvirt-daemon (etc) to 10.4.0-1 Then I could no longer connect to qemu://session from virt-manager or virsh, I got the errors: error: failed to connect to the hypervisor virsh error: Cannot recv data: Connection reset by peer In journalctl I was also seeing this: internal error: could not find a usable firewall backend Initialization of bridge state driver failed: internal error: could not find a usable firewall backend I use nftables (not firewalld). I tried installing firewalld, restarting libvirtd and rebooting all to no avail. Strangely enough I could run "virsh -c qemu:///system list" as my regular user although I got no output (I have no system VM's) it didn't error, so I assume its a permissions change or simply a bug in 10.4? Downgrading to 10.3.0-3 versions of these packages fixed the issue: libvirt0_10.3.0-3_amd64.deb libvirt-clients_10.3.0-3_amd64.deb libvirt-daemon_10.3.0-3_amd64.deb libvirt-daemon-config-network_10.3.0-3_all.deb libvirt-daemon-config-nwfilter_10.3.0-3_all.deb libvirt-daemon-driver-lxc_10.3.0-3_amd64.deb libvirt-daemon-driver-qemu_10.3.0-3_amd64.deb libvirt-daemon-driver-vbox_10.3.0-3_amd64.deb libvirt-daemon-system_10.3.0-3_amd64.deb libvirt-daemon-system-systemd_10.3.0-3_all.deb libvirt-l10n_10.3.0-3_all.deb libvirt-login-shell_10.3.0-3_amd64.deb python3-libvirt_10.3.0-1_amd64.deb I also tried 10.0.0-2 and that seemed to fix it too (didn't try "virsh start" but "virsh list" worked) which I think was the version I was on beforehand, or 9.x I dug around for hours trying to find a useful error message or pointer to a reason (logs, strace, config etc.) but found nothing, any ideas? Regards. -- Simon John
Bug#1051579: nomacs: segmentation fault in std::__atomic_base
On Sun, 10 Sep 2023 01:01:50 +0200 Vincent Lefevre wrote:> Package: nomacs > Version: 3.17.2282+dfsg-2 > Severity: important > > I got a segmentation fault when doing "View -> Close Tab" then > a double click on a directory. > Thank you for reporting. This has been fixed in the following pull request. https://github.com/nomacs/nomacs/pull/1087
Bug#1071117: fccexam: update question pool and URL
On Tue, May 14, 2024 at 4:57 PM Austen, Jeffrey wrote: > Package: fccexam > Version: 1.0.7-1.1 ... > Please update the question pool. Element 7 has changed. ... > The URL in the package description should be updated ... fccexam 1.0.8 is available at: https://launchpad.net/~jnogatch/+archive/ubuntu/fccexam This version includes the updates that you requested. -John AC6SL
Bug#1072407: Fix is coming
I am fixing this FFmpeg API change in upstream. The new version builds under unstable and experimental. I have uploaded an updated package to mentors.debian.net. You should see it soon. -- john
Bug#1072574: kernel-wedge: Enable Renesas RZ/G3S and RZ/V2H boards
Package: kernel-wedge Severity: important Tags: d-i X-Debbugs-Cc: john.vincent...@bp.renesas.com Dear Maintainer, Please enable Renesas RZ/G3S and RZ/V2H device support in Debian by updating the following configurations: CONFIG_ARCH_R9A09G057=y #RZ/V2H CONFIG_ARCH_R9A08G045=y #RZ/G3S Best Regards John -- System Information: Debian Release: 11.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-30-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages kernel-wedge depends on: pn debhelper ii make 4.3-4.1 kernel-wedge recommends no packages. kernel-wedge suggests no packages.
Bug#1051068: sysprof: Should mark test build dependencies as
On Tue, 2024-06-04 at 10:36 -0400, Jeremy Bícha wrote: > On Sat, Sep 2, 2023 at 4:22 PM Jeremy Bícha > wrote: > > > > Control: tags -1 moreinfo > > > > On Sat, Sep 2, 2023 at 2:06 AM John Paul Adrian Glaubitz > > wrote: > > > src:sysprof has multiple build dependencies in debian/control which are > > > required for running the testsuite only but yet these build dependencies > > > are not marked as to allow the package to be bootstrapped on > > > a new architecture. > > > > I was unable to identify any build dependencies like that. Please > > submit a merge proposal if you have specific improvements in mind. > > I am closing this bug since there has been no reply and there wasn't > enough information in this bug report to take any action. Hmm, I'm pretty sure that these were obvious. I will have to recheck. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072539: ipywidgets: Recent changes introduced nodejs dependency limiting portability
Source: ipywidgets Version: 8.1.2-3 Severity: important Hello, the recent change to obsolete some binary packages in ipywidgets [1] introduced a hard dependency on nodejs which is available on a limited set of architectures only making ipywidgets uninstallable on a number of architectures: - alpha - hppa - hurd-amd64 - hurd-i386 - m68k - powerpc - ppc64 - sh4 - sparc64 - x32 Would it be possible to revert this change to remove the introduced dependency on nodejs again? Thanks, Adrian > [1] > https://salsa.debian.org/python-team/packages/ipywidgets/-/commit/ab52650adf13fd9f82f66dc1b328d04128496dcf -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#635834: Revisiting inclusion of AcroTeX/eForms in TeX Live in light of advancements in libre PDF readers
Hello, I must disclaim that I've not used these packages yet and would welcome being informed if I'm mistaken. It looks like both TeX Live and Debian have had reservations about shipping AcroTeX and eForms because at the time it was considered, the only PDF readers that appeared to support the features were proprietary ones. However, it seems that free PDF viewers have made great strides in the past several years especially in supporting these advanced features, so I think their inclusion in the standard distribution should be reconsidered. Free PDF viewers, especially Okular with the Poppler backend, have gained support for many of the features that have been standardized, including non-XFA forms, digital/cryptographic signature support, and JavaScript, all things that eForms appears to assist in making. There are probably still some things that AcroTeX and eForms can do that only proprietary readers support, but unless software patents muddy the waters, it seems like this can improve in client software at any time. Frankly I'm itching to use this functionality in my documents, but as a strong advocate for free software as well, I'd like to be informed if there are any freedom or distribution issues remaining. Thanks, John P.S. I'm having trouble subscribing, so please CC me on replies. -- Homepage: https://johnscott.me Contact info: as a vCard: https://johnscott.me/me/me.vcf or as an LDAP directory entry: ldap://johnscott.me/CN=John%20Scott,DC=johnscott,DC=me signature.asc Description: This is a digitally signed message part smime.p7s Description: S/MIME cryptographic signature
Bug#944139: Another possible solution
I can confirm that Christopher's patch, https://salsa.debian.org/debian/debmirror/-/merge_requests/15, fixes the original problem. John
Bug#1072481: RFP: cockpit-filesharing — A plugin for Cockpit to manage Samba and NFS shares.
Package: wnpp Severity: wishlist The software enables the capacity to manage the network shares provided by Samba and NFS, via Cockpit. This is for the server on which Cockpit is installed, or can be connected to through the multiple server functionality of web interface daemon. The original official developers are concentrating on RPM based distributions, but do have a Debian repository. However it’s only valid for Debian 11 and Ubuntu Linux up to 20.04. https://github.com/45Drives/cockpit-file-sharing Sent from my iPad
Bug#1072479: RFP: cockpit-navigator — Web based file browser for cockpit to navigate filesystem.
Package: wnpp Severity: wishlist The package is really useful as it allows users, to navigate the filesystem of the server, on which the instance of Cockpit installed on. In order to manage its filesystem without, needing to connect and login with SSH to do so. The official developers of the software are currently concentrating on RPM distributions. They do have a Debian repository however the packages, are only built for Bullseye and not Debian Linux 12 or even the upcoming Debian Linux 13. https://github.com/45Drives/cockpit-navigator Sent from my iPad
Bug#1072382: nextcloud-desktop: Randomly starts, keeps restarting on exit
Package: nextcloud-desktop Version: 3.11.0-1.1+b1 Severity: normal X-Debbugs-Cc: contrapunc...@disroot.org Dear Maintainer, The Nextcloud desktop application often seems to start of its own accord, and frequently restarts when I exit it (by right clicking the tray icon - Exit Nextcloud). -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.7.12-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages nextcloud-desktop depends on: ii libc6 2.38-11 ii libcloudproviders0 0.3.6-1 ii libgcc-s1 14-20240330-1 ii libglib2.0-0t642.80.2-2 ii libkf5archive5 5.115.0-2 ii libnextcloudsync0t64 3.11.0-1.1+b1 ii libqt5core5t64 5.15.10+dfsg-7.2+b1 ii libqt5dbus5t64 5.15.10+dfsg-7.2+b1 ii libqt5gui5t64 5.15.10+dfsg-7.2+b1 ii libqt5keychain10.14.3-1 ii libqt5network5t64 5.15.10+dfsg-7.2+b1 ii libqt5qml5 5.15.10+dfsg-2+b2 ii libqt5quick5 5.15.10+dfsg-2+b2 ii libqt5quickcontrols2-5 5.15.10+dfsg-2+b2 ii libqt5sql5-sqlite 5.15.10+dfsg-7.2+b1 ii libqt5svg5 5.15.10-2+b2 ii libqt5webenginecore5 5.15.15+dfsg-2+b1 ii libqt5webenginewidgets55.15.15+dfsg-2+b1 ii libqt5widgets5t64 5.15.10+dfsg-7.2+b1 ii libssl3t64 3.2.1-3 ii libstdc++6 14-20240330-1 ii nextcloud-desktop-common 3.11.0-1.1 ii nextcloud-desktop-l10n 3.11.0-1.1 ii qml-module-qt-labs-platform5.15.10+dfsg-2+b2 ii qml-module-qtgraphicaleffects 5.15.10-2+b2 ii qml-module-qtqml 5.15.10+dfsg-2+b2 ii qml-module-qtqml-models2 5.15.13+dfsg-2 ii qml-module-qtquick-controls2 5.15.10+dfsg-2+b2 ii qml-module-qtquick-layouts 5.15.10+dfsg-2+b2 ii qml-module-qtquick-window2 5.15.10+dfsg-2+b2 ii qml-module-qtquick25.15.10+dfsg-2+b2 Versions of packages nextcloud-desktop recommends: ii nextcloud-desktop-doc 3.11.0-1.1 nextcloud-desktop suggests no packages. -- no debconf information
Bug#1072345: gcc-14: FTBFS on x32 due to missing package gccrs-14-x86-64-linux-gnux32
OK, it seems that this is because of x32 being part of "rs_no_cpu" in debian/rules.defs. So, please remove x32 from the Rust exclusion list and add cargo to BuildDepends in debian/control. It remains to be resolved why the build tries to enable Rust support despite x32 being in "rs_no_cpu" in debian/rules.defs. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072345: gcc-14: FTBFS on x32 due to missing package gccrs-14-x86-64-linux-gnux32
Source: gcc-14 Version: 14.1.0-1 Severity: normal Hello, trying to build gcc-14 on x32 fails because the package gccrs-14-x86-64-linux-gnux32 is missing in debian/control so that the call to dh_installdirs fails: dh_installdirs -pgccrs-14-x86-64-linux-gnux32 usr/bin usr/share/man/man1 usr/libexec/gcc/x86_64-linux-gnux32/14 usr/share/lintian/overrides dh_installdirs: error: Requested unknown package gccrs-14-x86-64-linux-gnux32 via -p/--package, expected one of: gcc-14-base libgcc-s1 (...) gccrs-14-for-build gccrs-14 gcc-14-source dh_installdirs: error: unknown option or error during option parsing; aborting I assume the oversight was that on x32, the architecture is not used as a package prefix but a package suffix, i.e. gccrs-14-x86-64-linux-gnux32 instead of gccrs-14-x32-linux-gnu. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072336: gcc-14: FTBFS on x32 due to outdated symbols file libasan8.symbols
Source: gcc-14 Version: 14.1.0-1 Severity: normal Hello, after installing cargo manually in the chroot to work around #1072327 [1], I ran into an FTBFS on x32 due to an outdated symbols file libasan8.symbols: dpkg-gensymbols: error: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libasan8/DEBIAN/symbols doesn't match completely debian/libasan8.symbols --- debian/libasan8.symbols (libasan8_14.1.0-1_x32) +++ dpkg-gensymbolsRcyeWc 2024-06-01 08:50:52.822957692 + @@ -402,7 +402,7 @@ ___interceptor_setlocale@Base 14 ___interceptor_setpwent@Base 14 ___interceptor_setvbuf@Base 14 - ___interceptor_shmctl@Base 14 +#MISSING: 14.1.0-1# ___interceptor_shmctl@Base 14 ___interceptor_sigaction@Base 14 ___interceptor_sigaltstack@Base 14 ___interceptor_sigandset@Base 14 @@ -1579,7 +1579,7 @@ __interceptor_trampoline_setlocale@Base 14 __interceptor_trampoline_setpwent@Base 14 __interceptor_trampoline_setvbuf@Base 14 - __interceptor_trampoline_shmctl@Base 14 +#MISSING: 14.1.0-1# __interceptor_trampoline_shmctl@Base 14 __interceptor_trampoline_sigaction@Base 14 __interceptor_trampoline_sigaltstack@Base 14 __interceptor_trampoline_sigandset@Base 14 dh_makeshlibs: error: failing due to earlier errors I have uploaded the full gzipped build log in [2] since there were additional messages regarding symbols. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072327 > [2] http://people.debian.org/~glaubitz/gcc-14_14.1.0-1_x32.build.gz -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1063735: python-maturin - upcoming rust-indexmap update.
Package: python-maturin Followup-For: Bug #1063735 Control: severity -1 serious Hello, I am setting the severity to serious now as this actually causes python-maturin to fails to build from source [1]: cargo generate-lockfile --offline error: failed to select a version for the requirement `indexmap = "^1.9.3"` candidate versions found which didn't match: 2.2.6 location searched: directory source `/usr/share/cargo/registry` (which is replacing registry `crates-io`) required by package `maturin v1.3.2 (/<>)` perhaps a crate was updated and forgotten to be re-vendored? Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=python-maturin=sparc64=1.3.2-1=1717193660=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072328: gcc-14: Please add 32-bit SPARC (sparc) to ada_no_cpu
Source: gcc-14 Version: 14.1.0-1 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, I am currently building a cross-compiler for 32-bit SPARC (sparc) and noticed that I had to disable Ada by adding "sparc" to "ada_no_cpu" in debian/rules.defs to get the compiler to build due to #1072071 [1]. Since I don't expect #1072071 to be fixed quickly, it would be good to just to add "sparc" to "ada_no_cpu" in debian/rules.defs. PS: Please note, this bug does not affect sparc64! There are no changes required for sparc64. Thanks, Adrian > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072071 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072327: gcc-14: Missing cargo build dependency on x32
Source: gcc-14 Version: 14.1.0-1 Severity: normal Hello, The gcc-14 source package is missing cargo as build dependency which is why the build currently fails with [1]: > configure: error: cargo is required to build rust cargo was briefly not available on x32, but is installable again. Thanks, Adrian > [1] > https://buildd.debian.org/status/fetch.php?pkg=gcc-14=x32=14.1.0-1=1715675531=0 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1072283: chromium: Chromium FTBFS Depends: rustc-web but it is not installable
Package: chromium Version: 125.0.6422.112-1~deb12u1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Dear Maintainer, * What led up to the situation? Tried to build chromium * What exactly did you do (or not do) that was effective (or ineffective)? apt source chromium apt build-dep chromium * What was the outcome of this action? Depends: rustc-web but it is not installable * What outcome did you expect instead? Many hours of compilation followed by an installable chromium -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chromium depends on: ii chromium-common125.0.6422.112-1~deb12u1 ii libasound2 1.2.8-1+b1 ii libatk-bridge2.0-0 2.46.0-5 ii libatk1.0-02.46.0-5 ii libatomic1 12.2.0-14 ii libatspi2.0-0 2.46.0-5 ii libc6 2.36-9+deb12u7 ii libcairo2 1.16.0-7 ii libcups2 2.4.2-3+deb12u5 ii libdav1d6 1.0.0-2+deb12u1 ii libdbus-1-31.14.10-1~deb12u1 ii libdouble-conversion3 3.2.1-1 ii libdrm22.4.114-1+b1 ii libevent-2.1-7 2.1.12-stable-8 ii libexpat1 2.5.0-1 ii libflac12 1.4.2+ds-2 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgbm122.3.6-1+deb12u1 ii libgcc-s1 12.2.0-14 ii libglib2.0-0 2.74.6-2+deb12u2 ii libgtk-3-0 3.24.38-2~deb12u1 ii libharfbuzz-subset06.0.0+dfsg-3 ii libharfbuzz0b 6.0.0+dfsg-3 ii libjpeg62-turbo1:2.1.5-2 ii libjsoncpp25 1.9.5-4 ii liblcms2-2 2.14-2 ii libminizip11.1-8+deb12u1 ii libnspr4 2:4.35-1 ii libnss32:3.87.1-1 ii libopenh264-7 2.3.1+dfsg-3 ii libopenjp2-7 2.5.0-2 ii libopus0 1.3.1-3 ii libpango-1.0-0 1.50.12+ds-1 ii libpng16-161.6.39-2 ii libpulse0 16.1+dfsg1-2+b1 ii libsnappy1v5 1.1.9-3 ii libstdc++6 12.2.0-14 ii libwoff1 1.0.2-2 ii libx11-6 2:1.8.4-2+deb12u2 ii libxcb11.15-1 ii libxcomposite1 1:0.4.5-1 ii libxdamage11:1.1.6-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes3 1:6.0.0-2 ii libxkbcommon0 1.5.0-1 ii libxml22.9.14+dfsg-1.3~deb12u1 ii libxnvctrl0525.85.05-3~deb12u1 ii libxrandr2 2:1.5.2-2+b1 ii libxslt1.1 1.1.35-1 ii xdg-desktop-portal-gnome [xdg-desktop-portal-back 43.1-2 end] ii xdg-desktop-portal-gtk [xdg-desktop-portal-backen 1.14.1-1 d] ii zlib1g 1:1.2.13.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 125.0.6422.112-1~deb12u1 Versions of packages chromium suggests: pn chromium-driver pn chromium-l10n pn chromium-shell Versions of packages chromium-common depends on: ii libc6 2.36-9+deb12u7 ii libdrm2 2.4.114-1+b1 ii libjsoncpp25 1.9.5-4 ii libstdc++6
Bug#1069625: Acknowledgement (gstreamer1.0: Don't build ptp-helper on hppa)
Hello, the suggested patch is incomplete as it breaks the installation of ptp-helper on architectures with Rust support by just removing it from the .install file. I have improved the patch in this regard by employing dh-exec and extended it for the remaining Debian Ports architectures without Rust support (alpha, m68k and sh4). I intentionally omitted ia64 as it will be dropped from Debian Ports within the next days. NB: For dh-exec to work, the file libgstreamer1.0-0.install *must* be executable. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 diff -Nru old/gstreamer1.0-1.24.3/debian/changelog new/gstreamer1.0-1.24.3/debian/changelog --- old/gstreamer1.0-1.24.3/debian/changelog 2024-04-30 10:40:18.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/changelog 2024-05-28 07:57:26.535826780 +0200 @@ -1,3 +1,9 @@ +gstreamer1.0 (1.24.3-1+ports) unreleased; urgency=medium + + * Disable rustc for unsupported architectures + + -- John Paul Adrian Glaubitz Tue, 28 May 2024 07:57:09 +0200 + gstreamer1.0 (1.24.3-1) unstable; urgency=medium * New upstream version 1.24.3 diff -Nru old/gstreamer1.0-1.24.3/debian/control new/gstreamer1.0-1.24.3/debian/control --- old/gstreamer1.0-1.24.3/debian/control 2024-04-30 10:40:18.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/control 2024-05-28 11:16:10.247257446 +0200 @@ -6,6 +6,7 @@ Sjoerd Simons , Marc Leeman , Build-Depends: debhelper-compat (= 13), + dh-exec, dh-sequence-gir, meson (>= 0.62), pkgconf, @@ -18,7 +19,7 @@ libdw-dev [i386 amd64 armel armhf arm64 powerpc ppc64 ppc64el mipsel mips64el riscv64], bison, flex, - rustc, + rustc [!alpha !hppa !m68k !sh4], libgirepository1.0-dev, gir1.2-glib-2.0, gir1.2-freedesktop, diff -Nru old/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install new/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install --- old/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install 2024-04-30 10:37:47.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/libgstreamer1.0-0.install 2024-05-28 07:55:56.540429867 +0200 @@ -1,5 +1,6 @@ +#!/usr/bin/dh-exec usr/lib/*/gstreamer-1.0/*.so usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner -usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper +[!alpha !hppa !m68k !sh4] usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper usr/lib/*/*.so.* usr/share/locale diff -Nru old/gstreamer1.0-1.24.3/debian/rules new/gstreamer1.0-1.24.3/debian/rules --- old/gstreamer1.0-1.24.3/debian/rules 2024-04-30 10:37:47.0 +0200 +++ new/gstreamer1.0-1.24.3/debian/rules 2024-05-28 09:39:31.503804282 +0200 @@ -44,6 +44,10 @@ conf_flags += -Dlibunwind=disabled -Dlibdw=disabled endif +ifneq (,$(filter $(DEB_HOST_ARCH),alpha hppa m68k sh4)) +conf_flags += -Dptp-helper=disabled +endif + infiles := \ libgstreamer1.0-0.postinst
Bug#1072071: gcc-13: Please add libatomic for 32-bit SPARC for Ada
Source: gcc-13 Version: 13.2.0-25 Severity: normal User: debian-sp...@lists.debian.org Usertags: sparc X-Debbugs-Cc: debian-sp...@lists.debian.org Hello, I just tried to build a cross-compiler for 32-bit SPARC (Debian arch sparc) with Ada enabled. The build failed with a linker failure which indicates that linking against libatomic is required: checking float.h presence... yes checking for float.h... yes checking fp.h usability... /usr/sparc-linux-gnu/bin/ld: libgnat-13.so: undefined reference to `__atomic_compare_exchange_8' collect2: error: ld returned 1 exit status Such a patch already exists for armel [1], so it should be easy to extend it for 32-bit SPARC. 64-bit SPARC (Debian arch sparc64) is not affected, linking against libatomic is therefore not required. Thanks, Adrian > [1] > https://salsa.debian.org/toolchain-team/gcc/-/blob/gcc-13-debian/debian/patches/ada-armel-libatomic.diff -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#970043: Request to help test ia64 build for galera-4
evel/2023-05/msg00051.html > > In general I thought that UEFI was derived from EFI, so I don't really > see, why both can't coexist together. But I might have to do further > research on that. Apart from that, ELILO is working perfectly fine both > for diskless boots and booting from disk. ELILO is unmaintained and has had various issues and bugs in the past which is why I switched to GRUB on Debian back then. But it also looks like that ia64 support is going to stay in GRUB for a while, I haven't seen any new efforts for removing it lately on the grub-devel mailing list. > > - ia64 uses a 61-bit virtual address space as opposed to the 48-bit virtual > >address space found on x86_64; > > Yes, it was done earlier than x86_64. > > > this causes problems with languages like > >JavaScript which use tagged pointers to encode type information in the > >bits unused on x86_64, see: > > > >> https://www.ia64-linux.org/doc/IA64linuxkernel.PDF (p. 18) > > > >(NB: This is expected to improve in the future as x86_64 optionally > > supports > > larger virtual address spaces in the kernel nowadays as well). > > > > - the math error handling ABI on ia64 in glibc is different from other > > architectures > >and the code for it in sysdeps/ia64/fpu/libm_error.c is quite > > convoluted; as glibc > >tries to unify and simplify FPU error handling, the different semantics > > of the ia64 > >ABI would require - quoting Adhemerval here - »a lot boilerplate and > > mechanical > >changes« which he doesn't think is worth the effort > > I think we could have done more in this regard, if ia64 support wouldn't > have been removed from Linux last year, requiring additional work > everywhere. But I don't complain, I think it also forced our hands. Well, I have done a lot of work in this regard in the past to get JavaScript fixed on targets with virtual address space sizes beyond 48 bits. But it's still not fixed everywhere, especially not in Qt5. It has been fixed in Qt6 though. > > There are probably more issues and quirks that I don't remember, but I > > think the list > > above already mentions enough show stoppers which mean that upstream > > projects won't be > > willing to re-add support for the architecture. > > Thanks for your assessment. I consider that much more useful than to > advise people against working on ia64. I'm not advising against you to do anything. You are free to spend your free time with whatever you want and if you think that keeping ia64 is worth the effort, more power to you! All I did was giving an elaborate explanation why ia64 is going to be removed from Debian within the next days and why I personally think it's a lost cause. > > Of course, I am not going to stop you from continuing your work and I think > > such efforts > > are always laudable. I just don't think the very limited interest in this > > architecture > > will be enough to overcome the difficulties that ia64 maintainers have to > > face. > > > > This is also the reason why the ia64 maintainers of neither Debian nor > > Gentoo were against > > the removal of support for the architecture in Ruby, the Linux kernel, > > glibc and so on. > > Being not against something and taking care of something are two > different things. But why would maintainers start an argument with upstream developers over something they don't really care about? That makes no sense. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#970043: Request to help test ia64 build for galera-4
Hello Frank, On Sat, 2024-05-25 at 18:29 +0200, Frank Scheiner wrote: > > ia64 support has been removed from glibc, the Linux kernel and soon gcc, > > First - ia64 support was actually removed from the glibc **because** it > was removed from Linux. It was also removed because there was no maintainer for it in glibc and suffered from a lot of testsuite failures. I tried for a long time to convince Adhemerval to fix these issues, but he explained that it would involve rewriting large parts of the math code for ia64 which he thought wasn't worth the effort. > Second, how did you come to the conclusion that ia64 support will be > removed from the gcc soon? gcc usually drops support for a target when it's no longer present in the kernel and glibc. That happened in the past and that will happen in the future, although there are some targets like Blackfin, CRIS and M32R that are still supported by gcc while being dropped by the kernel. And since ia64 support has already been marked as deprecated, I expect it to be removed from gcc soon. Especially, since ia64 adds a lot of complexity to gcc due to its VLIW design. > Rene said he would step up as maintainer for ia64 in gcc - see the > thread at [1] - and I haven't heard any different since then. > > [1]: https://gcc.gnu.org/pipermail/gcc/2024-March/243432.html > > @Rene: Can you confirm? As of now, gcc is still marked as deprecated: > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config.gcc;h=a37113bd00aef1412771f7dd630abebabd444c1f;hb=HEAD#l273 > > so it will be removed within the next weeks after we have made an archive > > copy. > > > > There is no need to fix any bugs on ia64. > > Let me correct that for you: > > There is no need to fix any bugs for ia64 in Debian (Ports) - as sad as > that is. Have you already sorted out who is going to maintain ia64 support in glibc and the Linux kernel? And do you already know how to get Ruby upstream to re-add ia64 support? Ruby is required for a lot of other packages that depend on it. As someone who has been maintaining many exotic or deprecated architectures both in Debian and in the Linux kernel, I know how much work it involves to keep a port alive and running. And since I have also maintained ia64 in the past and know about all the quirks and problems the port has, I think the possibility that the port will ever return upstream to the kernel, glibc and the Ruby interpreter is nearly zero. To summarize the known issues and quirks on ia64: - ia64 has two stacks growing in opposite directions making exception handling in languages like Ruby more complicated and requiring additional code, see: > https://github.com/ruby/ruby/blob/master/doc/NEWS/NEWS-2.7.0 (search for IA64) - the VLIW design adds a lot of complexity to the compiler; when it was created, designers expected the design to be superior but it turned out that the implementation was more challenging than expected and left gcc with a lot of unresolved problems on ia64, see: > https://gcc.gnu.org/projects/ia64.html - ia64 comes with its own implementation of EFI which is not fully compatible with UEFI and requires additional support code; this was the main reason why some GRUB developers wanted to get rid of ia64 support, see: > https://lists.gnu.org/archive/html/grub-devel/2023-05/msg00051.html - ia64 uses a 61-bit virtual address space as opposed to the 48-bit virtual address space found on x86_64; this causes problems with languages like JavaScript which use tagged pointers to encode type information in the bits unused on x86_64, see: > https://www.ia64-linux.org/doc/IA64linuxkernel.PDF (p. 18) (NB: This is expected to improve in the future as x86_64 optionally supports larger virtual address spaces in the kernel nowadays as well). - the math error handling ABI on ia64 in glibc is different from other architectures and the code for it in sysdeps/ia64/fpu/libm_error.c is quite convoluted; as glibc tries to unify and simplify FPU error handling, the different semantics of the ia64 ABI would require - quoting Adhemerval here - »a lot boilerplate and mechanical changes« which he doesn't think is worth the effort There are probably more issues and quirks that I don't remember, but I think the list above already mentions enough show stoppers which mean that upstream projects won't be willing to re-add support for the architecture. Of course, I am not going to stop you from continuing your work and I think such efforts are always laudable. I just don't think the very limited interest in this architecture will be enough to overcome the difficulties that ia64 maintainers have to face. This is also the reason why the ia64 maintainers of neither Debian nor Gentoo were against the removal of support for the architecture in Ruby, the Linux kernel, glibc and so on. Adrian -- .''`. Joh
Bug#970043: Request to help test ia64 build for galera-4
Hi Otto, On Fri, 2024-05-24 at 21:24 -0700, Otto Kekäläinen wrote: > I have a patch to tentatively fix Debian package galera-4 builds on > ia64 at https://salsa.debian.org/mariadb-team/galera-4/-/merge_requests/19 > > Would anybody be interested in helping out and testing if the build > fully passes now? > > Details in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970043 ia64 support has been removed from glibc, the Linux kernel and soon gcc, so it will be removed within the next weeks after we have made an archive copy. There is no need to fix any bugs on ia64. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Bug#1071276: Is 1:1.2.13.dfsg-1 affected by CVE-2023-45853, and if it is, will 1:1.3.dfsg-3.1 be backported to bookworm?
Hello, I was thinking about this a bit more and I had a question, > Let me as well elaborate on the "ingored". This comes as the binary packages built from the *vulnerable* source, there is no point to force an update in bookworm and older. It sounds like Debian uses the "ignored" state to mean "this bug does not affect the Debian package". Is there another state that's used to indicate "won't fix"? Can we assume that "ignored" always means "won't fix"? Or can "ignored" mean either thing and we'd have to look in the notes to know for sure? Thanks, - J On Wed, May 22, 2024 at 9:56 AM John Waffle wrote: > Hello, > > I got a response from trivy, > https://github.com/aquasecurity/trivy/discussions/6722#discussioncomment-9518531 > > > Helllo @superlazyname <https://github.com/superlazyname> > > Thanks for your report! > > > As you can see - we marked this vulnerability as "Status": > "will_not_fix",. > > We use will_not_fix for vulnerabilities with ignored State. > > We can't parse State description, because it deoesn't have format. > > > [bookworm] - zlib (contrib/minizip not built and producing binary > packages) > > > It seems that debian chose wrong state. not_affected looks more correct. > -- > > > Trivy supports VEX > <https://aquasecurity.github.io/trivy/v0.51/docs/supply-chain/vex/>. > > You can create VEX file to ignore this CVE. > > > Regards, Dmitriy > > I'll call out these particular points, > > > We can't parse State description, because it doesn't have format. > > > It seems that debian chose wrong state. not_affected looks more correct. > > It sounds like this is some kind of incompatibility between how trivy > conceptualizes CVEs vs how Debian conceptualizes CVEs, plus a terminology > problem on the meaning of "ignored" (won't fix vs is not affected) > > - Would you consider marking the vulnerability as "not_affected" instead > of "ignored"? Or does the Debian CVE tracking system not support that? > > - I would agree that " [bookworm] - zlib (contrib/minizip not built and > producing binary packages)" doesn't have a standard format, but is there no > other viable way for a scanner to pick up on the CVE being ignored? > > - Do you have docs to show what method should be used to properly handle > this issue being marked as "ignored"? Do you have any sample code / script > snippets you can share with me? Maybe I can submit a PR? > > Maybe there is some way for trivy to notice that the issue is "ignored" > and then, for only Debian, interpret that as not_affected. > > - John > > On Sat, May 18, 2024 at 5:03 AM Salvatore Bonaccorso > wrote: > >> Hi John, >> >> On Fri, May 17, 2024 at 04:01:56PM -0400, John Waffle wrote: >> > This report came from a free tool, trivy, I filed a Github discussion >> about >> > it here: https://github.com/aquasecurity/trivy/discussions/6722 >> >> Thanks a lot for bringing that upstream. >> >> So to add some additional datapoint: The issue araises here by maybe >> thinking zlib refers to the binary package produced. It is correct, >> for the binary package zlib then indeed you would not be vulnerable. >> >> Let me as well elaborate on the "ingored". This comes as the binary >> packages built from the *vulnerable* source, there is no point to >> force an update in bookworm and older. >> >> I hope this all get a better picture now on the CVE. If you still have >> questions feel free to ask. >> >> Regards, >> Salvatore >> >
