Bug#983357: Xen vkb uevent/modalias fix (Debian installer bug)

[Jason Andryuk]

Hi,

A commit to address the Xen virtual keyboard large uevent/modalias
failure has been merged into upstream linux for the upcoming 6.10
release:
https://git.kernel.org/torvalds/c/0774d19038c496f0c3602fb505c43e1b2d8eed85

This should address https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983357
and https://github.com/systemd/systemd/issues/22944

It has already been backported to these stable releases:
6.9.3
6.8.12
6.6.33
6.1.95

It is queued for these future releases (assuming number holds):
5.15.162
5.10.221
5.4.279
4.19.317

Regards,
Jason

Bug#1034878: #1034878 meld gives python traceback if run as root

[jason]

Bug #1034878   -
meld gives python traceback if run as root
  is caused by
the call to Gtk.Settings.get_default() in settings.py at about line 56.

 

This code still exists in the head of the git repo.



As per the PyAPI manual at
https://lazka.github.io/pgi-docs/Gtk-3.0/classes/Settings.html#Gtk.Settings.
get_default . If Gtk is not initialised (which often happens when you sudo
root over a remote shell as you need to pass xauth) then the call to
Gtk.Settings.get_default() will fail and return None.  This is not handled.
The issue is that a couple lines down instead of referencing
Gtk.Setting.props it now looks for (None).props... and breaks as per the bug
report.  Something like following two/four lines are required, though that
is really only a partial fix, as this will eliminate the Python error as per
the bug, but meld will still die horribly this time with a Gtk error, rather
than exit gracefully while informing the user.
I don't know enough about Gtk or meld to fix that.

 


gtk_settings = Gtk.Settings.get_default()

>  # get_default() returns None if there is no graphics, 

 >  # even if the user has settings in their profile

>  if gtk_settings is None:

> return

 prefer_dark = settings.get_boolean(key)

 gtk_settings.props.gtk_application_prefer_dark_theme =
prefer_dark

Cheers,

Jay (the-moog at github)

Bug#929265: IPOPT in Debian approaching 10 years old

[Jason Moore]

Hi,

IPOPT is now at 3.14.14, released Jan 2024. The Debian package is now
almost 10 years old. I'm assuming this Debian package is not being
maintained. How would one go about helping this package get updated to a
newer version?

Jason

Bug#1040499: Seems to be caused by -fstack-protector-strong

[Jason Lynch]

I too am seeing this issue on a freshly installed unstable system. I was 
initially unable to reproduce the issue on a copy of mailutils compiled 
manually (without the Debian scripts). After some comparison of the two 
builds, I was able to finally reproduce by adding the 
-fstack-protector-strong flag to CFLAGS.


It seems the getaddrinfo call on line 86 of libmailutils/base/hostname.c 
is somehow broken by this flag, though this is far outside my wheelhouse 
and I do not really understand what the flag does in detail or how it 
would possibly affect things.

Bug#1057967: linux-image-6.1.0-15-amd64 renders my physical bookworm/gnome computer largely unusable

[Jason Zarin]

The test build also works on my system without issues [2010 macbook with
broadcom-sta-dkms driver]

On Mon, Dec 11, 2023 at 4:12 PM Kevin Price  wrote:

> Breaking news:
>
> Am 11.12.23 um 19:14 schrieb Salvatore Bonaccorso:
> > I have put binary packages for amd64 built in
> > https://people.debian.org/~carnil/tmp/linux/1057967/
>
> I confirm this test kernel is working fine for me, even with non-free
> broadcom-sta.
>
> (sent from
> "
> cat /proc/version
>
> Linux version 6.1.0-0.a.test-amd64 (debian-ker...@lists.debian.org)
> (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian)
> 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.66-1a~test (2023-12-11)
> "
>
> through
>
> "
> modinfo wl
>
> filename:   /lib/modules/6.1.0-0.a.test-amd64/updates/dkms/wl.ko
> license:MIXED/Proprietary
> alias:  pci:v*d*sv*sd*bc02sc80i*
> depends:cfg80211
> …"
> )
>
> Thank you Salvatore. Let's get this into stable soon.
> --
> Kevin Price
>

Bug#1057967:

[Jason Zarin]

I think it highly likely that it's that wifi reversion noted up thread.

On my system, wifi hangs (broadcom-sta-dkms) and causes network manager to
hit 100% according to top.

Problem not present in kernels 6.1.0-13&14 and back port 6.5.

Bug#1057041: qtpositioning5-dev_5.15.8%2bdfsg-3_amd64.deb 404 Not Found

[Jason Weisberger]

Package: mirrors

While attempting to install packages to compile a QT5 program on Debian
12, I get the following package error:

#sudo apt update
#sudo apt install qtpositioning5-dev

Err:3 http://deb.debian.org/debian bookworm/main amd64 qtpositioning5-
dev amd64 5.15.8+dfsg-3
  404  Not Found [IP: 199.232.30.132 80]
Fetched 2,896 kB in 0s (6,285 kB/s)
E: Failed to fetch
http://deb.debian.org/debian/pool/main/q/qtlocation-opensource-src/qtpositioning5-dev_5.15.8%2bdfsg-3_amd64.deb
 404  Not Found [IP: 199.232.30.132 80]
E: Unable to fetch some archives, maybe run apt-get update or try with
--fix-missing?

I see other versions in the repository, but the version that is
supposedly the most updated one doesn't exist on the server.

Using Linux debian-main 6.1.0-12-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.1.52-1 (2023-09-07) x86_64 GNU/Linux, libc6 2.36-9+deb12u3

Bug#1057017: qtpositioning5-dev_5.15.8%2bdfsg-3_amd64.deb 404 Not Found

[Jason Weisberger]

Package: qtpositioning5-dev
Version: 5.15.8%2bdfsg-3_amd64

While attempting to install packages to compile a QT5 program on Debian
12, I get the following package error:

#sudo apt install qtpositioning5-dev

Err:3 http://deb.debian.org/debian bookworm/main amd64 qtpositioning5-
dev amd64 5.15.8+dfsg-3
  404  Not Found [IP: 199.232.30.132 80]
Fetched 2,896 kB in 0s (6,285 kB/s)
E: Failed to fetch
http://deb.debian.org/debian/pool/main/q/qtlocation-opensource-src/qtpositioning5-dev_5.15.8%2bdfsg-3_amd64.deb
 404  Not Found [IP: 199.232.30.132 80]
E: Unable to fetch some archives, maybe run apt-get update or try with
--fix-missing?

I see other versions in the repository, but the version that is
supposedly the most updated one doesn't exist on the server.

Using Linux debian-main 6.1.0-12-amd64 #1 SMP PREEMPT_DYNAMIC Debian
6.1.52-1 (2023-09-07) x86_64 GNU/Linux, libc6 2.36-9+deb12u3

Bug#1054566: twinkle-uri-handler script missing. Please update to release 1.10.3

[Jason Lewis]

Package: twinkle
Version: 1:1.10.2+dfsg-2
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

Twinkle requires helper script so you can dial out by clicking tel links in
Firefox. Current 1.10.2 does not include this script

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***



-- System Information:
Debian Release: 12.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-13-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 twinkle depends on:
ii  libasound2   1.2.8-1+b1
ii  libc62.36-9+deb12u3
ii  libccrtp2v5  2.0.9-2.3
ii  libgcc-s112.2.0-14
ii  libgsm1  1.0.22-1
ii  libmagic11:5.44-3
ii  libqt5core5a 5.15.8+dfsg-11
ii  libqt5gui5   5.15.8+dfsg-11
ii  libqt5qml5   5.15.8+dfsg-3
ii  libqt5quick5 5.15.8+dfsg-3
ii  libqt5widgets5   5.15.8+dfsg-11
ii  libreadline8 8.2-1.3
ii  libsndfile1  1.2.0-1
ii  libspeex11.2.1-2
ii  libspeexdsp1 1.2.1-1
ii  libstdc++6   12.2.0-14
ii  libucommon8  7.0.1-0.1
ii  libxml2  2.9.14+dfsg-1.3~deb12u1
ii  qml-module-qtquick2  5.15.8+dfsg-3
ii  twinkle-common   1:1.10.2+dfsg-2

twinkle recommends no packages.

twinkle suggests no packages.

-- no debconf information

Bug#1053227: lieer 1.5 relies on a newer, unavailble version of python3-google-auth

[Jason Riedy]

Package: lieer
Version: 1.5-1
Severity: important

Dear Maintainer,

Updating lieer to 1.5 breaks on saving credentials. The reason is
that the python3-google-auth package is severely out of date. The
to_json method was added to 1.8, and the 2.x series is now over a
year old.

The only fix within lieer is to downgrade to 1.3.

-- System Information:
Debian Release: trixie/sid
  APT prefers oldstable-security
  APT policy: (500, 'oldstable-security'), (500, 'unstable'), (500, 'testing'), 
