Bug 96345 - Kwave ebuild redux
|
Bug#:
96345
|
Product: Gentoo Linux
|
Version: 2005.0
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: enhancement
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: maintainer-wanted@gentoo.org
|
Reported By: mike@nerone.org
|
|
Component: Ebuilds
|
|
|
URL:
http://kwave.sourceforge.net/
|
|
Summary: Kwave ebuild redux
|
|
Keywords: EBUILD
|
|
Status Whiteboard:
|
|
Opened: 2005-06-17 00:38 0000
|
Bug #954 is a very old request for an ebuild for Kwave. There was some
difficulty with it and it was dropped. I'm hoping it's been long enough that it
can be looked at again. The current version of Kwave (0.7.3) even includes an
ebuild in the source tarball. The dependencies need to be updated to support
split ebuilds, so I haven't been able to test it on my split-ebuild system, but
I'd imagine it works for the author: according to the README, Gentoo is his
development platform.
Mike, do you care to produce a working ebuild?
Created an attachment (id=61378) [details]
kwave-0.7.3.ebuild; created by make -f Makefile.am
Jakub, you might try to run a `make -f Makefile.am` on the extracted tarball.
This creates (at least for me) an ebuild. Don't know how messy it is (or even
if it works).
Ah, forget my comment ;) Work is again a bit stressfully (aka me is unable to
read properly). I'll try to create on the upcoming evening/weekend.
Created an attachment (id=61433) [details]
Test media-sound/kwave-0.7.3.ebuild
This is a quick stab at a working ebuild. All I really did was modify the
author's provided ebuild to make it accept kdemultimedia-meta as an alternative
for kdemultimedia, and ditto for kdesdk. This is just until we can figure out
which subpackages it actually needs.
I also removed the USE flag option to use the bundled libaudiofile, adding a
dependency for media-libs/audiofile instead. I left in the author's
'RESTRICT="nomirror"', incidentally. If no dev has the time to do the legwork,
I'll contact the author about this as well as the KDE subpackage dependencies.
Unfortunately, I have to head to bed. I'll leave this test compiling, but I
won't be able to report results tonight (lots of dependencies due to using the
-meta's). I'll post those results tomorrow unless someone beats me to it.
This ebuild did work on my system. I'm going to start ldd'ing a bit to see if I
can narrow down the KDE subpackage dependencies. I'm not a programmer, so this
really isn't my forte. If someone else with more programming expertise can take
a look, please let me know. It's probably going to be ten times more work for me
than it would be for you.
Created an attachment (id=61459) [details]
New split-KDE (backward compatible) ebuild
Ok, it wasn't as hard as I thought. I think this does the trick, but needs to
be tested by others. It no longer needs the -meta's, depending on specific KDE
split ebuilds instead.
The ebuild of 2005-06-18 has problems on my system because of the split-KDE
ebuilds I use:
Calculating dependencies ...done!
[blocks B ] =kde-base/kapptemplate-3.4* (is blocking kde-base/kdesdk-3.4.1)
[blocks B ] =kde-base/kdesdk-kioslaves-3.4* (is blocking
kde-base/kdesdk-3.4.1)
[ebuild N ] dev-util/valgrind-2.4.0 +X 0 kB
[ebuild N ] dev-util/callgrind-0.9.11-r1 259 kB
[ebuild N ] kde-base/kdesdk-3.4.1 +arts -debug +kdeenablefinal -subversion
-xinerama 0 kB
[ebuild N ] kde-misc/kwave-0.7.3 -debug +kdeenablefinal +mmx 0 kB [1]
Hmmm....I use the split ebuilds myself and I don't have that problem. Could you
try swapping the packages within each || clause of DEPEND? I mean replace that
section with:
|| (
>=kde-base/kdemultimedia-arts-3.0.4
>=kde-base/kdemultimedia-3.0.4
)
|| (
>=kde-base/kdesdk-misc-3.0.4
>=kde-base/kdesdk-3.0.4
)
I will readily admit that I don't really understand what logic portage uses to
determine which path of a "||" dependency to try to take. I would think that if
either is blocked, go with the other one, but that would prevent your error.
Another thing I would recommend to anyone using the split ebuilds is to
explicity put all of the non-split packages (e.g. kde-base/kdemultimedia, etc.)
in /etc/portage/package.mask, to make it absolutely clear to portage that only
split ebuilds should be used.
*** Bug 99416 has been marked as a duplicate of this bug. ***
First of all: thank you very much for caring about the ebuild. But I have some
problems with it. (I'm the current maintainer/author of Kwave)
1. the USE-flags "gsl" and "flac" have no effect, please remove them.
Furthermore Kwave does not build properly without them (sonagram and codec_flac
plugins would be broken)
2. the USE-flag "arts" makes no sense. I really need this for the internal
streaming engine. So building with "USE=-arts" fails.
3. the USE-flag "debug" does not work. It produces a "configure: error: bad
value full for --enable-debug"
4. the aclocal line leaved out the "-I ./admin" parameter. I doubt if this is
ok...
5. some dependencies are missing, for example sys-apps/sed, sys-apps/gawk,
sys-apps/coreutils and sys-apps/findutils. I added them again.
The rest of it looks more elegant than my initial attempt. I will commit this
new version to CVS :)
Created an attachment (id=71284) [details]
kwave-0.7.4.ebuild
(In reply to comment #11)
> 1. the USE-flags "gsl" and "flac" have no effect, please remove them.
> Furthermore Kwave does not build properly without them (sonagram and
codec_flac
> plugins would be broken)
Well, I didn't fully test it, but assumed the configure flags are there for a
reason. :)
> 2. the USE-flag "arts" makes no sense. I really need this for the internal
> streaming engine. So building with "USE=-arts" fails.
We have it in kde.eclass and ignore the few cases where it doesn't apply -
maintenance decision. That's why I hardcoded the arts dependency, but you're
right, that desn't really suffice. Time it is to drop aRts. ;)
> 3. the USE-flag "debug" does not work. It produces a "configure: error: bad
> value full for --enable-debug"
See above. The configure flags given are "--enable-debug=full --with-debug"
Maybe you can fix this?
> 4. the aclocal line leaved out the "-I ./admin" parameter. I doubt if this is
> ok...
Usually a simple make -f admin/Makefile.common would do it, instead having to
call distinct binaries of one automake version and not the wrapper scripts. But
granted, I'm not good with autotools and too lazy to find out what's going on.
> 5. some dependencies are missing, for example sys-apps/sed, sys-apps/gawk,
> sys-apps/coreutils and sys-apps/findutils. I added them again.
These packages are in the base profile for all architectures. And since there's
no chance KWave would be built before one of them, the dependencies are usually
not exlicitly listed.
>The rest of it looks more elegant than my initial attempt. I will commit this
>new version to CVS :)
Why don't you just point to this bug?
I've just committed an ebuild for 0.7.9 to the tree.