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 attachment 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 attachment 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 attachment 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. ***
Created attachment 71023 [details] kwave-0.7.4.ebuild
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 attachment 71166 [details] kwave-0.7.4-r1.ebuild, see comment #11
Created attachment 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.
