Vee One Suite has new package padthv1 - DD upload needed

[James Cowgill]

Hi,

On 23/08/17 15:23, Jaromír Mikeš wrote:
> 2017-08-23 15:37 GMT+02:00 James Cowgill <jcowgill at debian.org>:
>> On 23/08/17 13:04, Jaromír Mikeš wrote:
> Hi James,
> 
>>> Vee One Suite has new package padthv1
>>> http://www.rncbc.org/drupal/node/1846
>>> https://padthv1.sourceforge.io/
>>>
>>> I need DD to upload it to "NEW" ... can somebody do it for me?
[...]
>> - The short name for public domain works is "public-domain".

I think DEP5 is case-sensitive, so the P has to be lower case:
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name

> Thank you for reviewing.
> All above done!

Thanks. One thing I just noticed is that only one dbgsym package is
built but there are 3 binary packages. This means the upstream build
system is stripping the binaries somewhere. I had a play and I think
adding "QMAKE_STRIP =" to the 3 .pri.in files in src/ will fix it.

>> On a related note, I see you've patched upstream to move the lv2 plugins
>> back into /usr/lib/lv2. I do not know much about lv2 plugins, but is it
>> a good idea to install them to a multiarch path at some point? How much
>> work would that be to do for every lv2 plugin in the archive? Would
>> doing that cause any big issues?
>>
> 
> This is interesting topic which I already started here on list quite long
> time ago.
> I would need to search archive to find this tread.
> Generally problem is ( as I understand it ) that plugins hosts doesn't
> search for plugins in multiarch path :(
> Otherwise it would great to have them multiarch.

I think if this were done, the plugin hosts should search both
directories as a transitional measure (so we could then gradually move
the plugins over).

I have just found this:
http://lv2plug.in/pages/filesystem-hierarchy-standard.html

It says that the system path is "$PREFIX/lib/lv2" (as opposed to
"$LIBDIR/lv2" which would imply multiarch) so maybe this is the wrong
idea, or at least we should talk to upstream LV2 if we do this.

Thanks,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20170823/d7c8b38e/attachment.sig>