Bug 710917

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?

* 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.

? Should we build this package with jack support? Jack is the most common sound server used in audio production type applications.

(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.

> 
> * 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.

> 
> ? 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.

(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.

> > 
> > * 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


> > 
> > ? 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?

(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

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> 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.
> 

Yes, but the common convention is to get the library first into Fedora, then link to the library dynamically or statically. For instance, clementine was bundling libraries
- qtsingleapplication
- qtlockedfile
- qxt
- qtiocompressor
- gmock
- gtest
- libechonest
- libprojectM
We had to package them one by one, and upstream all the clementine's patches before we released clementine under Fedora. Another example was the java DAW frinika.

However, I investigated this further. Unlike rtaudio, rtmidi does not provide any libraries (static or dynamic). They just distribute the source code to be included in other software (as is the case with universalchardet library). So I think we are safe with having it built into vmpk.


> > 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.
> 

Let us know what comes out so we can approve the package. Thanks.


> > 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

You wight as well compile two binaries, one that uses ALSA, one that uses JACK. I leave it up to you.

License specified to "GPLv3+ and MIT and (LGPLv2 with exceptions or GPLv3)"

Spec URL: http://cheeselee.fedorapeople.org/vmpk.spec
SRPM URL: http://cheeselee.fedorapeople.org/vmpk-0.4.0-3.fc15.src.rpm

Do you still work on this review? I have made an update a couple of weeks ago.

Oh sorry, it slipped out of my mind. I'll get back to it asap.

Sorry again for the delay. The package looks good, except the bundled rtmidi library. I asked about this [1] in the Fedora Devel list and apparently, according to the answer I got, you will need to ask FPC (Fedora Packaging Committee) for an exception. Please see [2] for the complete procedure.

[1] http://lists.fedoraproject.org/pipermail/devel/2011-July/153938.html
[2] https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions

Finally, RtMidi is submitted for review. And vmpk now builds with the shared object.

Spec URL: http://cheeselee.fedorapeople.org/vmpk.spec
SRPM URL: http://cheeselee.fedorapeople.org/vmpk-0.4.0-4.fc15.src.rpm

Changes:
- Use the RtMidi shared object
- License revised to "GPLv3+ and (LGPLv2 with exceptions or GPLv3)"

Do you still work on this review?

Sorry, I forgot about it. I'll get to this this weekend.

This package is good to go. Sorry again for the delay. But please keep an eye on qticonloader. If it becomes an independent project we will have to make a separate package for it.

---------------------------------------
This package (vmpk) is APPROVED by oget
---------------------------------------

New Package SCM Request
=======================
Package Name: vmpk
Short Description: Virtual MIDI Piano Keyboard
Owners: cheeeselee
Branches: f15 f16

Git done (by process-git-requests).

Corrected FAS account name.

vmpk-0.4.0-4.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/vmpk-0.4.0-4.fc15

vmpk-0.4.0-4.fc15 has been pushed to the Fedora 15 testing repository.

vmpk-0.4.0-4.fc15 has been pushed to the Fedora 15 stable repository.