Bug#1077452: picolibc: FTBFS: make[1]: *** [debian/rules:134: override_dh_auto_test] Error 104
Quoting Keith Packard (2024-09-11 19:59:25) > > In an upstream github issue that Keith responded to a week or more ago he > > did say he couldn't do anything immediately as he was "off flying rockets" > > - I took that to mean he is likely enjoying a vacation but may be back to > > tackle this soon. > > I've been managing some final PRs into picolibc 1.8.7 and am busy releasing > that today. This will close #1077452 and #1080065. Thank you for your work and congrats on the new upstream release! :) signature.asc Description: signature
Bug#1077452: picolibc: FTBFS: make[1]: *** [debian/rules:134: override_dh_auto_test] Error 104
On Tue, 10 Sep 2024 16:56:49 + Tj wrote: > > Since Keith seems to still be busy, I'm wondering how to best fix this > > FTBFS via an NMU without doing a huge change like importing a new upstream > > release. > > > > What do you think of doing a minimal NMU which just temporarily (until a > > new upstream version is packaged) disables the tests? > > In an upstream github issue that Keith responded to a week or more ago he did > say he couldn't do anything immediately as he was "off flying rockets" - I > took that to mean he is likely enjoying a vacation but may be back to tackle > this soon. In case of Keith, "off flying rockets" means literally that. :) Keith wrote a firmware called [AltOS] which coincidentally is one of the users of picolibc. :D Thanks! cheers, josch [AltOS] https://altusmetrum.org/AltOS/ signature.asc Description: signature
Bug#1077452: picolibc: FTBFS: make[1]: *** [debian/rules:134: override_dh_auto_test] Error 104
Hi, On Thu, 05 Sep 2024 14:13:14 +0100 Tj wrote: > The package needs updating to the current (2024-09-05) upstream HEAD /and/ > build-testing via sbuild to ensure it builds and tests correctly. > > There are an entire series of TIMEOUT issues in the arm and aarch64 > tests that are fixed by various patches since 1.8.6. > > It is not worth trying to pick out the commits to fix the failures - > I've done that extensively and it is not practical. > > The arm tests failed due to two issues; MMU not being enabled > (commit 5252f4dd236e4) and exception vector table being generated with > Thumb instructions not ARM32 (commit dd711267309fbc3d and > b2d921a71ea011d4c1c) but other commits are needed preceding those. > > With all the arm tests fixed there are 32 failed aarch64 tests and no > idea if other architectures will also have failures. > > Building with latest origin/main all tests pass and package builds > successfully. thank you and mjt for all the time you've put into figuring out what's going on! Since Keith seems to still be busy, I'm wondering how to best fix this FTBFS via an NMU without doing a huge change like importing a new upstream release. What do you think of doing a minimal NMU which just temporarily (until a new upstream version is packaged) disables the tests? Thanks! cheers, josch signature.asc Description: signature
Bug#1081201: libc6-dev:amd64 : Breaks: libc6-dev-amd64-cross (< 2.40~) but 2.39-4cross1 is to be installed
Package: libc6-dev-amd64-cross Version: 2.39-4cross1 Severity: serious X-Debbugs-Cc: debian-cr...@lists.debian.org Hi, while trying to cross-build the next upload of my source package pico-sdk for amd64 on my arm64 box in a clean unstable chroot with sbuild, I ran into the following problem: Install main build dependencies (apt-based resolver) Installing build dependencies Reading package lists... Building dependency tree... Reading state information... Execute external solver... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libc6-dev:amd64 : Breaks: libc6-dev-amd64-cross (< 2.40~) but 2.39-4cross1 is to be installed E: Broken packages apt-get failed. E: Package installation failed On salsa-ci, the problem is even more weird. The test-crossbuild-arm64 job ends up installing the native architecture compilers: The following NEW packages will be installed: binutils-aarch64-linux-gnu:arm64 binutils-common:arm64 cpp-14-aarch64-linux-gnu:arm64 cpp-aarch64-linux-gnu cross-config crossbuild-essential-arm64 dpkg-cross file g++-14-aarch64-linux-gnu:arm64 g++-aarch64-linux-gnu gcc-14-aarch64-linux-gnu:arm64 gcc-14-base:arm64 gcc-aarch64-linux-gnu libasan8:arm64 libatomic1:arm64 libbinutils:arm64 libc6:arm64 libc6-dev:arm64 libcc1-0:arm64 libconfig-auto-perl libconfig-inifiles-perl libcrypt-dev:arm64 libcrypt1:arm64 libctf-nobfd0:arm64 libctf0:arm64 libdebian-dpkgcross-perl libfile-homedir-perl libfile-which-perl libgcc-14-dev:arm64 libgcc-s1:arm64 libgmp10:arm64 libgomp1:arm64 libgprofng0:arm64 libhwasan0:arm64 libicu72 libio-string-perl libisl23:arm64 libitm1:arm64 libjansson4:arm64 liblocale-gettext-perl liblsan0:arm64 libmagic-mgc libmagic1t64 libmpc3:arm64 libmpfr6:arm64 libsframe1:arm64 libstdc++-14-dev:arm64 libstdc++6:arm64 libtsan2:arm64 libubsan1:arm64 libxml-libxml-perl libxml-namespacesupport-perl libxml-sax-base-perl libxml-sax-perl libxml-simple-perl libxml2 libyaml-perl libzstd1:arm64 sensible-utils ucf zlib1g:arm64 This means that the build later fails with: /usr/lib/ccache/aarch64-linux-gnu-g++ -g -O2 -ffile-prefix-map=/builds/debian/pico-sdk/debian/output/source_dir=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -o CMakeFiles/cmTC_e5da0.dir/testCXXCompiler.cxx.o -c /builds/debian/pico-sdk/debian/output/source_dir/pioasm-obj-aarch64-linux-gnu/CMakeFiles/CMakeScratch/TryCompile-fi0q8w/testCXXCompiler.cxx ccache: error: execute_noreturn of /usr/bin/aarch64-linux-gnu-g++ failed: Exec format error Because obviously, the compiler binary from g++-14-aarch64-linux-gnu:arm64 cannot be executed on amd64. Full log here: https://salsa.debian.org/debian/pico-sdk/-/jobs/6250227/raw The problem does not seem to be limited to my package pico-sdk, hence the severity. Thanks! cheers, josch
Bug#1079702: Both autopkgtest are flaky
Hi Jeremy, Quoting Jeremy Bícha (2024-08-28 14:56:56) > On Wed, Aug 28, 2024 at 8:51 AM Johannes Schauer Marin Rodrigues > wrote: > > That would be odd because the autopkgtest runs just fine and reliable on > > salsa > > ci. But I have to find a better way to automate testing of gtk4 applications > > before I tackle this problem again. Taking screenshots via VNC and trying to > > find buttons in them is not smart. > > There is dogtail but I haven't really used it. I have and it works great -- under Xorg. :) In wayland, things are a bit more complicated because, as I understood it, the fact that one application cannot find out the position of widgets in another is a deliberate security feature. This makes automation hard but also hampers accessibility. As far as I've read (I'm not a Gnome user) Gnome works around this by having a daemon process always running in the background which is able to negotiate widget position and content of all applications that are running in a gnome session. But as far as I know, automating wayland applications is just not a thing... I assume the gtk software in Debian is stuck at Xorg for automation purposes? > There is openqa.debian.net but I believe it's not currently connected to > britney for blocking migration to Testing. It appears to only current support > amd64 and arm64 which may be enough since that's where most of our users are. > Since OpenQA also works with screenshots, it is susceptible to changes in > fonts, themes, and text rendering although the threshold for how sensitive it > is can be modified. Yes, I've been in contact with Phil Hands on that topic and was already given a quick introduction. According to Phil, running this on openqa.d.n is definitely in scope of the service. I just have to learn how to interact with it now. :) Thanks! cheers, josch signature.asc Description: signature
Bug#1079702: autopkgtest 'test_without_chroot' is flaky
Quoting Jeremy Bícha (2024-08-27 22:26:39) > gtk4 has more failing build tests than other architectures. > Unfortunately, we are forced to ignore them because our understanding > is that it's currently required for desktop tasks to be installable on > all release architectures. (Or I guess someone could fix the bugs but > that can be difficult.) My next upload (today) will disable the autopkgtest of reform-setup-wizard and should thus not be an issue anymore for you. Sorry for the inconvenience this has caused you. > If you have screenshots to demonstrate s390x breakage that may be gtk4's > fault, please forward them to the Debian bugtracker for gtk4. No, the bug is probably in the VNC server wayvnc which is serving me a screenshot with the RGBA values in reverse making it look like this: https://mister-muffin.de/p/O9dl.png Likely just a big-endian issue. Thanks! cheres, josch signature.asc Description: signature
Bug#1079702: Both autopkgtest are flaky
Quoting Reinhard Tartler (2024-08-28 13:43:30) > Seems I made a mistake in my previous report. It is actually the test > 'test_without_chroot' that is flaky. Also, I noticed this comment in > https://sources.debian.org/src/reform-setup-wizard/1.0-11/debian/tests/control/#L7-L25: > > # Since this test is skipped if it runs inside LXC because podman errors > out > # when run under LXC, this test will never be used for migration checks, > so > # we do not need to be rigorous here. > # > > > As it turns out, this test *is* currently holding up testing migration > of podman to testing. I'm currently preparing a new upload which will disable the autopkgtests altogether. > Looking at the test logs, it seems it tries to start up Xwayland but the test > runs without xwayland installed in the testbed? Maybe a matter of missing > test dependencies? That would be odd because the autopkgtest runs just fine and reliable on salsa ci. But I have to find a better way to automate testing of gtk4 applications before I tackle this problem again. Taking screenshots via VNC and trying to find buttons in them is not smart. > May I suggest to add at very least the restriction 'isolation-machine', and > possibly 'flaky'? No sense in spending CPU time on a flaky one. Sorry for the inconvenience my package caused you. cheers, josch signature.asc Description: signature
Bug#1077452: picolibc: FTBFS: make[1]: *** [debian/rules:134: override_dh_auto_test] Error 104
Control: clone -1 -2 Control: reassign -2 src:qemu 1:9.0.1+ds-1 Control: tags -2 = Control: severity -2 important Control: retitle -2 Regression: QEMU 9 makes picolibc FTBFS (failing tests) Control: block -1 by -2 Hi, On Mon, 29 Jul 2024 07:54:19 +0200 Lucas Nussbaum wrote: > Source: picolibc > Version: 1.8.6-2 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240728 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build on > amd64. it's qemu. I used debbisect to make sure of this: $ DEBIAN_BISECT_SRCPKG=picolibc debbisect --cache=./cache 2024-02-26 2024-08-27 /usr/share/doc/devscripts/examples/debbisect_buildsrc.sh [...] bisection finished successfully last good timestamp: 20240705T143429Z first bad timestamp: 20240705T203346Z the following packages differ between the last good and first bad timestamp: qemu-system-arm 1:8.2.5+ds-2 -> 1:9.0.1+ds-1 qemu-system-common 1:8.2.5+ds-2 -> 1:9.0.1+ds-1 qemu-system-data 1:8.2.5+ds-2 -> 1:9.0.1+ds-1 qemu-system-misc 1:8.2.5+ds-2 -> 1:9.0.1+ds-1 I unfortunately had to look into this because this FTBFS triggers the testing autoremover for some of my packages (pico-sdk & picotool). mjt, how would you track this down? Maybe pick one of the failing tests and use it to bisect QEMU upstream between 8.2.5 and 9.0.1? Do you have a recipe to "quickly" bisect QEMU for these situations? Keith, how can I run just a single test of the picolibc testsuite? Can I increase its verbosity? I'd also be very happy if you could take this from here because my laptop is very weak and I ssh into a different machine to diagnose this. Despite its name, picolibc compiles for many hours on my laptop without an end in sight (so many tens of thousands of files o0). I don't even think about compiling another large package like QEMU multiple times. :D Thanks! cheers, josch signature.asc Description: signature
Bug#1079292: libgtk-3-0t64: segfault in gdk_window_get_toplevel() crashes waybar when clicking any tray icon
Contorl: forwarded -1 https://gitlab.gnome.org/GNOME/gtk/-/issues/6958 Quoting Jeremy Bícha (2024-08-23 14:07:35) > On Fri, Aug 23, 2024 at 3:30 AM Johannes Schauer Marin Rodrigues > wrote: > > I now built four libgtk-3-0t64 packages. Each of them identical to what is > > currently in unstable except, each of them has one of above four packages > > *not* > > applied. I tried this in a vanilla Debian unstable system booted from > > SD-card > > on my arm64 laptop and the only package where the bug did *not* surface was > > the > > package that I built without > > wayland-Add-support-for-v2-of-xdg_foreign-protocol.patch > > Thank you! Are you able to do one more thing and report this issue upstream? > > https://gitlab.gnome.org/GNOME/gtk/-/issues Done. signature.asc Description: signature
Bug#1079292: libgtk-3-0t64: segfault in gdk_window_get_toplevel() crashes waybar when clicking any tray icon
Hi, Quoting Johannes Schauer Marin Rodrigues (2024-08-22 18:43:31) > Quoting Jeremy Bícha (2024-08-22 18:15:16) > > On Thu, Aug 22, 2024 at 11:59 AM Johannes Schauer Marin Rodrigues > > wrote: > > > Quoting Jeremy Bícha (2024-08-22 17:49:40) > > > > On Thu, Aug 22, 2024 at 11:45 AM Johannes Schauer Marin Rodrigues > > > > wrote: > > > > > Rebuilding src:gtk+3.0 with this patch fixes the issue: > > > > > > > > Thank you. I agree with bumping the severity. Do you have time to > > > > bisect and figure out which specific patch is broken? This would be > > > > very helpful upstream so that the problematic commit does not make it > > > > into the next stable gtk3 release. > > > > > > I do not have a lot of time. Maybe we can share the work? If you have a > > > hunch > > > which of the commits could be the likely culprit, I'll test out just > > > dropping > > > that one. Bisecting six commits needs 3 tries anyways. :) > > > > These 4 all do things with windows: > > > > wayland-Add-support-for-v2-of-xdg_foreign-protocol.patch > > Ensure-the-staging_cairo_surface-is-destroyed-before-re-a.patch > > a11y-Use-non-empty-message-dialog-title-as-a11y-name.patch > > immulticontext-Don-t-have-a-global_context_id.patch > > thank you, that helps! I now built four libgtk-3-0t64 packages. Each of them identical to what is currently in unstable except, each of them has one of above four packages *not* applied. I tried this in a vanilla Debian unstable system booted from SD-card on my arm64 laptop and the only package where the bug did *not* surface was the package that I built without wayland-Add-support-for-v2-of-xdg_foreign-protocol.patch I hope that helps! cheers, josch signature.asc Description: signature
Bug#1079292: libgtk-3-0t64: segfault in gdk_window_get_toplevel() crashes waybar when clicking any tray icon
hi, Quoting Jeremy Bícha (2024-08-22 18:15:16) > On Thu, Aug 22, 2024 at 11:59 AM Johannes Schauer Marin Rodrigues > wrote: > > Quoting Jeremy Bícha (2024-08-22 17:49:40) > > > On Thu, Aug 22, 2024 at 11:45 AM Johannes Schauer Marin Rodrigues > > > wrote: > > > > Rebuilding src:gtk+3.0 with this patch fixes the issue: > > > > > > Thank you. I agree with bumping the severity. Do you have time to > > > bisect and figure out which specific patch is broken? This would be > > > very helpful upstream so that the problematic commit does not make it > > > into the next stable gtk3 release. > > > > I do not have a lot of time. Maybe we can share the work? If you have a > > hunch > > which of the commits could be the likely culprit, I'll test out just > > dropping > > that one. Bisecting six commits needs 3 tries anyways. :) > > These 4 all do things with windows: > > wayland-Add-support-for-v2-of-xdg_foreign-protocol.patch > Ensure-the-staging_cairo_surface-is-destroyed-before-re-a.patch > a11y-Use-non-empty-message-dialog-title-as-a11y-name.patch > immulticontext-Don-t-have-a-global_context_id.patch thank you, that helps! > If you use sbuild, you can add --profiles=noudeb,nocheck to speed up the > build for this case. Thankhs, I'll add those. The build is not the problem but testing it is. I do run Debian bookworm, so to test this, I'm using an SD-Card with Debian unstable on it that I flash every time... XD signature.asc Description: signature
Bug#1079292: libgtk-3-0t64: segfault in gdk_window_get_toplevel() crashes waybar when clicking any tray icon
Quoting Jeremy Bícha (2024-08-22 17:49:40) > On Thu, Aug 22, 2024 at 11:45 AM Johannes Schauer Marin Rodrigues > wrote: > > Rebuilding src:gtk+3.0 with this patch fixes the issue: > > Thank you. I agree with bumping the severity. Do you have time to > bisect and figure out which specific patch is broken? This would be > very helpful upstream so that the problematic commit does not make it > into the next stable gtk3 release. I do not have a lot of time. Maybe we can share the work? If you have a hunch which of the commits could be the likely culprit, I'll test out just dropping that one. Bisecting six commits needs 3 tries anyways. :) signature.asc Description: signature
Bug#1079022: kmod: symbol lookup error: /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, version LIBKMOD_5
Hi Marco, Quoting Marco d'Itri (2024-08-19 23:48:24) > The quick and easy solution would be to rebuild dracut-install, but the > release team refused to binNMU it (#1079038). > > The stupid solution would be to revert the change, and I will not do it > because I do not want to diverge from upstream. > > The elegant solution would be to keep for a while both symbols in the > library, but I am not good enough with ld(1) and could not actually > manage to do it myself. > > The nuclear solution would be to make a new upload with "Breaks: > dracut-install (<= 103-1)", which at least would make libkmod2 not > installable until somebody will be forced to do a new sourceful upload > of dracut-install. > > So I will wait for a while to see if anybody can help with #3, and if not > then I will proceed with #4. given that this issue can render our user's systems unbootable, could we have a quick-and-dirty solution now rather than the proper solution in a few days? You could upload kmod with an ugly version like 33+20240816-2~really32+20240611-1 and the contents of the last-working version of kmod and then take all the time you need to implement the correct solution. Thanks! cheers, josch signature.asc Description: signature
Bug#1079022: kmod: symbol lookup error: /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, version LIBKMOD_5
Hi, On Mon, 19 Aug 2024 14:13:39 -0400 =?utf-8?Q?Antoine_Beaupr=C3=A9?= wrote: > So bizarrely, I installed an image from snapshot: > > https://snapshot.debian.org/archive/debian/20240813 > > and *that* worked. So maybe `testing` doesn't work as an install target > for that build script. Anyway. > > So I confirm that kmod 32+20240611-1 doesn't have that issue, perhaps we > should just upload that back to unstable until we figure out a fix? :) we are building bootable system images for the MNT Reform open hardware laptop. Since this is breaking our images and since this bug is still open, let me also confirm here as well that using these two packages from snapshot.d.o prevents the issue from happening: wget http://snapshot.debian.org/archive/debian/20240612T203258Z/pool/main/k/kmod/libkmod2_32%2B20240611-1_arm64.deb wget http://snapshot.debian.org/archive/debian/20240612T203258Z/pool/main/k/kmod/kmod_32%2B20240611-1_arm64.deb Maybe this information (downgrading to the packages above) helps somebody who is affected by this to make their system bootable again. Thanks! cheers, josch signature.asc Description: signature
Bug#1071861: plakativ: prepare for next python3-fitz version
Quoting Bastian Germann (2024-06-26 19:36:05) > Control: retitle -1 plakativ: autopkgtest fails with python3-fitz 1.24.x > Control: severity -1 serious > > Now the pymupdf version has been updated. Thank you! Unfortunately, with the changes and the new version I now get a segmentation fault in the tests: https://ci.debian.net/packages/p/plakativ/testing/amd64/48338176/ I didn't look into this yet. signature.asc Description: signature
Bug#1074111: [arm64] boot stops at 'Starting kernel ...' without any further output when kernel built with recent binutils
Source: linux Version: 6.9.2-1~exp1 Severity: serious Hi, to reproduce this locally, on arm64, run the following: $ debvm-create -- --include=linux-image-generic/experimental "deb http://deb.debian.org/debian unstable main" "deb http://deb.debian.org/debian experimental main" $ debvm-run The debvm-run output will stop at the point where it starts qemu and then print nothing. It works fine with kernel 6.8 in unstable. Now comes my naive attempt to figure out what triggered this regression. Please bear in mind that I'm far from an expert on this topic. We observed this problem when we built the linux kernel for the MNT Reform which is the Debian linux kernel plus some additional patches. Compiling the same kernel version 6.8.12 in *unstable* within a more recent build environment results in a vmlinuz that just prints on boot: Starting kernel ... And then nothing else. Since neither the linux sources in debian unstable changed, nor our patch stack changed between these rebuilds, the culprit is likely in the build environment. Kernel 6.9 from experimental exhibits the same problems. We also observed that copying the vmlinuz from an earlier build in the good chroot environment made the system boot fine again. We also observed how the good vmlinuz has a size of 31M and the bad vmlinuz a size of only 26M. This is with the same sources, just different build chroot environment. An old-enough build environment can be constructed using snapshot.d.o. One of the differences in the build environment between good and bad builds is binutils-arm-linux-gnueabihf with version 2.42-4 in the good environment and version 2.42.50.20240618-1 in the bad environment. To test whether this indeed triggers the problem, we tested building our kernel with current unstable but with binutils (= 2.42-4) and gcc-13 (= 13.2.0-25). We also have to choose an older gcc from snapshot.d.o because recent gcc-13 requires recent binutils. This makes the kernel work again. So, given that the problem affects linux in unstable *if* built with a more recent build environment, the problem might not be in src:linux but elsewhere (maybe binutils or gcc-13). I'm still filing it here as I lack the skills to investigate this problem further. Since the issue shows up with qemu, I'm sure that you can get to the bottom of it and can re-assign this bug to the package to which it belongs. Gratitude is due to Chris Hofstaedtler who convinced me that maybe this is a problem even with vanilla Debian kernel and not only with the Debian kernel with our patches on top. Thanks! cheers, josch
Bug#1073259: libyojson-ocaml-dev should depend on yojson-tools
Hi, Quoting julien.pu...@gmail.com (2024-06-16 18:37:55) > Sorry I was away for most of the weekend, but yes, I didn't test my > last change correctly and broke things. no problem. I think the breakage was minor. > I just fixed elpi. Thank you! > I'll also take care of coq-serapi. This package is a problem - I wonder > if I shouldn't have waited some more before packaging it: upstream is > moving things around in different packages like crazy, so it's bound to > break too often for my taste and my attention span. Maybe just file an RC bug against the package. That will prevent it from transitioning to testing. It's probably smart to only let it transition once it is ready for a stable release. > > In summary: I do not think that a Depends from the dev package on the > > tools package is needed. Adrian, do you agree? > Not needed! Thank you! Then I guess you can close this bug. cheers, josch signature.asc Description: signature
Bug#1073259: libyojson-ocaml-dev should depend on yojson-tools
Hi, Quoting Johannes Schauer Marin Rodrigues (2024-06-15 14:03:34) > So the reason for why there is no a tools package is, that I argued that it > would be nice if the tools found in /usr/bin would not be part of the -dev > package but in its own package to decrease the number of dependencies. > > If the -dev package starts depending on the tools package, this advantage > would > be lost. > > How about doing a rebuild of the reverse dependencies of yojson and see what > breaks? My gut feeling is, that botch is the only one affected by this. > > Julien, do you want to take care of that rebuild or should I? I found the following reverse dependencies: belenios botch camlp5 camlp5-buildscripts coq-serapi eliom elpi frama-c haxe hol-light js-of-ocaml js-of-ocaml-ocamlbuild lablgtk3 lambda-term ledit liquidsoap morbig morsmall nss-passwords nurpawiki ocaml-atd ocaml-base64 ocaml-bos ocaml-ca-certs ocaml-cohttp ocaml-conduit ocaml-logs ocaml-merlin ocaml-mirage-crypto ocaml-mtime ocaml-pbkdf ocaml-ptime ocaml-x509 ocplib-simplex ocsigenserver ocsipersist orpie ppx-deriving-yojson utop wyrd zeroinstall-injector I built them all using sbuild in unstable and found the following to fail: botch: #1073199 coq-serapi: 1073269 elpi: #1073275 Gianfranco just NMU-ed botch, so #1073199 should be taken care of. Julien maintains elpi, so they probably can figure out how to fix this. The build log of coq-serapi might indicate that something in the last yojson upload (which included an upstream version bump) broke it. Can you investigate? In summary: I do not think that a Depends from the dev package on the tools package is needed. Adrian, do you agree? Thanks! cheers, josch signature.asc Description: signature
Bug#1073275: FTBFS in unstable due to make test
Source: elpi Version: 1.18.2-2 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) Hi, during running of the tests, the package build fails, specifically: KO trace-browser-elab (trace elaboration) elpi-trace-elaborator KO trace-browser-elab-broken1 (recoverable broken trace elaboration) elpi-trace-elaborator KO trace-browser-elab-chr (trace elaboration) elpi-trace-elaborator KO trace-browser-elab-cut (trace elaboration) elpi-trace-elaborator KO trace-browser-elab-findall (trace elaboration) elpi-trace-elaborator KO trace-browser-w-elab (trace elaboration)elpi-trace-elaborator KO trace-browser2-elab (trace elaboration) elpi-trace-elaborator KO trace-browser3-elab (trace elaboration) elpi-trace-elaborator KO trace-browser4-elab (trace elaboration) elpi-trace-elaborator Full log attached. Thanks! cheers, josch sbuild (Debian sbuild) 0.85.0 (04 January 2023) on salat +==+ | elpi (amd64) Sat, 15 Jun 2024 12:30:49 + | +==+ Package: elpi Distribution: unstable Machine Architecture: amd64 Host Architecture: amd64 Build Architecture: amd64 Build Type: binary Unpacking /home/josch/.cache/sbuild/unstable-amd64.tar to /tmp/tmp.sbuild.u1sSqKPNOc... I: NOTICE: Log filtering will replace 'sbuild-unshare-dummy-location' with '<>' I: NOTICE: Log filtering will replace 'build/elpi-AxtKGU/resolver-wQbB4N' with '<>' +--+ | Update chroot| +--+ Get:1 http://deb.debian.org/debian unstable InRelease [198 kB] Get:2 http://deb.debian.org/debian unstable/main amd64 Packages [9934 kB] Fetched 10.1 MB in 1s (9855 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. +--+ | Fetch source files | +--+ Check APT - There are no deb-src lines in your sources.list Automatically adding to EXTRA_REPOSITORIES: deb-src http://deb.debian.org/debian/ sid main +--+ | Update chroot| +--+ Hit:1 http://deb.debian.org/debian unstable InRelease Get:2 http://deb.debian.org/debian sid InRelease [198 kB] Get:3 http://deb.debian.org/debian sid/main Sources [10.6 MB] Fetched 10.8 MB in 1s (8909 kB/s) Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Checking available source versions... Download source files with APT -- Reading package lists... NOTICE: 'elpi' packaging is maintained in the 'Git' version control system at: https://salsa.debian.org/ocaml-team/elpi.git Please use: git clone https://salsa.debian.org/ocaml-team/elpi.git to retrieve the latest (possibly unreleased) updates to the package. Need to get 2637 kB of source archives. Get:1 http://deb.debian.org/debian sid/main elpi 1.18.2-2 (dsc) [2310 B] Get:2 http://deb.debian.org/debian sid/main elpi 1.18.2-2 (tar) [2630 kB] Get:3 http://deb.debian.org/debian sid/main elpi 1.18.2-2 (diff) [4560 B] Fetched 2637 kB in 0s (44.2 MB/s) Download complete and in download only mode I: NOTICE: Log filtering will replace 'build/elpi-AxtKGU/elpi-1.18.2' with '<>' I: NOTICE: Log filtering will replace 'build/elpi-AxtKGU' with '<>' +--+ | Install package build dependencies | +--+ Setup apt archive - Merged Build-Depends: atdts (>= 2.9.1), camlp5 (>= 8.00.02), debhelper-compat (= 13), dh-ocaml (>= 1.2), gnuplot-nox, libansi-terminal-ocaml-dev, libatdgen-ocaml-dev (>= 2.9.1), libcmdliner-ocaml-dev, libmenhir-ocaml-dev, libppx-deriving-ocaml-dev, libppxlib-ocaml-dev, libre-ocaml-dev, lua5.1, menhir, ocaml-dune, time, build-essential, fakeroot Filtered Build-Depends: atdts (>= 2.9.1), camlp5 (>= 8.00.02), debhelper-compat (= 13), dh-ocaml (>= 1.2), gnuplot-nox, libansi-terminal-ocaml-dev, libatdgen-ocaml-dev (>= 2
Bug#1073269: FTBFS in unstable with Error: Unbound type constructor Result.result
Source: coq-serapi
Version: 8.19.0+0.19.3-2
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
Hi,
coq-serapi FTBFS in unstable with the following error:
/usr/bin/make build
make[2]: Entering directory '/<>'
dune build --root . --only-packages=coq-serapi @install
File "serlib/ser_constrexpr.mli", line 106, characters 85-98:
106 | val with_declaration_ast_of_yojson : Yojson.Safe.t ->
(with_declaration_ast, string) Result.result
^
Error: Unbound type constructor Result.result
File "serlib/ser_feedback.mli", line 25, characters 57-70:
25 | val doc_id_of_yojson : Yojson.Safe.t -> (doc_id, string) Result.result
^
Error: Unbound type constructor Result.result
File "serlib/ser_goptions.mli", line 31, characters 69-82:
31 | val option_value_of_yojson : Yojson.Safe.t -> (option_value, string)
Result.result
^
Error: Unbound type constructor Result.result
File "serlib/ser_genredexpr.mli", line 30, characters 61-74:
30 | val glob_red_flag_of_yojson : (Yojson.Safe.t -> ('a, string)
Result.result) -> Yojson.Safe.t -> ('a glob_red_flag,
string) Result.result
^
Error: Unbound type constructor Result.result
File "serlib/ser_glob_term.mli", line 34, characters 63-76:
34 | val glob_sort_of_yojson : Yojson.Safe.t -> (glob_sort, string)
Result.result
^
Error: Unbound type constructor Result.result
File "serlib/ser_pp.mli", line 26, characters 45-58:
26 | val of_yojson : Yojson.Safe.t -> (t, string) Result.result
^
Error: Unbound type constructor Result.result
File "serlib/ser_xml_datatype.mli", line 25, characters 52-65:
25 | val gxml_of_yojson : (Yojson.Safe.t -> ('a, string) Result.result) ->
Yojson.Safe.t -> ('a gxml, string) Result.re
sult
^
Error: Unbound type constructor Result.result
File "serlib/ser_dAst.ml", line 34, characters 62-75:
34 | let thunk_of_yojson : type a b. (Yojson.Safe.t -> (a, string)
Result.result) -> (Yojson.Safe.t -> (b, string) Resu
lt.result) -> Yojson.Safe.t -> ((a,b) thunk, string) Result.result =
^
Error: Unbound type constructor Result.result
Full build log attached.
Thanks!
cheers, josch
sbuild (Debian sbuild) 0.85.0 (04 January 2023) on salat
+==+
| coq-serapi (amd64) Sat, 15 Jun 2024 12:28:25 + |
+==+
Package: coq-serapi
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: binary
Unpacking /home/josch/.cache/sbuild/unstable-amd64.tar to
/tmp/tmp.sbuild.K1Xrqr4TDO...
I: NOTICE: Log filtering will replace 'sbuild-unshare-dummy-location' with
'<>'
I: NOTICE: Log filtering will replace 'build/coq-serapi-MOPvT6/resolver-iw1YuS'
with '<>'
+--+
| Update chroot|
+--+
Get:1 http://deb.debian.org/debian unstable InRelease [198 kB]
Get:2 http://deb.debian.org/debian unstable/main amd64 Packages [9934 kB]
Fetched 10.1 MB in 1s (9112 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
+--+
| Fetch source files |
+--+
Check APT
-
There are no deb-src lines in your sources.list
Automatically adding to EXTRA_REPOSITORIES: deb-src
http://deb.debian.org/debian/ sid main
+--+
| Update chroot|
+--+
Hit:1 http://deb.debian.org/debian unstable InRelease
Get:2 http://deb.debian.org/debian sid InRelease [198 kB]
Get:3 http://deb.debian.org/debian sid/main Sources [10.6 MB]
Fetched 10.8 MB in 1s (8562 kB/s)
Reading package lists...
Reading package lists...
Building dependency tree...
Read
Bug#1073259: libyojson-ocaml-dev should depend on yojson-tools
Quoting Johannes Schauer Marin Rodrigues (2024-06-15 13:49:49) > Control: merge -1 1073199 Sorry, I mixed this up (and luckily the bts stopped me from merging). So the reason for why there is no a tools package is, that I argued that it would be nice if the tools found in /usr/bin would not be part of the -dev package but in its own package to decrease the number of dependencies. If the -dev package starts depending on the tools package, this advantage would be lost. How about doing a rebuild of the reverse dependencies of yojson and see what breaks? My gut feeling is, that botch is the only one affected by this. Julien, do you want to take care of that rebuild or should I? Thanks! cheers, josch signature.asc Description: signature
Bug#1073259: libyojson-ocaml-dev should depend on yojson-tools
Control: merge -1 1073199 Hi, Quoting Adrian Bunk (2024-06-15 12:58:19) > Package: libyojson-ocaml-dev > Version: 2.2.1-1 > Severity: serious > Tags: ftbfs > Control: affects -1 src:botch > > https://buildd.debian.org/status/fetch.php?pkg=botch&arch=ppc64el&ver=0.24-3%2Bb1&stamp=1718448612&raw=0 > > ... > + ydump > ./tools/native.sh: 512: ydump: not found > ... > > > Packages (build) depending on libyojson-ocaml-dev and users upgrading > to trixie might see breakage when depending on or installing > libyojson-ocaml-dev no longer provides the ydump tool. > > There is likely no good reason against libyojson-ocaml-dev depending > on yojson-tools. This is a duplicate of 1073199. As I've already told Gianfranco in the other bug, I'm on a short vacation. Feel free to NMU. Julien, as you have introduced this situation, the offer to NMU botch for me also goes to you. I'll likely only be able to take care of this on Tuesday or later. Thanks! cheers, josch signature.asc Description: signature
Bug#1073199: botch: please update from libyojson-ocaml-dev to new yojson-tools package
Hi, I'm on vacation right now with very limited internet. If you like, please feel free to NMU. Thanks! cheers, josch Quoting Gianfranco Costamagna (2024-06-14 14:36:58) > Hello, we should also add it to build-depends: > > --- botch-0.24/debian/control 2024-06-14 14:01:13.0 +0200 > +++ botch-0.24/debian/control 2024-06-14 14:35:36.0 +0200 > @@ -36,6 +36,7 @@ >libgraph-easy-perl , >graphviz, >black , > + yojson-tools, > Build-Depends-Indep: >discount , >graphviz , > > G. > > On Fri, 14 Jun 2024 14:06:43 +0200 Gianfranco Costamagna > wrote: > > Package: botch > > Version: 0.24-3 > > Severity: serious > > Tags: patch > > > > > > Hello, new yojson 2.2.1-1 created a new yojson-tools package, making this > > package fail > > it's own autopkgtests due to missing tools (ydump) > > > > I think the best way to move forward is to update the dependency of your > > package > > > >* Depend on yojson-tools instead of old libyojson-ocaml-dev > > to fix missing ydump tool (split from libyojson-ocaml-dev) > > This fixes autopkgtests > > > > > > Thanks for considering the patch. > > > > --- botch-0.24/debian/control 2024-06-10 12:40:37.0 +0200 > > +++ botch-0.24/debian/control 2024-06-14 14:01:13.0 +0200 > > @@ -60,7 +60,7 @@ > >python3-pygraphviz (>= 1.4~rc1), > >zutils, > >dpkg-dev, > > - libyojson-ocaml-dev, > > + yojson-tools, > > # libjs-jquery-tablesorter and libjs-jquery are needed to look at the > > generated > > # HTML with javascript bling > > Recommends: signature.asc Description: signature
Bug#1068119: Solution for 1068119 - compile error for s390-tools 2.16.0-2
Control: affects -1 + mmdebstrap
Hi,
On Mon, 27 May 2024 12:07:11 +0200 Steffen Eiden wrote:
> this issue is already fixed upstream since v2.22.0.
>
> Do one of:
> - apply the upstream fix [1,2]
> - update your package to at least v2.22.0
>
>
> The upstream fix disables the warning similar to the kernel[3] (see
> commit description) as there is no better solution for this as of now.
>
> I can ensure the code is correct and does no weird things (see lkml).
> There is also a s390-tools upstream discussion regarding this issue.[4]
>
>
> Steffen Eiden
> s390-tools upstream-maintainer
based on Steffen's input, I just did a 0-day NMU of s390-tools as this RC bug
is older than 7 days and there was no maintainer activity on the bug for 7 days
and there does not seem to be a packaging VCS where a fix could maybe be found
already.
I also had to cherry-pick another commit from upstream fixing another build
failure with OpenSSL 3.0, namely 8723dbce048add87ce10fe8c72eea75c4f828ef8
This package affects the /usr-move transition because due to this FTBFS, it is
not possible to rebuild s390-tools on unstable with new packages for the 64-bit
time_t transition and that in turn makes apt select the wrong packages in the
mmmdebstrap autopkgtest which we need to succeed to transition util-linux,
bash, dash, glibc and base-files to testing.
The debdiff is attached.
Thanks!
cheers, joschdiff -Nru s390-tools-2.16.0/debian/changelog s390-tools-2.16.0/debian/changelog
--- s390-tools-2.16.0/debian/changelog 2021-08-18 09:26:50.0 +0200
+++ s390-tools-2.16.0/debian/changelog 2024-06-11 11:15:24.0 +0200
@@ -1,3 +1,12 @@
+s390-tools (2.16.0-2.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Add patches from upstream to fix FTBFS (closes: #1068119)
+ - 0001-genprotimg-boot-disable-Warray-bounds-for-now.patch
+ - 0001-genprotimg-add-OpenSSL-3.0-support.patch
+
+ -- Johannes Schauer Marin Rodrigues Tue, 11 Jun 2024 11:15:24 +0200
+
s390-tools (2.16.0-2) unstable; urgency=medium
* Add missing build-dependency on libglib2.0-dev. (Closes: #992249)
diff -Nru s390-tools-2.16.0/debian/patches/0001-genprotimg-add-OpenSSL-3.0-support.patch s390-tools-2.16.0/debian/patches/0001-genprotimg-add-OpenSSL-3.0-support.patch
--- s390-tools-2.16.0/debian/patches/0001-genprotimg-add-OpenSSL-3.0-support.patch 1970-01-01 01:00:00.0 +0100
+++ s390-tools-2.16.0/debian/patches/0001-genprotimg-add-OpenSSL-3.0-support.patch 2024-06-11 11:15:06.0 +0200
@@ -0,0 +1,151 @@
+From 8723dbce048add87ce10fe8c72eea75c4f828ef8 Mon Sep 17 00:00:00 2001
+From: Marc Hartmayer
+Date: Wed, 23 Jun 2021 13:16:25 +
+Subject: [PATCH] genprotimg: add OpenSSL 3.0 support
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Add OpenSSL 3.0 support while still supporting OpenSSL 1.1.0 and newer. For this
+set the OPENSSL_API_COMPAT user defined macro to OpenSSL 1.1.0 (see
+https://www.openssl.org/docs/manmaster/man7/OPENSSL_API_COMPAT.html) so we don't
+see any deprecation warnings when using OpenSSL 3.0. In addition, add an
+compatibility layer for OpenSSL since some OpenSSL API functions were constified
+with OpenSSL 3.0.
+
+Fixes: https://github.com/ibm-s390-linux/s390-tools/issues/112
+Reviewed-by: Patrick Steuer
+Signed-off-by: Marc Hartmayer
+Signed-off-by: Jan Höppner
+---
+ genprotimg/src/Makefile | 1 +
+ genprotimg/src/utils/crypto.c | 15 ++--
+ genprotimg/src/utils/openssl_compat.h | 33 +++
+ 4 files changed, 43 insertions(+), 7 deletions(-)
+ create mode 100644 genprotimg/src/utils/openssl_compat.h
+
+diff --git a/genprotimg/src/Makefile b/genprotimg/src/Makefile
+index a71bb1e..0e811d6 100644
+--- a/genprotimg/src/Makefile
b/genprotimg/src/Makefile
+@@ -29,6 +29,7 @@ $(bin_PROGRAM)_OBJS := $($(bin_PROGRAM)_SRCS:.c=.o)
+
+ ALL_CFLAGS += -std=gnu11 -DPKGDATADIR=$(PKGDATADIR) \
+ $(GLIB2_CFLAGS) $(LIBCRYPTO_CFLAGS) $(LIBCURL_CFLAGS) \
++ -DOPENSSL_API_COMPAT=0x1010L \
+ $(WARNINGS) \
+ $(NULL)
+ ALL_CPPFLAGS += $(INCLUDE_PARMS)
+diff --git a/genprotimg/src/utils/crypto.c b/genprotimg/src/utils/crypto.c
+index 2e4750b..087de37 100644
+--- a/genprotimg/src/utils/crypto.c
b/genprotimg/src/utils/crypto.c
+@@ -31,6 +31,7 @@
+
+ #include "buffer.h"
+ #include "curl.h"
++#include "openssl_compat.h"
+ #include "crypto.h"
+
+ #define DEFINE_GSLIST_MAP(t2, t1) \
+@@ -1438,7 +1439,7 @@ static const char *get_first_dp_url(DIST_POINT *dp)
+ return NULL;
+ }
+
+-static gboolean insert_crl(X509_NAME *name, X509_CRL *crl)
++static gboolean insert_crl(const X509_NAME *name, X509_CRL *crl)
+ {
+ g_autofree gchar *key = NULL;
+
+@@ -1453,7 +1454,7 @@ static gboolean insert_crl(X509_NAME *name, X509_CRL *crl)
+ }
+
+ /* Caller is responsible for free'ing */
+-static X509_CRL *lookup_c
Bug#1063645: Aw: Re: markdown: missing required debian/rules targets build-arch and/or build-indep
Quoting Bastian Germann (2024-06-10 09:30:20) > "Johannes Schauer Marin Rodrigues": > > Do you have recommendations? I just need a drop-in replacement for markdown > > into stdin, html on stdout. Nothing fancy. > I would suggest discount or python3-markdown. Brilliant! That tip was gold! All I did was this to fix the issue in my package: --- a/debian/control +++ b/debian/control @@ -37,7 +37,7 @@ Build-Depends-Arch: graphviz, black , Build-Depends-Indep: - markdown , + discount , graphviz , Vcs-Browser: https://salsa.debian.org/debian/botch Vcs-Git: https://salsa.debian.org/debian/botch.git Much easier than fixing d/rules of src:markdown. ;) signature.asc Description: signature
Bug#1063645: markdown: missing required debian/rules targets build-arch and/or build-indep
On Sat, 8 Jun 2024 19:10:28 +0200 Bastian Germann wrote: > If you think about fixing this to keep a reverse dependency in Debian: That's me. > Please consider porting the reverse dep to some other markdown implementation > that is still maintained. Do you have recommendations? I just need a drop-in replacement for markdown into stdin, html on stdout. Nothing fancy. signature.asc Description: signature
Bug#1072732: update-shells: duplicates entries when a package includes both aliased and canonical shells
Hi, On Sat, 8 Jun 2024 18:10:04 +0200 Helmut Grohne wrote: > On Fri, Jun 07, 2024 at 10:09:04AM +0200, Helmut Grohne wrote: > > My recent bash upload changes it's shells.d snippet to include both > > aliased and canonical shells, which is right in principle, but it causes > > update-shells to duplicate /usr/bin/bash in /etc/shells. While that's > > not breaking anything yet, it's also not nice and kudos to Johannes for > > spotting it. > > > > It also is easy to fix with the attached patch. Would you kindly apply > > it? > > I fear this aspect currently breaks mmdebstrap's autopkgtests, so this > is an rc bug somewhere. While it isn't technically rc for debianutils, I > hope that the simplest way forward is to just upload debianutils. If you > disagree with this assessment, we'll have to adapt mmdebstrap's > autopkgtests until this bug is fixed, which also works, but is kinda > meh. So I am tentatively raising it to rc severity for debianutils > hoping that you agree and let you downgrade in case you disagree. Thanks for > considering. please CC me on the decision, so that I know how I should upload the next version of mmdebstrap. :) Thanks! cheers, josch signature.asc Description: signature
Bug#1071031: ezurio-qcacld-2.0-dkms: several module build failures
Quoting Andreas Beckmann (2024-05-28 10:57:37) > On 28/05/2024 10.16, Johannes Schauer Marin Rodrigues wrote: > > But I wonder, the autopkgtest results now say (for example for arm64): > > > > 657s I: Summary: > > 657s I: PASS ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-arm64 > > 657s I: SKIP ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-cloud-arm64 > > 657s I: PASS ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-rt-arm64 > > > > As a result, the whole test is marked as "skipped" and not "successful", so > > I > > No. The neutral state comes from autopkgtest-pkg-dkms being > "superficial". As this only tests building the module but not its > functionality, this is only some kind of smoketest and thus has to be > marked "superficial". It is now possible to have "isolation-machine" > tests that could test module functionality (see e.g. dm-writeboost-dkms) > but not if this requires special hardware. Okay, thank you! > So there is probably no migration boost possible for most -dkms packages. But > at least we should be able to catch build failures on new kernels earlier. > (But that will need some work on britney as a new kernel upload does not yet > trigger all -dkms packages.) I don't know how the field "Testsuite: autopkgtest-pkg-dkms" gets implemented in practice, but when just using debian/tests/control, one can add this to let another package foo trigger the tests: Features: test-name=hint-testsuite-triggers Test-Command: false Depends: foo Restrictions: hint-testsuite-triggers This is for example done for the package debvm: https://sources.debian.org/src/debvm/0.3/debian/tests/control/#L15 Thanks! cheers, josch signature.asc Description: signature
Bug#1071031: ezurio-qcacld-2.0-dkms: several module build failures
Hi Andreas, I noticed that you are one of the dkms uploaders, so maybe you can answer a follow-up question? :) Quoting Johannes Schauer Marin Rodrigues (2024-05-27 23:45:08) > Quoting Andreas Beckmann (2024-05-27 18:52:58) > > On 27/05/2024 18.32, Johannes Schauer Marin Rodrigues wrote: > > > I'm inclined to just restrict the kernel to amd64, arm64 and riscv64 as > > > the > > > relevant hardware is unlikely (or rather impossible) to be found on other > > > architectures. Or do you think that this would be a bed "solution"? > > > > No objections. > > > > Either make the package Architecture: instead of all or try > > BUILD_EXCLUSIVE_ARCH="" in dkms.conf > > (directive exists, but I've never used it and AFAIK no other Debian > > package does use it; maybe needs kernel architectures instead of Debian > > architectures) > > or if you can anchor it on some CONFIG_* option > > BUILD_EXCLUSIVE_CONFIG="CONFIG_FOO !CONFIG_BAR" > > (it's an AND-ed list, no OR possible) > > > > You may need to add debian/tests/autopkgtest-pkg-dkms.conf with > > architecture = > > if the package is not arch:all as autodep8 may not (be able to) take the > > architecture list of the binary packages into account. > > the package is already using: > > BUILD_EXCLUSIVE_CONFIG="CONFIG_WIRELESS" > > which prevents building it for the cloud kernel, for example. I read a bit > into > the dkms.in sources and found that BUILD_EXCLUSIVE_ARCH is a bash regex, so I > set it up like tihs now: > > BUILD_EXCLUSIVE_ARCH="^(aarch64|x86_64|riscv64)$" > > The architectures seem to be what "uname -m" is printing. this seems to have done the trick: https://tracker.debian.org/pkg/ezurio-qcacld-2.0-dkms But I wonder, the autopkgtest results now say (for example for arm64): 657s I: Summary: 657s I: PASS ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-arm64 657s I: SKIP ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-cloud-arm64 657s I: PASS ezurio-qcacld-2.0/0.0~git20230623.2cd31b6 6.7.12-rt-arm64 As a result, the whole test is marked as "skipped" and not "successful", so I do not get the few days migration bonus. The module is not meant to be built for the cloud kernel, so can I somehow tell the dkms autopkgtest that so that it only tries to build it on the kernels where it makes sense and thus the whole test becomes "green" and not "yellow"? It's of course no big deal if there is no way. :) Thanks! cheers, josch signature.asc Description: signature
Bug#1071031: ezurio-qcacld-2.0-dkms: several module build failures
Hi, Quoting Andreas Beckmann (2024-05-27 18:52:58) > On 27/05/2024 18.32, Johannes Schauer Marin Rodrigues wrote: > > I'm inclined to just restrict the kernel to amd64, arm64 and riscv64 as the > > relevant hardware is unlikely (or rather impossible) to be found on other > > architectures. Or do you think that this would be a bed "solution"? > > No objections. > > Either make the package Architecture: instead of all or try > BUILD_EXCLUSIVE_ARCH="" in dkms.conf > (directive exists, but I've never used it and AFAIK no other Debian > package does use it; maybe needs kernel architectures instead of Debian > architectures) > or if you can anchor it on some CONFIG_* option > BUILD_EXCLUSIVE_CONFIG="CONFIG_FOO !CONFIG_BAR" > (it's an AND-ed list, no OR possible) > > You may need to add debian/tests/autopkgtest-pkg-dkms.conf with > architecture = > if the package is not arch:all as autodep8 may not (be able to) take the > architecture list of the binary packages into account. the package is already using: BUILD_EXCLUSIVE_CONFIG="CONFIG_WIRELESS" which prevents building it for the cloud kernel, for example. I read a bit into the dkms.in sources and found that BUILD_EXCLUSIVE_ARCH is a bash regex, so I set it up like tihs now: BUILD_EXCLUSIVE_ARCH="^(aarch64|x86_64|riscv64)$" The architectures seem to be what "uname -m" is printing. Thanks! cheers, josch signature.asc Description: signature
Bug#1071031: ezurio-qcacld-2.0-dkms: several module build failures
Hi Andreas, On Mon, 13 May 2024 10:32:23 +0200 Andreas Beckmann wrote: > The module fails to build for several architectures and kernel versions: > > Linux 6.6.*: > https://ci.debian.net/packages/e/ezurio-qcacld-2.0-dkms/testing/amd64/45828215/#L3674 > 243s > /var/lib/dkms/ezurio-qcacld-2.0/0.0~git20230623.2cd31b6/build/CORE/HDD/src/wlan_hdd_cfg80211.c: > In function ‘__wlan_hdd_cfg80211_change_beacon’: > 243s > /var/lib/dkms/ezurio-qcacld-2.0/0.0~git20230623.2cd31b6/build/CORE/HDD/src/wlan_hdd_cfg80211.c:19956:48: > error: invalid use of undefined type ‘struct cfg80211_ap_update’ > > struct cfg80211_ap_update was introduced in Linux 6.7, so I'd recommend > to add > > # struct cfg80211_ap_update was added in "wifi: cfg80211: split struct > # cfg80211_ap_settings" bb55441c57ccc5cc2eab44e1a97698b9d708871d > (v6.7-rc1) > BUILD_EXCLUSIVE_KERNEL_MIN="6.7" > > to dkms.conf. thank you, this seems sensible! > > i386, Linux 6.7.*: > ERROR: modpost: "__udivdi3" > [/var/lib/dkms/ezurio-qcacld-2.0/0.0~git20230623.2cd31b6/build/wlan.ko] > undefined! > > This probably affects more 32-bit platforms. > > IIRC __udivdi3 is a compiler generated function call for > (long long) a / (long long) b > for architectures that don't have native support for long long > arithmetic. This symbol is part of libgcc_s, but that cannot be linked > into the kernel for obvious reasons. > I do not know the solution for this case, but this is something affecting > more out-of-tree kernel modules. I'm inclined to just restrict the kernel to amd64, arm64 and riscv64 as the relevant hardware is unlikely (or rather impossible) to be found on other architectures. Or do you think that this would be a bed "solution"? Thanks! cheers, josch signature.asc Description: signature
Bug#1070020: autopkgtest: (unrelated) packages not found
Hi, Quoting Johannes Schauer Marin Rodrigues (2024-04-28 19:34:07) > unfortunately, this problem is not transient but reproducible. The problem > is, that the involved libraries which are 404 have alternative 64bit time_t > versions in unstable: > > libssl3 -> libssl3t64 > libdb5.3 -> libdb5.3t64 > libgdbm6 -> libgdbm6t64 > libgdbm-compat4 -> libgdbm-compat4t64 > > And apt chooses to satisfy the (virtual) dependencies on those differently, > depending on the surrounding dependency satisfaction problem. Related, > debootstrap is also broken by the virtual providers of libssl3: #1069787 > > Feel free to tell the release team to ignore these failures if necessary. > They will go away once the 64bit time_t transition is finished. do you agree that there is nothing for mmdebstrap to do here? If yes, could you close this bug? Thanks! cheers, josch signature.asc Description: signature
Bug#1070020: autopkgtest: (unrelated) packages not found
Hi, Quoting Chris Hofstaedtler (2024-04-28 18:30:56) > the autopkgtests for mmdebstrap as part of migration tests for testing/amd64 > fail with apt reporting 'Not found' errors. > > As an example, for this scenario: > mmdebstrap 1.4.3-6 > util-linux/2.40-8 gdm3/46.0-2 sssd/2 > src:util-linux from unstable > src:gdm3 from unstable > src:sssd from unstable > https://ci.debian.net/packages/m/mmdebstrap/testing/amd64/46033215/ > > 1085s Err:22 http://127.0.0.1/debian unstable/main amd64 libssl3 amd64 3.1.5-1 > 1085s 404 File not found [IP: 127.0.0.1 80] > ... > 1085s Err:41 http://127.0.0.1/debian unstable/main amd64 libdb5.3 amd64 > 5.3.28+dfsg2-4+b1 > 1085s 404 File not found [IP: 127.0.0.1 80] > ... > 1085s Err:73 http://127.0.0.1/debian unstable/main amd64 libgdbm6 amd64 > 1.23-5+b1 > 1085s 404 File not found [IP: 127.0.0.1 80] > 1085s Err:74 http://127.0.0.1/debian unstable/main amd64 libgdbm-compat4 > amd64 1.23-5+b1 > 1085s 404 File not found [IP: 127.0.0.1 80] > > This looks like a pinning problem or some other issue. Given libssl3 is > a problem here, which is NOT a package considered for migration in this > test, I don't see how the test failure is actually related to the > involved packages. > If this is a transient situation, please detect it and exit with status 77. unfortunately, this problem is not transient but reproducible. The problem is, that the involved libraries which are 404 have alternative 64bit time_t versions in unstable: libssl3 -> libssl3t64 libdb5.3 -> libdb5.3t64 libgdbm6 -> libgdbm6t64 libgdbm-compat4 -> libgdbm-compat4t64 And apt chooses to satisfy the (virtual) dependencies on those differently, depending on the surrounding dependency satisfaction problem. Related, debootstrap is also broken by the virtual providers of libssl3: #1069787 Feel free to tell the release team to ignore these failures if necessary. They will go away once the 64bit time_t transition is finished. Thanks! cheers, josch signature.asc Description: signature
Bug#1069793: wrong package name mnt-reform-setup-wizard -- should be reform-setup-wizard
Package: reform-setup-wizard Version: 0.1.0-1 Severity: serious As it says in subject.
Bug#1064266: marked as pending in python-lsp-black
Control: tag -1 pending Hello, Bug #1064266 in python-lsp-black reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/python-lsp-black/-/commit/d2f03a48ce7912e0eecb9dd952c74a28ae2624bc temporarily disable test_load_config_defaults and test_load_config_with_skip_options Forwarded: https://github.com/python-lsp/python-lsp-black/issues/55 Closes: #1064266 (this message was generated automatically) -- Greetings https://bugs.debian.org/1064266
Bug#1064266: python-lsp-black: FTBFS with black 24.2.0-1
Source: python-lsp-black
Version: 2.0.0-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source
X-Debbugs-Cc: sylves...@debian.org
Hi,
python-lsp-black currently FTBFS in unstable. To track down the reason,
I ran debbisect:
DEBIAN_BISECT_SRCPKG=python-lsp-black debbisect --cache="$(pwd)/cache"
2024-01-01 today /usr/share/doc/devscripts/examples/debbisect_buildsrc.sh
[...]
#6: trying 20240214T085951Z...
test script output: good
snapshot timestamp difference: 3.758796296296296 days
computation time left: 0:37:59.675485
approximately 4 steps left to test
#7: trying 20240215T151223Z...
test script output: bad
bisection finished successfully
last good timestamp: 20240214T085951Z
first bad timestamp: 20240215T151223Z
only one package differs: black 24.1.1-1 -> 24.2.0-1
I haven't investigated the failure yet.
I have put Sylvestre, who uploaded black 24.2.0-1 a few days ago in
X-Debbugs-Cc.
Sylvestre, do you have an idea what the cause for this error could be? From the
failing build log:
= test session starts ==
platform linux -- Python 3.11.8, pytest-7.4.4, pluggy-1.4.0
rootdir: /<>
collected 21 items / 2 deselected / 19 selected
tests/test_plugin.py ..FF... [100%]
=== FAILURES ===
__ test_load_config_defaults ___
config = {'fast': False, 'line_length': 88, 'preview': False, 'pyi': False, ...}
def test_load_config_defaults(config):
config = load_config(str(fixtures_dir / "example.py"), config)
> assert config == {
"line_length": 88,
"target_version": set(),
"pyi": False,
"fast": False,
"skip_magic_trailing_comma": False,
"skip_string_normalization": False,
"preview": False,
}
E AssertionError: assert {'fast': Fals...': False, ...} == {'fast':
Fals...': False, ...}
E Omitting 6 identical items, use -vv to show
E Differing items:
E {'target_version': {, , , }} != {'target_version':
set()}
E Use -v to get more diff
It seems that the target_version member is now somehow empty?
Thanks!
cheers, josch
Bug#1063648: krb5: FTBFS on arm64, armel and ppc64el with "Can't resolve hostname" in dh_auto_test
Source: krb5 Version: 1.20.1-5+b1 Severity: serious Tags: ftbfs Hi, there as a binNMU "Rebuild to sync binNMU versions" for krb5 and that failed for arm64, armel and ppc64el: https://buildd.debian.org/status/package.php?p=krb5 The error logs look very similar: making check in lib/rpc... make[4]: Entering directory '/<>/build/lib/rpc' making check in lib/rpc/unit-test... make[5]: Entering directory '/<>/build/lib/rpc/unit-test' PYTHONPATH=../../../../src/util VALGRIND="" python3 ../../../../src/lib/rpc/unit-test/t_rpc.py *** Failure: ./client failed with code 1. *** Last command (#10): ./client -t arm-conova-03 58621 host@arm-conova-03 1026 *** Output of last command: Can't resolve hostname arm-conova-03 For details, see: /<>/build/lib/rpc/unit-test/testlog Or re-run this test script with the -v flag: cd /<>/build/lib/rpc/unit-test PYTHONPATH=/<>/src/util /usr/bin/python3 ../../../../src/lib/rpc/unit-test/t_rpc.py -v Use --debug=NUM to run a command under a debugger. Use --stop-after=NUM to stop after a daemon is started in order to attach to it with a debugger. Use --help to see other options. make[5]: *** [Makefile:644: check-pytests] Error 1 make[5]: Leaving directory '/<>/build/lib/rpc/unit-test' make[4]: *** [Makefile:1595: check-recurse] Error 1 make[4]: Leaving directory '/<>/build/lib/rpc' make[3]: *** [Makefile:973: check-recurse] Error 1 make[3]: Leaving directory '/<>/build/lib' make[2]: *** [Makefile:1521: check-recurse] Error 1 make[2]: Leaving directory '/<>/build' dh_auto_test: error: cd build && make -j1 check "TESTSUITEFLAGS=-j1 --verbose" VERBOSE=1 returned exit code 2 make[1]: *** [debian/rules:150: override_dh_auto_test] Error 25 make[1]: Leaving directory '/<>' make: *** [debian/rules:153: build-arch] Error 2 dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit status 2 Thanks! cheers, josch
Bug#1063501: building less from source fails the island test
Control: retitle -1 building less from source fails the island test On Fri, 09 Feb 2024 00:24:00 +0100 Johannes Schauer Marin Rodrigues wrote: > the current curl packaging The first sentence in my mail should've been > the current less packaging Apologies for the confusion! cheers, josch signature.asc Description: signature
Bug#1063501: building curl from source fails the island test
Source: less Version: 590-2 Severity: serious Tags: patch Hi, the current curl packaging uses pre-built artifacts from the upstream tarball without regenerating them. Attempting to regenerate them by running "make -f Makefile.aut" proceeds to call curl to download stuff from ftp://ftp.unicode.org. To fix this, I added a build dependency on unicode-data and symlinked the relevant files in the source tree to the files shipped by the unicode-data package. While I was at it, my patch also regenerates all the other files which were so far just copypasted from the upstream tarball without verifying whether they can really be built using Debian main. This is the patch: diff -Nru less-590/debian/control less-590/debian/control --- less-590/debian/control 2023-03-12 15:49:03.0 +0100 +++ less-590/debian/control 2024-02-08 23:12:54.0 +0100 @@ -4,7 +4,8 @@ Maintainer: Milan Kupcevic Build-Depends: debhelper (>= 12), - libncurses-dev + libncurses-dev, + unicode-data Standards-Version: 4.6.2 Vcs-Git: https://salsa.debian.org/debian/less.git Vcs-Browser: https://salsa.debian.org/debian/less diff -Nru less-590/debian/rules less-590/debian/rules --- less-590/debian/rules 2023-02-12 11:17:35.0 +0100 +++ less-590/debian/rules 2024-02-08 23:16:58.0 +0100 @@ -12,3 +12,20 @@ dh_auto_configure -- \ --with-regex=gnu \ --with-editor=/usr/bin/editor + +execute_before_dh_auto_build: + mkdir -p unicode + ln -s /usr/share/unicode/UnicodeData.txt unicode/UnicodeData.txt + ln -s /usr/share/unicode/EastAsianWidth.txt unicode/EastAsianWidth.txt + make -f Makefile.aut + +execute_before_dh_auto_clean: + set -e; for t in "" echo key; do mv "less$$t.nro" "less$$t.bak"; done + make -f Makefile.aut clean + rm -f *.nro *.man help.c funcs.h defines.h.in configure + rm -f unicode/UnicodeData.txt unicode/EastAsianWidth.txt + [ ! -d unicode ] || rmdir unicode + set -e; for t in "" echo key; do mv "less$$t.bak" "less$$t.nro"; touch "less$$t.nro.VER" "less$$t.nro"; done + +execute_before_dh_auto_install: + make -f Makefile.aut distfiles The stunt with preserving the *.nro files is necessary because the upstream tarball does not ship the *.nro.VER files which are then made into *.nro files by replacing @@VERSION@@ and @@DATE@@ with their respective values. Technically this is a case where the original source is missing from the Debian tarball but this replacement is probably trivial enough to not be a DFSG violation. The patch could be made much simpler if you were using a tarball from the upstream git instead of the distribution tarball which is missing sources but you probably have your reasons for doing it this way. Thanks! cheers, josch
Bug#1060961: clapper: FTBFS: make: *** [debian/rules:6: binary] Error 25
Hi, On Tue, 16 Jan 2024 20:43:11 +0100 Lucas Nussbaum wrote: > During a rebuild of all packages in sid, your package failed to build on > amd64. thank you for your bug! > Couldn't find include 'GObject-2.0.gir' (search path: '['/usr/share/gir-1.0', > '/usr/lib/x86_64-linux-gnu/gir-1.0', > '/<>/debian/.debhelper/generated/_source/home/.local/share/gir-1.0', > 'gir-1.0', '/usr/local/share/gir-1.0', '/usr/share/gir-1.0', > '/usr/lib/x86_64-linux-gnu/gir-1.0', '/usr/share/gir-1.0', > '/usr/share/gir-1.0']') I'm unable to reproduce your bug in unstable. The day before the date from your build log, a disruptive upload of gobject-introspection happened to unstable and there have been more uploads of gobject-introspection since then. Maybe the issue is fixed now? Would you mind re-trying the build? I am building the package on arm64 and maybe that makes a difference? In any case, I'm not able to reproduce it. Thanks! cheers, josch signature.asc Description: signature
Bug#1059869: autopkgtest fails
On 2024-01-11 23:40, Bastian Germann wrote: Ping. It is now 1 week until this will auto-remove several packages. Please consider releasing and packaging the new release. Whoops, sorry!! And thank you for the ping. This has now been taken care of. The version I just uploaded has the autopkgtest running fine on salsa so I guess this issue is indeed fixed. Thanks! cheers, josch
Bug#1056312: zlib1g makes tex-common fail to install due to fmtutil failing
Package: zlib1g Version: 1:1.3.dfsg-2 Severity: serious Hi, I didn't investigate this further yet but filing this as RC as it is easy to reproduce and it's easy to find out that only zlib1g changed using debbisect. Downgrading to zlib1g 1:1.2.13.dfsg-3 makes the problem go away. Steps to reproduce: $ mmdebstrap --include=tex-common,texlive-base unstable /dev/null Processing triggers for tex-common (6.18) ... Running updmap-sys. This may take some time... done. Running mktexlsr /var/lib/texmf ... done. Building format(s) --all. This may take some time... fmtutil failed. Output has been stored in /tmp/fmtutil.tcAsaQVq Please include this file if you report a bug. dpkg: error processing package tex-common (--configure): installed tex-common package post-installation script subprocess returned error exit status 1 Errors were encountered while processing: tex-common E: Sub-process env returned an error code (1)
Bug#1055916: uninstallable in unstable
Package: gedit Version: 44.2-1 Severity: serious Hi, currently, gedit cannot be installed in unstable with this error message from apt: Reading package lists... Building dependency tree... Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libtepl-common : Breaks: libtepl-6-2 but 6.4.0-7 is to be installed E: Unable to correct problems, you have held broken packages. Sebastian Ramacher suggested in #debian-mentors that I file a bug about that against gedit as tepl is involved in an uncoordinated transition that needs action from their respective maintainers. Relevant other bug: https://bugs.debian.org/1055778 Thanks! cheers, josch
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Quoting Alexandru Mihail (2023-09-21 12:30:52) > I have no problem with that, can you minimally review the tag and determine > if it's fit for release or if anything is missing (ignore the added patch, > that fixes a separate bug) ? > > This is still one of my first releases, I'm still getting the hang of > certain operations in salsa :) > > If everything is OK, let's proceed with the upload ! Looks good to me! I just uploaded. If this upload introduces any other problems, feel free to contact me to upload a fix. Thanks! cheers, josch signature.asc Description: signature
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Hi, Quoting Alexandru Mihail (2023-09-21 01:31:23) > Hello again,> okay, I'll wait. Thank you for your quick reply! > Thank you for the wait ! > I've committed the necessary systemd service fix into a new mini-httpd > release (1.30-5). Currently waiting for sponsored upload from my mentor. if you want a sponsor, I can also upload it for you. Thanks! cheers, josch signature.asc Description: signature
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Quoting Alexandru Mihail (2023-09-19 23:41:05) > > do you have an estimate when you think you can upload this? This bug has > > now blocked part of my work in Debian for two weeks and I'm unable to do > > another release for my package until this bug gets fixed. > I'm planning to release no later than Friday. okay, I'll wait. Thank you for your quick reply! signature.asc Description: signature
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Hi, Quoting Alexandru Mihail (2023-09-17 15:13:29) > This is great, I successfully tested your proposed service file changes and > everything appears to work great ! We're currently on > mini-httpd/unstable,now 1.30-4; The next release (1.30-5) will incorporate > your fix, closing this bug. do you have an estimate when you think you can upload this? This bug has now blocked part of my work in Debian for two weeks and I'm unable to do another release for my package until this bug gets fixed. If you are short on time I can also NMU mini-httpd with the changes to the service file I proposed in my last mail. Thanks! cheers, josch signature.asc Description: signature
Bug#1052139: dead upstream, popcon <10
Source: morty Severity: serious Hi, last upstream commit was in April 2021. This package was mainly useful together with searx (from the same developer) but that project got abandoned in favour of searxng by different people which does not need morty anymore. Additionally, morty has a very low popcon. Lets make sure that this package does not make it into the next stable release by accident. Thanks! cheers, josch
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Hi, Quoting Alexandru Mihail (2023-09-16 16:40:38) > > I asked in #debian-systemd and the fix could be as simple as setting the > > following in the .service file: > > > > EnvironmentFile=-/etc/default/mini-httpd > > > > Can you confirm? > I will test this and get back to you as soon as I can confirm the fix. > Documentation on /etc/default/mini-httpd options is rather scarce, do > you mind posting a minimal /etc/default/mini-httpd file with which I > could confirm the fix (a path or port setting perhaps)? It would speed > up my work here as the package does not provide a default one. here is my /etc/default/mini-httpd: START=1 DAEMON_OPTS="-h 127.0.0.1 -p 80 -u nobody -dd /mnt/cache -i /var/run/mini-httpd.pid -T UTF-8" I successfully tested the following patch to the .service file: @@ -5,7 +5,8 @@ [Service] Type=forking PIDFile=/run/mini_httpd.pid -ExecStart=/usr/sbin/mini_httpd -C /etc/mini-httpd.conf +EnvironmentFile=-/etc/default/mini-httpd +ExecStart=/usr/sbin/mini_httpd -C /etc/mini-httpd.conf $DAEMON_OPTS -i /run/mini_httpd.pid [Install] WantedBy=multi-user.target The EnvironmentFile uses "=-" to support a non-existant /etc/default/mini-httpd. The ExecStart line also adds a -i option to make sure that neither /etc/mini-httpd.conf nor $DAEMON_OPTS can set -i to something that is different from the path in PIDFile. What do you think? Thanks! cheers, josch signature.asc Description: signature
Bug#1051819: fluidsynth: Consider building with pipewire support
Hi Nicholas,
Quoting Nicholas D Steeves (2023-09-16 14:06:00)
> Oh my, yes, it seems I forgot to add the new pipewire -dev package to the
> fluidsynth -dev package. 'not sure how that happened, but my mistake! Isn't
> only waiting 48h a bit rushed for an NMU though?
the number of delayed days are documented here:
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#when-and-how-to-do-an-nmu
It seems that indeed a 0-day nmu was a bit too quick here.
> I can of course import your fix and upload in the next 48h, and I'd like to
> improve your changelog entry, because I think you'll agree that the concept
> of "runtime" doesn't make sense for headers ;)
It does make sense as we have two types of dependencies in Debian: build
dependencies and runtime dependencies. A header package is also a binary
package so it has runtime dependencies like all other binary packages do.
But indeed the term "runtime dependency" is not very widely used. I do not
think that Debian policy uses it. I think the term is mostly used by people
like me who work on dependency resolution software.
> If this is truly 0-day urgent, I'm confident a team member (IIRC Josch is a
> multimedia-team member) will upload.
I'm afraid it was already uploaded and is now in unstable. :(
> ('hope this isn't HTML email, since I'm currently AFK on a phone)
It was HTML but it also had a text/plain part. :)
Thanks!
cheers, josch
signature.asc
Description: signature
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Hi, Quoting Johannes Schauer Marin Rodrigues (2023-09-16 09:23:43) > On Thu, 07 Sep 2023 00:58:34 +0200 Johannes Schauer Marin Rodrigues > wrote: > > after an upgrade to mini-httpd 1.30-4 my setup stopped working. It seems > > that > > this new version changed the init script for a systemd unit where the latter > > ignores the contents of /etc/default/mini-httpd. > > > > If that is intentional and not an oversight, there should at least be a > > NEWS entry so that users upgrading to 1.30-4 learn about this breaking > > change and are also told how to convert their existing configuration to > > the new style. > > > > If possible it would of course be nice if the systemd service would not > > break > > user's setups and would continue to consume /etc/default/mini-httpd. > > this issue has now made the mmdebstrap jenkins job fail for 10 days in a row: > > https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/ > > Even if you do not have time to fix this soon, could you maybe advise on how > you plan to fix this? Is the behaviour change introduced by the last upload > supposed to stay and I should adjust my setup accordingly? Or will you restore > compatibility with existing setups using /etc/default/mini-httpd so that I > need to do nothing and just wait for an upload fixing this? I asked in #debian-systemd and the fix could be as simple as setting the following in the .service file: EnvironmentFile=-/etc/default/mini-httpd Can you confirm? Thanks! cheers, josch signature.asc Description: signature
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Hi Alexandru & Nicholas, On Thu, 07 Sep 2023 00:58:34 +0200 Johannes Schauer Marin Rodrigues wrote: > after an upgrade to mini-httpd 1.30-4 my setup stopped working. It seems that > this new version changed the init script for a systemd unit where the latter > ignores the contents of /etc/default/mini-httpd. > > If that is intentional and not an oversight, there should at least be a > NEWS entry so that users upgrading to 1.30-4 learn about this breaking > change and are also told how to convert their existing configuration to > the new style. > > If possible it would of course be nice if the systemd service would not break > user's setups and would continue to consume /etc/default/mini-httpd. this issue has now made the mmdebstrap jenkins job fail for 10 days in a row: https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/ Even if you do not have time to fix this soon, could you maybe advise on how you plan to fix this? Is the behaviour change introduced by the last upload supposed to stay and I should adjust my setup accordingly? Or will you restore compatibility with existing setups using /etc/default/mini-httpd so that I need to do nothing and just wait for an upload fixing this? Thanks! cheers, josch signature.asc Description: signature
Bug#1051819: fluidsynth: Consider building with pipewire support
Control: affects -1 + src:ardour src:blockattack src:calf src:chocolate-doom src:crispy-doom src:denemo src:fluidsynth-dssi src:freedink src:frotz src:gambas3 src:gargoyle-free src:gst-plugins-bad1.0 src:jag src:pianobooster src:planetblupi src:qsynth src:qtads src:scummvm src:toppler src:ufoai src:vlc Hi, On Thu, 14 Sep 2023 07:23:22 +0200 Gianfranco Costamagna wrote: > And also a -dev dependency on the library package, as shown by autopkgtests > now being regressed (and vlc build broken). ah you were faster than me! :D (i made the mistake of first trying to compile all its reverse dependencies for more evidence) This not only breaks vlc but also (at least) the source packages I listed in the "effects" bts control line above. I verified that those packages build again when libpipewire-0.3-dev is installed as is done by Gianfranco's patch. Thanks! cheers, josch signature.asc Description: signature
Bug#1051374: breaks existing setups using /etc/default/mini-httpd
Package: mini-httpd Version: 1.30-4 Severity: serious Hi, after an upgrade to mini-httpd 1.30-4 my setup stopped working. It seems that this new version changed the init script for a systemd unit where the latter ignores the contents of /etc/default/mini-httpd. If that is intentional and not an oversight, there should at least be a NEWS entry so that users upgrading to 1.30-4 learn about this breaking change and are also told how to convert their existing configuration to the new style. If possible it would of course be nice if the systemd service would not break user's setups and would continue to consume /etc/default/mini-httpd. Thanks! cheers, josch
Bug#1050755: usr-is-merged.postinst operates on outer directories with DPKG_ROOT
Package: usrmerge Version: 36 Severity: serious Tags: patch Hi, the recent changes to usr-is-merged.postinst broke DPKG_ROOT support: Setting up usr-is-merged (36) ... removed '/lib64' /tmp/mmdebstrap.P6Rv45i7Hi/var/lib/dpkg/info/usr-is-merged.postinst: 16: rmdir: not found dpkg: error processing package usr-is-merged (--configure): installed usr-is-merged package post-installation script subprocess returned error exit status 127 Errors were encountered while processing: usr-is-merged E: Sub-process /usr/bin/dpkg returned an error code (1) E: setup failed: E: command failed: /usr/share/mmdebstrap/hooks/merged-usr/essential00.sh I: main() received signal PIPE: waiting for setup... I: removing tempdir /tmp/mmdebstrap.P6Rv45i7Hi... Can't exec "rm": No such file or directory at /usr/bin/mmdebstrap line 6232. E: rm failed: -1 Since usr-is-merged.postinst fails to respect $DPKG_ROOT it will operate on the directory hierarchy outside the chroot and remove several rather important directories. I'm filing this with severity series because it breaks the mmdebstrap autopkgtest and should thus be prevented from transitioning to testing until fixed. The following patch fixes the problem: diff -Nru usrmerge-36/debian/usr-is-merged.postinst usrmerge-36+nmu1/debian/usr-is-merged.postinst --- usrmerge-36/debian/usr-is-merged.postinst 2023-08-27 13:33:27.0 +0200 +++ usrmerge-36+nmu1/debian/usr-is-merged.postinst 2023-08-29 01:14:03.0 +0200 @@ -9,11 +9,11 @@ # so clean up the unused (and unowned) ones local arch_directories="/lib64 /lib32 /libo32 /libx32" for dir in $arch_directories; do -[ -e "$dir" ] || continue +[ -e "$DPKG_ROOT$dir" ] || continue if ! dpkg-query -S $dir >/dev/null 2>&1; then - rm -v $dir - if [ -e /usr$dir ] && ! dpkg-query -S /usr$dir >/dev/null 2>&1 ; then -rmdir --ignore-fail-on-non-empty -v /usr$dir + rm -v "$DPKG_ROOT$dir" + if [ -e "$DPKG_ROOT/usr$dir" ] && ! dpkg-query -S /usr$dir >/dev/null 2>&1 ; then +rmdir --ignore-fail-on-non-empty -v "$DPKG_ROOT/usr$dir" fi fi done
Bug#1050752: breaks chrootless and mmdebstrap autopkgtest
Package: debianutils
Version: 5.9
Severity: serious
Tags: patch
Hi,
this commit broke $DPKG_ROOT support:
https://salsa.debian.org/debian/debianutils/-/commit/89daf5e2
this in turn breaks the mmdebstrap autopkgtest, thus filing this with severity
serious to prevent transition to testing until this problem is fixed.
The following patch fixes the problem:
--- a/debian/postinst
+++ b/debian/postinst
@@ -14,10 +14,10 @@ ua() {
usrmerge(){
for p in run-parts tmpfile; do
- [ -e /usr/bin/$p ] || ln -s /bin/$p /usr/bin/$p
+ [ -e "$DPKG_ROOT/usr/bin/$p" ] || ln -s /bin/$p
"$DPKG_ROOT/usr/bin/$p"
done
- [ -e /usr/sbin/installkernel ] || \
- ln -s /sbin/installkernel
/usr/sbin/installkernel
+ [ -e "$DPKG_ROOT/usr/sbin/installkernel" ] || \
+ ln -s /sbin/installkernel
"$DPKG_ROOT/usr/sbin/installkernel"
}
if test -z "$2" && test ! -f "$DPKG_ROOT/etc/shells"
Bug#1041432: box64: unsatisfiable dependencies
Hi Adrian, thank you for weighing in! Quoting Adrian Bunk (2023-07-20 01:27:10) > > Package: box64 > Architecture: amd64 arm64 ppc64el riscv64 > Depends: > libgcc-s1:amd64, > libstdc++6:amd64, > > A package must not assume that the user has other architectures enabled. why not? Is this codified in a policy somewhere? If foreign architectures are not enabled, box64 would just not be installable but there are tons of packages I cannot install on my system without the package itself being buggy (for example due to Conflicts). If I just drop these dependencies, that would make the package have an RC bug because box64 cannot function without amd64 shared libraries. > There is a general issue around such dependencies, and also the more specific > problem that permitting cross-architecture dependencies would also require > checking that migrating a package for one architecture does not break > dependencies on other architectures. > > For box64, using libgcc-s1-amd64-cross and libstdc++6-amd64-cross might be an > option (untested). Those packages install their libraries into /usr/ which is not searched by the dynamic linker. Maybe some LD_LIBRARY_PATH trickery can make it work but those shared libraries are not meant for running actual binaries. Originally, box64 upstream shipped their own binary blobs of libstdc++.so.6 and libgcc_s.so.1 and installed them into /usr/lib/x86_64-linux-gnu/. This is of course not an option either as that would conflict with users who do have amd64 packages installed and would also make the package violate DFSG for shipping binaries without source. It seems that the correct way forward would be to teach britney about foreign architecture dependencies? I had a look at the britney source and it seems to ship with its own dependency resolver instead of relying on dose3, for example. Teaching it about foreign architectures looks like a massive change... Thanks! cheers, josch signature.asc Description: signature
Bug#1041432: box64: unsatisfiable dependencies
Quoting Jeremy Bícha (2023-07-18 22:29:58) > On Tue, Jul 18, 2023 at 4:23 PM Johannes Schauer Marin Rodrigues > wrote: > > Quoting Jeremy Bícha (2023-07-18 21:20:21) > > > https://tracker.debian.org/pkg/box64 says that box64 is unable to migrate > > > into Testing because it has unsatisfiable dependencies on amd64, arm64, > > > ppc64el (and I guess riscv64) > > > > I saw that but it doesn't say which one is unsatisfiable. Do you have an > > idea > > about what is going on? > > I am guessing that britney (or whatever is checking) is not familiar > with the :amd64 syntax even on amd64. $ apt-cache show crossbuild-essential-mips64el | grep Depends: Depends: gcc-mips64el-linux-gnuabi64 (>= 4:10.2) | gcc:mips64el, g++-mips64el-linux-gnuabi64 (>= 4:10.2) | g++:mips64el, dpkg-cross But other packages use the same thing. Why does it work there? signature.asc Description: signature
Bug#1041432: box64: unsatisfiable dependencies
Hi, Quoting Jeremy Bícha (2023-07-18 21:20:21) > https://tracker.debian.org/pkg/box64 says that box64 is unable to migrate > into Testing because it has unsatisfiable dependencies on amd64, arm64, > ppc64el (and I guess riscv64) I saw that but it doesn't say which one is unsatisfiable. Do you have an idea about what is going on? Thanks! cheers, josch signature.asc Description: signature
Bug#1040477: librust-syn-1-dev fails to coinstall
Hi, Quoting Helmut Grohne (2023-07-06 13:27:19) > librust-syn-1-dev has (among other things) the following metadata: > > Provides: librust-syn-1.0.109-dev > Breaks: librust-syn-1.0.109-dev > Multi-Arch: same this looks very bad. > If apt and dose were refusing this situation this were a normal bug at > best. But since dpkg fails badly and leaves the system in an > inconsistent state, I am raising this to rc-severity. Even if we deem > this to be an apt bug or dpkg bug in the end, librust-syn-1-dev must > still be changed since we cannot depend on fixed versions of package > managers being used to install packages. I'd be very interested in knowing what this self-conflict is supposed to achieve. Depending on the answer it might be worth adding a Lintian check so that this doesn't happen again in the future. Thanks! cheers, josch signature.asc Description: signature
Bug#1035654: non-essential adduser poses problems to purging packages
Hi, Quoting Nicolas Dandrimont (2023-05-18 20:51:04) > On Thu, May 18, 2023, at 10:03, Marc Haber wrote: > > adduser probably needs an additional hint because the new upload makes > > piuparts fail now, as discussed yesterday. > To work around this issue on the piuparts side, it sounds like we should make > piuparts treat adduser as fake-essential for tests ending at bookworm or sid, > so that we don't try to uninstall it; Andreas, what do you think? a more general solution would be to skip uninstallation on all packages marked with Protected:yes or to only uninstall with --allow-remove-essential. Such a solution would not only benefit adduser but also any future packages marked with Protected:yes. Thanks! cheers, josch signature.asc Description: signature
Bug#1035654: non-essential adduser poses problems to purging packages
Hi, here is a status update on the adduser situation. Quoting Johannes Schauer Marin Rodrigues (2023-05-10 08:10:26) > The remaining 14 failures belong to the following 9 source packages: > > amavisd-new #1035841 > debian-edu-fai #1035292 > desktop-autoloader #1035291 > kismet #1035290 > matrix-sydent #1035844 > tcpcryptd #1035845 > webdis #1035435 > x2gobroker #1035847 > x2gothinclient #1034755 > > Out of these 9 remaining source packages, 5 had bugs already filed by Andreas > Beckmann. I filed bugs with patches for the remaining 4 packages and offered > to NMU if necessary. amavisd-new #1035841 fixed in unstable, unblock approved, will transition tomorrow debian-edu-fai #1035292, desktop-autoloader #1035291, x2gobroker-* #1035847, x2gothinclient #1034755 done by Mike Gabriel kismet #1035290, matrix-sydent #1035844, tcpcryptd #1035845 not in testing (nor stable) so no action required right now webdis #1035435 NMU-ed to DELAYED/2 Mike, you said on IRC that you want to file the unblock bugs for debian-edu-fai, desktop-autoloader, x2gobroker and x2gothinclient (which didn't happen yet). If you like, I can file these for you. Just say the word. :) Marc, the same offer to you for your recent adduser upload to unstable. Thanks! cheers, josch signature.asc Description: signature
Bug#1035435: webdis: fails to purge - command (deluser|adduser) in postrm not found
Hi, Quoting Johannes Schauer Marin Rodrigues (2023-05-16 23:35:38) > On Wed, 03 May 2023 14:45:01 +0200 Andreas Beckmann wrote: > > There is ongoing discussion how to handle system users on package > > removal, see https://bugs.debian.org/621833 > > Consensus seems to be not to remove system users (to avoid reusing UIDs > > which could grant access to the wrong files) but to "lock" them (where > > "locking"/"unlocking" is not yet precisely defined). Until that has > > been decided it should be sufficient to have the postrm script ignore > > any errors from deluser: > > deluser ... diff -Nru webdis-0.1.9+dfsg/debian/changelog webdis-0.1.9+dfsg/debian/changelog --- webdis-0.1.9+dfsg/debian/changelog 2020-04-23 01:04:04.0 +0200 +++ webdis-0.1.9+dfsg/debian/changelog 2023-05-17 23:56:13.0 +0200 @@ -1,3 +1,10 @@ +webdis (0.1.9+dfsg-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * ignore deluser not being available in postrm purge (closes: #1035435) + + -- Johannes Schauer Marin Rodrigues Wed, 17 May 2023 23:56:13 +0200 + webdis (0.1.9+dfsg-1) unstable; urgency=medium * d/copyright: acknowledge upstream files relocation diff -Nru webdis-0.1.9+dfsg/debian/webdis.postrm webdis-0.1.9+dfsg/debian/webdis.postrm --- webdis-0.1.9+dfsg/debian/webdis.postrm 2018-08-25 09:53:40.0 +0200 +++ webdis-0.1.9+dfsg/debian/webdis.postrm 2023-05-17 23:56:13.0 +0200 @@ -15,7 +15,7 @@ fi rm -rf $WEBDIS_LOG -deluser --system webdis +deluser --system webdis || true ;; *) signature.asc Description: signature
Bug#1035845: tcpcryptd fails to purge without adduser
Hi, Quoting Johannes Schauer Marin Rodrigues (2023-05-16 23:34:06) > Quoting jo...@debian.org (2023-05-10 07:56:44) > > To work around this problem, at least 125 source packages [codesearch] > > simply > > ignore failures of calling the passwd or adduser tools during purge. The > > following patch should fix this package by doing the same: > > > > --%<- > > diff -Nru tcpcrypt-0.5/debian/tcpcryptd.postrm > > tcpcrypt-0.5/debian/tcpcryptd.postrm > > --- tcpcrypt-0.5/debian/tcpcryptd.postrm2016-04-01 > > 23:45:55.0 +0200 > > +++ tcpcrypt-0.5/debian/tcpcryptd.postrm2023-05-10 > > 07:54:45.0 +0200 > > @@ -6,7 +6,7 @@ > > purge) > > # add a debian-tcpcryptd user if one does not already exist > > if getent passwd "$TCPCRYPT_USER" >/dev/null ; then > > -deluser "$TCPCRYPT_USER" > > +deluser "$TCPCRYPT_USER" || true > > fi > > ;; > > esac > > -->%- > > > > If you prefer I can fix this via an NMU. > > since time is running short, I am going to NMU tcpcryptd on Thursday with a > delay of 2 days unless you disagree and/or want to do this yourself. never mind, no urgency here, because tcpcryptd is not in testing (nor in the current stable) and suffers from multiple RC bugs. Thanks! cheers, josch signature.asc Description: signature
Bug#1035290: kismet: fails to purge - command (deluser|adduser) in postrm not found
Quoting Johannes Schauer Marin Rodrigues (2023-05-16 23:27:26) > since time is running out, would you mind if I NMU kismet with this change > and file the unblock request? never mind, no urgency here, because kismet is not in testing (nor in the current stable) and suffers from multiple RC bugs. Thanks! cheers, josch signature.asc Description: signature
Bug#1035844: matrix-sydent fails to purge without adduser
Hi Hubert, Quoting Hubert Chathi (2023-05-17 00:43:00) > On Tue, 16 May 2023 23:31:16 +0200, Johannes Schauer Marin Rodrigues > said: > > since time is running short, I am going to NMU matrix-sydent on Thursday > > with a delay of 2 days unless you disagree and/or want to do this yourself. > Thanks for the report and the offer to fix it. I'm not objecting to your > NMU, but I wanted to point out that matrix-sydent isn't in testing (and > AFAICT never has been), so it isn't holding up the release. So I don't think > there's any particular rush to fix this issue. There's also another RC bug > (https://bugs.debian.org/1029442) that would block it from migrating. well that's even better news! Less work for me then because in that case, closing this bug is of no urgency. Would you like a merge request on the matrix-sydent packaging git fixing this or will you take care of implementing this fix yourself? Thanks! cheers, josch signature.asc Description: signature
Bug#1034755: x2gothinclient-common: about .postinst and .postrm scripts
Hi, On Sun, 14 May 2023 18:29:56 +0200 Patrice Duroux wrote: > Here is a patch for the .postrm script useing deluser/delgroup on purge. that patch looks good. Thanks! Since time is running short, I am going to NMU x2gothinclient on Thursday with a delay of 2 days unless you disagree and/or want to do this yourself. Thanks! cheers, josch signature.asc Description: signature
Bug#1035435: webdis: fails to purge - command (deluser|adduser) in postrm not found
On Wed, 03 May 2023 14:45:01 +0200 Andreas Beckmann wrote: > There is ongoing discussion how to handle system users on package > removal, see https://bugs.debian.org/621833 > Consensus seems to be not to remove system users (to avoid reusing UIDs > which could grant access to the wrong files) but to "lock" them (where > "locking"/"unlocking" is not yet precisely defined). Until that has > been decided it should be sufficient to have the postrm script ignore > any errors from deluser: > deluser ... || true since time is running short, I am going to NMU webdis on Thursday with a delay of 2 days unless you disagree and/or want to do this yourself. Thanks! cheers, josch signature.asc Description: signature
Bug#1035845: tcpcryptd fails to purge without adduser
Hi, Quoting jo...@debian.org (2023-05-10 07:56:44) > To work around this problem, at least 125 source packages [codesearch] simply > ignore failures of calling the passwd or adduser tools during purge. The > following patch should fix this package by doing the same: > > --%<- > diff -Nru tcpcrypt-0.5/debian/tcpcryptd.postrm > tcpcrypt-0.5/debian/tcpcryptd.postrm > --- tcpcrypt-0.5/debian/tcpcryptd.postrm2016-04-01 23:45:55.0 > +0200 > +++ tcpcrypt-0.5/debian/tcpcryptd.postrm2023-05-10 07:54:45.0 > +0200 > @@ -6,7 +6,7 @@ > purge) > # add a debian-tcpcryptd user if one does not already exist > if getent passwd "$TCPCRYPT_USER" >/dev/null ; then > -deluser "$TCPCRYPT_USER" > +deluser "$TCPCRYPT_USER" || true > fi > ;; > esac > -->%- > > If you prefer I can fix this via an NMU. since time is running short, I am going to NMU tcpcryptd on Thursday with a delay of 2 days unless you disagree and/or want to do this yourself. Thanks! cheers, josch signature.asc Description: signature
Bug#1035844: matrix-sydent fails to purge without adduser
Hi,
Quoting jo...@debian.org (2023-05-10 07:49:26)
> To work around this problem, at least 125 source packages [codesearch] simply
> ignore failures of calling the passwd or adduser tools during purge. The
> following patch should fix this package by doing the same:
>
> --%<-
> diff -Nru matrix-sydent-2.5.1/debian/postrm matrix-sydent-2.5.1/debian/postrm
> --- matrix-sydent-2.5.1/debian/postrm 2021-06-01 21:17:05.0 +0200
> +++ matrix-sydent-2.5.1/debian/postrm 2023-05-10 07:46:13.0 +0200
> @@ -25,7 +25,7 @@
> dpkg-statoverride --force-all --quiet --remove "${DIR}"
> done
>
> - getent passwd "${USER}" >/dev/null && deluser "${USER}"
> + getent passwd "${USER}" >/dev/null && deluser "${USER}" || true
>
> rm -f /var/lib/${NAME}/*
> if [ -d /var/lib/${NAME} ]; then
> -->%-
>
> If you prefer I can fix this via an NMU.
since time is running short, I am going to NMU matrix-sydent on Thursday with a
delay of 2 days unless you disagree and/or want to do this yourself.
Thanks!
cheers, josch
signature.asc
Description: signature
Bug#1035290: kismet: fails to purge - command (deluser|adduser) in postrm not found
Hi, On Sun, 30 Apr 2023 05:08:50 +0200 Andreas Beckmann wrote: > during a test with piuparts I noticed your package failed to purge due > to a command not found. According to policy 7.2 you cannot rely on the > depends being available during purge, only the essential packages are > available for sure. > > The fix should be easy: your package is using adduser or deluser from > the adduser package, which is only priority important. Using useradd or > userdel from the passwd package (priority required) should fix this > problem. > > There is ongoing discussion how to handle system users on package > removal, see https://bugs.debian.org/621833 > Consensus seems to be not to remove system users (to avoid reusing UIDs > which could grant access to the wrong files) but to "lock" them (where > "locking"/"unlocking" is not yet precisely defined). Until that has > been decided it should be sufficient to have the postrm script ignore > any errors from deluser: > deluser ... || true since time is running out, would you mind if I NMU kismet with this change and file the unblock request? Thanks! cheers, josch signature.asc Description: signature
Bug#1035841: fixed in amavisd-new 1:2.13.0-3
Hi, On Thu, 11 May 2023 23:52:00 + Debian FTP Masters wrote: > Changes: > amavisd-new (1:2.13.0-3) unstable; urgency=medium > . >* Fix failure to purge without adduser. Closes: #1035841. thank you! Would you like me to take care of filing the unblock request with release.debian.org or would you like to take care of that yourself? Thanks! cheers, josch signature.asc Description: signature
Bug#1035654: non-essential adduser poses problems to purging packages
Hi, Quoting Helmut Grohne (2023-05-07 13:52:50) > > I contend that: > > 1. This change is in unstable since 2022-10-31, i.e. more than half a > year. > 2. While having adduser drop from the essential+apt set is caused by > apt dropping it, this was an implementation detail and any package > using adduser without a dependency was (invisibly) buggy before. > > So I don't quite buy the reasoning of "too late" or it being apt's > fault. > > On the flip side, I think it would technically have been the > responsibility of the proponents of dropping adduser to do the testing. > The proponents have been Josch and my self and we ultimately failed to do so. > Thanks to Andreas for doing it for us. this is true. I must admit that I haven't thought of maintainer scripts using adduser during purge and failing because they expect adduser to always be installed. Even though it is too late, I ran this script on all 11864 binary packages in unstable amd64 that have either a postrm or prerm script: #!/bin/sh set -eu ret=0 PKG_TO_TEST="$1" mmdebstrap --logfile="$1.log" --variant=essential \ --customize-hook='APT_CONFIG=$MMDEBSTRAP_APT_CONFIG apt-get -oDPkg::Chroot-Directory="$1" --yes install --no-install-recommends "$PKG_TO_TEST"' \ --customize-hook='APT_CONFIG=$MMDEBSTRAP_APT_CONFIG apt-get -oDPkg::Chroot-Directory="$1" --yes remove adduser' \ --customize-hook='printf "#!/bin/sh\nset -eu\necho \"I: adduser-dummy: attempting to run \$0\" >&2\nexit 1\n" > "$1/usr/sbin/adduser-dummy"' \ --customize-hook='chmod +x "$1/usr/sbin/adduser-dummy"' \ --customize-hook='ln -s adduser-dummy "$1/usr/sbin/adduser"' \ --customize-hook='ln -s adduser-dummy "$1/usr/sbin/deluser"' \ --customize-hook='ln -s adduser-dummy "$1/usr/sbin/addgroup"' \ --customize-hook='ln -s adduser-dummy "$1/usr/sbin/delgroup"' \ --customize-hook='APT_CONFIG=$MMDEBSTRAP_APT_CONFIG apt-get -oDPkg::Chroot-Directory="$1" --yes remove --purge "$PKG_TO_TEST"' \ unstable /dev/null http://127.0.0.1:3142/debian || ret=$? if [ "$ret" -eq 0 ] && ! grep --silent "^I: adduser-dummy: attempting to run " "$1.log"; then rm "$1.log" fi I did not limit the investigation to the packages with strings like deluser and delgroup in their maintainer scripts to make sure to also catch packages that indirectly call adduser tools through another script. Out of the tested 11864 packages, 133 called adduser tools at one point or the other but purging still succeeds (for example because of a || true). 210 of the tested 11864 packages fail this script. Out of the 210 failures, 17 are Essential:yes packages and thus failed. Out of the 193 remaining failures, 113 fail to install in the first place. Out of the 80 remaining failures, 32 fail because they try calling adduser tools which are not installed and thus fail. I skimmed through the 48 other purging failures and they seem to be nearly all related to gtk and gsettings. Of the remaining 32 adduser related purging problems, 18 packages check if deluser/delgroup exist before calling it and then fail because I installed the dummy. The remaining 14 failures belong to the following 9 source packages: amavisd-new #1035841 debian-edu-fai #1035292 desktop-autoloader #1035291 kismet #1035290 matrix-sydent #1035844 tcpcryptd #1035845 webdis #1035435 x2gobroker #1035847 x2gothinclient #1034755 Out of these 9 remaining source packages, 5 had bugs already filed by Andreas Beckmann. I filed bugs with patches for the remaining 4 packages and offered to NMU if necessary. > > With such a change I would have expected upgrade/piuparts tests from > > bullseye to bookworm that tried to remove adduser a various stages and > > check for the fallout. Given that Andreas is only doing them now, that's > > too late for changes to the pseudo-essential set. Given that only 9 source packages in unstable fail to purge because they expect adduser to be present, I have another proposal. I think making adduser Essential:yes (even if temporary) or making it a dependency of an Essential:yes has the downside, that now package maintainers have official reason to rely on its functionality and include that into their maintainer scripts. Finding these new bugs becomes a bit more tricky because to test for this, an Essential:yes package has to be removed. Same goes for making it pseudo-essential via apt because removing adduser to test regressions would remove apt. According to [popcon], adduser is installed on 100% of the systems providing popcon data. This makes sense because probably near 100% of the systems submitting popcon data either has apt installed (which used to pull in adduser) or was installed via d-i (which pulls in adduser because it is Priority:important). I would thus argue that what we have to guard against
Bug#1030638: cp -a fails to preserve ownership information on 32-bit arches
Hi Shengjing, Quoting Shengjing Zhu (2023-03-01 06:40:38) > I've debugged it as well and here is my write up. Though I don't have > solution yet. you don't have a *good* solution yet but I think you are extremely close! Thank you so much for spending all the time debugging this *and* for this very helpful writeup which is helpful for guys like me who could've never come this far by themselves. Thank you! :) Would it maybe possible to choose the correct stat struct by trying to see with which struct the values make sense? For example it should be easy to check which inode numbers actually exist. The other entries of the stat struct also can be checked if they look legitimate, like the file mode (which should not be larger than 0o4777). What do you think? Thanks! cheers, josch
Bug#1030638: cp -a fails to preserve ownership information on 32-bit arches
Hi,
Quoting Johannes Schauer Marin Rodrigues (2023-02-06 00:47:35)
> since glibc 2.34 and coreutils 9.1, fakeroot fails to preserve ownership
> information when running "cp -a" on a file owned by a user other than
> root. On armel, armhf and i386 (our 32 bit arches), you can reproduce
> this problem by running inside fakeroot:
>
> $ touch foo
> $ chown 0:42 foo
> $ ls -lha foo
> $ cp -a foo bar
> $ ls -lha bar"
>
> which will print this:
>
> -rw-r--r-- 1 root shadow 0 Feb 5 23:00 foo
> -rw-r--r-- 1 root root 0 Feb 5 23:00 bar
>
> I submitted an improvement to the `cp-a` test which adds a check for the
> ownership information in addition to the mode checks as a merge request
> for that test here:
>
> https://salsa.debian.org/clint/fakeroot/-/merge_requests/19
>
> Observe how the salsaci pipeline succeds for amd64 but fails on i386.
> The reason is that on i386, fakeroot will not retain the ownership
> information.
>
> A quick comparison of the strace output on arm64 (which does not have
> this problem) and armhf (which does have this problem) shows that arm64
> calls fchown() while armhf calls fchown32() which is not wrapped by
> fakeroot. Maybe that is the problem?
>
> This breaks my package mmdebstrap in a similar way as #1023286 did.
I have a little bit of more input. This is what "cp --preserve=ownership" does
on amd64 (according to ltrace):
open("bar", 2162688, 015412541474)
= -1
__errno_location()
= 0x7ff47c598398
fstatat(0xff9c, 0x7ffe6c2ac337, 0x7ffe6c2aae10, 0)
= 0
open("foo", 0, 00)
= 3
fstat(3, 0x7ffe6c2aafc0, 0, 0x7ff47c72ae51)
= 0
openat(0xff9c, 0x7ffe6c2ac33b, 193, 384)
= 4
__errno_location()
= 0x7ff47c598398
ioctl(4, 1074041865, 0x3)
= -1
fstat(4, 0x7ffe6c2aaf30, 0x, 0x7ff47c730bab)
= 0
Okay, nothing to see here. This works, after all. On i386 it looks like this:
open64("bar", 2162688, 012625311011)
= -1
__errno_location()
= 0xf7bf56bc
__fstatat64_time64(-100, 0xff958337, 0xff957948, 0)
= 0
open64("foo", 0, 00)
= 3
__fstat64_time64(3, 0xff957a8c, 0xff957948, 0)
= 0
openat64(-100, 0xff95833b, 193, 384)
= 4
__errno_location()
= 0xf7bf56bc
__ioctl_time64(4, 0x40049409, 3, 1)
= -1
__fstat64_time64(4, 0xff957a20, 0, 0)
= 0
So now this looks even more like #1023286 because it involves
__fstatat64_time64 and __fstat64_time64. I added this patch to fakeroot:
--- a/libfakeroot.c
+++ b/libfakeroot.c
@@ -2671,6 +2673,11 @@ int WRAP_FSTATAT64_TIME64 FSTATAT64_TIME64_ARG(int ver,
int r;
+#ifdef LIBFAKEROOT_DEBUGGING
+ if (fakeroot_debug) {
+fprintf(stderr, "fstatat64[time64] fd %d %s\n", dir_fd, path);
+ }
+#endif /* LIBFAKEROOT_DEBUGGING */
r=NEXT_FSTATAT64_TIME64(ver, dir_fd, path, st, flags);
if(r)
return -1;
And re-ran the t.cp-a test that I changed according to my merge request to
reproduce the problem on i386 like this:
env --chdir=test srcdir=$(pwd)/test VERBOSE=1 libfakeroot=libfakeroot-0.so sh
-x ./t.cp-a
(is there a better way to run individual tests with maximum verbosity?)
The relevant call to `cp -a` looks like this:
stat64 file_name /home/josch/usr/bin/cp
stat64 file_name /usr/local/bin/cp
stat64 file_name /usr/bin/cp
fstatat64[time64] fd -100 empty
load_library_symbols
fstat64[time64] fd 3
fstat64[time64] fd 4
flistxattr fd 3
flistxattr fd 3
fchmod fd 4
This seems to indicate that __fstatat64_time64 does get wrapped as expected.
The dirfd is set to -100 which is the special value AT_FDCWD.
I'm at a loss at how to proceed.
Can you find out more?
Thanks!
cheers, josch
signature.asc
Description: signature
Bug#1030638: cp -a fails to preserve ownership information on 32-bit arches
Package: fakeroot Version: 1.30.1-1.1 Severity: grave Control: affects -1 + mmdebstrap Hi, since glibc 2.34 and coreutils 9.1, fakeroot fails to preserve ownership information when running "cp -a" on a file owned by a user other than root. On armel, armhf and i386 (our 32 bit arches), you can reproduce this problem by running inside fakeroot: $ touch foo $ chown 0:42 foo $ ls -lha foo $ cp -a foo bar $ ls -lha bar" which will print this: -rw-r--r-- 1 root shadow 0 Feb 5 23:00 foo -rw-r--r-- 1 root root 0 Feb 5 23:00 bar I submitted an improvement to the `cp-a` test which adds a check for the ownership information in addition to the mode checks as a merge request for that test here: https://salsa.debian.org/clint/fakeroot/-/merge_requests/19 Observe how the salsaci pipeline succeds for amd64 but fails on i386. The reason is that on i386, fakeroot will not retain the ownership information. A quick comparison of the strace output on arm64 (which does not have this problem) and armhf (which does have this problem) shows that arm64 calls fchown() while armhf calls fchown32() which is not wrapped by fakeroot. Maybe that is the problem? This breaks my package mmdebstrap in a similar way as #1023286 did. Since I think that `cp -a` functionality is quite essential, I'm making this bug RC. Feel free to adjust accordingly. Thanks! cheers, josch
Bug#1030256: FTBFS: test failures ArgumentError: can't find user for puppet
Hi, Quoting Vagrant Cascadian (2023-02-03 00:18:58) > On 2023-02-01, Jérôme Charaoui wrote: > > I don't know how common that is in build environments, but it's not > > something that I have or think I should have in my build (sbuild) or > > test (autopkgtest) environments. > > I was able to reproduce the issue with sbuild. > > This appears to be because sbuild copies the host's /etc/passwd and > /etc/group into the chroot when it builds... and presumably the buildd > environment does this as well (and all DSA machines have the puppet user > available?)... and so the puppet user is in fact available in those cases, > but not others... > > I was able to workaround the issue with: > > sbuild --chroot-setup-commands='adduser --gecos ,,, --disabled-password > puppet' ... > > Is there an option in sbuild to not copy the passwd/group information into > the chroot? What are the implications of that? I think we are not so much talking about a limitation of sbuild but about a limitation of the sbuild schroot backend. When above you say that sbuild copies /etc/passwd and /etc/group into the chroot, what you probably mean is that sbuild-createchroot appends the output of `getent passwd sbuild` and `getent group sbuild` to /etc/passwd and /etc/group, respectively? It would be news to me if sbuild at any point copies all of /etc/passwd or /etc/group into the chroot at any point. Do you see this somewhere happening in the code? Remember that the sbuild-createchroot utility is only really useful if you use the sbuild schroot backend (which is also the default backend and also the backend that is used on the buildds). Since you are asking whether passwd/group information can somehow not be copied into the chroot, you probably are not interested in a change in the buildd infrastructure but just a local change? In that case, maybe consider not using the schroot backend but the unshare backend. The latter has the advantage that you do not need any special setup of the chroot at all. Any chroot tarball that contains apt can be used by the unshare backend. Quick introduction (assuming you are on amd64): $ mkdir -p ~/.cache/sbuild $ mmdebstrap --variant=buildd unstable ~/.cache/sbuild/unstable-amd64.tar.xz $ sbuild --chroot-mode=unshare ... Note that in contrast to the schroot backend, you do not need to become the superuser at any point. Thanks! cheers, josch
Bug#1025872: installing greetd immediately reboots and prevents any logins
Package: greetd Version: 0.8.0-1+b1 Severity: critical Hi, installing the greetd package will log out the current user. When attempting to log in again, the message "This account is currently not available." is shown and the user is put back into the login prompt. This happens independent of which user one tries to login with. There are two problems here: 1. installing greetd should log out the current user. This prevents editing /etc/greetd/config.toml to add the intended configuration. Since the package cannot know the user's intention, maybe the service should be disabled by default? 2. the default configuration reads: command = "/usr/sbin/agreety --cmd $SHELL" since greetd is run as the _greetd user and since the shell of the _greetd is /usr/sbin/nologin, $SHELL will become /usr/sbin/nologin and thus all login attempts will be made impossible. I think to close this bug, both issues must be addressed: 1. do not start the greetd service by default installing a package should not result into logging out the currently active user 2. provide a sensible default. Using $SHELL makes no sense when the default shell of the user running greetd is /usr/sbin/nologin. Maybe replace $SHELL with /bin/bash? Thanks! cheers, josch
Bug#1023436: unusable on mipsel: unexpected breakpoint at 0x...
Package: ltrace Version: 0.7.3-6.3 Severity: grave Hi, running ltrace on mipsel, I get: $ ltrace echo unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ee8 unexpected breakpoint at 0x77e74ee8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ee8 unexpected breakpoint at 0x77e74ee8 unexpected breakpoint at 0x77e74ee8 unexpected breakpoint at 0x77e74ee8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77e74ef8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926d8 unexpected breakpoint at 0x77d926c8 unexpected breakpoint at 0x77d926c8 +++ exited (status 0) +++ This makes the package unusable. Thanks! cheers, josch
Bug#1016070: marked as pending in sbuild
Control: tag -1 pending Hello, Bug #1016070 in sbuild reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/sbuild/-/commit/002bb6fef7eda2cab7c5cc3e0bfa8baf14c8d6b3 debian/tests/unshare-qemuwrapper: bump disk size to 4G Sometimes gcc temporarily includes debug symbols to track down ICEs from build logs. This blows up the packages by several hundred megabytes until debug symbols are removed again. Usually this happens when new gcc versions are uploaded and gets reverted before a stable release. Closes: #1016070 (this message was generated automatically) -- Greetings https://bugs.debian.org/1016070
Bug#1021478: mmdebstrap - Enables first boot experience via machine-id
Control: tag -1 + patch Control: forwarded -1 https://gitlab.mister-muffin.de/josch/mmdebstrap/commit/d4cb0656396b12718f67f045e548d6ebe9ffef85 Quoting Bastian Blank (2022-10-09 10:28:25) > mmdebstrap writed "uninitialized" to /etc/machine-id. This triggers > first boot semantic[1], so makes the boot wait for input. > > Please write an empty file if you are not equipped to handle first boot > questions. Thanks! Done in the commit that this bug has been forwarded to. signature.asc Description: signature
Bug#1020593: mmdebstrap: debootstrap installing empty lsb-base package prevents autopkgtest from passing
Package: mmdebstrap Version: 1.2.1-2 Severity: serious X-Debbugs-Cc: jo...@debian.org The functionality of lsb-base is in the Essential:yes set since Bullseye. The package itself is now an empty transitional package (because debootstrap doesn't understand the Provides relationship) which depends on the new provider of the functionality, sysvinit-utils, which is also in the Essential:yes set. The problem is, that this empty package is only installed by debootstrap because its resolver is not clever enough to realize that its installation can be avoided. The resolver used by mmdebstrap (apt) does not draw in the useless empty lsb-base package, thus resulting in a difference between the chroots created by debootstrap and mmdebstrap that makes the mmdebstrap test suite not succeed: https://ci.debian.net/data/autopkgtest/unstable/amd64/m/mmdebstrap/26125615/log.gz [...] I: Retrieving logrotate 3.20.1-1 I: Validating logrotate 3.20.1-1 I: Retrieving lsb-base 11.4 W: Couldn't download package lsb-base (ver 11.4 arch all) at http://127.0.0.1/debian/pool/main/l/lsb/lsb-base_11.4_all.deb I: Retrieving dmsetup 2:1.02.185-1 I: Validating dmsetup 2:1.02.185-1 [...] I: Retrieving zlib1g 1:1.2.11.dfsg-4.1 I: Validating zlib1g 1:1.2.11.dfsg-4.1 E: Couldn't download packages: lsb-base Instead of adding a hack to mmdebstrap, lets correct all packages in the Priority:important set that still carry a useless dependency on lsb-base: https://salsa.debian.org/debian/cron/-/merge_requests/7 https://salsa.debian.org/debian/ifupdown/-/merge_requests/12 https://salsa.debian.org/md/kmod/-/merge_requests/9 https://salsa.debian.org/debian/procps/-/merge_requests/6 There is also a proposed lintian message deprecating the use of lsb-base in dependencies: https://salsa.debian.org/lintian/lintian/-/merge_requests/419 Thanks! cheers, josch
Bug#1020218: vcmi: luajit got removed on ppc64el, please either drop vcmi on ppc64el or switch to lua
Hi Paul,
thanks for caring about my "contrib" package! :)
Quoting Paul Gevers (2022-09-18 11:44:07)
> vcmi build depends on libluajit-5.1-dev but that got removed on
> ppc64el because it doesn't work correcty on that architecture and
> noone volunteers to fix *and maintain* it on that architecture. See
> bug #1014853.
>
> Please investigate if you can just use liblua or if your package needs
> to be removed on ppc64el.
I thought according to the recent threat on d-devel [1] packages that FTBFS on
some arches should rather just let it FTBFS instead of maintaining a list of
architectures the package can be built on?
[1] https://lists.debian.org/20220911150857.xedt2an2vye3qrc7@begin
Do you know more about Lua? I do not. If I change from libluajit-5.1-dev to
liblua5.1-dev I get:
/<>/scripting/lua/LuaScriptingContext.cpp:47:18: error:
‘LUA_BITLIBNAME’ was not declared in this scope; did you mean ‘LUA_IOLIBNAME’?
47 | {LUA_BITLIBNAME, luaopen_bit}
| ^~
| LUA_IOLIBNAME
/<>/scripting/lua/LuaScriptingContext.cpp:47:34: error:
‘luaopen_bit’ was not declared in this scope; did you mean ‘luaopen_io’?
47 | {LUA_BITLIBNAME, luaopen_bit}
| ^~~
| luaopen_io
/<>/scripting/lua/LuaScriptingContext.cpp:48:9: error: could not
convert ‘{{"", luaopen_base}, {"table", luaopen_table}, {"string",
luaopen_string}, {"math", luaopen_math}, {, }}’ from ‘’ to ‘const
std::vector’
48 | };
| ^
| |
|
Thanks!
cheers, josch
signature.asc
Description: signature
Bug#960679: fontconfig: strict dependency of arch:any libfontconfig1 on arch:all fontconfig-config going wrong
Hi,
On Fri, 15 May 2020 12:48:14 +0200 Julien Cristau wrote:
> libfontconfig1 Depends on fontconfig-config (>= ${source:Version})
>
> If the arch:amd64 buildd is faster than the arch:all one, as happened
> with 2.13.1-4.1, the new libfontconfig1 becomes uninstallable, and,
> because fontconfig indirectly build-depends on libfontconfig1, that
> situation can't fix itself.
>
> One way around that is to make fontconfig-config arch:any; there may be other
> solutions.
I uploaded an NMU with attached debdiff to DELAYED/10 to fix this bug.
Thanks!
cheers, joschdiff -Nru fontconfig-2.13.1/debian/changelog fontconfig-2.13.1/debian/changelog
--- fontconfig-2.13.1/debian/changelog 2022-01-29 17:05:46.0 +0100
+++ fontconfig-2.13.1/debian/changelog 2022-09-04 18:37:48.0 +0200
@@ -1,3 +1,14 @@
+fontconfig (2.13.1-4.5) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Make fontconfig-config arch:any. If one of the arch:any buildds is faster
+than the arch:all one, the new libfontconfig1 becomes uninstallable, and,
+because fontconfig indirectly build-depends on libfontconfig1, that
+situation can't fix itself. Turning fontconfig-config from arch:all to
+arch:any prevents this from happening. (closes: #960679)
+
+ -- Johannes Schauer Marin Rodrigues Sun, 04 Sep 2022 18:37:48 +0200
+
fontconfig (2.13.1-4.4) unstable; urgency=medium
* Non-maintainer upload.
diff -Nru fontconfig-2.13.1/debian/control fontconfig-2.13.1/debian/control
--- fontconfig-2.13.1/debian/control 2020-05-15 12:55:02.0 +0200
+++ fontconfig-2.13.1/debian/control 2022-09-04 17:16:52.0 +0200
@@ -42,7 +42,7 @@
available to fontconfig applications.
Package: fontconfig-config
-Architecture: all
+Architecture: any
Depends: ${misc:Depends},
ucf (>= 0.29),
# Bitstream Vera and derivatives
diff -Nru fontconfig-2.13.1/debian/rules fontconfig-2.13.1/debian/rules
--- fontconfig-2.13.1/debian/rules 2022-01-12 07:49:42.0 +0100
+++ fontconfig-2.13.1/debian/rules 2022-09-04 17:17:10.0 +0200
@@ -23,8 +23,7 @@
chmod +w debian/po/*.po
debconf-updatepo
-override_dh_install-indep:
- dh_install -i
+execute_after_dh_install-arch:
cd debian/fontconfig-config/usr/share/fontconfig/conf.avail && \
mv 70-yes-bitmaps.conf 70-force-bitmaps.conf
cp debian/70-yes-bitmaps.conf debian/fontconfig-config/usr/share/fontconfig/conf.avail/
signature.asc
Description: signature
Bug#1017592: mmdebstrap: autopkgtest fails because getpwnam is broken in fakechroot since glibc 2.34
Source: mmdebstrap Version: 1.1.0-1 Severity: serious X-Debbugs-Cc: jo...@debian.org Control: block -1 by 1017590 Hi, since the upload of src:glibc 2.34, getpwnam are not wrapped anymore by fakechroot. This breaks the autopkgtest of mmdebstrap. See https://bugs.debian.org/1017590 for details. Thanks! cheers, josch
Bug#1017441: debhelper: building src:shadow wrongly makes passwd depend on systemd | systemd-tmpfiles
Package: debhelper Version: 13.9 Severity: serious X-Debbugs-Cc: jo...@debian.org Steps to reproduce: $ sbuild -d unstable shadow [...] [...] [...] passwd_4.11.1+dfsg1-2_amd64.deb --- new Debian package, version 2.0. size 944912 bytes: control archive=7432 bytes. 111 bytes, 6 lines conffiles 740 bytes,17 lines control██ 18406 bytes, 275 lines md5sums██ 1090 bytes,40 lines * postinst #!/bin/sh 172 bytes, 5 lines * postrm #!/bin/sh 172 bytes, 5 lines * preinst #!/bin/sh 172 bytes, 5 lines * prerm#!/bin/sh Package: passwd Source: shadow Version: 1:4.11.1+dfsg1-2 Architecture: amd64 Maintainer: Shadow package maintainers Installed-Size: 2761 Depends: libaudit1 (>= 1:2.2.1), libc6 (>= 2.34), libcrypt1 (>= 1:4.1.0), libpam0g (>= 0.99.7.1), libselinux1 (>= 3.1~), libsemanage2 (>= 2.0.3), systemd | systemd-tmpfiles, libpam-modules The package passwd=1:4.11.1+dfsg1-2 in the archive does not have the dependency on "systemd | systemd-tmpfiles" and was compiled with debhelper 13.6. This currently installs systemd on a systems that don't need it, which is especially bad for minimal and embedded systems and/or containers. Thus setting the severity to serious. Feel free to adjust. Thanks! cheers, josch
Bug#1016905: freecad: fails to install when installing together with kicad
Package: freecad Version: 0.20+dfsg1-2 Severity: serious X-Debbugs-Cc: jo...@debian.org Hi, when installing freecad together with kicad, one gets the following error: Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libfreecad-python3-0.20 : Depends: libocct-data-exchange-7.5 (>= 7.5.2+dfsg1) but it is not installable Depends: libocct-foundation-7.5 (>= 7.5.2+dfsg1) but it is not installable Depends: libocct-modeling-algorithms-7.5 (>= 7.5.2+dfsg1) but it is not installable Depends: libocct-modeling-data-7.5 (>= 7.5.2+dfsg1) but it is not installable Depends: libocct-ocaf-7.5 (>= 7.5.2+dfsg1) but it is not installable Depends: libocct-visualization-7.5 (>= 7.5.2+dfsg1) but it is not installable E: Unable to correct problems, you have held broken packages. The reason is a conflict between libocct-modeling-algorithms-7.6 (as pulled in by kicad) and libocct-modeling-algorithms-7.5 (as pulled in by freecad): report: - coinst: freecad:amd64 (= 0.20+dfsg1-2) , kicad:amd64 (= 6.0.7+dfsg-1+b1) status: broken reasons: - conflict: pkg1: package: libocct-modeling-algorithms-7.6 version: 7.6.3+dfsg1-2 architecture: amd64 unsat-conflict: libocct-modeling-algorithms-7.5:amd64 pkg2: package: libocct-modeling-algorithms-7.5 version: 7.5.2+dfsg1-2 architecture: amd64 depchain2: - depchain: - package: freecad version: 0.20+dfsg1-2 architecture: all depends: freecad-python3:amd64 (>= 0.20+dfsg1-2) - package: freecad-python3 version: 0.20+dfsg1-2 architecture: amd64 depends: libfreecad-python3-0.20:amd64 (= 0.20+dfsg1-2) - package: libfreecad-python3-0.20 version: 0.20+dfsg1-2 architecture: amd64 depends: libocct-modeling-algorithms-7.5:amd64 (>= 7.5.2+dfsg1)
Bug#1016298: clapper: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 MESON_TESTTHREADS=8 meson test returned exit code 1
Hi Lucas, Quoting Lucas Nussbaum (2022-07-29 20:18:41) > During a rebuild of all packages in sid, your package failed to build on > amd64. thanks a lot for your bug report! > > command: MALLOC_PERTURB_=84 /usr/bin/appstream-util validate-relax > > /<>/data/com.github.rafostar.Clapper.metainfo.xml > > --- stdout > > --- > > /<>/data/com.github.rafostar.Clapper.metainfo.xml: FAILED: > > • url-not-found : failed to connect: SSL handshake > > failed > > [https://raw.githubusercontent.com/wiki/Rafostar/clapper/media/screenshot-windowed.png] > > • url-not-found : failed to connect: SSL handshake > > failed > > [https://raw.githubusercontent.com/wiki/Rafostar/clapper/media/screenshot-fullscreen.png] > > • url-not-found : failed to connect: SSL handshake > > failed > > [https://raw.githubusercontent.com/wiki/Rafostar/clapper/media/screenshot-floating.png] > > • url-not-found : failed to connect: SSL handshake > > failed > > [https://raw.githubusercontent.com/wiki/Rafostar/clapper/media/screenshot-mobile.png] > > --- stderr > > --- > > Validation of files failed > > == This is now fixed in git and I'll do an upload soon: https://salsa.debian.org/gnome-team/clapper/-/commit/a5e207f51fa37592bb3c8bbb64d71edbf19a88f7 What I don't understand is, why this wasn't discovered by the autobuilders. Do the buildds allow network access during the builds? I thought they did not. Do you have an idea? Thanks! cheers, josch signature.asc Description: signature
Bug#1016070: sbuild: autopkgtest fails with "No space left on device"
Quoting Paul Gevers (2022-07-26 22:24:55) > That worker (ci-worker13) has 7 TB of disk available, so space shouldn't be > the problem. I'm also not seeing [1] the disk usage anytime higher than 7% > (and it's actually that /mnt/lxc-containers that's being used and that > doesn't peak above 1.2% since we changed hosts). Yes, disk space is not a problem. The failing test is unshare-qemuwrapper which tests the unshare backend of sbuild. Since neither the salsaci nor the debci autopkgtest runners allow unsharing the user namespace, the autopkgtest creates a qemu virtual machine and the test is then run inside of qemu. Increasing the disk size of that qemu virtual machine is easy but I first want to confirm that the buildd chroot growing by half a GB is intended and not a bug that this test found. signature.asc Description: signature
Bug#1016070: sbuild: autopkgtest fails with "No space left on device"
Hi, Quoting Luca Boccassi (2022-07-26 15:27:35) > If it's not appropriate, please do update it accordingly, but IIRC it's what > gets used in these cases. a bunch of sbuild issues piled up during the last weeks so I'll be doing an upload soon and will include a fix for this as well. > > I put the gcc maintainer in CC. Is the buildd tarball to be more than twice > > the size compared to before now? > > Good find - regardless of whether it's intended that the tarball is so > large, perhaps it is an indication that the sbuild testsuite is a bit > fragile w.r.t. the running environment? Would it be possible to adjust > it to be more resilient? Is there a different disk-based scratch area > available for test artifacts? the autopkgtest checks whether the sbuild unshare backend works. The environment on salsaci and the one on ci.debian.net does not support Linux user namespaces. To still be able to test it, the autopkgtest creates a virtual qemu environment and runs the test inside a qemu virtual machine. The size of the machine image is the limiting factor here. The virtual machine image size was not a problem since the introduction of this test in January 2021, so I wouldn't call it "fragile". Increasing the disk size is simple but while you call such an adjustment to make it more "resilient" I first want to confirm that the more than twice increase in size is intentional or not. Otherwise, changing the disk size might have the opposite effect of "resilient" and hide problems resulting from an accidental upload which unnecessarily increased the installation size by half a Gigabyte. Thanks! cheers, josch signature.asc Description: signature
Bug#1016070: sbuild: autopkgtest fails with "No space left on device"
Hi, thank you for your bug report! Quoting Luca Boccassi (2022-07-26 13:28:50) > Severity: serious why is an autopkgtest failure "serious"? > The autopkgtest run for sbuild keeps failing in debci, blocking other > packages migrations. The failure manifests in two different error > types, but both related to "No space left on device" when running > mmdebstrap. The reason for this is the upload of gcc-defaults 1.198 to unstable. I bisected Debian unstable. On 2022-07-22T08:51:38Z a buildd chroot tarball was 396 MB small. Starting with snapshot timestamp 2022-07-22T15:09:35Z (the first timestamp with the new gcc-defaults version) a buildd chroot tarball is now 906 MB large. I put the gcc maintainer in CC. Is the buildd tarball to be more than twice the size compared to before now? Thanks! cheers, josch signature.asc Description: signature
Bug#1015155: neatvnc: copyright Joseph Werle for murmurhash missing
Source: neatvnc Version: 0.5.1+dfsg-1 Severity: serious Justification: Policy 2.3 X-Debbugs-Cc: jo...@debian.org Hi, your recent upload of neatvnc introduced murmurhash which is copyright "2014 Joseph Werle" but you did not add that to d/copyright: https://sources.debian.org/src/neatvnc/0.5.1%2Bdfsg-1/src/murmurhash.c/ Thanks! cheers, josch
Bug#1015099: wayvnc: FTBFS: ../src/main.c:504:9: error: too few arguments to function ‘nvnc_set_userdata’
Hi Boyuan, recently you uploaded neatvnc 0.5.1+dfsg-1 without making sure that its reverse dependencies don't break. This resulted in the following FTBFS for wayvnc. I'm fixing that now, but in the future, please do a rebuild of your reverse dependencies before uploading or upload to experimental and notify maintainers of your reverse dependencies so that they can fix them before a mass bug filing finds the problem. Thanks! cheers, josch Quoting Lucas Nussbaum (2022-07-16 15:23:55) > Source: wayvnc > Version: 0.4.1-1 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220716 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): > > cc -Iwayvnc.p -I. -I.. -I../include -I/usr/include/pixman-1 > > -I/usr/include/libdrm -I/usr/include/p11-kit-1 -fdiagnostics-color=always > > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu11 -O0 > > '-DPROJECT_VERSION="0.4.1"' -D_GNU_SOURCE -DNDEBUG -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ > > wayvnc.p/src_main.c.o -MF wayvnc.p/src_main.c.o.d -o wayvnc.p/src_main.c.o > > -c ../src/main.c > > ../src/main.c: In function ‘init_nvnc’: > > ../src/main.c:504:9: error: too few arguments to function > > ‘nvnc_set_userdata’ > > 504 | nvnc_set_userdata(self->nvnc, self); > > | ^ > > In file included from ../src/main.c:27: > > /usr/include/neatvnc.h:125:6: note: declared here > > 125 | void nvnc_set_userdata(void* self, void* userdata, nvnc_cleanup_fn); > > | ^ > > ../src/main.c:508:9: warning: implicit declaration of function > > ‘nvnc_display_set_render_fn’; did you mean ‘nvnc_display_get_server’? > > [-Wimplicit-function-declaration] > > 508 | nvnc_display_set_render_fn(self->nvnc_display, on_render); > > | ^~ > > | nvnc_display_get_server > > ../src/main.c: In function ‘wayvnc_damage_region’: > > ../src/main.c:578:9: warning: implicit declaration of function > > ‘nvnc_display_damage_region’ [-Wimplicit-function-declaration] > > 578 | nvnc_display_damage_region(self->nvnc_display, damage); > > | ^~ > > ../src/main.c: In function ‘wayvnc_process_frame’: > > ../src/main.c:638:32: error: too few arguments to function ‘nvnc_fb_new’ > > 638 | self->buffer = nvnc_fb_new(width, height, format); > > |^~~ > > In file included from ../src/main.c:27: > > /usr/include/neatvnc.h:144:17: note: declared here > > 144 | struct nvnc_fb* nvnc_fb_new(uint16_t width, uint16_t height, > > | ^~~ > > ../src/main.c:639:17: warning: implicit declaration of function > > ‘nvnc_display_set_buffer’; did you mean ‘nvnc_display_feed_buffer’? > > [-Wimplicit-function-declaration] > > 639 | nvnc_display_set_buffer(self->nvnc_display, > > self->buffer); > > | ^~~ > > | nvnc_display_feed_buffer > > [36/50] cc -Iwayvnc.p -I. -I.. -I../include -I/usr/include/pixman-1 > > -I/usr/include/libdrm -I/usr/include/p11-kit-1 -fdiagnostics-color=always > > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu11 -O0 > > '-DPROJECT_VERSION="0.4.1"' -D_GNU_SOURCE -DNDEBUG -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ > > wayvnc.p/src_seat.c.o -MF wayvnc.p/src_seat.c.o.d -o wayvnc.p/src_seat.c.o > > -c ../src/seat.c > > [37/50] cc -Iwayvnc.p -I. -I.. -I../include -I/usr/include/pixman-1 > > -I/usr/include/libdrm -I/usr/include/p11-kit-1 -fdiagnostics-color=always > > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu11 -O0 > > '-DPROJECT_VERSION="0.4.1"' -D_GNU_SOURCE -DNDEBUG -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ > > wayvnc.p/src_output.c.o -MF wayvnc.p/src_output.c.o.d -o > > wayvnc.p/src_output.c.o -c ../src/output.c > > [38/50] cc -Iwayvnc.p -I. -I.. -I../include -I/usr/include/pixman-1 > > -I/usr/include/libdrm -I/usr/include/p11-kit-1 -fdiagnostics-color=always > > -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=gnu11 -O0 > > '-DPROJECT_VERSION="0.4.1"' -D_GNU_SOURCE -DNDEBUG -g -O2 > > -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat > > -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ > > wayvnc.p/src_screencopy.c.o -MF wayvnc.p/src_screencopy.c.o.d -o > > wayvnc.p/src_screencopy.c.o -c ../src/screencopy.c > > [39/50] cc -Iwayvnc.p -I. -I.. -I../include -I/usr/include/pixman-1 > > -I/usr/include/libdrm -I/usr/include/p11-kit-1 -fdiagnostics-color=always > > -D_FILE_OFFSET_BITS=6
Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory
Hi Andreas, Quoting Andreas Tille (2022-05-04 17:15:49) > > Well, yes, it would be more convenient for me, but you are doing the work, > > so I'm not going to make any demands. :D I think the stronger reason to go > > roll back to dcmtk-3.6.7+really3.6.6 is, that Sebastian Ramacher as a > > release team member pointed out that they would prefer that option. > > I think I'll go that route then (but probably tomorrow). BTW, I had (again) > a look into ants and think the new upstream version can help to fix the > open RC bugs. I once worked on this but at that point of time we did not > yet had insighttoolkit5. Now the issue hopefully boiled down to some issue > I've reported upstream[1]. do you need any assistance? Sebastian Ramacher asked me on IRC about the status of dcmtk and wants to add some blocks on the reverse dependencies so that they don't migrate, should you choose not to revert dcmtk. Thanks! cheers, josch signature.asc Description: signature
Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory
Quoting Andreas Tille (2022-05-04 16:07:27) > I'm an3as in IRC but I do not lurk in IRC usually. Ah, nice word play in the nick. :) > > So it seems that the right way forward would be an upload of > > dcmtk-3.6.7+really3.6.6. > > > > And then not forgetting the Breaks+Replaces from libdcmtk17 on libdcmtk16 (= > > 3.6.7-1) > > Well, I think I could do this in the source only upload. I just pushed that > change to Git[1] to make sure we will not forget this. I think this should be a Breaks+Replaces with exactly version 3.6.7-1. There is no reason to make libdcmtk17 not be co-installable with other versions of libdcmtk16, no? The file-conflict is only with libdcmtk16 (= 3.6.7-1). > Roling back to dcmtk-3.6.7+really3.6.6 would remain an option anyway if this > will be more convenient for you. Well, yes, it would be more convenient for me, but you are doing the work, so I'm not going to make any demands. :D I think the stronger reason to go roll back to dcmtk-3.6.7+really3.6.6 is, that Sebastian Ramacher as a release team member pointed out that they would prefer that option. Thanks! cheers, josch signature.asc Description: signature
Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory
Hi Andreas, Quoting Andreas Tille (2022-05-04 14:57:25) > > Will you take care of making sure that reverse dependencies are binNMU-ed? > > I admit I would use the chance to to real team uploads and check the > other dependencies manually. Your finding with ant makes me suspicious > about some of the other dependencies. However, what do you think about > asking ftpmaster for rejecting what is currently in new, re-upload 3.6.6 > to unstable and do a proper migration via experimental. Currently the > package is sitting in new and we have this chance. Or do you think it > is OK to force this "non-transition" somehow and leave things as they are > now? What does this mean from your blender perspective? I asked in #debian-release and Sebastian Ramacher writes: 15:27 < Sebastinas> libdcmtk17 will also need Breaks+Replaces on the libdcmtk16 version with the .so.17 files. 15:29 < Sebastinas> At least odil is involved in one ongoing transition, so the binNMU for icu may have broken that. 15:29 < Sebastinas> I'd appreciate a revert. So it seems that the right way forward would be an upload of dcmtk-3.6.7+really3.6.6. And then not forgetting the Breaks+Replaces from libdcmtk17 on libdcmtk16 (= 3.6.7-1) Thanks! cheers, josch signature.asc Description: signature
Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory
Hi Andreas, Quoting Andreas Tille (2022-05-04 11:25:20) > Aaargh, sorry for my sloppyness. I did not expect a SONAME bump connected > with micro-Version bump. An updated package is in new. thanks a lot for this very quick fix! I think the problem is that package-name-doesnt-match-sonames is overridden and thus you didn't have Lintian tell you that there was a problem. That would've probably have happened to me as well. Will you take care of making sure that reverse dependencies are binNMU-ed? Thanks! cheers, josch signature.asc Description: signature
Bug#1010536: libdcmimage.so.16: cannot open shared object file: No such file or directory
Hi,
On Tue, 03 May 2022 22:17:24 +0200 Johannes Schauer Marin Rodrigues
wrote:
> thanks for your upload of the new upstream version of dcmtk. Unfortunately,
> I think this is missing a proper transition because the ABI and thus the
> SONAME changed. This can also be seen in the autopkgtests of biosig, odil and
> odin which all fail with a similar error right now:
>
> biosig & odil: ImportError: libdcmdata.so.16: cannot open shared object file:
> No such file or directory
>
> odin: gencoil: error while loading shared libraries: libdcmimgle.so.16:
> cannot open shared object file: No such file or directory
>
> This is because the new upstream version bumped the SONAME from 16 to
> 17. This means, that the binary package name should also change from
> libdcmtk16 to libdcmtk17. This probably would've been caught by
> lintian if package-name-doesnt-match-sonames wasn't overridden in
> debian/libdcmtk16.lintian-overrides... :/
>
> The package should've probably first been uploaded to experimental,
> would go through binary-NEW and create a auto-dcmtk transition. I'm
> unsure how to clean this up now that the package has already been
> uploaded to unstable.
>
> I'm going to rebuild all reverse dependencies and see if anything breaks
> and report back to you in case I find any FTBFS caused by the new dcmtk
> version.
the following source package build depend on libdcmtk-dev:
aeskulap, amide, ants, biosig, cmtk, dicomscope, elastix, insighttoolkit4,
insighttoolkit5, itksnap, mia, odil, odin, openimageio, orthanc, orthanc-wsi,
plastimatch
I cannot test insighttoolkit4 or insighttoolkit5 because my system lacks the
resources to successfully build either source package (No space left on
device).
ants FTBFS but is broken beyond repair and hasn't been in testing since 2017.
itksnap FTBFS for for an unrelated reason (#1010549).
plastimatch FTBFS because of a missing build dependency on
libinsighttoolkit5-dev:
https://buildd.debian.org/status/package.php?p=plastimatch
It seems the new dcmtk version did not just bump ABI but also changed its API
(the DcmTransportLayerStatus enum including TCS_ok was removed from dcmlayer.h
and defining INCLUDE_{CSTRING,CSTDLIB,CSTDIO} now raises an error), so some
patches were necessary:
biosig: #1010545
orthanc: #1010554
Mathieu, since you filed #1010474 (upgrading dcmtk to 3.6.7) could you help
clean this up? For example maybe you find a solution to get orthanc to
successfully compile again (I X-Debbugs-Cc-ed you on the last bug). Currently,
the testsuite fails with:
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libdcmdata.so:
undefined reference to symbol 'inflateEnd'
/usr/bin/ld: /lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing
from command line
collect2: error: ld returned 1 exit status
Which may be something that we have to fix in dcmtk?
Note, that I'm not a Debian Med team member. I'm just putting my time here,
because the last dcmtk upload broke blender (because it depends on openimageio)
which in turn hampers my work on the MNT Reform system image. So for me this is
just one big yak shave...
Thanks!
cheers, josch
signature.asc
Description: signature
Bug#1010554: orthanc: FTBFS with dcmtk >= 3.6.7
Source: orthanc
Version: 1.10.1+dfsg-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: jo...@debian.org, ma...@debian.org
Hi,
orthanc FTBFS with dcmtk 3.6.7 from unstable:
/<>/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp:110:118:
error: ‘TCS_ok’ was
not declared in this scope
110 | if
(tls->addTrustedCertificateFile(trustedCertificatesPath.c_str(),
DCF_Filetype_PEM /*opt_keyFi
leFormat*/) != TCS_ok)
|
^~
/<>/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp:116:104:
error: ‘TCS_ok’ was
not declared in this scope
116 | if (tls->setPrivateKeyFile(ownPrivateKeyPath.c_str(),
DCF_Filetype_PEM /*opt_keyFileFormat*/) !=
TCS_ok)
|
^~
/<>/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp:122:106:
error: ‘TCS_ok’ was
not declared in this scope
122 | if (tls->setCertificateFile(ownCertificatePath.c_str(),
DCF_Filetype_PEM /*opt_keyFileFormat*/)
!= TCS_ok)
|
^~
/<>/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp:135:72:
error: ‘TCS_ok’ was n
ot declared in this scope
135 | if (tls->setTLSProfile(TSP_Profile_BCP195 /*opt_tlsProfile*/) !=
TCS_ok)
|
^~
/<>/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp:140:36:
error: could not convert ‘DcmTLSTransportLayer::activateCipherSuites()()’ from
‘OFCondition’ to ‘bool’
140 | if (tls->activateCipherSuites())
| ~^~
||
|OFCondition
make[4]: *** [CMakeFiles/OrthancFramework.dir/build.make:1941:
CMakeFiles/OrthancFramework.dir/<>/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp.o]
Error 1
The attached debdiff fixes above problem but the testsuite still fails with:
[100%] Linking CXX executable UnitTests
/usr/bin/ld:
/usr/lib/gcc/x86_64-linux-gnu/11/../../../x86_64-linux-gnu/libdcmdata.so:
undefined reference to symbol 'inflateEnd'
/usr/bin/ld: /lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing
from command line
collect2: error: ld returned 1 exit status
Maybe this has to be fixed in dcmtk but I'm not sure. Because my patch
is not complete I'm not tagging this bug with patch.
Thanks!
cheers, josch
diff -Nru orthanc-1.10.1+dfsg/debian/changelog
orthanc-1.10.1+dfsg/debian/changelog
--- orthanc-1.10.1+dfsg/debian/changelog2022-03-23 21:05:58.0
+0100
+++ orthanc-1.10.1+dfsg/debian/changelog2022-05-04 10:13:08.0
+0200
@@ -1,3 +1,10 @@
+orthanc (1.10.1+dfsg-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * add patch to build with dcmtk >= 3.6.7 (closes: #XXX)
+
+ -- Johannes Schauer Marin Rodrigues Wed, 04 May 2022
10:13:08 +0200
+
orthanc (1.10.1+dfsg-1) unstable; urgency=medium
* New upstream version
diff -Nru orthanc-1.10.1+dfsg/debian/patches/dcmtk-3.6.7
orthanc-1.10.1+dfsg/debian/patches/dcmtk-3.6.7
--- orthanc-1.10.1+dfsg/debian/patches/dcmtk-3.6.7 1970-01-01
01:00:00.0 +0100
+++ orthanc-1.10.1+dfsg/debian/patches/dcmtk-3.6.7 2022-05-04
10:13:08.0 +0200
@@ -0,0 +1,40 @@
+--- a/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp
b/OrthancFramework/Sources/DicomNetworking/Internals/DicomTls.cpp
+@@ -107,19 +107,19 @@ namespace Orthanc
+ new DcmTLSTransportLayer(tmpRole /*opt_networkRole*/, NULL
/*opt_readSeedFile*/,
+ OFFalse /*initializeOpenSSL, done by
Orthanc::Toolbox::InitializeOpenSsl()*/));
+
+- if (tls->addTrustedCertificateFile(trustedCertificatesPath.c_str(),
DCF_Filetype_PEM /*opt_keyFileFormat*/) != TCS_ok)
++ if (tls->addTrustedCertificateFile(trustedCertificatesPath.c_str(),
DCF_Filetype_PEM /*opt_keyFileFormat*/).bad())
+ {
+ throw OrthancException(ErrorCode_BadFileFormat, "Cannot parse PEM
file with trusted certificates for DICOM TLS: " +
+trustedCertificatesPath);
+ }
+
+- if (tls->setPrivateKeyFile(ownPrivateKeyPath.c_str(), DCF_Filetype_PEM
/*opt_keyFileFormat*/) != TCS_ok)
++ if (tls->setPrivateKeyFile(ownPrivateKeyPath.c_str(), DCF_Filetype_PEM
/*opt_keyFileFormat*/).bad())
+ {
+ throw OrthancException(ErrorCode_BadFileFormat, "Cannot parse PEM
file with private key for DICOM TLS: " +
+ownPrivateKeyPath);
+ }
+
+- if (tls->setCertificateFile(ownCertificatePath.c_str(),
DCF_Filetype_PEM /*opt_keyFileFormat*/) != TCS_ok)
++ if (tls->setCertificateFile(ownCertificatePath.c_str(),
DCF_Filetype_PEM /*opt_keyFileFormat*/).bad())
+ {
+
Bug#1010549: itksnap: FTBFS because b-d on libvtk6-dev
Source: itksnap Version: 3.6.0-5 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) X-Debbugs-Cc: jo...@debian.org Hi, currently itksnap FTBFS because it B-D on libvtk6-dev which depends on libjsoncpp24: https://qa.debian.org/dose/debcheck/src_unstable_main/latest/packages/itksnap.html Thanks! cheers, josch
