hey, put down those rocks... alsaplayer appears to have been resurrected. the new development team has released alsaplayer-0.99.77 with a number of improvements including fixing gtk2 support and the security issues that led to its removal (bug #143402), migrated the repository to SVN, and has begun updating various plugins. redhatter has stepped up and offered to maintain it. i'd like to re-add alsaplayer to the tree under the sound herd with redhatter as co-maintainer. any objections?
(In reply to comment #0) > any objections? > no objection from the security team. Welcome back to alsaplayer :)
No objection from me either, I was missing it.
Created attachment 109998 [details] alsaplayer-0.99.77 ebuild It is the ebuild from the pro-audio overlay. The commented out section for the endian patch is coming from the old 0.76-rn ebuild but it doesn't apply anymore. As I am not sure if it is still needed for ppc, I just commented it out. Work fine here on x86 with gcc.4-1 and safe use flags. I try to compile it by hand with the optimized use flags from the package and it worked fine too.
Created attachment 110000 [details, diff] cxxflags patch
Created attachment 110002 [details, diff] endian ppc old patch
Created attachment 110020 [details, diff] alsaplayer-0.99.77-join-null-thread.patch
Created attachment 110022 [details, diff] alsaplayer-0.99.77-cxxflags.patch
Created attachment 110027 [details, diff] alsaplayer-0.99.77-ppc-endian-fix.patch
Created attachment 110029 [details] alsaplayer-0.99.77.ebuild This is what i'll be committing.
arches, could you please re-keyword media-sound/alsaplayer-0.99.77? thanks.
Why do you disable the gtk interface? gtk+-1.2 is still in portage and the gtk2 interface is not usable..
~amd64 done.
And the gtk2 configure flag is now working, so it would be better to have both a gtk and a gtk2 use flag and someting as: RDEPEND=" ... gtk? ( >=x11-libs/gtk+-1.2 ) gtk2? ( >=x11-libs/gtk+-2.6 ) ...." econf \ $(use_enable audiofile) \ $(use_enable esd) \ $(use_enable flac) \ $(use_enable jack) \ $(use_enable mikmod) \ $(use_enable nas) \ $(use_enable opengl) \ $(use_enable oss) \ $(use_enable nls) \ $(use_enable sparc) \ $(use_enable vorbis oggvorbis) \ $(use_enable gtk) \ $(use_enable gtk2) \ ${myconf} \ --disable-sgi --disable-dependency-tracking \ || die "econf failed" The doc use flag only install the devel doc, and I think at someone that want this doc may want to have a gtk2 flag too. And thanks for the join-null-thread, I forget it.
No, there will be NO gtk2 useflag. If gtk2 works, that would be connected to gtk useflag and that is it. gtk2 useflag was deprecated for a long time now.
Well, but you must understand at Alsaplayer have 2 gtk interfaces, a gtk-1.2 that doesn't have any gtk-2 dependency, and a gtk-2 one that doesn't have any gtk-1.2 dependency. Also, --enable-gtk2 was not working with the 0.99.76 release. The result was at it was compiled in all cases (at least if --enable-gtk was enabled). But now with the 0.99.77, both --enable-gtk and --enable-gtk2 are working, so they can be compiled independently of each other. In consequence, the ebuild need 2 use flags if it will be able to deal with both gtk interfaces and to let the choice to the user. And it is more: I try to run your ebuild with all the use flags enabled and get "configure ... --enable-gtk ... --disable-gtk ..." and the compilation just skipped the gtk interface so I stopped it. You must also understand at the gtk2 interface is unusable because it is a "work in progress". But it doesn't arm. And the gtk-1.2 interface is the one that most users are using, so it is really needed.
~sparc resurrected in the resurrected ebuild.
well, the gtk-1 interface likes to crash in unicode-using locales, so it was disabled (bug #103751). so the choices are gtk2 or nothing. i could add an ewarn about it being incomplete for now...
we could also disable gtk2 support all together, but we really can't in all good conscious enable something that will break for half of our users =/.
Here are my user's locales: LANG=fr_CH.UTF-8 LC_CTYPE="fr_CH.UTF-8" LC_NUMERIC="fr_CH.UTF-8" LC_TIME="fr_CH.UTF-8" LC_COLLATE="fr_CH.UTF-8" LC_MONETARY="fr_CH.UTF-8" LC_MESSAGES="fr_CH.UTF-8" LC_PAPER="fr_CH.UTF-8" LC_NAME="fr_CH.UTF-8" LC_ADDRESS="fr_CH.UTF-8" LC_TELEPHONE="fr_CH.UTF-8" LC_MEASUREMENT="fr_CH.UTF-8" LC_IDENTIFICATION="fr_CH.UTF-8" LC_ALL=fr_CH.UTF-8 and the gtk interface doesn't crash. Maybe at the right solution is to do 2 ebuilds, one with the gtk interface and the second without. As in (bug #103751). Or to put a ewarn in the ebuild. The only thing that doesn't work well with my utf8 locales and the gtk interface is when a filename is in utf8 is at it is not displayed correctly. And I don't think at this will affect half of the users as stated in the other bug because a google search give me only 2 hits: http://www.google.ch/search?q=alsaplayer+%22Missing+charsets+in+FontSet+creation%22&ie=utf-8&oe=utf-8&rls=org.mozilla:fr:unofficial&client=firefox-a
Another thing is at I took a look at the big Indian patch. It is not needed anymore because it is part of a fix from debian: http://lists.tartarus.org/pipermail/alsaplayer-devel/2006-May/001891.html To re-introduce it will only reverse the fix.
Sorry, forget my comment #20. The changes doesn't have been committed for alsa 0.5.
A last things. As Alsaplayer do not provide a .desktop file, it would be great to have the following in src_install(): make_desktop_entry ${PN} "Alsaplayer" ${PN} \ "AudioVideo;Audio;Player"
i think i might be leaning towards your point of view. i want to see if i can find out exactly in what situations the gtk1 interface will crash. if it's a relatively small amount of cases i'll stick an ewarn in the ebuild. if we start getting bugs about it again we'll have to remove it though. that said, i can't produce a crash either. given, i don't know a huge amount about internationalization, but i've tried opening an mp3 with a japanese UTF-8 filename, with an id3 tag containing japanese UTF-8 characters, in a number of locales including ru_RU.UTF-8 which is what the reporter of bug #103751 was using. i get the same messages: Gdk-WARNING **: Missing charsets in FontSet creation Gdk-WARNING **: KSC5601.1987-0 Gdk-WARNING **: GB2312.1980-0 Gdk-WARNING **: JISX0201.1976-0 but it works. the bits that are in UTF-8 in the id3 tag (artist and title) are blank in the player window but the mp3 does play. anyone know what i'm missing?
~ppc keyword added.
i've added -r1 with the interface changes and menu entry.
I thing at it is missing font that cause the problem. KSC5601.1987-0 is a korean Hangul font, GB2312.1980-0 is a chinese font and JISX0201.1976-0 is a japanese one. You can test if you have some of them with xlsfonts | grep ksc xlsfonts | grep gb xlsfonts | grep jis To have those fonts will not solve the problem with the display. It is a well know problem of gtk-1.2 and only a new modern interface for Alsaplayer can solve this. But you will hopefully get ride of the error message.
*at least* put the gtk2 frontend there by default, it can't be more broken than gtk1 frontend which doesn't work at all.
The gtk2 interface is not working in this release and is not installed with this ebuild. If it was installed, but it is not the case, it would be possible to launch it with 'alsaplayer -i gtk2' and to control it from a console with the same commands as used to control the daemon interface. I am working on a new gtk2 interface with an AP user, but we decided to not do any release before we get a nice working gtk2 interface. It already work at least as well as the gtk1 interface with the code in the svn. If you want to try it, use the alsaplayer live ebuild (-9999) in the pro-audio overlay: http://proaudio.tuxfamily.org/wiki/index.php?title=Main_Page (the gtk2 interface is the default with this code from today) If you get in trouble with the svn version or have any suggestion, don't use this bug but please mail me directly or mail alsa-devel mailing list.
alsaplayer-0.99.80_rc1 has been added to portage. the new gtk-2 interface is now installed by default with the gtk USE flag.
It was fast, thank you! BTW, it is a desktop file in alsaplayer-0.99.80_rc1 that is installed in $PREFIX/share/application. So it is no need to install it with portage as in the ebuild.
(In reply to comment #30) > BTW, it is a desktop file in alsaplayer-0.99.80_rc1 that is installed in > $PREFIX/share/application. So it is no need to install it with portage as in > the ebuild. Noticed same thing when installing. Fixed now.
I noticed a mad icon key in AP desktop file. It doesn't matter for now as AP don't have any icon. Anyway, it is fixed in the svn. (not the icon, only the icon key)
Exactly why we have this open? I'm sure Alpha and IA64 users can request it to be keyworded when they need it.