(500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.4.0-4-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 lieer depends on:
ii  python3   3.11.4-5+b1
ii  python3-googleapi 1.7.12-1
ii  python3-notmuch   0.38-2
ii  python3-oauth2client  4.1.3-5
ii  python3-tqdm  4.64.1-1

lieer recommends no packages.

lieer suggests no packages.

-- no debconf information

Bug#1041764: No improvements with latest update

[Jason Bigelow]

I updated to kernel 6.1.0-11-amd64 today. No changes to the situation 
upon reboot, I still have to modprobe amdgpu.

Bug#1037044: Forced password reset leaves behind failed user@.service unit

[Jason Franklin]

Package: systemd
Version: 252.6-1
Severity: normal

Greetings:

It appears that user@.service is left in a failed state when a user logs
in over ssh and is forced to reset their password due to expiration.

I was able to regularly reproduce this behavior with the process
described below.

# Create a test user.
$ sudo adduser fish
...

# Ensure no failed units.
$ systemctl list-units --failed
...

# Expire the user's password.
$ sudo passwd -e fish

# Log in via ssh. Properly change the user's password when prompted.
$ ssh fish@localhost
...
# Here, you will be kicked back out to your prompt after the new
# password is set.

# Now, note that a failed unit for the user is left behind.
$ systemctl list-units --failed
  UNIT   LOAD   ACTIVE SUBDESCRIPTION
* user@1001.service  loaded failed failed User Manager for UID 1001
...

I think the above accurately describes the behavior I'm seeing.

It seems odd to me that the failed service lingers even though the
user's password has been changed correctly, without any real failures in
the process. The user is now able to log in and what not, but systemd
indicates a failure.

This is an issue for me because these failures can stack up on systems
at my work, and monitoring of failed units then indicates a problem
where there is not one.

Please let me know any thoughts on this. It could be another piece of
software that's causing the error. Or, it could be that I have something
improperly configured or that I am misinterpreting things.

Many thanks,

-- 
Jason Franklin

Bug#1034661: twinkle: Please update twinkle to latest release

[Jason Lewis]

Package: twinkle
Version: 1:1.10.2+dfsg-1
Severity: minor

Dear Maintainer,

Please can you update twinkle to the latest release version 1.10.3

this will at least solve https://github.com/LubosD/twinkle/issues/222

Thanks

Jason

-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-7-amd64 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 twinkle depends on:
ii  libasound2   1.2.8-1+b1
ii  libc62.36-9
ii  libccrtp2v5  2.0.9-2.3
ii  libgcc-s112.2.0-14
ii  libgsm1  1.0.22-1
ii  libmagic11:5.44-3
ii  libqt5core5a 5.15.8+dfsg-3
ii  libqt5gui5   5.15.8+dfsg-3
ii  libqt5qml5   5.15.8+dfsg-3
ii  libqt5quick5 5.15.8+dfsg-3
ii  libqt5widgets5   5.15.8+dfsg-3
ii  libreadline8 8.2-1.3
ii  libsndfile1  1.2.0-1
ii  libspeex11.2.1-2
ii  libspeexdsp1 1.2.1-1
ii  libstdc++6   12.2.0-14
ii  libucommon8  7.0.1-0.1
ii  libxml2  2.9.14+dfsg-1.1+b3
ii  qml-module-qtquick2  5.15.8+dfsg-3
ii  twinkle-common   1:1.10.2+dfsg-1

twinkle recommends no packages.

twinkle suggests no packages.

-- no debconf information

Bug#1034474: easyeffects: Lose all audio output when using pw-loopback at the same time as easyeffects

[Jason Bigelow]

I have also noticed the following output to the terminal when I launch 
easyeffects:
(easyeffects:24360): easyeffects-WARNING **: 20:47:56.290: 
stream_output_effects.cpp:270     link from node 265 to node 213 failed


(easyeffects:24360): easyeffects-WARNING **: 20:47:56.290: 
stream_output_effects.cpp:270     link from node 265 to node 292 failed


(easyeffects:24360): easyeffects-WARNING **: 20:47:56.290: 
stream_output_effects.cpp:303     link from node 265 to output device 46 
failed

Bug#1034474: easyeffects: Lose all audio output when using pw-loopback at the same time as easyeffects

[Jason Bigelow]

Package: easyeffects
Version: 7.0.0-1
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

I ordinarily plug my electric bass into the Line In input on my sound card and
listen with pw-loopback and the command line. I then use easyeffects to apply
some effects: a noise gate, compression and a limiter.

Previously, this setup worked fine and I was able to hear my bass with applied
effects - at least I think so, the effects are meant to be minimal on top of the
instrument's clean sound.

Recently out of the blue, through no configuration change to easyeffects, I
started losing all sound output when concurrently running pw-loopback and 
easyeffects.
By disabling pw-loopback from Output -> Player in easyeffects, I can restore
sound, so it seems directly linked to the use of that programs input. Sound is
properly restored in any case to the ordinary clean sound when I close
easyeffects and leave pw-loopback running.

Removing ~/.config/easyeffects and using easyeffects -r both had no effect,
other than losing my saved presets, so I don't know how it could be
related to configuration, or if it is, it seems to not be a sensible default or
some other part of the stack has changed.

I'd like to continue to be able to use effects on my bass while listening to its
output so a fix would be greatly appreciated. Thank you.

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: 12.0
  APT prefers testing-security
  APT policy: (500, 'testing-security'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-7-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages easyeffects depends on:
ii  calf-plugins 0.90.3-4
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4
ii  libadwaita-1-0   1.2.2-1
ii  libbs2b0 3.1.0+dfsg-7
ii  libc62.36-8
ii  libcairo21.16.0-7
ii  libebur128-1 1.2.6-1+b1
ii  libfftw3-double3 3.3.10-1
ii  libfftw3-single3 3.3.10-1
ii  libfmt9  9.1.0+ds1-2
ii  libgcc-s112.2.0-14
ii  libglib2.0-0 2.74.6-1
ii  libgsl27 2.7.1+dfsg-3+b1
ii  libgtk-4-1   4.8.3+ds-2
ii  liblilv-0-0  0.24.14-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpipewire-0.3-00.3.65-3
ii  librubberband2   3.1.2+dfsg0-1
ii  libsamplerate0   0.2.2-3
ii  libsigc++-3.0-0  3.4.0-1
ii  libsndfile1  1.2.0-1
ii  libspeexdsp1 1.2.1-1
ii  libstdc++6   12.2.0-14
ii  libtbb12 2021.8.0-1
ii  libzita-convolver4   4.0.3-2

Versions of packages easyeffects recommends:
ii  lsp-plugins-lv2  1.2.5-1

easyeffects suggests no packages.

-- no debconf information

Bug#1031846: installation-reports: Same as bug #1031806 Install completes successfully after reboot no /home /Documents etc folders

[Jason Daborn]

Hi Aurélien,

Sorry, yes can confirm it was KDE/Plasma. Thx for your quick work!

Regards

Jason



From: Aurélien COUDERC 
Sent: Saturday, February 25, 2023 1:24:05 AM
To: Jason ; 1031...@bugs.debian.org 
<1031...@bugs.debian.org>; Debian Bug Tracking System 
Subject: Re: Bug#1031846: installation-reports: Same as bug #1031806 Install 
completes successfully after reboot no /home /Documents etc folders

Dear Jason,

could you please confirm which desktop environment you installed ?

If it's KDE/Plasma I fixed the issue in the desktop-base package version 
12.0.3, currently in testing and that should reach unstable in a couple of days.

If you feel like testing the fix you could upgrade to unstable and try with a 
new user to check that it's fixed.

On an existing user running :
xdg-user-dirs-update
should fix the issue.


Haply hacking !
--
Aurélien

Bug#1031846: installation-reports: Same as bug #1031806 Install completes successfully after reboot no /home /Documents etc folders

[Jason]

Package: installation-reports
Severity: important
X-Debbugs-Cc: mtx_li...@hotmail.com

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: 
https://cdimage.debian.org/cdimage/bookworm_di_alpha2/amd64/iso-cd/debian-bookworm-DI-alpha2-amd64-netinst.iso
Date: 

Machine: Lenovo Thinkpad Edge E420
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [o ]
Detect network card:[o ]
Configure network:  [o ]
Detect media:   [o ]
Load installer modules: [o ]
Clock/timezone setup:   [o ]
User/password setup:[o ]
Detect hard drives: [o ]
Partition hard drives:  [o ]
Install base system:[o ]
Install tasks:  [o ]
Install boot loader:[o ]
Overall install:[o ]

Comments/Problems: None of the folders /Documents /Pictures /Videos /Downloads 
etc are present




Please make sure that any installation logs that you think would
be useful are attached to this report. (You can find them in the
installer system in /var/log/ and later on the installed system
under /var/log/installer.) Please compress large files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230217"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux e420debian 6.1.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.8-1 
(2023-01-29) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core 
Processor Family DRAM Controller [8086:0104] (rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd 
Generation Core Processor Family PCI Express Root Port [8086:0101] (rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd 
Generation Core Processor Family Integrated Graphics Controller [8086:0116] 
(rev 09)
lspci -knn: Subsystem: Lenovo Device [17aa:21e3]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 6 
Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 
Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series 
Chipset Family High Definition Audio Controller [8086:1c20] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: snd_hda_intel
lspci -knn: Kernel modules: snd_hda_intel
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b4)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 2 [8086:1c12] (rev b4)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.2 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 3 [8086:1c14] (rev b4)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.3 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 4 [8086:1c16] (rev b4)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.7 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series 
Chipset Family PCI Express Root Port 8 [8086:1c1e] (rev b4)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 
Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: Kernel driver in use: ehci-pci
lspci -knn: Kernel modules: ehci_pci
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation HM65 Express Chipset 
LPC Controller [8086:1c49] (rev 04)
lspci -knn: Subsystem: Lenovo Device [17aa:21e2]
lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 
Series 

Bug#1031806: installation-reports: Installation completed successfully but no user /home folder or Documents, Pictures etc

[Jason]

Package: installation-reports
Severity: normal
X-Debbugs-Cc: mtx_li...@hotmail.com

(Please provide enough information to help the Debian
maintainers evaluate the report efficiently - e.g., by filling
in the sections below.)

Boot method: USB
Image version: 
https://gemmei.ftp.acc.umu.se/cdimage/bookworm_di_alpha2/amd64/iso-cd/debian-bookworm-DI-alpha2-amd64-netinst.iso
Date: 

Machine: Dell Inspiron 3670
Partitions: 


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O ]
Detect network card:[O ]
Configure network:  [O ]
Detect media:   [O ]
Load installer modules: [O ]
Clock/timezone setup:   [O ]
User/password setup:[O ]
Detect hard drives: [O ]
Partition hard drives:  [O ]
Install base system:[O ]
Install tasks:  [O ]
Install boot loader:[O ]
Overall install:[O ]

Comments/Problems:




Please make sure that any installation logs that you think would
be useful are attached to this report. (You can find them in the
installer system in /var/log/ and later on the installed system
under /var/log/installer.) Please compress large files using gzip.


-- Package-specific info:

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="12 (bookworm) - installer build 20230217"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux debian 6.1.0-3-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.8-1 
(2023-01-29) x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 8th Gen Core 
Processor Host Bridge/DRAM Registers [8086:3ec2] (rev 07)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core 
Processor PCIe Controller (x16) [8086:1901] (rev 07)
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.0 Display controller [0380]: Intel Corporation CoffeeLake-S 
GT2 [UHD Graphics 630] [8086:3e92]
lspci -knn: DeviceName: Onboard - Video
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: 00:08.0 System peripheral [0880]: Intel Corporation Xeon E3-1200 
v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model 
[8086:1911]
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: 00:12.0 Signal processing controller [1180]: Intel Corporation 
Cannon Lake PCH Thermal Controller [8086:a379] (rev 10)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation Cannon Lake PCH 
USB 3.1 xHCI Host Controller [8086:a36d] (rev 10)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: Kernel driver in use: xhci_hcd
lspci -knn: Kernel modules: xhci_pci
lspci -knn: 00:14.2 RAM memory [0500]: Intel Corporation Cannon Lake PCH Shared 
SRAM [8086:a36f] (rev 10)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Intel Corporation Device [8086:7270]
lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation Cannon 
Lake PCH HECI Controller [8086:a360] (rev 10)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: 00:17.0 SATA controller [0106]: Intel Corporation Cannon Lake PCH 
SATA AHCI Controller [8086:a352] (rev 10)
lspci -knn: DeviceName: Onboard - SATA
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1b.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI 
Express Root Port #21 [8086:a32c] (rev f0)
lspci -knn: DeviceName: Intel HD Audio
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.0 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI 
Express Root Port #5 [8086:a33c] (rev f0)
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1c.7 PCI bridge [0604]: Intel Corporation Cannon Lake PCH PCI 
Express Root Port #8 [8086:a33f] (rev f0)
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation Device [8086:a308] 
(rev 10)
lspci -knn: DeviceName: Onboard - Other
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn: 00:1f.3 Audio device [0403]: Intel Corporation Cannon Lake PCH cAVS 
[8086:a348] (rev 10)
lspci -knn: DeviceName: Onboard - Sound
lspci -knn: Subsystem: Dell Device [1028:0868]
lspci -knn:  

Bug#1028473: dictionaries-common: problem in russian dict. Word '��� ��' contains illegal characters.

[Jason Lee Quinn]

Package: dictionaries-common
Version: 1.29.3
Followup-For: Bug #1028473
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com

Thank you for the reply.

If these dictionaries are installed,
where are they located? I've searched
/usr/lib/ispell and many other places can only find
american and british dictionaries on my machine.

Also where does the "contains illegal characters" message
actually come from? Whatever the source of that messgae,
I'm having trouble tracking it down. A techincal explaination
about why the message is harmless would also be interesting
for me. Perhaps the message itself and the logic that produces
it could be improved to provide a nicer user experience.

Bug#1028473: dictionaries-common: problem in russian dict. Word '��� ��' contains illegal characters.

[Jason Lee Quinn]

Package: dictionaries-common
Version: 1.29.3
Severity: minor
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com

Dear Maintainer,

About two weeks ago on a fresh install of Debian Bookworm
from a daily installer build I
came accross a dictionary error related to the
installation of synaptic. The relavent output is



Setting up synaptic (0.91.2) ...
Processing triggers for dictionaries-common (1.29.3) ...
ispell-autobuildhash: Processing 'american' dict.
ispell-autobuildhash: Processing 'brasilero' dict.
ispell-autobuildhash: Processing 'british' dict.
ispell-autobuildhash: Processing 'catala' dict.
ispell-autobuildhash: Processing 'danish' dict.
ispell-autobuildhash: Processing 'espa-nol' dict.
ispell-autobuildhash: Processing 'lietuviu' dict.
ispell-autobuildhash: Processing 'ngerman' dict.
ispell-autobuildhash: Processing 'polish' dict.
ispell-autobuildhash: Processing 'portugues' dict.
ispell-autobuildhash: Processing 'russian' dict.

Word '��� ��' contains illegal characters.
ispell-autobuildhash: Processing 'swiss' dict.



It looks to be an error in a dictionary file
but I never selected any language except English so
this is default behavior and as far as I can
tell I do not even have the russian dictionary
installed at all.

My best guess is that this is a issue in
dictionaries-common/dc-deconf-select.pl and/or
related files related to dpkg triggers.

If you'd like more details about this just suggest
what extra info you'd like and I can try to 
supply it.

Cheers,
Jason



-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dictionaries-common depends on:
ii  debconf [debconf-2.0]  1.5.81
ii  emacsen-common 3.0.5
ii  libtext-iconv-perl 1.7-8

dictionaries-common recommends no packages.

Versions of packages dictionaries-common suggests:
ii  aspell0.60.8-4+b1
ii  ispell3.4.05-1
ii  wamerican [wordlist]  2020.12.07-2

-- debconf information:
  dictionaries-common/ispell-autobuildhash-message:
* dictionaries-common/default-ispell: american (American English)
* dictionaries-common/default-wordlist: american (American English)
  dictionaries-common/selecting_ispell_wordlist_default:
  dictionaries-common/invalid_debconf_value:
  dictionaries-common/debconf_database_corruption:
  dictionaries-common/old_wordlist_link: true

Bug#987503: swap partition only 1 GB instead of at least 1 x RAM size

[Jason Quinn]

I was also bitten by this bug with the Debian bookworm alpha1 era
installer. This is not a wishlist kind of bug; This is a bug of grave
severity. Breaking hibernation is unacceptable and is a key feature of
modern operating systems for both laptop and desktop users. If the
idea behind the 1GB default is to cater to the server world, then
somewhere the installer needs to either prompt the user to say what
kind of installation it is (desktop or server) or to offer a choice
between the two camps so the installer picks better defaults.

I completely don't understand the comments about hibernation not
working on x86. I'm going to disregard that unless there's a
clarification.

Thanks to Johannes (in Message #30) for suggesting a solution. Other
workarounds found on the web suggest tinkering with systemd's
SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK variable and re-configuring
the GRUB menu (see
https://bbs.archlinux.org/viewtopic.php?pid=1928690#p1928690). I
haven't tried these yet but the Debian installer shouldn't burden
users with such low-level tinkering.

This is going to push potential Debian users to other distros after
they discover hibernate doesn't work.

Bug#1028033: xfce4 package incorrectly reporting version 4.16 instead of 4.18

[Jason Lee Quinn]

Package: xfce4
Version: 4.16
Severity: normal
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com

Dear Maintainer,

The xfce4 package still thinks xfce 4.16 is being used even
though it is now 4.18. 

I use Synaptic and it shows that the xfce4 package reports 4.16 as
both the "Installed" and "Latest Version". 

This system was installed through a daily installer after the
change to 4.18 so all vestiges of 4.16 should be gone.
I picked "XFCE" as my desktop during an expert net install. The
task-xfce-desktop package is reporting itself as version 3.70.

I'd guess it's just a minor packaging error where a versioning
number was forgotten to be changed.

Cheers,
Jason


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4 depends on:
ii  libxfce4ui-utils 4.18.0-1
ii  thunar   4.18.0-1
ii  xfce4-appfinder  4.18.0-1
ii  xfce4-panel  4.18.0-1
ii  xfce4-pulseaudio-plugin  0.4.5-1
ii  xfce4-session4.18.0-1
ii  xfce4-settings   4.18.0-1
ii  xfconf   4.18.0-1
ii  xfdesktop4   4.18.0-1
ii  xfwm44.18.0-1

Versions of packages xfce4 recommends:
ii  desktop-base  12.0.2
ii  tango-icon-theme  0.8.90-11
ii  thunar-volman 4.18.0-1
ii  xfce4-notifyd 0.6.5-1
ii  xorg  1:7.7+23

Versions of packages xfce4 suggests:
ii  xfce4-goodies4.14.0
ii  xfce4-power-manager  4.18.0-1

-- no debconf information

Bug#1027762: Regression Pipewire 0.63 breaks underruns breaking emacspeak accessibility

[Jason White]

I tested your supplied code with Pipewire 0.3.63-1, and reproduced the bug.

Bug#1027301: desktop-base: Positioning of the "Debian 12" logo on GRUB2 splashscreen makes GRUB2 text hard to read

[Jason Lee Quinn]

Package: desktop-base
Version: 12.0.2
Severity: important
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com

Dear Maintainer,

While the GRUB2 menu is being displayed, there's a "Debian 12" logo
on the splashscreen in the lower lefthand corner. GRUB2 however
displays text there (including the countdown timer message) and
it is very hard to read because of the logo. This may depend
on the user's screen resolution. I'm using 1440p and the
the positioning conflict is maximally bad there.

The logo would be much better positioned if it were on the
lower LEFT-hand side.

Cheers,
Jason

PS I used yesterday's daily Bookworm net installer so the
issue is as current as it could be.

PPS I noticed below in the auto generated message from
reportbug that desktop-base is suggesting xfce 4.16.
That should also be changed because we recently updated
testing to 4.18.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 6.0.0-6-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages desktop-base depends on:
ii  fonts-quicksand  0.2016-2.1
ii  librsvg2-common  2.54.5+dfsg-1

Versions of packages desktop-base recommends:
ii  plymouth-label  22.02.122-2

Versions of packages desktop-base suggests:
ii  xfce4  4.16

-- no debconf information

Bug#1026356: Cannot configure Neomutt to use gssapi/kerberos for SMTP

[Jason White]

Package: neomutt

Version: 20220429+dfsg1-4.1


If my .muttrc configuration includes the line:
set smtp_authenticators="gssapi"
then Neomutt gives an error on startup while processing the 
configuration file, citing the above line: "Option smtp_authenticators: 
gssapi is not a valid authenticator".


It correctly authenticates to the server via IMAP with Kerberos/gssapi. 
Furthermore, Mutt (i.e., from the Mutt package) correctly processes the 
above configuration.


If I recall correctly (and I don't have a system available for checking 
at the moment), the Neomutt package under Arch Linux, which is probably 
closer to upstream, does not have this bug; it may be Debian-specific.

Bug#1025623: should we deprecate DHOME, GROUPHOMES, LETTERHOMES?

[Jason Franklin]

On Tue, Dec 06, 2022 at 07:29:46PM +0100, Marc Haber wrote:
> I am wondering whether it is still worth to maintain DHOME, GROUPHOMES
> and LETTERHOMES. Installations as big that they need this are likely ot
> have a directory service.

Personally, I am fine with removing these features since I have never
seen a site organize home directories in the way that GROUPHOMES or
LETTERHOMES suggests. Every site I have encountered places home
directories immediately under "/home", which is the default.

I have no clue how many users out there have come to rely on these
features, however.

Hmmm... Maybe someone else will provide a better-informed opinion.

Best,

-- 
Jason Franklin

Bug#1024734: pipewire-pulse: please enable auto switch on connect in pipewire-pulse.conf by default

[Jason Lewis]

Package: pipewire-pulse
Version: 0.3.60-2
Severity: wishlist

Dear Maintainer,


* What led up to the situation?

I connected my already paired headset to my machine.


* What exactly did you do (or not do) that was effective (or

ineffective)?


It connected without error

* What was the outcome of this action?

Chrome was not outputting any sound to my bluetooth headset

* What outcome did you expect instead?

I expect sound should have been directed from chrome to my headset 
automatically after my headset connects to the computer.



I eventually found that I could manually switch output using Pulse 
Volume control. It would be better to automatically switch when the bt 
device connects.


See 
https://alexandra-zaharia.github.io/posts/fix-disabled-a2dp-profile-for-bluetooth-headset-in-linux/


Fix involves adding "{ path = "pactl" args = "load-module 
module-switch-on-connect" }"


to the /usr/share/pipewire/pipewire-pulse.conf file

Please consider making this the default

Thanks

Jason




-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.0.0-4-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 pipewire-pulse depends on:
ii init-system-helpers 1.65.2
ii pipewire 0.3.60-2

Versions of packages pipewire-pulse recommends:
ii pulseaudio-utils 16.1+dfsg1-2+b1

Versions of packages pipewire-pulse suggests:
ii libspa-0.2-bluetooth 0.3.60-2

-- no debconf information

--
Jason Lewis
http://emacstragic.net

Bug#1016014: adduser: Broken symlinks in /usr/*/man8 folders. Affects piuparts

[Jason Franklin]

On Fri, 2022-11-11 at 12:07 +0100, Bastian Germann wrote:
> Control: severity -1 important
> 
> Can you please fix this? This is really annoying for all maintainers who care 
> about the piuparts test results of their 
> packages (all maintainers?). I always have to look more closely because I 
> might have introduced a bug but every time for 
> the past 4 months it was this issue that comes up. This will lead people to 
> ignore piuparts and will introduce bugs.

I find it odd that our Salsa CI pipeline still shows a green check even
though piuparts is emitting an error message about these links. I hope
that doesn't indicate some kind of problem with our CI setup. :/

This is simple enough to fix, however. We can always add the links back
when up-to-date translations are submitted.

I will send up a merge request today and then ping a reviewer about it
to move things along.

Thanks to Peter, Andreas, and Bastian for being persistent. :)

-- 
Jason Franklin

Bug#1023836: Maintainer scripts should use /bin/sh unless Bash features are required

[Jason Franklin]

Package: adduser
Version: 3.129
Severity: minor

Greetings:

One user requested that our maintainer scripts be refactored to use
syntax that is compatible with /bin/sh.

Since only minor changes are needed to satisfy the request, I figured we
could simply go ahead with it.

I will send up a merge request shortly. :)

Best,

-- 
Jason Franklin

Bug#1023308: ncdu: please update ncdu package to upstream 2.2.1 version

[Jason Lewis]

Package: ncdu
Version: 1.17-0.1
Severity: wishlist

Dear Maintainer,

ncdu upstream is up to v2.2.1 now. please consider updating the debian 
package


thanks

Jason



-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 ncdu depends on:
ii libc6 2.35-4
ii libncursesw6 6.3+20220423-2
ii libtinfo6 6.3+20220423-2

ncdu recommends no packages.

ncdu suggests no packages.

-- no debconf information

--
Jason Lewis
http://emacstragic.net

Bug#1023307: baresip is up to v2.9.0 upstream please consider updating the packages

[Jason Lewis]

Package: baresip
Severity: wishlist

Dear Maintainer,

Please consider packaging a newer version of baresip. it is up to v2.9.0 
upstream now.


thanks

Jason


-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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

--
Jason Lewis
http://emacstragic.net

Bug#1023306: baresip is up to v2.9.0 upstream please consider updating the debian packages

[Jason Lewis]

Package: baresip
Severity: wishlist

Dear Maintainer,

Please consider packaging a newer version of baresip. it is up to v2.9.0 
upstream now.



thanks


Jason



-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'oldstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.19.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.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 baresip depends on:
pn baresip-core

Versions of packages baresip recommends:
pn baresip-ffmpeg
pn baresip-gstreamer
pn baresip-gtk
pn baresip-x11

baresip suggests no packages.

--
Jason Lewis
http://emacstragic.net

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

The issue also occurs when using the lookupcache=none option along with the 
5.10.X kernel.
I was hoping for this option to succeed and to investigate the performance 
impact, but it is no longer viable.
I believe that I am out of options to try with the 5.10.X kernel.
Please let me know where we stand.

> -Original Message-
> From: Jason Breitman
> Sent: Wednesday, September 21, 2022 1:01 PM
> To: Ben Hutchings ; 1017...@bugs.debian.org
> Subject: RE: Bug#1017720: nfs-common: No such file or directory
> 
> I now know that this behavior does exist in Debian Buster 10.8 and more
> specifically in the 4.19.X kernel after running stricter testing on more 
> servers.
> The 4.19.X kernel resolves itself immediately following the No such file or
> directory error which is different than the 5.X kernel requiring me to clear 
> the
> inode and dentry cache by running echo 2 > /proc/sys/vm/drop_caches.
> What further information is required to resolve this issue?
> 
> > -Original Message-
> > From: Jason Breitman
> > Sent: Tuesday, September 13, 2022 4:41 PM
> > To: Ben Hutchings ; 1017...@bugs.debian.org
> > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> >
> > I downgraded the nfs-common package which required the downgrade of
> > the libevent packages and am using the 4.19.X kernel.
> > I see the issue running the initial test, but then the issue is gone when
> > running the test a subsequent time.
> >
> > libevent-2.1-6:amd64  2.1.8-stable-4
> > amd64
> > Asynchronous event notification library
> > libevent-core-2.1-6:amd64 2.1.8-stable-4
> > amd64
> > Asynchronous event notification library (core)
> > libevent-pthreads-2.1-6:amd64 2.1.8-stable-4
> > amd64
> > Asynchronous event notification library (pthreads)
> > linux-image-4.19.0-21-amd644.19.249-2  
> > amd64Linux
> > 4.19 for 64-bit PCs (signed)
> > nfs-common  1:1.3.4-2.5+deb10u1 
> >amd64NFS
> > support files common to client and server
> >
> > What other packages do I need to downgrade in order to get Debian 11.4 to
> > behave like Debian 10.8?
> > What additional questions can I answer so that we can move forward?
> >
> > > -Original Message-
> > > From: Jason Breitman
> > > Sent: Tuesday, September 6, 2022 5:18 PM
> > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > >
> > > I also see the failure with the kernels below, but the 4.19.X kernel
> resolves
> > > the issue without dropping caches.
> > > linux-image-4.19.0-14-amd64   4.19.171-2 amd64
> > > Linux 4.19
> > for
> > > 64-bit PCs (signed)
> > > linux-image-4.19.0-21-amd64   4.19.249-2 amd64
> > > Linux 4.19
> > for
> > > 64-bit PCs (signed)
> > >
> > > I see the issue running the initial test, but then the issue is gone when
> > > running the test a subsequent time.
> > > I ran several tests to verify the behavior differences between the 4.19.X
> > and
> > > 5.X kernels.
> > >
> > > -- Test
> > > ls -l /mnt/dir/someOtherDir/* | grep '?'
> > >
> > > -- Error message - the error message is showing files that have been
> erased
> > > via rsync --delete
> > > ls: cannot access 'filename': No such file or directory
> > > -? ? ???? filename
> > >
> > > > -Original Message-
> > > > From: Jason Breitman
> > > > Sent: Friday, September 2, 2022 5:17 PM
> > > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > > >
> > > > I have tested with the following kernels and see this issue in each 
> > > > case.
> > > >
> > > > linux-image-5.10.0-16-amd64  5.10.127-1 
> > > >  amd64
> > > Linux
> > > > 5.10 for 64-bit PCs (signed)
> > > > linux-image-5.15.0-0.bpo.3-amd64 5.15.15-2~bpo11+1  
> > > > amd64
> > > > Linux 5.15 for 64-bit PCs (signed)
> > > > linux-image-5.18.0-0.deb11.3-amd64 5.18.14-1~bpo11+1  amd64
> > > &g

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

I now know that this behavior does exist in Debian Buster 10.8 and more 
specifically in the 4.19.X kernel after running stricter testing on more 
servers.
The 4.19.X kernel resolves itself immediately following the No such file or 
directory error which is different than the 5.X kernel requiring me to clear 
the inode and dentry cache by running echo 2 > /proc/sys/vm/drop_caches.
What further information is required to resolve this issue?

> -Original Message-
> From: Jason Breitman
> Sent: Tuesday, September 13, 2022 4:41 PM
> To: Ben Hutchings ; 1017...@bugs.debian.org
> Subject: RE: Bug#1017720: nfs-common: No such file or directory
> 
> I downgraded the nfs-common package which required the downgrade of
> the libevent packages and am using the 4.19.X kernel.
> I see the issue running the initial test, but then the issue is gone when
> running the test a subsequent time.
> 
> libevent-2.1-6:amd64  2.1.8-stable-4  
>   amd64
> Asynchronous event notification library
> libevent-core-2.1-6:amd64 2.1.8-stable-4
> amd64
> Asynchronous event notification library (core)
> libevent-pthreads-2.1-6:amd64 2.1.8-stable-4amd64
> Asynchronous event notification library (pthreads)
> linux-image-4.19.0-21-amd644.19.249-2  
> amd64Linux
> 4.19 for 64-bit PCs (signed)
> nfs-common  1:1.3.4-2.5+deb10u1   
>  amd64NFS
> support files common to client and server
> 
> What other packages do I need to downgrade in order to get Debian 11.4 to
> behave like Debian 10.8?
> What additional questions can I answer so that we can move forward?
> 
> > -Original Message-
> > From: Jason Breitman
> > Sent: Tuesday, September 6, 2022 5:18 PM
> > To: Ben Hutchings ; 1017...@bugs.debian.org
> > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> >
> > I also see the failure with the kernels below, but the 4.19.X kernel 
> > resolves
> > the issue without dropping caches.
> > linux-image-4.19.0-14-amd64   4.19.171-2 amd64  
> >   Linux 4.19
> for
> > 64-bit PCs (signed)
> > linux-image-4.19.0-21-amd64   4.19.249-2 amd64  
> >   Linux 4.19
> for
> > 64-bit PCs (signed)
> >
> > I see the issue running the initial test, but then the issue is gone when
> > running the test a subsequent time.
> > I ran several tests to verify the behavior differences between the 4.19.X
> and
> > 5.X kernels.
> >
> > -- Test
> > ls -l /mnt/dir/someOtherDir/* | grep '?'
> >
> > -- Error message - the error message is showing files that have been erased
> > via rsync --delete
> > ls: cannot access 'filename': No such file or directory
> > -? ? ???? filename
> >
> > > -Original Message-
> > > From: Jason Breitman
> > > Sent: Friday, September 2, 2022 5:17 PM
> > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > >
> > > I have tested with the following kernels and see this issue in each case.
> > >
> > > linux-image-5.10.0-16-amd64  5.10.127-1   
> > >amd64
> > Linux
> > > 5.10 for 64-bit PCs (signed)
> > > linux-image-5.15.0-0.bpo.3-amd64 5.15.15-2~bpo11+1  amd64
> > > Linux 5.15 for 64-bit PCs (signed)
> > > linux-image-5.18.0-0.deb11.3-amd64 5.18.14-1~bpo11+1  amd64
> > > Linux 5.18 for 64-bit PCs (signed)
> > >
> > > An interesting note is that when using the 5.18 kernel, I had to run echo 
> > > 3
> >
> > > /proc/sys/vm/drop_caches to resolve the issue.
> > > echo 2 > /proc/sys/vm/drop_caches did not work as it did on the 5.10 and
> > > 5.15 kernels.
> > >
> > > > -Original Message-
> > > > From: Jason Breitman
> > > > Sent: Friday, August 26, 2022 3:36 PM
> > > > To: 'Ben Hutchings' ;
> '1017...@bugs.debian.org'
> > > > <1017...@bugs.debian.org>
> > > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > > >
> > > > I was able to identify another workaround today which may help you to
> > > > identify the issue.
> > > > The workaround is to touch the directory where the troubled files live
> on
> > > the
> > > > file server.
> >

Bug#1020220: roger-router: Dead link

[Jason]

Package: roger-router
Version: 2.2.1-1
Severity: minor
X-Debbugs-Cc: qt...@disroot.org

Dear Maintainer,

The link under External Resources > Homepage [www.tabos.org] is dead.
The current website is https://www.tabos.org/projects/rogerrouter/

Bug#1019545: closed by Michael Tokarev (Re: Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bull

[Jason Wittlin-Cohen]

One more factor that may be relevant. This is a really old Debian install.
It was first installed sometime in 2014 and thus would have used Wheezy .
So, it's been upgraded from Wheezy > Jessie > Stretch > Buster > Bullseye.

/var/lib/samba/usershares contains files dated from January 2015 through
September 13, 2022

-rw-r--r-- 1 root sambashare 104 Jan 17  2015 backups



On Thu, Sep 15, 2022 at 10:16 AM Jason Wittlin-Cohen <
jwittlinco...@gmail.com> wrote:

>
>
> On Thu, Sep 15, 2022 at 9:58 AM Jason Wittlin-Cohen <
> jwittlinco...@gmail.com> wrote:
>
>> -- Forwarded message --
>>
>>> From: Michael Tokarev 
>>> To: Jason Cohen , 1019545-d...@bugs.debian.org
>>> Cc:
>>> Bcc:
>>> Date: Thu, 15 Sep 2022 13:17:28 +0300
>>> Subject: Re: Bug#1019545: samba: Permission/ownership issue in
>>> /var/lib/samba results in repeated panic or segfault after upgrading from
>>> Buster to Bullseye
>>> 11.09.2022 19:28, Jason Cohen wrote:
>>> > Package: samba
>>> > Version: 2:4.16.4+dfsg-2~bpo11+1
>>> > Severity: normal
>>> >
>>> > Dear Maintainer,
>>> >
>>> > *** Reporter, please consider answering these questions, where
>>> appropriate ***
>>> >
>>> > * What led up to the situation?
>>> >
>>> > I upgraded my system from Buster to Bullseye.  As part of that
>>> process, Samba was upgraded to 4.16.4. After the upgrade, I began receiving
>>> emails reporting a Panic or segfault in Samba everytime a user tried to
>>> access a file share after going idle.
>>>
>>> Just to clarify: 4.16[.4] is not part of bullseye, but is available in
>>> bullseye-backports.
>>> It's okay, it is just that from your statement one might conclude that
>>> upgrade to bullseye
>>> caused samba to be updated to 4.16.4, - no, it is not, you explicitly
>>> installed samba from
>>> backports.
>>>
>>> Also note that across-release upgrades has never been supported in
>>> debian. You can upgrade
>>> from buster version to bullseye version and only after that you can
>>> upgrade to bookworm
>>> version (which is what the bullseye-backport essentially is), but not
>>> from buster directly
>>> to bookworm.
>>>
>>
>> Yes, that's correct. When I upgraded from Buster to Bullseye, the version
>> in Bullseye-sec was installed (2:4.13.13+dfsg-1~deb11u5).  I manually
>> installed the bullseye-backports version to see if it would rectify the
>> issue, but it didn't.
>>
>> Start-Date: 2022-08-31  22:50:37
>> Commandline: apt install -t bullseye-backports samba
>> Requested-By: jason (1000)
>> Upgrade: python3-samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
>> 2:4.16.4+dfsg-2~bpo11+1), libldb2:amd64 (2:2.2.3-2~deb11u2,
>> 2:2.5.2+samba4.16.4-2~bpo11+1), libtevent0:amd64 (0.10.2-1,
>> 0.11.0-1~bpo11+1), samba-vfs-modules:amd64 (2:4.13.13+dfsg-1~deb11u5,
>> 2:4.16.4+dfsg-2~bpo11+1), samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
>> 2:4.16.4+dfsg-2~bpo11+1), libwbclient0:amd64 (2:4.13.13+dfsg-1~deb11u5,
>> 2:4.16.4+dfsg-2~bpo11+1), libsmbclient:amd64 (2:4.13.13+dfsg-1~deb11u5,
>> 2:4.16.4+dfsg-2~bpo11+1), samba-dsdb-modules:amd64
>> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common-bin:amd64
>> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), python3-talloc:amd64
>> (2.3.1-2+b1, 2.3.3-4~bpo11+1), libtdb1:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1),
>> python3-ldb:amd64 (2:2.2.3-2~deb11u2, 2:2.5.2+samba4.16.4-2~bpo11+1),
>> python3-tdb:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1), samba-libs:amd64
>> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common:amd64
>> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), ctdb:amd64
>> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), libtalloc2:amd64
>> (2.3.1-2+b1, 2.3.3-4~bpo11+1)
>> End-Date: 2022-08-31  22:52:40
>>
>>
>>>
>>> Tho, I don't think this matters here, - it is just a side note.
>>>
>>> > * What exactly did you do (or not do) that was effective (or
>>> >   ineffective)?
>>> >
>>> > After enabling debug logging, I saw that the panic/segfault was
>>> preceeded by the following error:L "stat of /var/lib/samba/usershare/data
>>> failed. Permission denied."
>>> >
>>> > In order to fix the issue, I changed the file ownership of all files
>>> in the above directory to root:sambashare and added my user (jason) to the
>>> samb

Bug#1019545: closed by Michael Tokarev (Re: Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bull

[Jason Wittlin-Cohen]

On Thu, Sep 15, 2022 at 9:58 AM Jason Wittlin-Cohen 
wrote:

> -- Forwarded message --
>
>> From: Michael Tokarev 
>> To: Jason Cohen , 1019545-d...@bugs.debian.org
>> Cc:
>> Bcc:
>> Date: Thu, 15 Sep 2022 13:17:28 +0300
>> Subject: Re: Bug#1019545: samba: Permission/ownership issue in
>> /var/lib/samba results in repeated panic or segfault after upgrading from
>> Buster to Bullseye
>> 11.09.2022 19:28, Jason Cohen wrote:
>> > Package: samba
>> > Version: 2:4.16.4+dfsg-2~bpo11+1
>> > Severity: normal
>> >
>> > Dear Maintainer,
>> >
>> > *** Reporter, please consider answering these questions, where
>> appropriate ***
>> >
>> > * What led up to the situation?
>> >
>> > I upgraded my system from Buster to Bullseye.  As part of that process,
>> Samba was upgraded to 4.16.4. After the upgrade, I began receiving emails
>> reporting a Panic or segfault in Samba everytime a user tried to access a
>> file share after going idle.
>>
>> Just to clarify: 4.16[.4] is not part of bullseye, but is available in
>> bullseye-backports.
>> It's okay, it is just that from your statement one might conclude that
>> upgrade to bullseye
>> caused samba to be updated to 4.16.4, - no, it is not, you explicitly
>> installed samba from
>> backports.
>>
>> Also note that across-release upgrades has never been supported in
>> debian. You can upgrade
>> from buster version to bullseye version and only after that you can
>> upgrade to bookworm
>> version (which is what the bullseye-backport essentially is), but not
>> from buster directly
>> to bookworm.
>>
>
> Yes, that's correct. When I upgraded from Buster to Bullseye, the version
> in Bullseye-sec was installed (2:4.13.13+dfsg-1~deb11u5).  I manually
> installed the bullseye-backports version to see if it would rectify the
> issue, but it didn't.
>
> Start-Date: 2022-08-31  22:50:37
> Commandline: apt install -t bullseye-backports samba
> Requested-By: jason (1000)
> Upgrade: python3-samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
> 2:4.16.4+dfsg-2~bpo11+1), libldb2:amd64 (2:2.2.3-2~deb11u2,
> 2:2.5.2+samba4.16.4-2~bpo11+1), libtevent0:amd64 (0.10.2-1,
> 0.11.0-1~bpo11+1), samba-vfs-modules:amd64 (2:4.13.13+dfsg-1~deb11u5,
> 2:4.16.4+dfsg-2~bpo11+1), samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
> 2:4.16.4+dfsg-2~bpo11+1), libwbclient0:amd64 (2:4.13.13+dfsg-1~deb11u5,
> 2:4.16.4+dfsg-2~bpo11+1), libsmbclient:amd64 (2:4.13.13+dfsg-1~deb11u5,
> 2:4.16.4+dfsg-2~bpo11+1), samba-dsdb-modules:amd64
> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common-bin:amd64
> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), python3-talloc:amd64
> (2.3.1-2+b1, 2.3.3-4~bpo11+1), libtdb1:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1),
> python3-ldb:amd64 (2:2.2.3-2~deb11u2, 2:2.5.2+samba4.16.4-2~bpo11+1),
> python3-tdb:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1), samba-libs:amd64
> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common:amd64
> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), ctdb:amd64
> (2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), libtalloc2:amd64
> (2.3.1-2+b1, 2.3.3-4~bpo11+1)
> End-Date: 2022-08-31  22:52:40
>
>
>>
>> Tho, I don't think this matters here, - it is just a side note.
>>
>> > * What exactly did you do (or not do) that was effective (or
>> >   ineffective)?
>> >
>> > After enabling debug logging, I saw that the panic/segfault was
>> preceeded by the following error:L "stat of /var/lib/samba/usershare/data
>> failed. Permission denied."
>> >
>> > In order to fix the issue, I changed the file ownership of all files in
>> the above directory to root:sambashare and added my user (jason) to the
>> sambashare group. After making these changes, the errors went away. I am
>> reporting this as it's a change in behavior. I did not experience these
>> segfaults in Buster.  It appears that the expected ownership of this
>> directory changed, causing my issue.
>>
>> That's lovely. It is definitely a bug that samba *crashes* when usershare
>> dir is not accessible.
>>
>> But I don't know if this is actually a bug in the behavior change as you
>> describe. It seems to
>> be, but the thing is that usershare permission model always worked like
>> this. At least as far
>> as I know.
>>
>> In 4.16 I changed the way how usershare directory is handled during
>> install indeed, with this
>> commit:
>>
>>
>> https://salsa.debian.org/samba-team/samba/-/commit/5f67d36ff617fa7e960

Bug#1019545: closed by Michael Tokarev (Re: Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bull

[Jason Wittlin-Cohen]

-- Forwarded message --

> From: Michael Tokarev 
> To: Jason Cohen , 1019545-d...@bugs.debian.org
> Cc:
> Bcc:
> Date: Thu, 15 Sep 2022 13:17:28 +0300
> Subject: Re: Bug#1019545: samba: Permission/ownership issue in
> /var/lib/samba results in repeated panic or segfault after upgrading from
> Buster to Bullseye
> 11.09.2022 19:28, Jason Cohen wrote:
> > Package: samba
> > Version: 2:4.16.4+dfsg-2~bpo11+1
> > Severity: normal
> >
> > Dear Maintainer,
> >
> > *** Reporter, please consider answering these questions, where
> appropriate ***
> >
> > * What led up to the situation?
> >
> > I upgraded my system from Buster to Bullseye.  As part of that process,
> Samba was upgraded to 4.16.4. After the upgrade, I began receiving emails
> reporting a Panic or segfault in Samba everytime a user tried to access a
> file share after going idle.
>
> Just to clarify: 4.16[.4] is not part of bullseye, but is available in
> bullseye-backports.
> It's okay, it is just that from your statement one might conclude that
> upgrade to bullseye
> caused samba to be updated to 4.16.4, - no, it is not, you explicitly
> installed samba from
> backports.
>
> Also note that across-release upgrades has never been supported in debian.
> You can upgrade
> from buster version to bullseye version and only after that you can
> upgrade to bookworm
> version (which is what the bullseye-backport essentially is), but not from
> buster directly
> to bookworm.
>

Yes, that's correct. When I upgraded from Buster to Bullseye, the version
in Bullseye-sec was installed (2:4.13.13+dfsg-1~deb11u5).  I manually
installed the bullseye-backports version to see if it would rectify the
issue, but it didn't.

Start-Date: 2022-08-31  22:50:37
Commandline: apt install -t bullseye-backports samba
Requested-By: jason (1000)
Upgrade: python3-samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), libldb2:amd64 (2:2.2.3-2~deb11u2,
2:2.5.2+samba4.16.4-2~bpo11+1), libtevent0:amd64 (0.10.2-1,
0.11.0-1~bpo11+1), samba-vfs-modules:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), samba:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), libwbclient0:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), libsmbclient:amd64 (2:4.13.13+dfsg-1~deb11u5,
2:4.16.4+dfsg-2~bpo11+1), samba-dsdb-modules:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common-bin:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), python3-talloc:amd64
(2.3.1-2+b1, 2.3.3-4~bpo11+1), libtdb1:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1),
python3-ldb:amd64 (2:2.2.3-2~deb11u2, 2:2.5.2+samba4.16.4-2~bpo11+1),
python3-tdb:amd64 (1.4.3-1+b1, 1.4.6-3~bpo11+1), samba-libs:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), samba-common:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), ctdb:amd64
(2:4.13.13+dfsg-1~deb11u5, 2:4.16.4+dfsg-2~bpo11+1), libtalloc2:amd64
(2.3.1-2+b1, 2.3.3-4~bpo11+1)
End-Date: 2022-08-31  22:52:40


>
> Tho, I don't think this matters here, - it is just a side note.
>
> > * What exactly did you do (or not do) that was effective (or
> >   ineffective)?
> >
> > After enabling debug logging, I saw that the panic/segfault was
> preceeded by the following error:L "stat of /var/lib/samba/usershare/data
> failed. Permission denied."
> >
> > In order to fix the issue, I changed the file ownership of all files in
> the above directory to root:sambashare and added my user (jason) to the
> sambashare group. After making these changes, the errors went away. I am
> reporting this as it's a change in behavior. I did not experience these
> segfaults in Buster.  It appears that the expected ownership of this
> directory changed, causing my issue.
>
> That's lovely. It is definitely a bug that samba *crashes* when usershare
> dir is not accessible.
>
> But I don't know if this is actually a bug in the behavior change as you
> describe. It seems to
> be, but the thing is that usershare permission model always worked like
> this. At least as far
> as I know.
>
> In 4.16 I changed the way how usershare directory is handled during
> install indeed, with this
> commit:
>
>
> https://salsa.debian.org/samba-team/samba/-/commit/5f67d36ff617fa7e9609ff2e3baa6ed1a533f5a5
>
> This means I only create this dir and specify its permissions only at
> first install, not every
> install.  But again, this is not really relevant.
>
> Now, I don't know which permissions/ownership you files *had* before you
> changed them.  Please
> note how this directory is being created:
>
> install -d -m 1770 -g sambashare /var/lib/samba/usershares
>
> The "1" "sticky" bit tells the kernel to use the sa

Bug#1019544: Additional Information

[Jason Wittlin-Cohen]

As there were several changes in 5.10.140 to the kernel I/O code which
could be the cause of my issue, I downloaded the vanilla source code for
the 5.10.139 kernel and built it using my Debian kernel config from /boot.
I installed the resulting kernel and kernel headers and DKMS built the
required ZFS modules. Upon rebooting, all my ZFS pools are working as
expected.

In particular, the main pool that consistently showed six missing drives
(A1-A6) under 5.10.140 is now showing all drives as online, just as it does
with 5.10.136-1.  In total, this system has 48 3.5" 7200 RPM SATA drives,
two 1.92TB Samsung enterprise SATA SSDs, and three NVMe SSDs.  The impacted
drives are 16TB 3.5" drives, which are in two 4U DS4246 JBOD enclosures,
and attached to a Dell R730xd server via an LSI 9207-8e HBA running P20
firmware in IT mode.  I'm running ZFS 2.1.5 from bullseye-backports.  Note
that SMART data for the impacted drives is normal with no bad sectors.  The
only change I made was booting into a different kernel.  Otherwise, it's
running all the updates from the 11.5 point release.

I will try to bisect 5.10.140 tomorrow to determine more precisely which
commit(s) are causing my issue.

NAME STATE READ
WRITE CKSUM
data ONLINE   0
0 0
  raidz2-0   ONLINE   0
0 0
A1   ONLINE   0
0 0
A2   ONLINE   0
0 0
A3   ONLINE   0
0 0
A4   ONLINE   0
0 0
A5   ONLINE   0
0 0
A6   ONLINE   0
0 0
A7   ONLINE   0
0 0
A8   ONLINE   0
0 0
A9   ONLINE   0
0 0
A10  ONLINE   0
0 0
A11  ONLINE   0
0 0
A12  ONLINE   0
0 0
special
  mirror-1   ONLINE   0
0 0
nvme-HP_SSD_EX920_1TB_HBSE48481800144-part1  ONLINE   0
0 0
nvme-HP_SSD_EX920_1TB_HBSE48481800847-part1  ONLINE   0
0 0
logs
  mirror-2   ONLINE   0
0 0
nvme-HP_SSD_EX920_1TB_HBSE48481800144-part2  ONLINE   0
0 0

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

I downgraded the nfs-common package which required the downgrade of the 
libevent packages and am using the 4.19.X kernel.
I see the issue running the initial test, but then the issue is gone when 
running the test a subsequent time.

libevent-2.1-6:amd64  2.1.8-stable-4
amd64Asynchronous event notification library
libevent-core-2.1-6:amd64 2.1.8-stable-4
amd64Asynchronous event notification library (core)
libevent-pthreads-2.1-6:amd64 2.1.8-stable-4amd64   
 Asynchronous event notification library (pthreads)
linux-image-4.19.0-21-amd644.19.249-2  
amd64Linux 4.19 for 64-bit PCs (signed)
nfs-common  1:1.3.4-2.5+deb10u1
amd64NFS support files common to client and server

What other packages do I need to downgrade in order to get Debian 11.4 to 
behave like Debian 10.8?
What additional questions can I answer so that we can move forward?

> -Original Message-
> From: Jason Breitman
> Sent: Tuesday, September 6, 2022 5:18 PM
> To: Ben Hutchings ; 1017...@bugs.debian.org
> Subject: RE: Bug#1017720: nfs-common: No such file or directory
> 
> I also see the failure with the kernels below, but the 4.19.X kernel resolves
> the issue without dropping caches.
> linux-image-4.19.0-14-amd64   4.19.171-2 amd64
> Linux 4.19 for
> 64-bit PCs (signed)
> linux-image-4.19.0-21-amd64   4.19.249-2 amd64
> Linux 4.19 for
> 64-bit PCs (signed)
> 
> I see the issue running the initial test, but then the issue is gone when
> running the test a subsequent time.
> I ran several tests to verify the behavior differences between the 4.19.X and
> 5.X kernels.
> 
> -- Test
> ls -l /mnt/dir/someOtherDir/* | grep '?'
> 
> -- Error message - the error message is showing files that have been erased
> via rsync --delete
> ls: cannot access 'filename': No such file or directory
> -? ? ???? filename
> 
> > -Original Message-
> > From: Jason Breitman
> > Sent: Friday, September 2, 2022 5:17 PM
> > To: Ben Hutchings ; 1017...@bugs.debian.org
> > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> >
> > I have tested with the following kernels and see this issue in each case.
> >
> > linux-image-5.10.0-16-amd64  5.10.127-1 
> >  amd64
> Linux
> > 5.10 for 64-bit PCs (signed)
> > linux-image-5.15.0-0.bpo.3-amd64 5.15.15-2~bpo11+1  amd64
> > Linux 5.15 for 64-bit PCs (signed)
> > linux-image-5.18.0-0.deb11.3-amd64 5.18.14-1~bpo11+1  amd64
> > Linux 5.18 for 64-bit PCs (signed)
> >
> > An interesting note is that when using the 5.18 kernel, I had to run echo 3 
> > >
> > /proc/sys/vm/drop_caches to resolve the issue.
> > echo 2 > /proc/sys/vm/drop_caches did not work as it did on the 5.10 and
> > 5.15 kernels.
> >
> > > -Original Message-
> > > From: Jason Breitman
> > > Sent: Friday, August 26, 2022 3:36 PM
> > > To: 'Ben Hutchings' ; '1017...@bugs.debian.org'
> > > <1017...@bugs.debian.org>
> > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > >
> > > I was able to identify another workaround today which may help you to
> > > identify the issue.
> > > The workaround is to touch the directory where the troubled files live on
> > the
> > > file server.
> > > I believe this tells us that updating the modify time attribute is used by
> the
> > > cache.
> > > It should be noted that access time updates are disabled on the file
> server.
> > >
> > > I also wanted to restate that we use rsync to push out these application
> > > updates and also use rsync to sync data files.
> > > Our rsync options preserve timestamps, so it is possible that the new 
> > > files
> > > have an older timestamp than "now".
> > > It is not the case that the new files have an older timestamp than the
> prior
> > > version that is stuck in the cache.
> > >
> > > The rsync process that I describe has not changed and has been in use for
> > > many years.
> > >
> > > > -Original Message-
> > > > From: Jason Breitman
> > > > Sent: Thursday, August 25, 2022 11:54 AM
> > > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > > Subject: RE: Bug#1017720: nfs-common: No such fi

Bug#1019545: samba: Permission/ownership issue in /var/lib/samba results in repeated panic or segfault after upgrading from Buster to Bullseye

[Jason Cohen]

Package: samba
Version: 2:4.16.4+dfsg-2~bpo11+1
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I upgraded my system from Buster to Bullseye.  As part of that process, Samba 
was upgraded to 4.16.4. After the upgrade, I began receiving emails reporting a 
Panic or segfault in Samba everytime a user tried to access a file share after 
going idle.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?

After enabling debug logging, I saw that the panic/segfault was preceeded by 
the following error:L "stat of /var/lib/samba/usershare/data failed. Permission 
denied."  

In order to fix the issue, I changed the file ownership of all files in the 
above directory to root:sambashare and added my user (jason) to the sambashare 
group. After making these changes, the errors went away. I am reporting this as 
it's a change in behavior. I did not experience these segfaults in Buster.  It 
appears that the expected ownership of this directory changed, causing my issue.

   * What was the outcome of this action?

Changing the ownership to root:sambashare and adding my user to the sambashare 
group resolved the segfaults. 

   * What outcome did you expect instead?


-- Package-specific info:
* /etc/samba/smb.conf present, and attached
* /var/lib/samba/dhcp.conf present, and attached

-- System Information:
Debian Release: 11.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-17-amd64 (SMP w/32 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages samba depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libbsd0  0.11.3-1
ii  libc62.31-13+deb11u4
ii  libcups2 2.3.3op2-3+deb11u2
ii  libgnutls30  3.7.1-5+deb11u2
ii  libldap-2.4-22.4.57+dfsg-3+deb11u1
ii  libldb2  2:2.5.2+samba4.16.4-2~bpo11+1
ii  libpam-modules   1.4.0-9+deb11u1
ii  libpam-runtime   1.4.0-9+deb11u1
ii  libpopt0 1.18-2
ii  libtalloc2   2.3.3-4~bpo11+1
ii  libtasn1-6   4.16.0-2
ii  libtdb1  1.4.6-3~bpo11+1
ii  libtevent0   0.11.0-1~bpo11+1
ii  lsb-base 11.1.0
ii  procps   2:3.3.17-5
ii  python3  3.9.2-3
ii  python3-dnspython2.0.0-1
ii  python3-samba2:4.16.4+dfsg-2~bpo11+1
ii  samba-common 2:4.16.4+dfsg-2~bpo11+1
ii  samba-common-bin 2:4.16.4+dfsg-2~bpo11+1
ii  samba-libs   2:4.16.4+dfsg-2~bpo11+1
ii  tdb-tools1.4.3-1+b1

Versions of packages samba recommends:
ii  attr1:2.4.48-6
ii  logrotate   3.18.0-2+deb11u1
ii  python3-markdown3.3.4-1
ii  samba-dsdb-modules  2:4.16.4+dfsg-2~bpo11+1
ii  samba-vfs-modules   2:4.16.4+dfsg-2~bpo11+1

Versions of packages samba suggests:
ii  bind9 1:9.16.27-1~deb11u1
ii  bind9-utils [bind9utils]  1:9.16.27-1~deb11u1
ii  bind9utils1:9.16.27-1~deb11u1
ii  ctdb  2:4.16.4+dfsg-2~bpo11+1
pn  ldb-tools 
ii  ntp   1:4.2.8p15+dfsg-1
pn  smbldap-tools 
pn  ufw   
pn  winbind   

-- Configuration Files:
/etc/logrotate.d/samba changed:
/var/log/samba/log.smbd {
weekly
missingok
rotate 7
postrotate
[ ! -x /usr/bin/smbcontrol ] || [ ! -f /run/samba/smbd.pid ] || 
/usr/bin/smbcontrol smbd reload-config
endscript
#compress
delaycompress
notifempty
}
/var/log/samba/log.nmbd {
weekly
missingok
rotate 7
postrotate
[ ! -x /usr/bin/smbcontrol ] || [ ! -f /run/samba/nmbd.pid ] || 
/usr/bin/smbcontrol nmbd reload-config
endscript
#compress
delaycompress
notifempty
}
/var/log/samba/log.samba {
weekly
missingok
rotate 7
postrotate
if [ -d /run/systemd/system ] && command systemctl >/dev/null 
2>&1 && systemctl is-active --quiet samba-ad-dc; then
systemctl kill --kill-who all --signal=SIGHUP 
samba-ad-dc
elif [ -f /run/samba/samba.pid ]; then
# This only sends to main pid, See #803924
kill -HUP `cat /run/samba/samba.pid`
fi
endscript
#compress
delaycompress
notifempty
}


-- debconf information:
  samba/run_mode: daemons
  samba-common/title:
#
# Sample co

Bug#1019544: linux-image-5.10.0-18-amd64: Kernel regression causes multiple data errors and pool suspension of ZFS pools

[Jason Cohen]

Package: src:linux
Version: 5.10.140-1
Severity: important
Tags: upstream

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

I installed the 11.5 point upgrade which included upgrading the kernel from 
5.10.136-1 to 5.10.140-1. After booting the new kernel, I immediately received 
multiple reports of data errors on multiple ZFS pools.  My main pool (12 drive 
raidz2) shows 6 drives as faulted, resulted in the pool being suspended (data 
inaccessible).  Uncorrectable data errors were shown on thousands of files. The 
issue persisted despite multiple reboots and a cool boot where I disconnected 
the power cables, drained power by holding the power button for 30 seconds, and 
reconnected power.

Note that smartmontools showed no errors on any of the impacted disks.

Syslog showed the following errors:

Sep 11 09:40:02 storage-server kernel: [  595.925139] WARNING: Pool 'data' has 
encountered an uncorrectable I/O failure and has been suspended.
Sep 11 09:40:02 storage-server kernel: [  595.925139]
Sep 11 09:40:02 storage-server zed: eid=203 class=io_failure pool='data'
Sep 11 09:40:02 storage-server zed: eid=202 class=data pool='data' priority=0 
err=6 flags=0x8881 bookmark=2564:131200:0:2448
Sep 11 09:40:11 storage-server kernel: [  605.153524] INFO: task txg_sync:36217 
blocked for more than 241 seconds.
Sep 11 09:40:11 storage-server kernel: [  605.153529]   Tainted: P  
 OE 5.10.0-18-amd64 #1 Debian 5.10.140-1
Sep 11 09:40:11 storage-server kernel: [  605.153530] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 11 09:40:11 storage-server kernel: [  605.153532] task:txg_sync
state:D stack:0 pid:36217 ppid: 2 flags:0x4000
Sep 11 09:40:11 storage-server kernel: [  605.153536] Call Trace:
Sep 11 09:40:11 storage-server kernel: [  605.153546]  __schedule+0x282/0x880
Sep 11 09:40:11 storage-server kernel: [  605.153549]  schedule+0x46/0xb0
Sep 11 09:40:11 storage-server kernel: [  605.153552]  
schedule_timeout+0x8b/0x150
Sep 11 09:40:11 storage-server kernel: [  605.153555]  ? 
__next_timer_interrupt+0x110/0x110
Sep 11 09:40:11 storage-server kernel: [  605.153558]  
io_schedule_timeout+0x4c/0x80
Sep 11 09:40:11 storage-server kernel: [  605.153570]  
__cv_timedwait_common+0x12f/0x170 [spl]
Sep 11 09:40:11 storage-server kernel: [  605.153576]  ? 
add_wait_queue_exclusive+0x70/0x70
Sep 11 09:40:11 storage-server kernel: [  605.153579]  
__cv_timedwait_io+0x15/0x20 [spl]
Sep 11 09:40:11 storage-server kernel: [  605.153666]  zio_wait+0x129/0x2b0 
[zfs]
Sep 11 09:40:11 storage-server kernel: [  605.153723]  
dsl_pool_sync+0x467/0x520 [zfs]
Sep 11 09:40:11 storage-server kernel: [  605.153766]  spa_sync+0x542/0xfa0 
[zfs]
Sep 11 09:40:11 storage-server kernel: [  605.153770]  ? mutex_lock+0xe/0x30
Sep 11 09:40:11 storage-server kernel: [  605.153813]  ? 
spa_txg_history_init_io+0x105/0x110 [zfs]
Sep 11 09:40:11 storage-server kernel: [  605.153855]  
txg_sync_thread+0x2e0/0x4a0 [zfs]
Sep 11 09:40:11 storage-server kernel: [  605.153899]  ? txg_fini+0x260/0x260 
[zfs]
Sep 11 09:40:11 storage-server kernel: [  605.153905]  
thread_generic_wrapper+0x6f/0x80 [spl]
Sep 11 09:40:11 storage-server kernel: [  605.153909]  ? 
__thread_exit+0x20/0x20 [spl]
Sep 11 09:40:11 storage-server kernel: [  605.153913]  kthread+0x11b/0x140
Sep 11 09:40:11 storage-server kernel: [  605.153915]  ? 
__kthread_bind_mask+0x60/0x60
Sep 11 09:40:11 storage-server kernel: [  605.153919]  ret_from_fork+0x22/0x30
Sep 11 09:40:11 storage-server kernel: [  605.154602] INFO: task 
chia_harvester:94763 blocked for more than 241 seconds.
Sep 11 09:40:11 storage-server kernel: [  605.154604]   Tainted: P  
 OE 5.10.0-18-amd64 #1 Debian 5.10.140-1
Sep 11 09:40:11 storage-server kernel: [  605.154605] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Sep 11 09:40:11 storage-server kernel: [  605.154606] task:chia_harvester  
state:D stack:0 pid:94763 ppid: 93650 flags:0x
Sep 11 09:40:11 storage-server kernel: [  605.154609] Call Trace:
Sep 11 09:40:11 storage-server kernel: [  605.154613]  __schedule+0x282/0x880
Sep 11 09:40:11 storage-server kernel: [  605.154616]  schedule+0x46/0xb0
Sep 11 09:40:11 storage-server kernel: [  605.154618]  
schedule_timeout+0x8b/0x150
Sep 11 09:40:11 storage-server kernel: [  605.154620]  ? 
__next_timer_interrupt+0x110/0x110
Sep 11 09:40:11 storage-server kernel: [  605.154622]  
io_schedule_timeout+0x4c/0x80
Sep 11 09:40:11 storage-server kernel: [  605.154626]  
__cv_timedwait_common+0x12f/0x170 [spl]
Sep 11 09:40:11 storage-server kernel: [  605.154629]  ? 
add_wait_queue_exclusive+0x70/0x70
Sep 11 09:40:11 storage-server kernel: [  605.154633]  
__cv_timedwait_io+0x15/0x20 [spl]
Sep 11 09:40:11 storage-server kernel: [  605.154681]  zio_wait+0x129/0x2b0 
[zfs]
Sep 11 09:40:11 storage-server kernel: [  605.154718] 

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

I also see the failure with the kernels below, but the 4.19.X kernel resolves 
the issue without dropping caches.
linux-image-4.19.0-14-amd64   4.19.171-2 amd64
Linux 4.19 for 64-bit PCs (signed)
linux-image-4.19.0-21-amd64   4.19.249-2 amd64
Linux 4.19 for 64-bit PCs (signed)

I see the issue running the initial test, but then the issue is gone when 
running the test a subsequent time.
I ran several tests to verify the behavior differences between the 4.19.X and 
5.X kernels.

-- Test
ls -l /mnt/dir/someOtherDir/* | grep '?'

-- Error message - the error message is showing files that have been erased via 
rsync --delete
ls: cannot access 'filename': No such file or directory
-? ? ???? filename

> -Original Message-
> From: Jason Breitman
> Sent: Friday, September 2, 2022 5:17 PM
> To: Ben Hutchings ; 1017...@bugs.debian.org
> Subject: RE: Bug#1017720: nfs-common: No such file or directory
> 
> I have tested with the following kernels and see this issue in each case.
> 
> linux-image-5.10.0-16-amd64  5.10.127-1   
>amd64Linux
> 5.10 for 64-bit PCs (signed)
> linux-image-5.15.0-0.bpo.3-amd64 5.15.15-2~bpo11+1  amd64
> Linux 5.15 for 64-bit PCs (signed)
> linux-image-5.18.0-0.deb11.3-amd64 5.18.14-1~bpo11+1  amd64
> Linux 5.18 for 64-bit PCs (signed)
> 
> An interesting note is that when using the 5.18 kernel, I had to run echo 3 >
> /proc/sys/vm/drop_caches to resolve the issue.
> echo 2 > /proc/sys/vm/drop_caches did not work as it did on the 5.10 and
> 5.15 kernels.
> 
> > -Original Message-
> > From: Jason Breitman
> > Sent: Friday, August 26, 2022 3:36 PM
> > To: 'Ben Hutchings' ; '1017...@bugs.debian.org'
> > <1017...@bugs.debian.org>
> > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> >
> > I was able to identify another workaround today which may help you to
> > identify the issue.
> > The workaround is to touch the directory where the troubled files live on
> the
> > file server.
> > I believe this tells us that updating the modify time attribute is used by 
> > the
> > cache.
> > It should be noted that access time updates are disabled on the file server.
> >
> > I also wanted to restate that we use rsync to push out these application
> > updates and also use rsync to sync data files.
> > Our rsync options preserve timestamps, so it is possible that the new files
> > have an older timestamp than "now".
> > It is not the case that the new files have an older timestamp than the prior
> > version that is stuck in the cache.
> >
> > The rsync process that I describe has not changed and has been in use for
> > many years.
> >
> > > -Original Message-
> > > From: Jason Breitman
> > > Sent: Thursday, August 25, 2022 11:54 AM
> > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > >
> > > I have the same issue after adding actimeo=30 to /etc/fstab, rebooting
> and
> > > testing.
> > > I also confirmed that those settings applied via /proc/mounts which
> shows
> > > the below snippet for each mountpoint.
> > > nfs4
> > >
> >
> rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,acregmin=30,a
> > >
> >
> cregmax=30,acdirmax=30,hard,noresvport,proto=tcp,timeo=600,retrans=2,s
> > >
> >
> ec=krb5,clientaddr=X.X.X.X,lookupcache=pos,local_lock=none,addr=Y.Y.Y.Y 0
> > > 0
> > >
> > > > -Original Message-
> > > > From: Jason Breitman
> > > > Sent: Tuesday, August 23, 2022 2:42 PM
> > > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > > >
> > > > What additional information can I provide for us to move forward with
> > this
> > > > process?
> > > >
> > > > To summarize and include further details, rsync is used to sync
> > applications
> > > to
> > > > a file server which behaves like a repository.
> > > > We do preserve timestamps from the build server and also use --
> delete.
> > > We
> > > > do not run the applications from the file server.  All servers use NTP.
> > > >
> > > > The application has a sub-directory that contain files with version
> > numbers.
> > > > These are librari

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

I have tested with the following kernels and see this issue in each case.

linux-image-5.10.0-16-amd64  5.10.127-1 
 amd64Linux 5.10 for 64-bit PCs (signed)
linux-image-5.15.0-0.bpo.3-amd64 5.15.15-2~bpo11+1  amd64   
 Linux 5.15 for 64-bit PCs (signed)
linux-image-5.18.0-0.deb11.3-amd64 5.18.14-1~bpo11+1  amd64
Linux 5.18 for 64-bit PCs (signed)

An interesting note is that when using the 5.18 kernel, I had to run echo 3 > 
/proc/sys/vm/drop_caches to resolve the issue.
echo 2 > /proc/sys/vm/drop_caches did not work as it did on the 5.10 and 5.15 
kernels.

> -Original Message-
> From: Jason Breitman
> Sent: Friday, August 26, 2022 3:36 PM
> To: 'Ben Hutchings' ; '1017...@bugs.debian.org'
> <1017...@bugs.debian.org>
> Subject: RE: Bug#1017720: nfs-common: No such file or directory
> 
> I was able to identify another workaround today which may help you to
> identify the issue.
> The workaround is to touch the directory where the troubled files live on the
> file server.
> I believe this tells us that updating the modify time attribute is used by the
> cache.
> It should be noted that access time updates are disabled on the file server.
> 
> I also wanted to restate that we use rsync to push out these application
> updates and also use rsync to sync data files.
> Our rsync options preserve timestamps, so it is possible that the new files
> have an older timestamp than "now".
> It is not the case that the new files have an older timestamp than the prior
> version that is stuck in the cache.
> 
> The rsync process that I describe has not changed and has been in use for
> many years.
> 
> > -Original Message-
> > From: Jason Breitman
> > Sent: Thursday, August 25, 2022 11:54 AM
> > To: Ben Hutchings ; 1017...@bugs.debian.org
> > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> >
> > I have the same issue after adding actimeo=30 to /etc/fstab, rebooting and
> > testing.
> > I also confirmed that those settings applied via /proc/mounts which shows
> > the below snippet for each mountpoint.
> > nfs4
> >
> rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,acregmin=30,a
> >
> cregmax=30,acdirmax=30,hard,noresvport,proto=tcp,timeo=600,retrans=2,s
> >
> ec=krb5,clientaddr=X.X.X.X,lookupcache=pos,local_lock=none,addr=Y.Y.Y.Y 0
> > 0
> >
> > > -Original Message-
> > > From: Jason Breitman
> > > Sent: Tuesday, August 23, 2022 2:42 PM
> > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > >
> > > What additional information can I provide for us to move forward with
> this
> > > process?
> > >
> > > To summarize and include further details, rsync is used to sync
> applications
> > to
> > > a file server which behaves like a repository.
> > > We do preserve timestamps from the build server and also use --delete.
> > We
> > > do not run the applications from the file server.  All servers use NTP.
> > >
> > > The application has a sub-directory that contain files with version
> numbers.
> > > These are libraries.
> > > When a new build is complete, a developer pushes their updates via
> rsync
> > to
> > > the file server / repository.
> > >
> > > I believe that the dentry cache thinks the "old" files exist and 
> > > generates a
> > No
> > > such file or directory error showing question marks for that files
> attributes.
> > > Dropping the dentry cache via echo 2 > /proc/sys/vm/drop_caches
> > resolves
> > > the issue.
> > >
> > > This behavior is not observed in Debian 10.8 with that distributions
> > associated
> > > kernel and packages.
> > >
> > > > -Original Message-
> > > > From: Jason Breitman
> > > > Sent: Friday, August 19, 2022 9:52 PM
> > > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > > >
> > > > > -Original Message-
> > > > > From: Ben Hutchings 
> > > > > Sent: Friday, August 19, 2022 7:27 PM
> > > > > To: Jason Breitman ;
> > > > > 1017...@bugs.debian.org
> > > > > Subject: Re: Bug#1017720: nfs-common: No such file or directory
> > > > >
> > > > > Control: tag -1 moreinfo
> > > > >
> > > > >

Bug#1017535: manuskript: Manuskript does not start, python error

[Jason]

Package: manuskript
Version: 0.12.0-1
Followup-For: Bug #1017535

Dear Maintainer,

   * What led up to the situation? 
   Tried starting manuskript after not having started it for months and
   a few system upgrades of unstable.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   All I did was try to start the app and when that didn't work, then I
   updated my system again to see if the issue was corrected with an
   up to date system.

   * What was the outcome of this action?
   The same error happened again.

   * What outcome did you expect instead?
   Was hoping the issue would be resolved with an up to date unstable
   system.


-- System Information:
Debian Release: bookworm/sid
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'unstable')
merged-usr: no
Architecture: amd64 (x86_64)

Kernel: Linux 5.18.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages manuskript depends on:
ii  libqt5svg5  5.15.4-2
ii  python3 3.10.6-1
ii  python3-enchant 3.2.2-1
ii  python3-lxml4.9.1-1+b1
ii  python3-markdown3.4.1-1
ii  python3-pyqt5   5.15.7+dfsg-1
ii  python3-pyqt5.qtwebkit  5.15.7+dfsg-1
ii  zlib1g  1:1.2.11.dfsg-4.1

Versions of packages manuskript recommends:
ii  pandoc  2.17.1.1-1

Versions of packages manuskript suggests:
pn  texlive-latex-recommended  

-- no debconf information

What happens:
$ manuskript
CRITICAL> An unhandled exception has occurred!
Traceback (most recent call last):
  File "/usr/bin/manuskript", line 30, in 
main.run()
  File "/usr/share/manuskript/manuskript/main.py", line 292, in run
app, MW = prepare(arguments)
  File "/usr/share/manuskript/manuskript/main.py", line 171, in prepare
from manuskript.mainWindow import MainWindow
  File "/usr/share/manuskript/manuskript/mainWindow.py", line 23, in 
from manuskript.models.worldModel import worldModel
  File "/usr/share/manuskript/manuskript/models/worldModel.py", line 11, in 

from manuskript.ui import style as S
  File "/usr/share/manuskript/manuskript/ui/style.py", line 36, in 
highlightLight = F.mixColors(highlight, window, .3)
  File "/usr/share/manuskript/manuskript/functions/__init__.py", line 197, in 
mixColors
return QColor(r, g, b) if not fromString else QColor(r, g, b).name()
TypeError: arguments did not match any overloaded call:
  QColor(Qt.GlobalColor): argument 1 has unexpected type 'float'
  QColor(int): argument 1 has unexpected type 'float'
  QColor(QRgba64): argument 1 has unexpected type 'float'
  QColor(Any): too many arguments
  QColor(): too many arguments
  QColor(int, int, int, alpha: int = 255): argument 1 has unexpected type 
'float'
  QColor(str): argument 1 has unexpected type 'float'
  QColor(Union[QColor, Qt.GlobalColor, QGradient]): argument 1 has unexpected 
type 'float'

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

I was able to identify another workaround today which may help you to identify 
the issue.
The workaround is to touch the directory where the troubled files live on the 
file server.
I believe this tells us that updating the modify time attribute is used by the 
cache.
It should be noted that access time updates are disabled on the file server.

I also wanted to restate that we use rsync to push out these application 
updates and also use rsync to sync data files.
Our rsync options preserve timestamps, so it is possible that the new files 
have an older timestamp than "now".
It is not the case that the new files have an older timestamp than the prior 
version that is stuck in the cache.

The rsync process that I describe has not changed and has been in use for many 
years.

> -Original Message-
> From: Jason Breitman
> Sent: Thursday, August 25, 2022 11:54 AM
> To: Ben Hutchings ; 1017...@bugs.debian.org
> Subject: RE: Bug#1017720: nfs-common: No such file or directory
> 
> I have the same issue after adding actimeo=30 to /etc/fstab, rebooting and
> testing.
> I also confirmed that those settings applied via /proc/mounts which shows
> the below snippet for each mountpoint.
> nfs4
> rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,acregmin=30,a
> cregmax=30,acdirmax=30,hard,noresvport,proto=tcp,timeo=600,retrans=2,s
> ec=krb5,clientaddr=X.X.X.X,lookupcache=pos,local_lock=none,addr=Y.Y.Y.Y 0
> 0
> 
> > -Original Message-
> > From: Jason Breitman
> > Sent: Tuesday, August 23, 2022 2:42 PM
> > To: Ben Hutchings ; 1017...@bugs.debian.org
> > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> >
> > What additional information can I provide for us to move forward with this
> > process?
> >
> > To summarize and include further details, rsync is used to sync applications
> to
> > a file server which behaves like a repository.
> > We do preserve timestamps from the build server and also use --delete.
> We
> > do not run the applications from the file server.  All servers use NTP.
> >
> > The application has a sub-directory that contain files with version numbers.
> > These are libraries.
> > When a new build is complete, a developer pushes their updates via rsync
> to
> > the file server / repository.
> >
> > I believe that the dentry cache thinks the "old" files exist and generates a
> No
> > such file or directory error showing question marks for that files 
> > attributes.
> > Dropping the dentry cache via echo 2 > /proc/sys/vm/drop_caches
> resolves
> > the issue.
> >
> > This behavior is not observed in Debian 10.8 with that distributions
> associated
> > kernel and packages.
> >
> > > -Original Message-
> > > From: Jason Breitman
> > > Sent: Friday, August 19, 2022 9:52 PM
> > > To: Ben Hutchings ; 1017...@bugs.debian.org
> > > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> > >
> > > > -Original Message-
> > > > From: Ben Hutchings 
> > > > Sent: Friday, August 19, 2022 7:27 PM
> > > > To: Jason Breitman ;
> > > > 1017...@bugs.debian.org
> > > > Subject: Re: Bug#1017720: nfs-common: No such file or directory
> > > >
> > > > Control: tag -1 moreinfo
> > > >
> > > > On Fri, 2022-08-19 at 13:16 +, Jason Breitman wrote:
> > > > > Package: nfs-common
> > > > > Version: 1:1.3.4-6
> > > > > Severity: important
> > > > >
> > > > > Kernel: 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30)
> x86_64
> > > > > GNU/Linux
> > > > >
> > > > > -- Description
> > > > > After updating and or creating new files on our file server via
> > > > > rsync, we see many files report the error message below from NFSv4
> > > > > clients since upgrading from Debian 10.8 to Debian 11.4.
> > > > > Clearing the dentry cache resolves the issue right away.
> > > > > I am not sure that nfs-common is the package to blame, but listed
> > > > > it based on the bug submission recommendations.
> > > >
> > > > The NFS implementation is mostly in the kernel, so probably this issue
> > > > belongs there.  But the kernel team is responsible for both packages.
> > > >
> > > > [...]
> > > > > -- Error message
> > > > > ls: cannot access 'filename': No such file or directory
> > > > > -? ? ??  

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

I have the same issue after adding actimeo=30 to /etc/fstab, rebooting and 
testing.
I also confirmed that those settings applied via /proc/mounts which shows the 
below snippet for each mountpoint.
nfs4 
rw,relatime,vers=4.1,rsize=131072,wsize=131072,namlen=255,acregmin=30,acregmax=30,acdirmax=30,hard,noresvport,proto=tcp,timeo=600,retrans=2,sec=krb5,clientaddr=X.X.X.X,lookupcache=pos,local_lock=none,addr=Y.Y.Y.Y
 0 0

> -Original Message-
> From: Jason Breitman
> Sent: Tuesday, August 23, 2022 2:42 PM
> To: Ben Hutchings ; 1017...@bugs.debian.org
> Subject: RE: Bug#1017720: nfs-common: No such file or directory
> 
> What additional information can I provide for us to move forward with this
> process?
> 
> To summarize and include further details, rsync is used to sync applications 
> to
> a file server which behaves like a repository.
> We do preserve timestamps from the build server and also use --delete.  We
> do not run the applications from the file server.  All servers use NTP.
> 
> The application has a sub-directory that contain files with version numbers.
> These are libraries.
> When a new build is complete, a developer pushes their updates via rsync to
> the file server / repository.
> 
> I believe that the dentry cache thinks the "old" files exist and generates a 
> No
> such file or directory error showing question marks for that files attributes.
> Dropping the dentry cache via echo 2 > /proc/sys/vm/drop_caches resolves
> the issue.
> 
> This behavior is not observed in Debian 10.8 with that distributions 
> associated
> kernel and packages.
> 
> > -Original Message-
> > From: Jason Breitman
> > Sent: Friday, August 19, 2022 9:52 PM
> > To: Ben Hutchings ; 1017...@bugs.debian.org
> > Subject: RE: Bug#1017720: nfs-common: No such file or directory
> >
> > > -Original Message-
> > > From: Ben Hutchings 
> > > Sent: Friday, August 19, 2022 7:27 PM
> > > To: Jason Breitman ;
> > > 1017...@bugs.debian.org
> > > Subject: Re: Bug#1017720: nfs-common: No such file or directory
> > >
> > > Control: tag -1 moreinfo
> > >
> > > On Fri, 2022-08-19 at 13:16 +, Jason Breitman wrote:
> > > > Package: nfs-common
> > > > Version: 1:1.3.4-6
> > > > Severity: important
> > > >
> > > > Kernel: 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64
> > > > GNU/Linux
> > > >
> > > > -- Description
> > > > After updating and or creating new files on our file server via
> > > > rsync, we see many files report the error message below from NFSv4
> > > > clients since upgrading from Debian 10.8 to Debian 11.4.
> > > > Clearing the dentry cache resolves the issue right away.
> > > > I am not sure that nfs-common is the package to blame, but listed
> > > > it based on the bug submission recommendations.
> > >
> > > The NFS implementation is mostly in the kernel, so probably this issue
> > > belongs there.  But the kernel team is responsible for both packages.
> > >
> > > [...]
> > > > -- Error message
> > > > ls: cannot access 'filename': No such file or directory
> > > > -? ? ???? filename
> > > [...]
> > >
> > > So we know the file's there but can't stat it.  I think this means the
> > > client has cached the handle of the old file of that name, which has
> > > been deleted.
> > >
> > > - Are client and server clocks closely synchronised?  If not, that
> > > needs to be fixed.
> > >
> > The clocks are synchronized using NTP.
> >
> > > - Are clients likely to read this directory while rsync is running, or
> > > shortly before?  If so, it may help to reduce the attribute caching
> > > timeout on the client.  See the "Directory entry caching" section in
> > > the nfs(5) manual page.
> > >
> > Clients are not likely to read this directory while rsync is running for the
> > observed cases.  That can happen in our environment, but not in this case.
> > I am using the lookupcache=pos option.  I tried noac, but the performance
> > penalty was too much.  Which option are you referring to and what setting
> > do you recommend testing?
> >
> > > I don't know why you're only seeing this after an upgrade of the
> > > clients, though.  I'm not aware that there has been any big change to
> > > attribute caching.
> > >
> > I appreciate you respond

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

What additional information can I provide for us to move forward with this 
process?

To summarize and include further details, rsync is used to sync applications to 
a file server which behaves like a repository.
We do preserve timestamps from the build server and also use --delete.  We do 
not run the applications from the file server.  All servers use NTP.

The application has a sub-directory that contain files with version numbers.  
These are libraries.
When a new build is complete, a developer pushes their updates via rsync to the 
file server / repository.

I believe that the dentry cache thinks the "old" files exist and generates a No 
such file or directory error showing question marks for that files attributes.
Dropping the dentry cache via echo 2 > /proc/sys/vm/drop_caches resolves the 
issue. 

This behavior is not observed in Debian 10.8 with that distributions associated 
kernel and packages.

> -Original Message-----
> From: Jason Breitman
> Sent: Friday, August 19, 2022 9:52 PM
> To: Ben Hutchings ; 1017...@bugs.debian.org
> Subject: RE: Bug#1017720: nfs-common: No such file or directory
> 
> > -Original Message-
> > From: Ben Hutchings 
> > Sent: Friday, August 19, 2022 7:27 PM
> > To: Jason Breitman ;
> > 1017...@bugs.debian.org
> > Subject: Re: Bug#1017720: nfs-common: No such file or directory
> >
> > Control: tag -1 moreinfo
> >
> > On Fri, 2022-08-19 at 13:16 +, Jason Breitman wrote:
> > > Package: nfs-common
> > > Version: 1:1.3.4-6
> > > Severity: important
> > >
> > > Kernel: 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64
> > > GNU/Linux
> > >
> > > -- Description
> > > After updating and or creating new files on our file server via
> > > rsync, we see many files report the error message below from NFSv4
> > > clients since upgrading from Debian 10.8 to Debian 11.4.
> > > Clearing the dentry cache resolves the issue right away.
> > > I am not sure that nfs-common is the package to blame, but listed
> > > it based on the bug submission recommendations.
> >
> > The NFS implementation is mostly in the kernel, so probably this issue
> > belongs there.  But the kernel team is responsible for both packages.
> >
> > [...]
> > > -- Error message
> > > ls: cannot access 'filename': No such file or directory
> > > -? ? ???? filename
> > [...]
> >
> > So we know the file's there but can't stat it.  I think this means the
> > client has cached the handle of the old file of that name, which has
> > been deleted.
> >
> > - Are client and server clocks closely synchronised?  If not, that
> > needs to be fixed.
> >
> The clocks are synchronized using NTP.
> 
> > - Are clients likely to read this directory while rsync is running, or
> > shortly before?  If so, it may help to reduce the attribute caching
> > timeout on the client.  See the "Directory entry caching" section in
> > the nfs(5) manual page.
> >
> Clients are not likely to read this directory while rsync is running for the
> observed cases.  That can happen in our environment, but not in this case.
> I am using the lookupcache=pos option.  I tried noac, but the performance
> penalty was too much.  Which option are you referring to and what setting
> do you recommend testing?
> 
> > I don't know why you're only seeing this after an upgrade of the
> > clients, though.  I'm not aware that there has been any big change to
> > attribute caching.
> >
> I appreciate you responding to my report and am happy to answer any
> questions.
> We have multiple monitors and log scrapers to detect "file not found"
> exceptions that would let us know if this was happening before.
> To share more, I have 2 environments mounting from the same file server.
> Each environment has several servers.  The issue is only seen in the
> environment running Debian 11.4.
> I also should have mentioned that the files in question have a version
> number appended.  filename-.  When the file is updated via rsync, it is
> called filename-1112 and the prior file is removed.  The error is about
> filename-.
> I am not sure if this is the proper terminology, but the issue appears to be
> the negative dentry cache.
> 
> > Ben.
> >
> > --
> > Ben Hutchings
> > Beware of bugs in the above code;
> > I have only proved it correct, not tried it. - Donald Knuth
> 
> Jason Breitman
Jason Breitman

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

> -Original Message-
> From: Ben Hutchings 
> Sent: Friday, August 19, 2022 7:27 PM
> To: Jason Breitman ;
> 1017...@bugs.debian.org
> Subject: Re: Bug#1017720: nfs-common: No such file or directory
> 
> Control: tag -1 moreinfo
> 
> On Fri, 2022-08-19 at 13:16 +, Jason Breitman wrote:
> > Package: nfs-common
> > Version: 1:1.3.4-6
> > Severity: important
> >
> > Kernel: 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64
> > GNU/Linux
> >
> > -- Description
> > After updating and or creating new files on our file server via
> > rsync, we see many files report the error message below from NFSv4
> > clients since upgrading from Debian 10.8 to Debian 11.4.
> > Clearing the dentry cache resolves the issue right away.
> > I am not sure that nfs-common is the package to blame, but listed
> > it based on the bug submission recommendations.
> 
> The NFS implementation is mostly in the kernel, so probably this issue
> belongs there.  But the kernel team is responsible for both packages.
> 
> [...]
> > -- Error message
> > ls: cannot access 'filename': No such file or directory
> > -? ? ???? filename
> [...]
> 
> So we know the file's there but can't stat it.  I think this means the
> client has cached the handle of the old file of that name, which has
> been deleted.
> 
> - Are client and server clocks closely synchronised?  If not, that
> needs to be fixed.
> 
The clocks are synchronized using NTP.  

> - Are clients likely to read this directory while rsync is running, or
> shortly before?  If so, it may help to reduce the attribute caching
> timeout on the client.  See the "Directory entry caching" section in
> the nfs(5) manual page.
>
Clients are not likely to read this directory while rsync is running for the 
observed cases.  That can happen in our environment, but not in this case.
I am using the lookupcache=pos option.  I tried noac, but the performance 
penalty was too much.  Which option are you referring to and what setting do 
you recommend testing?

> I don't know why you're only seeing this after an upgrade of the
> clients, though.  I'm not aware that there has been any big change to
> attribute caching.
> 
I appreciate you responding to my report and am happy to answer any questions.
We have multiple monitors and log scrapers to detect "file not found" 
exceptions that would let us know if this was happening before.
To share more, I have 2 environments mounting from the same file server.  Each 
environment has several servers.  The issue is only seen in the environment 
running Debian 11.4.
I also should have mentioned that the files in question have a version number 
appended.  filename-.  When the file is updated via rsync, it is called 
filename-1112 and the prior file is removed.  The error is about filename-.
I am not sure if this is the proper terminology, but the issue appears to be 
the negative dentry cache.

> Ben.
> 
> --
> Ben Hutchings
> Beware of bugs in the above code;
> I have only proved it correct, not tried it. - Donald Knuth

Jason Breitman

Bug#1017720: nfs-common: No such file or directory

[Jason Breitman]

Package: nfs-common
Version: 1:1.3.4-6
Severity: important

Kernel: 5.10.0-16-amd64 #1 SMP Debian 5.10.127-1 (2022-06-30) x86_64 GNU/Linux

-- Description
After updating and or creating new files on our file server via rsync, we 
see many files report the error message below from NFSv4 clients since 
upgrading from Debian 10.8 to Debian 11.4.
Clearing the dentry cache resolves the issue right away.
I am not sure that nfs-common is the package to blame, but listed it based 
on the bug submission recommendations. 

-- Test
ls -l /mnt/dir/someOtherDir/* | grep '?'

-- Error message
ls: cannot access 'filename': No such file or directory
-? ? ???? filename

-- Workaround
/usr/bin/sync && echo 2 > /proc/sys/vm/drop_caches

-- /etc/fstab snippet --
nfs-server.domain.com:/dir  /mnt/dirnfs4
lookupcache=pos,noresvport,sec=krb5,hard,rsize=1048576,wsize=10485760   0

Jason Breitman 

Bug#1016887: heaptrack: Grammar error in package description, misuse of contraction "it's" for possessive "its"

[Jason L. Quinn]

Package: heaptrack
Version: up to current (which is 1.3.0-1)
Severity: minor
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com

Dear Maintainer,

The Debian package description says

"Heaptrack is notable for it's ability..."

it should be

"Heaptrack is notable for its ability..."

I noticed on Bullseye but checked that it still exists
up in 1.3.0-1 package on testing (Bookworm) and unstable (sid).

This bug also applies to the packages

libheaptrack and heaptrack-gui

Small bug report but hopefully one that helps polish Debian.

Thanks for what you do.

Cheers,
Jason Quinn

-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-16-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 heaptrack depends on:
ii  libboost-iostreams1.74.01.74.0-9
ii  libboost-program-options1.74.0  1.74.0-9
ii  libc6   2.31-13+deb11u3
ii  libgcc-s1   10.2.1-6
pn  libheaptrack
ii  libstdc++6  10.2.1-6

heaptrack recommends no packages.

Bug#1008082: How to --lock an account

[Jason Franklin]

On Wed, Jul 27, 2022 at 03:21:08PM +0200, Marc Haber wrote:
> > Before I start, I want to make sure we agree on what should be done.
> > 
> > I asserted that two things were sufficient:
> >   1. Put a '!' in front of the user's password in /etc/shadow
> >   2. Expire the account
> > 
> > This makes it trivial to unlock an account with all of its attributes
> > intact, including login shell.
> 
> I think that having nologin as a shell has the advantage of giving a
> clear error message IF somebody manages to log in to the expired account
> with an invalid password.

The message with /usr/sbin/nologin is indeed nice. On my system, I get
something like...

| $ su --login foo
| Password:
| This account is currently not available.

With password locking plus account expiration, I get...

| $ su --login fish
| Password: 
| su: Authentication failure

I find it odd that I get a password prompt for an account that is
expired, but so it is.

Changing the shell won't hurt, of course.

My only reason for saying it's not necessary is that someone being able
to log in to an expired account would indicate a bug somewhere else that
should be fixed (in shadow, maybe?). If account expiration cannot be
relied upon, we have a bigger security concern, I think.

> For a normal user account, I am undecided whether:
> 
> - leave login shell intact, leaving a possible security hole

Again, this is where I am not so sure.

If there is a security hole, it would be someone else's, right?

Account expiration is either reliable or it is not.

> - set login shell back to the default when the account gets reenabled
> - save login shell somewhere to reinstate if on reenabling.
> 
> I'd say, do it as you see fit, changing that at a later time would be a
> rather isolated change so I'm fine with going ahead either way here,
> while still having a personal preference for the third possibility, but
> I am not the one who decides that.

This is fair.

As soon as I'm done with the other bug I'm working on, I'll move to this
one and proceed with the stateless implementation.

Saving and restoring a user's shell can be added later if needed.

Sound good?

-- 
Jason Franklin

Bug#152195: Suggested --homeless option may now be redundant

[Jason Franklin]

Greetings:

I began implementing the solution to this bug just this morning.

There are two parts to the fix:
  1. Clarify the intent of --no-create-home in the man page.
  2. Implement the new --homeless option.

I think that #2 has become redundant given that new systems users are
now "homeless" by default. This was not the case when we first decided
to add the --homeless option.

I cannot think of a situation where one would want to have a "homeless"
non-system (normal) user. Thus, I now think adding this option would be
a mistake.

If it is okay, I will skip the implementation of --homeless and just
proceed with updating the documentation for the --no-create-home option.

Sound good?

-- 
Jason Franklin

Bug#1015907: Remove the unused "get_users_groups" subroutine

[Jason Franklin]

Package: adduser
Version: 3.124
Severity: minor

Greetings:

This is a minor change, but it does remove a library function that
previously had some purpose.

Let me know if this causes problems.

Thanks!

-- 
Jason Franklin

Bug#1015781: autopkgtests fail if user foo exists or existed

[Jason Franklin]

On Thu, Jul 21, 2022 at 08:27:15AM +0200, Marc Haber wrote:
> The tests expect the test environment to be fresh.

When I wrote the initial autopkgtests, my thought was that this was the
entire design idea of the system.

Each stanza in the debian/tests/control file results in the
instantiation of a new chroot or container before its named collection
of tests is run.

The tests in each stanza, of course, use the same environment. That was
the reasoning behind saving and restoring /etc/passwd and friends in the
Perl BEGIN and END blocks of each test script. Not perfect, but it
speeds up the tests.

> They relay too much on uids being the same and do not preseed adduser
> to provide reproducible uids.

I can understand that this is a problem.

If new Debian system users or groups are added to the base files, or if
default ID ranges change, we have an issue when specific ID numbers are
relied upon.

This was why my tests mainly picked usernames and not ID numbers.

If Debian ever puts the user "foo" in the base system, we'll need to do
a find and replace to change "foo" to something else. ID numbers will be
harder to change, so they should be avoided or selected dynamically.

> Reproducer:
> - create test chroot
> - adduser --system foo
> - deluser foo
> - verify that foo is actually gone
> - run autopkgtests
> - see not just one test failing.

This seems like it shouldn't fail. However, there are probably side
effects here that the tests handle that aren't handled by doing this
interactively first.

In principle, I think that picking a set of canonical usernames to work
with in tests should be fine. Picking fixed ID numbers is probably not
fine.

-- 
Jason Franklin

Bug#1008082: Beginning work

[Jason Franklin]

On Wed, Jul 13, 2022 at 11:00:11PM +0200, Marc Haber wrote:
> The expire dates are controlled by useradd's configuration file
> /etc/login.defs, and the format is documented, so there is nothing too
> wrong by just grepping the information from there. For a non-system
> account, we would re-establish the default expiration value, or we could
> save the expiration date in a state file and read it from there. Otoh,
> for a system account, we should probably just disable account expiration
> and document that adduser as a policy layer does not handle system
> accounts with an expiration date.

Sounds reasonable.

> We're going to need state for some requested features anyway, sooner or
> later.
> 
> The nologin shell has the nice advantage of denying login _with_ _a_
> _message_ should somebody be able to log in to the account by some other
> means that might be allowed by weird PAM and ssh stuff. I would like to
> do that anyway, albeid not being strictly necessary.

Sure. I had thought that expiry would be sufficient. However, if you are
saving state after locking, it is simple enough to use the nologin shell
as another hardening step.

> I'd like to claim that feature and work on it if you're ok with that.
> I'm going to create a branch deluser-lock and push frequently, so you
> can review what I am doing. I reserve the right to force-push that
> branch though.

Proceed, of course!

Slowness on my part shouldn't hold things up! ;)

Best,

-- 
Jason Franklin

Bug#1008082: Beginning work

[Jason Franklin]

On Wed, Jul 13, 2022 at 10:18:55PM +0200, Marc Haber wrote:
> are you progressing here? If not, I'd like to tackle this with some low
> priority.

Unfortunately, I have not made any progress on this yet.

Too many personal things in the way...

> If adduser --lock sets the shell to nologin, how would we restore the
> account? Setting shell to /bin/bash, allowing --unlock a --shell option?
> Or should we finally introduce a state directory /var/lib/adduser and
> save the shell here?

I assume you mean to clarify the behavior of "deluser --lock" here.

Giving this some thought, I would not go the route of changing any of
the user's attributes like the login shell.

My understanding is that truly locking an account requires two things:
  1. Place a "!" in front of the password field in /etc/shadow.
  2. Expire the account.

The first makes the password invalid in a way that is easily reversible.
The commands "usermod -L foo" and "usermod -U foo" will disable and then
re-enable password authentication for user "foo" in this manner.

The second requires setting the user's EXPIRE_DATE to 1. This should
disable other forms of authentication without modifying any info we
would want to save (except for the expire date).

See usermod(8) and shadow(5) for more info on locking and expiry.

The minimal satisfactory fix would be just a "--lock" option for the
deluser command which does both of the above. To undo this, an admin
would run "usermod -U foo" and then set the expire date for the account
according to site policy. I am not sure if there is a convenient command
for doing the latter.

> Should we do that in adduser, or should we have a new binary moduser?

Not sure how to answer this one.

Like I say above, adding only the "--lock" option to deluser minimally
satisfies this new requirement.

I would say it's up to you! :)

-- 
Jason Franklin

Bug#1013311: libgl1-mesa-dri: mesa 22.x package build removes support for Intel Gen2 and Gen3 chipsets

[Jason Richards]

Package: libgl1-mesa-dri
Version: 22.0.5-1
Severity: normal
X-Debbugs-Cc: deb...@jasonworld.co.uk

Dear Maintainer,

Mesa 22 removed support for the legacy i915 driver but a Gallium i915 driver 
exists in it's place.

>From what I can gather, Debian stopped building this driver for historic 
>reasons due to it's poor quality back 2011. The quote from the changelog at 
>the time is:

"Stop building i915g at all, it's apparently never going to be a suitable 
replacement for i915c."

This is no longer true. The Gallium i915 driver has been receiving considerable 
attention upstream and is now the only choice for Intel Gen2 and Gen3 chipsets.

May is propose this driver is reinstated to the package build?


Kind Regards
Jason

Bug#1012492: /etc/adduser.conf.dpkg-save created by postinst

[Jason Franklin]

On Wed, Jun 08, 2022 at 06:01:11PM +0200, Marc Haber wrote:
> On Wed, Jun 08, 2022 at 10:11:48AM -0400, Jason Franklin wrote:
> > Personally, I think we should simply install a default adduser.conf file
> > and remove all of the debconf stuff from the post install script.
> 
> That was like the gist of a short discussion I initiated in March, see
> https://lists.debian.org/debian-boot/2022/03/msg00099.html

Aha! Wonderful. There is precedent for this idea.

This thread also explains the context in which this debconf question had
been useful (i.e., the installer). I had not been able to guess this.

We would also be able to finally close this one:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541620

> We just need to make sure to make a smooth transitoin, testing
> installation and upgrades from a system with a locally changed
> adduser.conf, a locally removed adduser.conf and adduser.conf unchanged
> from the package. Local changes must be preserved.

I had thought this would be gracefully handled by Dpkg, but maybe my
understanding is not complete here.

Simply changing the debian/install file to properly install the default
/etc/adduser.conf file would work, I had thought (also removing all of
the newly obsolete stuff in the maintscripts).

The result would be that installing/upgrading adduser would prompt for
whether or not you want to keep the local version or take the
maintainer's version, etc.

This prompt would depend on whether, for example, --force-confmiss or
--force-conf{old,new} are passed to Dpkg, usually via apt.

At least I thought that's how it would work.

If we're on the same page here, should I put a patch together?

-- 
Jason Franklin

Bug#1012492: /etc/adduser.conf.dpkg-save created by postinst

[Jason Franklin]

On Wed, Jun 08, 2022 at 11:50:53AM +0200, Tomáš Virtus wrote:
> Adduser's postinst script creates /etc/adduser.conf.dpkg-save file on
> debootstrap's root filesystem, that is, even if /etc/adduser.conf
> doesn't exist prior to package installation.

Greetings:

Personally, I think we should simply install a default adduser.conf file
and remove all of the debconf stuff from the post install script.

By installing the file directly, we will cause the adduser package to
own the conffile as one would expect. Debsums will work, dpkg -S will
work, etc.

This would also lead to a resolution of this bug:

https://bugs.launchpad.net/ubuntu/+source/adduser/+bug/1873519

I have never used the debconf settings that adduser has, but the ability
to use config-package-dev would be fantastic.

How impactful would it be to remove the debconf stuff?

I'd be happy to whip up a patch to do this, but I don't want to just
blow away debconf settings that people rely upon.

-- 
Jason Franklin

Bug#1012341: med-config: 90med-config file missing a necessary trailing semi-colon

[Jason Quinn]

Thank you for the quick follow-up, Andreas. There's no pressing need
for an immediate upload. I'm just a user who wanted to help Debian be
as polished as possible.

I'm glad you found the solution ultimately lies in blends-dev. Please
note I filed a similar bug (#1011982) against the science-config
package. If both my reports are caused by the same issue in
blends-dev, maybe you can create a bug there and close the two
separate bugs (or however Debian handles such cases).

Thanks again.

Bug#1012341: med-config: 90med-config file missing a necessary trailing semi-colon

[Jason L. Quinn]

Package: med-config
Version: 3.7
Severity: normal
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com

Dear Maintainer,

The file /etc/apt/apt.conf.d/90med-config has a syntax error. It is missing a
trailing semi-colon for the DPkg scope. This can cause parsing errors, eg with
the cupt package manager. You can confirm the bug by installing the cupt
package and running "cupt why" on the command line.

When a scope is used in an apt config file, the trailing semi-colon after the
closing delimiter brace is necessary (as per "man 5 apt.conf").

The fix, I believe, is to merely change

DPkg {
Post-Invoke {"test -f /var/run/med-config.usermenu && if [ -x
/usr/sbin/blend-update-usermenus ] ; then /usr/sbin/blend-update-usermenus med
; fi ; rm -f /var/run/med-config.usermenu";};
}

to

DPkg {
Post-Invoke {"test -f /var/run/med-config.usermenu && if [ -x
/usr/sbin/blend-update-usermenus ] ; then /usr/sbin/blend-update-usermenus med
; fi ; rm -f /var/run/med-config.usermenu";};
};

in the /etc/apt/apt.conf.d/90med-config file.

I'm running bullseye so I have med-config version 3.7.0 but I just checked and
the issue is still present in sid for 3.7.1.

Hope that helps.


-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-14-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 med-config depends on:
ii  adduser3.118
ii  blends-common  0.7.2
ii  debconf [debconf-2.0]  1.5.77
ii  menu   2.1.48

med-config recommends no packages.

med-config suggests no packages.

-- debconf information:
* med-config/group:
  shared/med-config/usermenus: never

Bug#995670: Another zig packaging effort

[Jason Ernst]

Yes no problem!

On Thu, Jun 2, 2022, 4:36 PM Bastian Germann  wrote:

> X-Debbugs-Cc: nicholaschasti...@gmail.com
>
> Hi,
>
> Jason, you would have to provide a source package (.dsc + referenced
> files) somewhere,
> which is a complete thing for Debian folks. This is the condition to find
> a sponsor.
> I have not looked at your approach because it is unfamiliar.
>
> I have had a look at what Nick provided and this seems to be reasonable
> enough to take a closer look.
> The build log looks like you took the approach that Andrew described.
>
> Jason, would you be willing to hand over the ITP to Nick so that we can
> make zig happen for bookworm?
> Nick, in case Jason does not reply in three weeks please take this over
> and address this ITP with your changelog.
>
> Thanks,
> Bastian
>

Bug#1011982: science-config: configuration file "90science-config" is missing semi-colon. Causes "unable to parse the config file" errors

[Jason L. Quinn]

Package: science-config
Version: 1.14.2
Severity: normal
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com

Dear Maintainer,

Using a tool like cupt results in warnings like

E: syntax error: line 8, character 1: expected: semicolon (';')
E: unable to parse the config file '//etc/apt/apt.conf.d/90science-config'
W: skipped the configuration file '//etc/apt/apt.conf.d/90science-config'


The contents of that file are:

/*
 * APT configuration file for science-config package
 */

DPkg {
Post-Invoke {"test -f /var/run/science-config.usermenu && if [ -x
/usr/sbin/blend-update-usermenus ] ; then /usr/sbin/blend-update-usermenus
science ; fi ; rm -f /var/run/science-config.usermenu";};
}


And it appears that indeed it is missing the semi-colon to end the DPkg scope.
The file should be

/*
 * APT configuration file for science-config package
 */

DPkg {
Post-Invoke {"test -f /var/run/science-config.usermenu && if [ -x
/usr/sbin/blend-update-usermenus ] ; then /usr/sbin/blend-update-usermenus
science ; fi ; rm -f /var/run/science-config.usermenu";};
};


Hope that helps.


-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-14-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 science-config depends on:
ii  adduser3.118
ii  blends-common  0.7.2
ii  debconf [debconf-2.0]  1.5.77
ii  menu   2.1.48

science-config recommends no packages.

science-config suggests no packages.

-- debconf information:
* science-config/group:
  shared/science-config/useusermenus:

Bug#1008082: Beginning work

[Jason Franklin]

Greetings:

I plan to start work on this issue in the next few days.

Let me know if this conflicts with anyone's plans!

Best,

-- 
Jason

Bug#956403: sasl2-bin: Log file missing string do_auth

[Jason Naughton]

Hi Bastian,

I wouldn’t worry about it any more.   I migrated to another solution a while 
back.  You can close this as it may have only effected me at the time.  To be 
honest I can’t even remember posting this bug as it was over 2 years ago.   

Cheers

Jason Naughton,  P.Eng, M.E.Sc,
Professional Contractor,
JMN Planning,  Pickering, Ontario,
Office: (647)-693-4880

> On Apr 24, 2022, at 09:24, Bastian Germann  wrote:
> 
> On Fri, 10 Apr 2020 13:54:46 -0400 Jason Naughton  wrote:
>> So it looks like in debian the package does not define HAVE_FUNC which leads 
>> to L_FUNC being set to " ".
>> I downloaded the source from the master and it seems that gcc implements 
>> this.  Compiling on my desktop I get:
>> checking whether gcc implements __func__... yes
>> Any chance this package can be compiled with this feature?
>> -- System Information:
>> Debian Release: 10.3
>>  APT prefers stable-updates
>>  APT policy: (500, 'stable-updates'), (500, 'stable')
>> Architecture: amd64 (x86_64)
>> Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
>> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
>> LANGUAGE=en_CA:en (charmap=UTF-8)
>> Shell: /bin/sh linked to /usr/bin/dash
>> Init: systemd (via /run/systemd/system)
>> Versions of packages sasl2-bin depends on:
>> ii  db-util5.3.1+nmu1
> 
> Hi Jason,
> 
> Does the bug also exist in bullseye or bookworm? If this is just a buster 
> issue, I will not fix it.
> 
> Thanks,
> Bastian

Bug#737359:

[Lee james jason Stephen hayes]

Bug#1007100: minetest: Takes a long time to start and has no audio

[Jason Bigelow]

Package: minetest
Version: 5.4.1+repack-2+b1
Severity: important
Tags: a11y

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***

Dear Mainter/Debian Games Team,

I am a long time player of Minetest and often build my own Minetest. This issue
has been affecting both my own builds as well as installation through apt.

Since the last few days, whenever I start 5.4.1+repack-2+b1 from apt, or my own
builds of 5.5.0 or 5.6.0-dev, Minetest takes a very long time to start, and
fails to launch with OpenAL sound support.

I suspect the issue does not actually lie directly in Minetest but some other
package, otherwise 5.4.1 from apt would have had this issue since its release. I
am reporting it against Minetest nevertheless because it has not affected any of
my other applications such as Firefox, VLC or any Steam games, and I do not know
where better to send this report.

The output of a terminal session where I am trying to remove, rebuild and run
minetest is attached, including the output of `minetest --trace`

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages minetest depends on:
ii  libc6 2.33-7
ii  libcurl3-gnutls   7.81.0-1
ii  libfreetype6  2.11.1+dfsg-1
ii  libgcc-s1 12-20220302-1
ii  libgl11.4.0-1
ii  libgmp10  2:6.2.1+dfsg-3
ii  libirrlicht1.81.8.5+ds-2
ii  libjsoncpp25  1.9.5-3
ii  libleveldb1d  1.23-3
ii  libluajit-5.1-2   2.1.0~beta3+dfsg-6
ii  libncursesw6  6.3-2
ii  libopenal11:1.19.1-2
ii  libpq514.2-1
ii  libspatialindex6  1.9.3-2
ii  libsqlite3-0  3.37.2-2
ii  libstdc++612-20220302-1
ii  libtinfo6 6.3-2
ii  libvorbisfile31.3.7-1
ii  libx11-6  2:1.7.2-2+b1
ii  minetest-data 5.4.1+repack-2
ii  zlib1g1:1.2.11.dfsg-2

minetest recommends no packages.

Versions of packages minetest suggests:
pn  minetest-mod-moreblocks  
pn  minetest-mod-moreores
pn  minetest-mod-pipeworks   
pn  minetest-server  
ii  minetestmapper   20200328-1

-- no debconf information
redacted@redacted:~/minetest$ cd ..
redacted@redacted:~$ rm -rf minetest
redacted@redacted:~$ git clone g...@github.com:minetest/minetest
Cloning into 'minetest'...
remote: Enumerating objects: 76442, done.
remote: Counting objects: 100% (58/58), done.
remote: Compressing objects: 100% (26/26), done.
remote: Total 76442 (delta 36), reused 39 (delta 32), pack-reused 76384
Receiving objects: 100% (76442/76442), 86.77 MiB | 6.12 MiB/s, done.
Resolving deltas: 100% (54548/54548), done.
redacted@redacted:~$ sudo dpkg --purge minetest
[sudo] password for redacted: 
(Reading database ... 516492 files and directories currently installed.)
Removing minetest (5.6.0) ...
dpkg: warning: while removing minetest, directory 
'/usr/local/share/locale/ru/LC_MESSAGES' not empty so not removed
dpkg: warning: while removing minetest, directory 
'/usr/local/share/locale/fr/LC_MESSAGES' not empty so not removed
dpkg: warning: while removing minetest, directory 
'/usr/local/share/locale/es/LC_MESSAGES' not empty so not removed
dpkg: warning: while removing minetest, directory 
'/usr/local/share/applications' not empty so not removed
dpkg: warning: while removing minetest, directory '/usr/local/bin' not empty so 
not removed
Processing triggers for man-db (2.10.1-1) ...
redacted@redacted:~$ cd minetest/
redacted@redacted:~/minetest$ git clone g...@github.com:minetest/irrlicht 
lib/irrlichtmt
Cloning into 'lib/irrlichtmt'...
remote: Enumerating objects: 10068, done.
remote: Counting objects: 100% (2626/2626), done.
remote: Compressing objects: 100% (1453/1453), done.
remote: Total 10068 (delta 1590), reused 1762 (delta 1147), pack-reused 7442
Receiving objects: 100% (10068/10068), 29.54 MiB | 5.83 MiB/s, done.
Resolving deltas: 100% (6495/6495), done.
redacted@redacted:~/minetest$ cmake .
-- The C compiler identification is GNU 11.2.0
-- The CXX compiler identification is GNU 11.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: 

Bug#868568: [Pkg-shadow-devel] Bug#868568: Bug#868568: Possible cause of deluser problem: subordinate user IDs

[Jason Franklin]

On Tue, 2022-03-08 at 18:39 +, Ben Harris wrote:
> On Tue, 8 Mar 2022, Serge E. Hallyn wrote
> 
> > So deluser was doing the right thing, right?
> > 
> > The bug is how you got into this state?  Either the adduser for
> > the high uid should have checked for it being a delegated subuid,
> > or the adduser which added the subuids to the lower subuid should
> > have refused when the higher subuid existed as a uid.
> 
> As far as I can see, there is no checking for collisions in either 
> direction: useradd depends on the ranges [UID_MIN,UID_MAX] and 
> [SUB_UID_MIN,SUB_UID_MAX] not overlapping, and issues a warning if you 
> assign a static UID outside the specified range.

Serge:

This is something that has recently gotten my attention in my adduser
maintenance efforts. I am trying to help where I can to work around it
and to collaborate with shadow on the issue to get at an optimal
solution.

adduser has its own UID ranges set in /etc/adduser.conf. These variables
are the ones that matter...

> FIRST_SYSTEM_UID=100
> LAST_SYSTEM_UID=999
> FIRST_SYSTEM_GID=100
> LAST_SYSTEM_GID=999
> FIRST_UID=1000
> LAST_UID=5
> FIRST_GID=1000
> LAST_GID=5

As far as I can tell, adduser has no concept of a "subordinate UID"
(neither do I for that matter). I was not familiar with this feature
until recently. This is something I'll have to read about.

The latest upload of adduser (v3.120) uses a naive technique of passing
through its own system user UID range settings to the useradd call. See
below...

  ('/usr/sbin/useradd', '-r',
  '-K', sprintf('SYS_UID_MIN=%d', $config{'first_system_uid'}),
  '-K', sprintf('SYS_UID_MAX=%d', $config{'last_system_uid'}),
  '-d', $home_dir,
  '-g', $ingroup_name,
  '-s', $shell,
  '-u', $new_uid,

This technique has the benefit that when you use "adduser" you make use
of adduser settings with no warnings from useradd. Likewise, using
useradd obviously still reads from /etc/login.defs.

However, it does not solve the problem that we have two places for the
settings to be specified. Maybe this is not as confusing as I think. The
adduser tool uses /etc/adduser.conf and useradd uses its own file. I
suppose it's on the user to know which file configures which tool.

Other than having adduser pass through its own settings to avoid
"useradd" warnings, I'm not sure what else can be done to reconcile this
divergence.  It has existed for a while.

Let me know if you have any thoughts! Thanks!

-- 
Jason Franklin

Bug#1004710: Invoke "useradd -r" when creating a system user

[Jason Franklin]

On Fri, 2022-02-25 at 02:45 -0600, Daniel Lewart wrote:
> Also "sudo apt install openssh-server" warns:
> useradd warning: sshd's uid 116 outside of the UID_MIN 1000 and
> UID_MAX 6 range.

Daniel:

Thanks for making note of this. Using "-r" does solve the issue, but
more needs to be done to ensure that other functionality is not altered
unintentionally.

To those interested, a fix for this is pending review and will be
included in the next upload.

-- 
Jason Franklin

Bug#1004710: Invoke "useradd -r" when creating a system user

[Jason Franklin]

On Tue, 2022-02-22 at 15:02 +0100, Marc Haber wrote:
> adduser --system should enforce policy for system users. The local
> administrator is free to ignore Debian policy as they see fit. adduser
> should not enforce things on the local admin that don't apply to them.
> 
> Maybe we add, some time in the future, an option --ignore-policy that a
> local admin can use, so that maintainer scripts get the support of
> policy enforcement.

I agree with this. The strictness should be something that can be
disabled if the local administrator so desires.

> > If useradd is intended to replace adduser, I would like to know as most
> > of my work would be lessened in importance.
> 
> I don't think there is any such intention in Debian. There is simply no
> mechanism to bring this forward other than talking and convincing each
> and every package maintainer.

It would be a ton of work. That's for sure.

-- 
Jason Franklin

Bug#1004710: Invoke "useradd -r" when creating a system user

[Jason Franklin]

On Sun, 2022-02-20 at 10:03 +0100, Ricardo Fraile wrote:
> Only to point that adduser is the recommended way to handle accounts in 
> maintainer scripts [1] and Debian Code Search reports 267 packages using 
> it [2], but dh_sysusers [3] seems to handle the same task on the 
> packages and works with useradd under the hood too.

There is certainly some work to be done to reconcile the three different
ways of managing users.

There needs to be:

- a "right way" to add a system user from a package
- a "right way" to add a system user from the command line
- a "right way" to do low-level user management tasks

I had envisioned "adduser" as a Debian policy enforcer on top of the
more distribution-agnostic tools from shadow. But, it is true now that
some features are confusingly duplicated across these methods. Notably,
there are settings for system user UID ranges in both /etc/login.defs
and /etc/adduser.conf.

There may be value in keeping "adduser" as a higher level tool that can
do helpful things by default (e.g., avoid forbidden UIDs, avoid UID
reuse, do additional clean up of at jobs w/o need for configs, etc.).

I am unsure how to proceed, but I know it will require working well with
the shadow maintainers.

I think I'll start a discussion through the proper channel.

Thanks!

-- 
Jason Franklin

Bug#1004710: Invoke "useradd -r" when creating a system user

[Jason Franklin]

On Sun, 2022-02-13 at 19:18 +0100, Marc Haber wrote:
> On Sun, Feb 13, 2022 at 12:27:26PM -0500, Jason Franklin wrote:
> > That warning is not emitted here when "-r" is added to the call made
> > from within adduser. The range discrepancy needs to be sorted out with
> > discussion, I think.
> 
> Policy also helps here, it's rather explicit in defining the uid ranges.
> Are we in line with policy?

Adduser is in line with policy for the moment. Improvements can be made
in this regard.

For example, some UIDs are explicitly forbidden by policy, but adduser
and useradd allow them.  These should be blocked, and tests should be
written to prove this.

> Useradd is more and more taking over functionality that has
> traditionally been implemented in adduser. Maybe they're working towards
> adduser just being a shim for backwards compatibility. Do you want me to
> reach out to them?

Please do.

I am actually a bit worried that my work is in vain. The useradd utility
does have quite a few features that clash with or overtake those
previously offered by adduser.

If useradd is intended to replace adduser, I would like to know as most
of my work would be lessened in importance.

The questions is: Can adduser offer features that admins want and that
useradd lacks?

I think the answer to the above question is "yes", but we need to make
sure we know what these additional features are.  :/

I'm a bit uncertain as to where I stand in this regard.

Thanks,

-- 
Jason Franklin

Bug#1004710: Invoke "useradd -r" when creating a system user

[Jason Franklin]

On Sun, 2022-02-13 at 18:14 +0100, Marc Haber wrote:
> Should useradd emit a warning in this case? I mean, we WANT the low UID
> in this case. Is it inside the limits of a low-level tool to impose its
> own standards on the system or is this possible a bug in useradd?

As part of this bug, we will need to have a conversation with the
"login" maintainers about how these ranges are to be configured.

Currently, useradd has its own range settings in /etc/login.defs, and
adduser has its own in /etc/adduser.conf. adduser can be written to
ignore the former completely in its useradd invocation.

However, having such a setting in two places may be a bit confusing.

That warning is not emitted here when "-r" is added to the call made
from within adduser. The range discrepancy needs to be sorted out with
discussion, I think.

-- 
Jason Franklin

Bug#1004710: Invoke "useradd -r" when creating a system user

[Jason Franklin]

On Sun, 2022-02-13 at 16:04 +0100, Ricardo Fraile wrote:
> Adding _tuptime user...
> useradd warning: _tuptime's uid 106 outside of the UID_MIN 1000 and UID_MAX 
> 6 range.
> Created symlink /etc/systemd/system/multi-user.target.wants/tuptime.service → 
> /lib/systemd/system/tuptime.service.
> Processing triggers for man-db (2.10.0-2) ...
> 
>* What outcome did you expect instead?
> Install the package without "useradd warning" prompt.

Ricardo:

I also came across this warning when investigating this bug.

When I get this bug fixed, the warning will go away.

Thanks!

-- 
Jason Franklin

Bug#1004710: Please pass "-r" to useradd when needed

[Jason Franklin]

On Fri, 2022-02-11 at 15:32 +0100, Marc Haber wrote:
> How about doing a release with all accumulated changes? It's called
> unstable for a reason, and frankly, I don't feel like putting ourselves
> into a rush just because another package broke ours.

I am certainly on board with this. Rushing is never good.

We will take our time and do this right. :)

It looks like Johannes will be able to work around this on his end for
now. I will put together a PR with tests in the near future to get this
fixed the right way.

-- 
Jason Franklin

Bug#1004710: Please pass "-r" to useradd when needed

[Jason Franklin]

On Fri, 2022-02-11 at 07:21 +0100, Johannes Schauer Marin Rodrigues
wrote:
> I can also see how setting the -r option might have unintended side-effects.
> 
> But the information you found already helps me to work around this problem 
> from
> the side of my package mmdebstrap. :)

Oh, cool! This is great to hear. It takes some of the time crunch off.

There are several useradd features that need to be incorporated into the
adduser code. This needs to be done carefully.

The "-r" option is one such feature. I will confirm this bug and make it
a priority to introduce this fix into the code with proper review and
tests and what not.

Thanks!

-- 
Jason Franklin

Bug#1004710: Please pass "-r" to useradd when needed

[Jason Franklin]

Johannes:

I took a bit of time to look at this further.

I think that adding "-r" to the useradd call found in adduser will not
break anything. It's the best way to go ahead and fix this, and it is
the most forward-looking solution.

To Marc: I would like to implement this with a proper autopkgtest in
adduser that proves that "/var/mail/foo" is not created by default when
system user "foo" is added. This will integrate nicely with the other
work I'm doing.

I could branch off of the 3.118 tag in the Debian/adduser repository and
submit a PR with the fix to master. Then, the new package with this fix
could be built off of the feature branch before the merge (the hotfix
branch). We can then merge with master (resolving conflicts) to
integrate with the changes we don't want to release yet.

Does this all sound reasonable?

-- 
Jason Franklin

Bug#1004710: Please pass "-r" to useradd when needed

[Jason Franklin]

Greetings:

I have been helping Marc Haber with some of the issues in adduser, so I
suppose it is appropriate for me to chime in here.

Thanks so much for the report and for the investigative work so far!

Here are my thoughts...

The "good" chroot has version 1:4.8.1-2 of passwd, and the "bad" chroot
has version 1:4.11.1+dfsg1-1 of passwd. The changes between these two
versions were substantial.

> Quoting Bálint Réczey (2022-02-10 22:46:50)
> > Apparently useradd correctly guessed system user ranges in the past,
> > but this is not something to rely on.

I do not think "useradd" ever attempted to guess whether a UID being
added was in the system user range. Instead, it looks like hardcoded
settings in the source code changed between the two versions above. To
see this, you may reference the upstream shadow repository...

Commit: 
https://github.com/shadow-maint/shadow/commit/bbf4b79bc49fd1826eb41f6629669ef0b647267b

The key part of that change was this:

- static const char *def_create_mail_spool = "no";
+ static const char *def_create_mail_spool = "yes";

The "adduser" command never set the "-r" option previously, but the
default in the upstream source was to not create the mail spool
directories.  Thus, this problem never surfaced.

> the recent upload of shadow 1:4.11.1+dfsg1-1 made above patch necessary as
> otherwise useradd will create empty directories in /var/mail and
> /var/spool/mail for the system users _apt, systemd-network and 
> systemd-resolve.
> This in turn breaks the testsuite of my package mmdebstrap.

I think setting the "-r" option is the right approach, but we need to
make sure that the new option doesn't do anything else that we do not
expect for it to do. I can see that it does more than just omit creating
the mail spool by default.

The "passwd" package could be patched temporarily to undo the change
from "no" to "yes" above. That would put us back at the old behavior for
the time being. This patch could be removed in the not-to-far future, as
I am committed to helping with supporting adduser and with fixing bugs
new and old, including this one. :)

