Comment 6 for bug 1827288

Hi Steve,

On Mon, May 6, 2019 at 2:24 PM, Steve Langasek
<email address hidden> wrote:
> The version number in the debian/changelog of the git branch is wrong;
> this needs to be a non-native package using the upstream tarball from
> sourceforge.

Fixed the versioning. The upstream tarball is on Github, no longer on
sourceforge (their website is a little behind, if that's where you got
your info).

> + libjack-jackd2-dev | libjack-dev,
> + php7.2-cli | php5-cli,
> + cairo-static | libcairo2-dev,
>
> why are you using alternative build-dependencies for a new,
> Ubuntu-only
> package? You should only list whichever of these build dependencies
> you
> actually expect to be used (and there is no cairo-static package in
> Ubuntu anywhere, so that is definitely wrong).
>
> Please use php-cli, not phpN.M-cli, as the build-dependency.
>

I don't know why, but I can fix. This is mostly a grab from the
KXStudio repo. As I don't know completely how to clean it, this is why
I appreciate feedback so I can learn these things and fix them,
reducing my ignorance through more practice. Learning by doing.

> +Provides:
> + lv2-plugin,
> + ladspa-plugin,
>
> Why are these Provides: attached to the lsp-plugins package, when
> there
> are separate lsp-plugins-ladspa and lsp-plugins-lv2 packages? The
> Provides look like they belong on the latter packages.

Fixed.

>
> +Package: lsp-plugins-common
> +Architecture: any
> +Provides: lsp-plugins-standalone
>
> Something is definitely wrong here given that you also have a binary
> package named lsp-plugins-standalone which depends on lsp-plugins-
> common. In fact, lsp-plugins-standalone appears to be an empty
> package;
> so you should not list this binary package at all in debian/control.

Fixed by renaming the common package to standalone. All of the other
plugins depend on these binaries, so it make sense. I guess I was being
redundant by having an empty package just to install the binaries as
standalone.

> +FLAGS=-O3 -pipe -ffast-math -mtune=generic -msse -msse2 -mfpmath=sse
> -fPIC -DPIC -fvisibility=hidden -Wno-unused-result
>
> How have you arrived at these flags? Compiler flags should a) inherit
> from dpkg-buildflags by default (You are completely overriding them),
> and b) document the reasons for any divergence from the distro
> defaults.
> But actually, it seems that the only thing you're doing is setting
> these
> flags in a make variable called 'dpkg_buildflags', so in fact this has
> no effect at all.
>
> Not that you could tell by looking at the build log, which does not
> show
> the compiler commands being invoked. This is significant for
> debuggability of builds in launchpad. Please figure out how to make
> this upstream's build system appropriately verbose.

I went ahead and removed all of those flags. The build worked fine, so
I don't understand why they were there to begin with. Again, that was
copied from KXStudio.

> +override_dh_auto_test:
> + #Tests only work manually, ok to override per
> <http://manpages.ubuntu.com/manpages/disco/en/man1/dh_auto_test.1.html>
> +
>
> what are these tests, and why do they only work manually? It's
> /allowed/ to override tests, but the goal should be to run them.

Overriding dh_auto_test with the commands one would use to manually run
the tests seemed to do the trick.

Thanks for the help!