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

Thomas Backlund <[email protected]> Sun, 7 May 2006 17:30:15 +0300
Newsgroups gmane.linux.mandrake.cooker.amd64
Message-ID <[email protected]>
s=F6ndag 07 maj 2006 16:45 skrev Pedro Lopez-Cabanillas:
> On Sunday, 7 May 2006 14:40, Thomas Backlund wrote:
> > Pedro Lopez-Cabanillas wrote:
> > > 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 ab=
le
> > > to do it. It seems sensible to reflect this dependency in the RPM
> > > package.
>
> [..]
>
> > 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.

Put like this, I think your solution is correct!

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

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

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

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

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

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


> Regards,
> Pedro

=2D-=20
=2D-
Regards

Thomas