This is part one of patching alsa ebuilds to compile and emerge cleanly on a working 2005.0 profile system. This is against alsa-lib-1.0.8.ebuild I have isolated the case for amd64 multilib only, so other ebuilds shouldn't have been affected. With this and second part (alsa-oss-1.0.8.ebuild patch) we can drop emul-linux-x86-soundlibs dependency from the 2005.0 profile. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Created attachment 52447 [details, diff] patch part one
Created attachment 52448 [details, diff] patch part two This is part two of patching alsa ebuilds to compile and emerge cleanly on a working 2005.0 profile system. This is against alsa-oss-1.0.8.ebuild
Please assign this patch to the correct team :-) I suggest assigning it to the sound@gentoo.org or/and amd64@gentoo.org Thanks
Created attachment 52537 [details, diff] patch for alsa-lib-1.0.8 cleanup and sanity check - versionator not needed - lib -> lib64
Created attachment 52538 [details, diff] patch for alsa-oss-1.0.8 sanity check - lib -> lib64
I've been testing this patches for a day on variety of programs both using 64-bit and 32-bit library backend. No problems to report thus far.
Any comments on this? I've been using modified/patched ebuild for a week now. Here are the results; 32-bit applications without problems: 1. armyops (aka America's Army) 2. doom3 (linux native version) 3. vmware 4. cedega 64-bit applications without problems: 1. xmms 2. bmp 3. xine 4. mplayer 5. esd and artsd I haven't noticed any glitches using this patched ebuild whatsoever. Is there a reason why nobody commented on this? Since it would replace only emul-linux-x86-soundlibs package, and there are no deep dependencies on this, I strongly suggest applying this to the portage tree. And I would be very pleased if someone would comment on this. Thanks
I knew I had something to test about emul libs... But didn't had time... I'll get it up and let give some feedback tomorrow or in a few days !
Thanks, I appriciate it. On the side note, other patches I did are quite simmiliar to this one, but there are too many packages affected by the changes, and I think that testing process would be enourmous enterprise. Here, the situation is clear, emul-linux-x86-soundlibs doesn't have parent dependencies apart of the glibc. And since we are talking about multilib aware 2005.0 profile, that shouldn't pose a problem. Dario P.S. regarding emul-linux-x86-compat patch (the libstdc++-v3 ebuild) http://bugs.gentoo.org/show_bug.cgi?id=83904 it is pretty trivial and usable, since there are only few lines of changes and multilib was already there but switched off. The problem is that only libstdc++.so.5 which it provides, doesn't cover all of the contest of emul-linux-x86-compat package.
Well, your patch applied properly, and emerging went fine. Everything seems to be OK (given the way you made the patch, it wouldn't seem to make sense if something breaks... but, who knows ^_^) however a couple of comments : - as it blocks emul-linux-x86-soundlibs, it should be quite reasonable to make a fake ebuild as for glibc (emul-linux-x86-glib-1000), and that's what I did - the blocking of emul-linux-x86-soundlibs is quite strange : while I wanted to rebuild alsa-lib, portage complains about the bloking, so I unmerged soundlibs, but after the emerging of alsa-lib, it wanted to merge soundlibs, without talking about blocking packages !? - at least, still about the blocking of emul-linux-x86-soundlibs : the emul package provides a bit more than just alsa-lib in 32bits. There is also jack and libsndfile. So I suppose, it could be a good idea to patch these ebuils the same way you did ;-) PS : Could you see also my comment on #83904 ?
- fake ebuild is a good idea, I'll look into it - about blocking, I did a lame thing around it, actually, I think when I make a fakey, that dependency should be in both ways, because now there is no mention of alsa-lib-* in the emul-linux-x86-soundlibs package so it doesn't block it - you are right, I'll add missing libsndfile and alsajack to it
Created attachment 52865 [details] Fake ebuild
I added the fake ebuild ;-) In fact, blocking alsa-lib from emul package is a bad idea I think, because of the same reasons why there is a fake ebuild for emul-glibc : too many packages to update (well, for soundlibs, there are far less than glibc...).
Okay, I agree, but ... if we don't block emul-* stuff for soundlibs, do I need to correct libsndfile and jack to be incorporated into this (since they are separate ebuilds)? This way, environment would pick up alsa from /usr/lib32 because of precedence of directories, we would have duplicate of libasound and libalsaoss this way, on the other hand ...
Well... in fact, wouldn't the best way be to correct the ebuilds which provides files contained in emul-* packages with patches as you did for alsa ? Actually, I don't understand quite well what you wanted to say in your last comment... BTW, I think a discussion like this should take place in the forums or by mail/msn/irc, no ?
Created attachment 52881 [details, diff] patch for alsa-lib-1.0.8 - adds emul-linux-x86-soundlibs-1000 awareness - absoulute path changed to relative path
Created attachment 52882 [details, diff] patch for alsa-oss-1.0.8 - adds emul-linux-x86-soundlibs-1000 awareness - absoulute path changed to relative path
Created attachment 52883 [details, diff] patch for libsndfile-1.0.11
Created attachment 52884 [details, diff] patch for jack-audio-connection-kit-0.99.0-r1
Created attachment 52885 [details, diff] patch for alsa-jack-1.0.8
This should be all there is in emul-linux-x86-soundlibs package. After some additional testing I think we could remove old emul-*-*-soundlibs version from the 2005.0 profile. Dario
Well, good job ! ... But I don't think it's necessary to make these ebuilds depend on emul-soundlibs : it isn't needed for them to work, but for other progs, which already depend on emul-soundlibds. The fake ebuild is only here not to break this dependency and make the upgrade more easy (=> no need to edit *every* ebuild depending on emul-soundlibds). But as the ebuild doesn't install anything, it's clearly harmless to depend on it... Just a question of sanity ;-)
Okay, sanity check :-)
Created attachment 52907 [details, diff] patch for alsa-lib-1.0.8
Created attachment 52908 [details, diff] patch for alsa-oss-1.0.8
Created attachment 52909 [details, diff] patch for libsndfile-1.0.11
Created attachment 52910 [details, diff] patch for jack-audio-connection-kit-0.99.0-r1
Created attachment 52911 [details, diff] patch for alsa-jack-1.0.8
Created attachment 52929 [details, diff] Patch for alsa-lib-1.0.8 Block old emul-linux-x86-soundlibs packages.
Created attachment 52930 [details, diff] Patch for alsa-oss-1.0.8 Block old emul-linux-x86-soundlibs packages.
Created attachment 52932 [details] New fake ebuild Make emul-linux-x86-soundlibs depend on alsa-lib and alsa-oss.
Updated my local portage tree with latest changes. No issues so far.
I've been using the corrected ebuild for a few days now, no problems to report whatsoever. I have noticed version bump on the alsa-oss-1.0.8 to -r1 in the portage tree, the only change is usr/lib -> /usr/${get_libdir}. Any news on the inclusion of this patches?
Created attachment 53053 [details, diff] patch for alsa-oss-1.0.8-r1 patch update to sync with portage tree
I've created an overlay for this stuff : http://jackmort.free.fr/gentoo-2005.0-amd64/emul-soundlibs-overlay-1.0.tbz2 If someone wants to test, just create an overlay dir, extract this archive, and remerge packages.
wow, really great work you did, Dario. I'm sure we can use this to create the emul-* packages. However, don't expect this to work before 2006.0, since portage isn't fully multilib-capable yet. The final goal is that *every* library in the tree can be built in 32bit and 64bit, and it would be quite messy to patch every single ebuild out there, so the changes will probably be made in portage itself, not the tree.
i'll close it for now as this is a long-term goal and we'll not need it before 2006.0
