On 2025-04-29 08:44:04 -0400, Jeremy Bícha wrote:
> On Mon, Apr 28, 2025 at 9:29 PM Vincent Lefevre wrote:
> > On 2025-04-28 20:15:01 -0400, Jeremy Bícha wrote:
> > > gtk4 now uses XDG desktop portals by default. I guess you need to
> > > figure out how to get xdg-des
s:
ii fonts-urw-base35 20200910-8
ii ghostscript 10.04.0~dfsg-2+b1
Versions of packages libmagickcore-7.q16-10 suggests:
ii libmagickcore-7.q16-10-extra 8:7.1.1.47+dfsg1-1
-- no debconf information
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
you can use.
>
> https://docs.gtk.org/gtk4/running.html suggests GDK_DEBUG=no-portals
"export GDK_DEBUG=no-portals" has no effect.
Note that the startup time has apparently reduced to around 15 seconds
(whether GDK_DEBUG=no-portals is used or not), which is still large.
--
Vi
e: 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 libtext-lorem-perl depends on:
ii perl 5.40.1-3
libtext-lorem-perl recommends no packages.
libtext-
Note: test failure appears to be armel-specific; I can't reproduce it on amd64.
On 2025-04-24 09:58, Vincent Bernat wrote:
On 2025-04-23 20:57, Adrian Bunk wrote:
Control: tags 1102673 + patch
Control: tags 1102673 + pending
Dear maintainer,
I've prepared an NMU for haproxy (versioned as 3.0.10-0.1) and uploaded
it to DELAYED/7. Please feel free to tell me if I s
On 2025-04-23 20:57, Adrian Bunk wrote:
Control: tags 1102673 + patch
Control: tags 1102673 + pending
Dear maintainer,
I've prepared an NMU for haproxy (versioned as 3.0.10-0.1) and uploaded
it to DELAYED/7. Please feel free to tell me if I should cancel it.
Upgrading to 3.0.10 looked more rea
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/
") and in the man page.
* The "*" character, which is used for executables (* at the end),
is not quoted. So, even if there were a reason to quote characters
added by "-F", this is not the case.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible val
broken?
After the upgrade, I just have
cventin:~> ll /etc/apparmor.d/**/*dhclient*
-rw-r--r-- 1 root root 3590 2025-04-04 16:49:15
/etc/apparmor.d/usr.sbin.dhclient
The one under /etc/apparmor.d/local is absent, though
/etc/apparmor.d/usr.sbin.dhclient does
#include
(without 'if exi
d, because xterm -ls -e does
write a wtmp entry (if configured to do so), whereas xterm -e does
not.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Control: severity -1 serious
as this yields a broken configuration if the dhclient files had
been removed before the upgrade (seen on one of my machines).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Wo
ii isc-dhcp-common 4.4.3-P1-7
Versions of packages isc-dhcp-client suggests:
pn avahi-autoipd
pn isc-dhcp-client-ddns
pn resolvconf
-- no debconf information
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
reinstalled or
upgraded. There is no point to output such a line for a conffile
that definitively no longer exists. About this issue:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085130
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <
On 2025-04-16 19:27:15 +1000, Craig Small wrote:
> On Wed, 29 Jan 2025 at 21:07, Vincent Lefevre wrote:
>
> > So perhaps the procps part is fixed in procps/2:4.0.4-7, but there
> > is still an issue on the dpkg side, at least missing documentation.
> >
> I'll clos
hell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
zsh-common depends on no packages.
Versions of packages zsh-common recommends:
ii zsh 5.9-8
Versions of packages zsh-common suggests:
ii zsh-doc 5.9-8
-- no debconf information
--
Vincent Lef
F-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ghostscript depends on:
ii libc62.41-6
ii libgs10 10.05.0~dfsg-1
ghostscript recommends no packages.
Versions of packages ghostscript suggests:
i
Control: found -1 2:4.0.4-7
The issue still occurs.
Note that concerning SSH sessions at least, "who" from coreutils 9.7-1
(which is now linked against libsystemd) displays the terminal name as
expected.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible v
set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-argcomplete depends on:
ii python3 3.13.2-2
python3-argcomplete recommends no packages.
python3-argcomplete suggests no packages.
-- no debconf information
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
orter
> and fixer of #944469? We can then discuss whether e.g. the completions are
> appropriate for bash but not zsh, or should be made non-default again across
> the board, or something else.
Bug filed as
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1102340
--
Vincent Lef
Control: forwarded -1 https://github.com/nomacs/nomacs/issues/1304
I've just reported the bug upstream.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pasca
Le 2025-03-29 10:09, Martin Maney a écrit :
> On Thu, 10 Oct 2024 16:41:36 +0200 Vincent Blut
> wrote:
>
> Sorry, I never saw this back in October - just came across it when I
> checked on the bug at bugs.debian.
>
> > As you correctly pointed out, AppArmor is not
#x27;t work any more.
>
> This issue still exists in current sid and bookworm.
I confirm that at least the CapsLock LED issue still occurs.
In grub, the LED works as expected, but it no longer works when
I need to type the passphrase to unlock the disk.
Under X11, the CapsLock LED wor
proposes libtree-sitter0.22 0.22.6-6 from unstable rather
than libtree-sitter0.22 0.22.6-5 from experimental.
Note that since libtree-sitter0.22 0.22.6-6 has
Replaces: libtree-sitter0 (<< 0.22.6-5~)
the removal of libtree-sitter0 is safe.
Note also that aptitude does not give any wa
/QTBUG-135482
This is actually a bug in Qt 6 (but Qt 5 was already buggy, as
this can be shown with a testcase in the upstream bug, copied
from the upstream nomacs bug).
It affects at least both nomacs (against which I had reported the bug)
and qpdfview.
--
Vincent Lefèvre - Web: <https://www.vin
27;t able to find the cause.
There have been complaints about this package at least for Arch Linux,
where the global completion (i.e. changing the "-default-" completer)
was enabled by default like in Debian. Such completions have then been
removed in Arch Linux.
See also:
https://www.z
Control: retitle -1 nomacs: window moves downward at each restart: Y position
increases between "show window:" and "active window:"
On 2025-04-02 02:24:07 +0200, Vincent Lefevre wrote:
> For instance, the following can be seen in the terminal after
> a restart:
&g
+b2
ii libraw23t640.21.3-1+b1
ii libstdc++6 14.2.0-19
ii libtiff6 4.7.0-2
ii qt5-image-formats-plugins 5.15.15-3
Versions of packages nomacs recommends:
ii nomacs-l10n 3.21.0+dfsg-1
nomacs suggests no packages.
-- no debconf information
--
user.zshrc.recommended $zd/.zshrc
source $zd/.zshrc
return 0
So you'll get completion settings that may interfere with the
testcase.
I suggest that you run the test under "zsh -f" (as suggested
in my bug report) instead of "zsh", so that init files (except
/etc
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
Package: wnpp
Severity: wishlist
Owner: Vincent Danjean
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: kameleon
Version : 2.10.13
Upstream Contact: pierre.ney...@imag.fr
* URL : http://kameleon.imag.fr/
* License : GPL-2+
Programming Lang: ruby
recommends no packages.
gir1.2-gimp-3.0 suggests no packages.
-- no debconf information
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
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
ue with not working
on the first time on this machine, and has already been wondering why...
Now, I know.)
Without python3-argcomplete, immediately gives
qaa% : testdir/FOO
as expected.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <ht
On 2025-03-30 17:41:52 +0200, Michael Prokop wrote:
> * Vincent Lefevre [Sun Mar 30, 2025 at 01:40:20PM +0200]:
> > On 2025-03-30 13:08:43 +0200, Michael Prokop wrote:
>
> > > Also can't reproduce it within a *current* Debian trixie container:
> > >
> &
$_/FOO; autoload -U compinit; $_; zstyle
':completion:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}'; print -z ls testdir/f
works as expected.
I don't see under which logic this should behave in a different way.
--
Vincent Lefèvre - Web: <https://www.vinc17.
On 2025-03-30 19:02:02 +0200, Vincent Lefevre wrote:
> On 2025-03-30 18:48:32 +0200, Vincent Lefevre wrote:
> > I've tested on 2 machines: I get the problem on the machine with
> > up-to-date packages, but not on the one with older packages.
>
> Hmm... It seems that mo
On 2025-03-30 18:48:32 +0200, Vincent Lefevre wrote:
> I've tested on 2 machines: I get the problem on the machine with
> up-to-date packages, but not on the one with older packages.
Hmm... It seems that more than completion that is broken.
After "zsh -f", if I test the
$_; zstyle
> ':completion:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}'; print -z : testdir/f
>
>
> FTR, with zsh v5.9-8+b7, gcc-14-base v14.2.0-19 + libcap2 v1:2.75-4.
> Feels like you had outdated gcc-14-base/libcap2 packages?
Why outdated? I'm
Control: severity -1 serious
At https://www.zsh.org/mla/workers/2025/msg00122.html Eric Cook says:
> from a debian testing container, i can reproduce it after updating
> gcc-14-base and libcap.
>
> can't reproduce it from archlinux with the same version of libcap
> though.
-8
Versions of packages zsh recommends:
ii libgdbm6t64 1.24-2
ii libncursesw6 6.5+20250216-2
ii libpcre2-8-0 10.45-1
Versions of packages zsh suggests:
ii zsh-doc 5.9-8
-- no debconf information
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
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
n my part, so I did not notice/remember it.
Regards,
Vincent
Note that I have "https" apt sources, so I do not initially think about a local
[network] config problem.
I raised the severity of this bug because:
1) I do not explicitely ask the installation of auto-apt-proxy
2) the error message does not point to auto-apt-proxy (it took me some ti
Le 2025-03-26 14:20, Tim Connors a écrit :
> Hi maintainer,
>
> This is a rather unfortunate bug. As can be seen from the manpage,
>
> "Generally, the directives can occur in any order in the file and if a
> directive is specified multiple times, only the last one will be
> effective. Exc
On 2025-03-25 11:59, Thomas Goirand wrote:
Source: snimpy
Version: 1.0.0-1
Severity: serious
Hi,
python3-pysnmp-lextudio was a fork created when the upstream of
pysnmp4 passed away, but since, someone took over the upstream
pypi project. Therefore, pysnmp-lextudio is not to be used
anymore, and
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
Control: tags -1 + moreinfo
Hi Daniel,
Le 2025-03-21 16:57, Daniel Gröber a écrit :
> Package: chrony
> Version: 4.6.1-1
> Severity: normal
> X-Debbugs-Cc: d...@darkboxed.org
>
> Hi Vincent,
>
> I installed and removed chrony=4.6.1-1 in an unstable schroot and
>
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
On 2025-03-18 15:17:08 +0100, Vincent Lefevre wrote:
> To reproduce, at
>
> --\ editorsText editors and word processors (2)
> --\ main The main Debian archive (2)
> i A emacs-bin-common 1:30.1+1-4 1:30.1+1-4+b1
> i emacs-gtk
.14 is planned, but that's almost 5 years
since this message was posted.
Regards,
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
I followed what aptitude suggested.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
g a package to experimental, and I didn't get any.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
OMAIN,pass=
2025-03-17T18:28:12.253419+01:00 di3224su kernel: [5285802.001330] CIFS:
Attempting to mount //cifsserver/DATA_SHARE
[kerberos cifs.upcall with creduid=0]
2025-03-17T18:28:12.276659+01:00 di3224su automount[1505873]: >> mount
error(13): Permission denied
I'm a missing s
er0.22 depends on:
ii libc6 2.41-6
libtree-sitter0.22 recommends no packages.
libtree-sitter0.22 suggests no packages.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
em)
LSM: AppArmor: enabled
Versions of packages screen depends on:
ii debianutils 5.21
ii libc6 2.41-6
ii libcrypt1 1:4.4.38-1
ii libpam0g 1.7.0-3
ii libtinfo6 6.5+20250216-2
ii libutempter0 1.2.1-4
screen recommends no packages.
Versions of packages screen suggests:
.05.0~dfsg-1
ii libc6 2.41-6
ii libx11-6 2:1.8.10-2
ii libxinerama1 2:1.1.4-3+b3
ii libxmu6 2:1.1.3-3+b4
ii libxt6t64 1:1.2.1-1.2+b2
ii xaw3dg 1.5+F-2+b1
gv recommends no packages.
gv suggests no packages.
-- no debconf information
--
Vincent Lefèvre - Web: <
ize of the queue, and even
if there had been one, this should not have been an issue).
So perhaps there's something wrong in the Thread::Queue
implementation.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/b
hi mailcap 3.70+nmu1
ii man-db 2.13.0-1
ii media-types 13.0.0
ii sensible-utils 0.0.24
ii w3m-el 1.4.632+0.20210201.2305.54c3ccd-3
ii w3m-img 0.5.3+git20230121-2.1
ii wget1.25.0-2
ii xdg-utils 1.2.1-2
pn xsel
-- no debconf inf
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:
-utils is related to:
ii tex-common6.19
ii texlive-binaries 2024.20240313.70630+ds-5+b1
-- no debconf information
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
(and stderr) if everything is OK".
I let the reporter of bug 346463 (or anyone else) report a new bug
on 7zip if this is still needed (the man page for 7z from 7zip does
not mention the requested feature).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated
when you re-open bugs, please indicate why.
I think that this is because Emilio Pozuelo Monfort did the forcemerge
in the wrong direction:
forcemerge -1 1099470
instead of
forcemerge 1099470 -1
(where -1 is 1099474).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessib
Awesome, thanks for the very quick response!
On Sat, Mar 8, 2025, at 22:09, NoisyCoil wrote:
> Control: tags -1 incoming
>
> On 08/03/25 21:19, Vincent van Leeuwen wrote:
>> Examining the file it seems to be zsh syntax, not fish syntax. I can't find
>> the file in the u
e something like 'broot
-s ' to get the same error. If you ignore the error broot mostly works fine
after that, except that you can't install the 'br' shell integration without
getting the same error.
Kind regards,
Vincent van Leeuwen
-- System Information:
Debian Releas
On 2025-03-05 15:07:42 -0500, Daniel Kahn Gillmor wrote:
> On Sun 2023-10-29 00:20:09 +0200, in https://bugs.debian.org/1054985, Vincent
> Lefevre wrote:
>
> > gpg-agent needs a working pinentry program. As pinentry-gnome3
> > (installed by default) doesn't work on
042
Yes, the man page is correctly rendered, and
/usr/share/man/man1/gpg.1.gz contains \- as expected. So, this seems
to be fixed on the gnupg2 side, in addition to the decision to revert
groff's decision to map an unescaped "-" to HYPHEN:
https://bugs.debian.org/cgi-bin/bugreport
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.
> >
> &
On 2025-03-05 12:04:04 +0100, Marc Haber wrote:
> On Wed, Mar 05, 2025 at 09:46:53AM +0100, Marc Haber wrote:
> > this is a discussion with Vincent Lefevre on #1099470:
> > >1. For a system account, there would still be an issue if the account↲
> > >has a
7;t know what problem this profile is meant to solve and whether
> adding this rule is appropriate there.
I've just reported the bug upstream.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: C
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
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
r, it should check
whether this is *not* a system user. And it should do that even when
the account is locked or the id mismatches (i.e. the test should
ignore the other flags).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vin
of "locked":
$ret |= EXISTING_LOCKED if (substr($pw,0,1) eq "!"); # TODO: also
check expiry?
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
out an exclamation point).
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
On Tue, 4 Mar 2025 06:28:52 +0100 Petter Reinholdtsen
wrote:
I ran into this too. I got around it by removing the user before doing the
upgrade.
# getent passwd colord
colord:x:105:112:colord colour management daemon,,,:/var/lib/colord:/bin/false
# deluser colord
# apt dist-upgrade
[...]
#
t; I believe that adduser should have their default values built in.
They are in the AdduserCommon.pm file:
first_system_uid => 100,
last_system_uid => 999,
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vi
ord recommends no packages.
Versions of packages colord suggests:
pn colord-sensor-argyll
-- no debconf information
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
e error.
BTW, I don't understand why the test is written to depend
on the lock status.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Hi,
On 2025-03-03 12:03:22 +0100, intrigeri wrote:
> Vincent Lefevre (2025-02-25):
> > I suspect that this is because the firejail-default AppArmor profile
> > does not use "userns" (contrary to the firefox AppArmor profile,
> > which completely changed).
>
&
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
ly, if EXISTING_SYSTEM is set, this means
that this is a system user: in sub existing_user_status:
$ret |= EXISTING_SYSTEM if \
($uid >= $config{"first_system_uid"} && $uid <=
$config{"last_system_uid"});
However, I still don't understand
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.
On 2025-03-02 20:55:29 +0100, Antoine wrote:
> On Mon, 10 Feb 2025 13:06:06 +0100 Vincent Lefevre
> wrote:
> > BTW, like Raphaël, I think I also saw the same issue on the linux and
> > gcc-defaults source packages (but not always).
Note that in my case, I always upgrade all t
program "foo" does not do the same thing in these
two packages A and B, then the user may want to be able to use both
programs on the same installation, which would be possible if the
program names were different (avoiding the package conflict).
--
Vincent Lefèvre - Web: <https://www
On 2025-02-26 12:28:29 -0800, Paul Eggert wrote:
> On 2/26/25 08:06, Vincent Lefevre wrote:
> > Hmm... The upstream bug was closed and archived more than 3 years ago!
> > I'm Cc'ing Paul, who closed the bug upstream.
>
> I assume the upstream bug is <https://
Control: found -1 3.11-4
On 2021-11-24 17:24:02 +0100, Vincent Lefevre wrote:
> The upstream bug has been closed after the move to PCRE2.
>
> Once the new grep is available in Debian, some tests need to be
> done to see whether this change introduces any regression.
That's
Hmm... The upstream bug was closed and archived more than 3 years ago!
I'm Cc'ing Paul, who closed the bug upstream.
BTW, the slowness (with a regexp consisting of just letters) also
seems to occur with grep 3.11 under Termux/Android.
On 2025-02-26 16:53:26 +0100, Vincent Lefevre wrote
Control: affects -1 firejail
... in case something needs to be done on the firejail side.
On 2025-02-25 13:59:04 +0100, Vincent Lefevre wrote:
> On 2025-02-25 12:18:53 +0100, Vincent Lefevre wrote:
> > After the apparmor upgrade to 4.1.0~beta5-2, Firefox
> > (Debian's packa
Control: retitle -1 apparmor: triggers a security warning in Firefox with
firejail
On 2025-02-25 12:18:53 +0100, Vincent Lefevre wrote:
> After the apparmor upgrade to 4.1.0~beta5-2, Firefox
> (Debian's package firefox 135.0.1-1) now displays the
> following warning message:
to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apparmor depends on:
ii debconf [debconf-2.0] 1.5.89
ii libc6 2.40-7
apparmor recommends no packages.
Versions of packages apparmor suggests:
pn apparmor-profiles-extra
p
On 2025-02-21 14:58:50 +0100, Chris Hofstaedtler wrote:
> ... which is just a broken configuration for the machine in question.
It was due to the kernel that was assigning a random name
(eth0 or eth1) to the Ethernet interface. Not sure what
had to be done at that time.
--
Vincent Lefè
On 2025-02-21 14:25:31 +0100, Vincent Lefevre wrote:
> Fri Aug 22 02:38:44 2008: Configuring network interfaces...eth0: error
> fetching interface information: Device not found
> Fri Aug 22 02:38:47 2008: Ignoring unknown interface eth0=eth0.
> Fri Aug 22 02:38:48 2008: if-up.d/m
ace names have been stabilized since 2008.
So errors like "error fetching interface information: Device not found"
should no longer occur.
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work:
Control: retitle -1 tracker-miner-fs: dangling symlink
tracker-miner-fs-3.service before and after purge
On 2025-02-20 18:28:50 +0100, Vincent Lefevre wrote:
> Package: tracker-miner-fs
> Version: 3.8.2-2
> Severity: important
>
> tracker-miner-fs got purged:
>
> 2025
ii libgstreamer1.0-0 1.24.11-1
ii libtracker-sparql-3.0-0 3.8.2-3
ii libupower-glib3 1.90.7-1
ii procps 2:4.0.4-7
ii tracker 3.8.2-3
ii tracker-extract [localsearch] 3.8.2-2
tracker-miner-fs recommends no packa
392mm
597mm x 336mm
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
hine (2015). I don't know whether this
was reproducible with newer kernels because I had to switch to the
Nvidia drivers for another reason, as explained.
Regards,
--
Vincent Lefèvre - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog
Control: tags -1 - moreinfo
Control: close -1
On 2025-02-19 22:28:14 +0100, Salvatore Bonaccorso wrote:
> On Mon, Feb 17, 2025 at 07:39:07PM +0100, Vincent Lefevre wrote:
[...]
> > Feb 17 19:37:05 disset kernel: nouveau :55:00.0: disp: error 0001
> > Feb 17 19:37:05 disset
1 - 100 of 8435 matches
Mail list logo
