[REBUILD] dssi-0.9.1-3mdk.src.rpm from cooker does not build correctly on x86_64

[Pedro Lopez-Cabanillas]

Hi everybody,

See
http://qa.mandriva.com/build/iurt//cooker/x86_64/log/dssi-0.9.1-3mdk.src.rp
m/
Command failed: TMP=/home/builder/tmp/ sudo chroot

[...]

* ======== DSSI 0.9.1 configured ========
* building jack-dssi-host: yes
* building DSSI OSC tools: yes
* building trivial_synth plugin: yes
* building less_trivial_synth plugin: yes
* building trivial_sampler plugin: yes
* building less_trivial_synth GUI: no (missing Qt)
* building trivial_sampler GUI: no (missing Qt)

[...]

/home/builder/rpm/tmp/dssi-0.9.1-3mdk-buildroot/usr/lib64/dssi/less_trivial
/home/builder/rpm/tmp/dssi-0.9.1-3mdk-buildroot/usr/lib64/dssi/trivial_samp
ler/trivial_sampler_*

Sorry. I'm receiving these build reports, but I can't do anything because I
don't have CVS write access. I've tried to contact Austin Acton several
times, but he doesn't read my messages or he is too much busy. I've attached
a patch for the spec file which I hope fixes the building problems. If not,
perhaps somebody knows how to fix it.

The build system doesn't find Qt, which is needed by the provided GUI for the
two sample plugins included in the package. I don't know for sure how the RPM
build server works, but there is a missing build requirement:

BuildRequires: qt3-devel

Another issue: It is necessary that when dssi-devel is installed (in order to
compile some plugin), ladspa-devel should also be installed. I've included it
also this requirement in the patch.

Regards,
Pedro

[Thomas Backlund]

Post by Pedro Lopez-Cabanillas
Hi everybody,

See
http://qa.mandriva.com/build/iurt//cooker/x86_64/log/dssi-0.9.1-3mdk.src.rp
m/
Command failed: TMP=/home/builder/tmp/ sudo chroot

[...]

* ======== DSSI 0.9.1 configured ========
* building jack-dssi-host: yes
* building DSSI OSC tools: yes
* building trivial_synth plugin: yes
* building less_trivial_synth plugin: yes
* building trivial_sampler plugin: yes
* building less_trivial_synth GUI: no (missing Qt)
* building trivial_sampler GUI: no (missing Qt)

[...]

/home/builder/rpm/tmp/dssi-0.9.1-3mdk-buildroot/usr/lib64/dssi/less_trivial
/home/builder/rpm/tmp/dssi-0.9.1-3mdk-buildroot/usr/lib64/dssi/trivial_samp
ler/trivial_sampler_*

Sorry. I'm receiving these build reports, but I can't do anything because I
don't have CVS write access. I've tried to contact Austin Acton several
times, but he doesn't read my messages or he is too much busy. I've attached
a patch for the spec file which I hope fixes the building problems. If not,
perhaps somebody knows how to fix it.
The build system doesn't find Qt, which is needed by the provided GUI for the
two sample plugins included in the package. I don't know for sure how the RPM
BuildRequires: qt3-devel
Another issue: It is necessary that when dssi-devel is installed (in order to
compile some plugin), ladspa-devel should also be installed. I've included it
also this requirement in the patch.
Regards,
Pedro
------------------------------------------------------------------------
? dssi.patch
Index: dssi.spec
===================================================================
RCS file: /cooker/contrib-SPECS/dssi/dssi.spec,v
retrieving revision 1.3
diff -u -r1.3 dssi.spec
--- dssi.spec 3 Apr 2006 01:55:05 -0000 1.3
+++ dssi.spec 6 May 2006 19:57:55 -0000
@@ -19,6 +19,7 @@
BuildRequires: jackit-devel
BuildRequires: libsamplerate-devel
BuildRequires: libsndfile-devel
+BuildRequires: qt3-devel
%description
DSSI (pronounced "dizzy") is an API for audio plugins, with particular
@@ -33,6 +34,7 @@
Summary: Disposable Soft Synth Interface API
Group: Development/C
Requires: %name = %version
+Requires: ladspa-devel
%description devel
DSSI (pronounced "dizzy") is an API for audio plugins, with particular

A *-devel package should _never_ be a Requires, only BuildRequires...

Have you tried to build it this way?
Does it work?
--
Regards

Thomas

[Pedro Lopez-Cabanillas]

Post by Thomas Backlund
A *-devel package should _never_ be a Requires, only BuildRequires...

