[Bug 710917] Review Request: vmpk - Virtual MIDI Piano Keyboard

bugzilla at redhat.com bugzilla at redhat.com
Tue Jun 21 18:17:18 UTC 2011


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=710917

--- Comment #4 from Robin Lee <robinlee.sysu at gmail.com> 2011-06-21 14:17:18 EDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > (In reply to comment #1)
> > > Here is my review for this
> > > - rpmlint output is clean
> > > 
> > > ? The package bundles the rtmidi library. Normally, we do not allow bundled
> > > libraries in Fedora. However as far as I remember, the last time we checked
> > > (1-2 years ago?), the rtmidi library was not packagable, so we allowed this as
> > > an exception. Did you look into this?
> > rtmidi library is still not dynamically linkable.
> > 
> 
> No it is not. But
> 1- It can be made dynamically linkable. But this might conflict with upstream's
> intentions. It should better be asked upstream.
> 2- Even if it should remain static, should we not package it separately? I am
> not sure if bundling is the correct solution.
> 
I think we are not necessary to talk about the issue of this library here:

1. The guide line says 'A package should not include or build against a local
copy of a library that *exists* on a system.' Since RtMidi doesn't exist in
Fedora, we can consider it just part of this very work.

2. We should not choose a shared library name for RtMidi upstream, who doesn't
intend to make it a shared library.

I will ask RtMidi upstream for this issue later.

> > > 
> > > * The license tag as GPLv3+ is correct, except the bundled rtmidi library is
> > > MIT. Depending on the unbundling situation we might need to add MIT to the
> > > license tag.
> > According to
> > https://fedoraproject.org/wiki/Licensing/FAQ#How_should_I_handle_multiple_licensing_situations.3F
> > , since MIT is compatible with GPL, so only GPL is needed listed.
> > 
> 
> I know about that guideline, which contradicts what FE-Legal says. I was
> thinking exactly the same way you are, and a package reviewer asked me to list
> all the licenses separately in the license tag of a package that all code was
> compiled into a single binary. 
> 
> I asked FE-Legal, quoting the link you gave above, and they told me to list all
> the licenses separately:
>   
> https://www.redhat.com/archives/fedora-legal-list/2009-December/msg00029.html
> 
I think we can try to ask FPC to make the guidelines for this situation more
explicit and detailed.


> 
> > > 
> > > ? Should we build this package with jack support? Jack is the most common sound
> > > server used in audio production type applications.
> > I prefer upstream default setting.
> 
> After you build the "vmpk" binary, you can pass some additional flag to cmake
> to build another binary with jack support, you can even call the second binary
> vmpk-jack. Please see the README and CMakeLists.txt files.
> 
> $ cmake . -DRTMIDI_DRIVER=JACK -DPROGRAM_NAME=vmpk-jack
> 
> Compiling with jack support is important, since we have a large collection of
> jack-supporting programs, and this will allow "vmpk" to communicate with all of
> them. jack is pretty much the standard sound server in Linux audio production
> software. Do you have an argument why compiling with jack support will be bad
> for Fedora users?
OK. Actually I don't have a strong position.

SRPM URL: http://cheeselee.fedorapeople.org/vmpk-0.4.0-2.fc15.src.rpm

Change:
- Use JACK driver instead of ALSA

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.



More information about the package-review mailing list