Bug#1071136: O: libopenraw -- free implementation for RAW decoding - development files
Package: wnpp Severity: normal X-Debbugs-Cc: libopen...@packages.debian.org, da...@debian.org Control: affects -1 + src:libopenraw I intend to orphan the libopenraw package. The package description is: libopenraw is an ongoing project to provide a free software implementation for camera RAW files decoding. One of the main reason is that dcraw is not suited for easy integration into applications, and there is a need for an easy to use API to build free software digital image processing application. . It also has the goal to address missing feature from dcraw like meta-data decoding and easy thumbnail extraction. . This package contains development header files.
Bug#1071135: O: jeex -- visual editor to view and edit files in hexadecimal
Package: wnpp Severity: normal X-Debbugs-Cc: j...@packages.debian.org, da...@debian.org Control: affects -1 + src:jeex I intend to orphan the jeex package. The package description is: Jeex is a simple hexadecimal editor which allows user to create, open and edit files in hexadecimal, binary, octal and ASCII. The features include insert, delete, copy-and-paste, search and many others. . It also shows several information about the opened file, like file mode bits, ownership, last access and modification timestamps.
Bug#1071134: O: gmtkbabel -- graphical interface for mtkbabel
Package: wnpp Severity: normal X-Debbugs-Cc: gmtkba...@packages.debian.org, da...@debian.org Control: affects -1 + src:gmtkbabel I intend to orphan the gmtkbabel package. The package description is: gmtkbabel consists of a set of shell scripts which use zenity to provide a graphical user interface to mtkbabel. Mtkbabel is a command-line tool to operate GPS-unit with MTK (Mediatek) chipsets.
Bug#1071120: birthday: Birthday doesn't work with my usual .birthdays file anymore
Package: birthday Version: 1.6.2-4.1 Severity: important Dear Maintainer, Birthday doesn't work anymore with my .birthdays file without giving any error or warning message. I include the file for showing that it has no malformed lines. It worked until now, I don't know when has broken. File .birthdays: - David=29/7/1972 bd Alexia=29/11/1974 bd Jennifer=4/4/1983 bd Cristina=5/4/1975 bd Gissela=28/09/1983 bd Papá=23/09/1945 bd Miguelón=30/07/1973 bd Yen=30/07/1972 bd Marga=26/06/1982 bd Pablo=11/11/1982 bd Juan Carlos=27/12/1972 bd Carmen=15/06/1987 bd # Eventos Diabetología Pontones 9:30 en C.E.P de Argüelles=02/07/2024 ev Oftalmología Pontones 9:40=31/01/2025 ev Dermatología Pontones 10:45 3ª planta=03/02/2025 ev Dentista 11:00=16/04/2024 ev Enfermera tiras 11:20=06/05/2024 ev Dermatología Díaz 1ª planta, 10:17=16/01/2024 ev Devolver libros BIBLIOTECA=23/04/2024 ev Inspección instalación de gas 11:00-13:00=03/07/2024 ev -- Greets. -- David -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.7.12-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages birthday depends on: ii libc6 2.38-10 Versions of packages birthday recommends: ii perl 5.38.2-4 birthday suggests no packages. -- no debconf information
Bug#1070959: /usr/lib/riscv64-linux-gnu/libapt-pkg.so.6.0.0: apt: riscv64: sun20i-d1: http(s): unhandled signal 4 code 0x1 in libapt-pkg.so.6.0.0
Hi, On Sun, May 12, 2024 at 12:13:11AM +0200, scpcom wrote: > When I run apt-get update on Allwinner D1 Nezha hardware I get the following > errors: > > [ 1610.448999] http[1575]: unhandled signal 4 code 0x1 at 0x003fa43ee5f8 > in libapt-pkg.so.6.0.0[3fa4326000+19c000] > [ 1610.459512] CPU: 0 PID: 1575 Comm: http Not tainted 6.6.29+sun20i #sun20i > [ 1610.466313] Hardware name: Allwinner D1 Nezha (DT) > [ 1610.471109] epc : 003fa43ee5f8 ra : 003fa43ee5f8 sp : > 003fc95c63d0 > [ 1610.478337] gp : 002ae3eca800 tp : 003fa35a0780 t0 : > 000a > [ 1610.485563] t1 : b8fa9f1e0b81022a t2 : 0064 s0 : > 002ae95abe00 > [ 1610.492789] s1 : a0 : 002ae95a5f80 a1 : > > [ 1610.500014] a2 : 002ae9565020 a3 : a4 : > 0001 > [ 1610.507239] a5 : 0001 a6 : 002ae95a1590 a7 : > 144ef8bcb0a5ab57 > [ 1610.514465] s2 : 003fa3df9618 s3 : 002ae3eca0a0 s4 : > > [ 1610.521691] s5 : 002ae959bda0 s6 : 002ae3eca0a0 s7 : > 003fc95c6d48 > [ 1610.528917] s8 : 003fc95c6d58 s9 : 003fc95c6690 s10: > 002ae9582730 > [ 1610.536144] s11: 003fa44ffd18 t3 : 003fa3d167cc t4 : > 003a > [ 1610.543371] t5 : 0001 t6 : 005c > [ 1610.548688] status: 00024020 badaddr: 833f cause: > 0002 > [ 1610.563819] https[1574]: unhandled signal 4 code 0x1 at 0x003fa5b155f8 > in libapt-pkg.so.6.0.0[3fa5a4d000+19c000] > [ 1610.574420] CPU: 0 PID: 1574 Comm: https Not tainted 6.6.29+sun20i #sun20i > [ 1610.581307] Hardware name: Allwinner D1 Nezha (DT) > [ 1610.586102] epc : 003fa5b155f8 ra : 003fa5b155f8 sp : > 003fd7b3b3c0 > [ 1610.593329] gp : 002ac54c6800 tp : 003fa4cc6780 t0 : > 000a > [ 1610.600554] t1 : b8fa9f1e0b81022a t2 : 0064 s0 : > 002ad80d4e40 > [ 1610.607780] s1 : a0 : 002ad80cefc0 a1 : > > [ 1610.615006] a2 : 002ad808e018 a3 : a4 : > 0001 > [ 1610.622233] a5 : 0001 a6 : 002ad80d2bc0 a7 : > 6fd82bd679d27ec2 > [ 1610.629458] s2 : 003fa5796618 s3 : 002ac54c60a0 s4 : > > [ 1610.636686] s5 : 002ad80d5540 s6 : 002ac54c60a0 s7 : > 003fd7b3bd38 > [ 1610.643912] s8 : 003fd7b3bd48 s9 : 003fd7b3b680 s10: > 002ad80ab730 > [ 1610.651138] s11: 003fa5c26d18 t3 : 003fa56b37cc t4 : > 003a > [ 1610.658363] t5 : 0001 t6 : 005c > [ 1610.663680] status: 00024020 badaddr: 833f cause: > 0002 > > The problem seems to exists since mid 2023. > On Ubuntu 23.04 there is no error. > I got the error on Ubuntu 23.10, 24.04 and latest Debian unstable. > The error only shows up on the real hardware and not inside a chroot > (qemu-user-static riscv64 image on amd64 hardware). > >* What exactly did you do (or not do) that was effective (or > ineffective)? > > I build apt 2.9.2 from sources on Ubuntu 23.04 and installed the resulting > libapt-pkg6.0t64 deb on Debian unstable which temporairly solved the problem. > > It looks like a toolchain issue and apt may not be the only affected packge > (I have seen the same "unhandled signal 4 code 0x1" on libvte) This does indeed sound like a toolchain issue given different versions behave differently and unrelated (to apt) things have the same issue, so I am "soft-reassigning" this to riscv64 porters in the hope they will know where to assign and deal with this as libapt seems not a good place for that as I have quite literally no idea about riscv64… Installing -dbgsym packages and getting a corefile might be helpful. I note that you haven't provided much detail on your apt setup, but given the crash says `http` (and `https`) it might be helpful to get a simpler reproducer than "ran some apt command": Do you have the same problem with e.g.: /usr/lib/apt/apt-helper download-file 'http://example.org/' /tmp/example.html -o Debug::Acquire::http=1 or can you reproduce it with another URI? One from `apt update --print-uris` perhaps? If you can, it is possible to talk to `/usr/lib/apt/methods/http` directly on stdin to might have an easier time debugging this. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#839546: apt upgrade wants to install packages that apt autoremove will remove
On Mon, May 13, 2024 at 04:19:53PM +1200, Olly Betts wrote: > On Sat, Oct 01, 2016 at 11:15:28PM +0300, Sami Liedes wrote: > > apt upgrade lists some packages as new packages that will be > > installed, but at the same time lists those packages as "automatically > > installed and no longer required". > [...] > > Note that all of the NEW packages that will be installed are also in > > the autoremoveable list (contrary to what apt says, those packages are > > not yet installed). > > I'm seeing what appears to be the same problem, so this bug still seems > to be present: Possible, although its hard to say as the reason is hard to pin point from the provided output alone. As an example, the just released 2.9.3 actually includes a fix which has the same output – but I doubt its the same issue as I couldn't spot an offending Recommends so far: https://salsa.debian.org/apt-team/apt/-/commit/e099ee946000797f4c03b8c5075ce7ebba193337 I don't see too much that screams at me, although that all of them are t64 might be related to Provides shenanigans. As hinted in the commit message, its sadly not as easy as just not installing them all if they are new, so this code is a bunch of rarely fully engaged guess work. > If there's stuff I can usefully prod to help debug what's causing this > please let me know. It would help if you could share `/var/lib/dpkg/status` and `/var/lib/apt/extended_states` – both together resemble your exact system state, so if you don't want to share them publicly, you could sent them to me privately. Ideally you also run `apt upgrade -s -o dir::log::solver=/tmp/solver.edsp.xz` and keep the resulting /tmp/solver.edsp.xz file for now. This one includes the two former files as well as info about all packages available to you at this moment in case this is repository state dependent which it might be… but its a big file even compressed and a bit unwieldy to deal with in autoremove-debugging, so I hope not. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1070970: O: fuseiso -- FUSE module to mount ISO filesystem images
Package: wnpp Severity: normal X-Debbugs-Cc: fuse...@packages.debian.org, da...@debian.org Control: affects -1 + src:fuseiso I intend to orphan the fuseiso package. The package description is: This package provides a module to mount ISO filesystem images using FUSE. With FUSE it is possible to implement a fully functional filesystem in a userspace program. . It can also mount single-tracks .BIN, .MDF, .IMG and .NRG.
Bug#1070969: O: ditaa -- convert ASCII diagrams into proper bitmap graphics
Package: wnpp
Severity: normal
X-Debbugs-Cc: di...@packages.debian.org, da...@debian.org
Control: affects -1 + src:ditaa
I intend to orphan the ditaa package.
The package description is:
DiTAA is a small command-line utility that can convert diagrams drawn using
ASCII art ("drawings" that contain characters that resemble lines, like | /
and -), into proper bitmap graphics.
.
DiTAA also uses special markup syntax to increase the possibilities of shapes
and symbols that can be rendered.
Bug#1070968: O: cutycapt -- utility to capture WebKit's rendering of a web page
Package: wnpp Severity: normal X-Debbugs-Cc: cutyc...@packages.debian.org, da...@debian.org Control: affects -1 + src:cutycapt I intend to orphan the cutycapt package. The package description is: CutyCapt is a small cross-platform command-line utility to capture WebKit's rendering of a web page into a variety of vector and bitmap formats, including SVG, PDF, PS, PNG, JPEG, TIFF, GIF, and BMP.
Bug#1070967: O: comparepdf -- command line tool for comparing two PDF files
Package: wnpp Severity: normal X-Debbugs-Cc: compare...@packages.debian.org, da...@debian.org Control: affects -1 + src:comparepdf I intend to orphan the comparepdf package. The package description is: comparepdf is a command line tool for comparing two PDF files. . By default it compares their texts but it can also compare them visually (e.g., to detect changes in diagrams, images, fonts, and layout). . It should prove useful for automated testing.
Bug#1070966: O: codfis -- tool to generate Italian fiscal codes (codice fiscale)
Package: wnpp Severity: normal X-Debbugs-Cc: cod...@packages.debian.org, da...@debian.org Control: affects -1 + src:codfis I intend to orphan the codfis package. The package description is: CodFis is a tool to generate Italian fiscal codes (codice fiscale) given name, surname, gender, date and place of birth. . Note that the official fiscal codes are only those assigned by Agenzia delle Entrate (which may be different from those generated by this tool in some special cases).
Bug#1070875: glibc: FTBFS on hppa - Encountered regressions that don't match expected failures
Source: glibc Version: 2.38-10 Severity: normal Tags: ftbfs Dear Maintainer, The following tests are known to fail on hppa when glibc is built with gcc-13 or later: FAIL: math/test-double-fma FAIL: math/test-double-ldouble-fma FAIL: math/test-float32x-float64-fma FAIL: math/test-float32x-fma FAIL: math/test-float64-fma FAIL: math/test-ldouble-fma The tests do not fail when glibc is built with gcc-12. See following gcc bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709 Full build log is here: https://buildd.debian.org/status/fetch.php?pkg=glibc=hppa=2.38-10=1715383873=0 Things get worse with gcc-14. I suspect this is an issue with nan representation. Please change the above tests to xfails. Thanks, Dave Anglin -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 6.1.90+ (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1070763: libyang2-dev needs move of header file for multi-arch compatibility
Package: libyang2-dev Version: 2.1.148-0.1 Severity: wishlist Tags: patch Hi all, the libyang2-dev package currently can't be installed in parallel for multi-arch build environments with mixed 32-bit and 64-bit architectures. The reason for this is that the content of /usr/include/libyang/config.h depends on the sizes of some types. Attached is a patch to move that file to /usr/include//libyang. This enables cross-compiling setups where libyang is needed on both build and host architectures. Cheers, equi diff -ur libyang2-2.1.148/debian/libyang2-dev.install libyang2-2.1.148/debian/libyang2-dev.install --- libyang2-2.1.148/debian/libyang2-dev.install2023-02-01 10:12:00.0 +0100 +++ libyang2-2.1.148/debian/libyang2-dev.install2024-05-08 17:25:49.081859201 +0200 @@ -1,3 +1,4 @@ usr/include/libyang/*.h +usr/include/*/libyang/*.h usr/lib/*/*.so usr/lib/*/pkgconfig/*.pc diff -ur libyang2-2.1.148/debian/rules libyang2-2.1.148.new/debian/rules --- libyang2-2.1.148/debian/rules 2023-02-01 10:12:00.0 +0100 +++ libyang2-2.1.148/debian/rules 2024-05-08 17:44:20.504783204 +0200 @@ -11,3 +11,11 @@ dh_auto_configure -- \ -DCMAKE_BUILD_TYPE:String="Release" \ -DENABLE_TESTS=ON + +override_dh_auto_install: + dh_auto_install + mkdir -p debian/tmp/usr/include/$(DEB_HOST_MULTIARCH)/libyang + mv debian/tmp/usr/include/libyang/config.h \ + debian/tmp/usr/include/$(DEB_HOST_MULTIARCH)/libyang + sed -e 's%#include "config\.h"%#include %' -i \ + debian/tmp/usr/include/libyang/*.h
Bug#1069265: tzdata: Upgrade from 2023c-2 to 2024 corrupts zoneinfo files
On Thu, 18 Apr 2024 23:39:14 + IvanAbs wrote: > On 2024-04-17 several of my servers running Debian 10 received an > update for the tzdata package via Debian unattended-upgrade. However, > this update resulted in corruption of files within the > /usr/share/zoneinfo directory. I, too, encountered a variation of this issue today while trying to update the tzdata package on my system. I was eventually able to resolve the issue with a little manual intervention. Details follow. > I was using tzdata 2023c-2 package, and originally installed from an > official Debian source In my case, the installed version of the package was tzdata 2023c-5. > I installed tzdata 2023c-2 with dpkg -i, because our severs needs the > last-year updated data, but there were not a release for Debian 10, > until yesterday. Similarly, I had installed tzdata 2023c-5 on what is effectively Debian Bullseye install (though what is actually an unabashed FrankenDevuan install that is mostly composed of packages from Devuan's Chimaera release). My motivation for doing so was similar: I wanted the then-current timezone database and the package in chimaera/bullseye had yet to be updated. I fully acknowledge this course of action is actively frowned upon[1]. [1] https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian > To resolve this issue, I had to completely remove the tzdata 2023 > version and perform a clean installation of the new tzdata 2024 > version. Here's how I was able to resolve the issue. Using snapshot.debian.org, I downloaded tzdata_2023d-1_all.deb which installed without issue over 2023c-5. Afterward, I was able to install tzdata 2024a-0+deb11u1 without issue. As this issue only manifests on systems in explicitly unsupported configurations, the severity of the bug should probably be reduced from grave, but I will leave that decision to others. I hope this was helpful, -- Plasma
Bug#1070405: darktable: Please drop unused Build-Depends: libsoup2.4-dev
Jeremy Bícha writes: > Source: darktable > Version: 4.6.1-2 > > Please drop Build-Depends: libsoup2.4-dev . It isn't used at all and > we would eventually like to remove libsoup2.4 from Debian. > > Thank you, > Jeremy Bícha How can I verify that it is not used? d
Bug#1070645: libavif: Please remove dependency on libgav1 on big-endian architectures
Source: libavif Version: 1.0.4-2 Severity: normal Tags: ftbfs Dear Maintainer, libgav1 is broken on big-endian targets. See this bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068583 As a result, libavif no longer builds on hppa and other big-endian architectures which depend on libgav1. This blocks building glibc: https://buildd.debian.org/status/package.php?p=glibc=sid Regards, Dave Anglin -- System Information: Debian Release: trixie/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 6.1.90+ (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system)
Bug#1006889: frr / bgp failing to insert routes on boot (usually ipv6, sometimes ipv4)
Hi Nick, (first of all, sorry, I kinda blanked out this bug report for some time, see below for why) On Mon, Mar 07, 2022 at 06:16:03PM +, Nick wrote: [...] >Because of the above, I checked out >/etc/systemd/system/multi-user.target.wants/frr.service and found >that it is set to start with 'After=network-pre.target'. I replaced >Wants= and After= with 'network-online.target' and removed Before= >entirely. > >* What was the outcome of this action? > >Having modified the systemd start script, routes are always inserted >on boot! [...] The problem with this is that while this fixes your specific scenario, it also breaks other users' setups since network-online.target itself is on occasion made to depend on frr.service, which would now create a loop. Further, the issue you're seeing is specific to your configuration with these two route-maps: [...] > route-map RM_SET_SRC permit 10 > set src 25.0.1.1 > ! > route-map RM_SET_SRC6 permit 10 > set src :f0a1::1 [...] You're correct to observe that these require the interface that owns these IP addresses to be up and configured before they can take effect, and the kernel will reject them otherwise. zebra's behavior on this is... call it "suboptimal" in not retrying the install; however the behavior of FRR is designed against a limitation of "normal" policy setups. route-maps, especially in zebra, are essentially code, and there are *lots* of possibilities to create edge cases or non-working setups. In your specific setup, the "FRR recommended practice" would be: add both of these IP addresses (25.0.1.1 and XYZ:f0a1::1) as /32 / /128 to your loopback interface. This will ensure they are always available. (This is generally recommended for a router's primary addresses.) Alternatively, your fix in editing the dependency is also viable, assuming you don't need to deal with cases where the interface or addresses go away and come back. I can't incorporate it into the package though because it is specific to your situation. Sorry, I'm not sure there is anything else I can do here, equi (David)
Bug#1070431: bookworm-pu: package php-composer-pcre/3.1.0-1+deb12u1
Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: php-composer-p...@packages.debian.org
Control: affects -1 + src:php-composer-pcre
Hi,
While fixing CVE-2024-24821 in composer in the recent DSA-5632-1, code
from php-composer-pcre has been backported in the Bullseye version of
composer. Because of that, php-composer-pcre now needs a Breaks+Replaces
against composer (<< 2.2) as advised by Andreas Beckmann in #1070423.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
Thanks in advance.
Regards,
taffit
diff -Nru php-composer-pcre-3.1.0/debian/changelog
php-composer-pcre-3.1.0/debian/changelog
--- php-composer-pcre-3.1.0/debian/changelog2022-11-21 20:13:56.0
+0100
+++ php-composer-pcre-3.1.0/debian/changelog2024-05-05 11:08:20.0
+0200
@@ -1,3 +1,11 @@
+php-composer-pcre (3.1.0-1+deb12u1) bookworm; urgency=medium
+
+ * Track bookworm
+ * Add missing Breaks+Replaces: composer (<< 2.2)
+Thanks to Andreas Beckmann (Closes: #1070423)
+
+ -- David Prévot Sun, 05 May 2024 11:08:20 +0200
+
php-composer-pcre (3.1.0-1) unstable; urgency=medium
[ Jordi Boggiano ]
diff -Nru php-composer-pcre-3.1.0/debian/control
php-composer-pcre-3.1.0/debian/control
--- php-composer-pcre-3.1.0/debian/control 2022-11-05 08:54:58.0
+0100
+++ php-composer-pcre-3.1.0/debian/control 2024-05-05 11:08:20.0
+0200
@@ -10,7 +10,7 @@
Standards-Version: 4.6.1
Homepage: https://github.com/composer/pcre
Vcs-Browser: https://salsa.debian.org/php-team/pear/php-composer-pcre
-Vcs-Git: https://salsa.debian.org/php-team/pear/php-composer-pcre.git
+Vcs-Git: https://salsa.debian.org/php-team/pear/php-composer-pcre.git -b
debian/bookworm
Rules-Requires-Root: no
Package: php-composer-pcre
@@ -19,8 +19,10 @@
Depends: ${misc:Depends}, ${phpcomposer:Debian-require}
Recommends: ${phpcomposer:Debian-recommend}
Suggests: ${phpcomposer:Debian-suggest}
-Replaces: ${phpcomposer:Debian-replace}
-Breaks: ${phpcomposer:Debian-conflict}, ${phpcomposer:Debian-replace}
+Replaces: composer (<< 2.2), ${phpcomposer:Debian-replace}
+Breaks: composer (<< 2.2),
+${phpcomposer:Debian-conflict},
+${phpcomposer:Debian-replace}
Provides: ${phpcomposer:Debian-provide}
Description: ${phpcomposer:description}
This library gives you a way to ensure `preg_*` functions do not fail
diff -Nru php-composer-pcre-3.1.0/debian/gbp.conf
php-composer-pcre-3.1.0/debian/gbp.conf
--- php-composer-pcre-3.1.0/debian/gbp.conf 2021-12-09 12:43:32.0
+0100
+++ php-composer-pcre-3.1.0/debian/gbp.conf 2024-05-05 11:08:20.0
+0200
@@ -1,5 +1,5 @@
[DEFAULT]
-debian-branch = debian/latest
+debian-branch = debian/bookworm
filter = [ '.gitattributes' ]
pristine-tar = True
upstream-branch = upstream/latest
Bug#1068583: libgav1: FTBFS on s390x: test failures
Adding architecture-is-little-endian to build dependency is not a good solution as this blocks building glibc on big endian targets: https://buildd.debian.org/status/package.php?p=glibc=sid Regards, Dave Anglin -- John David Anglin dave.ang...@bell.net
Bug#1070329: [borg mount] fuse: failed to exec fusermount3: No such file or directory
Package: borgbackup Version: 1.2.4-1 When I tried to use `borg mount`, it gave the error "fuse: failed to exec fusermount3: No such file or directory". The package recommends fuse, but installing fuse3 instead seemed to fix the error. Should the package recommend fuse3 instead of fuse?
Bug#990451: apt: the --no-all-versions option not working as documented
On Thu, May 02, 2024 at 12:40:30PM +0200, Manny wrote:
> Note that “-o APT::Cache::AllNames=false” is used in vain (it has no
> effect but at least it does not interfere either). The work of
I think you meant All*Versions*, not Names. The later is documented to
effect `pkgnames` only. In some way, AllVersions is documented to effect
`show`, but much less specific by "full records" – a record is what show
displays and policy doesn't, but yeah, not really discoverable.
> It would be nice if I could also get a total size on any files to be
> fetched. My knee-jerk thought would be to filter on all packages that
> are not sourced from file:/local/filesystem, run apt-cache on that
> subset to get full URLs, then do something like:
>
> apt-cache show "$pkg" | awk '/^Size/{print $2}'
>
> Anyway, the low-effort fix would be to at least update the man page to
> state the narrow availability of --no-all-versions. Though it would be
> useful if it worked for policy.
>
> In light of my use case, you could also say it’s already hacking
> territory that apt-cache was needed at all. In principle, aptitude’s
> installer output of how much data will be fetched should give a
> breakdown of data volume to be fetched from each source location,
> perhaps when run in a verbose mode.
fwiw: I don't know about aptitude and if you think it should get some
feature I suppose you should report it there, but for apt(-get) I have
to note that both display "download size" as the size of all *.deb
files to be downloaded from non-local (that mostly means non-file:/)
sources…
They do this mostly to check if the free disk space is large enough to
hold the debs to download (while file:/ are used from there they are),
but that is close at least to your knee-jerk thought.
Not sure about the later "each source location"… that can turn out to be
a lot of details for not that much gain: a typical Debian stable has
'normal', 'updates' and 'security'. You could add 'proposed' and e.g.
'backports' and a random set of 3rd parties like the typical Ubuntu user
with seemingly 42+ PPAs added. That is 3+X counters useless even to you
as you were just interested in the data coming from your local mirror
vs. others. And that would assume that all mirrors are complete and
available, no retries, no fallbacks, no redirects.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Bug#1068953: new upstream (10.0)
I've managed to get sbuild crosscompile to work for hppa and found the problem (it's a missing "XREF_SETUP()" line, not that the error message would give any hint to that...) With that, I have 4 things to fix in the package: - postrm is missing cleanup for /var/lib/frr (piuparts failure) - stick in that missing line for hppa - drop the (BD-Uninstallable) libunwind dep on alpha,m68k,sparc64,x32 - the watch expression is a bit shit I'll put a -2 together later today. (ia64 is also failing build, but that very much looks like a general ia64 problem, not some FRR breakage.)
Bug#1070189: ITP: gnome-shell-extension-happy-appy-hotkey -- Hotkey application focus / launcher for GNOME Shell
Package: wnpp Severity: wishlist Owner: David Edmondson X-Debbugs-Cc: debian-de...@lists.debian.org, d...@dme.org * Package name: gnome-shell-extension-happy-appy-hotkey Version : 8 Upstream Contact: Jan Ouwens * URL : https://github.com/jqno/gnome-happy-appy-hotkey/ * License : GPL3 Programming Lang: Javascript Description : Hotkey application focus/launch extension for GNOME Shell > Assign hotkeys to applications to give them focus or launch them > > Features: > - Assign a hotkey to an app to: > - Give it focus if it's already running, or > - Launch it if it's not. > - Assign a hotkey to cycle through all the apps that don't have a hotkey > - Optionally restrict hotkeys to current workspace > - Supports Wayland
Bug#1067077: frr: FTBFS on armel: /usr/bin/ld: ./build/../bgpd/bgp_io.c:476:(.text+0x51c): undefined reference to `__atomic_store_8'
On Mon, Apr 29, 2024 at 06:05:08PM +0200, Daniel Baumann wrote: > my initial attempt in 10.0-0.2 to link with libatomic didn't work, I've > fixed that locally but a build to confirming on an armel porterbox is > runnning before uploading 10.0-0.3 in some minutes.. I've synced in (all of) your changes, merged debian/ changes from upstream (used to build CI packages), and then flipped libatomic to be linked unconditionally. I was able to reproduce the linking problem with "sbuild --host=armel --build=amd64", it wasn't working before and is working now. (And linking libatomic didn't break amd64, i686 or arm64.) => https://github.com/FRRouting/frr/commits/debian/master/ Do you want to do anything else with it or should I go mark it as -1? Cheers, -equi
Bug#895897: Further comments on apt purge
On Mon, Apr 29, 2024 at 04:16:14PM -0700, Andrew Athan wrote: > Note that > > apt purge ~c > > does something, but apt(8) does not mention the support for the ~c > parameter. It is relatively new and part of the aptitude-pattern backport. See apt-patterns(7). > On my system, it seems to be attempting to remove all packages that have the > "c" second character status in dpkg -l. Unfortunately, this includes > packages such as "locales" which I think are normally "ic", so this command > does not seem appropriate for removing "rc" packages as suggested elsewhere. A package is not "normally" 'ic'… that is your "desire" who made it so. As "dpkg -l" documents itself at the top, the first letter is a desired state, while the second is current status (and the third if present indicates an error state that is worse than the "normal" error states). So, 'rc' expresses the desire for the package to be removed and the current status is "removed, but not purged (conf-files remaining)". You could set it to 'pc' (to desire a purge) or like you did to 'ic', which would mean you desire it to be installed (again). Note that this "desire" is something used by dpkg/dselect and to some extend aptitude, but most (other) libapt-based tools including apt(-get) do not really work with it (except in fringe use cases like apt-get dselect-upgade) and/or internally while talking to dpkg. They prefer to receive the users desire directly on the command line if you want to interpret it this way. So, yes and no, ~c does indeed match 'ic' as well as 'rc', but that is because it looks at the current state – which is the same for them all, they only have conf-files remaining. Specifically, as you seem to think otherwise: "locales" in state 'ic' is not installed and behaves exactly like in state 'rc' – as in, they don't have a behaviour at all. If you want it to be installed, just install it and it will have the state 'ii'. Or purge it and it will be 'un'. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068953: new upstream (10.0)
On Mon, Apr 29, 2024 at 06:46:00PM +0200, Daniel Baumann wrote: > On 4/29/24 18:31, David Lamparter wrote: > > Did you run into issues that forced you up to 2.1.148? The "officially > > listed" (= in configure.ac) requirement is 2.1.128, if we(upstream) > > missed something I'd look into getting that listed minimum bumped up > > too. > > Rechecking the frr 10 announcement.. says indeed 2.1.128 not 2.1.148. > totally my fault, I'm very sorry about that! Ok, all good then, just wanted to confirm. > (I'm running frr 10 with 2.1.148 here since some days now with no issues > though) I would really hope that a newer version works... generally the libyang folks have been pretty good about not breaking compatibility, though there was one issue: https://github.com/CESNET/libyang/issues/2090 (=> 2.1.111 is "known bad") > > Is there some way to debug this? > > You can ask for (hppa) porterbox access; accounts to porterboxes are > given to non-DD/DMs too: > >https://dsa.debian.org/doc/guest-account/ > > If you send me the data requested there, I'll sign it so you can get access. Ok, for the time being I've instead decided to use this as a kick in my ass to finally do the NM procedure to become a Debian Maintainer... https://nm.debian.org/process/1284/ I have no idea what kind of timescale that works on, but I probably can't get to hppa debugging right off anyway - worst case I'd ping you later? Thanks, -equi
Bug#1002056: ITP: zlib-ng -- optimized zlib compression library
Hello, I think it already makes sense to push zlib-ng and let it co-exist with zlib since you can port your software directly to the zlib-ng, which I'm currently doing for Mesa3D. I dropped the zlib-ng sources into https://salsa.debian.org/dh/zlib-ng feel free to force push there any Debian relevant changes. After introducing the zlib-ng, we could continue to the second phase migrating software still relying on zlib to zlib-ng compat layer. What do you think? David On Mon, 6 Nov 2023 21:44:05 +0100 Sebastian Andrzej Siewior wrote: > On 2023-10-25 23:17:06 [+0200], Guillem Jover wrote: > > Hi! > Hi, > > > Ah, thanks! I had in my mind getting back to this ITP, given that the > > zlib-ng project has continued to gain traction and seems to have > > consolidated most of the other forks around it. > > > > So I'll draft another mail to Mark and probably to debian-devel to > > discuss this. > > Do you want me to join your efforts? This looks interrestig. I may have > time ;) > > > Thanks, > > Guillem > > Sebastian > > -- David Heidelberg
Bug#1068953: new upstream (10.0)
Quick offshoot mail on build details, ... On Mon, Apr 29, 2024 at 06:13:14PM +0200, Daniel Baumann wrote: > On 4/29/24 16:56, David Lamparter wrote: > > FRR definitely requires libyang 2.1.128. > > hm, frr 10 needs libyang2 2.1.148. Did you run into issues that forced you up to 2.1.148? The "officially listed" (= in configure.ac) requirement is 2.1.128, if we(upstream) missed something I'd look into getting that listed minimum bumped up too. > > There's also a bit of a problem in #1067077 > > I've fixed that already, just waiting some more minutes on the build to > finish on the armel porterbox. I'll throw that upstream as well when I see it in your 0.3, Thanks! Also, apropos porterbox, I have no way of debugging the hppa build problem that has been there in 9.1 already; FRR does some "slightly cursed" things that have python code figuring out C struct sizes that seems to be going wrong. Is there some way to debug this? Cheers, -equi
Bug#1068953: new upstream (10.0)
Hi Daniel, On Sun, Apr 14, 2024 at 08:40:29AM +0200, Daniel Baumann wrote: > it would be nice if you could upload the newly released frr version. If > you need/want help, I'm happy to do so, just let me know. Sorry about this... I've tried to improve this before, this problem is social in nature in that I can't do uploads myself (not a DM/DD) and unfortunately due to personal conditions the cost in "brain energy" to do these interactions is... massive. I see you've uploaded an FRR and libyang package. I can't speak to libyang2 at all, but (you probably saw) FRR definitely requires libyang 2.1.128. Finding some solution for libyang2 is presumably a similar problem, just with someone else ;). Other than this, there are in fact updates to the debian/ directory in FRR's master branch. One thing that stood out to me is the missing "mkdir /var/lib/frr" in postinst. I really need to merge master back into the debian branches on the FRR repo to pick that up, I can probably get to that today or tomorrow. There's also a bit of a problem in #1067077, which is caused by the 64-bit time_t transition. I'm not sure what the solution for that will be, but it's a blocker since armel is affected and that's still a mainline Debian arch... Cheers (& Apologies), -equi (David)
Bug#1067077: atomic operations on 64-bit time_t
On Mon, Mar 18, 2024 at 12:42:56AM +0100, Sebastian Ramacher wrote: > Source: frr > Version: 9.1-0.1 > Justification: fails to build from source (but built successfully in the past) [...] > https://buildd.debian.org/status/fetch.php?pkg=frr=armel=9.1-0.1=1710631814=0 [...] > ./build/../bgpd/bgp_vty.c:13678:(.text+0x1d934): undefined reference to > `__atomic_load_8' [...] This is due to FRR using "_Atomic time_t", which ... with the 64-bit time_t transition is now 8 bytes, and armel, hppa, m68k, powerpc and sh4 can't do 64-bit atomic ops... I'm not sure what the best fix for this is, I looked at https://wiki.debian.org/ReleaseGoals/64bit-time but there is no mention of atomic ops on time_t. Googling didn't yield anything either. Is frr the only package using "_Atomic time_t"? Input appreciated... -equi (David)
Bug#1069549: racket: FTBFS on armel: dh_install: error: missing files, aborting
Control: severity -1 important > Source: racket > Version: 8.12+dfsg1-7 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel OK, I figured out why this doesn't show up on the buildd's: they don't build the arch all packages on armel. For many years, armel hasn't been able to build the documentation for racket, and it has been disabled there. After some informal consultation with the release team I'm downgrading this bug to non-RC. I'll work on having more clear diagnostics for the build failure. I don't know how common this scenario is, but it might make sense to restrict such rebuilds to arch:any on armel (and armhf), depending on your goals of course.
Bug#1069874: E: Problem parsing Provides line of perccli:all=007.2616.0000.0000
On Fri, Apr 26, 2024 at 08:30:42AM +0200, Harald Dunkel wrote: > If I put Dell's current debian package for perccli into my local > reprepro, then "apt update" complains Oh boy, that is some heavy package… and that not only because it claims to be 7GB large… I think the producer of that package meant 7 MB, but didn't realize that Installed-Size is in KiB, not Bytes. Anyway, this control file is not produced by dpkg-gencontrol; that wouldn't include bogus empty lines, too. Maybe you can get them to fix their package and in that process also clean it up… if they insist on producing it by hand. > E: Problem parsing Provides line of perccli:all=007.2616.. > E: Error occurred while processing perccli (NewVersion2) > E: Problem with MergeList > /var/lib/apt/lists/debian.ac.aixigo.de_debian_dists_bookworm-experimental_main_binary-amd64_Packages > E: The package lists or status file could not be parsed or opened. Seems like this was simple enough to "fix" in libapt code… https://salsa.debian.org/apt-team/apt/-/commit/c98bcdf00e5366fec101dd17094d36be21872a02 I would still advice to fix the package as this is somewhat unlikely to reach users 'soon' (with trixie of course, but I doubt that gets backports into oblivion). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1069828: [debian trixie] [package procps] w segmentation fault
Package: procps Version: 2:4.0.4-4 Hello, it seems there is a bug in the debian package "procps" with the "w"utility. it produce a segfault when using the "-s" argument. I tried download and compile from source, and the bug is not present. it is only present with the debian system package (debian trixie). david@debian12:~/procps/procps-4.0.4/src$ ./w -s 00:10:33 up 53 min, 1 user, load average: 0,47, 0,64, 0,64 USER TTY IDLE WHAT davidtty7 53:23 xfce4-session david@debian12:~/procps/procps-4.0.4/src$ w -s 00:10:38 up 53 min, 1 user, load average: 0,43, 0,63, 0,64 UTIL.TTY DEIDLE QUOI Erreur de segmentation david@debian12:~/procps/procps-4.0.4/src$ uname -a Linux debian12 6.6.15-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.6.15-2 (2024-02-04) x86_64 GNU/Linux david@debian12:~/procps/procps-4.0.4/src$
Bug#1069795: Please keep random
Package: bsdgames Version: 2.17-33 Severity: wishlist I've found random a useful tool for sampling data files and would find it helpful if it were kept. Thank you. -- The standard is written in English . If you have trouble understanding a particular section, read it again and again and again . . . Sit up straight. Eat your vegetables. Do not mumble. -- _Pascal_, ISO 7185 (1991)
Bug#1059101: upstream bug
tag 1059101 + upstream thanks This is bug#70122 upstream, and Braun & Eli are converging on a fix there. -- Any social occasion, it's hello, how do you do.
Bug#1040690: failure in a chroot
The failure in a chroot looks the same as that described in #1041415, and is due to the lack of /proc. It doesn't seem related to the originally described problem. -- Time is waiting to explain, why refuse?
Bug#1041415: details
tag 1041415 - upstream
thanks
Ultimately this fails because /proc is not available in the chroot.
The version of libc in use *emulates* fchmodat() using /proc/self/fd
rather than using the fchmodat system call.
When /proc is provided in the chroot, the fchmodat emulation works
successfully and emacs is happy.
zarquon% sudo chroot /var/lib/machines/debian-sid
root@zarquon:/# mount
mount: failed to read mtab: No such file or directory
root@zarquon:/# /usr/bin/emacs --no-init-file --no-site-file -batch -f
batch-byte-compile /usr/share/emacs/site-lisp/debian-startup.el
>>Error occurred processing /usr/share/emacs/site-lisp/debian-startup.el: File
>>error (("Doing chmod" "Operation not supported"
>>"/usr/share/emacs/site-lisp/debian-startup.elcGBDJRw"))
root@zarquon:/# mount -t proc /proc /proc
root@zarquon:/# mount
/proc on /proc type proc (rw,relatime)
root@zarquon:/# /usr/bin/emacs --no-init-file --no-site-file -batch -f
batch-byte-compile /usr/share/emacs/site-lisp/debian-startup.el
root@zarquon:/# exit
zarquon%
So, not an upstream bug, and not really a bug at all.
--
We're deep in discussion, the party's on mute.
Bug#1041415: details
tag 1041415 + upstream
thanks
The error message:
>>Error occurred processing /usr/share/emacs/site-lisp/debian-startup.el: File
>>error (("Doing chmod" "Operation not supported"
>>"/usr/share/emacs/site-lisp/debian-startup.elcFx8oFi"))
comes from the emacs byte compiler. Tracing through the byte compiler,
we find that the error is reported by the call to `set-file-modes` in
`byte-write-target-file`.
set-file-modes is implemented in C, and ultimately results in a call to
`fchmodat`.
`byte-write-target-file` *always* sets the 'nofollow flag when calling
`set-file-modes`, which results in `fchmodat` being called with the
AT_SYMLINK_NOFOLLOW flag.
Unfortunately, documentation for `fchmodat` on Linux indicates:
> AT_SYMLINK_NOFOLLOW
> If pathname is a symbolic link, do not dereference it: instead
> operate on the link itself. This flag is not currently
> implemented.
...and...
> ENOTSUP
> (fchmodat()) flags specified AT_SYMLINK_NOFOLLOW, which is not supported.
ENOTSUP maps to "Operation not supported", which is the error returned
back up the stack.
So this looks like a bug in upstream emacs 28. Will take it there.
--
She's got no name, but she is family.
Bug#1041415: details
Ah, by specifically using a chroot rather than a systemd-nspawn container, I *am* able to reproduce the failure. Off to debug... -- I'm not living in the real world, no more, no more.
Bug#1041415: details
I was not able to reproduce this failure. Is there anything interesting about the filesystem underlying the chroot used during the install? Is root able to write files with impunity in the relevant directories? Are you able to reproduce the failure? -- Time is waiting to explain, why refuse?
Bug#1017834: analysis
The failure to build elpa-cider is caused by: > In toplevel form: > cider.el:218:1: Error: Wrong number of arguments: (3 . 4), 2 In the source, this corresponds to: > (define-obsolete-variable-alias 'cider-default-repl-command > 'cider-jack-in-default) In recent versions of emacs, the definition of this (macro) is: > (define-obsolete-variable-alias OBSOLETE-NAME CURRENT-NAME WHEN > DOCSTRING) So the call from cider.el is missing the third argument, leading to the error. Examining emacs' history, we can find in NEWS.28: > ** The WHEN argument of 'make-obsolete' and related functions is mandatory. > The use of those functions without a WHEN argument was marked obsolete > back in Emacs 23.1. The affected functions are: 'make-obsolete', > 'define-obsolete-function-alias', 'make-obsolete-variable', > 'define-obsolete-variable-alias'. So this is indeed caused by a change in emacs 28, where the third argument to define-obsolete-variable-alias is now mandatory. Upstream cider removed this call to define-obsolete-variable-alias in version 1.1, changeset 4b6c0e9936d125102c2dd0bb1dedbd80fb4907a6, in December 2020. What to do? Debian could carry a patch to fix version 0.19 of cider to address this failure. This would be straightforward, but given how old the packaged version of cider is, it's not clear that it would really be a useful way forward. It seems like either: - the Debian packaged version of cider should be updated to something more current, and kept updated, - the package should be removed, leaving Debian without a packaged version of cider. New versions of cider appear quite frequently - sometimes weekly. Keeping them up to date in Debian would be an ongoing commitment. Given how old the packaged version of cider is and how apparently little used (it has been broken for a couple of years, and popcon lists 7 installs), removing it seems the more sensible approach. -- I've been waiting for so long, to come here now and sing this song.
Bug#1069625: Acknowledgement (gstreamer1.0: Don't build ptp-helper on hppa)
Updated patch to fix install. Dave -- John David Anglin dave.ang...@bell.net --- control.save2024-04-21 15:25:15.368645225 + +++ control 2024-04-21 15:14:58.183856344 + @@ -18,7 +18,7 @@ libdw-dev [i386 amd64 armel armhf arm64 powerpc ppc64 ppc64el mipsel mips64el riscv64], bison, flex, - rustc, + rustc [!hppa], libgirepository1.0-dev, gir1.2-glib-2.0, gir1.2-freedesktop, --- libgstreamer1.0-0.install.save 2024-04-21 16:38:07.810032050 + +++ libgstreamer1.0-0.install 2024-04-21 16:38:17.922110631 + @@ -1,5 +1,4 @@ usr/lib/*/gstreamer-1.0/*.so usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner -usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper usr/lib/*/*.so.* usr/share/locale --- rules.save 2024-04-21 15:25:23.96877 + +++ rules 2024-04-21 16:40:18.347048541 + @@ -44,6 +44,10 @@ conf_flags += -Dlibunwind=disabled -Dlibdw=disabled endif +ifneq (,$(filter $(DEB_HOST_ARCH),hppa)) +conf_flags += -Dptp-helper=disabled +endif + infiles := \ libgstreamer1.0-0.postinst --- libgstreamer1.0-0.postinst.in.save 2024-04-21 19:15:04.053817208 + +++ libgstreamer1.0-0.postinst.in 2024-04-21 19:15:41.034100581 + @@ -2,7 +2,7 @@ set -e -if [ "$1" = configure ]; then +if [ "$1" = configure && test -f /usr/lib/@MULTIARCH@/gstreamer1.0/gstreamer-1.0/gst-ptp-helper ]; then # If we have setcap is installed, try setting cap_net_bind_service,cap_net_admin+ep, # which allows us to install our helper binary without the setuid bit. if command -v setcap > /dev/null; then
Bug#1069549: racket: FTBFS on armel: dh_install: error: missing files, aborting
Control: tag -1 confirmed Lucas Nussbaum writes: > Source: racket > Version: 8.12+dfsg1-7 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240420 ftbfs-trixie ftbfs-t64-armel > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on armel. Thanks for the report. I don't know why it wasn't triggered previously, but I can confirm the problem is not architecture specific, and I can replicate it on amd64 with CONFIG_ARGS_amd64 := --disable-docs --enable-bc Rather than being architecture specific it seems related to the configuration options that happen to only be used for armel at the moment.
Bug#1069625: gstreamer1.0: Don't build ptp-helper on hppa
Source: gstreamer1.0 Version: 1.24.2-1 Severity: normal Tags: ftbfs patch Dear Maintainer, The standalone ptp-helper application in gstreamer1.0 1.24.2-1 requires the rust compiler to build. rustc is not available on hppa, alpha, hurd-amd64, hurd-i386, ia64, m68k and sh4. The current dependence on rustc blocks the entire package from being built. This indirectly blocks hundreds of packages from being built. I do not believe the ptp-helper is useful on hppa. PTP support requires hardware time stamping. None of the Ethernet hardware commonly used in PA-RISC machines have this capability. gstreamer1.0 builds successfully with the attached patch on hppa. Work is needed to add other architectures without rustc and to adjust the installation files. Regards, Dave Anglin -- System Information: Debian Release: trixie/sid APT prefers buildd-unstable APT policy: (500, 'buildd-unstable'), (500, 'unstable') Architecture: hppa (parisc64) Kernel: Linux 6.8.7 (SMP w/4 CPU threads) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) --- control.save2024-04-21 15:25:15.368645225 + +++ control 2024-04-21 15:14:58.183856344 + @@ -18,7 +18,7 @@ libdw-dev [i386 amd64 armel armhf arm64 powerpc ppc64 ppc64el mipsel mips64el riscv64], bison, flex, - rustc, + rustc [!hppa], libgirepository1.0-dev, gir1.2-glib-2.0, gir1.2-freedesktop, --- libgstreamer1.0-0.install.save 2024-04-21 16:38:07.810032050 + +++ libgstreamer1.0-0.install 2024-04-21 16:38:17.922110631 + @@ -1,5 +1,4 @@ usr/lib/*/gstreamer-1.0/*.so usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-plugin-scanner -usr/lib/*/gstreamer1.0/gstreamer-1.0/gst-ptp-helper usr/lib/*/*.so.* usr/share/locale --- rules.save 2024-04-21 15:25:23.96877 + +++ rules 2024-04-21 16:40:18.347048541 + @@ -44,6 +44,10 @@ conf_flags += -Dlibunwind=disabled -Dlibdw=disabled endif +ifneq (,$(filter $(DEB_HOST_ARCH),hppa)) +conf_flags += -Dptp-helper=disabled +endif + infiles := \ libgstreamer1.0-0.postinst
Bug#1069585: apt: autoremoval forgets transitional packages in a OR dependency
Control: reassign -1 synaptic 0.91.3 On Sun, Apr 21, 2024 at 03:50:27AM +0200, Vincent Lefevre wrote: > "apt: autoremoval keeps all branches of an OR on the system even if > I don't want one". > > While I can understand the reason why this is wontfix, this reason > makes no sense on transitional packages. Instead of asking apt (and all other applications) to come up with a complex set of rules what a transitional package might be (case in point: policykit-1 is not in section oldlibs[0]) you should focus your energy on making that transition actually happen if you care that much about it. [0] https://wiki.debian.org/RenamingPackages > As an example: > > qaa:~> apt autoremove -s > NOTE: This is only a simulation! > apt needs root privileges for real execution. > Keep also in mind that locking is deactivated, > so don't depend on the relevance to the real current situation! > Summary: > Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 82 > > but policykit-1 (marked as automatically installed) could be removed: > > qaa:~> aptitude remove -s policykit-1 > The following packages will be REMOVED: > policykit-1 > 0 packages upgraded, 0 newly installed, 1 to remove and 82 not upgraded. > Need to get 0 B of archives. After unpacking 34.8 kB will be freed. > Would download/install/remove packages. > > I suppose that "apt autoremove" doesn't remove it because of > the OR dependency: > > qaa:~> aptitude why policykit-1 > i synaptic Depends pkexec | policykit-1 > > (at least, this seems to be one of the reasons). synaptics could drop the or on policykit-1 – or if for some reason keeping it is desirable make it a versioned on, like: | pkexec | policykit-1 (<< first-transitional-version~) Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1069316: network-manager-gnome: Debian 11 Xfce panel Network Manager applet has disappeared
Package: network-manager-gnome Version: 1.20.0-3 Severity: important X-Debbugs-Cc: dpchr...@holgerdanske.com Dear Maintainer, Please see: https://lists.debian.org/debian-user/2024/04/msg00171.html David -- System Information: Debian Release: 11.9 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-28-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages network-manager-gnome depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.28-0+deb11u1 ii libatk1.0-0 2.36.0-2 ii libayatana-appindicator3-10.5.5-2+deb11u2 ii libc6 2.31-13+deb11u8 ii libcairo2 1.16.0-5 ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1+deb11u1 ii libglib2.0-0 2.66.8-1+deb11u1 ii libgtk-3-03.24.24-4+deb11u3 ii libjansson4 2.13.1-1.1 ii libmm-glib0 1.14.12-0.2 ii libnm01.30.6-1+deb11u1 ii libnma0 1.8.30-1 ii libnotify40.7.9-3 ii libpango-1.0-01.46.2-3 ii libpangocairo-1.0-0 1.46.2-3 ii libsecret-1-0 0.20.4-2 ii libselinux1 3.1-3 ii network-manager 1.30.6-1+deb11u1 ii policykit-1-gnome [polkit-1-auth-agent] 0.105-7 Versions of packages network-manager-gnome recommends: ii gnome-keyring3.36.0-1 ii iso-codes4.6.0-1 ii mobile-broadband-provider-info 20201225-1 ii notification-daemon 3.20.0-4 ii xfce4-notifyd [notification-daemon] 0.6.2-1 Versions of packages network-manager-gnome suggests: pn network-manager-openconnect-gnome pn network-manager-openvpn-gnome pn network-manager-pptp-gnome pn network-manager-vpnc-gnome -- no debconf information
Bug#1069275: apt: random display of the "Summary:" line
On Fri, Apr 19, 2024 at 02:06:44PM +0200, Antonio wrote:
> If you find the "apt autoremove --purge" command in the sequence of the
> commands I have indicated, you will notice that it appears three times:
>
> - in second position produces this output:
>
> $ apt autoremove --purge
^^^
> Summary:
> Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
>
> - in seventh position it produces the same output
>
> $ apt autoremove --purge
^^^
> Summary:
> Upgrading: 0, Installing: 0, Removing: 0, Not Upgrading: 0
>
> but the same command, in the fifteenth position produces a different output:
>
> $ apt-get autoremove --purge
^^^
> 0 updated, 0 installed, 0 to be removed and 0 not updated.
>
> what has changed? I would always expect the same output...
(Lets play a game! Lets call it: Spot the difference. )
As Julian already mentioned, "apt" and "apt-get" have different output.
This is intended (for compat) and not random, but yes, it can be a bit
confusing if your muscle memory lets you end up mix their use.
(Note that not only their output is different; they also have behaviour
differences e.g. "apt-get upgrade" vs "apt upgrade")
As an interactive user, its is probably best to forget apt-{get,cache,…}
exist and get used to 'apt'. If that is missing something compared to
the others feel free to report a bug so we can add it – or suggest an
alternative as sometimes that might be better approach.
Best regards
David Kalnischkies
signature.asc
Description: PGP signature
Bug#1069273: ITP: gnome-shell-extension-tactile -- Tile windows on a custom grid using your keyboard
Package: wnpp Severity: wishlist Owner: David Edmondson X-Debbugs-Cc: debian-de...@lists.debian.org, d...@dme.org * Package name: gnome-shell-extension-tactile Version : 32 Upstream Contact: Per Thomas Lundal, https://gitlab.com/lundal * URL : https://gitlab.com/lundal/tactile * License : GPL-3+ Programming Lang: Javascript, Typescript Description : Tile windows on a custom grid using your keyboard > Type Super-T to show the grid, then type two tiles (or the same tile > twice) to move the active window. > > The grid can be up to 4x3 (corresponding to one hand on the keyboard) > and each row/column can be weighted to take up more or less space. I've been using Tactile for a few years now and find it indispensable for managing windows on a larger monitor with GNOME. I'm eager to maintain the package in Debian and will need a sponsor.
Bug#832473: synaptic: Cannot change mark from "complete removal" to "removal"
On Wed, Apr 17, 2024 at 12:14:14PM -0700, Philip Chung wrote: > > If I mark a package for complete removal, I cannot change the mark > > directly to simple removal. > > > > Steps to reproduce: > > > > 1. Select a package. > > > > 2. Mark the package for complete removal.[1] > > > > 3. Mark the package for removal.[1] […] > In the implementation of that method (source file apt-pkg/depcache.cc), > there is a particular check that suggests a deliberate design decision to > disallow moving from purging (complete removal) to simple removal but allow > moving in the other direction: I think the idea is that code that explicitly decided to mark a package for complete removal should not be overridden later on by code that just happens to want a package removed due to a Conflicts relation or some such. That could be resolved by looking at FromUser but the check you quoted is from 1999, while the FromUser parameter (that I added I might add) is "only" from 2009. After a quarter century of this behaviour, I am not sure it is worthwhile to "fix" this given, if I really tried, I could probably argue in favour of either way. I could frame that "decision" from 2009 a compat one given that FromUser was a new parameter and defaults to true, so that would have been a behaviour change if I had changed that… but I doubt I was thinking about that back then. So, absolutely not a fundamental design decision; just something that happened due to dumb luck/cosmic intervention/reasons. > I've CC'ed the APT team on this e-mail to get their input. If there are good (That CC'ed worked & the Fwd reached us a bit later, too. Some hop in between you, mailing list and you has probably greylisted the mail for a while making it look like it didn't reach us I suppose. No worries anyhow.) > fix." (I don't think there is a compelling reason for Synaptic to work > around this design decision in APT.) I think for an interactive graphical tool like Synaptic this behaviour of libapt might be unfortunate, but easy to work around: If you see in Step 3 that a package is marked for complete removal already, just MarkKeep it first before MarkDelete it again. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1069183: [Aptitude-devel] Bug#1069183: aptitude: already running package installs/upgrade get interrupted because of lost dpkg lock
pes that nothing grabs it in the meantime, which was the practice before dpkg gained the frontend lock (these are aptitudes own methods that wrap _system->Lock() from libapt that does acquire the frontend and the dpkg lock – and also releases both if told so). The solution here should be to hold onto the frontend lock for the entire run and do the lock dance for compatibility with the dpkg lock only. _system->LockInner() is part of that and grep has no hits for it in aptitude. So, my suspicion is that aptitude doesn't use the frontend lock and is hence prune to other front ends grabbing the dpkg (and front end) lock the moment it releases the dpkg lock for dpkg. Hence the two fails and the run of needrestart takes long enough for the other front end to finish so that the last dpkg call aptitude makes succeeds again. Someone who knows aptitude better – or at least has more than a passing interested in aptitude – should check the code to proof the suspicions made here (or disprove them of course). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1069128: haskell-aeson: FTBFS from source - out of memory in SomeType2ElemArray test
Source: haskell-aeson
Version: 2.1.2.1-5
Severity: normal
Tags: ftbfs
Dear Maintainer,
Build fails here:
ApproxDefault: OK (0.03s)
+++ OK, passed 100 tests.
SomeType2ElemArray:
aeson-tests: out of memory (requested 2097152 bytes)
Test suite aeson-tests: FAIL
Test suite logged to: dist-ghc/test/aeson-2.1.2.1-aeson-tests.log
0 of 1 test suites (0 of 1 test cases) passed.
-e: error: debian/hlibrary.setup test --builddir=dist-ghc --show-details=direct
returned exit code 1
at /usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 875.
Debian::Debhelper::Dh_Lib::error("debian/hlibrary.setup test
--builddir=dist-ghc --show-details"...) called at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 614
Debian::Debhelper::Dh_Lib::error_exitcode("debian/hlibrary.setup test
--builddir=dist-ghc --show-details"...) called at
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 477
Debian::Debhelper::Dh_Lib::doit("debian/hlibrary.setup", "test",
"--builddir=dist-ghc", "--show-details=direct") called at
/usr/share/perl5/Debian/Debhelper/Buildsystem/Haskell/Recipes.pm line 692
Debian::Debhelper::Buildsystem::Haskell::Recipes::check_recipe() called
at -e line 1
make: *** [/usr/share/cdbs/1/class/hlibrary.mk:163: check-ghc-stamp] Error 25
dpkg-buildpackage: error: debian/rules binary-arch subprocess returned exit
status 2
Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=haskell-aeson=hppa=2.1.2.1-5%2Bb1=1713288523=0
Regards,
Dave Anglin
-- System Information:
Debian Release: trixie/sid
APT prefers buildd-unstable
APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)
Kernel: Linux 6.8.4 (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Bug#1053548: check-patroni: does not work well with current Patroni
Hi Michael, Le Fri, Dec 15, 2023 at 02:31:23PM +0100, David Prevot a écrit : > On 2023-12-04 16:59, Michael Banck wrote: […] > > So, what are your plans? I can offer to take over the packaging of > > check-patroni as part of the Postgres team; I'd move the git to > > salsa.debian.org/postgresql and merge in a few of the things I did > > differently. > > Sounds good to me, thanks! FYI, I uploaded the latest version just because I noticed it, but still agree with your plan of taking over under /postgresql whenever you wish. Regards, taffit signature.asc Description: PGP signature
Bug#1068946: png23d: Package Homepage is a broken link, here's the correct one
Package: png23d Version: 1.10-1.3 Severity: minor Dear Maintainer, The package home page is listed as http://kyllikki.github.com/png23d/ but that returns 404 Page not found error. The following looks to me like the page to use at this point. https://github.com/kyllikki/png23d -- David Fries -- System Information: Debian Release: 11.6 Architecture: amd64 (x86_64) Versions of packages png23d depends on: ii libc62.31-13+deb11u5 ii libpng16-16 1.6.37-3 png23d recommends no packages. png23d suggests no packages.
Bug#1068774: (No Subject)
On Sat, Apr 13, 2024 at 11:52:32AM +, mYnDstrEAm wrote: > > So, which is it: You install random things you don't care about because > > their name appeared in the kept-back list or you explicitly install that > > package from the kept-back list because you care very deeply about it? > > I and many others (this issue is not about me) install them like that because > their name appeared in the kept-back list. So it's the former and I never > said it wouldn't be that. And I tried to explain to you that many others believe in the exact opposite: That the package they asked to be installed is of course important enough for them that it should be marked manual. Just because you can find people who complain about the current behaviour doesn't mean there aren't people who like it – they just have no reason to complain. If everyone would always listen to complains we would have blasted the sun from orbit ages ago. All the glaring, sunburn and oh god, its so hot some times… and I heard the sun is the main cause of global warming… > > that isn't how apt sees it. You might remember that in a previous request > > you made apt might have said that about a package, but apt has no such > > memory > > Well then part of this would be to make it run a check if any of the packages > to be installed is currently kept-back. I never said it would have to keep > prior apt commands in mind, it just knows (can check) which packages are > kept-back. In the usual scenario the notice about a kept-package displays > during an apt-get upgrade/update command. 'update' doesn't display something about kept back because that makes no sense. kept-back is a property of the specific request you just made: Just like all the other packages listed as new, remove or upgrade. A package might be phased (repository) or put on hold (user) and for that reason appear in kept-back (or not, as said, phased is display nowadays in another list), but that is still related to the request as if you explicitly request that package name they are not considered kept-back and while the kept-back-reason package-was-put-on-old-by-user is checkable (and apt checks that and even prints a warning about that: Changing held packages) most reasons for kept-back are not as if you explicitly install a package the question if other packages can or should fiddle with its state never arises. "Worse" it might lead to other packages being kept-back like the other side of a transition that was previously winning the tug of war. Your sysv-rc-conf is kinda an example: A normal upgrade doesn't do it because it is deemed not a good idea to prefer this over 20 other packages. Removing the package serves no real purpose either through, at least not if the user isn't asking for it – after all, who likes packages being removed needlessly. If you explicitly request the installation that is no longer the case: Everything is okay for the benefit of respecting the user request, so 1, 20, or 2000 pkg to remove are not a problem even if it includes systemd-sysv, the default init process and the only one many packages are nowadays prepared to work with. Any package who looses the ability working with anything else but systemd-sysv would in that scenario be kept-back even through it happily upgrades if you don't ask for sysv-rc-conf explicitly. > > based on your explicit manual install request > > This issue is not about installs that are explicitly manual and it shouldn't > be merged with other issues that are about something else. You enter "apt install some-pkg". That is an explicit manual install request for some-pkg. Just because you wish it to be something else doesn't make it true. The observable difference is if some-pkg was previously not installed (in which case it is installed and tagged manual installed) or if some-pkg is currently installed. For the later, two cases exist: Either the candidate version is installed or it is not which both want to ensure the same outcome: The candidate version is installed. The only question that arises is: Should that ALSO, like the first scenario set the package to manually installed given its installation was manually requested. The answer so far is yes – and you insist on it being changed to no, while I keep telling you that there are usecases/scenarios for both, so an acceptable compromise might be to implement both and offer a choice… Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1052434: Acknowledgement (qttools-opensource-src: FTBFS on hppa - No rule to make target 'assistant.qch')
This bug appears to have been introduced by the fix for #1045220. Dave -- John David Anglin dave.ang...@bell.net
Bug#1068823: Stepwise Debian upgrade to enable systems with little free storage space to upgrade without breaks due to "No space left on device"
On Thu, Apr 11, 2024 at 04:46:03PM +, mYnDstrEAm wrote: > With the two commands above one can already split it up into two steps but > especially the second command still requires a lot of disk space. I am going to assume that your "a lot of disk space" stems from the *.deb files that are downloaded. If so, you can e.g. attach an USB disk/ drive and mount it e.g. under /media/apt-archives Tell apt to use that directory instead of /var/cache/apt/archives, e.g.: apt upgrade -o dir::cache::archives=/media/apt-archives (for some more free MBs you could 'apt clean' and then move dir::cache elsewhere, but for that you need to create some directories in the target location and the binary caches are not THAT large to make it really worthwhile in practice. Similar for other files like /var/lib/apt aka dir::state::lists) Instead of an USB drive you could do the same with e.g. an SD card, drop them into RAM (if your device has surprisingly more RAM than disk) or even use a network share (NFS, sshfs, … you name it). The filesystem is not usually a concern (as in: even fat32 should work given we encode away the : in epochs). Note that whoever has write access to the files on the storage (or in case of unencrypted transfer, also everyone who can meddle with transfer over the network) could use that to attack you as apt (well, apt will casually check them first, but after that and dpkg, who actually interacts with them the most) will assume that the files in /var/cache/apt/archives (or where ever else you stored them and told apt to use them) are valid & trusted. Note also that apt uses for its space check statvfs(3) f_bavail, as in, depending on how you configured your disk, it should have a couple of additional free blocks in reserve (typically 5%, see tune2fs(8) -m). If you know what you are doing, you could decrease that value. Note that the value apt displays is only an estimate, powered by what the individual packages claim (via dpkg), which is an estimate. Also, if you happen to have a 2GB installed, the upgrade will roughly take an additional 2GB as dpkg would first extract the new files along the old ones and then replace them in one swoop – so for a bit, you have that package installed two times. Multiple this by group size, divide by unchanged files and sprinkle some salt over it for flavour. Predictions are hard, especially about the future. I would in general not recommend to try approaches like upgrading individual packages as that easily leads unsuspecting users into situations that nobody else has encountered before: aka bugs in packages that nobody else will encounter as they are either hidden by the involved set usually being upgraded together as intended™ or – which tends to be even worse – the breakage is known but ignored on purpose as the solution is far worse than the problem (at least for everyone doing upgrades the normal way – example: usrmerge). Also, but that is just an aside, people grossly overestimate how easy it is for packages to be upgraded individually (compare: t64 testing migration). Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068774: (No Subject)
On Thu, Apr 11, 2024 at 10:43:38PM +, mYnDstrEAm wrote: > > You found with #956330 already a feature request that asks for that > > No, that other issue is not about kept-back packages in specific. I don't see > how the functionality of that issue would be very useful but for kept-back > packages asking the user or by default not marking them as manually installed > could be very useful and seems more like what one would expect it to do. So, which is it: You install random things you don't care about because their name appeared in the kept-back list or you explicitly install that package from the kept-back list because you care very deeply about it? APT isn't keeping back a package because its bored. It has reasons, different ones even, and the general reply from a user to it should be: "Okay" and not "Lets try to force it". In some cases that force will not work and end in failure (unsatisfied dependencies), in some cases it will lead to non-optional solution which might lead to problems later on (unsatisfied recommends), sometimes its an ongoing transition that apt decides to wait on instead of applying (which usually means a bunch of stuff has to be removed), sometimes the distro itself decides that newer versions are shipped piece meal to different users to avoid potential issues hitting them all at once (phasing) and sometimes a user has explicitly put that package on hold. I probably forgot a few more possibilities. > This is about kept-back packages where install is used to make them install. No it isn't because that isn't how apt sees it. You might remember that in a previous request you made apt might have said that about a package, but apt has no such memory. What would that memory even be given that your last request could have been something between complete bogus you would prefer to pretend to have never entertained and a heartfelt "I can't do without you" plea. Would that memory be time bound: If its two seconds later, its related, but if it was last week, it is not? That would turn quickly into a complete mess of unpredictable behaviour. So, even if you think you are forcing apt with an install request to install a package version it decided to keep back in a previous request, for apt you are "just" asking it to install the given package, period. apt could ask about if it should modify the auto/manual installed state based on your explicit manual install request (<- note the wording choice) for a package you attempt to upgrade (compared to new install), but it currently doesn't and that is what the request I merged it with is talking about. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068774: When installing a package that is kept back with apt-get install do not mark it as manually installed or ask the user whether the mark should be added
Control: forcemerge 956330 -1 On Wed, Apr 10, 2024 at 09:53:39PM +, mYnDstrEAm wrote: > Could you please make apt not mark packages as manually installed when > installing packages […] You found with #956330 already a feature request that asks for that, so I am merging this one with it as even in the best case this could only be considered a sub-task (if at all). > […] that have been kept back in specific? Note that "phases upgrades" have their own listing now, but you might be better of asking in Ubuntu support channels about this as Debian doesn't use the Phasing feature at all. > Alternatively, the user could be asked whether they want to have it marked if > the mark would be added but I think most users would not want that. In #956330 Алексей Шилин actually makes a good point about an install request having predictably the same outcome. In any case, I think in part this comes from a conceptional disagreement: I don't think 'install' is meant to "force" an upgrade of a package, but it can have that side effect and so some users end up using it for that side effect: > It makes little sense and only causes problems, partly because they then > won't uninstall when removing packages that depend on them. You mean they are protected from autoremove, right? Well, see, that is the thing: If you don't use 'install' to force random packages to upgrade it turns out that you 'install' things you care about and don't want removed as unneeded later on… But how should apt differentiate between "apt install firefox": - I dislike Chromium, let me try out this other browser - … that I had never installed before - … that I had installed in some old version years ago - … that happened to be removed recently - … oh, I have it already installed? Didn't know! - … that I have already installed as a dep, but now I am active user! - New version is phased, but I want it now now now because - … that's my beloved browser I want always latest and never removed - … friend said I should test this new version early - … I have no idea what it is, but upgrades are good, right? - Critical security bug! The announcement tells me to upgrade - … no time to upgrade everything, lets just pick that one - … unattended-upgrade did it all before me - Whoa! autoremove tells me it wants to remove my beloved browser, lets install it explicitly to make it stop that - Ups, I let autoremove remove it! Lets rectify that mistake! And that aren't even all… so I certainly have some sympathy for the predictable outcome mentioned and conversely not putting too much value in what it means that a package is marked manual or auto installed as it effectively just guards against suggesting auto-removing packages the user somehow showed they cared about at some point with a failure mode of just keeping some dead weight around. Giving it more value means we would need to involve users a lot more in the management of it, which many would probably be happy to do, but many also not appreciate much given the failure mode is so low key. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068637: apt does not always install Recommends
Control: reassign 1068637 debian-installer Control: reassign 1068560 debian-installer Control: forcemerge 931283 1068637 1068560 Summary of bug(s) so far: lvm2 installed by d-i without its Recommends Question: Can we solve this once and for all or do we need/want a workaround and/or downgrade for lvm2 only to make user happy [only pun intended] Merging both into #931283 that seems to be about the same thing. On Tue, Apr 09, 2024 at 02:17:18AM +0200, Vincent Lefevre wrote: > Then, I don't know the internals. But according to Bastian Blank[*]: > "It is installed like everything else." (but see the details below). > > [*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068560#22 He likely meant that you have installed it, "like everything else" because that is what users usually do and you weren't particular clear that you haven't – and what you used that did for you… lvm2 isn't "a core package", so there are certainly ways of installing Debian (even with d-i, which isn't the only way either) without lvm2. d-i seems to install packages without recommends: https://salsa.debian.org/installer-team/base-installer/-/blob/master/library.sh?ref_type=heads#L152 That is later dropped for "everything else", but I suppose lvm2 is installed before that – but I don't know much about d-i or lvm2. Anyway, it probably isn't a good idea to have d-i install all recommends while it sets up the machine – better things to do and all that –, but perhaps it can as one of the last actions (final_apt_preferences ?) run something like: | apt-get install --fix-policy (after the config is removed, or add --install-recommends). Likely involves demoting some 'Recommends' in the base set to 'Suggests' through, but they behave like that already if installed by d-i, so that is probably for the best for consistency alone. In any case, I will leave d-i folks have fun with this now, but feel free to ask apt-team if there is something we can help with. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068637: apt does not always install Recommends
On Mon, Apr 08, 2024 at 01:05:40PM +0200, Vincent Lefevre wrote: > On 2024-04-08 12:29:17 +0200, Julian Andres Klode wrote: > > On Mon, Apr 08, 2024 at 11:50:04AM +0200, Vincent Lefevre wrote: > > > The lvm2 package is installed, but not thin-provisioning-tools, > > > though lvm2 recommends it. This can yield a broken system: […] > It is not mandatory in all cases, but it some cases. In any case, > the "Recommends:" must be honored. You haven't mentioned AT ALL if we are talking about upgrade or a fresh install of lvm2, for the later see below. For the former: Are you absolutely, positively sure that you haven't ignored apt (aptitude) telling you that it wont install that recommends while installing lvm2? APT (and aptitude?) do not install old unsatisfied recommends on an upgrade, so the only way of not getting thin-provisioning-tools installed is either to not have it installed while it was new in which case apt (and I think aptitude has somewhat similar) output contains: | Recommended packages: | thin-provisioning-tools Same for Suggests btw which aren't installed by default (but lvm2 has none). Or you have removed thin-provisioning-tools at some point after it was once installed. And yes, as Julian explained, if a package is not installable, that also leads to a recommends not being installed but same output. (I somewhat doubt you have managed to install an lvm2 which had not yet a recommends on thin-provisioning-tools and upgraded that now to a version with that recommends. That would be a new recommends that apt tries to install, but might fail for reasons Julian mentioned already. Different upgrade-commands-implementations have different approaches to that – 'apt upgrade' e.g. tries to detect that and holds the upgrade off it does, while 'apt full-upgrade' ignores that. Both work better if the archive is a stable state… which tends to be the case with stable for obvious reasons. Less so for unstable.) > No, lvm2 was installed before the time_t transition. It actually > affects plain bookworm installations (on a machine where I installed > Debian 12.1 on 2023-10-07); you can see with the attached > "dpkg --get-selections" output I had at that time. What time? Before you installed lvm2? That output says lvm2 is installed. So after it, but what are you trying to tell us then? That you had lvm2 installed, upgraded it and it still didn't install thin-provisioning-tools? Well, as explained above, working as intended. I just bootstrapped a minimal stable chroot with mmdebstrap and behold: | # apt install --install-recommends lvm2 | Reading package lists... Done | Building dependency tree... Done | Reading state information... Done | The following additional packages will be installed: | dmeventd dmsetup libaio1 libdevmapper-event1.02.1 libdevmapper1.02.1 liblvm2cmd2.03 thin-provisioning-tools | The following NEW packages will be installed: | dmeventd dmsetup libaio1 libdevmapper-event1.02.1 libdevmapper1.02.1 liblvm2cmd2.03 lvm2 thin-provisioning-tools | 0 upgraded, 8 newly installed, 0 to remove and 0 not upgraded. | Need to get 2662 kB of archives. | After this operation, 9729 kB of additional disk space will be used. | Do you want to continue? [Y/n] n | Abort. In other words your issue with a "plain bookworm" install is unreproducible (My chroots are configured to not install recommends by default, so I enable it explicitly on the command line here. There is no difference in behaviour for apt. I think aptitude reacts differently, but who knows). If I leave out the flag apt tells me it wont install the recommends as shown above. What am I doing wrong, where is the bug? So, if you want to have any chance of us investigating your problem as a bug rather than as a user-error you will have to tell us what you did exactly, preferably with easy to follow steps and output. Failing that, on your bookworm install you might be lucky and still have the installation/upgrade and such of lvm2 in your history.log(s). That might shine some light on it as well. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#1068408:
Seconded - the current package situation makes Kicad in Trixie unusable at the moment. dmp@thor:~$ dpkg -l | grep kicad ii kicad 7.0.11+dfsg-1 amd64Electronic schematic and PCB design software ii kicad-demos7.0.11+dfsg-1 all Demo projects for kicad ii kicad-footprints 8.0.1-1 all Footprint symbols for KiCad's Pcbnew ii kicad-libraries7.0.11+dfsg-1 all Virtual package providing common used libraries by kicad ii kicad-packages3d 8.0.1-1 all 3D models for 3D viewer in KiCad's Pcbnew and Footprint Editor ii kicad-symbols 8.0.1-1 all Schematic symbols for KiCad's Eeschema ii kicad-templates8.0.1-1 all Project templates for KiCad The footprints/templates/symbols that are part of 8.0.1-1 are not compatible with the main kicad 7.0.11+dfsg-1. This means the system is unusable until the main kicad package in sid arrives in trixie. The other option would be to update the kicad package to specify the depends for the kicad package on its' libraries/symbols etc as >=7 <8 to avoid the current situation. Hopefully kicad 8 will be arriving from sid shortly.....! David
Bug#1068370: elpa-dpkg-dev-el: Comp warnings due to XEmacs compatible code
Xiyue Deng writes: > > Will re-evaluate if XEmacs compatibility would be dropped. > > [1] > https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/132669ed6d6ee19a440234b943625da9cd6e2d9b > Does the package currently work (somehow?) with XEmacs? At least dh-elpa byte compilation does not support XEmacs, but I have not tested the binary package with XEmacs. d
Bug#1062932: Error building nvidia-kernel-dkms while installing nvidia-driver package
Good evening, The bug involving compiling/installing nvidia-kernel-dkms is still present. The result of the bug is that following a reboot after the erroneous installation noted below, my display drivers get completely disabled, including nouveau, resulting in my external display not functioning and my primary laptop display having very low resolution. I followed the instructions to install NVIDIA proprietary drivers here: https://wiki.debian.org/NvidiaGraphicsDrivers When I executed: sudo apt install nvidia-driver firmware-misc-nonfree I received the following errors, as recorded from the output of the above command: Setting up nvidia-kernel-dkms (525.147.05-4~deb12u1) ... Loading new nvidia-current-525.147.05 DKMS files... Building for 6.1.0-18-amd64 Building initial module for 6.1.0-18-amd64 Error! Bad return status for module build on kernel: 6.1.0-18-amd64 (x86_64) Consult /var/lib/dkms/nvidia-current/525.147.05/build/make.log for more information. dpkg: error processing package nvidia-kernel-dkms (--configure): installed nvidia-kernel-dkms package post-installation script subprocess returned error exit status 10 dpkg: dependency problems prevent configuration of nvidia-driver: nvidia-driver depends on nvidia-kernel-dkms (= 525.147.05-4~deb12u1) | nvidia-kernel-525.147.05 | nvidia-open-kernel-525.147.05 | nvidia-open-kernel-525.147.05; however: Package nvidia-kernel-dkms is not configured yet. Package nvidia-kernel-525.147.05 is not installed. Package nvidia-kernel-dkms which provides nvidia-kernel-525.147.05 is not configured yet. Package nvidia-open-kernel-525.147.05 is not installed. Package nvidia-open-kernel-525.147.05 is not installed. dpkg: error processing package nvidia-driver (--configure): dependency problems - leaving unconfigured Processing triggers for libc-bin (2.36-9+deb12u4) ... Processing triggers for initramfs-tools (0.142) ... update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64 Processing triggers for update-glx (1.2.2) ... Processing triggers for glx-alternative-nvidia (1.2.2) ... update-alternatives: using /usr/lib/nvidia to provide /usr/lib/glx (glx) in auto mode Processing triggers for glx-alternative-mesa (1.2.2) ... Processing triggers for libc-bin (2.36-9+deb12u4) ... Processing triggers for initramfs-tools (0.142) ... update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64 Errors were encountered while processing: nvidia-kernel-dkms nvidia-driver E: Sub-process /usr/bin/dpkg returned an error code (1) From /var/lib/dkms/nvidia-current/525.147.05/build/make.log: ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_lock' ERROR: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol '__rcu_read_unlock' make[3]: *** [/usr/src/linux-headers-6.1.0-18-common/scripts/Makefile.modpost:126: /var/lib/dkms/nvidia-current/525.147.05/build/Module.symvers] Error 1 make[2]: *** [/usr/src/linux-headers-6.1.0-18-common/Makefile:1991: modpost] Error 2 make[2]: Leaving directory '/usr/src/linux-headers-6.1.0-18-amd64' make[1]: *** [Makefile:250: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.1.0-18-common' make: *** [Makefile:82: modules] Error 2 Here is the output of hostnamectl: Static hostname: landarian-laptop Icon name: computer-laptop Chassis: laptop Machine ID: 096686ad78fe43939982b38788ec530e Boot ID: 42ecccb1e0704aaba319fc8d066e6a6a Operating System: Debian GNU/Linux 12 (bookworm) Kernel: Linux 6.1.0-18-amd64 Architecture: x86-64 Hardware Vendor: HP Hardware Model: OMEN by HP Laptop 17-cb1xxx Firmware Version: F.41 And here is the output of lspci -nn | egrep -i "3d|display|vga": 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation TU116M [GeForce GTX 1660 Ti Mobile] [10de:2191] (rev a1) lsmod | grep -w video yields this: video 65536 1 nouveau After researching this issue, I found another Debian user with an identical issue: https://github.com/NVIDIA/nvidia-container-toolkit/issues/361 A patch was linked to here: https://unix.stackexchange.com/questions/769026/debian-12-linux-image-6-1-0-18-amd64-dist-upgrade-fails-on-nvidia-gpl-incompatib I will attempt the patch until this bug gets resolved. Thank you. _ David Landry
Bug#1068337: mblaze(7) and debian/control refer to mless(1) and msort(1), but they are actually mblaze-less(1) and mblaze-sort(1) in Debian
Proposed patches are in the debian/sid branch at https://salsa.debian.org/dme/mblaze. -- Come down, come talk to me.
Bug#1068337: mblaze(7) and debian/control refer to mless(1) and msort(1), but they are actually mblaze-less(1) and mblaze-sort(1) in Debian
Package: mblaze Version: 1.1-1 Severity: minor Tags: patch X-Debbugs-Cc: d...@dme.org Dear Maintainer, When the Debian packaging build renames mless -> mblaze-less and msort -> mblaze-sort, it does not update the references in the mblaze manual page or package description. This is confusing! -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable'), (550, 'experimental'), (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.6.15-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mblaze depends on: ii libc6 2.37-15 mblaze recommends no packages. mblaze suggests no packages. -- no debconf information
Bug#1068253: RFS: gnome-online-accounts-gtk/3.50.1-1 [ITP] -- GUI Utility for logging into online accounts
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "gnome-online-accounts-gtk": * Package name : gnome-online-accounts-gtk Version : 3.50.1-1 Upstream contact : Clement Lefebvre * URL : https://github.com/linuxmint/gnome-online-accounts-gtk * License : GPL-3 * Vcs : https://github.com/ubuntubudgie/gnome-online-accounts-gtk/tree/debian Section : misc The source builds the following binary packages: gnome-online-accounts-gtk - GUI Utility for logging into online accounts To access further information about this package, please visit the following URL: https://mentors.debian.net/package/gnome-online-accounts-gtk/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/gnome-online-accounts-gtk/gnome-online-accounts-gtk_3.50.1-1.dsc Changes for the initial release: gnome-online-accounts-gtk (3.50.1-1) unstable; urgency=medium . Initial version (Closes: #1068200) Summary: Upstream blog post https://blog.linuxmint.com/?p=4660 "GNOME Online Accounts, aka “GOA”, is a project which allows users to connect to their data in the cloud. This project was only designed for GNOME though so it doesn’t provide any front-end. It only provides libraries (namely libgoa and libgoa-backend). Other than GNOME, many desktop environments integrated a front-end to these libraries in their control center: Cinnamon, Budgie, Unity, etc. This project is important because it doesn’t just connect a desktop to the cloud, it’s used by many applications and libraries. Among other things you might use it to connect the Calendar application, the Thunderbird email program or the file browser to your online data. With GNOME 46, libgoa/libgoa-backend 3.50 moved to GTK4. It can no longer be used by GTK3 applications. To solve this problem a new XApp called GNOME Online Account GTK was created. As any XApp its goal is to work for everybody, in any desktop environment and in any Linux distribution. Regards, -- David Mohammed
Bug#1068200: ITP: gnome-online-accounts-gtk - GNOME Online Accounts GTK
Package: wnpp Severity: wishlist Owner: David Mohammed (fossfree...@ubuntu.com) Package name : gnome-online-accounts-gtk Version : 3.50.1 Upstream Author : Linux Mint URL : https://github.com/linuxmint/gnome-online-accounts-gtk License : GPL 3+ Programming Lang: C Description : GUI Utility for logging into online accounts Enter login details for some online services such as Google and Facebook. This enables applications to access online services like email, calendars, chat and documents. . This is a standalone application for desktop environments where GNOME Online Accounts capability is not integrated in their equivalent settings utility.
Bug#1068140: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)
Sebastian Ramacher writes: > Control: affects -1 src:polymake > [...] > Let's make sure that it is visible for polymake then. Otherwise I'll > file it a third time ;) Thanks, I thought to myself at some point this morning it should have affects, and then, well, I didn't do it. many hands make light-er work, I guess David
Bug#1068140: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)
Control: reassign -1 flint Sebastian Ramacher writes: > Source: polymake > Version: 4.11-2 > Severity: serious > Tags: ftbfs > Justification: fails to build from source (but built successfully in the past) > X-Debbugs-Cc: sramac...@debian.org > > https://buildd.debian.org/status/fetch.php?pkg=polymake=amd64=4.11-2%2Bb4=1711743555=0 As I said the previous two times this bug was reported, as far as I know this has to be a bug (uncoordinated transition) in flint. I guess I can stop building polymake against flint, but really someone(TM) should fix flint. The fact that it uses a hardcoded shlibs file instead of symbols is a bit worrying for me.
Bug#1065057: bookworm-pu: package php-composer-xdebug-handler/3.0.3-2+deb12u1
Hi Adam, Le Mon, Mar 25, 2024 at 06:44:54PM +, Adam D. Barratt a écrit : > On Thu, 2024-02-29 at 11:18 +0100, David Prévot wrote: > > This is a follow up from composer/DSA-5632-1. […] > + * Track debian/bookworm-security > > Even though this update isn't going to the security archive? Well, the debian/bookworm branch has already been published, and is related to version 2 that was (once) the targeted version for Bookworm. Version 3 was finally pushed to unstable before Bookworm got released and this old debian/bookworm was forgotten until now. I decided to use another branch name for this upload instead of messing with Git history (after all, it’s just a branch name), but I agree it’s a bit of a mess. Regards, taffit signature.asc Description: PGP signature
Bug#1065056: bookworm-pu: package php-composer-class-map-generator/1.0.0-2+deb12u1
Hi Adam, Le Mon, Mar 25, 2024 at 06:43:31PM +, Adam D. Barratt a écrit : > On Thu, 2024-02-29 at 11:10 +0100, David Prévot wrote: > > [1/9 for bookworm] > > > > This is a follow up from composer/DSA-5632-1. […] > All 9 of them. :-/ Yay, sorry about that… > Please go ahead. Thanks! All related package have been uploaded. Regards, taffit signature.asc Description: PGP signature
Bug#1054901: icingaweb2: [L10,DE] icingaweb2-module-toplevelview: german translation
close #1054901 0.3.3-3 thanks Hi, this bug has been fixed in above version, hence closing. Regards, David
Bug#1067785: pipx : modifies the wrong zsh init files.
Package: pipx Version: 1.4.3-1 Severity: normal When you use zsh, pipx ensurepath adds export PATH="$PATH:/home/edavid/.local/bin" to both .zshrc and .zprofile, this could lead to a the directory being twice in the path, or not. With zsh the place to put it is ~/.zshenv -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable-security'), (600, 'unstable'), (500, 'stable-updates'), (500, 'proposed-updates'), (400, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pipx depends on: ii python3 [python3-supported-min] 3.11.6-1 ii python3-argcomplete 3.1.4-1 ii python3-packaging23.2-1 ii python3-platformdirs 4.2.0-1 ii python3-tomli2.0.1-2 ii python3-userpath 1.9.1-1 ii python3-venv 3.11.6-1 pipx recommends no packages. pipx suggests no packages. -- no debconf information
Bug#1067767: dpkg-gencontrol: Don't fail on syntax error in removed field
Package: dpkg-dev
Version: 1.22.6
Severity: normal
X-Debbugs-Cc: debhel...@packages.debian.org
Hi,
since recently my arch:any package `ycmd` fails to built from source in
a fresh unstable sbuild environment with at least dpkg 1.22.6 and
debhelper 13.15.2 (compat 13) while generating the dbgsym package:
|dh_gencontrol
-O--sourcedirectory=/<>/ycmd-0\+20231230\+git9e43034\+ds/cpp
-O--builddirectory=/<>/ycmd-0\+20231230\+git9e43034\+ds/ycm_build
| dpkg-gencontrol: warning: can't parse dependency ycmd-core-version (= )
| dpkg-gencontrol: warning: Depends field of package ycmd: substitution
variable ${misc:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package ycmd: substitution
variable ${python3:Depends} used, but is not defined
| dpkg-gencontrol: warning: Depends field of package ycmd: substitution
variable ${shlibs:Depends} used, but is not defined
| dpkg-gencontrol: warning: Recommends field of package ycmd: substitution
variable ${misc:Clang-Ver} used, but is not defined
| dpkg-gencontrol: warning: Provides field of package ycmd: substitution
variable ${misc:Core-Ver} used, but is not defined
| dpkg-gencontrol: warning: can't parse dependency ycmd-core-version (= )
| dpkg-gencontrol: error: parsing package 'ycmd' Provides field:
ycmd-core-version (= ), ycmd-core-version (= 48)
| dh_gencontrol: error: dpkg-gencontrol -pycmd -ldebian/changelog -T/dev/null
-Pdebian/.debhelper/ycmd/dbgsym-root -UPre-Depends -URecommends -USuggests
-UEnhances -UProvides -UEssential -UConflicts -DPriority=optional -UHomepage
-UImportant -DAuto-Built-Package=debug-symbols -UProtected -UBuilt-Using
-UStatic-Built-Using -DPackage=ycmd-dbgsym "-DDepends=ycmd (=
\${binary:Version})" "-DDescription=debug symbols for ycmd"
-DBuild-Ids=dc609a05ca957392f347883f157f1d84a1561dbe -DSection=debug
-UMulti-Arch -UReplaces -UBreaks returned exit code 25
| dh_gencontrol: error: Aborting due to earlier error
| make: *** [debian/rules:19: binary] Error 25
(`vim-youcompleteme` also from me uses something similar but doesn't
fail to build – that one is arch:all and doesn't have a -dbgsym)
The incorrect syntax comes from debian/control containing:
| Provides: ycmd-core-version (= ${misc:Core-Ver}), […]
and dpkg-gencontrol being called with -T/dev/null here (by debhelper).
I am not quite sure if dpkg or debhelper caused this regression with the
recent changes around substvars, but given that a substvar can only be
used to modify the contents of a field and can not embed other fields
in the modification it seems reasonable that if a field is removed from
the output with -U (or overridden with -D) dpkg-gencontrol should not
insist on its syntax being correct – or even warn about undefined
substvars within – as it will have no effect on the output and as
such this might be considered a feature request potentially fixing
a regression (and is as such upgraded from wishlist to normal):
I could easily resolve this error & ignoring the warnings by letting
the entire provides being generated instead of just the version number
here as a simple workaround, but given the choice I would prefer what
I have and it doesn't seem that strange, so others might be effected.
That might very well be a bug in debhelper (too), as I assume it does
this dance to have some fields copied from the package to its -dbgsym
offspring, which could contain substvars and hence the -T/dev/null might
be the regression here, but I am not sure as I did not dare too look too
deeply under the hood (or in version control) for the time being.
On a sidenote, while writing this, using "misc:Core-Ver" seems silly…
but deb-substvars(5) doesn't seem to offer a hint at a reasonable naming
scheme less likely to conflict with future changes. Other packages use
":" which seems more reasonable at a glance, so might that
be a good suggestion that could be added there?
Best regards
David Kalnischkies
P.S.: I do consider my sbuild setup reasonably normal/standard, so
I spare you the details, but I am happy to add them if it turns out
I am more of a unique snowflake here than I am assuming.
signature.asc
Description: PGP signature
Bug#1067363: polymake: FTBFS: dpkg-shlibdeps: error: no dependency information found for /lib/x86_64-linux-gnu/libflint.so.19 (used by debian/libpolymake4.11/usr/lib/libpolymake.so.4.11)
Control: reassign -1 flint Lucas Nussbaum writes: > Source: polymake > Version: 4.11-2 > Severity: serious > Justification: FTBFS > Tags: trixie sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20240319 ftbfs-trixie > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > I'm fairly sure this is actually a bug in flint.
Bug#1067663: org-mode: Org mode 9.6.23 that fixes several critical
Package: org-mode Version: 9.6.10+dfsg-1 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: debian-emac...@lists.debian.org, Debian Security Team -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 In https://list.orgmode.org/87o7b3eczr@bzg.fr/T/#t, Ihor Radchenko writes I just released Org mode 9.6.23 that fixes several critical vulnerabilities. The release is coordinated with emergency Emacs 29.3 release (https://lists.gnu.org/archive/html/info-gnu/2024-03/msg5.html). Please upgrade your Org mode *and* Emacs ASAP. The vulnerabilities involve arbitrary Elisp and LaTeX evaluation when previewing attachments in Emacs or when opening third-party Org files. - -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 6.6.15-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages org-mode depends on: ii elpa-org 9.6.10+dfsg-1 org-mode recommends no packages. org-mode suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmYBSjMACgkQA0U5G1Wq FSHjuA/+PbZdJex2gariys1U8zA9ExAUW0TKE2Pt/k/bngZt9+B7JGm1bNqSMkBm mPN+6uIEZdmmasNCqHzNwlxPyezWnL1ik4n3lfz1fkXMSf7YWExcL/rnBvsc6aqi yzTB0IPP2+1Jx0BV3ysiX62eRlLXiv3NlJQuKHyOwVCjOUDJUdN25YgZQ7b4Q2/S 4lC6O1wkmJqyV/PopvHIeFTo76l8Cg612ZGFrdniXkWB4zUSl2MdfsduimFO4xfp /izY1u7nCT+bdsKT6OdvKqV5bStEukiklo/A2V9KTWrAQ2xeNwgE0gtP6MYzVfZ+ f7of4+SCqt0dZMwLiuZse+XA82nPnDqSdiT5A5EGRQ8am5BQ9d0weOoaQMho3vym bUQO0rdU0MCrZR3MxCH4YPKm1ge1wPS7zLL48/+6PFhlHHkmQ1t98EzCbJ+gEgJW Qm/wnT0ctJRmp2uqGDpRLeI0t+YU/kyfaaHS/rB7XSkQN6vBmJKnClGmgFnhVphR hrQVVpJjD0SeZSv9uOUI17HfPz9v3pIKLCMs4R2+WTddxf6bdXytFmlOWBlcvEpE 0ocIW00D68jDWx0Bq1PItEJ11V9GbcqrigtBHfEocYVnL4hB3x5lkaGkMF5P2gOn 4OL3eC+UqJoEpr53PiD5fdbo7WkeI3NCdDBqb/GDn9Kj4HQyZqY= =aTCW -END PGP SIGNATURE-
Bug#1067655: RM: php-league-uri-interfaces -- ROM; Superseded by php-league-uri-src
Control: affects -1 + src:php-league-uri-interfaces Le Mon, Mar 25, 2024 at 09:15:11AM +0100, David Prévot a écrit : […] > Hi, > > Please remove the php-league-uri-interfaces source package. The php-league-uri-interfaces binary package is now built by php-league-uri-src, so the php-league-uri-interfaces source package has become useless. Regards, taffit signature.asc Description: PGP signature
Bug#1067656: RM: php-league-uri -- ROM; Superseded by php-league-uri-src
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: php-league-...@packages.debian.org Control: affects -1 + src:php-league-uri-src Control: affects -1 + src:php-league-uri User: ftp.debian@packages.debian.org Usertags: remove Hi, The php-league-uri binary package is now built by php-league-uri-src, so the php-league-uri source package has become useless. Regards, taffit signature.asc Description: PGP signature
Bug#1067655: RM: php-league-uri-interfaces -- ROM; Superseded by php-league-uri-src
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: php-league-uri-...@packages.debian.org Control: affects -1 + src:php-league-uri-src User: ftp.debian@packages.debian.org Usertags: remove Hi, Please remove the signature.asc Description: PGP signature
Bug#1067630: emacs: release 29.3 fixes "several security vulnerabilities"
Source: emacs Version: 29.2+1-2 Severity: grave Tags: security upstream Justification: user security hole X-Debbugs-Cc: Debian Security Team , debian-emac...@lists.debian.org -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 According to the 29.3 release notes * Changes in Emacs 29.3 Emacs 29.3 is an emergency bugfix release intended to fix several security vulnerabilities described below. ** Arbitrary Lisp code is no longer evaluated as part of turning on Org mode. This is for security reasons, to avoid evaluating malicious Lisp code. ** New buffer-local variable 'untrusted-content'. When this is non-nil, Lisp programs should treat buffer contents with extra caution. ** Gnus now treats inline MIME contents as untrusted. To get back previous insecure behavior, 'untrusted-content' should be reset to nil in the buffer. ** LaTeX preview is now by default disabled for email attachments. To get back previous insecure behavior, set the variable 'org--latex-preview-when-risky' to a non-nil value. ** Org mode now considers contents of remote files to be untrusted. Remote files are recognized by calling 'file-remote-p'. - -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: arm64 Kernel: Linux 6.6.15-amd64 (SMP w/20 CPU threads; PREEMPT) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled - -- no debconf information -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEkiyHYXwaY0SiY6fqA0U5G1WqFSEFAmYAhNIACgkQA0U5G1Wq FSEANg//cukjqohXxNRpkxbutqHHvOB1aAr3d78jowjP3Yb9ozAArNxUjuJHEdSZ 5HCASm269atf5753maZILjyx3VmF/qUihyGjbbWjqMwNrQkkQiuXBfYn1F4R76/V tyFile5NZVXIgYMykLb+rSHap6KMBnhjvLWSwNsDMuD8WB7OPH7KOI2xYqkUb7ue SIgkCr0GJ+LaHOAYlRKkAYok4qwIfijLBw41Bt7t9Tawh+5d5nDkNPDphFOB+bG+ 1hOQD8KVYWIceRK83wcDictSxbeTSo/cp6cEtVZX3yrDvBRbj3VKjKWL+0UIKfWO iGWQYn622B7WbBIwEddQMmla+nxa5rxEN9VMEE8N5xcpI1lnL0lVSxw0jbT0FopJ PmwFYmz1+pxB2fhRTv1T7ZTSAJS3BKQ9u2R8tuKO5ilSYp1zJrBBIazGPZ3Q+UBS EoPh4hy5G4IZ3X3yaE9cX76fdDMMGPQ7HIinkw5A7KWb8zHse5m3+WG+iPNuveHU GRwOB9pDDRTQrQVG8of2YVS0kLb9eu2jUD0sbi8As3P5Mr/gXHlrSgs5t1qg3HuA Kkg7m7PAONZu0LBZNZsItm/V0weDqBdE+LZsa/1LUk3H+zvswhctlNLuZ7Y4mKqh YpuwmZ2+cv1To2M/DKbBx2ngl5EiojF8hk5pGezcZ811NRFAQKc= =BxE4 -END PGP SIGNATURE-
Bug#1067620: add max version to python3-ruamel.yaml dependency
Package: whipper Version: 0.10.0-2 From https://github.com/whipper-team/whipper/issues/605 and https://github.com/whipper-team/whipper/issues/606 it looks like whipper fails with newer version of ruamel.yaml. Should the Debian package add a max version to the dependency to prevent it breaking when python3-ruamel.yaml is updated?
Bug#1067539: 4.11-2.1~exp1 does not fix it
Joachim Zobel writes: > I just ran a pbuilder build of experimental for gap polymaking. The > error message persists. The version of flint in unstable has an uncoordinated transition to SONAME libflint19. As far as I can tell this is from Julien's commit 711f501dec6ed05ac5c6d4b21eb428b5cfc48da3. There is a certain amount of confusion due to the t64 transition, but I think there is an RC bug about this already for flint. In summary I don't think this is a polymake bug. Or at least there is an RC bug in flint that should probably be fixed first, before we can debug polymake.
Bug#1067539: Causes FTBFS for gap-polymaking by failing tests 2
Joachim Zobel writes: > Package: polymake > Version: 4.11-2 > Severity: important > > Hi. > > I am seeing FTBFS for my packages gap-polymaking and gap-hapcryst. > The error message is > >> Can't load '/usr/lib/polymake/perlx/5.38.2/x86_64-linux-gnu-thread- > multi/auto/Polymake/Ext/Ext.so' for module Polymake::Ext: > libflint.so.18: cannot open shared object file: No such file or > directory at /usr/lib/x86_64-linux-gnu/perl-base/DynaLoader.pm line > 201. > > This is most likely caused by the latest version of libflint beeing > libflint18t64. The bug is similiar to #1053316, just the library is > different. I see the NMUed "t64" version of polymake has not been uploaded to unstable yet, so I assume that transition is still in progress for polymake.
Bug#1066103: icingaweb2-module-cube: [INTL:de] updated German po file translation
close #1066103 1.3.1-1 thanks Hi, this bug has been fixed in above version, hence closing. Regards, David
Bug#1052659: icingaweb2-module-cube: [INTL:nl] Dutch debconf templates translation
close #1052659 1.1.1-4 thanks Hi, this bug has been fixed in above version, hence closing. Regards, David
Bug#1052657: icingaweb2-module-nagvis: [INTL:nl] Dutch debconf templates translation
close #1052657 1.1.1-4 thanks Hi, this bug has been fixed in above version, hence closing. Regards, David
Bug#1066102: icingaweb2-module-nagvis: [INTL:de] updated German po file translation
close #1066102 1.1.1-4 thanks Hi, this bug has been fixed in above version, hence closing. Regards, David
Bug#1065628: [INTL:es] Spanish translation of icingaweb2-module-incubator debconf template
Close #1065628 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066921>0.20.0-2 Thanks Hi, this bug has been fixed in above version, hence closing. Regards, David
Bug#1038919: icingaweb2-module-graphite: [L10N,DE] icingaweb2-module-graphite updated german programm translation
close #1038919 1.2.3-1 thanks Hi, this bug has been fixed in above version, hence closing. Regards, David
Bug#1066923: icingaweb2-module-generictts: [INTL:de] updated German po file translation
close #1066923 2.1.0-2 thanks Hi, this bug has been fixed in above version, hence closing. Regards, David
Bug#1066919: icingaweb2-module-fileshipper: [INTL:de] updated German po file translation
close #1066919 1.2.0-3 thanks Hi, this bug has been fixed in above version, hence closing. Regards, David
Bug#1066921: icingaweb2_module_eventdb: [INTL:de] updated German po file translation
Close #1066921 <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1066921> 1.3.0-4 Thanks Hi, this bug has been fixed in above version, hence closing. Regards, David
Bug#1065083: $icingaweb2-module-director: [INTL:de] updated German icingaweb2-module-director translation\
close #1065083 1.10.2-2 thanks Hi this bug has been fixed in above version, hence closing. Regards, David
Bug#1064726: 0ad: FTBFS: ImportError: cannot import name 'dist' from 'distutils' (/usr/lib/python3.11/distutils/__init__.py)
Hi, I found that adding Build-Depends: python3-distutils solves this problem. The natural question is why did build of 0ad work in the past, but not now. I found that python3-distutils was being pulled in only as a side effect of one of the dependencies, libsdl2-dev. The build failure is caused by the fact that the Debian package of glib2.0 stopped depending on python3-distutils as of 23 Jan 2024. Specifically, libsdl2-dev depends on libibus-1.0-dev, which depends on libglib2.0-dev, which depends on libglib2.0-dev-bin, which used to depend on python3-distutils, but now depends on python3-packaging. This change was made to libglib2.0-dev-bin in version 2.78.3-2 on 23 Jan 2024. I've committed the Build-Depends change to Debian Salsa. Thanks. -- David W. Kennedy
Bug#1057394: Resolve FTBFS
Hi, I've been looking at this via Ubuntu 24.04 since it has the same FTBFS. I've PRd a fix upstream for this and have enclosed a debdiff for the suggested fix here. thanks David content_patch.debdiff Description: Binary data
Bug#990451: [EXT]Re: Bug#990451: (no subject)
On Fri, Mar 15, 2024 at 07:24:32PM -0700, Chandler Sobel-Sorenson wrote: > David Kalnischkies wrote on 3/13/24 2:28 AM: > > What would this achieve; what is the use case? > The use case is when a repo has too many versions of a software on it. > I'd only be interested in seeing the details for the Installed and > Candidate versions, so even my initial --versions suggestion is not good > enough for that. So, your request is to add a saw-blade to a hammer just in case you might have a need for tree chopping with policy some day? If you are about details about specific versions, I would suggest using e.g. "apt show foo=version" or "apt show foo" (= that displays only info about the candidate) or "apt show foo/now" (= currently installed). Or go crazy with some apt-patterns(8). Or, you use "apt-cache show foo" (for info about all versions) and select with some (dctrl-)grep'ing. > […] > Fax mentis incendium gloriæ culpum et cetera, et cetera... > > Memor bis punitor delicatum! Omnia dicta fortiora si dicta Latina.¹ I wasn't quiet sure if you are serious or not, but I see now that you are indeed just trying to troll. Very funny. Did I pass the test now? Can't wait for my life time supply of chocolate, Mr. Wonka. Reference: https://yewtu.be/watch?v=WW2qaBJWdaA (many more videos show a bit more or less of the scene – that one just has hard coded subs; spoiler alert for "Willy Wonka & the Chocolate Factory" from 1971 …) > > Best regards > You sure? "You lose! Good day, Sir." David Kalnischkies ¹ everything sounds more impressive when said in Latin signature.asc Description: PGP signature
Bug#1066949: slic3r-prusa: Unneeded build dependencies on xvfb, xauth
Source: slic3r-prusa Version: 1.37.1+dfsg2-1 Severity: minor Dear Maintainer, Please drop xvfb and xauth from the build dependencies for slic3r-prusa. Prior to version 1.37.1+dfsg2-1 of slic3r-prusa, the debian/rules file made use of xvfb (and, by extension, xauth), but this is no longer the case. Thanks, -- Plasma
Bug#1065831: document package specifiers for `upgrade`
(this reply has nothing to do with the bugreport in question) On Wed, Mar 13, 2024 at 10:00:56PM +0100, Miguel Angel Rojas wrote: > >> Julian provided an explanation in #74, > 20240312113620.ga1944...@debian.org > > I can't access this link.. It isn't a link, it is a message id of an email. Your mail client (or web frontend or whatever) should find the mail if you search for it – assuming you got that mail and haven't deleted it in the meantime of course. You can also make it a link by prepending https://lists.debian.org/, aka: https://lists.debian.org/20240312113620.ga1944...@debian.org That will search for the mail in Debians mailing list archives. Best regards David Kalnischkies signature.asc Description: PGP signature
Bug#900572: Packaging PoC
control: tag -1 patch Hi, I’ve prepared a php-sqlsrv package for Bullseye (I had to stick with version 5.10 for PHP 7.4), it should work almost out of the box for Bookworm and unstable. I don’t intend to upload it to Debian proper, but it’s available in a public repository. https://gitea.evolix.org/dprevot/php-sqlsrv Regards, -- David Prévot Marseille (37 rue Guibal, Pôle Média, 13003) / Paris / Montréal http://evolix.com | Twitter: @Evolix @EvolixNOC | http://blog.evolix.com
Bug#900568: Packaging PoC
control: tag -1 patch Hi, I’ve prepared a php-pdo-sqlsrv package for Bullseye (I had to stick with version 5.10 for PHP 7.4), it should work almost out of the box for Bookworm and unstable. I don’t intend to upload it to Debian proper, but it’s available in a public repository. https://gitea.evolix.org/dprevot/php-pdo-sqlsrv Regards, -- David Prévot Marseille (37 rue Guibal, Pôle Média, 13003) / Paris / Montréal http://evolix.com | Twitter: @Evolix @EvolixNOC | http://blog.evolix.com
