Update xfce

[david]

update to xfce 4.20

only tested via vnc

• xfce4 desktop
• xfce4 plugins
• xfce4-xkb-plugin seems not to work, could be vnc session needs to be checked
  - worked local
• testing on machdoch with fresh login
• testing on ploetze background update while logged in
• xscreensaver works now
• no visible files on the desktop
• xscreensaver authentication failed
• check where log spamming comes from
• no background picture (that worked before ?)
• strange log message
  traps: xfdesktop[13057] trap int3 ip:7f4821393267 sp:7ffd40014da0 error:0 in libglib-2.0.so.0.8200.5[68267,7f482134d000+95000]

[pmenzel]

Do you have an update command? ;-)

[david]

yes, in the bee-file repo 'scripts/update-xfce.sh'

[david]

after Update Gimp crash when it open a jpeg

/usr/lib/gimp/3.0/plug-ins/file-jpeg/file-jpeg: fatal error: Segmentation fault

unrelated is a bug in GIMP
GIMP creates a folder gimp in $TMPDIR, if the folder is owned by a different user GIMP gets a permissions denied and segfaulted afterwards

[david]

issue:
lock screen shortcut or menu button did not work
tested with fresh login and with running sessions

tested on ploetze and sigusr2:
different accounts molgen & schrader

[david]

new issue, I do not know why I didn't see earlier, but all my Desktop icons are gone

[david]

issue: lock screen shortcut or menu button did not work tested with fresh login and with running sessions

tested on ploetze and sigusr2: different accounts molgen & schrader

xflock4
Error org.freedesktop.DBus.Error.UnknownMethod: No such method “Lock”

xfce 4.20 exspect dbus service file in /usr/share/dbus-1/service/ and xscreensaver didn't deliver this file

dbus-send --session --print-reply --dest=org.freedesktop.ScreenSaver /org/freedesktop/ScreenSaver org.freedesktop.ScreenSaver.Lock
Error org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.ScreenSaver was not provided by any .service files

[david]

xscreenserver daemon do not start at login after update

[david]

xscreenserver daemon do not start at login after update

stupid me
fixed with c49541e

[david]

After Update xscreensaver did not accept password after

running session and fresh session both have this error

[david]

log spamming

[...]
2026-07-10T09:11:47.886229+02:00 bacon kernel: __vm_enough_memory: pid: 13377, comm: wrapper-2.0, bytes: 16361543696384 not enough memory for the allocation
2026-07-10T09:11:52.886230+02:00 bacon kernel: __vm_enough_memory: pid: 13377, comm: wrapper-2.0, bytes: 16361610805248 not enough memory for the allocation
2026-07-10T09:11:57.888228+02:00 bacon kernel: __vm_enough_memory: pid: 13377, comm: wrapper-2.0, bytes: 16361677914112 not enough memory for the allocation
2026-07-10T09:12:02.888234+02:00 bacon kernel: __vm_enough_memory: pid: 13377, comm: wrapper-2.0, bytes: 16361745022976 not enough memory for the allocation
2026-07-10T09:12:07.887228+02:00 bacon kernel: __vm_enough_memory: pid: 13377, comm: wrapper-2.0, bytes: 16361812131840 not enough memory for the allocation
[...]

[wwwutz]

16361745022976 ... 16361745022k ... 16361745M ... 16361G ... 16 TinyByte

wow...

[pmenzel]

Answer from the clanker:

