Control: clone 887506 -2
Control: severity -2 important
Control: clone -2 -3
Control: clone -2 -4
Control: reassign -2 python-notify2
Control: retitle -2 python-notify2: Don't rely on location of
notification-daemon
Control: reassign -3 libgtk2-notify-perl
Control: retitle -3 libgtk2-notify-perl: Don't rely on location of
notification-daemon
Control: reassign -4 golang-github-thecreeper-go-notify
Control: retitle -4 golang-github-thecreeper-go-notify: Don't rely on location
of notification-daemon
On Wed, 17 Jan 2018 at 17:47:03 +0200, Adrian Bunk wrote:
> debian/runtests.sh: 5: debian/runtests.sh:
> /usr/lib/notification-daemon/notification-daemon: not found
The exact location of the notification daemon shouldn't be treated as API:
the entry point is /usr/share/applications/notification-daemon.desktop.
It's ${libexecdir}/notification-daemon, and the default ${libexecdir}
changed between debhelper compat levels (which is what happened here),
and might well change again in future (for example to /usr/libexec when
Debian Policy picks up a newer FHS version).
python-notify2's runtests.sh should launch the desktop file instead,
for example with gtk-launch from libgtk3-bin:
-/usr/lib/notification-daemon/notification-daemon &
+gtk-launch notification-daemon.desktop
The same is true for other packages that launch notification-daemon for
their tests.
> This is caused by the following unintentional
> change in notification-daemon 3.20.0-2:
> -/usr/lib/notification-daemon/notification-daemon
> +/usr/lib/x86_64-linux-gnu/notification-daemon
It would be straightforward to change this back by passing
--libexecdir=/usr/lib/notification-daemon to configure, and that's
probably the most expedient short-term answer (which is why I haven't
closed this bug, and why I reduced the severity of its clones).
smcv
_______________________________________________
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
