[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: OpenAL in AMD64

On 8/24/07, Miriam Ruiz wrote:
> It seems that there are problems  with OpenAL in AMD64, does anyone know
> something about itß
> * http://btanks.sourceforge.net/blog/2007/08/21/good-news-everyone/
> * http://www.miriamruiz.es/weblog/?p=100

    For reference, this is being tracked as bug 428375 (1)

On Oct 8, 2007 1:07 AM, Emmet Hikory wrote:
>     I've been able to replicate a crash in torcs that appears to be
> related to this.  Looking in the upstream changelog (1), it appears
> that there was a change to the MMX routines done in March 2006 due to
> differences between gcc 3.x and gcc 4.x.  The current contents of the
> src/arch directory in svn seem much more robust than in the current
> package, and likely to benefit from stronger run-time checking as well
> as better compile-time detection.

    Looking at this issue again recently, I notice that Cyril has
already (in July) packaged the new libopenal in SVN, which doesn't
seem to express this issue in my testing.  Looking through the mailing
list archives, I don't see any comments about this upgrade.  As the
latest upload of openal is in testing, could others also please test
openal 1:0.0.8+svn~r1464-1 from SVN?  If others find it clean, I'd
like to propose a package transition to take advantage of the myriad
upstream fixes available.

    I've reviewed the rdepends, and all are team-maintained excepting
the following:

hugs98 (libhugs-openal-bundled rdepends: none)
osgal (libosgal1 rdepends: none)
pyopenal (python-openal rdepends: none)
soya (python-soya rdepends: balazar, balazar-brothers)

1: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=428375


Reply to: