Bug#1069449: firejail: FTBFS on armhf: ccnMX2lv.s:1765: Error: symbol `fopen64' is already defined

On 2024-04-20 14:51:12 +0200, Lucas Nussbaum wrote: > > /tmp/ccnMX2lv.s: Assembler messages: > > /tmp/ccnMX2lv.s:1765: Error: symbol `fopen64' is already defined > > /tmp/ccnMX2lv.s:2079: Error: symbol `freopen64' is already defined > > /tmp/ccnMX2lv.s:3164: Error: symbol `__stat64_time64' is

Bug#1071829: fail2ban: spurious ">" character in paths-debian.conf

Package: fail2ban Version: 1.1.0-3 Severity: grave Justification: renders package unusable The /etc/fail2ban/paths-debian.conf file starts with ># Debian which yields an error: May 25 10:39:45 qaa systemd[1]: Started fail2ban.service - Fail2Ban Service. May 25 10:39:45 qaa

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

On 2024-05-24 14:52:08 +0200, Sylvestre Ledru wrote: > Could you please propose a PR ? I didn't find the time to fix this lately > (and i don't use fail2ban anymore). https://salsa.debian.org/python-team/packages/fail2ban/-/merge_requests/9 This restores the use of nftables and selects the

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

On 2024-05-07 08:35:28 +0200, Sylvestre Ledru wrote: > > Le 07/05/2024 à 03:57, Vincent Lefevre a écrit : > > On 2024-05-07 03:28:28 +0200, Vincent Lefevre wrote: > > > May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,226 > > > fail2ban

Bug#1071372: emacs: it hangs saving .gpg files (without using cpu)

On 2024-05-20 01:03:00 +0200, Vincent Lefevre wrote: > The issue remains after downgrading the emacs packages to testing > (1:29.3+1-2). And it disappears after downgrading the packages of gnupg2 source to 2.2.40-3. The issue about the file disappearing does not occur with "emacs -Q&

Bug#1071372: emacs: it hangs saving .gpg files (without using cpu)

Control: found -1 1:29.3+1-2 On 2024-05-20 00:45:40 +0200, Vincent Lefevre wrote: > On 2024-05-18 01:22:03 +0200, Alex Andreotti wrote: > > [...] Probably a "recent" apt upgrade broke it but I don't know > > exactly which one, before this problem I used to save .gpg

Bug#1070713: how-can-i-help: undefined local variable or method autorm_header_done

On 2024-05-10 12:20:43 +0200, Diederik de Haas wrote: > Control: severity -1 grave > > On 07 May 2024 19:35:30 +0200 Nicolas Noirbent wrote: > > Package: how-can-i-help > > Version: 18 > > Severity: important > > Tags: patch > > > > Running how-can-i-help outputs nothing past the initial

Bug#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean

Control: reopen -1 On 2024-05-07 11:25:05 +0200, Vincent Lefevre wrote: > What's the status of this bug? > > apt-listbugs still reports python3-lxml as buggy: > > serious bugs of python3-lxml (5.1.0-1 → 5.2.1-1) > b1 - #1068349 - nbsphinx/nbconvert broken by lxml 5.

Bug#1068349: nbsphinx/nbconvert broken by lxml 5.2: lxml.html.clean