Are you sure? I can't find this rule written anywere. It doesn't have any
sense to me, either. The dssi-devel package provides a c-language header
file, which in turn includes the ladspa header (provided by ladspa-devel). I
have little experience as a packager, though. Perhaps I'm wrong.

Anybody wanting to use the dssi.h header to develop (or compile) a plug-in
needs to have installed the ladspa.h header in order to be able to do it. It
seems sensible to reflect this dependency in the RPM package.

I can show you some other examples of Mandriva (main) packages, where a -devel
package is required by another -devel package. I've even made a little script
to find them:

[~]$ cat searchreq.sh
#!/bin/bash
CNT=0
for PKG in $(rpm -qa|grep "\-devel"); do
DLIST=""
for DP in $(rpm -q --requires $PKG); do
echo $DP|grep -q "\-devel"
if [ $? == 0 ]; then
DLIST="$DLIST $DP"
fi
done
if [ "x" != "x$DLIST" ]; then
let CNT++
echo "Package: $PKG"
for DP in $DLIST; do
echo -e "\trequires: $DP"
done
fi
done
echo "$CNT packages found"
[~]$

Running the script against a Mandriva 2006.0 RPM database, it shows many
examples. Here are only a few ones:

Package: libpng3-devel-1.2.8-1mdk
requires: zlib-devel
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/libpng/

Package: libqt3-devel-3.3.4-23mdk
requires: XFree86-devel
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/qt3/

Package: libgtkmm2.4_1-devel-2.6.1-1mdk
requires: gtk+2-devel
requires: glibmm2.4-devel
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/gtkmm2.4/

Post by Thomas Backlund
Have you tried to build it this way?
Does it work?

In my Mandriva 2006.0 systems (an amd64 and a 32-bits one) I have no problems
to build the dssi package and the dssi plugins (hexter, fluidsynth-dssi,
xsynth-dssi), because I have all the required software already installed. The
problem comes from Iurt and the Cooker build system environment, which I
don't know very well. Please, help!

Let me explain why I'm complicating my life with this matter, and perhaps I
could awake your solidarity. I'm a musician and a developer, contributing to
some Linux audio applications. Among others, my beloved Rosegarden. Sometimes
I use to show a demo of Linux/Rosegarden/audio apps to other musician
fellows, using Mandriva. I'm also a Mandriva user and supporter. That's the
point why I'm here, at this list. It is a common question after the demo,
that my friends ask me if I can recommend Mandriva as a platform for
Rosegarden. I must answer *not*, because Mandriva doesn't include neither
DSSI nor plugins, and provides a Rosegarden binary package compiled without
DSSI support. I would like to help to fill the gap.

DSSI is a plug-in specification and architecture for soft-musical instruments,
something like the VSTi specification from Steinberg in the proprietary
world, but free as in freedom. It is complementary to the LADSPA
specification, which is a plug-in architecture for audio effects, equivalent
to VST. Some applications using DSSI now are Rosegarden and Om. Support is in
development for MusE and others.

Regards,
Pedro

[Thomas Backlund]

Post by Pedro Lopez-Cabanillas

Post by Thomas Backlund
A *-devel package should _never_ be a Requires, only BuildRequires...

Are you sure? I can't find this rule written anywere. It doesn't have any
sense to me, either. The dssi-devel package provides a c-language header
file, which in turn includes the ladspa header (provided by ladspa-devel). I
have little experience as a packager, though. Perhaps I'm wrong.

Sorry,
I missed the point that it was a -devel package requiring a -devel
package, wich may be ok, ...

Post by Pedro Lopez-Cabanillas
Anybody wanting to use the dssi.h header to develop (or compile) a plug-in
needs to have installed the ladspa.h header in order to be able to do it. It
seems sensible to reflect this dependency in the RPM package.

It can be...
AFAIK the main idea is to keep dependencices to a absolute minimum...
So if you have the following:
foo
foo-devel
bar-devel

and want to create:
foo-module

In this case instead of making foo-module BuildRequire foo-devel wich
Requires bar-devel (thereby forcing everyone install bar-devel, when
they only want foo-devel) you would do:

foo-module BuildRequire foo-devel & bar-devel


Of course if most of foo-devel users anyway needs to install bar-devel,
then the Requires could be ok...

