Bug 132823 – We need pyopenal 0.1.6 to work with openal-0.0.8

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Chris Gianelloni (RETIRED) 2006-05-09 14:02:44 UTC]

The summary pretty much says it all.  I've emailed the author, since 0.1.6, which is released, isn't available in source form.  An oversight, I'm sure.

I'll report back here once I get a response from the author, but this will need to be completed for me to move to only supporting openal-0.0.8 and removing the older CVS snapshot ebuilds from the tree.

Thanks,

[Comment 1 Chris Gianelloni (RETIRED) 2006-05-10 06:58:14 UTC]

From: 		Jiba <[e-mail]>
To: 		Chris Gianelloni <[e-mail]>
Subject: 	Re: PyOpenalAL
Date: 		Tue, 9 May 2006 23:49:32 +0200  (17:49 EDT)


> The PyOpenAL sources for 0.1.6 aren't available from download.gna.org
> yet.  I am working to ensure that we only have OpenAL 0.0.8 (the 1.0
> spec) available in Gentoo's portage tree, and need to have our pyopenal
> package updated to accommodate.  Please let me know when the file is
> available so I can have the package updated in the Gentoo portage tree.
> 
> Thanks,

Oh, that was a mistake and I've forgotten to upload this file.

It is now available at : http://download.gna.org/pyopenal/PyOpenAL-0.1.6.tar.gz

Thank you !

[Comment 2 Chris Gianelloni (RETIRED) 2006-05-19 06:24:35 UTC]

Does anyone from the python team mind if I bump this package myself and close this bug?

[Comment 3 Marien Zwart (RETIRED) 2006-05-19 15:40:04 UTC]

Couple of questions:

(1) Can the "oh-so-ugly new *DEPEND structure necessary to properly support these packages" mentioned in bug 133501 be used here? Looks like it can?

(2) When openal-0.0.8 and freealut are installed pyopenal-1.1.6 builds but cannot be imported because it does not link to alut. Currently the logic in setup.py is "if the response from openal-config --version starts with a 0 we need to link to just openal, else we need alut too". This does not work (both openal-0.0.8 and the latest non-packagemasked snapshot report 0.0.8 as --version). What would be a better check? I do not know the package well enough to think of anything better than a has_version for the versions mentioned in the DEPEND to have a separate alut, which would be ugly.

[Comment 4 Chris Gianelloni (RETIRED) 2006-05-19 16:42:11 UTC]

Well, once I get all of the packages that don't work with the new openal (0.0.8) fixed (and stable), I plan on masking, then removing, all of the CVS snapshot versions, which means we'll be left with *only* the newer openal.  After a somewhat sane period of time (30 days?) after the packages are no more, I will remove the masks.

This should give anyone and everyone enough time to upgrade that are caught in the middle.

[Comment 5 Chris Gianelloni (RETIRED) 2006-06-13 14:09:14 UTC]

I've done this one on the permission of kloeri.