Summary: | emerge blender 2.41 fails - cannot find -lalut (openal-0.0.8 available on x86?) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Josef Reidinger <queen.killer> |
Component: | New packages | Assignee: | Luca Barbato <lu_zero> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | Heinrich.Nirschl, malverian, wolf31o2 |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 133501 | ||
Bug Blocks: | 132826 |
Description
Josef Reidinger
2006-07-01 13:56:49 UTC
-r1 will be _the_ stable. (In reply to comment #1) > -r1 will be _the_ stable. > so, then problem is version number openAL, when portage think that 20051024 is newer than 0.0.8. For me it isn`t problem, I hard-masked old version 2005* in my package.mask but it isn`t "clear" resolution. ref bug #136368, this is an error in the deps, and the only change between this ebuild and -r1 is the deps. Since the build correctly attempts to use -lalut, I believe the correct course of action is to mark -r1 stable... which via ref bug above has been on hold since 6/13.. for a simple dep change??? r1 was stable and now it is the only ebuild available. What do you mean? $ emerge -p =media-gfx/blender-2.41-r1 These are the packages that would be merged, in order: Calculating dependencies !!! All ebuilds that could satisfy "=media-gfx/blender-2.41-r1" have been masked which arch? x86 the r1 has the following keywords KEYWORDS="amd64 ppc ppc64 ~sparc x86" please sync (you made me afraid of a lost commit =P ) I have run a sync today. Looks like it is masked somewhere else... ?! Also, if I add ~x86 to the /etc/portage/package.keywords to try to fix, I get 'invalid atom' or such. =_= Looks like I assumed the new openal was out when it isn't at all. I'll restore the r0 and I'd suggest you to not use p.masked libraries ... ?? That is the only way to get blender to compile, and is the whole point of this thread... ?! Further, openal 0.0.8 is marked stable x86... it should be p.masked what does that mean? openal release has alaut split, blender doesn't expect it and -r1 fixes that issue. Looks like the openal-0.0.8 is somewhat available from the stable profile even if it should stay p.masked till the transition is done. I'll restore the r0 and put a constraint to avoid openal-0.0.8 Hopefully that will fix the problems. Um, read the initial problem report in this thread again! The blender build DOES expect the split -lalut; because it is missing, the build fails... SHEESH! sigh, no -r0 didn't and now doesn't check what version of openal you have and please downgrade/upgrade to the snapshot version. OR unmask r1 and emerge it. It must be very late in your timezone, or you have a very itchy trigger finger to respond to bugzilla. I would suggest some more time spent thinking here. I'll try to help with a problem and solution summary: i) blender (r0) build was failing because the scons build expected split -lalut ii) this split is only available in the most recent openal (0.0.8) and freealut iii) the blender -r1 build claims to fix this, and only differs in its deps. Further, both openal 0.0.8 and freealut are marked stable ...as to your suggestions: a) I cannot 'unmask' blender -r1 because it seems to be 'masked' somewhere else, possibly incorrectly. This is mysterious, as both freealut and openal 0.0.8 are marked stable, and as far as I know, and for me, only blender depends on openal. b) I will not downgrade to a non-working (for the blender build), and obsolete (in time) openal, when the newest one is marked stable. c) There seems to be some confusion as to the -lalut problem initially reported: it is not an ebuild problem, it is an scons REQUIREMENT I suppose you could make a patch to fix the scons problem, or you could correct whatever the problem is with the -r1 build being masked. To recap, openal is already stable on all arches blender supports but amd64, -r1 is currently masked and -r0 got wiped by error. and -r1 cannot be unmasked. -r0 will not build unless openal is upgraded, freealut is installed, and a no-deps build is done. r0 builds with pre split openal. I built it before. You can unmask locally r1 just add it to package.unmask as explained in man portage. I require openal-0.0.8 and freealut-1.1.0 and this has caused me a little inconvenience and head-scratching too. Why do the openal-20050504-r* ebuilds present themselves as upgrades to openal-0.0.8? openal-20050504-r1 is not masked on my x86 system, only the 20051024 ebuild is and -r1 and 0.0.8 are both marked stable. I have had to use /etc/portage/package.mask to stop the openal-2005*s. 2.41-r1 isn't masked anymore... this should be fixed |