Package: dracut
Version: 060+5-8
Severity: normal
X-Debbugs-Cc: in.cognit...@arcor.de
Dear Maintainer,
* What led up to the situation?
Recent update to dracut 060+5-8 and systemd 256~rc3-2.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Regenerated
Hi Daniel,
On 2024-05-08 19:25, Daniel Kahn Gillmor wrote:
thanks for taking care about this in general and this one:
> Thanks, i've reported this part upstream:
> https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/issues/74
in particular.
Should I open another issue about
Never mind. During one of the last t64 upgrade orgies package gpg-sq got
installed on my system and succeeded to install the diversion to /usr/bin/gpg.
And the sequoia replacement is not very feature complete, as they continue
to stress themselfes.
For example, referencing a recipient by exact
A quick comparison of the package sources hasn't revealed anything obvious.
So here is a reproducer (custom pinentry defined in gpg-agent.conf that dumps
its environment):
[~]$ grep ^pinentry-program .gnupg/gpg-agent.conf
pinentry-program/home/farblos/tmp/pinentry
[~]$ cat /home/farblos
Package: gnupg
Version: 2.2.40-3
Severity: normal
X-Debbugs-Cc: in.cognit...@arcor.de
Dear Maintainer,
* What led up to the situation?
Most likely today's upgrade from GnuPG related packages
2.2.40-1.1 -> 2.2.40-3. "Yesterday this still has been working."
* What exactly did you do (or
Package: tar-doc
Version: 1.35-1
Severity: important
X-Debbugs-Cc: in.cognit...@arcor.de
Dear Maintainer,
* What led up to the situation?
Usage of package tar-doc to browse the tar info manual.
* What exactly did you do (or not do) that was effective (or
ineffective)?
>From "emacs
On 2023-09-19 19:50, Nicholas D Steeves wrote:
> On Fri, 15 Sep 2023 14:35:08 +0200 "Farblos"
> wrote:
>> Not sure whether this is still relevant or just bad luck or whatever ... my
>> unattended-upgrade failed today because of this issue. Logs available
Not sure whether this is still relevant or just bad luck or whatever ... my
unattended-upgrade failed today because of this issue. Logs available
on request. Work-around was to remove version 3.20+dfsg-7, retrigger
the unattended upgrade, install version 3.20+dfsg-8.
Thanks for taking care of
Package: src:linux
Version: 6.4.4-3
Severity: normal
X-Debbugs-Cc: in.cognit...@arcor.de
Dear Maintainer,
* What led up to the situation?
Latest kernel update from Debian testing.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Latest kernel update from
On 2023-08-04 22:54, Michael Biebl wrote:
Since I myself can't reproduce the issue anymore with 2.10.0-4, I'm
going to close this bug report again and you ask you to report this
upstream as a separate issue.
Just one more round-trip with you, please:
It seems that you cherry-picked commit
hardware::storage:cd,
hardware::storage:dvd, hardware::usb, implemented-in::c,
interface::daemon, role::program
[~]$ pgrep udisksd
961
[~]$ suls -al /proc/961
[sudo] password for farblos:
total 0
dr-xr-xr-x 9 root root 0 Aug 2 11:20 .
dr-xr-xr-x 360 root root 0 Aug 2 11:
Pinging this issue as I can see it as well in my bullseye system ...
Using an ugly service override
/etc/systemd/system/console-setup.service.d/override.conf:
[Unit]
Wants=systemd-tmpfiles-setup.service
After=systemd-tmpfiles-setup.service
helps as work-around.
--show-config
[Seat:*]
B greeter-session=lightdm-autologin-greeter
A greeter-hide-users=true
A session-wrapper=/etc/X11/Xsession
B user-session=lightdm-xsession
D autologin-user-timeout=0
D autologin-user=farblos
Sources:
A /usr/share/lightdm/lightdm.conf.d/01_debian.conf
B /usr/share
ifferent flash drive with the following steps:
# Ensure Gnome's (or whatever) auto-mounting is off to have
# better control over mount operations.
farblos@sappc2:~$ sudo mkfs.vfat -n "MCBACKUP" /dev/sda1
mkfs.fat 4.2 (2021-01-31)
farblos@sappc2:~$ udisksctl mount --block-device
14 matches
Mail list logo
