Control: tags -1 confirmed The test is the unit test of the package. I don't think it is sensible to package unit tests, I don't see large benefits only work doing so and it litters the packages namespace.
Said that, when I find time, I will look into option #2, possibly all it needs is a "LD_PRELOAD", but I haven't looked at the tests at all. -- tobi On Thu, 10 Oct 2024 11:13:02 +0100 Simon McVittie <s...@debian.org> wrote: > Source: gnome-shell-pomodoro > Version: 0.26.0-1 > Severity: normal > User: debian...@lists.debian.org > Usertags: other > > While looking at blockers for the GNOME Shell 47 migration, we noticed that > the autopkgtest for gnome-shell-pomodoro rebuilds the package from source > and runs the unit test executable from the newly-built package. > > This is not really the intention for autopkgtests. The way that autopkgtests > are meant to operate is that they test the binaries that are already in the > archive, against a proposed update for a dependency (like GNOME Shell or > libmutter in this case). > > From a quick look at the package, I see two possible ways this could work: > > 1. Install the gnome-pomodoro-test-executable and any data that it needs > in some binary package (gnome-shell-pomodoro or a new > gnome-shell-pomodoro-tests), and make the autopkgtest run that. > For example mutter-15-tests is the equivalent of this for mutter. > This could potentially be an upstreamable change by making use of > <https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests>. > > 2. Continue to use a newly-built gnome-pomodoro-test-executable executable, > but instead of loading the libgnome-pomodoro.so.0 from the built tree, > make sure that it's loading the libgnome-pomodoro.so.0 from the binary > package shipped in the archive. This makes sure that the version under > test is the version that users install. > > Thanks, > smcv > >