Looking forward to hearing what Marc and others think on this one.

Thanks!

-- Jason Franklin

Bug#473379: Recommendation to remove the check and the warning

[Jason Franklin]

Greetings:

I thought I would go ahead and confirm this one. I noticed it myself
today, and I wanted to follow up here.

I recommend that we remove the check and the warning entirely.

First, the warning is already incorrect. It may mislead someone into
thinking that they can remove a group that still as members.

Second, an empty group is in many if not most cases NOT an error. There
are several standard groups that may be empty on a given system (e.g.,
"cdrom" or "adm").

Third, I believe that this is a case of "deluser" being a bit too
helpful. We should only be worried about whether a group is empty or not
when deleting a group. Otherwise, it is on the sysadmin to check for
empty groups if they are not desired.

Is my reasoning sound here?

If so, I'll work on this one after I finish the bug I'm working on
currently. It should be an easy win!

-- 
Jason Franklin

Bug#964906: This is still an issue in 11.2

[Jason Michaelson]

After two years i did a dist-upgrade on one particular system and this is
still an issue. I have to wonder why it got moved to btrfs-progs. This
really seems like a sequencing matter because all of the btrfs devices
aren't found before the system attempts to mount /. That makes me think
that it is an issue with initamfs-tools, especially since those of us who
have submitted potential fixes for it in this bug did so against initramfs
scripts.

