Bug 541535 - Review Request: raul - Realtime Audio Utility Library
Review Request: raul - Realtime Audio Utility Library
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Michael Schwendt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-11-26 04:06 EST by Orcan Ogetbil
Modified: 2010-02-18 17:42 EST (History)
3 users (show)

See Also:
Fixed In Version: raul-0.6.0-2.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-02-18 17:40:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
bugs.michael: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Orcan Ogetbil 2009-11-26 04:06:30 EST
Spec URL: http://oget.fedorapeople.org/review/raul.spec
SRPM URL: http://oget.fedorapeople.org/review/raul-0.5.1-1.fc12.src.rpm
Description: 
Raul (Realtime Audio Utility Library) is a lightweight C++ convenience
library for realtime programming, with a bias towards audio applications on
GNU/Linux machines.

rpmlint is silent.

koji rawhide build:
   http://koji.fedoraproject.org/koji/taskinfo?taskID=1831767
Comment 1 Michael Schwendt 2009-12-05 09:29:03 EST
> rpmlint is silent.

Okay, lemme add some noise then. ;)


> # There are some MIT files but the effective license is GPLv2+
> License:	GPLv2+

The comment is confusing. What files do you refer to?

In case any source files applied a license other than GPLv2+, the guidelines would want you to make that clear.

http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Mixed_Source_Licensing_Scenario

All of the source files contain a GPLv2+ header, though. Only some autotools' scripts/files contain other headers, but we don't give them special treatment with regard to the licensing guidelines.


> raul-gcc44.patch
> ...
> +#include <stdio.h>

In C++ the proper header is <cstdio> though.


> %check
> pushd tests
>         export LD_PRELOAD=../src/.libs/lib%{name}.so

IMO, better would be this set-up:

export LD_LIBRARY_PATH=${RPM_BUILD_ROOT}%{_libdir}


> rpm -i /home/qa/tmp/rpm/RPMS/raul-devel-0.5.1-1.fc12.i686.rpm  \
> /home/qa/tmp/rpm/RPMS/raul-0.5.1-1.fc12.i686.rpm
> error: Failed dependencies:
>         liblo-devel is needed by raul-devel-0.5.1-1.fc12.i686

Uh, it requires another -devel package that wasn't needed for building it.


> $ rpm -qR raul-devel|grep devel
> boost-devel  
> glib2-devel  
> jack-audio-connection-kit-devel  
> liblo-devel  

> $ pkg-config --cflags raul
> -pthread -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include
> -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
> -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  
> $ pkg-config --libs raul
> -pthread -lraul -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lgthread-2.0
> -lglib-2.0 -ljack -lpthread -lrt 

"Requires: glibmm24-devel libsigc++20-devel" is missing in raul-devel. Only because the pkg-config file adds them explicitly.

Upstream might add proper "Requires" to raul.pc.in, in particular since some of these explicitly added libraries are not needed when building with libraul.


> $ grep mm include/raul/*
> AtomRDF.hpp:#include <redlandmm/Node.hpp>
> AtomRDF.hpp:#include <redlandmm/World.hpp>
> Command.hpp:#include <raul/Semaphore.hpp>
> Command.hpp:#include <boost/utility.hpp>
> Stateful.hpp:#include <redlandmm/Model.hpp>

$ sudo repoquery --whatprovides /usr/include\*/redlandmm/Node.hpp
$

Not in Fedora yet.
Comment 2 Orcan Ogetbil 2009-12-05 16:09:21 EST
(In reply to comment #1)
> > rpmlint is silent.
> 
> Okay, lemme add some noise then. ;)
> 
> 

Thanks for getting your hands dirty :)

> > # There are some MIT files but the effective license is GPLv2+
> > License:	GPLv2+
> 
> The comment is confusing. What files do you refer to?
> 
> In case any source files applied a license other than GPLv2+, the guidelines
> would want you to make that clear.
> 
> http://fedoraproject.org/wiki/Packaging/LicensingGuidelines#Mixed_Source_Licensing_Scenario
> 
> All of the source files contain a GPLv2+ header, though. Only some autotools'
> scripts/files contain other headers, but we don't give them special treatment
> with regard to the licensing guidelines.
> 
> 