On 2024-04-07 22:06:05 +0100, Rebecca N. Palmer wrote: > To avoid being blocked by this bug, the pandas version I just uploaded > temporarily disables the documentation. > > This is also an option for any other affected packages that urgently need to > be uploaded. (I don't know whether the

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

On 2024-05-07 03:57:44 +0200, Vincent Lefevre wrote: > sshd_backend = systemd BTW, that would fix the issue only for sshd. But what about the other jails the user could have enabled in /etc/fail2ban/jail.local? The user configuration may rely on systemd being the default backend, at le

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

On 2024-05-07 03:28:28 +0200, Vincent Lefevre wrote: > May 07 03:01:28 qaa fail2ban-server[557228]: 2024-05-07 03:01:28,226 fail2ban >[557228]: ERROR Failed during configuration: Have not found > any log file for sshd jail I suppose that this is because sshd no lo

Bug#1070677: fail2ban fails: "Failed during configuration: Have not found any log file for sshd jail"

Package: fail2ban Version: 1.1.0-1 Severity: grave Justification: renders package unusable After the upgrade to 1.1.0-1, "systemctl status" gives × fail2ban.service - Fail2Ban Service Loaded: loaded (/usr/lib/systemd/system/fail2ban.service; enabled; preset: enabled) Active: failed

Bug#1070652: ruby-json: breaks how-can-i-help

Package: ruby-json Version: 2.7.2+dfsg-1 Severity: grave Justification: renders package unusable This new ruby-json version breaks how-can-i-help: [...] Unpacking ruby-json:amd64 (2.7.2+dfsg-1) over (2.6.3+dfsg-1+b2) ... Setting up ruby-json:amd64 (2.7.2+dfsg-1) ...

Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

Hi, On 2024-04-28 19:21:18 -0300, Facundo Gaich wrote: > Today I upgraded one of my unstable machines and saw several instances of > something I believe is the same bug. The resolver seems to be failing to > choose to upgrade certain dependencies. What's more, in the aptitude GUI > I can see the

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

Here's the /var/log/apt/history.log part that corresponds to this upgrade: Start-Date: 2024-04-28 22:05:30 Upgrade: libsmartcols1:amd64 (2.40-6, 2.40-8), libvpx8:amd64 (1.13.1-2, 1.13.1-2+b1), libltdl7:amd64 (2.4.7-7, 2.4.7-7+b1), libpaper1:amd64 (1.1.29, 1.1.29+b1), libnftnl11:amd64 (1.2.6-2,

Bug#1070027: fdisk: dependency problems prevent configuration of fdisk

Package: fdisk Version: 2.40-8 Severity: serious During an upgrade with aptitude 0.8.13-6, I got: Extracting templates from packages: 100% Preconfiguring packages ... (Reading database ... 417244 files and directories currently installed.) Preparing to unpack .../bsdutils_1%3a2.40-8_amd64.deb

Bug#1067316: gnucash-docs: FTBFS: Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/jvm/java-17-openjdk-amd64/lib/libfontmanager.so: libharfbuzz.so.0: cannot open shared object file:

[Not reassigning yet to openjdk-17-jre-headless, as the change was done on purpose, but Cc-ing the OpenJDK Team.] Hi, Since no-one looked at this issue in a month and gnucash-docs has now been removed from testing... On 2024-03-20 22:03:18 +0100, Lucas Nussbaum wrote: [...] > > Exception in

Bug#1068637: apt does not always install Recommends

Package: apt Version: 2.7.14 Severity: serious The lvm2 package is installed, but not thin-provisioning-tools, though lvm2 recommends it. This can yield a broken system: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857142 the fix of this bug being * Make lvm2 recommend

Bug#1041089: thin-provisioning-tools FTBFS with googletest 1.13.0

On 2024-01-13 10:23:06 +0100, Bastian Blank wrote: > On Sat, Jan 13, 2024 at 01:03:17AM +0100, Karsten Kruse wrote: > > Is there something else that needs to be done to get the package back into > > testing? > > Yes, > https://salsa.debian.org/rust-team/debcargo-conf/-/merge_requests/547 Any

Bug#1067523: firefox: CVE-2024-29943 / CVE-2024-29944 critical bugs, fixed in FF 124.0.1

Package: firefox Version: 124.0-1 Severity: grave Tags: security upstream fixed-upstream Justification: user security hole X-Debbugs-Cc: Debian Security Team Firefox 124.0.1 is available upstream, which fixes 2 critical bugs: https://www.mozilla.org/en-US/security/advisories/mfsa2024-15/ --

Bug#1065331: libhdf5-103-1t64: depends on libcurl4 instead of libcurl4t64

On 2024-03-18 20:58:02 +0100, Gilles Filippini wrote: > Vincent Lefevre a écrit le 03/03/2024 à 01:08 : > > Package: libhdf5-103-1t64 > > Version: 1.10.10+repack-3.1 > > Severity: serious > > > > libhdf5-103-1t64 depends on libcurl4 instead of libcurl4t64. &

Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

And on a 3rd machine, where I used aptitude --log-file=/tmp/aptitude.log --log-level=info dpkg: dependency problems prevent removal of libb2-1:amd64: libqt6core6t64:amd64 depends on libb2-1 (>= 0.98.1). dpkg: error

Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

The same problem occurred on another machine, with other packages: dpkg: dependency problems prevent removal of libjte2:amd64: libisofs6t64:amd64 depends on libjte2. dpkg: error processing package libjte2:amd64 (--purge): dependency problems - not removing (Reading database ... 708510 files

Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

On 2024-03-07 17:15:05 +, Simon McVittie wrote: > I can confirm that version 2.24.33-4 of libgtk2.0-common, libgtk2.0-0t64 > and libgtk2.0-bin are, in fact, installable (I have them installed > right now). I can't see any dependency relationships between them that > look suspicious. > > If

Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

On 2024-03-07 16:00:35 +0100, Vincent Lefevre wrote: > Will install 11 packages, and remove 3 packages. > 8192 B of disk space will be used > > [...] > [HOLD, DEPENDENCIES] libmtp-common:amd64 1.1.21-3 > [...] > [INSTALL, DEPENDENCIES]

Bug#1065626: libgtk2.0-0t64 / libgtk2.0-bin dependency problem makes dpkg fail with attempt of removal of libgtk2.0-common

Package: libgtk2.0-0t64 Version: 2.24.33-4 Severity: serious During an upgrade with aptitude: dpkg: dependency problems prevent removal of libgtk2.0-common: libgtk2.0-bin depends on libgtk2.0-common. libgtk2.0-0t64:amd64 depends on libgtk2.0-common. dpkg: error processing package

Bug#1065625: libmtp9t64 / libmtp-runtime dependency problem makes dpkg fail with attempt of removal of libmtp-common

Package: libmtp9t64 Version: 1.1.21-3.1 Severity: serious During an upgrade with aptitude: dpkg: dependency problems prevent removal of libmtp-common: libmtp9t64:amd64 depends on libmtp-common. libmtp-runtime depends on libmtp-common. dpkg: error processing package libmtp-common (--purge):

Bug#1065603: libdebuginfod1t64 dependency problem breaks the upgrade

Control: retitle -1 libdebuginfod1t64 dependency problem makes dpkg fail with attempt of removal of libdebuginfod-common On 2024-03-07 11:28:21 +0100, Vincent Lefevre wrote: > When I wanted to upgrade, this ended up with > > dpkg: dependency problems prevent removal of libdebuginf

Bug#1065603: libdebuginfod1t64 dependency problem breaks the upgrade

Package: libdebuginfod1t64 Version: 0.190-1.1 Severity: serious When I wanted to upgrade, this ended up with dpkg: dependency problems prevent removal of libdebuginfod-common: libdebuginfod1t64:amd64 depends on libdebuginfod-common (>= 0.190-1.1). dpkg: error processing package

Bug#1065331: libhdf5-103-1t64: depends on libcurl4 instead of libcurl4t64

On 2024-03-03 01:08:10 +0100, Vincent Lefevre wrote: > Package: libhdf5-103-1t64 > Version: 1.10.10+repack-3.1 > Severity: serious > > libhdf5-103-1t64 depends on libcurl4 instead of libcurl4t64. > This makes the upgrade of curl impossible. It seems that this was actually a

Bug#1065331: libhdf5-103-1t64: depends on libcurl4 instead of libcurl4t64

Package: libhdf5-103-1t64 Version: 1.10.10+repack-3.1 Severity: serious libhdf5-103-1t64 depends on libcurl4 instead of libcurl4t64. This makes the upgrade of curl impossible. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'),

Bug#1064982: gnuplot-qt: gnuplot displays a window with nothing in it

On 2024-02-28 19:20:58 +0100, Vincent Lefevre wrote: > Before the upgrade to gnuplot 6, everything was fine. But after > the upgrade, I get a window where nothing is drawn, i.e. I just > get what's *behind* the window. That's always reproducible on > this machine. > > I've trie

Bug#1064982: gnuplot-qt: gnuplot displays a window with nothing in it

Package: gnuplot-qt Version: 6.0.0+dfsg1-1 Severity: grave Justification: renders package unusable Before the upgrade to gnuplot 6, everything was fine. But after the upgrade, I get a window where nothing is drawn, i.e. I just get what's *behind* the window. That's always reproducible on this

Bug#1064969: apt: can't upgrade with aptitude

On 2024-02-28 15:56:56 +0100, Julian Andres Klode wrote: > aptitude is not our chosen tool for distribution upgrades, as such > failures there are not release critical for the packages. So while > this is release critical for aptitude, it's a wishlist bug for apt > that probably would end up being

Bug#1064969: apt: can't upgrade with aptitude

Source: apt Version: 2.7.12+nmu1 Severity: serious While there are no upgrade issues with apt itself (according to "apt install -s apt"), aptitude does not want to upgrade apt automatically, while this just appears to be a package rename: # aptitude install apt The following packages will be

Bug#1055067: isc-dhcp-client: network-manager 1.44.2-3 changed path to nm-dhcp-helper, apparmor need update

On 2024-02-26 00:22:01 +0100, Sven-Haegar Koch wrote: > While installing your test package I lost wifi connection, but I think > that was not from your package but from updating network-manager from > unstable at the same time (did dist-upgrade), which always breaks my > network. With the

Bug#1064402: luametatex: "mtxrun --generate": lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'

Control: retitle -1 luametatex: "mtxrun --generate": lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i' More accurate title, as described below. On 2024-02-21 16:15:31 +0100, Vincent Lefevre wrote: > Indeed, I can reproduce the problem on an

Bug#1064402: texlive-binaries: tex-common configure: lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'

Control: reassign -1 luametatex 2.11.01+ds-2 Control: severity -1 grave Control: affects -1 texlive-binaries On 2024-02-21 15:46:04 +0100, Vincent Lefevre wrote: > On 2024-02-21 15:28:17 +0100, Vincent Lefevre wrote: > > /tmp/mtxrun.gd7J0NKo just contains: > > > > lua error

Bug#1064402: texlive-binaries: tex-common configure: lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'

On 2024-02-21 15:28:17 +0100, Vincent Lefevre wrote: > /tmp/mtxrun.gd7J0NKo just contains: > > lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const > variable 'i' > > Note: the tex-common and context (from which /bin/mtxrun.lua comes > from) a

Bug#1064402: texlive-binaries: tex-common configure: lua error : startup file: /bin/mtxrun.lua:2438: attempt to assign to const variable 'i'

Package: texlive-binaries Version: 2023.20230311.66589-8+b1 Severity: serious When upgrading TeX Live: [...] Processing triggers for tex-common (6.18) ... Running mktexlsr. This may take some time... done. Running mtxrun --generate. This may take some time... mtxrun --generate failed. Output

Bug#1061438: tpm2-tss: can't upgrade the tpm2-tss packages to 4.0.1-6; missing Conflicts?

Source: tpm2-tss Version: 4.0.1-6 Severity: serious It is not possible to upgrade the tpm2-tss packages to 4.0.1-6 with "apt upgrade" or with aptitude (command line or its TUI, without a *manual* dependency resolution): root@disset:~# apt upgrade Reading package lists... Done Building dependency

Bug#1059314: imagemagick-6.q16: please update "Suggests: imagemagick-doc" to imagemagick-6-doc

Package: imagemagick-6.q16 Version: 8:6.9.12.98+dfsg1-4 Severity: serious The imagemagick-doc package is not longer built and has been replaced by imagemagick-6-doc. So the "Suggests" should be updated. Note that the current Suggests can prevent installations/upgrades if suggested packages are

Bug#1059193: imagemagick-6-doc: missing Breaks+Replaces against the dropped imagemagick-doc package, in order to force its removal

Package: imagemagick-6-doc Version: 8:6.9.12.98+dfsg1-4 Severity: serious Justification: Policy 7.6.2 On my new laptop, I can't upgrade the imagemagick packages automatically from 8:6.9.11.60+dfsg-1.6 to 8:6.9.12.98+dfsg1-4 with aptitude (I need to enter the dependency resolution so that

Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau

Another piece of information: this is a regression. With the 6.1.0-16-amd64 kernel from stable, "journalctl -b -g ga107" gives Dec 19 04:57:07 qaa kernel: nouveau :01:00.0: NVIDIA GA107 (b77000a1) Dec 19 04:57:07 qaa kernel: nouveau :01:00.0: firmware: failed to load

Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau

On 2023-12-19 04:32:02 +0100, Vincent Lefevre wrote: > firmware-misc-nonfree triggers the following warnings: > > update-initramfs: Generating /boot/initrd.img-6.5.0-5-amd64 [...] > W: Possible missing firmware /lib/firmware/nvidia/ga107/acr/ucode_ahesasc.bin > for module nouvea

Bug#1058991: firmware-misc-nonfree: Possible missing firmware for module nouveau, kernel crash in nouveau

Package: firmware-misc-nonfree Version: 20230625-1 Severity: grave Justification: renders package unusable firmware-misc-nonfree triggers the following warnings: update-initramfs: Generating /boot/initrd.img-6.5.0-5-amd64 W: Possible missing firmware /lib/firmware/rtl_nic/rtl8156b-2.fw for

Bug#1057355: libmpfr6: major formatted output function bugs with %c and the value 0

Control: tags -1 fixed-upstream On 2023-12-03 22:13:03 +0100, Vincent Lefevre wrote: > I've reported the following bug in the MPFR mailing-list. I think > I've fixed the issues on the MPFR side in master, but MPFR is still > affected by the bug on the GMP side (gmp_vasprintf): >

Bug#1058690: liblatex-tounicode-perl: trying to overwrite .../ltx2unitxt.1.gz, which is also in package texlive-bibtex-extra 2023.20231207-1

Package: liblatex-tounicode-perl Version: 0.54-1 Severity: serious As a consequence of the upgrade of texlive-bibtex-extra to 2023.20231207-3: [...] Selecting previously unselected package liblatex-tounicode-perl. (Reading database ... 711147 files and directories currently installed.) Preparing

Bug#1057151: clang-17: ClangTargets.cmake cannot find libclang-17.so.1

Control: reassign -1 libclang1-17 1:17.0.6-1 because the problem is actually there (and this package may be installed even if clang-17 isn't). On 2023-11-30 12:13:21 -0700, Cordell Bloor wrote: > While attempting to update rocm-device-libs, I noticed that searching > for clang with

Bug#1057355: libmpfr6: major formatted output function bugs with %c and the value 0

Package: libmpfr6 Version: 4.2.0-1 Severity: grave Tags: security upstream Justification: user security hole Forwarded: https://sympa.inria.fr/sympa/arc/mpfr/2023-12/msg0.html X-Debbugs-Cc: Debian Security Team I've reported the following bug in the MPFR mailing-list. I think I've fixed the

Bug#1057344: libgmp10: major formatted output function bug with %c and the value 0

Package: libgmp10 Version: 2:6.2.1+dfsg1-1.1 Severity: grave Tags: security upstream Justification: user security hole Forwarded: https://gmplib.org/list-archives/gmp-bugs/2023-December/005420.html X-Debbugs-Cc: Debian Security Team I've reported the following bug upstream. Debian/stable is

Bug#1056313: network-manager: breaks networking

On 2023-11-20 12:24:36 +0100, Vincent Lefevre wrote: > Note: the errors about /usr/libexec/nm-dhcp-helper changed to > > Nov 20 12:17:42 cventin dhclient[295468]: execve > (/usr/libexec/nm-dhcp-helper, ...): No such file or directory > > but the network is workin

Bug#1056313: network-manager: breaks networking

On 2023-11-20 12:42:14 +0100, Vincent Lefevre wrote: > I suspect that nm-dhcp-helper has been added because it is now needed. > But it doesn't work due to the "Permission denied". If I understand correctly, /usr/lib/NetworkManager/nm-dhcp-helper moved to /usr/libexec/nm-dhcp-

Bug#1056313: network-manager: breaks networking

Control: found -1 1.44.2-3 Control: retitle -1 network-manager: breaks networking (Permission denied for the new /usr/libexec/nm-dhcp-helper) On 2023-11-20 12:24:36 +0100, Vincent Lefevre wrote: > Package: network-manager > Version: 1.44.2-4 > Severity: grave > Justification: ren

Bug#1056313: network-manager: breaks networking

Package: network-manager Version: 1.44.2-4 Severity: grave Justification: renders package unusable Just after the upgrade of network-manager from 1.44.2-1 to 1.44.2-4, my network is down. In the journalctl logs, I can see [...] Nov 20 12:08:58 cventin NetworkManager[286424]: [1700478538.0092]

Bug#1041838: Bug#1041834: libclang-rt-16-dev: undeclared file conflict with libclang-rt-16-dev-wasm{32,64} on /usr/lib/llvm-16/lib/clang/16/lib/wasi/libclang_rt.builtins-wasm*.a

1838@b.d.o, so that I was confused). On 2023-11-09 14:13:37 +0100, Vincent Lefevre wrote: > On 2023-07-24 06:54:27 +0200, Helmut Grohne wrote: > > Control: clone -1 -2 > > Control: reassign -2 libclang-rt-17-dev > > > > On Mon, Jul 24, 2023 at 06:45:00AM +0200, Helmut G

Bug#1054650: dbus: makes the machine extremely slow, freezes on shutdown

Package: dbus Version: 1.14.10-2 Severity: critical Justification: breaks the whole system dbus 1.14.10-2 makes the machine extremely slow (this affects the boot, login, the su command, and package installation at least), and it freezes on shutdown. This is reproducible (I've tested on 2

Bug#1054022: libncursesw6: broken in GNU Screen

Via JuiceSSH+mosh under Android, if I hit a key, I can see spurious escape sequences in the output after the error message: ^[[1;1R^[[49;80R^[[49;80R^[[49;80R -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR

Bug#1054022: libncursesw6: broken in GNU Screen

On 2023-10-16 04:10:36 -0400, Thomas Dickey wrote: > But in a quick check to "upgrade", my sources.list to investigate this, > I get stopped by the "improvements". It might help if you posted the > corresponding sources.list (or are you using the separate gpg stuff?). I'm wondering why this

Bug#1054022: libncursesw6: broken in GNU Screen

Package: libncursesw6 Version: 6.4+20231007-1 Severity: grave Justification: renders package unusable With libncursesw6 6.4+20231007-1, I get the following issue: $ screen -dRR mutt /usr/bin/mutt [screen is terminating] after a few seconds (or immediately "[screen is terminating]" when I hit a

Bug#1041731: groff-base: "-" mapped as HYPHEN

On 2023-09-11 20:33:27 -0700, Russ Allbery wrote: > Yes, I understand why upstream really wants to find a way to make the > distinction between a language hyphen and an ASCII hyphen to work. They > are different characters in the *roff language, and in a proper > typesetting system such as troff

Bug#1052136: libcdb1: tries to overwrite /usr/share/man/man5/cdb.5.gz in tinycdb 0.78+b1

Package: libcdb1 Version: 0.80-1 Severity: serious When upgrading, I got: Unpacking libcdb1:amd64 (0.80-1) over (0.78+b1) ... dpkg: error processing archive /tmp/apt-dpkg-install-DmVfNl/25-libcdb1_0.80-1_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man5/cdb.5.gz', which is also in

Bug#1051116: maildrop: depends on libgcc1, which is no longer in the archive

On 2023-09-17 13:05:16 +0200, Sebastian Ramacher wrote: > On 2023-09-03 02:26:55 +0200, Vincent Lefevre wrote: > > Package: maildrop > > Version: 2.9.3-2+b1 > > Severity: grave > > Justification: renders package unusable > > > > maildrop depends on lib

Bug#1052040: mmm-mode: post-install script fails

Control: tags -1 - upstream The issue actually comes from the 01-xemacs patch. On 2023-09-16 17:46:23 +0200, Vincent Lefevre wrote: > An easy solution would be to avoid the XEmacs form (marked as > obsolete in GNU Emacs since 23.1 and whose support was removed > in GNU Emacs 28[*]), i.

Bug#1052040: mmm-mode: post-install script fails

Control: forwarded -1 https://github.com/dgutov/mmm-mode/issues/137 Control: tags -1 upstream On 2023-09-16 17:02:54 +0200, Vincent Lefevre wrote: > This appears to be related to macro expansion, which seems to > occur even if the code is not executed. An easy solution would be to

Bug#1052040: mmm-mode: post-install script fails

On 2023-09-16 16:53:33 +0200, Vincent Lefevre wrote: > If I understand correctly, the second define-obsolete-function-alias > (with 2 arguments) is executed instead of the first one (with 4 > arguments). This would mean that > > (string-match "XEmacs" (emacs-ver

Bug#1052040: mmm-mode: post-install script fails

Ditto here. On 2023-09-16 14:31:11 +0200, mister...@web.de wrote: > In toplevel form: > mmm-auto.el:178:4: Error: Wrong number of arguments: (3 . 4), 2 This seems to be due to this change: -(defalias 'mmm-add-find-file-hooks #'mmm-add-find-file-hook) +(if (not (string-match "XEmacs"

Bug#1051496: mailgraph: does not support the new syslog format

Control: tags -1 patch upstream On 2023-09-08 19:30:29 +0200, Vincent Lefevre wrote: > mailgraph no longer works after the upgrade to bookworm, and > this is probably due to the fact that it does not support the > new syslog format: /usr/sbin/mailgraph contains [...] > and

Bug#1051496: mailgraph: does not support the new syslog format

Package: mailgraph Version: 1.14-20 Severity: grave Justification: renders package unusable mailgraph no longer works after the upgrade to bookworm, and this is probably due to the fact that it does not support the new syslog format: /usr/sbin/mailgraph contains sub _next_syslog($) { [...]

Bug#1041492: xpra: FTBFS with ffmpeg 6.0

Control: tags -1 fixed-upstream On 2023-07-19 19:10:36 +0200, Sebastian Ramacher wrote: > xpra FTBFS with ffmpeg 6.0 (available in experimental) and in unstable since a few weeks. Any news? FYI, https://github.com/Xpra-org/xpra/blob/v3.1.x/src/NEWS says that this is fixed in v3.1.4

Bug#1051116: maildrop: depends on libgcc1, which is no longer in the archive

Package: maildrop Version: 2.9.3-2+b1 Severity: grave Justification: renders package unusable maildrop depends on libgcc1, which is no longer in the archive. This can be checked on https://packages.debian.org/en/bullseye/maildrop which says: dep: libgcc1 (>= 1:3.0) [not armel, armhf, i386,

Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken

On 2023-08-19 07:39:24 +0200, Ansgar wrote: > On Fri, 2023-08-18 at 22:45 +0200, Vincent Lefevre wrote: > > On 2023-08-18 07:35:33 +0200, Ansgar wrote: > > > Please investigate why "usrmerge" is not installed (I assume this is an > > > upgraded system).  Or

Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken

On 2023-08-18 07:35:33 +0200, Ansgar wrote: > This seems the be the real issue: > > +--- > | Debian Release: trixie/sid > | [...] > | merged-usr: no > +---[ https://bugs.debian.org/1049969#5 ] > > /bin *must* be a symlink to /usr/bin, so /usr/bin/run-parts must exist > and cron's PATH is

Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken

Control: retitle -1 cron-daemon-common: in /etc/crontab, run-parts is no longer in $PATH That's actually the real reason. /etc/crontab has PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin but zira:~> dlocate =run-parts debianutils: /bin/run-parts -- Vincent Lefèvre - Web:

Bug#1049969: cron-daemon-common: the /etc/cron.hourly line in /etc/crontab is broken

Package: cron-daemon-common Version: 3.0pl1-166 Severity: serious (set to serious because this is a regression whose effect will be to send a spurious mail every hour) After upgrading to 3.0pl1-166, I got a mail with Subject: Cron cd / && run-parts --report /etc/cron.hourly /bin/sh: 1:

Bug#1042892: nvidia-legacy-390xx-kernel-dkms: dkms module does not build against kernel 6.4

See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1042081 for the same bug corresponding to nvidia-kernel-dkms. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC

Bug#1042537: manpages-fr-dev: trying to overwrite '/usr/share/man/fr/man3/uuid_generate_time_safe.3.gz', which is also in package util-linux-locales 2.39.1-3

Package: manpages-fr-dev Version: 4.19.0-6 Severity: serious There's still an issue about the move of man pages (and symlinks) to util-linux-locales (see bugs 1037040 and 1042484 on the subject): Unpacking manpages-fr-dev (4.19.0-6) over (4.19.0-3) ... dpkg: error processing archive

Bug#1041789: RM: unison-2.51+4.13.1 -- RoQA; newer version packaged

On 2023-07-28 18:04:24 +0200, Stéphane Glondu wrote: > Note that I would like to keep unison-2.52 (even if a newer version > is packaged) at least in trixie, to allow synchronizing between > bookworm and trixie. Is this version really needed? /usr/share/doc/unison-2.52/NEWS.md.gz says: ##

Bug#1042484: util-linux-locales: /usr/share/man/fr/man1/lastb.1.gz is also in package manpages-fr 4.19.0-5

On 2023-07-29 12:06:01 +0200, Helge Kreutzmann wrote: > Hello Vincent, > On Sat, Jul 29, 2023 at 11:48:57AM +0200, Vincent Lefevre wrote: > > So I would say that this is rather a bug in src:manpages-l10n > > 4.19.0-5 (the new version meant to be compatible with > > uti

Bug#1042484: util-linux-locales: /usr/share/man/fr/man1/lastb.1.gz is also in package manpages-fr 4.19.0-5

CC'ed Helge Kreutzmann (maintainer of manpages-l10n). On 2023-07-29 07:30:30 +0200, Jean-Marc wrote: > Package: util-linux-locales > Version: 2.39.1-3 > Severity: serious > Justification: 6 > X-Debbugs-Cc: jean-m...@6jf.be > > Dear Maintainer, > > Upgrading util-linux-locales from 2.38.1-6 to

Bug#1041588: grep -r fails with "Operation not supported"

Control: tags -1 patch On 2023-07-21 19:38:08 +0200, Vincent Lefevre wrote: > Indeed, it's a bundled gnulib. I was surprised because there is > no "gnulib" directory. Actually these are just files under the m4 > directory. The bug is in "m4/dirfd.m4". I can see >

Bug#1041588: grep -r fails with "Operation not supported"

On 2023-07-21 13:08:11 -0400, Boyuan Yang wrote: > BTW: Is grep 3.11-1 using Debian-packaged gnulib anywere? I did not > see a build-dependency in > https://sources.debian.org/src/grep/3.11-1/debian/control/ . > > * If grep is indeed using it, please include the build-dep explicitly. > > * If

Bug#1041588: grep -r fails with "Operation not supported"

On 2023-07-21 17:22:11 +0200, Vincent Lefevre wrote: > The best solution would be to fix gnulib on the Debian side, IMHO. > I wonder whether other packages are affected too. [...] > So, if I understand correctly, the fix in gnulib appeared between > these two commits. But I don't see

Bug#1041588: grep -r fails with "Operation not supported"

On 2023-07-21 11:02:10 -0400, Boyuan Yang wrote: > Debian gnulib package maintainer here. I briefly checked grep source code, > and it seems that grep is using the bundled gnulib and not using the packaged > gnulib. Not 100% sure. > > Whether to use the bundled gnulib is up to the packager's

Bug#1041588: grep -r fails with "Operation not supported"

On 2023-07-21 04:06:51 +0200, Vincent Lefevre wrote: > On 2023-07-21 03:30:12 +0200, Vincent Lefevre wrote: > > There is a major regression in grep 3.11-1: I now get an error > > > > cventin:~/Mail> grep -r xxxyyyzzz oldarc > > grep: oldarc/cur: Operation not su

Bug#1041588: grep -r fails with "Operation not supported"

On 2023-07-21 03:30:12 +0200, Vincent Lefevre wrote: > There is a major regression in grep 3.11-1: I now get an error > > cventin:~/Mail> grep -r xxxyyyzzz oldarc > grep: oldarc/cur: Operation not supported And no such issue with grep from the upstream git. -- Vincent Lefèvre

Bug#1041588: grep -r fails with "Operation not supported"

Package: grep Version: 3.11-1 Severity: grave Justification: renders package unusable There is a major regression in grep 3.11-1: I now get an error cventin:~/Mail> grep -r xxxyyyzzz oldarc grep: oldarc/cur: Operation not supported This is just a big maildir mailbox (195700 messages). The

Bug#1039583: libltdl-dev: missing Breaks+Replaces: libltdl3-dev

Hi, On 2023-06-27 14:50:30 +0200, Andreas Beckmann wrote: > during a test with piuparts I noticed your package fails to upgrade from > 'lenny' to 'squeeze' to 'wheezy' to 'jessie' to 'stretch' to 'buster'. > It installed fine in 'lenny', and upgraded to 'squeeze', 'wheezy', > 'jessie', 'stretch',

Bug#1041229: dependency problems prevent configuration of libltdl-dev

And "apt install -f" cannot fix the error. I could downgrade the packages to testing (2.4.7-5), though. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP,

Bug#1041229: dependency problems prevent configuration of libltdl-dev

Package: libltdl-dev Version: 2.4.7-6 Severity: grave Justification: renders package unusable When upgrading, I got: E: Sub-process /usr/bin/dpkg returned an error code (1) dpkg: dependency problems prevent configuration of libltdl-dev:amd64: libltdl-dev:i386 (2.4.7-6) breaks libltdl3-dev and

Bug#816470: apt-show-versions may show incorrect package version for "Architecture: all" when a foreign arch is enabled

Control: forcemerge 858337 816470 1024765 I don't have the complete details for bug 816470, but this seems to be the same bug as 858337: this was also for "Architecture: all" with a foreign architecture. And the details in bug 1024765 show that this is the same bug as 858337. Actually, my

Bug#858337: apt-show-versions: wrong output when version of an installed package is missing from the Packages files

Control: retitle -1 apt-show-versions may show incorrect package version for "Architecture: all" when a foreign arch is enabled More precise bug title. The "*manually* upgradeable from" message is just a consequence. -- Vincent Lefèvre - Web: 100% accessible

Bug#858337: apt-show-versions: wrong output when version of an installed package is missing from the Packages files

Control: tags -1 patch On 2023-07-11 11:45:25 +0200, Vincent Lefevre wrote: > IMHO, for architecture "all", either only the Packages file that > corresponds to the main architecture of the machine should be > considered, or the latest version between the various packages

Bug#858337: apt-show-versions: wrong output when version of an installed package is missing from the Packages files

I think I've found the issue. If I add a "print" in the loop that builds $apackagescachefile: # Get available package information out of all Packages files foreach (@files) { print "file $_\n"; # Parse Packages file if creation time is newer than packages cache if (! -e

Bug#858337: apt-show-versions: wrong output when version of an installed package is missing from the Packages files

On 2023-07-11 09:31:54 +0200, Christoph Martin wrote: > Am 11.07.23 um 00:46 schrieb Vincent Lefevre: > > cventin:~> apt-show-versions -a libreoffice-common > > libreoffice-common:all 4:7.5.4-4 install ok installed > > libreoffice-common:all 4:7.4.5-3 stable ftp.

Bug#858337: apt-show-versions: wrong output when version of an installed package is missing from the Packages files

Hi Christoph, On 2023-07-10 16:36:56 +0200, Christoph Martin wrote: > Am 05.07.23 um 12:13 schrieb Vincent Lefevre: > > Control: retitle -1 apt-show-versions gives unreliable information > > Control: severity -1 grave > > I still can not reproduce your problem. > > Pl

Bug#1040675: ca-certificates-java: incorrect "Breaks:" versions about ubuntu

Package: ca-certificates-java Severity: serious ca-certificates-java 20230707 has Breaks: openjdk-11-jre-headless (<< 11.0.19+7~1~), openjdk-17-jre-headless (<< 17.0.8~6-3~), openjdk-18-jre-headless (<< 18.0.2+9-2ubuntu1~), openjdk-19-jre-headless (<< 19.0.2+7-0ubuntu4~),

Bug#1034348: at: autopkgtest regression on arm64

On 2023-07-05 18:58:13 +0200, Johannes Christ wrote: > Is there another way to reproduce this issue? I'm wondering whether there is a race condition in the test: # use at command to schedule a job. echo "echo `date` > ${WORKDIR}/${TMPFILE}" | at now + 1 minute So the file is expected to be

Bug#858337: apt-show-versions: wrong output when version of an installed package is missing from the Packages files

On 2023-07-05 12:13:54 +0200, Vincent Lefevre wrote: > A last thing: > /var/lib/apt/lists/ftp.debian.org_debian_dists_testing_non-free-firmware_binary-i386_Packages > has > > Package: libreoffice-common > Source: libreoffice > Version: 4:7.4.5-3 > > but amd64 is the

Bug#1040178: Kernel modules will not build, missing asm/orc_header.h

On 2023-07-04 16:13:56 +0200, Andreas Beckmann wrote: > This needs to be fixed before linux 6.3.0-2-* can migrate to testing, > otherwise it will break dkms module building for everyone still having > linux-headers-6.3.0-1-* installed (which is probably for the currently > running kernel). On one

  1   2   3   4   5   6   7   8   9   10   >