| Summary: | re-keyword media-libs/tunepimp-0.5.0: new api, new dependency | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Malte S. Stretz <gentoo-bugger> |
| Component: | New packages | Assignee: | Gentoo KDE team <kde> |
| Status: | VERIFIED LATER | ||
| Severity: | enhancement | CC: | agaffney, alpha, amd64, bsd+disabled, hppa, ia64, ppc64, sparc, tychver |
| Priority: | Lowest | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://juffo.org/proj/musicbrainz-overlay/README.html | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Malte S. Stretz
2006-07-09 07:33:20 UTC
tunepimp-0.5 is in cvs, but it remains masked for now, as we need to iron out some issues (see ebuild comments) and also it has a new dependency, media-libs/libofa. arch teams: Please test both libs and re-keyword. Thank you. :) I'm getting this on my PPC64 using gcc-4.1 (compiling libofa-0.9.3): JAMA/tnt_math_utils.h: In function 'Real TNT::hypot(const Real&, const Real&) [with Real = float]': JAMA/jama_svd.h:73: instantiated from 'JAMA::SVD<Real>::SVD(const TNT::Array2D<T>&) [with Real = float]' mainprint.cpp:151: instantiated from here JAMA/tnt_math_utils.h:33: error: call of overloaded 'abs(const float&)' is ambiguous /usr/include/stdlib.h:786: note: candidates are: int abs(int) /usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.1/include/g++-v4/cstdlib:143: note: long int std::abs(long int) can someone confirm this on another arch? Should work now, Markus. See bug 145489. Builds find here on SPARC. What can we test against? Nothing. The only thing in portage able to use tunepimp 0.5 is amarok 1.4.2, but i have failures with it so i haven't enabled it, till i have time to investigate the segfault with amarok devs. Which makes this bug kinda a moot point. Actually, makes the whole presence of tunepimp 0.5 in portage a moot point.... A new version of tunepimp is already out (0.5.1). I don't know if it breaks API compatability though. Musicbrainz also needs bumping from 2.1.2 to 2.1.4. And on an almost totally irrelevant note, helix/realplayer support in amarok would be nice for those of us who have trouble with xine. A new version of tunepimp is already out (0.5.1). I don't know if it breaks API compatability though. Musicbrainz also needs bumping from 2.1.2 to 2.1.4. And on an almost totally irrelevant note, helix/realplayer support in amarok would be nice for those of us who have trouble with xine. What you think the "real" useflag on amarok do, eh? Carlo, why on earth did you add tunepimp 0.5 tho? I can see it crashing on Amarok quite a bit (I'll try 0.5.1 later, hoping nothing breaks), if it was for picard, it was task for whoever was going to add picard to portage.. Can't we just use modified versions of the ebuilds from the gentoo musicbrainz overlay? http://juffo.org/proj/musicbrainz-overlay/README.html I've been messing around with these and my own ebuilds quite a bit. The combination of picard-0.7, musicbrainz-2.1.4, libofa-0.9.3 and libtunepimp-0.5.2 seems stable. As of amarok-1.4.2 musicbrainz has been re-enabled so I don't see why we can't have musicbrainz support in amarok again. Musicbrainz support in Kaudiocreator might be nice too. (In reply to comment #8) > What you think the "real" useflag on amarok do, eh? > > Carlo, why on earth did you add tunepimp 0.5 tho? I can see it crashing on > Amarok quite a bit (I'll try 0.5.1 later, hoping nothing breaks), if it was for > picard, it was task for whoever was going to add picard to portage.. > Any all using real, helix or both of them in use resulted in amarok being built --without-helix. (In reply to comment #8) > Carlo, why on earth did you add tunepimp 0.5 tho? Why shouldn't I? Better the ebuilds in cvs, than forcing another one to do the work again. It's hard masked stuff, so there's nothing to break, unless a user explicitly asks for what he deserves. I made the ebuilds ready, while you were extended afk, but unfortunately coudldn't test, since the Amarok 1.39 -> 1.4.2 update didn't upgrade my postgres db. tunepimp 0.5.1 + Amarok 1.4.3 works fine for me, so when you'd update the Amarok ebuild acordingly, the arch teams can test. Try it on a WMA or FLAC files, they crash amarok, and without an usable backtrace. Don't have any. Creating a flac isn't a problem, but wma? We could disable flac and wma support for now. Tested with multiple mp3, mpc, ogg and flac files - no crashes, everything working fine. I suppose this is either an arch specific issue or a local one. So where are we at with this? Is keywording still desired and do we have anything in the tree to test against? Add us back at a time when you really want tunepimp tested and keyworded. Zzzzz, pointless bug. happend |
