Bug#1087383: libreoffice: does not start if a soffice.bin process is running

The upstream repository has been archived a few weeks ago (March 31). And I can see that unoconv has been deprecated since 2021-11-12[*], i.e. more than 3 years ago. So it became completely unsupported upstream. [*] https://forum.jsreport.net/topic/2805/create-pdf-from-word-template-unoconv-depre

Bug#1087383: libreoffice: does not start if a soffice.bin process is running

Control: found -1 0.7-2.1 and now with the current unoconv version. BTW, I forgot to Cc the maintainer at the time of the reassign. :( I suppose that this new message should be sufficient. I'm keeping the contents below for this reason. On 2025-05-22 15:00:49 +0200, Vincent Lefevre

Bug#1104789: libhtml-gumbo-perl: erratic behavior on the unsupported template HTML element - GUMBO_NODE_TEMPLATE node type

On 2025-05-17 12:57:23 +0300, Niko Tyni wrote: > The attached change does not make HTML::Gumbo support > properly but seems to plug this specific hole, and hence the > known security aspects. > > I've checked that this doesn't break the (not very extensive) test > suite, and that the only reverse

Bug#1103503: isc-dhcp-client: In /etc/apparmor.d/local, sbin.dhclient should be renamed to usr.sbin.dhclient for consistency

On 2025-04-22 13:01:02 +0200, Vincent Lefevre wrote: > > I suppose it makes apparmor.service fail to start? > > No, I don't see any error with apparmor.service (and the documentation > does not suggest that there would be a fatal error for that). It actually fails to start

Bug#1104789: libhtml-gumbo-perl: erratic behavior on the unsupported template HTML element - GUMBO_NODE_TEMPLATE node type

Package: libhtml-gumbo-perl Version: 0.18-4+b1 Severity: serious Tags: security upstream Justification: security Forwarded: https://github.com/ruz/HTML-Gumbo/issues/6 X-Debbugs-Cc: Debian Security Team I get erratic behavior on the template HTML element, e.g. on the HTML file "". For instance: $

Bug#1104514: screen: about the typo in configure.ac

On 2025-05-05 03:10:50 +0200, Vincent Lefevre wrote: > Removing utempter support in debian/rules by either removing > the --enable-utempter option or changing it to --disable-utempter > has no effect, but if I understand correctly the configure.ac file, > this option is not used! Well

Bug#1104514: screen: corrupts the main terminal screen after detach due to lack of utmp in systemd 257

On 2025-05-05 03:10:50 +0200, Vincent Lefevre wrote: > On 2025-05-04 23:51:46 +0200, Vincent Lefevre wrote: > > In short, the issue may be been introduced with the systemd upgrade > > from 256.7-1 to 257.5-2 (the very old machine on which I do not see > > the issue has syste

Bug#1104514: screen: outputs some data to the main screen instead of the alternate screen

Control: retitle -1 screen: corrupts the main terminal screen after detach due to lack of utmp in systemd 257 On 2025-05-04 23:51:46 +0200, Vincent Lefevre wrote: > In short, the issue may be been introduced with the systemd upgrade > from 256.7-1 to 257.5-2 (the very old machine on whic

Bug#1104514: screen: outputs some data to the main screen instead of the alternate screen

On 2025-05-01 14:30:00 +0200, Vincent Lefevre wrote: > What's strange is that I think that I've never noticed this issue > before today, while it is now often reproducible. It could be Actually I'm not sure (see below). > related to some other upgrade on

Bug#1103503: isc-dhcp-client: In /etc/apparmor.d/local, sbin.dhclient should be renamed to usr.sbin.dhclient for consistency

Hi, On 2025-04-22 11:52:24 +0200, intrigeri wrote: > Vincent Lefevre (2025-04-19): > > On 2025-04-18 13:40:01 +0200, intrigeri wrote: > >> What dhclient files have been removed before the upgrade? > > > > /etc/apparmor.d/sbin.dhclient > > /etc/apparmor.d/local/

Bug#1103503: isc-dhcp-client: In /etc/apparmor.d/local, sbin.dhclient should be renamed to usr.sbin.dhclient for consistency

On 2025-04-18 13:40:01 +0200, intrigeri wrote: > What dhclient files have been removed before the upgrade? /etc/apparmor.d/sbin.dhclient /etc/apparmor.d/local/sbin.dhclient > How were they removed? With "rm". > Can you please describe how the resulting configuration is broken? After the upgrad

Bug#1101675: [Pkg-zsh-devel] Bug#1101675: Bug#1101675: zsh: completion suddenly broken

On 2025-04-07 18:56:41 +0100, Colin Watson wrote: > While I don't have any specific disagreement with anything you say here, I'm > reluctant to unilaterally revert what was apparently a deliberate change in > response to a user request (see https://bugs.debian.org/944469) so close to > the trixie f

Bug#1102340: python3-argcomplete: global zsh completions breaks completions unrelated to python

Package: python3-argcomplete Version: 3.1.4-1 Severity: critical Justification: breaks unrelated software In bug 944469, Daniel Kahn Gillmor (in Cc) requested activation of global bash completions. As a fix introduced in 3.1.4-1, Stefano Rivera (in Cc) activated global completions for both bash an

Bug#1101675: [Pkg-zsh-devel] Bug#1101675: Bug#1101675: zsh: completion suddenly broken

Control: tags -1 upstream Control: forwarded -1 https://github.com/kislyuk/argcomplete/issues/491 On 2025-03-31 02:41:40 +0200, Vincent Lefevre wrote: > Control: affects -1 zsh > > On 2025-03-31 02:30:17 +0200, Vincent Lefevre wrote: > > With python3-argcomplete 3.5.3-1, same

Bug#1101675: [Pkg-zsh-devel] Bug#1101675: Bug#1101675: zsh: completion suddenly broken

Control: affects -1 zsh On 2025-03-31 02:30:17 +0200, Vincent Lefevre wrote: > With python3-argcomplete 3.5.3-1, same issue, but if I type > a second time, I get > > qaa% : testdir/FOO > > as expected. (BTW, I had already seen this issue with not working > on the first

Bug#1100704: libtree-sitter0.22: trying to overwrite .../libtree-sitter.so.0.22, which is also in package libtree-sitter0 (0.22.6-4)

On 2025-03-17 20:03:34 +0100, Vincent Lefevre wrote: > On 2025-03-17 14:56:42 -0400, James McCoy wrote: > > Then maybe aptitude isn't presenting information clearly. You have > > experimental enabled in your sources and that version is only available > > in experimen

Bug#1101675: [Pkg-zsh-devel] Bug#1101675: Bug#1101675: zsh: completion suddenly broken

Control: tags -1 - upstream I'm removing the "upstream" tag, because at https://github.com/kislyuk/argcomplete/issues/491#issuecomment-2774459991 the upstream author says: Argcomplete does not activate global completion by default and does not recommend that distributions activate it by d

Bug#1101675: [Pkg-zsh-devel] Bug#1101675: Bug#1101675: zsh: completion suddenly broken

On 2025-04-01 11:28:57 +0100, Colin Watson wrote: > cjwatson@sacred-mosquito:~$ zsh > This is the Z Shell configuration function for new users, > zsh-newuser-install. > You are seeing this message because you have no zsh startup files > (the files .zshenv, .zprofile, .zshrc, .zlogin in th

Bug#1100699: screen: hardcopy and screen-exchange are insecure by default

reate /tmp/screen-exchange with default mode 0666. Closes: #48. This is far from being enough. > On 2025-03-17 15:54:06, Vincent Lefevre wrote: > > tags 1100699 security > > That said, I wonder about your disclosure process. I am not sure screen > has any sort of disclosure p

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

Hi Paul, On 2025-03-23 11:17:52 +0100, Paul Gevers wrote: > Hi Vincent, > > On Fri, 15 Dec 2023 04:53:51 +0100 Vincent Lefevre > wrote: > > On 2023-12-03 22:13:03 +0100, Vincent Lefevre wrote: > > > I've reported the following bug in the MPFR mailing-list. I thin

Bug#1100704: libtree-sitter0.22: trying to overwrite .../libtree-sitter.so.0.22, which is also in package libtree-sitter0 (0.22.6-4)

On 2025-03-17 14:56:42 -0400, James McCoy wrote: > Then maybe aptitude isn't presenting information clearly. You have > experimental enabled in your sources and that version is only available > in experimental: I track unstable. aptitude is supposed to give a warning when upgrading a package to ex

Bug#1100704: libtree-sitter0.22: trying to overwrite .../libtree-sitter.so.0.22, which is also in package libtree-sitter0 (0.22.6-4)

On 2025-03-17 14:35:47 -0400, James McCoy wrote: > Not sure why you're upgrading to the version from experimental, when > there's a newer version in unstable that already fixed this problem. No, experimental was not involved. And the new version was not available yet, since I followed what aptitud

Bug#1100704: libtree-sitter0.22: trying to overwrite .../libtree-sitter.so.0.22, which is also in package libtree-sitter0 (0.22.6-4)

Package: libtree-sitter0.22 Version: 0.22.6-5 Severity: serious When upgrading: [...] Preparing to unpack .../libtree-sitter0.22_0.22.6-5_amd64.deb ... Unpacking libtree-sitter0.22:amd64 (0.22.6-5) ... dpkg: error processing archive /var/cache/apt/archives/libtree-sitter0.22_0.22.6-5_amd64.deb (

Bug#1100699: screen: hardcopy and screen-exchange are insecure by default

Package: screen Version: 4.9.1-1 Severity: grave Justification: user security hole + possible data loss via a symlink attack The hardcopy (C-a h) in screen works in the following way: │ hardcopydir directory │ │ Defines a directory where hardcopy files will be placed. If unset, │ hardcopys are d

Bug#1100530: texlive-extra-utils: trying to overwrite /usr/share/man/man1/mflua.1.gz in texlive-binaries

On 2025-03-14 22:38:48 +0100, Vincent Lefevre wrote: > Package: texlive-extra-utils > Version: 2024.20250309-1 > Severity: serious > > When I wanted to upgrade texlive-extra-utils: > > Unpacking texlive-extra-utils (2024.20250309-1) over (2024.20250114-1) ... > dpkg:

Bug#1100530: texlive-extra-utils: trying to overwrite /usr/share/man/man1/mflua.1.gz in texlive-binaries

Package: texlive-extra-utils Version: 2024.20250309-1 Severity: serious When I wanted to upgrade texlive-extra-utils: Unpacking texlive-extra-utils (2024.20250309-1) over (2024.20250114-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-BfM9Yd/10-texlive-extra-utils_2024.20250309-1_all.

Bug#1099470: colord: upgrade to colord 1.4.7-3 fails: The user `colord' already exists, but is not a system user.

On 2025-03-05 09:57:09 +0100, Marc Haber wrote: > On Tue, Mar 04, 2025 at 03:23:17PM +0100, Vincent Lefevre wrote: > > Well, I don't know whether a system account may have a password, > > but this would still fail unexpectedly in such a case. > > > &

Bug#1099470: colord: upgrade to colord 1.4.7-3 fails: The user `colord' already exists, but is not a system user.

On 2025-03-04 14:27:44 +0100, Marc Haber wrote: > On Tue, Mar 04, 2025 at 01:41:28PM +0100, Vincent Lefevre wrote: > > On 2025-03-04 10:40:04 +0100, Marc Haber wrote: > > > On Tue, Mar 04, 2025 at 08:11:10AM +0100, Marc Haber wrote: > > > > I expect a fix for this add

Bug#1099470: colord: upgrade to colord 1.4.7-3 fails: The user `colord' already exists, but is not a system user.

On 2025-03-04 13:41:28 +0100, Vincent Lefevre wrote: > I recall the problematic code: > > my $ret = existing_user_status($new_name, $new_uid); > if ($ret == (EXISTING_FOUND|EXISTING_SYSTEM)) { > # a user with this name already exists; it's a problem when it&#x

Bug#1099470: colord: upgrade to colord 1.4.7-3 fails: The user `colord' already exists, but is not a system user.

On 2025-03-04 10:40:04 +0100, Marc Haber wrote: > On Tue, Mar 04, 2025 at 08:11:10AM +0100, Marc Haber wrote: > > I expect a fix for this adduser issue for later today and apologize for > > the problem. There is no need to debug other packages until adduser > > 3.144 is uploaded. > > Can you try t

Bug#1099470: colord: upgrade to colord 1.4.7-3 fails: The user `colord' already exists, but is not a system user.

On 2025-03-04 10:46:50 +0100, Marc Haber wrote: > > This is the opposite. The upgrade fails for system accounts that are > > not locked (those without an exclamation point). > > Just to get the terminology straight: How would you call an account that > has * as a password in /etc/shadow? I'd say

Bug#1099470: colord: upgrade to colord 1.4.7-3 fails: The user `colord' already exists, but is not a system user.

Control: retitle -1 fails upgrade of packages with non-locked system accounts On 2025-03-04 08:11:10 +0100, Marc Haber wrote: > Control: retitle -1 fails upgrade of packages with locked system accounts This is the opposite. The upgrade fails for system accounts that are not locked (those without

Bug#1099470: adduser: spurious fatal error "The user `colord' already exists, but is not a system user."

On 2025-03-04 10:04:30 +0800, Yao Wei (魏銘廷) wrote: > I found one way to workaround the issue is to uncomment part of > /etc/adduser.conf "FIRST_SYSTEM_UID" and "LAST_SYSTEM_UID", so the UID > check can be passed. I don't see how this can solve the problem. > I believe that adduser should have the

Bug#1099470: adduser: spurious fatal error "The user `colord' already exists, but is not a system user."

Control: severity 1099470 critical Control: affects 1099477 colord Control: merge 1099470 1099477 Correctly merging... Note that the consequence of the incorrect test may even be worse: It would not notice when the user is not a system user. This might give unexpected rights to a normal user. --

Bug#1099470: colord: upgrade to colord 1.4.7-3 fails: The user `colord' already exists, but is not a system user.

Control: reassign -1 adduser 3.143 Control: affects -1 colord Control: retitle -1 adduser: spurious fatal error "The user `colord' already exists, but is not a system user." On 2025-03-03 17:09:32 -0500, Jeremy Bícha wrote: > Please also file a bug against adduser. Nothing has changed in > colord

Bug#1099470: colord: upgrade to colord 1.4.7-3 fails: The user `colord' already exists, but is not a system user.

On 2025-03-03 23:26:17 +0100, Vincent Lefevre wrote: > BTW, the adduser code looks suspicious: > > my $ret = existing_user_status($new_name, $new_uid); > if ($ret == (EXISTING_FOUND|EXISTING_SYSTEM)) { > # a user with this name already exists; it's a proble

Bug#1099470: colord: upgrade to colord 1.4.7-3 fails: The user `colord' already exists, but is not a system user.

On 2025-03-03 23:18:35 +0100, Michael Musenbrock wrote: > This maybe looks more like an issue in adduser? Yes, I've just reassigned the bug to adduser. > So changing the shadow password field from '*' (no pwd) to '!' > (locked) allows adduser to pass. Because use constant { EXISTING_NOT_FOU

Bug#1099470: colord: upgrade to colord 1.4.7-3 fails: The user `colord' already exists, but is not a system user.

On 2025-03-03 22:42:28 +0100, Vincent Lefevre wrote: > When upgrading colord with aptitude: > > Setting up colord (1.4.7-3) ... > warn: The home dir /var/lib/colord you specified already exists. > > fatal: The user `colord' already exists, but is not a system user.

Bug#1099470: colord: upgrade to colord 1.4.7-3 fails: The user `colord' already exists, but is not a system user.

Package: colord Version: 1.4.7-3 Severity: serious When upgrading colord with aptitude: Setting up colord (1.4.7-3) ... warn: The home dir /var/lib/colord you specified already exists. fatal: The user `colord' already exists, but is not a system user. Exiting. dpkg: error processing package colo

Bug#1057621: valgrind should not drop valgrind-dbg

Hi, On 2023-12-06 02:05:07 +0200, Adrian Bunk wrote: > Package: valgrind > Version: 1:3.20.0-1 > Severity: serious > X-Debbugs-Cc: Adam Borowski > > -dbgsym packages are not part of the normal archive, > and they can therefore not be expected to be pulled in > by normal dependencies. > > For th

Bug#1095737: valgrind: unsatisfiable recommends on valgrind-dbg

Package: valgrind Version: 1:3.24.0-2 Severity: serious valgrind 1:3.24.0-2 still has a "Recommends" on valgrind-dbg, which is no longer available. This prevents upgrade with aptitude, in particular. Either the valgrind-dbg package should be built, or the Recommends should be dropped. But see als

Bug#1089039: mailgraph: Support RFC3339 or syslog-ng ISO dates

On 2025-01-30 09:49:40 +0100, Vincent Lefevre wrote: > On 2025-01-30 08:13:43 +0100, Johannes Schauer Marin Rodrigues wrote: > > If you look at mailgraph in Trixie, it still uses the same regex: > > > > https://sources.debian.org/src/mailgraph/1.14-22/mailgraph.pl/#L229 >

Bug#1089039: mailgraph: Support RFC3339 or syslog-ng ISO dates

On 2025-01-30 08:13:43 +0100, Johannes Schauer Marin Rodrigues wrote: > If you look at mailgraph in Trixie, it still uses the same regex: > > https://sources.debian.org/src/mailgraph/1.14-22/mailgraph.pl/#L229 You're looking at the wrong place. It should use the regexp at https://sources.debian.

Bug#1089039: mailgraph: Support RFC3339 or syslog-ng ISO dates

On 2025-01-28 16:05:13 +0100, Johannes Schauer Marin Rodrigues wrote: > I can confirm this issue with mailgraph on our systems. This makes mailgraph > completely unusable, thus raising the severity to RC. Here is an example of an > anonymized log snippet which fails: > > 2025-01-28T14:12:33.468866

Bug#1092330: libmimalloc2.0: fails to provide libmimalloc.so.2.0

On 2025-01-22 10:19:08 +0100, Emmanuel Fleury wrote: > A quick (and dirty) workaround is as follow: > > #> sudo ln -s /usr/lib/x86_64-linux-gnu/libmimalloc.so.2 > /usr/lib/x86_64-linux-gnu/libmimalloc.so.3.0 The libraries are not compatible. You should not do that. -- Vincent Lefèvre - Web:

Bug#1087038: libpango-1.0-0: Pango 1.52+ API+ABI breakage (affecting gnuplot in particular)

On 2025-01-22 13:37:10 -0500, Jeremy Bícha wrote: > It doesn't look like pango will be changing upstream as a result of > your bug report. We're not going to do a downstream library transition > for a widely used library like pango, just because of a small behavior > change that apparently broke on

Bug#1086145: sysprof: error "Failure: Failed to authorize user credentials"

On 2025-01-19 20:16:11 -0500, Jeremy Bícha wrote: > Could you provide more details about how your system is set up? I am > unable to duplicate the issue, as you have described it here. First, when I install the sysprof package, I notice: Setting up sysprof (47.2-1) ... sysprof3.service is a disab

Bug#1086145: sysprof: error "Failure: Failed to authorize user credentials"

Control found -1 sysprof On 2025-01-19 14:21:14 -0500, Jeremy Bícha wrote: > On Sun, Oct 27, 2024 at 9:21 AM Vincent Lefevre wrote: > > Package: sysprof > > Version: 3.46.0-4 > > Severity: grave > > Justification: renders package unusable > > > >

Bug#1093221: mutt drops RFC822/2822/5322 comments for display and replies

Package: mutt Version: 2.2.12-0.1~deb12u1 Severity: grave Tags: security upstream Forwarded: https://gitlab.com/muttmua/mutt/-/issues/495 Justification: user security hole X-Debbugs-Cc: Debian Security Team I've reported the following bug upstream: Consider a mailbox with a message as follows:

Bug#1092330: libmimalloc2.0: fails to provide libmimalloc.so.2.0

On 2025-01-16 10:38:42 +0100, mister...@web.de wrote: > I'm not familiar with the inner workings of apt-listbugs, but after > adding a found version to this bug I was correctly warned by it when > libmimalloc2.0 was due to be upgraded on another system of mine. > > I can only assume, that libmimal

Bug#1093160: rsync: failed verification -- update discarded

Control: found -1 3.2.7-1+deb12u1 Control: notfound -1 rsync/3.3.0+ds1-2 On 2025-01-16 10:30:21 +0100, Vincent Lefevre wrote: > This seems to be due to the -K option. > > On the Debian bookworm machine (joooj): [...] The same failure can be reproduced on this machine only: just c

Bug#1093160: rsync: failed verification -- update discarded

Hi Salvatore, On 2025-01-16 05:57:27 +0100, Salvatore Bonaccorso wrote: > Have you more information on the setup which triggers this? Do you > have a minimal reproducing case to show the problem? This seems to be due to the -K option. On the Debian bookworm machine (joooj): $ mkdir real-dir $

Bug#1092330: libmimalloc2.0: fails to provide libmimalloc.so.2.0

On 2025-01-11 16:21:43 +0100, mister...@web.de wrote: > Control: found -1 3.0.1+ds-1 > > Hi, > > I'm just adding a package version to this bug, so that people using > apt-listbugs may be warned about this. No, this has no effect for the tex-common upgrade: I've just got hit by this bug and got n

Bug#1093160: rsync: failed verification -- update discarded

On 2025-01-15 23:30:22 +0100, Vincent Lefevre wrote: > When updated a directory with "rsync -KRlptzv --progress", > I now get errors like > > ERROR: public_html/cine/index.fr.html failed verification -- update discarded. > ERROR: public_html/cine/perso-lyon.txt fail

Bug#1093160: rsync: failed verification -- update discarded

Package: rsync Version: 3.3.0+ds1-2 Severity: grave Justification: renders package unusable When updated a directory with "rsync -KRlptzv --progress", I now get errors like ERROR: public_html/cine/index.fr.html failed verification -- update discarded. ERROR: public_html/cine/perso-lyon.txt failed

Bug#1092247: libgumbo2:amd64: misses the html element

Control: retitle -1 libgumbo2: ABI broken without SONAME bump (affects HTML::Gumbo perl bindings: misses html element) Control: affects libhtml-gumbo-perl based on information from the upstream issue. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog:

Bug#1092247: libgumbo2:amd64: misses the html element

Control: tags -1 upstream Control: forwarded -1 https://codeberg.org/gumbo-parser/gumbo-parser/issues/3 This matches the issue reported upstream a few days ago: Commit ae13588699 broke perl bindings test #3 -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML

Bug#1092247: libgumbo2:amd64: misses the html element

Package: libgumbo2 Version: 0.12.3+dfsg-1 Severity: grave Justification: renders package unusable After the to 0.12.3+dfsg-1, libgumbo2 misses the html element. This is a major regression. For instance, this has the effect to generate invalid XML files. To reproduce, consider the following Perl s

Bug#1090207: davfs2: FTBFS: configure: error: could not find neon

On 2024-12-16 17:49:38 +, Santiago Vila wrote: > Package: src:davfs2 > Version: 1.7.0-1 > Severity: serious > Tags: ftbfs [...] > checking linking against neon... yes > configure: incompatible neon library version 0.34.0: wanted 0.27 28 29 30 31 > 32 33 > configure: error: could not find neon

Bug#1089753: crashes during startup

On 2024-12-12 10:09:15 +0100, Yuri D'Elia wrote: > I'm getting a ~50% random crash chance during startup: [...] I do not notice any crash when just running mlterm from 3.9.3-2, but I confirm an issue I can see with valgrind: cventin:~> valgrind mlterm ==12239== Memcheck, a memory error detector =

Bug#1087761: bluez: Fails to connect to device: Permission denied

On 2024-11-18 12:29:13 +0100, Bastian Venthur wrote: > Package: bluez > Version: 5.79-1 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: vent...@debian.org > > Dear Maintainer, > > Since the recent update, I cannot connect to my bluetooth headphones anymore. Note that

Bug#1087642: bsdutils: wall does not work at all

Package: bsdutils Version: 1:2.40.2-11 Severity: grave Justification: renders package unusable "wall" does not work at all, even when run as root: the message is not output in any of the terminals. -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500,

Bug#1082282: libunwind: FTBFS on i386: passing argument 1 of '_Ux86_sigreturn' from incompatible pointer type

On 2024-11-15 15:15:35 +0100, Alban Browaeys wrote: > Le mardi 12 novembre 2024 à 15:48 +0100, Vincent Lefevre a écrit : > > Hi, > > > > On 2024-10-11 09:16:26 +0200, Alban Browaeys wrote: > > > Upstream in https://github.com/libunwind/libunwind/issues/672 for >

Bug#1082282: libunwind: FTBFS on i386: passing argument 1 of '_Ux86_sigreturn' from incompatible pointer type

Hi, On 2024-10-11 09:16:26 +0200, Alban Browaeys wrote: > Upstream in https://github.com/libunwind/libunwind/issues/672 for 1.8. This is unclear. https://github.com/libunwind/libunwind/issues/672 is about 1.7.2, and this issue is closed as being fixed in 1.8. > Also gentoo for libunwind 1.8: >

Bug#1087362: how-can-i-help: /usr/bin/how-can-i-help script returns a "no implicit conversion" error

Control: found -1 17 On 2024-11-12 07:32:42 +0100, Jean-Marc wrote: > /usr/bin/how-can-i-help:238:in `&': no implicit conversion of nil into Array > (TypeError) > from /usr/bin/how-can-i-help:238:in `block in ' > from /usr/bin/how-can-i-help:215:in `each' > from /usr/bin/how-can

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

Control: found -1 gnuplot/5.4.4+dfsg1-2 Control: found -1 gnuplot/6.0.0+dfsg1-1 Control: found -1 gnuplot/6.0.0+dfsg1-3 Control: forwarded -1 https://sourceforge.net/p/gnuplot/bugs/2693/ to restore and update the old found/forwarded values. -- Vincent Lefèvre - Web: 10

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

Pango 1.52+ API+ABI breakage (affecting gnuplot in particular) I've reassigned the initial bug instead of the cloned bug as I had reported the initial bug against gnuplot. On 2024-10-30 13:14:05 +0100, Vincent Lefevre wrote: > On 2024-09-17 14:55:47 +0200, Vincent Lefevre wrote: > >

Bug#1086532: libzbar0t64: upgrade blocked due to bad Recommends

Package: libzbar0t64 Version: 0.23.93-5+b2 Severity: serious libzbar0t64 0.23.93-5+b2 has Recommends: libmagickcore-6.q16-7-extra instead of Recommends: libmagickcore-7.q16-10-extra This blocks the upgrade to imagemagick 7 due to the unsatisfied Recommends. -- System Information: Debian R

Bug#1086145: sysprof: error "Failure: Failed to authorize user credentials"

On 2024-10-27 14:17:28 +0100, Vincent Lefevre wrote: > sysprof-cli gives the following error: > > Failure: Failed to authorize user credentials There is no such issue when I connect to the machine remotely via ssh (with or without X11 forwarding): qaa:~> sysprof-cli -- echo Reco

Bug#1086145: sysprof: error "Failure: Failed to authorize user credentials"

Package: sysprof Version: 3.46.0-4 Severity: grave Justification: renders package unusable sysprof-cli gives the following error: Failure: Failed to authorize user credentials -- System Information: Debian Release: trixie/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'),

Bug#1076352: procps: leftover conffiles

On 2024-10-22 00:30:32 +0200, of1 wrote: > Just a note to point out that /etc/sysctl.conf is still referenced in > the sysctl manual. Is the file still a valid and usable conf file? On a similar subject, I had reported https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077187 about the sysctl

Bug#1085643: systemd: breaks who from coreutils due to disabled utmp support

Package: systemd Version: 256.7-2 Severity: serious Due to * Disable utmp support, not y2038 safe. utmp support in tmux has been disabled, so autopkgtest should no longer break the "who" utility from the coreutils package no longer works (it just returns nothing). Until "who" supports wtm

Bug#1085045: cfortran: trying to overwrite '/usr/include/cfortran.h', which is also in package libcfitsio-dev:amd64 4.5.0-2

On 2024-10-13 17:46:03 +0200, Vincent Lefevre wrote: > Package: cfortran > Version: 20210827-1 > Severity: serious > > When installing cfortran: > > Unpacking cfortran (20210827-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-XpEiQK/0-cfortran_2

Bug#1085045: cfortran: trying to overwrite '/usr/include/cfortran.h', which is also in package libcfitsio-dev:amd64 4.5.0-2

Package: cfortran Version: 20210827-1 Severity: serious When installing cfortran: Unpacking cfortran (20210827-1) ... dpkg: error processing archive /tmp/apt-dpkg-install-XpEiQK/0-cfortran_20210827-1_all.deb (--unpack): trying to overwrite '/usr/include/cfortran.h', which is also in package li

Bug#1082745: aptitude: information mismatch for package removal

This issue occurred again for the new Linux kernel upgrade. Here's additional information. The reformatted diff on the /var/lib/aptitude/pkgstates file just after the upgrade: Package: linux-headers-6.10.12-amd64 Architecture: amd64 Unseen: yes State:

Bug#1078402: gimp: FTBFS: dh_install: error: missing files, aborting

Any news? gimp has just been removed from testing because of this bug. Nothing has been done upstream for a backport for autoconf. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic /

Bug#1080330: coreutils: who no longer works

Control: retitle -1 coreutils: "who" should support wtmpdb (y2038) Control: severity -1 wishlist Control: tags -1 upstream [Cc Luca Boccassi so that he gets aware of this issue. In short, "who" from coreutils still relies on utmp.] On 2024-09-20 11:39:55 -0300, Adilson dos Santos Dantas wrote: >

Bug#1014124: nomacs: CVE-2020-23884

Control: tags -1 - fixed-upstream Control: reassign -1 qt5-image-formats-plugins Control: retitle -1 buffer overflow in the mng plugin for Qt (CVE-2020-23884) The upstream fix in Nomacs was for MS Windows only: "I removed the qmng.dll plugin from Windows version. MNG files will not work by defaul

Bug#1080330: coreutils: who no longer works

On 2024-09-04 11:15:26 +0200, Chris Hofstaedtler wrote: > On Mon, Sep 02, 2024 at 11:15:19AM -0400, Michael Stone wrote: > > On Mon, Sep 02, 2024 at 01:07:59PM +0200, Vincent Lefevre wrote: > > > Severity: grave > > > Justification: renders package unusable > >

Bug#1080330: coreutils: who no longer works

BTW, note that the "w" utility from procps still works, but according to strace, it doesn't seem to use wtmpdb. However, though the w(1) and who(1) man pages are similar ("show who is logged on"), w misses some information. -- Vincent Lefèvre - Web: 100% accessible vali

Bug#1080330: coreutils: who no longer works

Control: retitle -1 coreutils: "who" no longer works with systemd 256.5-2 (utmp is now disabled, use wtmpdb instead) (title with more details) -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer

Bug#1080330: coreutils: who no longer works

Package: coreutils Version: 9.4-3.1 Severity: grave Justification: renders package unusable Though the whole package is not unusable, an important utility is now unusable because coreutils still hasn't switched to wtmpdb. This must be fixed before the next Debian release. With systemd 256.5-2, "w

Bug#1078158: gcc-doc-defaults: switch to GCC 14

On 2024-08-07 15:13:52 +0200, Andreas Beckmann wrote: > gcc-doc-defaults started to FTBFS when the default compiler has been > switched to GCC 14. Please update the doc package to GCC 14, too. But gcc-14-doc is not available in Debian yet. -- Vincent Lefèvre - Web: 100

Bug#1078208: fail2ban: sshd.conf filter does not works with OpenSSH 9.8

Control: tags -1 patch I've attached a patch fixing both issues. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) --- fail2ban-1.1.0-a/config/filter.d/

Bug#1078208: fail2ban: sshd.conf filter does not works with OpenSSH 9.8

On 2024-08-11 02:53:27 +0200, Vincent Lefevre wrote: > On 2024-08-08 11:25:07 +0200, Vincent Lefevre wrote: > > As seen at https://github.com/fail2ban/fail2ban/pull/3782/files > > the change is quite simple: change > > > > _daemon = sshd > > > >

Bug#1078208: fail2ban: sshd.conf filter does not works with OpenSSH 9.8

On 2024-08-08 11:25:07 +0200, Vincent Lefevre wrote: > As seen at https://github.com/fail2ban/fail2ban/pull/3782/files > the change is quite simple: change > > _daemon = sshd > > to > > _daemon = sshd(?:-session)? Unfortunately this change alone does not solve the issue

Bug#1078208: fail2ban: sshd.conf filter does not works with OpenSSH 9.8

Package: fail2ban Version: 1.1.0-4 Severity: serious Tags: upstream fixed-upstream The fail2ban sshd.conf filter does not works with OpenSSH 9.8. This is due to openssh (1:9.8p1-1) unstable; urgency=medium * New upstream release (https://www.openssh.com/releasenotes.html#9.8p1): [...] - ss

Bug#1076729: libwayland: breaks plasma desktop start after last upgrade to version 1.23.0-1

On 2024-08-05 12:42:42 +0200, Vincent Lefevre wrote: > This bug was closed, but has not been marked as fixed in > libwayland-client0, so that the current version is still > regarded as buggy, as reported by apt-listbugs: > > serious bugs of libwayland-client0 (1.22.0-2.1+b1 →

Bug#1076729: libwayland: breaks plasma desktop start after last upgrade to version 1.23.0-1

This bug was closed, but has not been marked as fixed in libwayland-client0, so that the current version is still regarded as buggy, as reported by apt-listbugs: serious bugs of libwayland-client0 (1.22.0-2.1+b1 → 1.23.0-1) b1 - #1076729 - libwayland: breaks plasma desktop start after last upgra

Bug#1077587: still occurs (reply to Sylvestre Ledru ) (Bug#1077587: fixed in llvm-toolchain-18 1:18.1.8-8)

On 2024-08-01 14:02:15 +0200, Vincent Lefevre wrote: > On 2024-07-30 09:39:08 +, Debian Bug Tracking System wrote: > > Changes: > > llvm-toolchain-18 (1:18.1.8-8) unstable; urgency=medium > > . > >* Fix breaks/replaces (Closes: #1077587) > > Package: llv

Bug#1077587: still occurs (reply to Sylvestre Ledru ) (Bug#1077587: fixed in llvm-toolchain-18 1:18.1.8-8)

Control: reopen -1 Control: found -1 1:18.1.8-8 On 2024-07-30 09:39:08 +, Debian Bug Tracking System wrote: > Changes: > llvm-toolchain-18 (1:18.1.8-8) unstable; urgency=medium > . >* Fix breaks/replaces (Closes: #1077587) Package: llvm-18-dev Source: llvm-toolchain-18 Version: 1:18.1.8

Bug#1077605: pinfo: copies a file from the current directory to /tmp

Package: pinfo Version: 0.6.13-1.3+b1 Severity: grave Tags: security Justification: user security hole X-Debbugs-Cc: Debian Security Team When running "pinfo mpfr", I can see in the strace output: execve("/bin/sh", ["sh", "-c", "--", "cat ./mpfr> /tmp/pinfo.tVVaeB"], 0x7ffc16308110 /* 135 vars

Bug#1077587: llvm-18-dev: tries to overwrite '/usr/lib/llvm-18/lib/libLLVM-18.so.1', which is also in libllvm18 1:18.1.8-5

Package: llvm-18-dev Version: 1:18.1.8-7 Severity: serious When upgrading the llvm-toolchain-18 packages: Unpacking llvm-18-dev (1:18.1.8-7) over (1:18.1.8-5) ... dpkg: error processing archive /tmp/apt-dpkg-install-LjdMdY/04-llvm-18-dev_1%3a18.1.8-7_amd64.deb (--unpack): trying to overwrite '/

Bug#1076582: Bug#1077274: Excessive initramfs size with firmware-nvidia-graphics and plymouth

On 2024-07-29 15:59:14 +0200, Rodrigo Campos wrote: > On 7/28/24 10:33 PM, Ben Hutchings wrote: > > This issue was fixed by initramfs-tools version 0.143 in experimental. > > I have just uploaded version 0.143.1 to unstable, so you should be able > > to get the fix through a regular upgrade in a fe

Bug#1076582: Processed (with 1 error): tagging 1076539, forcibly merging 1076582 1076539

Control: notfixed -1 0.143 Control: fixed -1 initramfs-tools/0.143 There's a bug in the BTS software, which forgot the source package name for bug 1076582. On 2024-07-28 20:27:17 +, Debian Bug Tracking System wrote: > After four attempts, the following changes were unable to be made: > fixed_

Bug#1075301: mutt: ftbfs with GCC-14

On 2024-07-03 12:37:27 +, Matthias Klose wrote: > gcc -DPKGDATADIR=\"/usr/share/mutt\" -DSYSCONFDIR=\"/etc\" > -DBINDIR=\"/usr/bin\" -DMUTTLOCALEDIR=\"/usr/share/locale\" -DHAVE_CONFIG_H=1 > -I. -I../.. -I. -I../.. -I../../imap-Wdate-time -D_FORTIFY_SOURCE=2 > -isystem /usr/include/mit-

Bug#1077184: systemd: /etc/sysctl.conf is no longer read

Package: systemd Version: 256.4-2 Severity: grave Tags: security Justification: user security hole X-Debbugs-Cc: Debian Security Team The /etc/sysctl.conf file is no longer read, while I have security settings there. I suspect that the cause is * Drop /etc/sysctl.d/99-sysctl.conf symlink proc

Bug#1076582: initramfs-tools-core: mkinitramfs failure zstd -q -9 -T0 70 (No space left on device)

On 2024-07-24 10:58:24 +0200, Diederik de Haas wrote: > Uninstalling firmware YOU DON'T NEED is a perfectly valid solution. How can one do that? I mean, get only the Nvidia firmware for my particular Nvidia card, not everything of all the existing cards (which is really the issue). > What IS a ge

Bug#1076449: Might be a different cause

On 2024-07-22 17:58:01 +0700, Sam wrote: > So, I have now two machines where this bug happens, but on a third one > (my notebook) there seems to be no problem, despite all of them showing > 6.8-1 as the installed version (via `dpkg --list | grep mercurial`). > > Any recommendations how to make a d

Bug#1076449: mercurial: does not start anymore with python 3.12.4-3, hgdemandimport problem

On 2024-07-16 11:12:12 -0400, Daniel Serpell wrote: > In current sid, with python 3.12.4-3, mercurial fails at load with: > > ~$ hg > Traceback (most recent call last): >File "/usr/bin/hg", line 57, in > from mercurial import dispatch >File "", line 1360, in _find_and_load >Fi

  1   2   3   4   5   6   7   8   9   10   >