I'm glad I had my script changes elsewhere and could migrate them from one
system to another when i encountered this problem. It would just be nice to
have it incorporated at the source.

Bug#559423: Update on bug #559423 (--system exit status)

[Jason Franklin]

Greetings:

The bug that I most recently started working on was this one. The latest
commits on the feature branch I have for this can be found on Salsa...

https://salsa.debian.org/deadjoe/adduser/-/commits/DBTS-559423-delgroup-status

N.B. This branch will probably be deleted when it's merged, so the above
link may break one day.

This bug is my first attempt at writing a new functional test. Notice
that the test CI step is failing during autopkgtest execution with the
proper expected failure (at commit d4f37a2a).

Next steps include adding a fix for this new failing test to close this
bug and writing a second test while implementing the proper set-up/tear-
down routines to be called in between.

I have arrived at a stopping point, having just a few questions...

1. I have commented out the invocation of the legacy test suite in the
test metadata file (debian/tests/control) to isolate my work.  This is
temporary to make sure nothing interferes with my new tests.  Should we
continue to support the legacy test suite?

2. In light of the above, does autopkgtest run the tests from each
stanza in debian/tests/control in a new/clean testbed?  How good is the
isolation between stanzas at test runtime, and what can I rely on
regarding this?  I would like to make sure old-style tests don't
interfere with my new-style tests.

