Bug#1068103: Cannot disable touchpad acceleration after upgrading to GNOME 46

[Josh Triplett]

On Sat, Mar 30, 2024 at 03:24:21PM -0400, Jeremy Bícha wrote:
> On Sat, Mar 30, 2024 at 2:06 PM Josh Triplett  wrote:
> > After upgrading GNOME to 46, the touchpad seems to have some sort of
> > acceleration enabled: it feels like it has a painfully large amount of
> > inertia.
> >
> > I've tried
> > gsettings set org.gnome.desktop.peripherals.touchpad accel-profile flat
> > and that doesn't seem to change anything.
> 
> Please note that 'flat' should be in single quotes.

That doesn't seem to make a difference; libinput still shows the same
thing afterwards.

That said, after upgrading more packages and rebooting, this problem
*seems* to have resolved, insofar as "adaptive" no longer feels like the
cursor is stuck in molasses. So, this can be closed as a transient
issue that an upgrade resolved.

- Josh Triplett

Bug#1068103: Cannot disable touchpad acceleration after upgrading to GNOME 46

[Josh Triplett]

Package: gnome-settings-daemon
Version: 46.0-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

After upgrading GNOME to 46, the touchpad seems to have some sort of
acceleration enabled: it feels like it has a painfully large amount of
inertia.

I've tried
gsettings set org.gnome.desktop.peripherals.touchpad accel-profile flat
and that doesn't seem to change anything.

If I run
libinput list-devices
all three mouse devices show this:
Accel profiles:   flat *adaptive custom




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

Kernel: Linux 6.7.9-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-settings-daemon depends on:
ii  gnome-settings-daemon-common  46.0-1
ii  gsettings-desktop-schemas 46.0-1
ii  libasound2t64 1.2.11-1+b1
ii  libc6 2.37-15.1
ii  libcairo2 1.18.0-1+b1
ii  libcanberra-gtk3-0t64 0.30-12.2+b1
ii  libcanberra0t64   0.30-12.2+b1
ii  libcolord21.4.7-1
ii  libcups2t64   2.4.7-1.2+b1
ii  libfontconfig12.15.0-1
ii  libgck-2-24.2.0-4
ii  libgcr-4-44.2.0-4
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-3+b1
ii  libgeoclue-2-02.7.1-2
ii  libgeocode-glib-2-0   3.26.3-6+b1
ii  libglib2.0-0t64   2.78.4-6
ii  libgnome-desktop-3-20t64  44.0-5
ii  libgtk-3-0t64 3.24.41-4
ii  libgudev-1.0-0238-5
ii  libgweather-4-0t644.4.2-1
ii  libmm-glib0   1.22.0-3+b1
ii  libnm01.46.0-1+b1
ii  libnotify40.8.3-1
ii  libp11-kit0   0.25.3-4
ii  libpam-systemd [logind]   255.4-1+b1
ii  libpango-1.0-01.52.1+ds-1
ii  libpangocairo-1.0-0   1.52.1+ds-1
ii  libpolkit-gobject-1-0 124-2
ii  libpulse-mainloop-glib0   16.1+dfsg1-3
ii  libpulse0 16.1+dfsg1-3
ii  libspa-0.2-bluetooth  1.0.4-3
ii  libsystemd0   255.4-1+b1
ii  libupower-glib3   1.90.2-8+b1
ii  libwacom9 2.9.0-2
ii  libwayland-client01.22.0-2.1+b1
ii  libx11-6  2:1.8.7-1
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  libxi62:1.8.1-1
ii  pipewire-audio1.0.3-1

Versions of packages gnome-settings-daemon recommends:
pn  iio-sensor-proxy   
ii  pipewire-audio 1.0.3-1
ii  pkexec 124-2
ii  x11-xserver-utils  7.7+10

Versions of packages gnome-settings-daemon suggests:
pn  usbguard  

-- no debconf information

Bug#1068097: Please provide a way to open a shell from aptitude

[Josh Triplett]

Package: aptitude
Version: 0.8.13-6
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

Sometimes, when things go horribly wrong in an upgrade (e.g. in the
recent t64 transition if a library disappears and makes dpkg and sudo
and su unrunnable), it would help to have a root shell available. In
such circumstances, sometimes it would avoid the need for a rescue
system if aptitude provided a means of starting a shell.

Thank you.

Bug#1067927: Please display changelog for all versions between current and upgrade

[Josh Triplett]

Package: fwupd
Version: 1.9.14-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

When fwupd proposes upgrading firmware (e.g. BIOS), it shows the
changelog for the target version. However, typically that changelog only
states the changes made in the most recent version. If the user is
upgrading from, say, 1.50 to 1.53, showing the changelog for 1.53 does
not explain the changes in 1.51 and 1.52.

Please consider addressing this by providing a way to view the
changelogs for all the versions in between.


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

Kernel: Linux 6.7.9-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages fwupd depends on:
ii  adduser3.137
ii  libarchive13   3.7.2-1
ii  libc6  2.37-15
ii  libcbor0.100.10.2-1.2
ii  libcurl3-gnutls8.6.0-3
ii  libflashrom1   1.3.0-2.1+b1
ii  libfwupd2  1.9.14-1
ii  libglib2.0-0   2.78.4-1
ii  libgnutls303.8.3-1
ii  libgudev-1.0-0 238-3
ii  libgusb2   0.4.8-1
ii  libjcat1   0.2.0-2
ii  libjson-glib-1.0-0 1.8.0-2
ii  liblzma5   5.6.0-0.2
ii  libmbim-glib4  1.30.0-1
ii  libmbim-proxy  1.30.0-1
ii  libmm-glib01.22.0-3
ii  libpolkit-gobject-1-0  124-1
ii  libprotobuf-c1 1.4.1-1+b1
ii  libqmi-glib5   1.34.0-2
ii  libqmi-proxy   1.34.0-2
ii  libsqlite3-0   3.45.1-1
ii  libsystemd0255.3-2
ii  libtss2-esys-3.0.2-0   4.0.1-7
ii  libxmlb2   0.3.14-2
ii  shared-mime-info   2.4-1
ii  zlib1g 1:1.3.dfsg-3+b1

Versions of packages fwupd recommends:
ii  bolt   0.9.6-2
ii  dbus   1.14.10-4
ii  fwupd-amd64-signed [fwupd-signed]  1:1.4+1
ii  jq 1.7.1-3
ii  python33.11.6-1
pn  secureboot-db  
ii  udisks22.10.1-5

Versions of packages fwupd suggests:
pn  gir1.2-fwupd-2.0  

-- Configuration Files:
/etc/fwupd/fwupd.conf [Errno 13] Permission denied: '/etc/fwupd/fwupd.conf'

-- no debconf information

Bug#1067496: Vertical splits no longer delineated by default

[Josh Triplett]

On Sat, Mar 23, 2024 at 10:15:06AM -0400, James McCoy wrote:
> On Fri, Mar 22, 2024 at 01:42:41PM +0000, Josh Triplett wrote:
> > After upgrading to the new version of neovim, the highlight
> > `WinSeparator` (which links to `VertSplit`) no longer has any visible
> > setting by default. In previous versions, there was an inverse-video bar
> > between windows; now there's only a black bar the same color as normal
> > text background, which makes the windows blend together.
> 
> Do you see the same issue if you run "nvim --clean"?

Ah, that helped track it down. Sorry for the noise; I should have
rechecked with `--clean` before reporting.

It looks like the new version of neovim changed the defaults to use a
vertical bar that *isn't* inverse-video, and I had `vert` overridden in
`fillchars` to a space to rely solely on the inverse-video, so the
combination led to no visible separator. I need to either stop
overriding `vert` or start overriding `WinSeparator`.

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Josh Triplett]

On Sat, Mar 23, 2024 at 12:08:10PM +0800, Sean Whitton wrote:
> Thanks.  For the time being, I myself am not convinced.  Policy is not a
> stick to beat maintainers with, as we say, but I'm not sure that idea is
> one that ought to be in Policy itself.

Having observed many attempts to use Policy as a stick, could you
provide any insight about why you feel there isn't value in writing down
something that's already established to be true but not otherwise
documented? Would another wording or approach help address that better?

Bug#1067496: Vertical splits no longer delineated by default

[Josh Triplett]

Package: neovim
Version: 0.9.5-6
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

After upgrading to the new version of neovim, the highlight
`WinSeparator` (which links to `VertSplit`) no longer has any visible
setting by default. In previous versions, there was an inverse-video bar
between windows; now there's only a black bar the same color as normal
text background, which makes the windows blend together.

I've worked around this by setting `highlight VertSplit cterm=inverse
gui=inverse`, but I think the default should have at least *some*
delineation between split windows.

Thank you.

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

Kernel: Linux 6.7.9-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages neovim depends on:
ii  libc6 2.37-15
ii  libluajit2-5.1-2  2.1-20230410-1
ii  libmsgpackc2  4.0.0-3+b1
ii  libtermkey1   0.22-1
ii  libtree-sitter0   0.20.8-2+b1
ii  libunibilium4 2.1.0-3+b1
ii  libuv1t64 1.48.0-1.1
ii  libvterm0 0.3.3-3
ii  lua-luv   1.48.0-2-2
ii  neovim-runtime0.9.5-6

Versions of packages neovim recommends:
pn  python3-pynvim  
ii  wl-clipboard2.2.1-1
pn  xxd 

Versions of packages neovim suggests:
pn  ctags
ii  vim-scripts  20210124.2

-- no debconf information

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Josh Triplett]

On Mon, Mar 18, 2024 at 05:38:15PM +0800, Sean Whitton wrote:
> Was there some recent packaging situation that prompted you to think
> about this?  I'm cautious about adding it in the absence of that.

Mostly, recent discussions in various places regarding whether packages
are required to use *cron* to run periodic jobs. Policy says what
packages must do if they install a cronjob, but that itself does not
mandate the use of cron specifically. It seemed worth explicitly stating
the understood-but-unwritten interpretation that having Policy about XYZ
does not mandate that packages use XYZ.

I've also seen a few arguments over the decades that amount to "Policy
talks about A, and doesn't talk about B" being used as some amount of
weight towards A or against B.

And finally, I have occasionally seen someone try to build a Debian
package by sitting down with the Policy manual, and start down the route
of trying to supply everything Policy talks about that seems like it
makes sense for the package. The mention of "Policy talking about where
to install info documentation, but that doesn't mean you have to have
info documentation" was not a hypothetical; I've seen that and similar
reasoning a non-zero number of times.

I figured that something like this text would help address all of those.

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Josh Triplett]

Package: debian-policy
Version: 4.6.2.1
Severity: normal
Tags: patch
X-Debbugs-Cc: j...@joshtriplett.org

This proposal adds a paragraph to Policy to explicitly state that having
policy about *how* to use a particular technology or mechanism is not
necessarily policy *requiring* the use of that technology or mechanism.
Policy can explicitly state that packages must use a particular
technology, but having policies *about* that technology does not imply
such a mandate.

For example, having policy about how to install info files does not mean
that packages must provide info files. Having policy about how to ship
cron jobs does not mean that packages must ship cron jobs. (This is
already the standard interpretation, and thus this does not *change*
policy, but rather it clarifies that and avoids misinterpretation.)

Stating this up front can help packagers understand that not all parts
of Policy will apply to them, and that they're not required to use a
particular technology *unless* Policy specifically says that.

I've provided a patch implementing this, but I'm happy to modify the
wording as desired, and will make updates as requested.

This patch is also available on Salsa at:
https://salsa.debian.org/josh/policy/-/tree/no-implicit-requirements

diff --git a/policy/ch-scope.rst b/policy/ch-scope.rst
index a279c26..047cdf8 100644
--- a/policy/ch-scope.rst
+++ b/policy/ch-scope.rst
@@ -25,6 +25,12 @@ Debian policy does not mean that it is not a bug, let alone 
that it is
desirable.  Questions not covered by policy should be evaluated on
their merits.

{+This manual often specifies that if a package wants to use a particular+}
{+technology or mechanism, it must/should meet specific requirements when+}
{+doing so. The inclusion of such requirements in this manual does not+}
{+require the use of that particular technology or mechanism, unless this+}
{+manual explicitly includes a requirement to that effect.+}

The footnotes present in this manual are merely informative, and are not
part of Debian policy itself.

Bug#1065569: Please reduce Recommends on uuid-runtime to Suggests

[Josh Triplett]

Package: util-linux
Version: 2.39.3-6
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

libuuid1/libuuid1t64 currrently Recommends uuid-runtime.

As I understand it, uuid-runtime is primarily used when generating a
huge number of UUIDs very rapidly on a system, and wanting to ensure
that they can efficiently be generated uniquely.

Recommends is supposed to be used for cases of "packages that would be
found together with this one in all but unusual installations."

I think it's safe to say that it isn't just "unusual installations" that
can do without uuid-runtime; *needing* uuid-runtime is the uncommon
case. And in addition, today we do not install uuid-runtime when
bootstrapping a system (because some part of bootstrapping doesn't
look at Recommends), so many systems end up with libuuid1 without
uuid-runtime, without issue.

I would propose that the relationship on uuid-runtime become a
"Suggests": "This is used to declare that one package may be more useful
with one or more others. Using this field tells the packaging system and
the user that the listed packages are related to this one and can
perhaps enhance its usefulness, but that installing this one without
them is perfectly reasonable."

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

Kernel: Linux 6.6.15-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages util-linux depends on:
ii  libblkid1  2.39.3-6
ii  libc6  2.37-15
ii  libcap-ng0 0.8.4-2
ii  libcrypt1  1:4.4.36-4
ii  libmount1  2.39.3-6
ii  libpam0g   1.5.2-9.1+b1
ii  libselinux13.5-2
ii  libsmartcols1  2.39.3-6
ii  libsystemd0255.3-2
ii  libtinfo6  6.4+20240113-1
ii  libudev1   255.3-2
ii  libuuid1   2.39.3-6
ii  zlib1g 1:1.3.dfsg-3+b1

Versions of packages util-linux recommends:
ii  sensible-utils  0.0.22

Versions of packages util-linux suggests:
ii  dosfstools  4.2-1
pn  kbd 
pn  util-linux-extra
pn  util-linux-locales  

-- no debconf information

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

[Josh Triplett]

Sean Whitton wrote:
> On Sun 17 Sep 2023 at 10:52am -07, Russ Allbery wrote:
> > So far as I can tell, the only important part is that the directory
> > be registered in tmpfiles.d (or a service unit) so that it can be
> > recreated when needed.
>
> Something which I don't think has been mentioned yet is that we
> explicitly permit the local administrator to nuke /usr/share/doc, even
> though that is a similar sort of inconsistency between the dpkg db and
> the filesystem as the ones that are bothering Luca.

One key difference between the two is the existence of Policy 12.3:
> Packages must not require the existence of any files in
> "/usr/share/doc/" in order to function.  [6] Any files that are used
> or read by programs but are also useful as stand alone documentation
> should be installed elsewhere, such as under "/usr/share/package/",
> and then included via symbolic links in "/usr/share/doc/package".

Bug#1062653: gnome-network-displays crashes ("Trace/breakpoint trap") if local display selection cancelled

[Josh Triplett]

Package: gnome-network-displays
Version: 0.92.1-2
Severity: important
X-Debbugs-Cc: j...@joshtriplett.org

Steps to reproduce:

- Open gnome-network-displays
- Hit cancel on the prompt for whether to cast the whole screen, a
  window, or a virtual monitor
- Select a display to cast to
- gnome-network-displays crashes with "Trace/breakpoint trap"

Log messages:

(gnome-network-displays:9669): libportal-CRITICAL **: 01:04:19.778: 
xdp_session_get_streams: assertion 'XDP_IS_SESSION (session)' failed
(gnome-network-displays:9669): Gnd-ERROR **: 01:04:19.778: XDP session streams 
not found!


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

Kernel: Linux 6.6.13-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-network-displays depends on:
ii  libadwaita-1-0  1.4.2-1+b1
ii  libavahi-common30.8-13+b1
ii  libavahi-gobject0   0.8-13+b1
ii  libc6   2.37-15
ii  libglib2.0-02.78.3-2
ii  libgstreamer-plugins-base1.0-0  1.22.8-1
ii  libgstreamer1.0-0   1.22.9-1+b1
ii  libgstrtspserver-1.0-0  1.22.8-1
ii  libgtk-4-1  4.12.5+ds-2
ii  libjson-glib-1.0-0  1.8.0-2
ii  libnm0  1.44.2-7
ii  libportal-gtk4-10.7.1-5
ii  libportal1  0.7.1-5
ii  libprotobuf-c1  1.4.1-1+b1
ii  libpulse-mainloop-glib0 16.1+dfsg1-3
ii  libpulse0   16.1+dfsg1-3
ii  libsoup-3.0-0   3.4.4-5
ii  network-manager 1.44.2-7
ii  wpasupplicant   2:2.10-21

gnome-network-displays recommends no packages.

gnome-network-displays suggests no packages.

-- no debconf information

Bug#1062205: Crashes desktop when attempting to make a network display

[Josh Triplett]

On Wed, Jan 31, 2024 at 08:23:22PM -0500, Jeremy Bícha wrote:
> On Wed, Jan 31, 2024 at 12:39 PM Josh Triplett  wrote:
> > I've attempted to use gnome-network-displays a few times, creating a
> > virtual display and sharing that display on a Chromecast on the local
> > network. When doing so, the entire GNOME desktop crashes, dropping me
> > into GDM to log back in.
> 
> I am uploading gnome-network-displays 0.92.1-1 now so try the new
> version. Both this version and the version you tried worked for me
> using the Chromecast protocol. Could you try to provide a bit more
> information?
> 
> What version of GNOME Shell are you using?

44.8-1

> Are you using X or Wayland?

Wayland.

> Is there anything unusual about your system you should mention?

Nothing that I can think of. Tested with latest sid as of today.

> If you are using Shell extensions, have you tried without them?

No, I'm not running any extensions.

> Does it still crash if you try while logged in as a new user?

Yes.

> Try looking through your systemd log with journatlctl to see if there
> are related errors.

I tried with the newly uploaded version, and managed to get some further
information.

Attempting to cast a window, or the whole screen, appears to work now,
but with 8-10 seconds of lag, making it unusable. (I'll report that as a
separate bug.)

Attempting to cast a virtual monitor still causes a crash. Here are logs
from that attempt:

Feb 02 00:28:36 o gnome-shell[1083]: Added virtual monitor Meta-0
...
Feb 02 00:28:37 o kernel: gnome-shell[1083]: segfault at 20 ip 7fececdf8f04 
sp 7ffc5ad85ed8 error 4 in 
libmutter-clutter-12.so.0.0.0[7fececda5000+9] likely on CPU 3 (core 4, 
socket 0)
Feb 02 00:28:37 o kernel: Code: c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 
d2 7e 05 00 48 8d 3d 4e f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa 
<48> 8b 47 20 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f

Bug#1062652: Lags by 8-10 seconds

[Josh Triplett]

Package: gnome-network-displays
Version: 0.92.1-2
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

When casting either a window or the entire screen to a Chromecast, the
display on the Chromecast lags by 8-10 seconds behind the local display,
making it unusable for any interactive purposes. Concretely, moving the
mouse or typing in a terminal became visible 8-10 seconds later.


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

Kernel: Linux 6.6.13-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-network-displays depends on:
ii  libadwaita-1-0  1.4.2-1+b1
ii  libavahi-common30.8-13+b1
ii  libavahi-gobject0   0.8-13+b1
ii  libc6   2.37-15
ii  libglib2.0-02.78.3-2
ii  libgstreamer-plugins-base1.0-0  1.22.8-1
ii  libgstreamer1.0-0   1.22.9-1+b1
ii  libgstrtspserver-1.0-0  1.22.8-1
ii  libgtk-4-1  4.12.5+ds-2
ii  libjson-glib-1.0-0  1.8.0-2
ii  libnm0  1.44.2-7
ii  libportal-gtk4-10.7.1-5
ii  libportal1  0.7.1-5
ii  libprotobuf-c1  1.4.1-1+b1
ii  libpulse-mainloop-glib0 16.1+dfsg1-3
ii  libpulse0   16.1+dfsg1-3
ii  libsoup-3.0-0   3.4.4-5
ii  network-manager 1.44.2-7
ii  wpasupplicant   2:2.10-21

gnome-network-displays recommends no packages.

gnome-network-displays suggests no packages.

-- no debconf information

Bug#1062205: Crashes desktop when attempting to make a network display

[Josh Triplett]

Package: gnome-network-displays
Version: 0.91.0-1
Severity: important
X-Debbugs-Cc: j...@joshtriplett.org

I've attempted to use gnome-network-displays a few times, creating a
virtual display and sharing that display on a Chromecast on the local
network. When doing so, the entire GNOME desktop crashes, dropping me
into GDM to log back in.

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

Kernel: Linux 6.6.13-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-network-displays depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-4+b1
ii  libavahi-common3 0.8-13+b1
ii  libavahi-gobject00.8-13+b1
ii  libc62.37-14
ii  libglib2.0-0 2.78.3-2
ii  libgstreamer-plugins-base1.0-0   1.22.8-1
ii  libgstreamer1.0-01.22.8-1
ii  libgstrtspserver-1.0-0   1.22.8-1
ii  libgtk-3-0   3.24.40-2
ii  libjson-glib-1.0-0   1.8.0-2
ii  libnm0   1.44.2-7
ii  libprotobuf-c1   1.4.1-1+b1
ii  libpulse-mainloop-glib0  16.1+dfsg1-3
ii  libpulse016.1+dfsg1-3
ii  libsoup-3.0-03.4.4-5
ii  network-manager  1.44.2-7
ii  wpasupplicant2:2.10-21

gnome-network-displays recommends no packages.

gnome-network-displays suggests no packages.

-- no debconf information

Bug#1061480: debconf should automatically be noninteractive if input is /dev/null

[Josh Triplett]

Package: debconf
Version: 1.5.84
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

I'm building a system for remotely running noninteractive commands. That
system lets people run commands like `apt-get install xyz` to install
packages, but it by design has no specific knowledge of any software
like apt or dpkg (and thus *cannot* set things like
DEBIAN_FRONTEND=noninteractive for the user).

I run commands with stdout/stderr connected to a socket, and stdin
connected to /dev/null, since all commands are non-interactive and can
receive no input. Generally, this results in software noticing that it
cannot get input, and handling that.

In a recent attempt to install a package, tzdata got pulled in as a
dependency, resulting in this:

```
Setting up tzdata (2021a-1+deb11u11) ...
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
Configuring tzdata
--

