Dear Maintainer,
I get this error in my logs:
oct. 01 12:19:15 hermes systemd-xdg-autostart-generator[501717]: Exec binary '/usr/lib/x86_64-linux-gnu/xapps/sn-watcher/xapp-sn-watcher' does not exist: No such file or directory
oct. 01 12:19:15 hermes systemd-xdg-autostart-generator[501717]: /etc/xdg/autostart/xapp-sn-watcher.desktop: not generating unit, error parsing Exec= line: No such file or directory

it turns out I have libxapp1:amd64 2.6.1-1 installed but not xapp-sn-watcher.

I believe the xapp-sn-watcher.desktop shipped by libxapp1 should be shipped by
the xapp-sn-watcher package.

Cheers,
Alban

Il 01/10/2023 12:33, Alban Browaeys ha scritto:

Hi, from the version you are reporting xapp-sn-watcher.desktop is
already in xapp-sn-watcher package:
https://packages.debian.org/sid/amd64/xapp-sn-watcher/filelist

file was moved latest time in 2.4.2-1 (from xapp package) and first time
in 2.2.6-1 (from libxapp1)

I suppose the issue you spotted is related to old conffile moved (in
case your system was upgraded and was installed intially with version <
2.2.6-1, where there was the first move from libxapp1), relating to it
there is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983441 but is
blocked by another bug in dpkg (that I'm unable to fix it) and as wrote
in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886389 is
impossible use rm_conffile in case of move from one binary package to
another of the same source or the file of the new package will be
removed broking it

since the unexpected case you spotted is more that simply "mark as
obsolete" I think is good to reply on bug #886389 that now seems
considered minor and without progress

Exec binary '/usr/lib/x86_64-linux-gnu/xapps/sn-watcher/xapp-sn-
watcher' does not exist: No such file or directory
/etc/xdg/autostart/xapp-sn-watcher.desktop: not generating unit, error
parsing Exec= line: No such file or directory
sn-watcher.
shipped by
time
<
it
is
wrote

I reported to both bug reports because there is something specific to
my issue.

In my case the desktop file is not only marked as obsolete in the
database. It is also still marked as owned by the old package libxapp1
... weird:

$ dpkg -L libxapp1
/.
/usr
/usr/lib
/usr/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu/libxapp.so.2.6.1
/usr/share
/usr/share/doc
/usr/share/doc/libxapp1
/usr/share/doc/libxapp1/changelog.Debian.gz
/usr/share/doc/libxapp1/changelog.gz
/usr/share/doc/libxapp1/copyright
/usr/lib/x86_64-linux-gnu/libxapp.so.1
/etc/xdg/autostart/xapp-sn-watcher.desktop


$ apt policy libxapp1
libxapp1:
  Installé : 2.6.1-1
  Candidat : 2.6.1-1
 Table de version :
 *** 2.6.1-1 500
         90 http://ftp.debian.org/debian sid/main amd64 Packages
        500 http://deb.debian.org/debian trixie/main amd64 Packages
        100 /var/lib/dpkg/status
     2.4.2-3 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages
     1.2.2-1 500
        500 http://httpredir.debian.org/debian buster/main amd64 Packages

ls /etc/xdg/autostart/xapp-sn-watcher.desktop
/etc/xdg/autostart/xapp-sn-watcher.desktop

dpkg -S  /etc/xdg/autostart/xapp-sn-watcher.desktop
libxapp1:amd64: /etc/xdg/autostart/xapp-sn-watcher.desktop

dpkg-query -W -f='${Conffiles}\n' | grep obsolete$ |grep xapp-sn
 /etc/xdg/autostart/xapp-sn-watcher.desktop a9fa3be7aaf46761adcdb856c63c125f obsolete


It could still be
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886389
still all the report I found in it, tell the files are owned by the new
package but still marked as obsolete.

Here, the file is still owned by the old package. I do not even have
the new package xapp-sn-watcher installed.

So maybe it is the same bug but without installing the new package the
ownership is also not removed from the old package.
This might help define the origin of this bug.

Cheers,
Alban

Il 03/10/2023 21:21, Alban Browaeys ha scritto:
this is for xapp-sn-watcher not installed in this case rm_conffile will
works correctly but installing also xapp-sn-watcher will remove
xapp-sn-watcher.desktop broking it after the upgrade so I couldn't do it
as I wrote, I did some tests looking for a workaround but unfortunately
I didn't find any and the "best" solution was to not to use rm_conffile.

after this new issue (with people that don't install recommends) I
thinked about increase to depends but I think is a problem have circular
depends (xapp-sn-watcher depends on libxapp1)

so I suppose that the best thing it would fix that old bug in dpkg, but
I don't know how

or someone have another idea? any advice is welcome

Hello,

Bug #1053306 in xapp reported by you has been fixed in the
Git repository and is awaiting an upload. You can see the commit
message below and you can check the diff of the fix at:

https://salsa.debian.org/cinnamon-team/xapp/-/commit/8d38fd8cc19c62e2840afbdb147a96c1ce0e2aca
------------------------------------------------------------------------
d/libxapp1.conffiles: remove the stale xapp-sn-watcher autostart file

The autostart file moved from libxapp1 to xapp-sn-watcher in 2.4.2-1,
but on systems where xapp-sn-watcher is not installed, and it is only a
Recommends, dpkg keeps the file in the libxapp1 file list, re-marks it
obsolete at every upgrade and leaves it on disk forever, so the session
keeps trying to autostart a binary that is not there.

The remove-on-upgrade flag removes it exactly on those systems and is a
no-op everywhere else: dpkg skips the removal when another installed
package owns the path (pkg_remove_conffile_on_upgrade() in
src/main/unpack.c), which is what makes this safe, unlike rm_conffile.
The line can be dropped again once this version has gone through a
stable release.

Closes: #983441, #1053306

Assisted-by: Claude Code:claude-opus-5
------------------------------------------------------------------------

(this message was generated automatically)
-- 
Greetings

https://bugs.debian.org/1053306