Hopefully, a method for adding new tests can be established that is
immediately obvious to reviewers and contributors.  That will clear a
path for other contributors to add tests when they provide patches.

That's all for now.  Let me know what you think!

-- 
Jason Franklin

Bug#152195: Question on the use of "/nonexistent"

[Jason Franklin]

On Sun, 2021-12-19 at 12:08 +0100, Marc Haber wrote:
> I don't have anything to add but my support for the way that has been
> unanimously lined out in this discussion. Jason, you have my "go" to do
> those changes, and if it would be my choice it'd be --homeless ;-)
> 
> Otoh, --nonexistent-home would be more serious, but there is no much
> different to --home /nonexistent.

Most excellent!

I am happy that everyone else seems to be content with the result of
this discussion.  It sounds like we have a plan!  :)

There are three improvements to make here:

1. Augment the documentation for "--no-create-home" to clarify intent.
2. Implement the "--homeless" option. (This is tentative!)
3. Add tests for these options!

For #1: This is mainly to help less-experienced Debian admins such as
myself who are only exposed to creating users in the standard way.

For #2: A separate option is nice because it does not rely on a specific
directory value (e.g., "/nonexistent") in a script, which is a detail.
 It will need to be mutually exclusive with the "--home" option, and it
will need to imply the passing of "--no-create-home".  Don't worry, I
won't try to add something like this without automated tests!