Please select the geographic area in which you live. Subsequent configuration
questions will narrow this down by presenting a list of cities, representing
the time zones in which they are located.

  1. Africa   3. Antarctica  5. Arctic  7. Atlantic  9. Indian11. US
  2. America  4. Australia   6. Asia8. Europe10. Pacific  12. Etc
```

And then the command hung, fruitlessly attempting to wait for input that
will never arrive.

debconf should detect if reading from stdin produces EOF (a zero-byte
read, e.g. because it's /dev/null), and automatically switch to a
noninteractive mode, rather than hanging.

(In an ideal world, I'd also say that debconf should do this anytime its
stdin is not a tty and it doesn't explicitly have a non-tty-requiring
frontend set, rather than falling back to "readline" on a non-terminal,
but I understand if this is historical behavior that'd be difficult to
change for compatibility reasons. Dealing with EOF on stdin better would
be the next best thing.)


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

Kernel: Linux 6.6.11-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

debconf depends on no packages.

Versions of packages debconf recommends:
ii  apt-utils 2.7.10
pn  debconf-i18n  

Versions of packages debconf suggests:
pn  debconf-doc
pn  debconf-kde-helper 
pn  debconf-utils  
ii  libgtk3-perl   0.038-3
pn  libnet-ldap-perl   
pn  libterm-readline-gnu-perl  
ii  perl   5.38.2-3
ii  whiptail   0.52.24-2

-- debconf information excluded

Bug#1060181: Please consider supporting configuration via both /usr/share/apt/verify.d and /etc/apt/verify.d

[Josh Triplett]

On Mon, 08 Jan 2024 10:30:02 +0100 Simon Josefsson  wrote:
> Josh Triplett  writes:
> > Many tools that use .d configuration directories support multiple such
> > directories, to make it easy to separate local sysadmin configuration
> > from distribution configuration. For instance, a hypothetical
> > apt-verify-myplugin package could install
> > /usr/share/apt/verify.d/50myplugin so that it automatically works when
> > installed, and then the sysadmin could change that with
> > /etc/apt/verify.d/50myplugin . One of several advantages of this is that
> > a sysadmin can, themselves, *package* their configuration very easily,
> > without having to divert files or similar.
> 
> Thanks for feedback -- this makes sense, and I've opened an upstream bug
> about it:
> 
> https://gitlab.com/debdistutils/apt-verify/-/issues/6
> 
> What do you think about processing identically named scripts in both
> paths vs only the /etc/ script?

Replied there: Having identically named files in /etc override the ones
in /usr/share is exactly what I had in mind; I should have been more
explicit about that.

> > (Also, in the process of this, you might consider refusing to run if no
> > configuration exists, to avoid effectively disabling verification. If a
> > user really wants to *disable* verification they should use the apt
> > configuration for *that* rather than installing apt-verify as a hook and
> > then giving apt-verify nothing to do.)
> 
> There is no way verification can be disabled -- apt will yell.  Or can
> you explain more what you mean?

Just dug into apt-verify's documentation more, and realized that apt is
checking gpgv output rather than exit code, so this isn't actually a
concern. Nevermind then.

If, at some point in the future, apt adds a verification mechanism that
uses exit codes rather than the output of GPG, then it'd be important to
make sure that an empty .d directory or one where all the scripts have
been masked by empty ones (or symlinks to /dev/null) in /etc causes a
failure.

Bug#1060465: gnome-control-center: crashes loading System panel if gnome-remote-desktop is missing

[Josh Triplett]

On Thu, 11 Jan 2024 18:00:58 -0500 =?UTF-8?Q?Jeremy_B=C3=ADcha?= 
 wrote:
> On Thu, Jan 11, 2024 at 5:27 PM Arnaud Ferraris  wrote:
> > Package: gnome-control-center
> > Version: 1:46~alpha-1
> …
> >
> > On a system without gnome-remote-desktop, trying to access the "System" 
> > panel
> > (containing the "Users", "Date & Time" panels among other important things)
> > results in a crash with the following message:
> >
> >   GLib-GIO[25147]: ERROR: Settings schema 'org.gnome.desktop.remote-
> > desktop.rdp' is not installed
> >
> > I believe either g-c-c should handle the lack of gnome-remote-desktop more
> > gracefully, or the latter should be promoted to Depends instead of 
> > Recommends.
> 
> Ok, I'll promote gnome-remote-desktop to Depends again.
> 
> Josh, I remember you complained about this dependency in
> https://bugs.debian.org/1014879
> 
> GNOME Remote Desktop is going to be more tightly entwined in GNOME 46
> to support the new integrated "headless" mode allowing remote access
> even when the user is not already logged into the host computer. It
> doesn't feel feasible to me to make this dependency optional because
> of the integration in gnome-session, gdm3, gnome-settings-daemon, and
> as a separate page in gnome-control-center.

I appreciate that, and I understand.

I do continue to feel that having gnome-remote-desktop installed and
*enabled* by default feels risky in a similar way to having an installed
sshd on a system that shouldn't be remotely accessed. But, of course, we
cannot have settings pages crashing, either.

For the "headless" mode, would it be possible to confirm that it isn't
enabled by default, that nothing is running if it *isn't* enabled, and
that it requires administrator permissions to enable? (e.g. enabling the
requisite setting should require a policykit prompt.)

For the per-user version, would it be possible to similarly confirm that
it isn't enabled by default, and thus there's *no* remote socket
connection without it first being explicitly enabled, not even a
socket-activateable connection?

Bug#1060181: Please consider supporting configuration via both /usr/share/apt/verify.d and /etc/apt/verify.d

[Josh Triplett]

Package: apt-verify
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

Many tools that use .d configuration directories support multiple such
directories, to make it easy to separate local sysadmin configuration
from distribution configuration. For instance, a hypothetical
apt-verify-myplugin package could install
/usr/share/apt/verify.d/50myplugin so that it automatically works when
installed, and then the sysadmin could change that with
/etc/apt/verify.d/50myplugin . One of several advantages of this is that
a sysadmin can, themselves, *package* their configuration very easily,
without having to divert files or similar.

(Also, in the process of this, you might consider refusing to run if no
configuration exists, to avoid effectively disabling verification. If a
user really wants to *disable* verification they should use the apt
configuration for *that* rather than installing apt-verify as a hook and
then giving apt-verify nothing to do.)


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

Kernel: Linux 6.6.8-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1037113: Patch implementing this

[Josh Triplett]

tags 1037113 + patch
thanks

Submitted an MR on Salsa implementing this:
https://salsa.debian.org/debian/sm/-/merge_requests/3

Bug#1057100: --tab no longer opens in last-opened window

[Josh Triplett]

Package: gnome-terminal
Version: 3.50.1-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

`gnome-terminal --help-all` says:

> --tab   Open a new tab in the last-opened window with 
> the default profile

This used to work; `gnome-terminal --tab` would open a tab in the
last-opened window. However, it no longer works except when launched
from the terminal in question. If you use `gnome-terminal --tab` from
the Run dialog (Alt+F2), or from a keyboard shortcut, it now opens a new
window, rather than a tab in the existing window.


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

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

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.14.10-3
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-4
ii  gnome-terminal-data   3.50.1-1
ii  gsettings-desktop-schemas 45.0-2
ii  libatk1.0-0   2.50.0-1
ii  libc6 2.37-12
ii  libgcc-s1 13.2.0-7
ii  libglib2.0-0  2.78.1-4
ii  libgtk-3-03.24.38-6
ii  libhandy-1-0  1.8.2-3
ii  libpango-1.0-01.51.0+ds-3
ii  libstdc++613.2.0-7
ii  libuuid1  2.39.2-6
ii  libvte-2.91-0 0.74.1-1
ii  libx11-6  2:1.8.7-1

Versions of packages gnome-terminal recommends:
ii  gvfs   1.52.1-1
pn  nautilus-extension-gnome-terminal  
ii  yelp   42.2-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#1054632: Single-line description continues into extended description

[Josh Triplett]

Package: filtermail
Version: 1.04.00-1+b1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

Policy 3.4.2, "The extended description":
> Do not try to continue the single line synopsis into the extended
> description. This will not work correctly when the full description is
> displayed, and makes no sense where only the summary (the single line
> synopsis) is available.



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

Kernel: Linux 6.5.0-3-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages filtermail depends on:
pn  libbobcat6  
ii  libc6   2.37-12
ii  libgcc-s1   13.2.0-5
ii  libstdc++6  13.2.0-5
ii  whois   5.5.19

filtermail recommends no packages.

filtermail suggests no packages.

Bug#1054333: Please either provide nftables-bin package or make service conditional

[Josh Triplett]

Package: nftables
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

There are two potential reasons to install the nftables package: to have
it run at boot time, or to run the nft tool manually. If only doing the
latter and not the former, the service is not necessarily desirable.

Please consider either:

- shipping an nftables-bin package that just provides nft but not the
  system service, or

- making the systemd unit use ConditionPathExists=/etc/nftables.conf ,
  so that it does nothing if the script does not exist, and then
  removing the default configuration file and shipping it as an example
  in /usr/share/doc/nftables.

The latter seems easier. This would make it easy to install nftables and
use nft without changing anything about system boot, and then still
easily create /etc/nftables.conf and have it work automatically.

Thank you.

Bug#1053660: Please remove legacy /etc/bash_completion.d/git-prompt

[Josh Triplett]

Package: git
Version: 1:2.42.0-1
Severity: normal
File: /etc/bash_completion.d/git-prompt
X-Debbugs-Cc: j...@joshtriplett.org

/etc/bash_completion.d/git-prompt exists for compatibility with versions
of git prior to git 1.7.12, which is well over a decade old at this
point. Please consider dropping it, with a NEWS.Debian.gz entry telling
people to update their shell startup files to reference or copy
/usr/lib/git-core/git-sh-prompt directly.


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

Kernel: Linux 6.5.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages git depends on:
ii  git-man  1:2.42.0-1
ii  libc62.37-12
ii  libcurl3-gnutls  8.3.0-2
ii  liberror-perl0.17029-2
ii  libexpat12.5.0-2
ii  libpcre2-8-0 10.42-4
ii  perl 5.36.0-9
ii  zlib1g   1:1.2.13.dfsg-3

Versions of packages git recommends:
ii  ca-certificates  20230311
ii  less 590-2
ii  openssh-client [ssh-client]  1:9.4p1-1
ii  patch2.7.6-7

Versions of packages git suggests:
ii  gettext-base  0.21-13+b1
pn  git-cvs   
pn  git-daemon-run | git-daemon-sysvinit  
pn  git-doc   
pn  git-email 
pn  git-gui   
pn  git-mediawiki 
pn  git-svn   
ii  gitk  1:2.42.0-1
pn  gitweb

-- no debconf information

Bug#567033: Decide if we should continue recommending /usr/games

[Josh Triplett]

On Mon, Sep 11, 2023 at 07:11:30PM +0100, Simon McVittie wrote:
> Games are often written for performance more than correctness, and
> frequently do non-ideal things or have unfixed security issues. If we
> separate them into /usr/games and avoid putting that directory in root's
> PATH, then tab completion mistakes can't result in root accidentally
> running a game.
> 
> Similarly, I think (although I have no evidence) it's more common to
> install non-free games, and non-free game managers like Steam, than
> non-free utility/application software. If we put those in /usr/games, the
> root can't accidentally run those as a result of a tab-completion mistake.

Doing this by PATH alone seems of relatively limited value in a world in
which:
- Many (possibly *most*) users don't typically *log in* as root
  directly, and use something like sudo to explicitly run things as root
  instead, outside of recovery scenarios. And it seems fairly unlikely
  to explicitly "sudo somegame".
- Many non-text-based games may be launched from a GUI. And the
  text-based games seem unlikely to have massive unfixed security
  issues that arise just from *invocation*.
- On the average single-user system, most of the value is in the user's
  data *in their account*, and if something had a security issue
  allowing remote access, it'd likely be trivial to escalate to root
  anyway by any number of means, since that user ultimately has root
  access. If we have games with unfixed security issues, those need
  fixing (or sandboxing) *anyway* and putting them in /usr/games doesn't
  seem like a substantive mitigation.

Bug#1038994: Upgrading systemd stopped GNOME session

[Josh Triplett]

On Tue, Aug 22, 2023 at 11:19:56AM +0200, Michael Biebl wrote:
> Control: tags -1 + moreinfo unreproducible
> 
> Hi Josh
> 
> Am 24.06.23 um 10:03 schrieb Josh Triplett:
> > Package: systemd
> > I'm not entirely sure which package this bug belongs to, but it happened
> > when upgrading systemd, and systemd is my best guess here. Please feel
> > free to reassign.
> > 
> > When upgrading to systemd 253-3, my GNOME session restarted. From the
> > logs:
> 
> ...
> 
> I distupgraded a test-vm running GNOME/Wayland from bookworm to trixie but
> couldn't trigger the failure.
> 
> Can you still reproduce the issue? And if so, provide steps how we can
> reproduce it ourselves?

I can give you the exact set of package upgrades performed in the same
run, which might help:

===

Aptitude 0.8.13: log report
Sat, Jun 24 2023 00:19:49 -0700

  IMPORTANT: this log only lists intended actions; actions which fail
  due to dpkg problems may not be completed.

Will install 115 packages, and remove 1 packages.
906 kB of disk space will be used

[REMOVE, NOT USED] libmujs2:amd64 1.3.2-1
[INSTALL, DEPENDENCIES] fonts-liberation:amd64 1:2.1.5-2
[INSTALL, DEPENDENCIES] libmujs3:amd64 1.3.3-1+b1
[INSTALL, DEPENDENCIES] systemd-dev:amd64 253-3
[UPGRADE] bind9-dnsutils:amd64 1:9.18.13-1 -> 1:9.18.16-1
[UPGRADE] bind9-host:amd64 1:9.18.13-1 -> 1:9.18.16-1
[UPGRADE] bind9-libs:amd64 1:9.18.13-1 -> 1:9.18.16-1
[UPGRADE] binutils:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1
[UPGRADE] binutils-aarch64-linux-gnu:amd64 2.40.50.20230611-2 -> 
2.40.50.20230622-1
[UPGRADE] binutils-common:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1
[UPGRADE] binutils-multiarch:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1
[UPGRADE] binutils-x86-64-linux-gnu:amd64 2.40.50.20230611-2 -> 
2.40.50.20230622-1
[UPGRADE] build-essential:amd64 12.9 -> 12.10
[UPGRADE] coinor-libcbc3:amd64 2.10.8+ds1-1 -> 2.10.10+ds1-1
[UPGRADE] cpp:amd64 4:12.2.0-3 -> 4:12.3.0-1
[UPGRADE] cpp-aarch64-linux-gnu:amd64 4:12.2.0-3 -> 4:12.3.0-1
[UPGRADE] crossbuild-essential-arm64:amd64 12.9 -> 12.10
[UPGRADE] cups:amd64 2.4.2-4 -> 2.4.2-5
[UPGRADE] cups-bsd:amd64 2.4.2-4 -> 2.4.2-5
[UPGRADE] cups-client:amd64 2.4.2-4 -> 2.4.2-5
[UPGRADE] cups-common:amd64 2.4.2-4 -> 2.4.2-5
[UPGRADE] cups-core-drivers:amd64 2.4.2-4 -> 2.4.2-5
[UPGRADE] cups-daemon:amd64 2.4.2-4 -> 2.4.2-5
[UPGRADE] cups-ipp-utils:amd64 2.4.2-4 -> 2.4.2-5
[UPGRADE] cups-ppdc:amd64 2.4.2-4 -> 2.4.2-5
[UPGRADE] cups-server-common:amd64 2.4.2-4 -> 2.4.2-5
[UPGRADE] dash:amd64 0.5.12-5 -> 0.5.12-6
[UPGRADE] enscript:amd64 1.6.5.90-3+b1 -> 1.6.5.90-3.1
[UPGRADE] fonts-liberation2:amd64 2.1.5-1 -> 1:2.1.5-2
[UPGRADE] g++:amd64 4:12.2.0-3 -> 4:12.3.0-1
[UPGRADE] g++-aarch64-linux-gnu:amd64 4:12.2.0-3 -> 4:12.3.0-1
[UPGRADE] gcc:amd64 4:12.2.0-3 -> 4:12.3.0-1
[UPGRADE] gcc-aarch64-linux-gnu:amd64 4:12.2.0-3 -> 4:12.3.0-1
[UPGRADE] ghostscript:amd64 10.0.0~dfsg-11 -> 10.01.2~dfsg-1
[UPGRADE] gvfs:amd64 1.50.4-2 -> 1.50.4-3
[UPGRADE] gvfs-backends:amd64 1.50.4-2 -> 1.50.4-3
[UPGRADE] gvfs-common:amd64 1.50.4-2 -> 1.50.4-3
[UPGRADE] gvfs-daemons:amd64 1.50.4-2 -> 1.50.4-3
[UPGRADE] gvfs-fuse:amd64 1.50.4-2 -> 1.50.4-3
[UPGRADE] gvfs-libs:amd64 1.50.4-2 -> 1.50.4-3
[UPGRADE] libaom3:amd64 3.6.0-1 -> 3.6.1-1
[UPGRADE] libbinutils:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1
[UPGRADE] libboost-filesystem1.74.0:amd64 1.74.0+ds1-21 -> 1.74.0+ds1-21.1
[UPGRADE] libboost-iostreams1.74.0:amd64 1.74.0+ds1-21 -> 1.74.0+ds1-21.1
[UPGRADE] libboost-locale1.74.0:amd64 1.74.0+ds1-21 -> 1.74.0+ds1-21.1
[UPGRADE] libboost-regex1.74.0:amd64 1.74.0+ds1-21 -> 1.74.0+ds1-21.1
[UPGRADE] libboost-thread1.74.0:amd64 1.74.0+ds1-21 -> 1.74.0+ds1-21.1
[UPGRADE] libctf-nobfd0:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1
[UPGRADE] libctf0:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1
[UPGRADE] libcups2:amd64 2.4.2-4 -> 2.4.2-5
[UPGRADE] libcupsimage2:amd64 2.4.2-4 -> 2.4.2-5
[UPGRADE] libdata-optlist-perl:amd64 0.113-1 -> 0.114-1
[UPGRADE] libde265-0:amd64 1.0.11-1 -> 1.0.12-1
[UPGRADE] libdrm-amdgpu1:amd64 2.4.114-1+b1 -> 2.4.115-1
[UPGRADE] libdrm-common:amd64 2.4.114-1 -> 2.4.115-1
[UPGRADE] libdrm-intel1:amd64 2.4.114-1+b1 -> 2.4.115-1
[UPGRADE] libdrm-nouveau2:amd64 2.4.114-1+b1 -> 2.4.115-1
[UPGRADE] libdrm-radeon1:amd64 2.4.114-1+b1 -> 2.4.115-1
[UPGRADE] libdrm2:amd64 2.4.114-1+b1 -> 2.4.115-1
[UPGRADE] libfribidi0:amd64 1.0.13-2 -> 1.0.13-3
[UPGRADE] libgprofng0:amd64 2.40.50.20230611-2 -> 2.40.50.20230622-1
[UPGRADE] libgs-common:amd64 10.0.0~dfsg-11 -> 10.01.2~dfsg-1
[UPGRADE] libgs10:amd64 10.0.0~dfsg-11 -> 10.01.2~dfsg-1
[UPGRADE] libgs10-common:amd64 10.0.0~dfsg-11

Bug#1049932: make: Leaves --jobserver-auth for pipe in MAKEFLAGS when invoking command without +

[Josh Triplett]

Package: make
Version: 4.3-4.1
Severity: normal
Tags: upstream
X-Debbugs-Cc: j...@joshtriplett.org

When make invokes a command without `+` set, it closes the jobserver fds
in that child, but it leaves the --jobserver-auth option set in
MAKEFLAGS pointing to non-existent fds:

/tmp$ cat Makefile
all:
env | grep jobserver || true ; ls /proc/self/fd
+env | grep jobserver || true ; ls /proc/self/fd
/tmp$ make -j12
env | grep jobserver || true ; ls /proc/self/fd
MAKEFLAGS= -j12 --jobserver-auth=3,4
MFLAGS=-j12 --jobserver-auth=3,4
0  1  2  3
env | grep jobserver || true ; ls /proc/self/fd
MAKEFLAGS= -j12 --jobserver-auth=3,4
MFLAGS=-j12 --jobserver-auth=3,4
0  1  2  3  4  5

When the invoked command opens a file descriptor, that file descriptor
may then overlap with the referenced jobserver fds. If the invoked
command then subsequently attempted to access the jobserver, it'd
operate on the wrong fd, potentially causing random havoc with the fd
open in that spot.

Removing this flag would also remove the ability of make to notice and
emit a warning ("warning: jobserver unavailable: using -j1. Add '+' to
parent make rule."). However, in the absence of this issue, that warning
would purely be a missed optimization, not a semantic issue. And
optionally, to retain the ability to warn about the missed optimization,
make could change MAKEFLAGS in non-+ rules to pass --jobserver-warn
(without fd numbers), telling make (or any jobserver-capable program) to
emit such a warning about using + without leaving open the possibility
of trying to use the wrong fd as a jobserver.

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

Kernel: Linux 6.3.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages make depends on:
ii  libc6  2.37-7

make recommends no packages.

Versions of packages make suggests:
pn  make-doc  

-- no debconf information

Bug#1042543: Known upstream regression in 6.4: audio distortion on ThinkPad X1 Gen 11

[Josh Triplett]

Package: src:linux
Version: 6.4.4-1
Severity: important
Tags: upstream
X-Debbugs-Cc: j...@joshtriplett.org

See https://github.com/thesofproject/linux/issues/4482 and
https://bugzilla.kernel.org/show_bug.cgi?id=217673 for the bug, and
https://github.com/thesofproject/linux/pull/4484 for the fix.

I can confirm that 6.4 has intermittent audio distortion on my system,
and 6.3 does not.

Please consider applying the fix.

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

Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-6.4.0-1-amd64 depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.142
ii  kmod30+20230519-1
ii  linux-base  4.9

Versions of packages linux-image-6.4.0-1-amd64 recommends:
pn  apparmor 
ii  firmware-linux-free  20200122-1

Versions of packages linux-image-6.4.0-1-amd64 suggests:
pn  debian-kernel-handbook  
ii  extlinux3:6.04~git20190206.bf6db5b4+dfsg1-3+b1
ii  grub-efi-amd64  2.06-13
pn  linux-doc-6.4   

Versions of packages linux-image-6.4.0-1-amd64 is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
ii  firmware-iwlwifi  20230515-3
pn  firmware-libertas 
pn  firmware-linux-nonfree
ii  firmware-misc-nonfree 20230515-3
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
ii  firmware-realtek  20230515-3
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#1041559: Recommends non-existent package linux-musl-dev

[Josh Triplett]

Package: musl-dev
Version: 1.2.3-1
Severity: serious
X-Debbugs-Cc: j...@joshtriplett.org

musl-dev Recommends linux-musl-dev, which does not appear to exist in
the archive.

Policy 2.2.1 "The main archive area":
> package must not declare a "Pre-Depends", "Depends", "Recommends",
> "Build-Depends", "Build-Depends-Indep", or "Build-Depends-Arch"
> relationship on a non-*main* package unless that package is only
> listed as a non-default alternative for a package in *main*



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

Kernel: Linux 6.3.0-2-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages musl-dev depends on:
ii  gcc [gcc-x86-64-linux-gnu]  4:13.1.0-4
ii  musl1.2.3-1

Versions of packages musl-dev recommends:
pn  linux-musl-dev  

musl-dev suggests no packages.

-- no debconf information

Bug#1040908: [Pkg-utopia-maintainers] Bug#1040908: Please don't depend on mdadm

[Josh Triplett]

On Wed, 12 Jul 2023 13:14:47 +0200 Michael Biebl  wrote:
> Am 12.07.23 um 11:14 schrieb Josh Triplett:
> > Package: libblockdev-mdraid3
> > Version: 3.0.1-1
> > Severity: normal
> > X-Debbugs-Cc: j...@joshtriplett.org
> > 
> > Current udisks2 has a dependency on libblockdev-mdraid3, and
> > libblockdev-mdraid3 has a dependency on mdadm. This effectively makes
> > mdadm required on desktop systems.
> > 
> > As I understand it from
> > https://github.com/storaged-project/udisks/issues/1142 , udisks2 needs
> > to depend on libblockdev-mdraid3. (And that much isn't necessarily an
> > issue, it's just a library.)
> > 
> > Would it be possible for libblockdev-mdraid3 to avoid pulling in mdadm,
> 
> By avoid, I assume you mean not even demoting it to Recommends would be 
> an option for you, but drop the dependency completely (or make it a 
> Suggests)

I was hoping for a Suggests, yes. Using Recommends would still leave
this as an issue for most desktop systems, and would contribute to the
reasons why some people disable Recommends by default and just
selectively install Recommends when installing packages.

> > so that systems not using RAID don't have to have mdadm and its
> > associated configuration and boot-time logic installed?
> 
> And then I'll get bug reports like
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=989493

My understanding was that that error happens *unconditionally* whether
there's a RAID device on the system or not, and that that bug is fixed
by depending on libblockdev-mdraid3 (which seems fine). But if I'm
understanding the upstream issue correctly, libblockdev-mdraid3 doesn't
actually need the mdadm binary *unless* the user's system actually has a
RAID device on it, in which case they would more likely want to have
mdadm installed. So, I *think* removing the Depends on mdadm would mean
that the only users getting an error message are those who have a RAID
device and *don't* have mdadm installed, which seems like exactly the
set of users who *should* get an error message.

- Josh Triplett

Bug#1040908: Please don't depend on mdadm

[Josh Triplett]

Package: libblockdev-mdraid3
Version: 3.0.1-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

Current udisks2 has a dependency on libblockdev-mdraid3, and
libblockdev-mdraid3 has a dependency on mdadm. This effectively makes
mdadm required on desktop systems.

As I understand it from
https://github.com/storaged-project/udisks/issues/1142 , udisks2 needs
to depend on libblockdev-mdraid3. (And that much isn't necessarily an
issue, it's just a library.)

Would it be possible for libblockdev-mdraid3 to avoid pulling in mdadm,
so that systems not using RAID don't have to have mdadm and its
associated configuration and boot-time logic installed?

Bug#1038993: audit enabled despite nothing requesting it

[Josh Triplett]

On Mon, 26 Jun 2023 12:51:18 +0100 Luca Boccassi  wrote:
> On Sat, 24 Jun 2023 00:38:16 -0700 Josh Triplett
>  wrote:
> > Package: systemd
> > Version: 253-3
> > Severity: normal
> > X-Debbugs-Cc: j...@joshtriplett.org
> > 
> > The NEWS.Debian for the latest version of systemd mentions no longer
> > disabling audit, and relying on the audit socket being disabled by
> > default. However, despite that, upgrading systemd seems to have
> enabled
> > the audit socket unit:
> > 
> > ~$ systemctl | grep audit
> >   systemd-journald-audit.socket loaded active running   Journal
> Audit Socket
> > 
> > And there are a pile of audit messages in dmesg and the journal,
> > drowning out other messages.
> > 
> > I checked, and no units have Audit=yes, nor does anything appear to
> > depend on systemd-journald-audit.socket, nor is
> > systemd-journald-audit.socket included in sockets.target.wants.
> 
> Turns out we overlooked one thing - systemd-journald.service lists the
> audit socket under Sockets=, but that adds an implicit Wants, so
> effectively it is always activated automatically.

This *seems* like it may have been triggered by the upgrade,
specifically. Immediately after that upgrade, when systemd reloaded, I
got this message:

> Jun 24 00:24:10 o systemd-journald[237141]: Collecting audit messages is 
> enabled.

But on a fresh boot, I get:

> Jun 24 11:57:29 o systemd-journald[528]: Collecting audit messages is 
> disabled.

Does that help?

Bug#1029152: systemd: Revisit disabling of bump fs.nr_open, bump-proc-sys-fs-nr-open=false

[Josh Triplett]

On Wed, 18 Jan 2023 10:27:48 -0600 Jesse Hathaway  wrote:
> Package: systemd
> Version: 252.4-1
> Severity: normal
> X-Debbugs-Cc: je...@mbuki-mvuki.org
> 
> Dear Maintainer,
> 
> Would it be possible to revisit the decision to disable
> bump-proc-sys-fs-nr-open, from commit,
> 084e84e33a403868b7f84159da745689e2ff0ba9 ^[1]?
> 
> This recently caused me trouble when running a minikube instance on my
> laptop which used a bunch of file descriptors. It would be nice to not
> need to write sysctl values to bump it higher. Are there any paths to
> reverting this patch? Thanks for maintaining systemd!!
> 
> [1]: 
> https://salsa.debian.org/systemd-team/systemd/-/commit/084e84e33a403868b7f84159da745689e2ff0ba9.

Ideally, Debian should set the default value for this in the kernel,
rather than changing it at boot time.

(Also, ideally the default could change in the upstream kernel.)

Bug#1038994: Upgrading systemd stopped GNOME session

[Josh Triplett]

Package: systemd
Version: 253-3
Severity: important
X-Debbugs-Cc: j...@joshtriplett.org

I'm not entirely sure which package this bug belongs to, but it happened
when upgrading systemd, and systemd is my best guess here. Please feel
free to reassign.

When upgrading to systemd 253-3, my GNOME session restarted. From the
logs:

Jun 24 00:24:07 o systemd[1]: Reloading.
Jun 24 00:24:07 o systemd[1]: /lib/systemd/system/systemd-udevd.service:21: 
Failed to parse service type, ignoring: notify-reload
Jun 24 00:24:07 o systemd[1]: /lib/systemd/system/systemd-logind.service:63: 
Failed to parse service type, ignoring: notify-reload
Jun 24 00:24:07 o systemd[1]: /lib/systemd/system/systemd-networkd.service:50: 
Failed to parse service type, ignoring: notify-reload
Jun 24 00:24:07 o systemd[1]: /lib/systemd/system/user@.service:20: Failed to 
parse service type, ignoring: notify-reload
Jun 24 00:24:07 o systemd[1]: Stopping systemd-udevd.service - Rule-based 
Manager for Device Events and Files...
Jun 24 00:24:07 o systemd[1]: systemd-udevd.service: Deactivated successfully.
Jun 24 00:24:07 o systemd[1]: Stopped systemd-udevd.service - Rule-based 
Manager for Device Events and Files.
Jun 24 00:24:07 o systemd[1]: systemd-udevd.service: Consumed 7.243s CPU time.
Jun 24 00:24:07 o systemd[1]: Started systemd-udevd.service - Rule-based 
Manager for Device Events and Files.
Jun 24 00:24:07 o systemd[1]: Reloading.
...
Jun 24 00:24:10 o systemd[1]: Reloading requested from client PID 237159 (unit 
user@1000.service)...
...
Jun 24 00:24:48 o gdm-autologin][824]: pam_unix(gdm-autologin:session): session 
closed for user josh
Jun 24 00:24:48 o systemd[840]: Stopped target 
gnome-session-wayland@gnome.target - GNOME Wayland Session (session: gnome).
Jun 24 00:24:48 o systemd[840]: Stopped target graphical-session.target - 
Current graphical user session.
Jun 24 00:24:48 o systemd[840]: Stopped target gnome-session.target - GNOME 
Session.
Jun 24 00:24:48 o systemd[840]: Stopped target gnome-session-wayland.target - 
GNOME Wayland Session.
Jun 24 00:24:48 o systemd[840]: Stopped target gnome-session@gnome.target - 
GNOME Session (session: gnome).
...

I'm wondering if this might have happened because
/lib/systemd/system/user@.service was changed (to use notify-reload, as
indicated in the above log messages)?

Yes, I'm aware of the general guidance to do upgrades from within a
screen/tmux/etc session or similar. However, ordinarily upgrading
systemd does not result in killing the whole session.


-- Package-specific info:

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

Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libaudit1  1:3.0.9-1
ii  libblkid1  2.38.1-5+b1
ii  libc6  2.36-9
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-4
ii  libfdisk1  2.38.1-5+b1
ii  libgcrypt201.10.2-2
ii  libkmod2   30+20230519-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.1-0.2
ii  libmount1  2.38.1-5+b1
ii  libp11-kit00.24.1-2
ii  libseccomp22.5.4-1+b3
ii  libselinux13.4-1+b6
ii  libssl33.0.9-1
ii  libsystemd-shared  253-3
ii  libsystemd0253-3
ii  libzstd1   1.5.4+dfsg2-5
ii  mount  2.38.1-5+b1
ii  systemd-dev253-3

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.8-1
ii  systemd-timesyncd [time-daemon]  253-3

Versions of packages systemd suggests:
ii  libfido2-11.13.0-1
ii  libqrencode4  4.1.1-1
ii  libtss2-esys-3.0.2-0  3.2.1-3
ii  libtss2-mu0   3.2.1-3
pn  libtss2-rc0   
ii  policykit-1   122-4
ii  polkitd   122-4
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.8-1
pn  dracut 
ii  initramfs-tools0.142
pn  libnss-systemd 
ii  libpam-systemd 253-3
ii  udev   253-3

-- no debconf information

Bug#1038993: audit enabled despite nothing requesting it

[Josh Triplett]

Package: systemd
Version: 253-3
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

The NEWS.Debian for the latest version of systemd mentions no longer
disabling audit, and relying on the audit socket being disabled by
default. However, despite that, upgrading systemd seems to have enabled
the audit socket unit:

~$ systemctl | grep audit
  systemd-journald-audit.socket loaded active running   Journal Audit Socket

And there are a pile of audit messages in dmesg and the journal,
drowning out other messages.

I checked, and no units have Audit=yes, nor does anything appear to
depend on systemd-journald-audit.socket, nor is
systemd-journald-audit.socket included in sockets.target.wants.

- Josh Triplett


-- Package-specific info:

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

Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  libacl12.3.1-3
ii  libaudit1  1:3.0.9-1
ii  libblkid1  2.38.1-5+b1
ii  libc6  2.36-9
ii  libcap21:2.66-4
ii  libcryptsetup122:2.6.1-4
ii  libfdisk1  2.38.1-5+b1
ii  libgcrypt201.10.2-2
ii  libkmod2   30+20230519-1
ii  liblz4-1   1.9.4-1
ii  liblzma5   5.4.1-0.2
ii  libmount1  2.38.1-5+b1
ii  libp11-kit00.24.1-2
ii  libseccomp22.5.4-1+b3
ii  libselinux13.4-1+b6
ii  libssl33.0.9-1
ii  libsystemd-shared  253-3
ii  libsystemd0253-3
ii  libzstd1   1.5.4+dfsg2-5
ii  mount  2.38.1-5+b1
ii  systemd-dev253-3

Versions of packages systemd recommends:
ii  dbus [default-dbus-system-bus]   1.14.8-1
ii  systemd-timesyncd [time-daemon]  253-3

Versions of packages systemd suggests:
ii  libfido2-11.13.0-1
ii  libqrencode4  4.1.1-1
ii  libtss2-esys-3.0.2-0  3.2.1-3
ii  libtss2-mu0   3.2.1-3
pn  libtss2-rc0   
ii  policykit-1   122-4
ii  polkitd   122-4
pn  systemd-boot  
pn  systemd-container 
pn  systemd-homed 
pn  systemd-resolved  
pn  systemd-userdbd   

Versions of packages systemd is related to:
ii  dbus-user-session  1.14.8-1
pn  dracut 
ii  initramfs-tools0.142
pn  libnss-systemd 
ii  libpam-systemd 253-3
ii  udev   253-3

-- no debconf information

Bug#1038404: Single option to not depend on host configuration

[Josh Triplett]

Package: mmdebstrap
Version: 1.3.6-3
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

mmdebstrap has a couple of places in which it copies host configuration
into the bootstrapped system. For instance, it puts the host's hostname
into /etc/hostname, and copies in the host's /etc/resolv.conf. Please
consider providing a single option that suppresses all current and
future uses of the host configuration, to make it easier to build
reproducible installations.

The manpage mentions using a customize-hook to handle those two files,
but given the common need for reproducible installations, it'd be nice
to have this become simpler and standardized.

Bug#1037113: Should not be in /usr/games

[Josh Triplett]

On Mon, Jun 12, 2023 at 05:03:01PM -0500, Dirk Eddelbuettel wrote:
> 
> reassign 1037113 screen-message
> thanks
> 
> Binary package 'sm' is from source package 'screen-message'
> 
> Binary package 'r-cran-sm' is from source package 'sm', which I maintain, and
> something totally different :-)   Not the first crossed bug report so no
> worries, the reassign should work.

Sorry about that, and thank you.

Bug#1037239: Paste from clipboard no longer creates new image

[Josh Triplett]

Package: gimp
Version: 2.99.14-2+b1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

With the 2.0 branch, pasting from the clipboard (e.g. after taking a
screenshot) would create a new image. With the 3.0 branch, pasting
seems to do nothing, until after manually creating an image.


-- System Information:
Debian Release: 12.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.3.0-0-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gimp depends on:
ii  gimp-data2.99.14-2
ii  graphviz 2.42.2-7+b3
ii  libaa1   1.4p5-50
ii  libappstream-glib8   0.8.2-1
ii  libarchive13 3.6.2-1
ii  libasound2   1.2.8-1+b1
ii  libbabl-0.1-01:0.1.98-1+b1
ii  libbz2-1.0   1.0.8-5+b1
ii  libc62.36-9
ii  libcairo21.16.0-7
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-5
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libgegl-0.4-01:0.4.42-2
ii  libgexiv2-2  0.14.1-1
ii  libgimp-3.0-02.99.14-2+b1
ii  libglib2.0-0 2.74.6-2
ii  libgs10  10.0.0~dfsg-11
ii  libgtk-3-0   3.24.37-2
ii  libgudev-1.0-0   237-2
ii  libharfbuzz0b6.0.0+dfsg-3
ii  libheif1 1.15.1-1
ii  libjpeg62-turbo  1:2.1.5-2
ii  libjson-glib-1.0-0   1.6.6-1
ii  libjxl0.70.7.0-10
ii  liblcms2-2   2.14-2
ii  liblzma5 5.4.1-0.2
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.5-1 1.6.0-2
ii  libopenexr-3-1-303.1.5-5
ii  libopenjp2-7 2.5.0-2
ii  libpango-1.0-0   1.50.12+ds-1
ii  libpangocairo-1.0-0  1.50.12+ds-1
ii  libpangoft2-1.0-01.50.12+ds-1
ii  libpng16-16  1.6.39-2
ii  libpoppler-glib8 22.12.0-2+b1
ii  librsvg2-2   2.54.5+dfsg-1
ii  libstdc++6   12.2.0-14
ii  libtiff6 4.5.0-6
ii  libwebp7 1.2.4-0.2
ii  libwebpdemux21.2.4-0.2
ii  libwebpmux3  1.2.4-0.2
ii  libwmf-0.2-7 0.2.12-5.2
ii  libwmflite-0.2-7 0.2.12-5.2
ii  libx11-6 2:1.8.4-2
ii  libxcursor1  1:1.2.1-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxmu6  2:1.1.3-3
ii  libxpm4  1:3.5.12-1.1
ii  xdg-utils1.1.3-4.1
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  10.0.0~dfsg-11

Versions of packages gimp suggests:
pn  gimp-data-extras  
pn  gimp-help-en | gimp-help  
ii  gjs   1.74.2-1
ii  gvfs-backends 1.50.4-2
pn  luajit
ii  python3   3.11.2-1+b1

-- no debconf information

Bug#1037113: Should not be in /usr/games

[Josh Triplett]

Package: sm
Version: 0.26-3
Severity: minor
X-Debbugs-Cc: j...@joshtriplett.org

sm is a useful utility for a wide variety of purposes. I don't think it
belongs in /usr/games. Please consider relocating it to /usr/bin.

Thank you for maintaining sm!

Bug#1035904: dpkg currently warning about merged-usr systems (revisited)

[Josh Triplett]

On Fri, May 12, 2023 at 01:11:38PM +0100, Luca Boccassi wrote:
> The loader is still available via the old path, so external/third
> party/local/other software works unchanged. This should negatively
> only affect our 1st party packages, when running on a non-merged
> distro.
> And are _all_ our packages really 100% compatible with other distros
> at all? Are they even supposed to be?

People build things on Debian that are not Debian packages. People
compile binaries on Debian, and expect them to work on any system that
has sufficiently new libraries.

This is *not* about Debian packages failing to work on other
distributions; this is about *software compiled on Debian* faliing to
work in other environments.

If you build a dynamically linked binary that only depends on glibc, you
can expect it to be reasonably portable, to any system that uses glibc
and has a sufficiently new version.

Debian stable is, in fact, one of the common environments people use to
compile binaries for distribution.

> So, what I am asking is, what actual, real difference does it make if,
> by default (and with an override available for example), packages
> built on Debian for Debian record the ld path to point to its (actual)
> location on Debian, via say a compiler spec file that is injected in a
> deb build?

Making binaries built *on* Debian different than binaries built *for*
Debian would introduce a needless additional source of complexity,
compared to just compiling code the same way in both cases.

To frame this in different terms: consider that one of the major goals
of systemd has been to harmonize across distributions and eliminate
needless variations that don't serve much actual purpose (e.g.
variations in config file paths for the same config file). Consider how
much effort systemd went to work with distributions, understand and deal
with the *important* variations, and try to convince them to abandon the
*unimportant* variations. Now imagine if someone came along and said
"let's patch systemd to put unit files in /purple/; it'll work with
everything in our distribution".

Or, imagine if someone said "let's inject an argument to gzip, only for
building the .gz files sihpped in our packages of course, to modify the
gzip header and remove a few of the extraneous additional fields; it'll
be fine, because we've patched our gzip to parse it"

The x86-64 ABI is set. Feel free to make the case to the next
architecture designer that their new ABI should have the dynamic linker
in `/usr/lib`. That would *not* have the same downsides, as long as
everyone agrees on a path.

- Josh Triplett

Bug#1034744: Please consider making emacs support optional

[Josh Triplett]

Package: dictionaries-common
Version: 1.29.5
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

As far as I can tell, the support provided by dictionaries-common makes
emacs better if installed, but isn't needed if an emacs isn't installed.
The maintainer scripts correctly check to see if the necessary binaries
are installed before invoking them. Would it be possible to change the
emacsen-common Depends to a Recommends?

dictionaries-common is the only thing on my system pulling in the
emacsen-common machinery, and dictionaries-common is in turn a
dependency of required packages for various other programs.

Thank you,
Josh Triplett

Bug#580152: Still an issue in current apt

[Josh Triplett]

I ran into this recently.

For .d directories like /etc/apt/preferences.d, it'd be nice if apt were
silent about the directory not existing, and if it just treated that the
same as an empty directory.

Bug#1029932: Can no longer use 4k when mirroring to LG OLED TV

[Josh Triplett]

Package: gnome-settings-daemon
Version: 43.0-4
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

I don't know if this issue lies in gnome-settings-daemon, mutter,
gnome-shell, the kernel, or somewhere else.

Some time in the last month or two, something changed such that I can no
longer use 4k with mirror mode over HDMI to an LG OLED TV (tested with
both C2 and G2). Instead, I'm limited to 2560x1440. If I use "join"
mode, I can set the TV to 4k, but mirror mode no longer allows 4k.

My laptop screen is 3840x2400. In the past, mirror mode worked at
3840x2160 and just letterboxed on the laptop screen.

ThinkPad X1 Carbon 9th gen. Intel graphics. Happy to provide more
information.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-settings-daemon depends on:
ii  gnome-settings-daemon-common  43.0-4
ii  gsettings-desktop-schemas 43.0-1
ii  libasound21.2.8-1+b1
ii  libc6 2.36-8
ii  libcairo2 1.16.0-7
ii  libcanberra-gtk3-00.30-10
ii  libcanberra0  0.30-10
ii  libcolord21.4.6-2.1
ii  libcups2  2.4.2-1+b2
ii  libfontconfig12.14.1-3
ii  libgcr-base-3-1   3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0   2.42.10+dfsg-1+b1
ii  libgeoclue-2-02.6.0-2
ii  libgeocode-glib-2-0   3.26.3-5
ii  libglib2.0-0  2.74.5-1
ii  libgnome-desktop-3-20 43.1-1
ii  libgtk-3-03.24.36-2
ii  libgudev-1.0-0237-2
ii  libgweather-4-0   4.2.0-1
ii  libmm-glib0   1.20.4-1
ii  libnm01.40.10-1
ii  libnotify40.8.1-1
ii  libnspr4  2:4.35-1
ii  libnss3   2:3.87-1
ii  libpam-systemd [logind]   252.4-2
ii  libpango-1.0-01.50.12+ds-1
ii  libpangocairo-1.0-0   1.50.12+ds-1
ii  libpolkit-gobject-1-0 122-2
ii  libpulse-mainloop-glib0   16.1+dfsg1-2+b1
ii  libpulse0 16.1+dfsg1-2+b1
ii  libspa-0.2-bluetooth  0.3.64-4
ii  libupower-glib3   0.99.20-2
ii  libwacom9 2.5.0-1
ii  libwayland-client01.21.0-1
ii  libx11-6  2:1.8.3-3
ii  libxext6  2:1.3.4-1+b1
ii  libxfixes31:6.0.0-2
ii  libxi62:1.8-1+b1
ii  pipewire-audio0.3.64-4

Versions of packages gnome-settings-daemon recommends:
pn  iio-sensor-proxy   
ii  pipewire-audio 0.3.64-4
ii  pkexec 122-2
ii  x11-xserver-utils  7.7+9+b1

Versions of packages gnome-settings-daemon suggests:
pn  usbguard  

-- no debconf information

Bug#1029661: Cannot authenticate with Google

[Josh Triplett]

Package: gcalcli
Version: 4.3.0-1
Severity: grave
Tags: upstream
X-Debbugs-Cc: j...@joshtriplett.org

Google no longer allows gcalcli to authenticate. Upstream recommends
manually creating a developer account and registering gcalcli as your
own app. This is a *much* more cumbersome setup process, and the simple
oauth2 workflow that gcalcli uses by default doesn't work with no
indication of why.

At a minimum, this should be documented and the flow for not having
authenticated yet should give better guidance to the user and not try an
authentication that won't work.

https://github.com/insanum/gcalcli/issues/580


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.1.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gcalcli depends on:
ii  python33.11.1-1
ii  python3-dateutil   2.8.2-1
ii  python3-googleapi  1.7.12-1
ii  python3-httplib2   0.20.4-3
ii  python3-oauth2client   4.1.3-3
ii  python3-parsedatetime  2.6-3
ii  python3-six1.16.0-4

Versions of packages gcalcli recommends:
pn  python3-vobject  

gcalcli suggests no packages.

-- no debconf information

Bug#1029487: Please respect NAME if DEBFULLNAME not set

[Josh Triplett]

Package: devscripts
Version: 2.22.2
Severity: wishlist
File: /usr/bin/bts
X-Debbugs-Cc: j...@joshtriplett.org

Most tools that check DEBFULLNAME seem to fall back to NAME. bts,
however, looks at DEBFULLNAME and if not set it falls back to the passwd
database via getpwuid.

Please consider including a fallback checking NAME if DEBFULLNAME isn't
set.


-- Package-specific info:

--- /etc/devscripts.conf ---
Empty.

--- ~/.devscripts ---
BTS_SMTP_HELO=joshtriplett.org
BTS_SMTP_HOST=reportbug.debian.org:587
BTS_SUPPRESS_ACKS=yes
DEBUILD_DPKG_BUILDPACKAGE_OPTS="--no-sign"
DEBUILD_PREPEND_PATH=/usr/lib/ccache
DEBUILD_LINTIAN_OPTS='-i -I'

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages devscripts depends on:
ii  dpkg-dev  1.21.18
ii  fakeroot  1.30.1-1.1
ii  file  1:5.44-2
ii  gnupg 2.2.40-1
ii  gpgv  2.2.40-1
ii  libc6 2.36-8
ii  libfile-dirlist-perl  0.05-3
ii  libfile-homedir-perl  1.006-2
ii  libfile-touch-perl0.12-2
ii  libfile-which-perl1.27-2
ii  libipc-run-perl   20220807.0-1
ii  libmoo-perl   2.005005-1
ii  libwww-perl   6.67-1
ii  patchutils0.4.2-1
ii  perl  5.36.0-7
ii  python3   3.11.1-1
ii  sensible-utils0.0.17+nmu1
ii  wdiff 1.2.2-4

Versions of packages devscripts recommends:
ii  apt 2.5.5
ii  curl7.87.0-2
ii  dctrl-tools 2.24-3+b1
pn  debian-keyring  
pn  dput | dupload  
ii  equivs  2.3.1
pn  libdistro-info-perl 
ii  libdpkg-perl1.21.18
ii  libencode-locale-perl   1.05-3
pn  libgit-wrapper-perl 
pn  libgitlab-api-v4-perl   
ii  liblist-compare-perl0.55-2
ii  liblwp-protocol-https-perl  6.10-1
ii  libsoap-lite-perl   1.27-2
pn  libstring-shellquote-perl   
ii  libtry-tiny-perl0.31-2
ii  liburi-perl 5.17-1
pn  licensecheck
ii  lintian 2.116.0
ii  man-db  2.11.2-1
ii  patch   2.7.6-7
pn  pristine-tar
ii  python3-apt 2.5.1
ii  python3-debian  0.1.49
pn  python3-magic   
ii  python3-requests2.28.1+dfsg-1
pn  python3-unidiff 
ii  python3-xdg 0.28-2
ii  strace  5.10-1
ii  unzip   6.0-27
ii  wget1.21.3-1+b2
ii  xz-utils5.4.1-0.0

Versions of packages devscripts suggests:
pn  adequate 
pn  at   
pn  autopkgtest  
pn  bls-standalone   
pn  bsd-mailx | mailx
ii  build-essential  12.9
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper13.11.4
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  elpa-devscripts  
pn  faketime 
pn  gnuplot  
pn  how-can-i-help   
pn  libauthen-sasl-perl  
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-3
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3300-2
pn  libyaml-syck-perl
ii  mmdebstrap   1.3.1-2
pn  mozilla-devscripts   
ii  mutt 2.2.9-1
ii  openssh-client [ssh-client]  1:9.1p1-2
pn  piuparts 
pn  postgresql-client
pn  pristine-lfs 
pn  quilt
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information

Bug#1019211: [html2text] Eats 6+GB RAM (or crashes if it can't) on a certain HTML file

[Josh Triplett]

Package: html2text
Followup-For: Bug #1019211
X-Debbugs-Cc: j...@joshtriplett.org

Possibly related, with a minimal reproducer if so: I can cause html2text
to run out of memory with the following one-line HTML file.

/tmp$ cat temp.html

/tmp$ html2text < temp.html
html2text: error: Cannot allocate memory
Aborted

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages html2text depends on:
ii  libc6   2.36-7
ii  libgcc-s1   12.2.0-13
ii  libstdc++6  12.2.0-13

html2text recommends no packages.

Versions of packages html2text suggests:
ii  curl  7.87.0-1
ii  wget  1.21.3-1+b2

-- no debconf information

Bug#931254: Minimal reproducer [was: Re: html2text crashes with exit status 139 when table column spacing is not zero and a COLSPAN attribute exceeds the document width]

[Josh Triplett]

Package: html2text
Version: 1.3.2a-28
Followup-For: Bug #931254
X-Debbugs-Cc: j...@joshtriplett.org

Possibly related, I can cause html2text to run out of memory with the
following one-line HTML file involving colspan:

/tmp$ cat temp.html

/tmp$ html2text < temp.html
html2text: error: Cannot allocate memory
Aborted



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages html2text depends on:
ii  libc6   2.36-7
ii  libgcc-s1   12.2.0-13
ii  libstdc++6  12.2.0-13

html2text recommends no packages.

Versions of packages html2text suggests:
ii  curl  7.87.0-1
ii  wget  1.21.3-1+b2

-- no debconf information

Bug#1025206: RFP: bespoke -- Software modular music synthesizer

[Josh Triplett]

Package: wnpp
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

* Package name: bespoke
  Version : 1.1.0
  Upstream Author : Ryan Challinor 
* URL : https://www.bespokesynth.com/
https://github.com/BespokeSynth/BespokeSynth/
* License : GPLv3
  Programming Lang: C++
  Description : Software modular music synthesizer

Bespoke is a graphical tool to synthesize music, by wiring together
modular components.

Bug#1006251: USB Lenovo ThinkPad Compact Keyboard has fn_lock inverted

[Josh Triplett]

I have an external ThinkPad USB keyboard:

$ lsusb | grep -i keyboard
Bus 003 Device 022: ID 17ef:6047 Lenovo ThinkPad Compact Keyboard with 
TrackPoint

The Linux kernel exposes a fn_lock attribute in sysfs for this keyboard:

$ cat
sys/devices/pci:00/:00:14.0/usb3/3-5/3-5.4/3-5.4.3/3-5.4.3:1.1/0003:17EF:6047.000F/fn_lock
1

However, this attribute appears inverted for this particular keyboard:
it seems to be 1 when FnLock is *disabled* and 0 when FnLock is
*enabled*. In order to enable FnLock, I have to write 0 to this file.

(Also, separately from that, it would be nice if the kernel could handle
fn_lock toggling *internally*, rather than expecting userspace to do it.
As far as I can tell, it does handle similar things for some keyboards,
but not this one.)

Bug#1006251: USB Lenovo ThinkPad Compact Keyboard has fn_lock inverted

[Josh Triplett]

On Fri, Feb 25, 2022 at 02:43:59PM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi Josh,
> 
> On Mon, Feb 21, 2022 at 04:31:39PM -0800, Josh Triplett wrote:
> > Package: src:linux
> > Version: 5.16.7-2
> > Severity: normal
> > X-Debbugs-Cc: j...@joshtriplett.org
> > 
> > I have an external ThinkPad USB keyboard:
> > 
> > $ lsusb | grep -i keyboard
> > Bus 003 Device 022: ID 17ef:6047 Lenovo ThinkPad Compact Keyboard with 
> > TrackPoint
> > 
> > The Linux kernel exposes a fn_lock attribute in sysfs for this keyboard:
> > 
> > $ cat 
> > /sys/devices/pci:00/:00:14.0/usb3/3-5/3-5.4/3-5.4.3/3-5.4.3:1.1/0003:17EF:6047.000F/fn_lock
> > 1
> > 
> > However, this attribute appears inverted for this particular keyboard:
> > it seems to be 1 when FnLock is *disabled* and 0 when FnLock is
> > *enabled*.
> 
> If you can reproduce this with either 5.16.10-1 (or later today
> 5.16.11-1) or the current version in experimental (5.17~rc4-1~exp1)
> would it be possible you report it upstream and keep us updated on the
> progress?

Reproduced with 6.0.6-2, and reported upstream (CCed to this bug).

Bug#1006251: Closing this bug (BTS maintenance for src:linux bugs)

[Josh Triplett]

reopen 1006251 6.0.6-2
thanks

I can confirm that this still exists in current kernels.

- Josh Triplett

On Fri, Nov 11, 2022 at 04:46:52PM +0100, car...@debian.org wrote:
> Hi
> 
> This bug was filed for a very old kernel or the bug is old itself
> without resolution.
> 
> If you can reproduce it with
> 
> - the current version in unstable/testing
> - the latest kernel from backports
> 
> please reopen the bug, see https://www.debian.org/Bugs/server-control
> for details.
> 
> Regards,
> Salvatore

Bug#1022119: Wakes up every 1.5s even with no work to do

[Josh Triplett]

On Thu, Oct 20, 2022 at 03:24:48PM +0200, Samuel Thibault wrote:
> Control: reassign -1 pulseaudio
> 
> Samuel Thibault, le jeu. 20 oct. 2022 15:02:09 +0200, a ecrit:
> > Josh Triplett, le jeu. 20 oct. 2022 13:45:45 +0100, a ecrit:
> > > sd_dummy seems to be waking up every 1.5s even when it has no work to
> > > do.
> > 
> > I don't see that happening on my system. Could you run strace on it so
> > we get to know what happens in your case? E.g.
> > 
> > strace -p $(pgrep sd_dummy)
> 
> Ah, -f is needed to see the thread started by pulseaudio.
> 
> (gdb) bt
> #0  0x7fb4fdefe32f in __GI___poll (fds=fds@entry=0x7fb4f40071a0, 
> nfds=nfds@entry=2, timeout=timeout@entry=1500) at 
> ../sysdeps/unix/sysv/linux/poll.c:29
> #1  0x7fb4fe0652e1 in poll (__timeout=1500, __nfds=2, 
> __fds=0x7fb4f40071a0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:39
> #2  poll_func (ufds=0x7fb4f40071a0, nfds=2, timeout=1500, 
> userdata=0x56184db546b0) at ../src/pulse/thread-mainloop.c:70
> #3  0x7fb4fe056fa4 in pa_mainloop_poll (m=m@entry=0x56184db545b0) at 
> ../src/pulse/mainloop.c:863
> #4  0x7fb4fe057606 in pa_mainloop_iterate (m=m@entry=0x56184db545b0, 
> block=block@entry=1, retval=retval@entry=0x0) at ../src/pulse/mainloop.c:945
> #5  0x7fb4fe0576b0 in pa_mainloop_run (m=0x56184db545b0, 
> retval=retval@entry=0x0) at ../src/pulse/mainloop.c:963
> #6  0x7fb4fe0653b9 in thread (userdata=0x56184db54560) at 
> ../src/pulse/thread-mainloop.c:101
> #7  0x7fb4fd5d433f in internal_thread_func (userdata=0x56184db5ad20) at 
> ../src/pulsecore/thread-posix.c:81
> #8  0x7fb4fde8784a in start_thread (arg=) at 
> ./nptl/pthread_create.c:442
> #9  0x7fb4fdf0b2cc in clone3 () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
> 
> so that's coming from pulseaudio. The 1500 delay is most probably
> coming from
> 
> ./src/pulse/stream.c:#define AUTO_TIMING_INTERVAL_END_USEC 
> (1500*PA_USEC_PER_MSEC)
> 
> I don't know why pulseaudio would be waking up every 1.5s even if the
> speech module doesn't submit any audio.

In case it matters, I'm using pipewire, not pulseaudio.

An strace looks something like this (note: had to manually start
speech-dispatcher to get this, as I've since disabled autospawn because
of this issue):

[pid 14399] restart_syscall(<... resuming interrupted read ...> 
[pid 14398] futex(0x560856cef080, 
FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY 

[pid 14399] <... restart_syscall resumed>) = 0
[pid 14399] getpid()= 14397
[pid 14399] write(10, "W", 1)   = 1
[pid 14399] write(10, "W", 1)   = 1
[pid 14399] write(10, "W", 1)   = 1
[pid 14399] read(9, "WWW", 10)  = 3
[pid 14399] sendto(12, 
"\0\0\0\30\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0L\0\0\0\16L\0\0\0\rL\0"..., 
44, MSG_NOSIGNAL, NULL, 0) = 44
[pid 14399] read(9, 0x7f6ef0069c0e, 10) = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 14399] poll([{fd=9, events=POLLIN}, {fd=12, events=POLLIN}], 2, 1500) = 1 
([{fd=12, revents=POLLIN}])
[pid 14399] write(10, "W", 1)   = 1
[pid 14399] recvmsg(12, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="\0\0\0S\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0", 
iov_len=20}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, 
cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=746, uid=1000, gid=1000}}], 
msg_controllen=32, msg_flags=0}, 0) = 20
[pid 14399] write(10, "W", 1)   = 1
[pid 14399] read(9, "WW", 10)   = 2
[pid 14399] poll([{fd=9, events=POLLIN}, {fd=12, events=POLLIN}], 2, 1499) = 1 
([{fd=12, revents=POLLIN}])
[pid 14399] write(10, "W", 1)   = 1
[pid 14399] recvmsg(12, {msg_name=NULL, msg_namelen=0, 
msg_iov=[{iov_base="L\0\0\0\2L\0\0\0\rU\0\0\0\0\0\0V*U\0\0\0\0\0\0\0\TcQ"...,
 iov_len=83}], msg_iovlen=1, msg_control=[{cmsg_len=28, cmsg_level=SOL_SOCKET, 
cmsg_type=SCM_CREDENTIALS, cmsg_data={pid=746, uid=1000, gid=1000}}], 
msg_controllen=32, msg_flags=0}, 0) = 83
[pid 14399] write(10, "W", 1)   = 1
[pid 14399] read(9, "WW", 10)   = 2
[pid 14399] poll([{fd=9, events=POLLIN}, {fd=12, events=POLLIN}], 2, 1499) = 0 
(Timeout)
[pid 14399] getpid()= 14397
[pid 14399] write(10, "W", 1)   = 1
[pid 14399] write(10, "W", 1)   = 1
[pid 14399] write(10, "W", 1)   = 1
[pid 14399] read(9, "WWW", 10)  = 3
[pid 14399] sendto(12, 
"\0\0\0\30\377\377\377\377\0\0\0\0\0\0\0\0\0\0\0\0L\0\0\0\16L\0\0\0\16L\0"..., 
44, MSG_NOSIGNAL, NULL, 0) = 44
[pid 14399] read(9, 0x7f6ef0069c0e, 10) = -1 EAGAIN (Resource temporarily 
unavailable)
[pid 14399] poll([{fd=9, e

Bug#1021483: Pipewire keeps waking up CPU even when not playing sound

[Josh Triplett]

On Sun, 09 Oct 2022 12:11:24 +0100 Josh Triplett  wrote:
> Reporting this as "important" because as far as I can tell my battery
> life has gone down noticeably since switching from Pulseaudio to Pipewire.
> 
> Even when not playing any sound whatsoever, pipewire is waking up more
> than a hundred times per second, and using ~10ms of CPU out of every 1s.
> 
> This keeps the CPU in lower sleep states, and uses more battery.

Following up on this, I think this is caused by speech-dispatcher:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1022120

Bug#1022120: speech-dispatcher-dummy causes pipewire to spin and use battery

[Josh Triplett]

Package: speech-dispatcher
Version: 0.11.3-1+b1
Severity: important
X-Debbugs-Cc: j...@joshtriplett.org

Previously, I reported
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1021483 against
pipewire. I discovered pw-top, and it showed that
speech-dispatcher-dummy was the only thing interacting with pipewire.
Killing speech-dispatcher caused pipewire to *stop* waking up and using
battery.

To the best of my knowledge, nothing on my system should be *using*
speech-dispatcher. (Happy to check that if there's a tool to do so.) So
it shouldn't be sending anything to pipewire and causing pipewire to
wake up.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.0.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages speech-dispatcher depends on:
ii  adduser  3.129
ii  init-system-helpers  1.65.2
ii  libc62.35-3
ii  libdotconf0  1.3-0.3
ii  libglib2.0-0 2.74.0-3
ii  libltdl7 2.4.7-4
ii  libsndfile1  1.1.0-3
ii  libspeechd2  0.11.3-1+b1
ii  speech-dispatcher-audio-plugins  0.11.3-1+b1
ii  sysvinit-utils [lsb-base]3.05-6

Versions of packages speech-dispatcher recommends:
pn  sound-icons  
pn  speech-dispatcher-espeak-ng  

Versions of packages speech-dispatcher suggests:
pn  espeak  
pn  libttspico-utils
pn  mbrola  
pn  speech-dispatcher-cicero
pn  speech-dispatcher-doc-cs
pn  speech-dispatcher-espeak
pn  speech-dispatcher-festival  
pn  speech-dispatcher-flite 

-- no debconf information

Bug#1022119: Wakes up every 1.5s even with no work to do

[Josh Triplett]

Package: speech-dispatcher
Version: 0.11.3-1+b1
Severity: normal
File: /usr/lib/speech-dispatcher-modules/sd_dummy
X-Debbugs-Cc: j...@joshtriplett.org

sd_dummy seems to be waking up every 1.5s even when it has no work to
do. It should sleep indefinitely if it doesn't have work to do, to save
battery and spurious CPU usage.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 6.0.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages speech-dispatcher depends on:
ii  adduser  3.129
ii  init-system-helpers  1.65.2
ii  libc62.35-3
ii  libdotconf0  1.3-0.3
ii  libglib2.0-0 2.74.0-3
ii  libltdl7 2.4.7-4
ii  libsndfile1  1.1.0-3
ii  libspeechd2  0.11.3-1+b1
ii  speech-dispatcher-audio-plugins  0.11.3-1+b1
ii  sysvinit-utils [lsb-base]3.05-6

Versions of packages speech-dispatcher recommends:
pn  sound-icons  
pn  speech-dispatcher-espeak-ng  

Versions of packages speech-dispatcher suggests:
pn  espeak  
pn  libttspico-utils
pn  mbrola  
pn  speech-dispatcher-cicero
pn  speech-dispatcher-doc-cs
pn  speech-dispatcher-espeak
pn  speech-dispatcher-festival  
pn  speech-dispatcher-flite 

-- no debconf information

Bug#1019192: Upstream report

[Josh Triplett]

Someone diagnosed and reported this upstream at
https://lore.kernel.org/lkml/c8c65713-5cda-43ad-8018-20f2e32e4...@t-8ch.de/T/#u

- Josh

Bug#1021483: Pipewire keeps waking up CPU even when not playing sound

[Josh Triplett]

Package: pipewire
Version: 0.3.59-1
Severity: important
X-Debbugs-Cc: j...@joshtriplett.org

Reporting this as "important" because as far as I can tell my battery
life has gone down noticeably since switching from Pulseaudio to Pipewire.

Even when not playing any sound whatsoever, pipewire is waking up more
than a hundred times per second, and using ~10ms of CPU out of every 1s.

This keeps the CPU in lower sleep states, and uses more battery.

- Josh Triplett

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.19.0-2-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages pipewire depends on:
ii  init-system-helpers  1.65.2
ii  libpipewire-0.3-modules  0.3.59-1
ii  pipewire-bin 0.3.59-1

pipewire recommends no packages.

pipewire suggests no packages.

-- no debconf information

Bug#1019192: Pile of error messages from certs subsystem on boot

[Josh Triplett]

Package: src:linux
Version: 5.19.6-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

After upgrading to the 5.19 kernel, I got a pile of kernel error
messages appearing right before the disk decryption prompt. Providing
them below with context; the repeated message was the only one with a
visible priority level.

Loading compiled-in X.509 certificates
Loaded X.509 cert 'Debian Secure Boot CA: 
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
Loaded X.509 cert 'Debian Secure Boot Signer 2022 - linux: 
14011249c2675ea8e5148542202005810584b25f'
zswap: loaded using pool lzo/zbud
Key type ._fscrypt registered
Key type .fscrypt registered
Key type fscrypt-provisioning registered
Key type encrypted registered
AppArmor: AppArmor sha1 policy hashing enabled
integrity: Loading X.509 certificate: UEFI:db
integrity: Loaded X.509 cert 'Lenovo Ltd.: ThinkPad Product CA 2012: 
838b1f54c1550463f45f98700640f11069265949'
integrity: Loading X.509 certificate: UEFI:db
integrity: Loaded X.509 cert 'Lenovo UEFI CA 2014: 
4b91a68732eaefdd2c8c6b027ec3449e9c8f'
integrity: Loading X.509 certificate: UEFI:db
integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 
13adbf4309bd82709c8cd54f316ed522988a1bd4'
integrity: Loading X.509 certificate: UEFI:db
integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: 
a92902398e16c49778cd90f99e4f9ae17c55af53'
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
blacklist: Problem blacklisting hash (-13)
ima: Allocated hash algorithm: sha256
ima: No architecture policies found
evm: Initialising EVM extended attributes:


-- Package-specific info:
** Version:
Linux version 5.19.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.3.0-5) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.90.20220713) #1 SMP 
PREEMPT_DYNAMIC Debian 5.19.6-1 (2022-09-01)

** Command line:
BOOT_IMAGE=/vmlinuz-5.19.0-1-amd64 
root=UUID=fedea568-155d-463b-b38a-c1b46d63a8bc ro quiet

** Not tainted

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: LENOVO
product_name: 20XWCTO1WW
product_version: ThinkPad X1 Carbon Gen 9
chassis_vendor: LENOVO
chassis_version: None
bios_vendor: LENOVO
bios_version: N32ET75W (1.51 )
board_vendor: LENOVO
board_name: 20XWCTO1WW
board_version: Not Defined

** Loaded modules:
snd_ctl_led
snd_soc_skl_hda_dsp
snd_soc_intel_hda_dsp_common
qrtr
snd_soc_hdac_hdmi
snd_sof_probes
bnep
binfmt_misc
snd_hda_codec_hdmi
nls_ascii
nls_cp437
snd_hda_codec_realtek
vfat
snd_soc_dmic
x86_pkg_temp_thermal
snd_hda_codec_generic
fat
intel_powerclamp
mei_hdcp
snd_sof_pci_intel_tgl
snd_sof_intel_hda_common
intel_rapl_msr
soundwire_intel
soundwire_generic_allocation
soundwire_cadence
snd_sof_intel_hda
snd_sof_pci
snd_sof_xtensa_dsp
snd_sof
coretemp
snd_sof_utils
snd_soc_hdac_hda
snd_hda_ext_core
kvm_intel
snd_soc_acpi_intel_match
snd_soc_acpi
btusb
kvm
btrtl
snd_soc_core
iwlmvm
btbcm
snd_compress
irqbypass
btintel
soundwire_bus
btmtk
intel_cstate
i915
bluetooth
snd_hda_intel
mac80211
snd_intel_dspcfg
intel_uncore
snd_intel_sdw_acpi
joydev
snd_hda_codec
evdev
efi_pstore
serio_raw
snd_hda_core
iTCO_wdt
snd_hwdep
wmi_bmof
intel_pmc_bxt
snd_pcm
iTCO_vendor_support
watchdog
libarc4
snd_timer
uvcvideo
jitterentropy_rng
drm_buddy
iwlwifi
drm_display_helper
thinkpad_acpi
videobuf2_vmalloc
videobuf2_memops
mei_me
cec
sha512_ssse3
videobuf2_v4l2
nvram
platform_profile
ledtrig_audio
videobuf2_common
mei
sha512_generic
rc_core
snd
cfg80211
hid_multitouch
soundcore
ttm
videodev
drbg
processor_thermal_device_pci_legacy
ansi_cprng
drm_kms_helper
processor_thermal_device
int3403_thermal
ucsi_acpi
processor_thermal_rfim
typec_ucsi

Bug#1015157: gnome-control-center: segfaults reproducibly on sharing panel

[Josh Triplett]

On Sat, 16 Jul 2022 22:47:35 +0200 Ansgar  wrote:
> Package: gnome-control-center
> Version: 1:42.3-1
> Severity: normal
> Tags: upstream
> 
> gnome-control-center segfaults reproducibly about 1-2 seconds after
> opening the "Sharing" panel.  I've installed debug symbols and got the
> following backtrace from the coredump caught by systemd-coredumpd:

I can confirm this. It *only* seems to segfault with
gnome-remote-desktop installed; installing it makes gnome-control-center
start segfaulting, and removing it makes gnome-control-center stop
segfaulting and successfully launch again.

Bug#1014901: Home directories should not be setgid by default

[Josh Triplett]

On Thu, Jul 14, 2022 at 04:20:18PM -0400, Matt Barry wrote:
> On Thu, 2022-07-14 at 13:05 -0700, Josh Triplett wrote:
> > The use case below, and any other tools that create files and know to
> > set their permissions appropriately but don't expect unusual
> > ownership
> > by default:
> > > > In particular, it is common to build various kinds of filesystem,
> > > > container, or disk images, and to do so within your home
> > > > directory.
> > > > Users writing tools and scripts to build such images need to make
> > > > sure
> > > > to create files with an appropriate mode, but such scripts often
> > > > assume
> > > > (reasonably) that if they're running as root:root and they create
> > > > a
> > > > file, that file will be owned by root:root. Attempting to build
> > > > filesystems, containers, disk images, or similar in an
> > > > unexpectedly
> > > > setgid directory will produce unexpected results (leaving aside
> > > > that the
> > > > directory mode itself will be surprising).
> 
> Could you be just slightly more specific about a use case that fails? 
> Given how many times this has come up over the years, I'm trying to get
> a sense of what the *actual* issues are (as opposed to what they used
> to be).
> 
> Enough instruction that I can reproduce a specific problem(s) would be
> great.

Sure. Here's a sample of the kind of script I regularly encounter,
producing incorrect results in a setgid directory. The script expects to
produce files owned by root:root, but the files and directories get the
wrong group, and the setgid bit gets propagated to the constructed
filesystem image.

/tmp/testdir$ ls -ld
drwxr-sr-x 2 josh josh 4096 Jul 16 13:40 .
/tmp/testdir$ ls -l
total 4
-rwxr-xr-x 1 josh josh 354 Jul 16 13:40 make-filesystem.sh
/tmp/testdir$ cat make-filesystem.sh
#!/bin/bash
if [ "$(id -u)" -ne 0 ]; then
echo Run as root >&2
exit 1
fi

umask 022

mkdir fsroot fsroot/bin fsroot/etc fsroot/srv
mkdir -m 0700 fsroot/srv/workdir
echo 'nameserver 169.254.169.253' > fsroot/etc/resolv.conf
printf '#!/bin/sh\necho example binary\n' > fsroot/bin/example
chmod a+x fsroot/bin/example

mke2fs -d fsroot root.img 16M
/tmp/testdir$ sudo ./make-filesystem.sh
mke2fs 1.46.5 (30-Dec-2021)
Creating regular file root.img
Creating filesystem with 16384 1k blocks and 4096 inodes
Filesystem UUID: ec2c8666-96d9-4bce-b964-4c32ed098638
Superblock backups stored on blocks:
8193

Allocating group tables: done
Writing inode tables: done
Copying files into the device: done
Writing superblocks and filesystem accounting information: done

/tmp/testdir$ ls -l
total 1196
drwxr-sr-x 5 root josh 4096 Jul 16 13:41 fsroot
-rwxr-xr-x 1 josh josh  354 Jul 16 13:40 make-filesystem.sh
-rw-r--r-- 1 root josh 16777216 Jul 16 13:41 root.img
/tmp/testdir$ mkdir /tmp/testmount
/tmp/testdir$ sudo mount -o loop root.img /tmp/testmount
/tmp/testdir$ sudo ls -lR /tmp/testmount/
/tmp/testmount/:
total 15
drwxr-sr-x 2 root josh  1024 Jul 16 13:41 bin
drwxr-sr-x 2 root josh  1024 Jul 16 13:41 etc
drwx-- 2 root root 12288 Jul 16 13:41 lost+found
drwxr-sr-x 3 root josh  1024 Jul 16 13:41 srv

/tmp/testmount/bin:
total 1
-rwxr-xr-x 1 root josh 30 Jul 16 13:41 example

/tmp/testmount/etc:
total 1
-rw-r--r-- 1 root josh 27 Jul 16 13:41 resolv.conf

/tmp/testmount/lost+found:
total 0

/tmp/testmount/srv:
total 1
drwx--S--- 2 root josh 1024 Jul 16 13:41 workdir

/tmp/testmount/srv/workdir:
total 0

Bug#1014901: Home directories should not be setgid by default

[Josh Triplett]

On Thu, 14 Jul 2022 11:38:46 +0200 Marc Haber  
wrote:
> On Wed, Jul 13, 2022 at 11:45:58PM -0700, Josh Triplett wrote:
> > adduser 3.122 changes home directories to be setgid by default. The
> > issues discussing that change mention use cases involving multiuser
> > systems with shared groups, though that doesn't explain setting this
> > mode on home directories rather than on shared work areas.
> 
> This was part of the big adduser discussion debian-devel@l.d.o and
> didn't get much attention. The setting is run-time configurable in
> adduser.conf.
> 
> I would be willing to re-raise the severity of this issue if I can find
> a case for changing the default AGAIN and there is some discussion on
> debian-devel on this topic.
[...]
> It is really sad that you didn't participate in the discussion in march,
> where this part of the changes didnt get much attention and noone came
> up with any arguments against sgid home directories. I personally am at
> a loss here since I am just a server jockey who doesn't have many
> unprivileged shell account users on my boxes.

I'm not subscribed to -devel. I saw that some discussion about adduser
took place, and saw some of the topics, but I didn't see any mention of
sgid home directories. I would have been happy to participate in such a
discussion, had I known about it. The first I heard about this was via
apt-listchanges. :(

> > One of the issues links to
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=64806 , which talks
> > about easing the setup of shared directories for users who don't feel
> > comfortable running `chmod 2770` or similar themselves. That seems like
> > a relatively small justification, given that anyone setting up a shared
> > work directory *can* run `chmod 2770` or similar themselves, and doing
> > so does not require any special permission.
> 
> A local admin who doesn't like the behavior is free to change the
> default by setting an appropriate DIR_MODE in adduser.conf. There is a
> NEWS.Debian entry pointing the local administrator to this new behavior.

I understand this, and I understand that there's no one default that
will make everyone happy. I'm hoping to make the case for what the
default should be, to both minimize surprises and minimize the impact on
the most users.

> > The more recent issue 643559 suggests that
> > > Those "bad side-effects", if they were ever relevant and important
> > > enough to make personal groups not work properly, have now been fixed.
> > 
> > However, this is not the case; this change does in fact have bad
> > side-effects. This change breaks some common use cases that apply to
> > users on many systems, both single-user and multi-user.
> 
> Can we please have more information than just "bad side-effects"?

The use case below, and any other tools that create files and know to
set their permissions appropriately but don't expect unusual ownership
by default:
> > In particular, it is common to build various kinds of filesystem,
> > container, or disk images, and to do so within your home directory.
> > Users writing tools and scripts to build such images need to make sure
> > to create files with an appropriate mode, but such scripts often assume
> > (reasonably) that if they're running as root:root and they create a
> > file, that file will be owned by root:root. Attempting to build
> > filesystems, containers, disk images, or similar in an unexpectedly
> > setgid directory will produce unexpected results (leaving aside that the
> > directory mode itself will be surprising).
> 
> Would it help to do this kind of work in a subdirectory under the home
> directory and making sure that one is not setgid? I am happy to document
> this.

That's certainly a workaround if you know it's a problem. On the other
hand, it's likewise possible for anyone doing shared-work-directories on
a multiuser system to create a directory that *is* setgid.

I fully acknowledge here that there's no one default that will make
everyone happy, and that someone is going to end up needing to configure
it. I'm attempting to make the case for what the default should be.

I'm also hoping to make a case for "this change is a surprise and a
regression, and changing it *back* shouldn't have the burden of
'changing the default' but rather 'reverting this change and returning to the
previous default'". But either way, I'm willing to make the case
regarding the default itself.

> > Given those tradeoffs, I don't think this change is the right default.
> > I'd like to ask that the default mode be reverted from 2700 to 700.
> 
> I'd like you to take this discussion to debian-devel, most desireably as
> reply to https://lists.debian.org/debian-devel/2022/03/msg00304.html,
> .

I can do that.

> We can also talk to the ctte if the discussion on -devel doesn't bring
> any more consensus.

I sincerely hope it doesn't come to that.

Bug#1014901: Home directories should not be setgid by default

[Josh Triplett]

Package: adduser
Version: 3.122
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

adduser 3.122 changes home directories to be setgid by default. The
issues discussing that change mention use cases involving multiuser
systems with shared groups, though that doesn't explain setting this
mode on home directories rather than on shared work areas.

One of the issues links to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=64806 , which talks
about easing the setup of shared directories for users who don't feel
comfortable running `chmod 2770` or similar themselves. That seems like
a relatively small justification, given that anyone setting up a shared
work directory *can* run `chmod 2770` or similar themselves, and doing
so does not require any special permission.

The more recent issue 643559 suggests that
> Those "bad side-effects", if they were ever relevant and important
> enough to make personal groups not work properly, have now been fixed.

However, this is not the case; this change does in fact have bad
side-effects. This change breaks some common use cases that apply to
users on many systems, both single-user and multi-user.

In particular, it is common to build various kinds of filesystem,
container, or disk images, and to do so within your home directory.
Users writing tools and scripts to build such images need to make sure
to create files with an appropriate mode, but such scripts often assume
(reasonably) that if they're running as root:root and they create a
file, that file will be owned by root:root. Attempting to build
filesystems, containers, disk images, or similar in an unexpectedly
setgid directory will produce unexpected results (leaving aside that the
directory mode itself will be surprising).

This is not just a matter of "change the configuration on your system";
this is a support issue for many, many users who run such tools or who
work with others who do so. I really do not look forward to adding this
to my library of "if something is broken, check this" issues (and,
likely, not remembering it immediately as a possibility about another
developer's system, having long since fixed my own).

Both of these are valid use cases, and I'm not going to suggest that
either one is invalid. However, I think having setgid home directories
is *more surprising* behavior, and addresses a less common use case at
the expense of a more common one. The default behavior of a Linux system
is that file creation uses the current user and group, and setgid home
directories are a surprise.

Perhaps most importantly, the failure mode of the multiuser case is much
more obvious and easy to debug. You go to work in a shared area, on a
multiuser interactive system, a file has the wrong permission, you
change it with chmod/chgrp. Because the system is interactive and the
failure mode is noticed by an interactive user as a permission issue,
it's easy to diagnose and fix and causes relatively little hiccup.

By contrast, the failure mode of the filesystem/image/container creation
case can be much harder to debug, and can manifest as "this image I
created isn't booting on a remote system, which has no users and no
shells and no remote access, and it's failing before it gets
logging/tracing up because things have the wrong ownership, so there's
no obvious cause". Nothing necessarily points to ownership/permissions
right away, and it's *not* encountered by an interactive user with an
obvious error message.

Given those tradeoffs, I don't think this change is the right default.
I'd like to ask that the default mode be reverted from 2700 to 700.

- Josh Triplett

Bug#1014879: Please do not depend on gnome-remote-desktop

[Josh Triplett]

On Wed, Jul 13, 2022 at 10:51:05PM +0200, Jeremy Bicha wrote:
> On Wed, Jul 13, 2022 at 6:27 PM Josh Triplett  wrote:
> > gnome-control-center 1:42.3-1 adds a dependency on gnome-remote-desktop,
> 
> Please see https://launchpad.net/bugs/1980606 (which was mentioned in
> the debian/changelog).
> 
> Without that dependency, the app crashes.
> 
> Perhaps the gsettings schemas could be split to a separate package but
> I believe the code assumes that gnome-remote-desktop is available. So
> we would just have a different bug.

That does indeed seem like a bug, and I'd be happy for this bug to be
repurposed to that effect: "gnome-control-center should work without
gnome-remote-desktop installed". (Having the schemas installed doesn't
seem like a problem.)

> If you want to keep gnome-remote-desktop from running, why don't you
> mask and disable the systemd user services?

That would be my next logical path, but in general I try to minimize the
number of things I have to have installed-and-disabled, so it seemed
worth first seeing if this could become a Recommends. And it sounds like
the answer is that first gnome-control-center would need a fix to not
require it.

Bug#1014879: Please do not depend on gnome-remote-desktop

[Josh Triplett]

Package: gnome-control-center
Version: 1:42.3-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

gnome-control-center 1:42.3-1 adds a dependency on gnome-remote-desktop,
a daemon for remote desktop sharing. I'd like to avoid installing that
on my system, for the same reason I avoid installing even an inert sshd:
avoiding mistakes where it could end up running unexpectedly.

I appreciate that gnome *metapackages* aren't designed for people to
pick-and-choose components, and I would understand if a gnome
metapackage had this dependency (though I'd really appreciate it if it
did not have a hard dependency).

But gnome-control-center is not a metapackage; it's a concrete package
containing one of the core required components of a GNOME desktop. I'd
appreciate it if it didn't have a hard dependency on
gnome-remote-desktop.

Bug#1014083: Leaves many mldbm files in /tmp without cleanup

[Josh Triplett]

Package: lintian
Version: 2.115.2
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

The current version of lintian seems to create numerous temporary files
in /tmp/mldbm-elf-* and /tmp/mldbm-elf-by-member-* and while some of
them disappear by the time lintian finishes, others remain around
without getting cleaned up.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

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

Versions of packages lintian depends on:
ii  binutils2.38.50.20220627-1
ii  bzip2   1.0.8-5
ii  diffstat1.64-1
ii  dpkg1.21.8
ii  dpkg-dev1.21.8
ii  file1:5.41-4
ii  gettext 0.21-6
ii  gpg 2.2.35-2
ii  intltool-debian 0.35.0+20060710.5
ii  iso-codes   4.10.0-1
ii  libapt-pkg-perl 0.1.40+b1
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-1+b2
ii  libcapture-tiny-perl0.48-1
ii  libclass-xsaccessor-perl1.19-3+b8
ii  libclone-perl   0.45-1+b2
ii  libconfig-tiny-perl 2.28-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.30-1
ii  libdata-dpath-perl  0.58-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-2
ii  libdevel-size-perl  0.83-1+b3
pn  libdigest-sha-perl  
ii  libdpkg-perl1.21.8
ii  libemail-address-xs-perl1.04-1+b4
ii  libfile-basedir-perl0.09-1
ii  libfile-find-rule-perl  0.34-1.1
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-2
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.023-1
ii  libipc-run3-perl0.048-2
ii  libjson-maybexs-perl1.004003-1
ii  liblist-compare-perl0.55-1
ii  liblist-someutils-perl  0.58-1
ii  liblist-utilsby-perl0.12-1
ii  libmldbm-perl   2.05-3
ii  libmoo-perl 2.005004-3
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.122-1
ii  libperlio-gzip-perl 0.20-1
ii  libperlio-utf8-strict-perl  0.009-1+b1
ii  libproc-processtable-perl   0.634-1+b1
ii  libregexp-wildcards-perl1.05-2
ii  libsereal-decoder-perl  4.023+ds-1
ii  libsereal-encoder-perl  4.023+ds-1
ii  libsort-versions-perl   1.62-2
ii  libsyntax-keyword-try-perl  0.27-1
ii  libterm-readkey-perl2.38-1+b3
ii  libtext-levenshteinxs-perl  0.03-5
ii  libtext-markdown-discount-perl  0.13-1+b1
ii  libtext-xslate-perl 3.5.9-1+b1
ii  libtime-duration-perl   1.21-1
ii  libtime-moment-perl 0.44-1+b4
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-1+b3
ii  liburi-perl 5.10-1
ii  libwww-mechanize-perl   2.09-1
ii  libwww-perl 6.67-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-1
ii  libyaml-libyaml-perl0.83+ds-1+b1
ii  lzip [lzip-decompressor]1.23-3
ii  lzop1.04-2
ii  man-db  2.10.2-1
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.34.0-4
ii  t1utils 1.41-4
ii  unzip   6.0-26
ii  xz-utils5.2.5-2.1

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.38.50.20220627-1
pn  libtext-template-perl  

-- no debconf information

Bug#1010188: NIS not actually removed in 1.4.0-12

[Josh Triplett]

Source: pam
Version: 1.4.0-11
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

When I upgraded to 1.4.0-12, I noticed that the dependencies didn't seem
to change, and the package still pulled in NIS libraries. As far as I
can tell from the git repository, the only thing that changed in
1.4.0-12 was the changelog. Diffstats:

commit f77e0c7cc0200911ffdc1e95032488072ad2ed15
Author: Steve Langasek 
Date:   Mon Apr 25 11:33:31 2022 -0700

releasing package pam version 1.4.0-12

 debian/changelog | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

commit b36d84ca59e4cf29f12ff37f7f820ce3bc1625d5
Author: Steve Langasek 
Date:   Mon Apr 25 11:33:24 2022 -0700

Don't build with NIS support.  This is only used for password changes on 
NIS systems, and is pulling a large dependency chain into the Essential package 
set which is not justifiable.

 debian/changelog | 8 
 1 file changed, 8 insertions(+)


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1009938: Audio output switching no longer works after upgrade to GNOME 42

[Josh Triplett]

Package: gnome-control-center
Version: 1:42.0-3
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

After upgrading to GNOME 42, the options in gnome-control-center to
switch the audio output device no longer functions; sound always goes to
the headphone port in my dock if plugged in, or my HDMI monitor otherwise,
without the option to switch back and forth with both plugged in.

The option still exists, but changing its value doesn't change where
audio goes.

- Josh Triplett

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-control-center depends on:
ii  accountsservice   22.07.5-1
ii  apg   2.2.3.dfsg.1-5+b2
ii  colord1.4.6-1
ii  desktop-base  11.0.3
ii  desktop-file-utils0.26-1
ii  gnome-control-center-data 1:42.0-3
ii  gnome-desktop3-data   42.0-2
ii  gnome-settings-daemon 42.1-3
ii  gsettings-desktop-schemas 42.0-1
ii  libaccountsservice0   22.07.5-1
ii  libadwaita-1-01.1.0-1
ii  libc6 2.33-7
ii  libcairo2 1.16.0-5
ii  libcolord-gtk4-1  0.3.0-3
ii  libcolord21.4.6-1
ii  libcups2  2.4.1op1-2
ii  libepoxy0 1.5.10-1
ii  libfontconfig12.13.1-4.4
ii  libgcr-base-3-1   3.40.0-4
ii  libgdk-pixbuf-2.0-0   2.42.8+dfsg-1
ii  libglib2.0-0  2.72.1-1
ii  libgnome-bg-4-1   42.0-2
ii  libgnome-bluetooth-ui-3.0-13  42.0-5
ii  libgnome-desktop-4-1  42.0-2
ii  libgnome-rr-4-1   42.0-2
ii  libgnutls30   3.7.4-2
ii  libgoa-1.0-0b 3.44.0-1
ii  libgoa-backend-1.0-1  3.44.0-1
ii  libgsound01.0.3-2
ii  libgtk-3-03.24.33-1
ii  libgtk-4-14.6.2+ds-1
ii  libgtop-2.0-112.40.0-2
ii  libgudev-1.0-0237-2
ii  libibus-1.0-5 1.5.26-4
ii  libkrb5-3 1.19.2-2+b1
ii  libmalcontent-0-0 0.10.4-1
ii  libmm-glib0   1.18.6-2
ii  libnm01.36.4-2
ii  libnma-gtk4-0 1.8.38-1
ii  libpango-1.0-01.50.6+ds-2
ii  libpangocairo-1.0-0   1.50.6+ds-2
ii  libpolkit-gobject-1-0 0.105-33
ii  libpulse-mainloop-glib0   15.0+dfsg1-4
ii  libpulse0 15.0+dfsg1-4
ii  libpwquality1 1.4.4-1+b1
ii  libsecret-1-0 0.20.5-2
ii  libsmbclient  2:4.16.0+dfsg-6
ii  libudisks2-0  2.9.4-1
ii  libupower-glib3   0.99.17-1
ii  libwacom9 2.2.0-1
ii  libx11-6  2:1.7.5-1
ii  libxi62:1.8-1
ii  libxml2   2.9.13+dfsg-1

Versions of packages gnome-control-center recommends:
pn  cracklib-runtime  
ii  cups-pk-helper0.2.6-1+b1
ii  gkbd-capplet  3.26.1-2
ii  gnome-online-accounts 3.44.0-1
ii  gnome-user-docs   42.0-1
ii  gnome-user-share  3.34.0-5
ii  iso-codes 4.9.0-1
pn  libnss-myhostname 
pn  malcontent-gui
ii  network-manager-gnome 1.26.0-1
ii  policykit-1   0.105-33
pn  power-profiles-daemon 
ii  pulseaudio-module-bluetooth   15.0+dfsg1-4
pn  realmd
ii  rygel 0.40.3-1+b1
ii  rygel-tracker 0.40.3-1+b1
ii  system-config-printer-common  1.5.16-1

Versions of packages gnome-control-center suggests:
ii  gnome-software   42.0-1
pn  gstreamer1.0-pulseaudio  
ii  x11-xserver-utils7.7+9

-- no debconf information

Bug#654542: Please mention "dirname" in description of printf %h

[Josh Triplett]

On Fri, Apr 15, 2022 at 02:17:30PM +0200, Andreas Metzler wrote:
> On 2012-01-04 Josh Triplett  wrote:
> > The find manpage says:
> 
> > > %h Leading  directories of file's name (all but the last element).
> > > If the file name contains no slashes (since it is in the current
> > > directory) the %h specifier expands to ".".
> 
> > Please consider using the standard term "dirname" in this description,
> > to make it easier to find.
> 
> Nowadays the paragraph reads:
> h Dirname; the Leading directories of the file's name  (all
>   but  the  last  element).   If  the file name contains no
>   slashes (since it is in the  current  directory)  the  %h
>   specifier expands to `.'.