Ah, I probably was going thru the source files and saw the MIT headers in the autotools files and didn't pay attention what they actually are for. I'll remove the comment.

> > raul-gcc44.patch
> > ...
> > +#include <stdio.h>
> 
> In C++ the proper header is <cstdio> though.
> 

Yes. But it's not too big of a deal (Is it?). And upstream accepted and applied my <stdio.h> patch to the trunk.

> 
> > %check
> > pushd tests
> >         export LD_PRELOAD=../src/.libs/lib%{name}.so
> 
> IMO, better would be this set-up:
> 
> export LD_LIBRARY_PATH=${RPM_BUILD_ROOT}%{_libdir}
> 

Could you tell me what makes this better? Don't they serve the same purpose in this case? Does LD_PRELOAD have a potential of hiding errors or breaking thing?

> 
> > rpm -i /home/qa/tmp/rpm/RPMS/raul-devel-0.5.1-1.fc12.i686.rpm  \
> > /home/qa/tmp/rpm/RPMS/raul-0.5.1-1.fc12.i686.rpm
> > error: Failed dependencies:
> >         liblo-devel is needed by raul-devel-0.5.1-1.fc12.i686
> 
> Uh, it requires another -devel package that wasn't needed for building it.
> 

A "Requires" in the devel package does not necessarily mean that you need that package during building. Just check the header files that go into the devel package and you will understand what I mean :). You will see that some #include headers from liblo and some #include headers from:

> > boost-devel  
> > glib2-devel  
> > jack-audio-connection-kit-devel  
> > liblo-devel  
> 

So these requirements are for development purposes.

> > $ pkg-config --cflags raul
> > -pthread -I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include
> > -I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
> > -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  
> > $ pkg-config --libs raul
> > -pthread -lraul -lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lgthread-2.0
> > -lglib-2.0 -ljack -lpthread -lrt 
> 
> "Requires: glibmm24-devel libsigc++20-devel" is missing in raul-devel. Only
> because the pkg-config file adds them explicitly.
> 
> Upstream might add proper "Requires" to raul.pc.in, in particular since some of
> these explicitly added libraries are not needed when building with libraul.
> 

Should I remove these entries from the .pc file:
-lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 lgthread-2.0 -lglib-2.0 -ljack
I don't think they are really required.

> 
> > $ grep mm include/raul/*
> > AtomRDF.hpp:#include <redlandmm/Node.hpp>
> > AtomRDF.hpp:#include <redlandmm/World.hpp>
> > Command.hpp:#include <raul/Semaphore.hpp>
> > Command.hpp:#include <boost/utility.hpp>
> > Stateful.hpp:#include <redlandmm/Model.hpp>
> 
> $ sudo repoquery --whatprovides /usr/include\*/redlandmm/Node.hpp
> $
> 
> Not in Fedora yet.  

Exactly. That's why I didn't add BR: redlandmm-devel (or whatever it is called) to the Requires of the devel package. I will add it once this package is in Fedora. For the time being this won't break anything. I don't know of any software that uses redlandmm feature of raul. In particular, redlandmm needs redland >= 1.0.8 or higher. But even in rawhide we still have 1.0.7. I talked to the maintainer and got the response that it is being worked on. I guess the progress is a little slow.
Comment 3 Michael Schwendt 2009-12-05 19:36:52 EST
> LD_LIBRARY_PATH vs. LD_PRELOAD

The benefit would be that you would test run-time linking of the test-suite programs with the actual shared libs installed into the package buildroot. It's much more a real-world test scenario than forcefully making available a .so that won't even be put into the run-time library package.


> A "Requires" in the devel package does not necessarily mean
> that you need that package during building.

I found it surprising enough to mention it. :-)  Upstream could include a check for liblo in its build framework. Afterall, it's a requirement of the API.


> Should I remove these entries from the .pc file:

Raises the question whether you would like the increased maintenance requirements?