● Root cause fully confirmed at both the code and runtime level. Here's the diagnosis.
  
  Root cause
  
  It's not a bug in xscreensaver's logic — it's a stale local PAM config that a behavior change in 6.15 now trips over.
  
  What changed (6.09 → 6.15, driver/passwd-pam.c):
  
  In 6.09, the result of the account phase (pam_acct_mgmt()) was stored in a throwaway status2 and ignored on Linux (it was only honored if built with --with-pam-check-account-type, i.e. PAM_CHECK_ACCOUNT_TYPE):
  
  status2 = pam_acct_mgmt (pamh, 0);
  ...
  #ifdef PAM_CHECK_ACCOUNT_TYPE
     status = status2;      /* not defined on this build → ignored */
  #endif
  
  In 6.15 jwz deleted that logic ("I'm going to assume that this nonsense is no longer ongoing. -- jwz 2025") and now the account result is the final result:
  
  status = pam_acct_mgmt (pamh, 0);   // 6.15
  ...
  return (status == PAM_SUCCESS);
  
  Why that fails on this box: /etc/pam.d/xscreensaver (a MarIuX file dated Aug 2012) contains only auth lines — no account stanza. When a service file lacks a module group, Linux-PAM falls through to
  /etc/pam.d/other, which is account required pam_deny.so. So pam_acct_mgmt() returns PAM_AUTH_ERR.
  
  Empirical proof (no password needed)
  
  pam_acct_mgmt() requires no password, so I reproduced it directly with a 30-line libpam probe:
  
  Service xscreensaver: pam_acct_mgmt = 7 (Authentication failure)   ← the "auth failed" you see
  Service login:        pam_acct_mgmt = 0 (Success)                  ← login has an account stanza
  
  Flow in 6.15: pam_authenticate() succeeds (correct password) → pam_acct_mgmt() returns 7 → return (status == PAM_SUCCESS) is False → "authentication failed". In 6.09 the 7 was discarded, so it worked.
  
  The fix
  
  Add an account stanza to /etc/pam.d/xscreensaver (requires root — I don't have it here). Mirror the system's login/system-auth:
  
  account     required       pam_access.so
  account     required       pam_unix.so
  
  status = pam_acct_mgmt (pamh, 0);   // 6.15
  ...
  return (status == PAM_SUCCESS);
  
  Why that fails on this box: /etc/pam.d/xscreensaver (a MarIuX file dated Aug 2012) contains only auth lines — no account stanza. When a service file lacks a module group, Linux-PAM falls through to
  /etc/pam.d/other, which is account required pam_deny.so. So pam_acct_mgmt() returns PAM_AUTH_ERR.

  Empirical proof (no password needed)

  pam_acct_mgmt() requires no password, so I reproduced it directly with a 30-line libpam probe:

  Service xscreensaver: pam_acct_mgmt = 7 (Authentication failure)   ← the "auth failed" you see
  Service login:        pam_acct_mgmt = 0 (Success)                  ← login has an account stanza
  
  Flow in 6.15: pam_authenticate() succeeds (correct password) → pam_acct_mgmt() returns 7 → return (status == PAM_SUCCESS) is False → "authentication failed". In 6.09 the 7 was discarded, so it worked.
  
  The fix
  
  Add an account stanza to /etc/pam.d/xscreensaver (requires root — I don't have it here). Mirror the system's login/system-auth:
  
  account     required       pam_access.so
  account     required       pam_unix.so
  
  That's the minimal correct fix. login uses exactly these two and my probe showed they return Success for your user, so this resolves it. (For completeness you may also add password required pam_unix.so md5
  shadow to cover expired-password changes, but the current failure is fixed by the account lines alone.)
  
  This is really a packaging bug in the MarIuX xscreensaver beebuild: the shipped 6.15 driver/xscreensaver.pam uses account include login (which would work), but the box carries a stale hand-written
  /etc/pam.d/xscreensaver from 2012 that predates when the account phase mattered. The proper long-term fix is to update the packaged /etc/pam.d/xscreensaver.
  
  ---
  I couldn't apply the fix myself (no write access to /etc/pam.d, no passwordless sudo). Would you like me to:
  
  1. Write out the corrected /etc/pam.d/xscreensaver to a temp file so you can sudo cp it into place, or
  2. Locate where the beebuild installs its pam file so the package can be corrected at the source?

[pmenzel]

Answer from the clanker:

[…]

Tested on sigusr2. Able to unlock session after changing /etc/pam.d/xscreensaver.

[david]

second test today
background image was there
no, strange log message [...] trap int3 ip:7f4821393267 [...]

background pdist (?)