Post by Pedro Lopez-Cabanillas
[~]$ cat searchreq.sh
#!/bin/bash
CNT=0
for PKG in $(rpm -qa|grep "\-devel"); do
DLIST=""
for DP in $(rpm -q --requires $PKG); do
echo $DP|grep -q "\-devel"
if [ $? == 0 ]; then
DLIST="$DLIST $DP"
fi
done
if [ "x" != "x$DLIST" ]; then
let CNT++
echo "Package: $PKG"
for DP in $DLIST; do
echo -e "\trequires: $DP"
done
fi
done
echo "$CNT packages found"
[~]$
Running the script against a Mandriva 2006.0 RPM database, it shows many
Package: libpng3-devel-1.2.8-1mdk
requires: zlib-devel
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/libpng/
Package: libqt3-devel-3.3.4-23mdk
requires: XFree86-devel
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/qt3/
Package: libgtkmm2.4_1-devel-2.6.1-1mdk
requires: gtk+2-devel
requires: glibmm2.4-devel
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/gtkmm2.4/

Post by Thomas Backlund
Have you tried to build it this way?
Does it work?

In my Mandriva 2006.0 systems (an amd64 and a 32-bits one) I have no problems
to build the dssi package and the dssi plugins (hexter, fluidsynth-dssi,
xsynth-dssi), because I have all the required software already installed. The
problem comes from Iurt and the Cooker build system environment, which I
don't know very well. Please, help!
Let me explain why I'm complicating my life with this matter, and perhaps I
could awake your solidarity. I'm a musician and a developer, contributing to
some Linux audio applications. Among others, my beloved Rosegarden. Sometimes
I use to show a demo of Linux/Rosegarden/audio apps to other musician
fellows, using Mandriva. I'm also a Mandriva user and supporter. That's the
point why I'm here, at this list. It is a common question after the demo,
that my friends ask me if I can recommend Mandriva as a platform for
Rosegarden. I must answer *not*, because Mandriva doesn't include neither
DSSI nor plugins, and provides a Rosegarden binary package compiled without
DSSI support. I would like to help to fill the gap.

If they are GPL /Open-Source all those, if so please do help us help you...

But here it comes again, if we provide all those modules as binary rpms,
then I think that the -devel Requires should instead be added as
BuildRequires for those modules...

Post by Pedro Lopez-Cabanillas
DSSI is a plug-in specification and architecture for soft-musical instruments,
something like the VSTi specification from Steinberg in the proprietary
world, but free as in freedom. It is complementary to the LADSPA
specification, which is a plug-in architecture for audio effects, equivalent
to VST. Some applications using DSSI now are Rosegarden and Om. Support is in
development for MusE and others.
Regards,
Pedro

--
Regards

Thomas

[Pedro Lopez-Cabanillas]

Post by Thomas Backlund

Post by Pedro Lopez-Cabanillas
Anybody wanting to use the dssi.h header to develop (or compile) a
plug-in needs to have installed the ladspa.h header in order to be able
to do it. It seems sensible to reflect this dependency in the RPM
package.

[..]

Post by Thomas Backlund
Of course if most of foo-devel users anyway needs to install bar-devel,
then the Requires could be ok...

_Every_ user of dssi-devel _must_ install also ladspa-devel. There is a
#include <ladspa.h> inside the file dssi.h; it has also an #include
<alsa/seq_event.h> so I guess there should be another requirement:

%package devel
Requires: ladspa-devel
Requires: libalsa2-devel

I want to remark that the only piece of software in the dssi-devel package is
this single header. Likewise, the single ladspa.h file is the only software
component of ladspa-devel. There are also documents, of course.

Post by Thomas Backlund

Post by Pedro Lopez-Cabanillas
It is a common
question after the demo, that my friends ask me if I can recommend
Mandriva as a platform for Rosegarden. I must answer *not*, because
Mandriva doesn't include neither DSSI nor plugins, and provides a
Rosegarden binary package compiled without DSSI support. I would like to
help to fill the gap.

If they are GPL /Open-Source all those, if so please do help us help you...

Yes. The DSSI header file is provided under the GNU Lesser General Public
License, see http://dssi.sourceforge.net; the examples are public domain, and
the jack-dssi-host is provided under a BSD-like license.

http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/dssi/

Plugins can have other licenses, of course, but the three plugins that are now
in Cooker (rebuild pending) are GPL licensed:

http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/fluidsynth-dssi/
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/xsynth-dssi/
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/hexter/

After the whole set of packages are in contrib, there will be another problem:
Rosegarden is in main, while the dssi package is in contrib... what can we do
then?

Post by Thomas Backlund
But here it comes again, if we provide all those modules as binary rpms,
then I think that the -devel Requires should instead be added as
BuildRequires for those modules...

The three plug-in specs have already a BuildRequires: dssi-devel. You may want
to patch these specs to include also the ladspa-devel requirement or
otherwise include the Requires: ladspa-devel in the dssi-devel package, which
is my proposal.

