mpd offers support for libgme, a library to play various game-music-formats. libgme is even already in portage, but there is no useflag for mpd to turn it on or off as far as I can see. Although the mpd-wikia does not mention it, the flag can be found in the configure-script. It's "--enable-gme". I think adding a gme-useflag is a good idea and is easy to implement. Reproducible: Always
This won't work with current gme in portage. mpd uses pkg-config to find libgme, but gme-0.5.5 doesn't ship a .pc file. Since it looks like nobody really maintains gme, I'll look into adding a subversion snapshot which does include said .pc file. Also, next time just look at the ebuild, it includes --disable-gme, reading that would've stopped you from searching for a USE flag ;)
(In reply to comment #1) > Since it looks like nobody really maintains gme, hu? it has no bug nor new version, what do you want more ??? > I'll look into adding a > subversion snapshot which does include said .pc file. ask upstream, they promised a release some months ago
(In reply to comment #2) > (In reply to comment #1) > > Since it looks like nobody really maintains gme, > > hu? it has no bug nor new version, what do you want more ??? You misunderstood me ;) I didn't say that nobody cares about it, just that no-one specifically maintains it, metadata doesn't list a maintainer, just the sound herd, which I'm part of. > > I'll look into adding a > > subversion snapshot which does include said .pc file. > > ask upstream, they promised a release some months ago Sorry, got that too late, already added the snapshot. Also added the USE flag, so this is fixed.
(In reply to comment #3) > > > I'll look into adding a > > > subversion snapshot which does include said .pc file. > > > > ask upstream, they promised a release some months ago > > Sorry, got that too late, already added the snapshot. ... and then you have to fix the version http://code.google.com/p/game-music-emu/source/browse/trunk/changes.txt look at what will be the next version number...
Created attachment 320120 [details, diff] Patch to insert USE="gme" to mpd's ebuild No pkg-config required in game-music-emu, no need to roll a snapshot
Well, 0.6.0 is what the current sources report: ~ % pkg-config --modversion libgme 0.6.0 So I'm not sure the next version will really be 0.5.6.
(In reply to comment #3) > > > I'll look into adding a > > > subversion snapshot which does include said .pc file. > > > > ask upstream, they promised a release some months ago > > Sorry, got that too late, already added the snapshot. and to be honest, 15 mins after is not what i would call 'too late' :) imho you should remove the snapshot and backport the .pc commit to a -r1, it'll be saner without upstream explanations on why there's been no release; there are two possibilities: 1) slacking, in which case the snapshot is fine 2) new code has problems, in which case the snapshot is bad and considering the 15 mins interval, i doubt you checked this, so the snapshot is not that a great idea, but i may be wrong.
(In reply to comment #5) > Created attachment 320120 [details, diff] [details, diff] > Patch to insert USE="gme" to mpd's ebuild > > No pkg-config required in game-music-emu, no need to roll a snapshot Hm, yeah, would've worked too. But like I said, I've already added it. Either way though, the svn history doesn't really look like they'll release a new version any time soon. Only 1 commit this year, none last year, 4 in 2010, only action was between July and August 2009, when the project was created. So rolling a snapshot didn't seem like a bad idea. Anyway, if any of you wants to remove the snapshot and change the mpd ebuild, feel free to. I'll get some sleep now.
(In reply to comment #7) > (In reply to comment #3) > > > > I'll look into adding a > > > > subversion snapshot which does include said .pc file. > > > > > > ask upstream, they promised a release some months ago > > > > Sorry, got that too late, already added the snapshot. > > and to be honest, 15 mins after is not what i would call 'too late' :) Well, I didn't say _you_ are too late, but _I_ got your comment too late. I.e. after I added it already. > imho you should remove the snapshot and backport the .pc commit to a -r1, > it'll be saner without upstream explanations on why there's been no release; > there are two possibilities: > 1) slacking, in which case the snapshot is fine Looking at the history, definitely this (see above comment) > 2) new code has problems, in which case the snapshot is bad > > and considering the 15 mins interval, i doubt you checked this, so the > snapshot is not that a great idea, but i may be wrong. Again, see above comment, if you really don't want it in the tree, remove it and change the mpd ebuild according to Samuli's patch.
btw, I can see the snapshot in CVS but not the change in mpd's ebuild (which is ~15 minutes now from closing this as FIXED) forgot to push it?
(In reply to comment #9) > > imho you should remove the snapshot and backport the .pc commit to a -r1, > > it'll be saner without upstream explanations on why there's been no release; > > there are two possibilities: > > 1) slacking, in which case the snapshot is fine > > Looking at the history, definitely this (see above comment) http://code.google.com/p/game-music-emu/issues/detail?id=12 maybe ? > > > 2) new code has problems, in which case the snapshot is bad > > > > and considering the 15 mins interval, i doubt you checked this, so the > > snapshot is not that a great idea, but i may be wrong. > > Again, see above comment, if you really don't want it in the tree, remove it > and change the mpd ebuild according to Samuli's patch. well, do you really want to hear my opinion about this 'shoot quick and let others clean up the mess' attitude ? :)
(In reply to comment #10) > btw, I can see the snapshot in CVS but not the change in mpd's ebuild (which > is ~15 minutes now from closing this as FIXED) > forgot to push it? Looks like it, yeah, did now. (In reply to comment #11) > http://code.google.com/p/game-music-emu/issues/detail?id=12 > maybe ? Not quite sure what you're trying to tell me there. The report also says that the current svn condition is perfectly fine for a release. And also that upstream is slacking, given the bug is from April 2011. So this just means the snapshot was fine. > well, do you really want to hear my opinion about this 'shoot quick and let > others clean up the mess' attitude ? :) This was neither 'shoot quick and let others clean up the mess' nor do I care about your opinion. I've tested the snapshot as far as possible (using https://github.com/gulopine/libgme/blob/master/test.nsf with mpd[gme] which plays just fine), the version is just as the package reports. I don't see any mess here. All I can see is a perfectly fine and newer version of gme. Also all I'm saying is that if you're really not okay with the snapshot, go ahead and remove it. I'm not gonna do it. But since I'm not gonna do it, you'd break mpd by doing it, so please apply Samuli's patch, if you're gonna do it.
(In reply to comment #12) > (In reply to comment #11) > > http://code.google.com/p/game-music-emu/issues/detail?id=12 > > maybe ? > > Not quite sure what you're trying to tell me there. The report also says > that the current svn condition is perfectly fine for a release. And also > that upstream is slacking, given the bug is from April 2011. So this just > means the snapshot was fine. > > > well, do you really want to hear my opinion about this 'shoot quick and let > > others clean up the mess' attitude ? :) > > This was neither 'shoot quick and let others clean up the mess' nor do I > care about your opinion. The above discussion should have come _before_ adding the snapshot. The above link shows that indeed it is not _that_ worrysome to have a snapshot. However, adding a .pc file does never justify a snapshot. You just need to add the relevant patch... > I've tested the snapshot as far as possible (using > https://github.com/gulopine/libgme/blob/master/test.nsf with mpd[gme] which > plays just fine), nice, what about the other supported formats ? since it is a shared lib, did you check the abi is the same ? (lots of projects bump soname if they realize abi has changed only before a release) > the version is just as the package reports. <sarcasm> Oh, of course, because you asked and know better :) </sarcasm> However, the changelog disagrees with what the .pc reports. Who is right ? In case of doubt, in order to avoid a false downgrade later, it is always better to take snapshots as ${current_version}_p${date} In most of the cases it will avoid such a downgrade scenario. > I don't see > any mess here. A svn snapshot for a .pc file is a mess. Esp. when other possibilities have not been considered. > All I can see is a perfectly fine and newer version of gme. Time will tell :=) > Also all I'm saying is that if you're really not okay with the snapshot, go > ahead and remove it. I'm not gonna do it. But since I'm not gonna do it, > you'd break mpd by doing it, so please apply Samuli's patch, if you're gonna > do it. I'm fine with the snapshot, that's one less package for me to care about :=) please make sure to fix bugs if they come
(In reply to comment #13) > The above discussion should have come _before_ adding the snapshot. > The above link shows that indeed it is not _that_ worrysome to have a > snapshot. > However, adding a .pc file does never justify a snapshot. You just need to > add the relevant patch... I thought about backporting the patch, but since I did take a look at the whole package (despite you thinking the time it took me is not enough), I definitely considered a snapshot the better alternative. So this was not just about "let's update the package to get mpd working with it" but rather "let's update the package so it's up-to-date and hey, it also makes mpd work with it". > nice, what about the other supported formats ? > since it is a shared lib, did you check the abi is the same ? (lots of > projects bump soname if they realize abi has changed only before a release) We both know that nobody ever tests all supported formats of a library. This simply isn't possible. I don't have access to all formats, I doubt you do. And you're not gonna tell me the ffmpeg guys test every supported format before adding a snapshot, right? As for the ABI, I checked if qmmp and vlc also work fine with it. I know the ABI changed, at least they extended the C++ ABI afaiu. > However, the changelog disagrees with what the .pc reports. Who is right ? > In case of doubt, in order to avoid a false downgrade later, it is always > better to take snapshots as ${current_version}_p${date} > In most of the cases it will avoid such a downgrade scenario. Well, the changelog might disagree, but the rest of the package agrees. It's not only the .pc, the library is also called libgme.so.0.6.0. So even if they'd release a 0.5.6 (out of whatever reason), this might actually still be an upgrade, given the situation looks like they'd either release 0.6.0 from trunk or 0.5.6 from wherever else they have code sitting... or just nothing because they really didn't do anything in over 2 years. > I'm fine with the snapshot, that's one less package for me to care about :=) > please make sure to fix bugs if they come Don't worry. Considering hardly any package uses it, hardly any user uses it and other distributions also added a snapshot, I doubt this will be a lot of maintenance workload. Also, if you stopped caring about the package, we can stop spamming this bug report that was originally about adding a USE flag to mpd, right?
(In reply to comment #14) > > nice, what about the other supported formats ? > > since it is a shared lib, did you check the abi is the same ? (lots of > > projects bump soname if they realize abi has changed only before a release) > > We both know that nobody ever tests all supported formats of a library. This > simply isn't possible. I don't have access to all formats, I doubt you do. I know its not really possible to test all formats here. I was only pointing out that testing with one file is not really a good argument. > And you're not gonna tell me the ffmpeg guys test every supported format > before adding a snapshot, right? You know, ffmpeg has a regression test suite covering almost every format. And they are now doing official releases so that nobody takes snapshots these days. > > However, the changelog disagrees with what the .pc reports. Who is right ? > > In case of doubt, in order to avoid a false downgrade later, it is always > > better to take snapshots as ${current_version}_p${date} > > In most of the cases it will avoid such a downgrade scenario. > > Well, the changelog might disagree, but the rest of the package agrees. It's > not only the .pc, the library is also called libgme.so.0.6.0. So even if > they'd release a 0.5.6 (out of whatever reason), this might actually still > be an upgrade, given the situation looks like they'd either release 0.6.0 > from trunk or 0.5.6 from wherever else they have code sitting... or just > nothing because they really didn't do anything in over 2 years. You are probably guessing right, but that's still a guess. It costs nothing to ask upstream. Its probable that you won't get a quick answer, but it will show them an interest for a new release and remind them about it. There was no rush (and not much need) to jump in and take a svn snapshot of a package that has been stable and mature for more than 1.5 year...
