← Back to team overview

ubuntustudio-bugs team mailing list archive

[Bug 1829562] Re: [Needs Packaging] DPF-Plugins for Eoan

 

Hello Erich! Thank you for preparing the new package and thank you
Thomas for sponsoring it. The package looks good, but there are still a
few things I'd like to have addressed before we can accept it.

1) Copyright needs a bit more work, I suppose? So the worst thing about
packages that batch up multiple projects together is the copyright hell.
Due to copyright reasons we should always try to get as close to the
actual copyright state of the source as possible. After glancing through
the source with licensecheck -r, it still feels to me that there are a
few parts missing in debian/copyright. For example:

 - dpf/dgl/src/nanovg is copyrighted separately and is licensed under the zlib license.
 - dpf/dgl/src/resources/LICENSE-DejaVuSans.ttf.txt - looks like a separate license for the attached font?
 - dpf/dgl/src/sofd/libsofd* - those files seem to be having an MIT header, so this should be mirrored to the copyright file.
 - dpf/distrho/src/dssi/ and some other parts seem to be LGPL
 - dpf/distrho/src/vestige/vestige.h GPL here as well?
 - plugins/common/ - these files are not mentioned anywhere but are reported as MIT

Could you do a licensecheck run on the source and see what can be done?

2) I see in debian/control that you have a versioned dependency on
libprojectm-dev (>= 2.0.1+dfsg-10~bpo60+1). The 2.0.1+dfsg-10~bpo60+1 is
very very old and even precise had a higher version available (not to
mention eoan having 2.1.0+dfsg-4build2 already). I think we should just
drop the version in the dependency in this case.

3) There is no debian/watch file, but I also don't see any releases
shared on the homepage of the project. This makes me wonder - how are
the new upstream versions prepared and tagged? Where does the 1.2
version number come from? (I didn't see it anywhere in the source). It's
rather important for us to be able to match new upstream releases pushed
to Ubuntu with releases done on the home project. We all trust eachother
as we know eachother, but to the outside this might feel unsafe, as no
one knows if the upstream tarball only consists of changes approved by
upstream.

How does this situation look here? Could you explain the process?


Ok, I guess this is most of it. I will reject the source for now - let's try iterating on it some more. Thanks!

-- 
You received this bug notification because you are a member of Ubuntu
Studio Bugs, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1829562

Title:
  [Needs Packaging] DPF-Plugins for Eoan

Status in DPF Plugins:
  Fix Committed
Status in Ubuntu Studio:
  Fix Committed
Status in Ubuntu:
  Fix Committed

Bug description:
  From the project:

   Collection of DPF-based audio plugins in LADSPA, DSSI, LV2 and VST2 formats.
   .
   The list of plugins/packs are:
    - glBars
    - Kars
    - Mini-Series (3BandEQ, 3BandSplitter, PingPongPan)
    - ndc-Plugs (Amplitude Imposer, Cycle Shifter, Soul Force)
    - MVerb
    - Nekobi
    - ProM

  These are audio plugins for audio plugin hosts such as Carla, or a
  Digital Audio Workstation (DAW) such as Ardour.

  Package is ready for MOTU upload to Eoan.\

  Code at https://code.launchpad.net/dpf-plugins
  Build at https://code.launchpad.net/~ubuntustudio-dev/+archive/ubuntu/autobuild

To manage notifications about this bug go to:
https://bugs.launchpad.net/dpf-plugins/+bug/1829562/+subscriptions