Well. At this point, I would like to ask why is it necessary to fullfill all
these details only in x86_64, if the same packages and the same spec files
are building OK in i586:
http://qa.mandriva.com/build/iurt/cooker/i586/log/status.contrib.log
(look for dssi, fluidsynth-dssi, xsynth-dssi and hexter in this report)

Regards,
Pedro

[Thomas Backlund]

Post by Pedro Lopez-Cabanillas

Post by Thomas Backlund

Post by Pedro Lopez-Cabanillas
Anybody wanting to use the dssi.h header to develop (or compile) a
plug-in needs to have installed the ladspa.h header in order to be able
to do it. It seems sensible to reflect this dependency in the RPM
package.

[..]

Post by Thomas Backlund
Of course if most of foo-devel users anyway needs to install bar-devel,
then the Requires could be ok...

_Every_ user of dssi-devel _must_ install also ladspa-devel. There is a
#include <ladspa.h> inside the file dssi.h; it has also an #include
%package devel
Requires: ladspa-devel
Requires: libalsa2-devel
I want to remark that the only piece of software in the dssi-devel package
is this single header. Likewise, the single ladspa.h file is the only
software component of ladspa-devel. There are also documents, of course.

Put like this, I think your solution is correct!

Post by Pedro Lopez-Cabanillas

Post by Thomas Backlund

Post by Pedro Lopez-Cabanillas
It is a common
question after the demo, that my friends ask me if I can recommend
Mandriva as a platform for Rosegarden. I must answer *not*, because
Mandriva doesn't include neither DSSI nor plugins, and provides a
Rosegarden binary package compiled without DSSI support. I would like
to help to fill the gap.

If they are GPL /Open-Source all those, if so please do help us help you...

Yes. The DSSI header file is provided under the GNU Lesser General Public
License, see http://dssi.sourceforge.net; the examples are public domain,
and the jack-dssi-host is provided under a BSD-like license.
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/dssi/
Plugins can have other licenses, of course, but the three plugins that are
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/fluidsynth-dssi/
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/xsynth-dssi/
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/contrib-SPECS/hexter/
After the whole set of packages are in contrib, there will be another
problem: Rosegarden is in main, while the dssi package is in contrib...
what can we do then?

Hmmm,
that's why the dssi is disabled in Rosearden as _no_ package in main is
allowed to depend on contrib packages...

Now we need to check if the dssi is OK to be moved to main, and if so
re-enable dssi support...

Post by Pedro Lopez-Cabanillas

Post by Thomas Backlund
But here it comes again, if we provide all those modules as binary rpms,
then I think that the -devel Requires should instead be added as
BuildRequires for those modules...

The three plug-in specs have already a BuildRequires: dssi-devel. You may
want to patch these specs to include also the ladspa-devel requirement or
otherwise include the Requires: ladspa-devel in the dssi-devel package,
which is my proposal.

Yeah, this seems to be the best solution ...

Post by Pedro Lopez-Cabanillas
Well. At this point, I would like to ask why is it necessary to fullfill
all these details only in x86_64, if the same packages and the same spec
http://qa.mandriva.com/build/iurt/cooker/i586/log/status.contrib.log
(look for dssi, fluidsynth-dssi, xsynth-dssi and hexter in this report)

It can be a bug in the autorequires checks that does not pick up correctly on
x86_64...

Post by Pedro Lopez-Cabanillas
Regards,
Pedro

[Pedro Lopez-Cabanillas]

Post by Thomas Backlund

Post by Pedro Lopez-Cabanillas
After the whole set of packages are in contrib, there will be another
problem: Rosegarden is in main, while the dssi package is in contrib...
what can we do then?

Hmmm,
that's why the dssi is disabled in Rosearden as _no_ package in main is
allowed to depend on contrib packages...

Well, Rosegarden was already in main years ago. DSSI is in Cooker since only a
few weeks ago. That's why we have troubles compiling it in x86_64.

Post by Thomas Backlund
Now we need to check if the dssi is OK to be moved to main, and if so
re-enable dssi support...

Or move Rosegarden to contrib, or create another Rosegarden-dssi package in
contrib with DSSI support (and everything else) enabled.

Post by Thomas Backlund

Post by Pedro Lopez-Cabanillas
Well. At this point, I would like to ask why is it necessary to fullfill
all these details only in x86_64, if the same packages and the same spec
http://qa.mandriva.com/build/iurt/cooker/i586/log/status.contrib.log
(look for dssi, fluidsynth-dssi, xsynth-dssi and hexter in this report)

