Hello!

After the following upgrade:

    [UPGRADE] libgdk-pixbuf-2.0-0:amd64 2.44.4+dfsg-1 -> 2.44.5+dfsg-3

the 'volumeicon' program (shipped by Debian package 'volumeicon-alsa')
can run, but fails to become visible in the systray, thus failing to
be of any use.

Downgrading libgdk-pixbuf-2.0-0 to version 2.44.4+dfsg-1 makes 'volumeicon'
work again as usual.

Please investigate and fix this bug and/or forward the bug report upstream,
as appropriate.

Thanks for your time and dedication!

Dear Maintainer,

Evince fails to start. Probably it is due to the same problem with
libgdk-pixbuf-2.0-0.

Error message:
Gtk:ERROR:../../../gtk/gtkiconhelper.c:495:ensure_surface_for_gicon:
assertion failed (error == NULL): Failed to load
/usr/share/icons/Tango/scalable/status/image-missing.svg: Could not
spawn `"bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/"
"--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try"
"/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store"
"/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv"
"--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run"
"--setenv" "XDG_RUNTIME_DIR" "/run/user/1000" "--symlink" "/usr/lib"
"/lib" "--symlink" "/usr/lib64" "/lib64" "--ro-bind-try"
"/etc/fonts/conf.d" "/etc/fonts/conf.d" "--ro-bind-try"
"/etc/fonts/fonts.conf" "/etc/fonts/fonts.conf" "--ro-bind-try"
"/home/simon/.cache/fontconfig" "/home/simon/.cache/fontconfig"
"--ro-bind-try" "/home/simon/.fontconfig" "/home/simon/.fontconfig"
"--ro-bind-try" "/home/simon/.fonts" "/home/simon/.fonts"
"--ro-bind-try" "/var/cache/fontconfig" "/var/cache/fontconfig"
"--bind-try"
"/home/simon/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg"
"/home/simon/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg"
"--setenv" "XDG_CACHE_HOME"
"/home/simon/.cache/glycin/usr/libexec/glycin-loaders/2+/glycin-svg"
"--seccomp" "21" "/usr/libexec/glycin-loaders/2+/glycin-svg" "--dbus-fd"
"20"`: Toegang geweigerd (os error 13) (gdk-pixbuf-error-quark, 0)

Update history:: Start-Date: 2026-02-14  13:41:31
Install: glycin-loaders:amd64 (2.0.7+ds-5, automatic),
glycin-thumbnailers:amd64 (2.0.7+ds-5, automatic), libglycin-2-0:amd64
(2.0.7+ds-5, automatic)
Upgrade: libgnome-desktop-3-20t64:amd64 (44.4-1+b1, 44.5-1),
gir1.2-gdkpixbuf-2.0:amd64 (2.44.4+dfsg-1, 2.44.5+dfsg-3),
libgdk-pixbuf-2.0-0:amd64 (2.44.4+dfsg-1, 2.44.5+dfsg-3),
dracut-install:amd64 (109-11, 110-1), gnome-desktop3-data:amd64 (44.4-1,
44.5-1), libgdk-pixbuf2.0-common:amd64 (2.44.4+dfsg-1, 2.44.5+dfsg-3)
Remove: libgdk-pixbuf2.0-bin:amd64 (2.44.4+dfsg-1)
End-Date: 2026-02-14  13:41:35

For evince see #1127935, which is fixed in unstable.

     smcv

Control: reassign -1 src:volumeicon 0.5.1+git20230228-1
Control: affects -1 = src:gdk-pixbuf

I'm reassigning to volumeicon for now. Debian's gdk-pixbuf 2.44.5
switched to glycin to provide image loaders. Some apps will need to
make adjustments.

Thank you,
Jeremy Bícha

Control: clone -1 -2
Control: reassign -2 libgdk-pixbuf-2.0-0 2.44.5+dfsg-3
Control: affects -2 = volumeicon-alsa
Control: retitle -2 uncoordinated transition causes other packages to break (e.g. volumeicon-alsa)
Control: block -2 by -1

It's OK to reassign, if the bug has to be fixed in 'volumeicon-alsa',
but please let's also keep an RC bug open in 'libgdk-pixbuf-2.0-0', so
that people (especially users of 'apt-listbugs') get warned not to
upgrade 'libgdk-pixbuf-2.0-0' until the 'volumeicon-alsa' is fixed...

Thanks a lot for your cooperation!

I knew that at some point it's going to happen -- that's why I've frozen this
libgdk-pixbuf-2.0-0 package on my machines (v. 2.44.4+dfsg-1). Probably many X
packages will be broken because of this libgdk-pixbuf-2.0-0 + glycin. The best
option would be just to build this libgdk-pixbuf-2.0-0 also as a separate
package without the whole glycin included. Otherwise we'll end up with a broken
minimal desktop environments like X/Openbox.