[pkg-config is kind of unflexible in that area. For any inter-dependency on other .pc files that is added in a .pc file's "Requires" line, it propagates and accumulates the cflags and ldflags. Good for the cflags (to find headers in customised trees outside standard search paths). However, when linking shared-only, we don't need to relink against shared libs a base library is linked with already (as opposed to static linkage). So, as an affect, shared library ldflags pile up even if an API doesn't depend on any of the libs.]
And in this case the author even specified all those cflags and ldflags manually instead of using dependencies.


> I don't know of any software that uses redlandmm feature of raul.

The cleaner work-around would be to %exclude those headers then and effectively disable that part of the API that could not be used. We can't ship an API that is defunctional because of missing headers.
Comment 4 Orcan Ogetbil 2009-12-08 05:52:19 EST
I asked these questions to the author via email. Let us wait, then I will proceed with what comes out.
Comment 5 Orcan Ogetbil 2009-12-08 23:51:44 EST
The author replied and actually released a new version today, with the excessive linkage removed. So here we go:

Spec URL: http://oget.fedorapeople.org/review/raul.spec
SRPM URL: http://oget.fedorapeople.org/review/raul-0.6.0-1.fc12.src.rpm

ChangeLog - 0.6.0-1
- Update to 0.6.0. Build system uses waf now.
- Drop upstreamed gcc44 patch
- Removed irrelevant license comment
- Change LD_PRELOAD to LD_LIBRARY_PATH in %%check
- Exclude the headers that require redlandmm
Comment 6 Michael Schwendt 2009-12-26 07:13:00 EST
Something is wrong with the new -debuginfo package now. It's missing the sources.
Comment 7 Orcan Ogetbil 2010-01-22 17:04:34 EST
That doesn't happen here. Koji's build has the source files in debuginfo package too:
   http://koji.fedoraproject.org/koji/taskinfo?taskID=1939511

How did you build the package?
Comment 8 Michael Schwendt 2010-01-25 17:00:12 EST
* A plain rpmbuild shell function on a F-12 update-testing machine that only adds stdin/stderr output logging. Somehow buildroot/builddir paths appeared in the -debuginfo below /usr/src/debug. Though, I cannot reproduce it anymore. :-) 

* There is a mixture of $RPM_BUILD_ROOT and %buildroot in the spec.
https://fedoraproject.org/wiki/Packaging/Guidelines#macros

* x86_64 build hardcodes /usr/lib in raul.pc

* raul.pc is still somewhat "unclean" beyond that, which bears a risk that you will have fun with it in the future: It hardcodes header/library search paths instead of setting a dependency on "gthread-2.0" and "glib-2.0". It relinks with gthread+glib2+rt, which libraul is linked with already.


* If you want me to give another update a look, feel free to request that.

If you think you can deal with those items in cvs: APPROVED
Comment 9 Orcan Ogetbil 2010-01-30 13:20:23 EST
Thanks Michael, I'll do the trivial fixes. About linkage in raul.pc, I already informed upstream about it. I'll go with their decision. I am sure they will update those paths accordingly in time, or the software will get obsolete anyway.

New Package CVS Request
=======================
Package Name: raul
Short Description: Realtime Audio Utility Library
Owners: oget
Branches: F-11 F-12
InitialCC:
Comment 10 Kevin Fenzi 2010-01-31 13:21:01 EST
CVS done (by process-cvs-requests.py).
Comment 11 Fedora Update System 2010-02-01 15:42:21 EST
raul-0.6.0-2.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/raul-0.6.0-2.fc12
Comment 12 Fedora Update System 2010-02-01 15:43:26 EST
raul-0.6.0-2.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/raul-0.6.0-2.fc11
Comment 13 Fedora Update System 2010-02-02 15:40:22 EST
raul-0.6.0-2.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update raul'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2010-1378
Comment 14 Fedora Update System 2010-02-02 15:42:34 EST
raul-0.6.0-2.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update raul'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2010-1396
Comment 15 Fedora Update System 2010-02-18 17:40:27 EST
raul-0.6.0-2.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 16 Fedora Update System 2010-02-18 17:42:07 EST
raul-0.6.0-2.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.