Am 09.09.21 um 16:35 schrieb Will Godfrey:
But I don't understand what they are talking about.
It seems they are apply these options then complaining about applying them.
https://lintian.debian.org/sources/yoshimi
Hi Will,
this is something the official Debian package maintainers would have
to care for. According to the debian/control file:
Maintainer:
Debian Multimedia Maintainers <debian-multime...@lists.debian.org>
Uploaders:
Dennis Braun <d_br...@kabelmail.de>,
JaromÃr Mike <mira.mi...@seznam.cz>
To explain the full story.
Debian has an elaborated build infrastructure, which runs automatically.
This includes two different kinds of automated testing
- when a package has a suite of unit-tests, these are invoked
within the package building process, after compilation but prior to
adding the built artefacts + documentation into the binary packages (DEB)
- but there is also the "autopckgtest" facility.
The idea here is not to run within the build setup, but rather invoke
self-test functions against the *installed* software (i.e. the software
in the shape a user would get when installing it into the system). The
intention is to catch incompatibilities or unwanted interferences between
various packages installed into the system.
Now, this whole idea and setup of a "distribution" like Debian hinges on a
special Role, namely "the Packager". This needs to be a human, which cares for
and understands the purpose of a specific package and thus maintains the package
definition with appropriate tags and definitions, allowing the automated
infrastructure to work and yield quality results.
This whole idea is resented frequently, typically by developers, which seem to
think that "all this stuff should work fully automatically". Which seems to be
corroborated by the fact that most distributions suffer a lack of people to
do this work, and thus you'll often encounter maintainers which have to care
for way too much packages.
Anyway, it is the packager's job to define /how to launch these tests/ for
the specific application/package at hand. And to make matters worse, someone
found it a good idea to build a "nag" into lintian for the case when a package
does not actually define such a test hook. So the inevitable happend: the
friendly guys which happen to care for the debian package of yoshimi just
added a dummy test "to make lintian happy" (because actually Yoshimi has
no automated tests yet)
https://github.com/Ichthyostega/yoshimi/commit/e3f63f74d77b7621220380af96679053affd105f
> commit e3f63f74d77b7621220380af96679053affd105f
> Author: Dennis Braun <d_br...@kabelmail.de>
> Date: Sun Nov 1 21:34:36 2020 +0100
>
> Add a superficial test
> +++ b/debian/tests/control
> @@ -0,0 +1,4 @@
> +# Run yoshimi without gui in command line interface
> +Test-Command: yoshimi -Ci &
> +Depends: @
> +Restrictions: allow-stderr, superficial
As you can see, they defined this test to just launch yoshimi as brackground
job, with CLI but without GUI.
Oh well. And now Debian's lintian (rightfully) complains that this test
just can not fail, because our poor Yoshimi will die in the background,
eventually, unless maybe a pink robot happens to pass by.
Bottom line: we could propose the Maintainers to use a better test,
e.g. a shell script which feeds some command to the CLI and then
closes yoshimi. Maybe using the new built-in test-invoker ;-)
> echo "set test exec" | yoshimi --null --no-gui --cmdline
-- Hermann
_______________________________________________
Yoshimi-devel mailing list
Yoshimi-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