- -- System Information:
Debian Release: forky/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'buildd-unstable'), (500, 'testing'), (130, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages volumeicon-alsa depends on:
ii  libasound2t64        1.2.15.3-1
ii  libc6                2.42-13
ii  libcairo2            1.18.4-3
hi  libgdk-pixbuf-2.0-0  2.44.4+dfsg-1
ii  libglib2.0-0t64      2.87.2-3
ii  libgtk-3-0t64        3.24.51-4
ii  libnotify4           0.8.8-1
ii  libx11-6             2:1.8.12-1+b1

volumeicon-alsa recommends no packages.

Versions of packages volumeicon-alsa suggests:
pn  alsamixergui | aumix-gtk | kmix | gnome-alsamixer  <none>
ii  xfce4-notifyd [notification-daemon]                0.9.7-2

- -- no debconf information
-----BEGIN PGP SIGNATURE-----

iHQEARYKAB0WIQR1ZhNYxftXAnkWpwEy2ctjR5bMoQUCaZd5oAAKCRAy2ctjR5bM
oTuLAQDXsRiSfUETSZTnATKKL3iAwrl1V+g1T+7ee+LTQZQoPAD3dpfoW47ADdD9
VpMW9ocgQTQxXthskKAMWNTWJjkMCw==
=14bK
-----END PGP SIGNATURE-----

Currently, the only things known to be broken are volumeicon and some
AppArmor profiles. If you find any other breakage, please let Debian's
gdk-pixbuf maintainers know by filing a Debian bug against the broken
package and marking the bug as affecting gdk-pixbuf.

There are significant maintainability and security advantages to
gdk-pixbuf+glycin. Therefore, the Debian GNOME maintainers do not
currently see a need to provide gdk-pixbuf without glycin for Debian
release architectures any more starting with forky.

It looks like there isn't anyone able to fix volumeicon so its Debian
maintainer has requested its removal from unstable (and forky):
https://bugs.debian.org/1128879

Thank you,
Jeremy Bícha

And this is the real issue. My system is GNOME free and it's not just because I
don't like GNOME (once, I really liked gnome2). It's simply because I can't
confine apps in apparmor profiles under such desktop environments like GNOME or
KDE -- it's simply impossible. That's why I don't use these highly integrated
desktop environments -- I really like security.

When I upgraded the libgdk-pixbuf-2.0-0 package (to the one with glycin), my
system just died after reboot... And I asked myself WTF?  Then I found this
glycin change, and I googled it, and found out that it's a GNOME component. I
asked myself again -- WTF is GNOME doing on my machine? I checked APT for
packages related to GNOME, and I can't find anything. So this is the second
problem, which is that we're starting to have GNOME components in non-GNOME
environments -- it really sucks...

But let's focus on the very first problem. This whole glycin required me to add
many rules to many apparmor profiles -- my system currently have the following:

# aa-status | grep are
948 profiles are loaded.
774 profiles are in enforce mode.
104 profiles are in complain mode.
0 profiles are in prompt mode.
0 profiles are in kill mode.
70 profiles are in unconfined mode.
69 processes are in enforce mode.
11 processes are in complain mode.
0 processes are in prompt mode.
0 processes are in kill mode.
0 processes are unconfined but have a profile defined.
0 processes are in mixed mode.

So as you can see I utilize apparmor a lot. And I could update all the profiles
that need to be updated for the glycin change, but there's a problem. What
problem? Apps now need the following rules:

   /usr/bin/bwrap rPx,
   /usr/share/glycin-loaders/*/conf.d/ r,
   /usr/share/glycin-loaders/*/conf.d/glycin-*.conf r,
   /usr/libexec/glycin-loaders/*/glycin-* rix,

Not a big deal -- can be done. The problem is with this whole bwrap, which
requires bunch of CAPs like sys_admin or net_admin, here's the (not complete)
list:

   network netlink raw,
   allow userns create,
   capability sys_admin,
   capability sys_chroot,
   capability setpcap,
   capability sys_ptrace,
   capability net_admin,
   capability sys_resource,
   mount,
   umount,
   pivot_root,

And still, not a big deal, because it's a sandbox mechanism -- it's normal. Just
create a child profile and execute this bwrap under this child profile. And this
switching between the main app profile and bwrap child profile gives
*no_new_privs* errors. You can of course avoid this no_new_privs errors by
directly executing bwrap inside of the main app profile. But this gives the app
the access to what bwrap needs, which includes everything listed above.

Including rules allowing for everything in all (or most of) apparmor profiles
defeats the purpose of having apparmor enabled... And this is the real problem.

I've seen similar scenario before when apparmor introduced *userns* feature per
app, but Debian has already forced its users to use apparmor by enabling it by
default. This created a problem with app starting because they didn't have a
apparmor profile allowing this userns. How this story ends? Apparmor is still
enabled by default "because of security", and we get more and more profiles, which
are similar to this:

     # This profile allows everything and only exists to give the
     # application a name instead of having the label "unconfined"
     ...

To hell with this kind of security....

Dear submitter,

as the package volumeicon has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/1128879

The version of this package that was in Debian prior to this removal
can still be found using https://snapshot.debian.org/.

Please note that the changes have been done on the master archive and
will not propagate to any mirrors until the next dinstall run at the
earliest.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Thorsten Alteholz (the ftpmaster behind the curtain)

Hi,

I just learned that volumeicon had been removed from Debian,
although it still works except for a bug in glycin. :-(
(It's high quality software that didn't need updates in
almost 10 years and still has happy users!)

Here is the workaround:

  volumeicon & sleep 2; pkill -P `pidof volumeicon` bwrap


There is a hanging bwrap process in the "Testing bwrap
availability" step, killing it makes glycin continue
to load volumeicon's icons:

$ G_MESSAGES_DEBUG=all volumeicon
(volumeicon:15428): GLib-DEBUG: 19:33:03.485: unsetenv() is not thread-safe and should not be used after threads are created
(volumeicon:15428): GLib-GIO-DEBUG: 19:33:03.487: _g_io_module_get_default: Found default implementation local (GLocalVfs) for ‘gio-vfs’
2026-03-15T18:33:03.515856Z DEBUG glycin::gobject: Initialized logging
2026-03-15T18:33:03.518332Z DEBUG glycin::sandbox: Testing bwrap availability with: "bwrap" "--unshare-all" "--die-with-parent" "--chdir" "/" "--ro-bind" "/usr" "/usr" "--dev" "/dev" "--ro-bind-try" "/etc/ld.so.cache" "/etc/ld.so.cache" "--ro-bind-try" "/nix/store" "/nix/store" "--tmpfs" "/tmp-home" "--tmpfs" "/tmp-run" "--clearenv" "--setenv" "HOME" "/tmp-home" "--setenv" "XDG_RUNTIME_DIR" "/tmp-run" "--symlink" "/usr/lib32" "/lib32" "--symlink" "/usr/lib64" "/lib64" "--symlink" "/usr/lib" "/lib" "--symlink" "/usr/libx32" "/libx32" "--seccomp" "12" "/usr/bin/true"
2026-03-15T18:34:33.126481Z  INFO glycin::sandbox: Can't determine if bwrap syscalls are blocked: IO error: No child processes (os error 10)  (StdIoError { err: Os { code: 10, kind: Uncategorized, message: "No child processes" }, info: "" }
)
...

After this bwrap is killed glycin gets an error but continues
anyway. Running the bwrap command alone in a shell (without
seccomp) doesn't hang, only when glycin calls it. The key
difference in strace is that /usr/bin/true exits wait4 returns
ECHILD instead of its exit status:

glycin:
16665 20:09:11.648386 exit_group(0)     = ?
16665 20:09:11.648590 +++ exited with 0 +++
16663 20:09:11.648604 <... wait4 resumed>, 0x7fff013f71c4, 0, NULL) = -1 ECHILD (No child processes)
16663 20:09:11.648778 exit_group(1)     = ?
16663 20:09:11.649339 +++ exited with 1 +++
(parent process hangs in poll())

shell:
17067 20:31:48.320606 exit_group(0)     = ?
17067 20:31:48.320795 +++ exited with 0 +++
17065 20:31:48.320822 <... wait4 resumed>, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2
17065 20:31:48.320874 write(4, "\1\0\0\0\0\0\0\0", 8) = 8
17065 20:31:48.320949 wait4(-1 <unfinished ...>
17064 20:31:48.320968 <... poll resumed>) = 1 ([{fd=4, revents=POLLIN}])
17065 20:31:48.320997 <... wait4 resumed>, 0x7ffde3999754, 0, NULL) = -1 ECHILD (No child processes)
17064 20:31:48.321022 read(4, "\1\0\0\0\0\0\0\0", 8) = 8
17064 20:31:48.321151 exit_group(0 <unfinished ...>
17065 20:31:48.321174 exit_group(0 <unfinished ...>


This issue should be reassigned to the rust-glycin package.

It's apparently also a bwrap bug that it hangs in this case,
child brwap process exits with error status without writing to the pipe
to wake up the parent process.


Best Regards,
Johannes