For #3: I am currently trying to get up to speed with how to use
autopkgtest in adduser.  I am reluctant to change anything other than
docs until I have a corresponding test for what I want to change.  Once
I have a good workflow, I'll come back to this issue and make the
changes.

I suppose I can re-classify this as "minor" and "confirmed" for now.  I
would say "wishlist", but the main issue here is clarifying the docs,
and the new option ultimately might not be added.

I am still new to classifying bugs, so feel free to overwrite my changes
if they seem improper!  That will help me learn if I get it wrong.

Thanks to Marc and everyone else for clarifying things!

-- 
Jason Franklin

Bug#152195: Question on the use of "/nonexistent"

[Jason Franklin]

On Sat, 2021-12-18 at 19:22 +0100, Bill Allombert wrote:
> This seems to be a misunderstanding of the purpose of --no-create-home.
> This option does not say that the user does not have a home directory,
> but that it should not be created by adduser, and instead will be create
> later by some other procedure, for example by setting pam_mkhomedir
> to create it on first login, or by mounting a NFS filesystem on /home,
> etc.
> 
> In this bug report, users used --no-create-home but failed to create the
> home directory themselves.
> It seems that what they wanted to do was '--home /nonexistent'

Agreed.  I see the difference now.

I suppose I had thought that the discussion on this report happened
before the usage of /nonexistent was standard.