It can be a bug in the autorequires checks that does not pick up correctly
on x86_64...

Do you think it's time to open a bug report against... Which package, RPM?
Or is there anybody knowing about this issue, and thinking that it is
preferable to provide all the explicit dependencies in x86_64 that aren't
required in i586?

Regards,
Pedro

[Thomas Backlund]

Post by Pedro Lopez-Cabanillas

Post by Thomas Backlund

Post by Pedro Lopez-Cabanillas
After the whole set of packages are in contrib, there will be another
problem: Rosegarden is in main, while the dssi package is in contrib...
what can we do then?

Hmmm,
that's why the dssi is disabled in Rosearden as _no_ package in main is
allowed to depend on contrib packages...

Well, Rosegarden was already in main years ago. DSSI is in Cooker since only a
few weeks ago. That's why we have troubles compiling it in x86_64.

Post by Thomas Backlund
Now we need to check if the dssi is OK to be moved to main, and if so
re-enable dssi support...

Or move Rosegarden to contrib, or create another Rosegarden-dssi package in
contrib with DSSI support (and everything else) enabled.

Post by Thomas Backlund

Post by Pedro Lopez-Cabanillas
Well. At this point, I would like to ask why is it necessary to fullfill
all these details only in x86_64, if the same packages and the same spec
http://qa.mandriva.com/build/iurt/cooker/i586/log/status.contrib.log
(look for dssi, fluidsynth-dssi, xsynth-dssi and hexter in this report)

It can be a bug in the autorequires checks that does not pick up correctly
on x86_64...

Do you think it's time to open a bug report against... Which package, RPM?
Or is there anybody knowing about this issue, and thinking that it is
preferable to provide all the explicit dependencies in x86_64 that aren't
required in i586?

First step done...
a new set of dssi packages are uploaded with your suggested fixes...

Now for the rest...
Have you tried to build Rosegarden with dssi enabled?
Does it work?

If so, I'm going to request dssi move to main, and rebuild Rosegarden...

Those modules can stay in contribs for now...

--
Regards

Thomas

[Pedro Lopez-Cabanillas]

Post by Thomas Backlund
First step done...
a new set of dssi packages are uploaded with your suggested fixes...

Thanks, but I don't expect too much success.

Post by Thomas Backlund
Now for the rest...
Have you tried to build Rosegarden with dssi enabled?
Does it work?

Yes, I've compiled Rosegarden4-1.2.3 successfully in both Mandriva 2006.0
x86_64 and i586 (not RPMs, though). It compiles and works well in both
architectures with DSSI support. But...

* Rosegarden4-1.2.3 doesn't build in cooker-64bit, now. See:
http://qa.mandriva.com/build/iurt//cooker/x86_64/log/rosegarden4-1.2.3-1mdk.src.rpm/

* Rosegarden4-1.2.3 requires SCons (instead of autotools/make). This package
was broken in 2006.0 (x86_64). There was a bug report and it was fixed,
apparently: http://qa.mandriva.com/show_bug.cgi?id=21854

* SCons has been updated in Cooker recently. Only three days ago:
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/SPECS/scons/
I couldn't try this version yet. Other packages requiring SCons had problems
to build, too:
http://qa.mandriva.com/build/iurt//cooker/x86_64/log/ardour-0.99.2-1mdk.src.rpm/

If necessary, Rosegarden4 package includes a scons-mini package. It can be
used to build Rosegarden itself, with only Python as a requirement.

* There are some bugs in Rosegarden4-1.2.3 in the buildsystem. For instance,
when you use "nodssi=1" or other options, the options are ignored and DSSI
support is included anyway, if it was available at compile time :-)
There is a bug affecting the DESTDIR option, and other minor issues. I can
provide patches. Eventually, there will be a release 1.2.4 with those bugs
fixed. Some day.

* About the fluidsynth-dssi plug-in: in 2006.0 the fluidSynth package was too
old, and crashed the stack. I think that Cooker has a newer, good enough one.

* In order to use Rosegarden4 with DSSI plugins, you need jackd (jackit, in
contrib) running first. I recommend to use QJackCtl as a GUI (contrib again).
And jack needs a kernel with low-latency and realtime schedule capabilities
enabled, like the multimedia kernels in both x86_64 and i586 (over good
hardware, of course).

Post by Thomas Backlund
If so, I'm going to request dssi move to main, and rebuild Rosegarden...
Those modules can stay in contribs for now...

Yes, thanks again. I will provide more DSSI plug-in packages in the future.

Regards,
Pedro