Thank you!

Bug#654541: Please mention "basename" in description of %f printf option

[Josh Triplett]

On Fri, Apr 15, 2022 at 02:21:52PM +0200, Andreas Metzler wrote:
> On 2012-01-04 Josh Triplett  wrote:
> > The find manpage says:
> 
> > > %f File's name with any leading directories removed (only the last 
> > > element).
> 
> > Please consider using the standard term "basename" in this description,
> > to make it easier to find when searching.
> 
> Hello,
> 
> the paragraph now reads
> %f Print the basename; the file's name with any leading  di‐
>rectories  removed  (only  the last element).  For /, the
>result is `/'.  See the EXAMPLES section for an example.

Thank you!

Bug#996326: musl: static PIE does not work

[Josh Triplett]

tags 996326 + patch
thanks

On Wed, 13 Oct 2021 03:07:50 +0200 Thorsten Glaser  wrote:
> Supposedly, all versions since stretch/bionic should be able
> to do static PIE, at least as far as my research shows me, but
> I either can’t seem to figure it out, or it’s plain broken.
> 
> Both of…
>  musl-gcc -fPIE -static-pie -o foo foo.c -v -fno-lto
>  musl-gcc -fPIE -static -static-pie -o foo foo.c -v -fno-lto
> … fail, as the -v shows, it passes -dynamic-linker and doesn’t
> pick rcrt0. (The -fno-lto makes the output marginally more
> legible so I included it in an otherwise minimal example.)
> 
> The first generates a dynamically linked(?) PIE executable that
> lintian detects as a shared library not linked against (g)libc,
> the second is… I don’t even know; file says static but it doesn’t
> have the right crt objects but *has* -dynamic-linker…
> 
> So how can we get static PIE with musl on Debian, and in which
> releases?

There's a patch available at
https://src.fedoraproject.org/rpms/musl/blob/rawhide/f/musl-1.2.0-Support-static-pie-with-musl-gcc-specs.patch
that should make static-pie work.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On April 8, 2022 6:31:27 AM PDT, Wookey  wrote:
>If they want to prove that no patches for the current approach will
>ever be accepted, that can only be done by engaging further. Yes it
>will be hard work, but if it's not done we are just stuck. 

It sounds like at least one patch has already been rejected, not with comments 
about the patch needing work (which it absolutely does), but AIUI with 
"usrmerge is broken by design". That seems like sufficient proof that the 
problem is not a lack of engagement or patches. I don't think it's reasonable 
to expect further one-sided engagement by way of further "proof" of futility. 
That's leaving aside the (likely also accurate) expectation based on reported 
experiences with multiarch that any patch will go through extreme amounts of 
rework and iteration in that hostile environment, even *if* there were enough 
trust left to expect good faith.

I would love to see some engagement from the dpkg side, beyond reverting NMUs 
and subverting project decisions. Literally a single sentence would largely 
solve this: "as much as I disagree with this decision, I will stop shipping or 
recommending dpkg-fsys-usrunmess, and I will merge a reasonable patch to 
support usrmerge via directory symlinks in dpkg".

In the absence of such engagement, it would help if the TC provided the 
equivalent of both halves of that statement. But in either case, I think it's 
reasonable to not expect people to enthusiastically participate in a hostile 
and gruelling development environment in dpkg in the wake of a TC override 
(whether the one mentioned here or the one that has already taken place).

Bug#1008815: Followup: screencast starts the first time but creates empty

[Josh Triplett]

file
Reply-To: 

Following up on this: the *first* time I try starting a screencast after
restarting GNOME, it appears to start, and shows a recording icon in the
top bar, but the resulting file is empty (0 bytes), and the log says:

"Error stopping screencast: Timeout was reached"

The second and subsequent times, I get the previously reported error,
and the screencast doesn't appear to even start, and no file gets
created at all.

Bug#1008815: Unable to record screencast: "Error starting screencast"

[Josh Triplett]

Package: gnome-shell
Version: 42.0-2
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

When trying to record a screencast, I got the following non-specific
error in the logs:

gnome-shell[787]: Error starting screencast

And the screencast didn't start recording.



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.16.0-6-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-shell depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  evolution-data-server3.44.0-3
ii  gir1.2-accountsservice-1.0   22.07.5-1
ii  gir1.2-adw-1 1.1.0-1
ii  gir1.2-atk-1.0   2.38.0-1
ii  gir1.2-atspi-2.0 2.44.0-3
ii  gir1.2-freedesktop   1.72.0-1+b1
ii  gir1.2-gcr-3 3.40.0-4
ii  gir1.2-gdesktopenums-3.0 42.0-1
ii  gir1.2-gdkpixbuf-2.0 2.42.8+dfsg-1
ii  gir1.2-gdm-1.0   42.0-1
ii  gir1.2-geoclue-2.0   2.5.7-3
ii  gir1.2-glib-2.0  1.72.0-1+b1
ii  gir1.2-gnomebluetooth-3.042.0-3
ii  gir1.2-gnomedesktop-3.0  42.0-1
ii  gir1.2-graphene-1.0  1.10.8-1
ii  gir1.2-gstreamer-1.0 1.20.1-1
ii  gir1.2-gtk-3.0   3.24.33-1
ii  gir1.2-gtk-4.0   4.6.2+ds-1
ii  gir1.2-gweather-4.0  4.0.0-1
ii  gir1.2-ibus-1.0  1.5.26-2
ii  gir1.2-mutter-10 42.0-3
ii  gir1.2-nm-1.01.36.4-1
ii  gir1.2-nma-1.0   1.8.36-1
ii  gir1.2-pango-1.0 1.50.6+ds-2
ii  gir1.2-polkit-1.00.105-33
ii  gir1.2-rsvg-2.0  2.52.5+dfsg-3+b1
ii  gir1.2-soup-2.4  2.74.2-3
ii  gir1.2-upowerglib-1.00.99.17-1
ii  gir1.2-webkit2-4.0   2.36.0-2
ii  gnome-backgrounds42.0-1
ii  gnome-settings-daemon42.1-2
ii  gnome-shell-common   42.0-2
ii  gsettings-desktop-schemas42.0-1
ii  gstreamer1.0-pipewire0.3.49-1
ii  libatk-bridge2.0-0   2.38.0-4
ii  libatk1.0-0  2.38.0-1
ii  libc62.33-7
ii  libcairo21.16.0-5
ii  libecal-2.0-13.44.0-3
ii  libedataserver-1.2-263.44.0-3
ii  libgcr-base-3-1  3.40.0-4
ii  libgdk-pixbuf-2.0-0  2.42.8+dfsg-1
ii  libgirepository-1.0-11.72.0-1+b1
ii  libgjs0g 1.72.0-2
ii  libgles2 1.4.0-1
ii  libglib2.0-0 2.72.0-1
ii  libglib2.0-bin   2.72.0-1
ii  libgnome-autoar-0-0  0.4.3-1
ii  libgnome-desktop-3-1942.0-1
ii  libgraphene-1.0-01.10.8-1
ii  libgtk-3-0   3.24.33-1
ii  libgtk-4-1   4.6.2+ds-1
ii  libical3 3.0.14-1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmutter-10-0   42.0-3
ii  libnm0   1.36.4-1
ii  libpango-1.0-0   1.50.6+ds-2
ii  libpangocairo-1.0-0  1.50.6+ds-2
ii  libpolkit-agent-1-0  0.105-33
ii  libpolkit-gobject-1-00.105-33
ii  libpulse-mainloop-glib0  15.0+dfsg1-4
ii  libpulse015.0+dfsg1-4
ii  libsecret-1-00.20.5-2
ii  libsystemd0  250.4-1
ii  libwayland-server0   1.20.0-1
ii  libx11-6 2:1.7.4-1
ii  libxfixes3   1:6.0.0-1
ii  python3  3.10.4-1

Versions of packages gnome-shell recommends:
pn  bolt  
pn  chrome-gnome-shell
ii  gdm3  42.0-1
ii  gkbd-capplet  3.26.1-2
ii  

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, Mar 24, 2022 at 11:56:02PM -0700, Josh Triplett wrote:
> On Tue, Mar 15, 2022 at 03:14:37PM -0700, Josh Triplett wrote:
> > It would appear that the situation has deteriorated further. dpkg 1.21.2
> > now issues a warning on all merged-usr systems:
> > 
> > Setting up dpkg (1.21.2) ...
> > dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
> > dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.
> 
> Update: in dpkg 1.21.3, the warning now reads:
> 
> dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind 
> dpkg's
> dpkg: warning: back, breaking its core assumptions. This can cause silent file
> dpkg: warning: overwrites and disappearances, and its general tools 
> misbehavior.
> dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.
> 
> While more explicit, I think the issue remains, both with this message
> and with the page it links to.

Update: we're now even further into full-blown "fights in the archive"
territory:

https://lists.debian.org/debian-devel-changes/2022/03/msg03658.html
Changed-By: Bastian Blank 
Changes:
 dpkg (1.21.5+nmu1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Revert rebellion against CTTE decision #994388:
 - Remove warning about unsupported system.
 - Don't install dpkg-fsys-usrunmess.

https://lists.debian.org/debian-devel-changes/2022/03/msg03660.html
Changed-By: Guillem Jover 
Changes:
 dpkg (1.21.6) unstable; urgency=medium
 .
   - This also clears a bullying NMU. -
 .
   [ Guillem Jover ]
   * Documentation:
 - man: Document untracked kernel module files handling in
   dpkg-fsys-usrunmess(8).

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Fri, 25 Mar 2022 11:05:26 -0600 Gunnar Wolf  wrote:
> However, even given his attitude, I trust he would apply a correctly
> done patch addressing the issue at hand.

I just read the dpkg git commit
(57e084a52e1ede33b7914c3e0357311ac370a186) that added this warning in
the first place. Quoting the commit message:

> debian: Warn in postinst about merged-/usr-via-aliased-dirs breakage
>
> dpkg does not, and has never supported this filesystem layout even less
> so the way it has been deployed as it bypasses dpkg entirely. It can
> cause file loss, file overwrites, unexpected query results, among other
> things, while being very insidious to detect if one is not aware. Adding
> support for it would be rather infeasible and gets in the way of features
> that have been on the works for some time now.

The last sentence ("Adding support for it would be rather infeasible and
gets in the way of features that have been on the works for some time
now.") would seem to be an objection to adding such support even given a
patch.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Tue, Mar 15, 2022 at 03:14:37PM -0700, Josh Triplett wrote:
> It would appear that the situation has deteriorated further. dpkg 1.21.2
> now issues a warning on all merged-usr systems:
> 
> Setting up dpkg (1.21.2) ...
> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
> dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.

Update: in dpkg 1.21.3, the warning now reads:

dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind dpkg's
dpkg: warning: back, breaking its core assumptions. This can cause silent file
dpkg: warning: overwrites and disappearances, and its general tools misbehavior.
dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.

While more explicit, I think the issue remains, both with this message
and with the page it links to.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 19:24:02 -0700 Sean Whitton  
wrote:
> This is how I see it as well.  Putting aside the postinst warning, the I
> can't see anything the TC could do beyond what we've already done, until
> there's a patch on the table.

I'm glad to hear that the postinst warning is something that could be
addressed regardless.

But also, given that the postinst warning occurred after the previous TC
ruling, I don't think the previous TC ruling alone gives sufficient
confidence that a patch would not be ignored or rejected. I don't think
anyone is expecting the TC to pre-approve a patch sight-unseen; rather,
in the past the TC has used wordings like "merging reasonable
contributions" to give some indication of what the TC expects.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 16:22:38 -0700 Russ Allbery  wrote:
> Luca Boccassi  writes:
> 
> > If it was possible to do it, it would have already happened, and we
> > wouldn't be discussing it at all, it would have just been done.
> 
> Has someone written a patch against dpkg that causes it to do the right
> thing?
> 
> > In the end, at the very least this is a _workable_ proposal. It might
> > not be ideal, but we know it can work. What's your counter-proposal?
> 
> Someone who believes strongly in merged-/usr should write a patch against
> dpkg that causes it to work properly with merged-/usr, including edge
> cases like files moving out of /bin and /lib between packages and dpkg -S
> working properly.
> 
> I understand that you don't think that patch will be accepted.  But we
> don't actually know that since so far as I know it doesn't exist.  We're
> arguing in the abstract about a future problem that hasn't happened yet
> because we don't have working code to argue about.

I think it's appropriate for people to wait on such work until there's
guidance from the TC ensuring that such a patch will be accepted.
Otherwise, anyone spending time writing it is spending substantial
effort that may well be wasted.

I am also hoping that such a patch is not a precondition for removing
the message from the current dpkg maintainer script, which is already
causing issues.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, Mar 24, 2022 at 01:24:39PM -0700, Russ Allbery wrote:
> Josh Triplett  writes:
> > On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery  wrote:
> 
> >> That said, I personally am disappointed that the folks who have been
> >> pushing merged-/usr forward are willing to leave dpkg in a known-buggy
> >> state without attempting to patch it to fix the remaining issues.  I
> >> realize that there are various obstacles in successfully doing that,
> >> not all of which are technical,
> 
> > I don't think "willing to" is a fair characterization here.
> 
> It's possible that you haven't seen the discussions that I've been in, but
> whenever I point out that this hasn't been fixed and that we should fix
> it, I am told, often quite emphatically, that Ubuntu has never seen any
> problems and therefore this problem is not important and no one needs to
> fix it.  It's hard for me not to characterize this as "willing to" leave
> dpkg in a state that I'd characterize as buggy.

I've certainly seen people state that the issues aren't important and
shouldn't be treated as blockers. I haven't seen people assert that
there are no issues at all without being corrected, just that they're
not important issues and not blockers. (That of course does not mean it
hasn't happened.) And I haven't seen assertions that we *shouldn't* fix
dpkg if dpkg is actually amenable to fixing.

If nothing else, the behavior of `dpkg -S` seems like a clear
counterexample that anyone on a usrmerge'd system can easily observe
themselves, leaving aside the more subtle issues with file migrations
and file conflicts. The debate over the severity of those issues seems
like it took place as part of the previous decision, though.

> I certainly agree that there are also other challenges in fixing dpkg.
> However, it would be nice if we could at least agree that it's necessary
> to fix dpkg, rather than arguing that it's fine to leave it in its current
> state.  (In fact, I suspect this belief that the current state is fine and
> reasonable to leave things in permanently is part of what's making it
> harder to discuss how to best fix dpkg in a way that is sustainable and
> supportable going forward.)

That's fair. It wouldn't surprise me at all if there are *multiple*
non-technical factors playing off each other here: expectation that
patches would be rejected, conflation between "not a blocker" and "not
an issue at all", and just general aversion to getting in the middle of
a flamewar-inviting issue. I do think this has become an adversarial
issue and gotten escalated excessively, which has absolutely compromised
the ability and inclination to fix it.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 10:35:10 -0700 Russ Allbery  wrote:
> I think this accidentally confuses the related states of "unsupported" and
> "buggy."  We know that merged-/usr is buggy, in that one can construct a
> set of package operations that leave the system in an invalid state.  We
> have a project disagreement over how serious those bugs are.  No one is
> stepping forward to fix those bugs, which is indeed quite unfortunate.  I
> personally strongly disagree with the belief that simply because Ubuntu
> hasn't seen many instances of this class of bugs while using a package set
> where people have not moved files between packages and out of /lib and
> /bin very much if at all, it is acceptable to leave dpkg in that buggy
> state.
> 
> However, I think this is similar to many other disagreements over the
> severity of bugs, particularly ones that are hard to fix.  It doesn't
> really imply that this configuration is *unsupported*, which would mean
> that if someone had a system in that state and reported a problem we would
> say that we couldn't help them because their system is not in a supported
> configuration.  This is not the case; merged-/usr is supported in that
> sense.  Guillem may not be willing to support the user in that case but
> other people most certainly would.
> 
> That said, I personally am disappointed that the folks who have been
> pushing merged-/usr forward are willing to leave dpkg in a known-buggy
> state without attempting to patch it to fix the remaining issues.  I
> realize that there are various obstacles in successfully doing that, not
> all of which are technical,

I don't think "willing to" is a fair characterization here. It does not
seem at all obvious that such patches would have been accepted, given
the repeated vehement objections from the dpkg maintainer about the
chosen approach. Those objections did not invite contribution; at every
point, the assertion was that usrmerge was broken, not that dpkg needed
help supporting it. In particular, while I've seen the dpkg maintainer
call for implementing *different* approaches to merged /usr, I have not
seen even the slightest hint that patches implementing merged /usr in
the fashion the TC decided upon would be accepted.

I think those who might otherwise have been willing to write such
patches could be forgiven for thinking they'd be unwelcome.

I'm hoping that the TC may be able to address that exact issue.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On Thu, 24 Mar 2022 18:56:54 +0100 Helmut Grohne  wrote:
> On Thu, Mar 24, 2022 at 09:31:21AM -0700, Sean Whitton wrote:
> > We should distinguish two senses of "supported".
> > 
> > There is the sense of what Debian-the-project supports.  That is
> > specified in the TC decision.  That is not subjective.
> 
> This could be a language issue on my side. As I see it, the Debian
> project clearly endorses merged-/usr. I have difficulties calling it
> support, because that would go in hand with fixing the resulting
> problems - which is not happening. In my reading, support is an activity
> rather than a statement. That activity is missing. I even ran into
> /usr-merge fallout in 2022 myself. The statement is clear enough and
> Guillem's warning is clearly not helping the state of affairs.
> 
> > The difficulty is that Guillem's warning kind of refers to both.
> 
> Yeah, I see how you get there. It is fully in line with the confusion I
> see elsewhere.
> 
> Let us try to turn this upside down: How can Guillem express his
> dissatisfaction with the current process in a way that does not cause
> harm? Guillem has to deal with quite a number of /usr-merge-caused bugs.
> Many of them lack patches and/or are duplicating existing ones. In cases
> patches were posted (e.g. dpkg-shlibdeps), Guillem has included them.

There are two separate issues here: dissatisfaction with Debian's chosen
approach to the /usr-merge issue, and dissatisfaction with dpkg not
natively supporting Debian's chosen approach.

For the former, that decision is made, and while anything can be
*discussed* and a new decision could theoretically be made in the
future, that doesn't change or invalidate the decision as already made.
Delete the "usrunmess" script and most of the contents of the Dpkg
usrmerge "FAQ".

For the latter, that's *absolutely* reasonable. Even if (as extensively
discussed) larger issues don't tend to arise in practice, there are real
issues such as `dpkg -S` not handling search paths as expected (`dpkg -S
/bin/ls` vs `dpkg -S /usr/bin/ls`), as well as issues making it harder
to migrate packages to "natively" have files in /usr eventually. And if
users are filing bugs about such issues, it'd be entirely reasonable to
close or merge such bugs, referencing to one or a few bugs tracking the
lack of usrmerge support.

It would also be entirely reasonable to call for help fixing such
issues. It's entirely possible that someone would have written dpkg
patches *already*, if the pitched battles over usrmerge hadn't made it
abundantly clear how such patches would be received (and, at the moment,
likely *still* would be received). I think that has unnecessarily
delayed any efforts to actually help with this.

The maintainer script was not such a call for help, at all. And it has
already caused harm, and is continuing to do so.

As it stands, I think the path forward would be:

1) Delete the message from the maintainer script, immediately, and
   upload a new version of dpkg with that message removed. Don't add any
   new such user-targeted messages in that or other places (e.g.
   Description).
2) Issue a call for help *supporting* the established approach to
   usrmerge, not subverting and relitigating it.
   2.1) Make it clear that dpkg patches to fix issues related to
usrmerge, as well as updates to the documentation (including the
wiki), will not be unreasonably blocked on the basis of dislike
for usrmerge. (This will be necessary to make (2) successful.)
3) Delete `dpkg-fsys-usrunmess`.
4) File one or more bugs, or select existing representative bugs that
   don't have too much noise in them, about dpkg support for usrmerge
   (ranging from `dpkg -S` to the handling of files moving from / to
   /usr to the handling of file conflicts between packages).
5) Close or merge any new and existing dpkg bugs about merged /usr,
   pointing to the appropriate representative bug(s).

I think it would be appropriate for the TC to issue a ruling regarding
points (1), (2.1), and (3) above, and optionally to issue advice
suggesting (2), (4), and (5).

Bug#810018: Bug #810018: Consider shipping pidof with procps

[Josh Triplett]

On Mon, Mar 21, 2022 at 02:01:14PM +0100, Andreas Henriksson wrote:
> On Mon, Mar 21, 2022 at 10:34:58AM +, Mark Hindley wrote:
> > Craig,
> > 
> > Thanks for this.
> > 
> > This dates from before my detailed involvement with this area of Debian. I 
> > have
> > read through the bug report, but apologies if I have missed pertinent 
> > detail.
> []
> >  3) A desire to reduce the Essential set.
> > 
> > I understand and appreciate the general motivation for this. However, 
> > moving
> > pidof to procps would make procps Essential and it is already about 20 
> > times
> > bigger than sysvinit-utils, so it does not achieve the aim.
> [...]
> 
> I don't see why you think pidof (and thus entire procps) must be
> Essential. That would indeed be counter-productive. (I haven't re-read
> the discussion, but I'm pretty sure we already covered this.)
> 
> As I've already proven elsewhere sysvinit-utils (with or without pidof,
> which AFAIR is the only semi-useful utility left in that binary package)
> can be made non-essential without any problems already.
> 
> > What do you think?
> 
> I think apart from reducing the essential set, it is also useful to
> eliminate pointless differences.
> 
> The distributions I've looked at (that are not just following along as a
> debian derivate) uses procps pidof already.

Exactly. And there have already been issues in which pidof's behavior
changed in unexpected ways because of the needs of sysvinit (e.g.
https://bugs.debian.org/926896 ). Decoupling the two makes such issues
less likely, and removes the one way in which systems not otherwise
using sysvinit have a dependency on sysvinit components.

I wouldn't expect procps to become essential; ideally packages that use
pidof in scripts would add an appropriate dependency. (This would help
people building minimal containers/chroots.) But orthogonally, I think
there's value in migrating pidof to procps.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

On March 15, 2022 11:38:44 PM PDT, Sean Whitton  
wrote:
>Hello Josh,
>
>On Tue 15 Mar 2022 at 03:14pm -07, Josh Triplett wrote:
>
>> It would appear that the situation has deteriorated further. dpkg 1.21.2
>> now issues a warning on all merged-usr systems:
>>
>> Setting up dpkg (1.21.2) ...
>> dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
>> dpkg: warning: See <https://wiki.debian.org/Teams/Dpkg/FAQ#broken-usrmerge>.
>
>Does this happen just when configuring dpkg.deb here, or does the
>warning get issued at other times, have you seen?
>

Just dpkg. It's mentioned in the changelog.

Bug#994388: dpkg currently warning about merged-usr systems

[Josh Triplett]

It would appear that the situation has deteriorated further. dpkg 1.21.2
now issues a warning on all merged-usr systems:

Setting up dpkg (1.21.2) ...
dpkg: warning: System unsupported due to merged-usr-via-aliased-dirs.
dpkg: warning: See .

This escalation seems in direct contradiction to the tech-ctte decision
in 994388. Moreover, this seems to effectively use package maintainer
scripts as a means of directing a complaint at Debian users that has not
gotten traction in other forums, and then directing such users at a wiki
page that contradicts a prior project decision.

This does not even seem to be calling for help in any meaningful way.
For instance, soliciting help updating dpkg to handle such
configurations might have been more productive; that still wouldn't be
appropriate in a maintainer script, but it might have been productive in
a mail to -devel. But this isn't soliciting help, it's just incorrectly
declaring the user's system broken.

This seems counterproductive and harmful.

Bug#554006: lintian: Warn if package ships files in /etc/cron.* without depending on cron

[Josh Triplett]

On Mon, Mar 14, 2022 at 05:36:38PM -0700, Felix Lechner wrote:
> Hi,
> 
> On Mon, Mar 14, 2022 at 1:36 PM Josh Triplett  wrote:
> >
> > I don't think lintian should warn about this, for two reasons:
> 
> Are you saying the condition should indicate a visibility level lower
> than a warning, or that the tag should not be implemented at all?
> Thank you!

The latter; I don't think lintian should implement this at all. Lintian
doesn't have any means of knowing whether a cron script is a core part
of a package's functionality, or if it's entirely optional.

Bug#1007257: Please upgrade missing-systemd-timer-for-cron-script to a warning

[Josh Triplett]

Package: lintian
Version: 2.114.0
Severity: wishlist
X-Debbugs-Cc: j...@joshtriplett.org

Please consider upgrading the lintian tag
missing-systemd-timer-for-cron-script to a warning.

This would help encourage packages to add such timers, which long-term
may allow cron to become optional, at least on systemd systems.

Note that doing so does not introduce any new dependencies on systemd:
packages adding systemd timers in parallel with cron scripts need not
depend on systemd, even if the periodic job is non-optional. (And since
cron scripts are in any case system configuration in /etc, packages
already need to be prepared for a sysadmin to disable or edit such
scripts.) In some cases, packages may need to downgrade dependencies on
cron or add alternatives.

Bug#554006: lintian: Warn if package ships files in /etc/cron.* without depending on cron

[Josh Triplett]

I don't think lintian should warn about this, for two reasons:

- It's possible to have an *optional* cron script, not required for
  package functionality, which might warrant at most a `Suggests`.
- If a script ships both a cron script and a systemd .timer file, it
  need not depend on cron.

Bug#1006251: USB Lenovo ThinkPad Compact Keyboard has fn_lock inverted

[Josh Triplett]

Package: src:linux
Version: 5.16.7-2
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

I have an external ThinkPad USB keyboard:

$ lsusb | grep -i keyboard
Bus 003 Device 022: ID 17ef:6047 Lenovo ThinkPad Compact Keyboard with 
TrackPoint

The Linux kernel exposes a fn_lock attribute in sysfs for this keyboard:

$ cat 
/sys/devices/pci:00/:00:14.0/usb3/3-5/3-5.4/3-5.4.3/3-5.4.3:1.1/0003:17EF:6047.000F/fn_lock
1

However, this attribute appears inverted for this particular keyboard:
it seems to be 1 when FnLock is *disabled* and 0 when FnLock is
*enabled*.

Bug#1005848: ThinkPad TrackPoint Keyboard II middle-mouse scrolling can't scroll horizontally

[Josh Triplett]

Source: libinput
Version: 1.16.4-3
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

I have the external wireless "ThinkPad TrackPoint Keyboard II"
(https://www.lenovo.com/us/en/p/accessories-and-software/keyboards-and-mice/keyboards/4y40x49493).

With this keyboard, middle-mouse scrolling works only vertically. In the
past, with a different keyboard/mouse combo device (a wired external
ThinkPad keyboard), I've been able to scroll both horizontally and
vertically. I don't know if this is an issue with the handling of this
model, or an issue that changed in libinput.

- Josh Triplett

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#1005847: ThinkPad TrackPoint Keyboard II middle-mouse scrolling also clicks

[Josh Triplett]

Source: libinput
Version: 1.16.4-3
Severity: important
X-Debbugs-Cc: j...@joshtriplett.org

I have the external wireless "ThinkPad TrackPoint Keyboard II"
(https://www.lenovo.com/us/en/p/accessories-and-software/keyboards-and-mice/keyboards/4y40x49493).

With this keyboard, middle-mouse scrolling *also* sends a middle-click,
which often has the net effect of triggering a paste in addition to
scrolling. This has the potential for unwanted information disclosure
(e.g. passwords), hence the severity.

In the past, with a different keyboard (a wired external ThinkPad
keyboard), middle-mouse scrolling avoids sending a middle-click, and
thus avoids triggering things like middle-mouse paste or opening a new
tab.

I don't know if this is an issue with the handling of this model, or an
issue that changed in libinput.

- Josh Triplett

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.16.0-1-amd64 (SMP w/8 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#914799: dbus: Privacy violations: Logs detailed commands and parameters

[Josh Triplett]

Package: dbus-daemon
Version: 1.12.20-3
Followup-For: Bug #914799
X-Debbugs-Cc: j...@joshtriplett.org

It seems like there's a potential balance here: logging the command name
(e.g. evince, okular) seems fine, it's the command *parameters* that
represent a potential privacy issue (in the same spirit as "recent
documents").

Yes, comm is readily available to another user or administrator on the
same system at the same time. But that's not the same as being available
to a user or administrator who does not have concurrent access to the
system, as is commonly the case for many single-user systems.

I'm hoping that changing dbus-daemon to only log the command name and
not the arguments would not generate awful bug reports in the other
direction.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.15.0-3-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages dbus-daemon depends on:
ii  dbus-bin 1.12.20-3
ii  dbus-session-bus-common  1.12.20-3
ii  libapparmor1 3.0.3-6
ii  libaudit11:3.0.6-1+b1
ii  libc62.33-5
ii  libcap-ng0   0.7.9-2.2+b1
ii  libdbus-1-3  1.12.20-3
ii  libexpat12.4.4-1
ii  libselinux1  3.3-1+b1
ii  libsystemd0  250.3-2

dbus-daemon recommends no packages.

dbus-daemon suggests no packages.

-- no debconf information

Bug#1002827: Should be in contrib; expects an installation of Steam

[Josh Triplett]

Package: proton-caller
Severity: serious
X-Debbugs-Cc: j...@joshtriplett.org

While portions of Proton are Open Source (being based on the LGPLed
Wine), proton-caller appears to specifically expect an installation of
Steam. The description says "Simply configure your Steam and common
directories", and the upstream documentation similarly talks about
configuring the path to a Steam installation.

- Josh


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages proton-caller depends on:
ii  libc6  2.33-1
ii  libgcc-s1  11.2.0-13

proton-caller recommends no packages.

proton-caller suggests no packages.

Bug#1001605: Custom terminal title corrupted

[Josh Triplett]

Package: gnome-terminal
Version: 3.42.2-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

After upgrading to current gnome-terminal, custom terminal titles now
appear heavily corrupted, with almost any non-alphabetic character
replaced with an unusual symbol or with nothing. For instance, / gets
replaced with what looks similar to a comma.

I've attached a screenshot of a few tabs showing this.

- Josh Triplett

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.15.0-2-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gnome-terminal depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.20-3
ii  dbus-x11 [dbus-session-bus]   1.12.20-3
ii  dconf-gsettings-backend [gsettings-backend]   0.40.0-2
ii  gnome-terminal-data   3.42.2-1
ii  gsettings-desktop-schemas 41.0-2
ii  libatk1.0-0   2.36.0-3
ii  libc6 2.32-5
ii  libdconf1 0.40.0-2
ii  libgcc-s1 11.2.0-12
ii  libglib2.0-0  2.70.2-1
ii  libgtk-3-03.24.30-4
ii  libpango-1.0-01.48.10+ds1-1
ii  libstdc++611.2.0-12
ii  libuuid1  2.37.2-4
ii  libvte-2.91-0 0.66.2-1
ii  libx11-6  2:1.7.2-2+b1

Versions of packages gnome-terminal recommends:
ii  gvfs   1.48.1-2
pn  nautilus-extension-gnome-terminal  
ii  yelp   41.2-1

gnome-terminal suggests no packages.

-- no debconf information

Bug#1000730: Merge conflict marker left in Debian changelog

[Josh Triplett]

Package: libreoffice
Version: 1:7.2.3-1
Severity: normal
X-Debbugs-Cc: j...@joshtriplett.org

The Debian changelog for libreoffice contains what looks like a merge
conflict marker around the entry for 1:7.3.0~alpha1-2:

libreoffice (1:7.3.0~alpha1-2) experimental; urgency=medium

  * debian/rules:
- use --without-cppunit in build-indep
- use clang 12 on ppc64el (if building with LTO at least)
- fix autopkgtest builds; explicitely set PACKAGE_SDK_DOCS=n

 -- Rene Engelhard   Sun, 31 Oct 2021 09:25:30 +0100
>>> efaacb77 (actually only set TEST_TIMEOUT if we ignore the test results 
>>> anyway...)

  * debian/control*.in: also apply 1:7.2.1-2/-3 changes for
libreoffice-core-nogui...

 -- Rene Engelhard   Thu, 18 Nov 2021 18:50:36 +0100

libreoffice (1:7.2.2-1) unstable; urgency=medium

Bug#998108: reopening 998108

[Josh Triplett]

reopen 998108 94.0-2
thanks

I'm still experiencing this bug regularly, with complete browser UI
freezes that require killing and restarting Firefox.

WebGL or video seems to trigger it more often, as does opening a new
tab. Browsing on an existing tab doesn't tend to trigger it.

Bug#999777: 6.3-1 breaks scrolling in neovim on gnome-terminal with vertical splits

[Josh Triplett]

On Tue, 16 Nov 2021 23:00:08 +0100 Sven Joachim  wrote:
> On 2021-11-16 21:53 +0100, Josh Triplett wrote:
> 
> > On Tue, Nov 16, 2021 at 08:02:53PM +0100, Sven Joachim wrote:
> >> On 2021-11-16 16:30 +0100, Josh Triplett wrote:
> >>
> >> > Package: libncursesw6
> >> > Version: 6.3-1
> >> > Severity: important
> >> > X-Debbugs-Cc: j...@joshtriplett.org
> >> >
> >> > "important" because this makes neovim nearly unusable; not RC because
> >> > I've only observed it with one combination of terminal and program. I
> >> > personally think that might still be enough to make it RC until
> >> > root-caused to determine if it's breaking anything else.
> >> >
> >> > Steps to reproduce:
> >> >
> >> > - `nvim -u NONE` (to ignore any .vimrc)
> >> > - :%!seq 1000
> >> > - :vert new
> >> > - :%!seq 1000
> >> > - Hit page-down
> >> > - Observe the other side of the split (as well as the vertical bar
> >> >   between the split windows) scrolling off the screen.
> >> >
> >> > Downgrading the ncurses packages to 6.2+20210905-1 makes the problem
> >> > disappear; re-upgrading to 6.3-1 makes it come back.
> >>
> >> This is rather surprising, because neovim does not depend on
> >> libncursesw6, not even on libtinfo6.  Did you up-/downgrade
> >> ncurses-{base,term} as well, and what is your $TERM?
> >
> > I downgraded by installing all seven of:
> >
> > libncurses6_6.2%2B20210905-1_amd64.deb
> > libncursesw6_6.2%2B20210905-1_amd64.deb
> > libncurses-dev_6.2%2B20210905-1_amd64.deb
> > libtinfo6_6.2%2B20210905-1_amd64.deb
> > ncurses-base_6.2%2B20210905-1_all.deb
> > ncurses-bin_6.2%2B20210905-1_amd64.deb
> > ncurses-term_6.2%2B20210905-1_all.deb
> >
> > That made the issue disappear. Re-upgrading made the issue re-appear.
> 
> Did you also restart gnome-terminal?  I don't really see how that could affect
> the issue since nothing in its stack depends on ncurses, but I am
> completely at a loss here.

I just confirmed that upgrading *only* ncurses-base causes the issue to
appear, and downgrading *only* ncurses-base causes the issue to
disappear.

I did not restart gnome-terminal.

strace of `nvim -u NONE` confirms that it opens and reads
/lib/terminfo/x/xterm-256color . neovim depends on both libunibilium4
and libtermkey1, which use terminfo.

Bug#999777: 6.3-1 breaks scrolling in neovim on gnome-terminal with vertical splits

[Josh Triplett]

On Tue, Nov 16, 2021 at 08:02:53PM +0100, Sven Joachim wrote:
> On 2021-11-16 16:30 +0100, Josh Triplett wrote:
> 
> > Package: libncursesw6
> > Version: 6.3-1
> > Severity: important
> > X-Debbugs-Cc: j...@joshtriplett.org
> >
> > "important" because this makes neovim nearly unusable; not RC because
> > I've only observed it with one combination of terminal and program. I
> > personally think that might still be enough to make it RC until
> > root-caused to determine if it's breaking anything else.
> >
> > Steps to reproduce:
> >
> > - `nvim -u NONE` (to ignore any .vimrc)
> > - :%!seq 1000
> > - :vert new
> > - :%!seq 1000
> > - Hit page-down
> > - Observe the other side of the split (as well as the vertical bar
> >   between the split windows) scrolling off the screen.
> >
> > Downgrading the ncurses packages to 6.2+20210905-1 makes the problem
> > disappear; re-upgrading to 6.3-1 makes it come back.
> 
> This is rather surprising, because neovim does not depend on
> libncursesw6, not even on libtinfo6.  Did you up-/downgrade
> ncurses-{base,term} as well, and what is your $TERM?

I downgraded by installing all seven of:

libncurses6_6.2%2B20210905-1_amd64.deb
libncursesw6_6.2%2B20210905-1_amd64.deb
libncurses-dev_6.2%2B20210905-1_amd64.deb
libtinfo6_6.2%2B20210905-1_amd64.deb
ncurses-base_6.2%2B20210905-1_all.deb
ncurses-bin_6.2%2B20210905-1_amd64.deb
ncurses-term_6.2%2B20210905-1_all.deb

That made the issue disappear. Re-upgrading made the issue re-appear.

I'm using gnome-terminal, and my $TERM is xterm-256color. (I also tested
downgrading libvte, since it had recently been upgraded, but that did
not fix the issue.)

Bug#999777: 6.3-1 breaks scrolling in neovim on gnome-terminal with vertical splits

[Josh Triplett]

Package: libncursesw6
Version: 6.3-1
Severity: important
X-Debbugs-Cc: j...@joshtriplett.org

"important" because this makes neovim nearly unusable; not RC because
I've only observed it with one combination of terminal and program. I
personally think that might still be enough to make it RC until
root-caused to determine if it's breaking anything else.

Steps to reproduce:

- `nvim -u NONE` (to ignore any .vimrc)
- :%!seq 1000
- :vert new
- :%!seq 1000
- Hit page-down
- Observe the other side of the split (as well as the vertical bar
  between the split windows) scrolling off the screen.

Downgrading the ncurses packages to 6.2+20210905-1 makes the problem
disappear; re-upgrading to 6.3-1 makes it come back.

-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable'), (500, 'testing'), (1, 
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: arm64

Kernel: Linux 5.14.0-4-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libncursesw6 depends on:
ii  libc6  2.32-4
ii  libtinfo6  6.3-1

Versions of packages libncursesw6 recommends:
ii  libgpm2  1.20.7-9

libncursesw6 suggests no packages.

-- no debconf information

Bug#999420: dh_shlibdeps: Please consider option (or default) to ignore weak symbols for dependencies

[Josh Triplett]

Package: debhelper
Version: 13.5.2
Severity: wishlist
File: /usr/bin/dh_shlibdeps
X-Debbugs-Cc: j...@joshtriplett.org

When a program or library declares a weak symbol, that typically
indicates that it's prepared to do without the symbol.

However, dh_shlibdeps takes weak symbols into account when determining
library dependencies, and will produce a strict Depends on a library
even if only needed for a weak symbol. Some software (e.g. the Rust
standard library) works around this by calling dlsym instead, but that
introduces other potential issues, and weak symbols are *much* simpler
and easier to work with.

I'd like to propose changing this behavior, either with an option, or as
part of a future debhelper compatibility level (which could make that
option the default). I'd propose instead that dh_shlibdeps could
separate out dependencies from weak symbols, and put them in a separate
substitution field, which packagers could then choose to put in either
Depends or Recommends or Suggests or nowhere, as appropriate.

The net effect of this would be to broaden shared library dependencies,
making packages easier to install and backport, and making it easier for
upstreams to make use of weak symbols without introducing compatibility
issues.

- Josh Triplett

Bug#998108: Additional information: tab freezes first, then browser

[Josh Triplett]

Some additional information that might help track this down: several
times, I've observed one tab freezing, but the browser itself is still
responsive for a *short* time. I can open a new tab, and close it again,
and the previous tab then renders as a busy symbol.

I'm wondering if one of the tab processes or helper processes dies, and
then that grinds the browser to a halt but not instantly.