> I would suggest you add an option --no-homedir that do '--home /nonexistent'
> or whatever is appropriate and close this bug.

This is an interesting idea.  It would at least provide a distinction
for the intended result and it would guide people toward complying with
Debian Policy in the case that a user is not supposed to have a home
directory.

-- 
Jason Franklin

Bug#152195: Question on the use of "/nonexistent"

[Jason Franklin]

On Sat, 2021-12-18 at 10:16 -0800, Russ Allbery wrote:
> The documentation says simply:
> 
>--no-create-home
>   Do not create the home directory, even if it doesn't exist.
> 
> Passing --no-create-home therefore does not *change* the home directory,
> and should not change the home directory, since that would defeat its
> entire purpose.  The home directory is still set the same as before,
> including any defaults.  adduser just doesn't try to create it or check if
> it exists, because this should be handled external to adduser.
> 
> If a user should have a nonexistent home directory, --home /nonexistent
> should be passed to adduser.

I follow you.  This is an important distinction.

I suppose a note in the documentation could clarify things for users who
may not be aware of these other usage scenarios.

Thanks!

-- 
Jason Franklin

Bug#1001863: adduser: EXCLUDE_FSTYPES not respected with --remove-all-files

[Jason Franklin]

Adam:

Thanks so much for the thorough bug report!

>From looking at the code, I also cannot see how "--remove-all-files"
could possibly respect the "EXCLUDE_FSTYPES" option.  This does not
agree with the documentation at all.

Note that deluser.conf(5) currently has this to say...

  EXCLUDE_FSTYPES
A regular expression which describes all file systems which
should be excluded when looking for files of a user to be
deleted.  Defaults to "(proc|sysfs|usbfs|devpts|tmpfs|afs)".

This seems like a pretty clear contract with the user to skip deletion
of data residing on file systems of these types.

I will mark this bug as confirmed so that it can be handled in a future
release.

Thanks again!

-- 
Jason Franklin

Bug#1000385: 4digits: Package "4digits" shows up in bullseye package list but it is not actually there.

[Jason L. Quinn]

Package: 4digits
Version: 1.1.4-1+b1
Severity: normal
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com

Dear Maintainer,

As seen via the Synaptic package manager, there is a strange entry for
"4digits"
but it's listed as having download size "1 byte" in Section "unknown". Clicking
on
it generates the following information:

