*amarok-1.3.6 (08 Nov 2005) I'll do a check later and see bugs depending on this. It seems like given our current stable version, it's become difficult for users to get upstream support. Once I get kde 3.4.3 rolling for x86 I'll get this started.
Best to get a newer kde stable first and test with that too as chris said.
I was waiting for another bug to be smashed before stable marking. Also, stabling should happen on _all_ arches, I don't want to have sparse keywords also on _this_ package. ^^;
A little update. The first 1.4 beta will probably be seen within a month or two, amaroK development moves _really_ fast, is there any way we can speed up amaroK stabilization in the future? especially with the minor point releases being soley bug fixes to begin with.
Difficult when new versions happens to _remove_ features like alsa output on gstreamer. It can be as fast as you want to develop upstream, the testing is not that fast. Next time, I might consider adding _pre versions of the candidate tarballs for minor releases to speed up testing.
The bug referenced to by Diego has a manageable fix (adding -fno-inline to CFLAGS). I'd like to go with this now if possible and get amarok headed towards stable.
And at the same time, I don't trust the -O3 to be causing that. I'd rather want to see alsa-driver vs in-kernel at this point, because I never had problems on amd64 with -O3.
I'm going to go ahead and get x86 stable looked at tommorow, as it does not appear to be effected by the bug.
1.3.6 x86 stable plzdunbreakkthx.
Hansmi has already marked 1.3.6 stable on ppc.
*** Bug 118670 has been marked as a duplicate of this bug. ***
It would have helped having this request in sound's list ^_^
removing amd64 as amarok-1.3.6 is already stable for us.
Why this is still open? *shrug*