Package 4digits has no available version, but exists in the database.
This typically means that the package was mentioned in a dependency and never
uploaded, has been obsoleted or is not available with the contents of
sources.list

Because 4digits is so close to the alphanumeric top of the package list, it is
highly visible so whatever this issue is, it's a more prominent blemish
than it might at first seem.


-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/12 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 4digits depends on:
ii  libc6  2.31-13+deb11u2
pn  python 
pn  python-glade2  

4digits recommends no packages.

Bug#997977: /lib/systemd/system/monopd.service:8: Special user nobody configured, this is not safe!

[Jason L. Quinn]

Package: monopd
Version: 0.10.2-4
Severity: grave
Tags: security
Justification: user security hole
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com, Debian Security Team 


Dear Maintainer,

Recently upgraded from Buster to Bullseye. I'm not perusing
"journalctl --boot" looking for errors and warnings and submitting
bug reports as I tend to do after a Debian upgrade. One of the curious
lines in my journal logs was

/lib/systemd/system/monopd.service:8: Special user nobody configured, this is
not safe!

This does indeed appear to be a valid systemd warning. See commit at

https://github.com/systemd/systemd/commit/bed0b7dfc0070e920d00c89d9a4fd4db8d974cf0

Marked as grave as per bug descriptions in the reportbug tool (introduces a
security hole).

Cheers,
Jason





-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 monopd depends on:
ii  libc6   2.31-13+deb11u2
ii  libgcc-s1   10.2.1-6
ii  libmuparser2v5  2.2.6.1+dfsg-1
ii  libstdc++6  10.2.1-6
ii  libsystemd0 247.3-6
ii  lsb-base11.1.0

monopd recommends no packages.

Versions of packages monopd suggests:
ii  gtkatlantic  0.6.3-1

Bug#997854: tlp: Misconfiguration in TLP causes complete loss of sound on some systems

[Jason L. Quinn]

Package: tlp
Severity: important
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com

Dear Debian Maintainer,

There appears to be a severe sound issue affecting
some users that may ultimately trace back to the tlp package.
Please see the thread at

https://bbs.archlinux.org/viewtopic.php?id=243004

and in particular comment #7 by Toolfox.

I vaguely remember fixing a problem with buster that
turned out to be related to tlp. And then recently
I upgraded to bullseye and faced the same problem.
I had no sound at all. Nothing. But "fixed" the issue merely by
uninstalling the tlp package. Upon reboot, sound was
back so tlp is definitely preventing sound for some users.

This is a beguiling bug to track down because there's few
clues to follow and nobody suspects a power management package
to ultimately be the cause of such a severe sound bug.
The bug may be related to whether users are on battery or wall power
as comment #7 explains. I almost always use wall power so it affected
me.




-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 tlp depends on:
pn  hdparm  
ii  iw  5.9-3
ii  lsb-base11.1.0
ii  pciutils1:3.7.0-5
ii  rfkill  2.36.1-8
ii  usbutils1:013-3
ii  wireless-tools  30~pre9-13.1

Versions of packages tlp recommends:
pn  ethtool  
pn  tlp-rdw  

Versions of packages tlp suggests:
pn  acpi-call-dkms  
ii  linux-cpupower  5.10.70-1
ii  smartmontools   7.2-1

Bug#997853: bluetooth.service: Failed to locate executable

[Jason L. Quinn]

Package: bluetooth
Version: 5.55-3.1
Severity: important
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com

Dear Maintainer,

After a recent full-upgrade from buster to bullseye, bluetooth is not working.
It appears the system is looking for the bluetooth daemon executable in the
/usr/lib/bluetooth/ directory
but no such directory exists. There is a directory called
/usr/libexec/bluetooth/
that has a bluetoothd executable. I have tried reinstalling almost all the
bluetooth-related packages
hoping it might solve the issue by creating missing symlinks or whatever but it
did not.
I also have the bluez package installed and I wasn't certain which package to
file this bug against.

The output of "systemctl status bluetooth" gives:

 bluetooth.service - Bluetooth service
 Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor
preset: enabled)
Drop-In: /etc/systemd/system/bluetooth.service.d
 └─01-disable-sap-plugin.conf
 Active: failed (Result: exit-code) since Tue 2021-10-26 12:25:19 +08; 8min
ago
   Docs: man:bluetoothd(8)
Process: 4917 ExecStart=/usr/lib/bluetooth/bluetoothd --noplugin=sap
(code=exited, status=203/EXEC)
   Main PID: 4917 (code=exited, status=203/EXEC)
CPU: 4ms

Oct 26 12:25:19 mycomputername systemd[1]: Starting Bluetooth service...
Oct 26 12:25:19 mycomputername systemd[4917]: bluetooth.service: Failed to
locate executable /usr/lib/bluetooth/bluetoothd: No such file or directory
Oct 26 12:25:19 mycomputername systemd[4917]: bluetooth.service: Failed at step
EXEC spawning /usr/lib/bluetooth/bluetoothd: No such file or directory
Oct 26 12:25:19 mycomputername systemd[1]: bluetooth.service: Main process
exited, code=exited, status=203/EXEC
Oct 26 12:25:19 mycomputername systemd[1]: bluetooth.service: Failed with
result 'exit-code'.
Oct 26 12:25:19 mycomputername systemd[1]: Failed to start Bluetooth service.


-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 bluetooth depends on:
ii  bluez  5.55-3.1

bluetooth recommends no packages.

Versions of packages bluetooth suggests:
ii  bluez-cups   5.55-3.1
pn  bluez-meshd  
ii  bluez-obexd  5.55-3.1

Bug#997836: linuxptp's timemaster service and missing chrony package causing log errors

[Jason L. Quinn]

Package: linuxptp
Version: 3.1-2.1
Severity: normal
Tags: d-i
X-Debbugs-Cc: jason.lee.quinn+deb...@gmail.com

Dear Maintainer,

Output of "journalctl -p err" was giving error lines such as

Oct 25 20:34:14 mycomputername timemaster[862]: [4.900] failed to spawn
/usr/sbin/chronyd: No such file or directory

"timemaster" here, I believe, is referring to the systemd timemaster service
from the linuxptp package on
Debian (I'm not sure about that). I don't have the chrony package installed so
this error makes sense for
that reason. If it's true that this error traces to the linuxptp package, the
error is
unexpected because the linuxptp package does not list the chrony package as
either recommended or suggested for
installation and wasn't installed when I upgraded a couple of days ago to
bullseye from buster.

Trying to install the chrony package shows that it would require removing the
systemd-timesyncd package.
At this point, it's unclear what a user not familiar with the intricacies of
timekeeping on
linux should do and I'm reluctant to start uninstalling packages and risk
falling down a rabbit hole.


-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500,
'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/12 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 linuxptp depends on:
ii  libc6  2.31-13+deb11u2

linuxptp recommends no packages.

linuxptp suggests no packages.

Bug#982894:

[Jason Perrin]

I have seen exactly the same problem (on AWS EC2 too), so I'm definitely
interested in a fix for this. Leaving /etc/resolv.conf unmodified if the
disk is full seems perfect as a fix!

Bug#995670: ITP: zig -- General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software

[Jason Ernst]

So far I have a working build from the main zig repo for amd64, using the
llvm, clang and lld from the debian repos (although this is only possible
in sid because version 12 isn't present in the stable releases).
I've been doing it via docker to ensure a clean build environment:
https://github.com/compscidr/zig-deb/tree/debian-pkg/debian-pkg

It generates all of the needed files, and sings the package according to
guides I've been following from the mentors / maintainers websites.

I think I have figured out how to also produce cross-compiled packages for
other arches using pbuilder, but I'll have to abandon my docker approach
since it doesn't seem to work well with it. Planning on abandoning the
docker approach and using a debian VM in virtualbox (I typically use
Ubuntu).

I'm guessing in order to work in non-sid debian, I'll have to pull in the
actual llvm, lld, and clang sources like the bootstrap repo does. I'm
guessing these also need to be packaged in the debian source package too?

One thing I haven't tried is just using zig itself to do the cross
compiling.

Andrew, happy to work with you on this, if you like instead of dev-ing this
in my own repo, I can make a branch in either the main zig repo, or the
bootstrap repo - whichever you'd prefer. Also happy to jump on a quick call
to discuss.

Jason


On Sat, Oct 9, 2021 at 12:42 PM Andrew Kelley  wrote:

> On Tue, 5 Oct 2021 00:20:09 + Paul Wise  wrote:
> > Please make sure the package is built solely from the source from
> > scratch without any existing binaries using the upstream supported
> > bootstrap process:
> >
> > https://github.com/ziglang/zig-bootstrap/
> >
> > Personally, I think merging zig-bootstrap into the zig source repo
> > would make it easier for distros to use, but I hear upstream isn't
> > interested in that.
>
> Hi pabs,
>
> Upstream is definitely interested in cooperating with Debian maintainers
> to the benefit of our shared users :-)
>
> I'm happy to discuss this suggestion. Here is some information to help
> us sort this out:
>
>   * zig-bootstrap contains copy+pasted upstream sources from
> - LLVM, LLD, Clang
>   - There is currently 1 tiny patch to LLD's build script to adjust
> an include directory to depend on something inside zig-bootstrap rather
> than to an external directory
>   - There are also some deleted files which is merely an attempt to
> reduce tarball size; these could be restored to no harmful effect.
> - Zig (no patches)
> - zlib (no patches)
>
>   * Apart from this, the *only* utility that zig-bootstrap provides is a
> short build script, which does the following process:
> - Build LLVM, Clang, LLD, zlib, zig from source, for the host system
> - Using freshly built native zig, use `zig cc`/`zig c++` to rebuild
> LLVM, Clang, LLD, zlib, and zig again, from source, for the target system
>
> This is useful for upstream to provide portable binaries of Zig,
> however, I suspect that there is a better strategy which is more
> compatible with Debian's guidelines. In fact, I have been keeping
> Debian-friendliness in mind since the very beginning. I suspect you will
> actually find the main build process more amenable to packaging.
>
> In the main upstream repository (https://github.com/ziglang/zig/), it is
> a standard cmake build that I believe is already Debian-compatible. I am
> guessing you found the zig-bootstrap repository because you wanted to
> avoid depending on a zig binary to build zig; what you may not realize
> is that the main zig repository *does not utilize a zig binary* to be
> built. In fact, the main cmake build process does the following things:
>
>   * Use the system C++ compiler to build zig0 executable using system
> LLVM, LLD, Clang, zlib libraries
>   * Use the freshly built zig0 executable to build zig1.o
>   * Re-link some of the build artifacts, swapping in zig1.o, producing
> the zig binary
>
> I believe this is exactly what a Debian package wants, because you will
> end up with a binary that
>   * Uses the system LLVM, LLD, Clang, zlib libraries
>   * Was built with the system C/C++ compiler and linker
>
> I suggest to try out the main, standard way of building Zig and let me
> know if you run into any trouble. I suspect the main issues will be:
>
>   * deps/SoftFloat-3e is a vendored library. I would be happy to improve
> the cmake build script to enable an option to prefer the system
> SoftFloat library instead.
>
>   * lib/libcxx, lib/libcxxabi, lib/libunwind, lib/tsan and lib/include
> are copy+pasted (MIT-compatibly licensed) from other upstreams, and
> there are quite a few patches and preprocessing which is part of the zig
> development process. I am hoping that Debian can grant zig an exception
> for thes

Bug#995670: ITP: zig -- General-purpose programming language and toolchain for maintaining robust, optimal, and reusable software

[Jason Ernst]

Package: wnpp
Severity: wishlist
Owner: Jason Ernst 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: ziglang
  Version : 0.8.1
  Upstream Author : Andrew Kelley and...@ziglang.org
* URL : https://ziglang.org
* License : MIT
  Programming Lang: Zig
  Description : General-purpose programming language and toolchain for 
maintaining robust, optimal, and reusable software

Zig is quickly become a new hot language, and there is growing demand for it
to be available in mainline repositories.

There is a ticket on the Zig repo: https://github.com/ziglang/zig/issues/7340
which requests for mainline packages to be available, and the upstream
maintainer replied that it is out of scope of their repository. I would like to
volunteer to package this and maintain it so it is available easily. Others are
making similar efforts in other distributions such as Fedora.

I also have a package which pulls the release and packs it using checkinstall
at https://github.com/compscidr/zig-deb which is currently hosted from a 
3rd party gemfury repository.

For now I am happy to maintain myself, but would more than welcome anyone who
would like to form a pkg-zig team (unless people feel there is a more 
appropriate team this could fit into. Co-maintainers are also welcome. I do
need a sponsor, this is my first time participating.

Bug#988461:

[Jason Schindler]

I'm seeing similar errors running `needrestart -v` within a KDE session.  
Similar to the reporter above, this occurs in a fresh session when no software 
has been updated.  In my case, it reports that `user@1000.service` needs to be 
restarted due to a deleted `/memfd:JITCode:QtQml`

---
[main] #2794 uses deleted /memfd:JITCode:QtQml
[main] #2794 is a child of #990
[main] #990 exe => /usr/lib/systemd/systemd
[main] trying systemctl status
[main] #990 is user@1000.service
---

-Jason

Bug#992383: debianutils: which is noisy and doesn't suggest a different option

[Jason Riedy]

I've been using which for decades, including on SunOS and AIX. 
When I know it's a script, less `which foobar` is quick and easy.


None of the alternatives listed do the same thing.

Yes, which has issues, but you're breaking what people have used 
for a very, very long time.



From a bash session:
DEPRECATION
  Since type and command -v were mandated by POSIX, 
  this utility  is  no  longer
  useful for maintainer scripts and thus will be 
  removed from debianutils.


Debian   9 Jul 2021 
WHICH(1)

ejr@signbit:~/kernel/linux$ type ls
ls is aliased to `ls --color=auto --hyperlink=auto'
ejr@signbit:~/kernel/linux$ command -v ls
alias ls='ls --color=auto --hyperlink=auto'
ejr@signbit:~/kernel/linux$ which ls
/usr/bin/which: this version of 'which' is deprecated and should 
not be used.

/usr/bin/ls
ejr@signbit:~/kernel/linux$ whereis ls
ls: /usr/bin/ls /usr/share/man/man1/ls.1.gz
ejr@signbit:~/kernel/linux$ whence ls
bash: whence: command not found
ejr@signbit:~/kernel/linux$ command which ls
/usr/bin/which: this version of 'which' is deprecated and should 
not be used.

/usr/bin/ls
ejr@signbit:~/kernel/linux$ command -v which ls
/usr/bin/which
alias ls='ls --color=auto --hyperlink=auto'

Bug#989406: wireguard-dkms makes little sense with the bullseye kernel

[Jason A. Donenfeld]

Could you close this bug or downgrade its severity, or do whatever it
takes so that this *isn't* removed from bullseye? Removing this
package from the bullseye release would cause large problems.

Bug#989406:

[Jason A. Donenfeld]

Many people run Debian on different kernels. Therefore the dkms remains
useful and should not be removed.

Bug#989377: chromium: keymap changes with xmodmap after chromium launches cause problems

[Jason Woofenden]

Package: chromium
Version: 90.0.4430.212-1
Severity: normal

Dear Maintainer,

Thanks for all your work on packaging chromium, I imagine that this
is a big job!

My keyboard lacks an AltGr key, so I use xmodmap to turn my useless
Menu key into an AltGr like so:

setxkbmap dvorak
xmodmap -e 'keycode 135 = Mode_switch' \
-e 'remove mod5 = Mode_switch'
xmodmap -e 'add mod3 = Mode_switch'

I have a script containing the above lines, though sometimes it's
"us" instead of "dvorak".

This worked well for about 5 years.

I'm not sure if it's the setxkbmap or the xmodmap, but when I run
that script _after_ chromium starts, then chromium starts ignoring
my keybinding for the menu key, and I can no longer type accented
characters, because I get a weird menu instead.

If I close chromium and open it up again, it's fixed (I can again
use that key as Mode_switch) until next time I switch to qwerty and
back (and run those xmodmap commands.)

When chromium is bugging, other programs are functioning correctly,
eg I can still type my accented characters with my menu key
remapped to alt-gr in other programs (I tested lowriter, st, atril,
and filezilla).

Thanks!

  - Jason


-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-7-amd64 (SMP w/8 CPU threads)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii  chromium-common 90.0.4430.212-1
ii  libasound2  1.2.4-1.1
ii  libatk-bridge2.0-0  2.38.0-1
ii  libatk1.0-0 2.36.0-2
ii  libatomic1  10.2.1-6
ii  libatspi2.0-0   2.38.0-4
ii  libavcodec587:4.3.2-0+deb11u1
ii  libavformat58   7:4.3.2-0+deb11u1
ii  libavutil56 7:4.3.2-0+deb11u1
ii  libc6   2.31-12
ii  libcairo2   1.16.0-5
ii  libcups22.3.3op2-3+deb11u1
ii  libdbus-1-3 1.12.20-2
ii  libdrm2 2.4.104-1
ii  libevent-2.1-7  2.1.12-stable-1
ii  libexpat1   2.2.10-2
ii  libflac81.3.3-2
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1
ii  libgbm1 20.3.5-1
ii  libgcc-s1   10.2.1-6
ii  libglib2.0-02.66.8-1
ii  libgtk-3-0  3.24.24-4
ii  libharfbuzz0b   2.7.4-1
ii  libicu6767.1-6
ii  libjpeg62-turbo 1:2.0.6-4
ii  libjsoncpp241.9.4-4
ii  liblcms2-2  2.12~rc1-2
ii  libminizip1 1.1-8+b1
ii  libnspr42:4.29-1
ii  libnss3 2:3.63-1
ii  libopenjp2-72.4.0-3
ii  libopus01.3.1-0.1
ii  libpango-1.0-0  1.46.2-3
ii  libpng16-16 1.6.37-3
ii  libpulse0   14.2-2
ii  libre2-920210201+dfsg-1
ii  libsnappy1v51.1.8-1
ii  libstdc++6  10.2.1-6
ii  libvpx6 1.9.0-1
ii  libwebp60.6.1-2+b1
ii  libwebpdemux2   0.6.1-2+b1
ii  libwebpmux3 0.6.1-2+b1
ii  libx11-62:1.7.1-1
ii  libxcb1 1.14-3
ii  libxcomposite1  1:0.4.5-1
ii  libxdamage1 1:1.1.5-2
ii  libxext62:1.3.3-1.1
ii  libxfixes3  1:5.0.3-2
ii  libxml2 2.9.10+dfsg-6.7
ii  libxrandr2  2:1.5.1-1
ii  libxshmfence1   1.3-1
ii  libxslt1.1  1.1.34-4
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium recommends:
ii  chromium-sandbox  90.0.4430.212-1

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  libc6   2.31-12
ii  libstdc++6  10.2.1-6
ii  libx11-62:1.7.1-1
ii  libxext62:1.3.3-1.1
ii  x11-utils   7.7+5
ii  xdg-utils   1.1.3-4.1
ii  zlib1g  1:1.2.11.dfsg-2

Versions of packages chromium-common recommends:
ii  chromium-sandbox 90.0.4430.212-1
ii  dunst [notification-daemon]  1.5.0-1
ii  fonts-liberation 1:1.07.4-11
ii  libgl1-mesa-dri  20.3.5-1
pn  libu2f-udev  
ii  system-config-printer1.5.14-1
ii  upower   0.99.11-2

Versions of packages chromium-sandbox depends on:
ii  libc6  2.31-12

-- no debconf information

Bug#985189: ITP: et -- Eternal Terminal (ET) is a remote shell that automatically reconnects without interrupting the session.

[Jason Gauci]

I'm fine with changing the name.

On Sun, Mar 14, 2021, 8:44 AM Gard Spreemann  wrote:

>
> Jason Gauci  writes:
>
> >   Package name: et
> >   Version : 6.1.4
> >   Upstream Author : Jason Gauci 
> >   URL : https://eternalterminal.dev/
> >   License : Apache
> >   Programming Lang: C++
> >   Description : Eternal Terminal (ET) is a remote shell that
> automatically reconnects without interrupting the session.
> >
> > Eternal Terminal (ET) is a remote shell that automatically reconnects
> without interrupting the session.
>
> Hi,
>
> Might it be sensible to consider the full name "eternalterminal" (or
> "eternal-terminal") for this package? This would take pressure off the
> two-letter package name space, without giving up much (any?)
> discoverability.
>
>  -- Gard
>
>
>