Bugzilla Bug 111968

This bug is a bit weird, but if kernel 2.6.14 goes stable, also alsa-*    
1.0.10_rc2 should go stable. alsa-driver 1.0.9 does not build against 2.6.14,    
and that version ships alsa version 1.0.10_rc1 (and for safety alsa-lib should    
be aligned).    
    
This is a problem for sparc that got its keywording removed from alsa-driver 
and that it's still on 1.0.8 for alsa-lib. 
 
Please do what you can, consider that rc2 and rc3 have quite a few fixes for 
alsa-driver that are not in 2.6.14. 
 
I don't really like asking for stabling an rc but... 
 
Thanks, 
Diego

There's an open upstream bug in alsa for sparc, also we don't have 2.6 kernels
stable, so...

1.0.10_rc2 works fine here. x86, please mark stable soon (or give me the OK to
do so) as 2.6.14 has gone stable.

  CC [M] 
/var/tmp/portage/alsa-driver-1.0.10_rc3/work/alsa-driver-1.0.10rc3/acore/misc.o
In file included from
/var/tmp/portage/alsa-driver-1.0.10_rc3/work/alsa-driver-1.0.10rc3/acore/misc.c:77:
/var/tmp/portage/alsa-driver-1.0.10_rc3/work/alsa-driver-1.0.10rc3/acore/misc.inc:494:40:
macro "create_workqueue" passed 2 arguments, but takes just 1
In file included from
/var/tmp/portage/alsa-driver-1.0.10_rc3/work/alsa-driver-1.0.10rc3/acore/misc.c:77:
/var/tmp/portage/alsa-driver-1.0.10_rc3/work/alsa-driver-1.0.10rc3/acore/misc.inc:
In function `snd_compat_create_workqueue2':
/var/tmp/portage/alsa-driver-1.0.10_rc3/work/alsa-driver-1.0.10rc3/acore/misc.inc:494:
error: `create_workqueue' undeclared (first use in this function)
/var/tmp/portage/alsa-driver-1.0.10_rc3/work/alsa-driver-1.0.10rc3/acore/misc.inc:494:
error: (Each undeclared identifier is reported only once
/var/tmp/portage/alsa-driver-1.0.10_rc3/work/alsa-driver-1.0.10rc3/acore/misc.inc:494:
error: for each function it appears in.)
make[4]: ***
[/var/tmp/portage/alsa-driver-1.0.10_rc3/work/alsa-driver-1.0.10rc3/acore/misc.o]
Error 1
make[3]: ***
[/var/tmp/portage/alsa-driver-1.0.10_rc3/work/alsa-driver-1.0.10rc3/acore] Error 2
make[2]: ***
[_module_/var/tmp/portage/alsa-driver-1.0.10_rc3/work/alsa-driver-1.0.10rc3] Error 2
make[1]: *** [modules] Error 2
make[1]: Leaving directory `/usr/src/linux-2.6.12-suspend2-r6'

Could be caused by suspend2 sources, but if it is in gentoo-sources too, then it
should be taken into account by the alsa-driver ebuild.

That should be a problem of only suspend2. Can someone confirm using 
2.6.12-gentoo? 

Stable on x86 ^_^.
Why isnt a new bug filed for rc3 problem? ;)

(In reply to comment #5)
> Stable on x86 ^_^.
> Why isnt a new bug filed for rc3 problem? ;)

You need to mark the dependencies stable as well... alsa-driver is x86, but
alsa-headers is not (Bug 112395); also alsa-lib should be keyworded stable at
the same time. 

CCing x86 again. 

*** Bug 112395 has been marked as a duplicate of this bug. ***

I already did alsa-headers. Looking at alsa-lib now.

All the needed packages should now be marked stable. Now we just wait for what
breaks. 

got some problem with it... I have a different automake version than the
packager

  /bin/sh /var/tmp/portage/alsa-lib-1.0.10_rc2/work/alsa-lib-1.0.10rc2/missing
--run automake-1.7 --foreign  test/Makefile
configure.in:12: version mismatch.  This is Automake 1.7.9,
configure.in:12: but the definition used by this AM_INIT_AUTOMAKE
configure.in:12: comes from Automake 1.7.6.  You should recreate
configure.in:12: aclocal.m4 with aclocal and run automake again.
make[1]: *** [Makefile.in] Error 1

thanks

same problem here as described in #11.

The problem is already fixed as bug #112412.

should/can I mark 1.0.10 packages stable on ppc64 (not the rc3 ones)

that was a question. there is an "?" missing at the end of my last comment...

Test it, because for example 1.0.10 final oopses kernel on ppc :| 

stable on hppa

I have marked 1.0.10 final stable on ppc64. (only alsa-jack is 1.0.10_rc1 as
there is no final)

Mark stable on amd64 too, 'cause it works well. :) 

sparc: you might want to re-keyword alsa as 
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1268 is resolved since 
rc3. 
 

However, on a regular sparc profile, alsa-driver does not compile because its
trying to use the kernel compiler for the configure script rather than the
userland compiler

I was thinking mainly to alsa-lib as 1.0.10 drivers are in 2.6.14 and they 
should be used with the same alsa-lib. 
 

Diego, alsa doesn't work on most sparc systems because -driver doesn't compile
right for 2.4.x (which is the kernel most sparc users use).  I removed ~sparc
from the latest alsa-drivers because you did some CHOST/CTARGET stuff which
breaks when pulling it on sparc with 2.6.X as well... I need to do some messing
with the build system in order for it to work right.  -lib and others are still
in ~sparc and have been since I reported upstream that the sparc alsa-lib bug
was fixed.  Also, kernel 2.6.14 isn't even in ~sparc.  I've been having issues
with it and haven't had time to investigate.

all alsa 1.0.10 package have been marked stable on amd64 including alsa-oss and
alsa-jack

Diego, is there a bug for the ppc segfault issue with 1.0.10?  I've been using
it with no issues.

Have to check it with updated linux-headers, might be fixed.

Arches: currently we're having a bit of scattered keywording on alsa-*
packages.
Can you all state what you can/want to do with such keywording?
If sparc has no stable 2.6 and alsa-driver can't work on 2.4, it would make
sense to leave all alsa ~sparc or something like that?

alsa-lib-1.0.10, alsa-oss-1.0.10-r1, alsa-jack-1.0.10, alsa-headers-1.0.10 &
alsa-utils-1.0.10 sparc stable.
alsa-drivers-1.0.9b was regressed to ~sparc to avoid up/downgrade loops - only
2.6.15 and newer kernel alsa drivers really work ok on sparc (snd-sun-cs4231)
and we really prefer this.
On sparc we currently default to 2.4 kernels and alsa is masked in the stable
profiles so only newer profiles (2006.0) can use it, it still requires cleaning
up since we've got no 2.6 kernel stable but then we'll probably default to the
2006.0/2.4 for building release material which, obviously, defaults to 2.4
kernel & headers and has alsa masked too.
I'll handle alsa-drivers b0rkage in a sepparate bug when i get some time in my
hands, but again, only 1.0.11*+ will probably only cut it, and that's only if
davem pushed the sun-cs4231 fixes upstream.
Diego: I'd say feel free to ditch alsa-drivers-1.0.9b, anyone running alsa on
sparc is using dev and ~arch stuff.

You already know what I think about this, you know I'd like not to mark rc*
stable, you know I don't actually like having it ~arch, too.
But if 2.6.15 is going stable, this has to go stable, too.
Kernel and userland _has_ to be in sync.

This has been marked as blocking 2.6.15 going stable. Why? As far as I can see,
its just a simple keywording thing, ppc are the only arch with <=1.0.10-rc3
marked stable (1.0.10-rc3 is the version included in 2.6.15)

Ok, missed the rename and comment #29 when reading this through the first time.
But to stay in-sync, you should only need to mark 1.0.10-rc3 stable.

there's a bug open of alsa 1.0.10 creating problems with 2.6.15.

Marked hppa stable:
   media-libs/alsa-lib-1.0.11_rc2
   media-sound/alsa-headers-1.0.11_rc2
   media-sound/alsa-utils-1.0.11_rc2

Alternatively we can apply this patch to 1.0.10 and stable that instead:
http://lkml.org/lkml/2005/12/9/124

alsa-utils fails with USE=nls:

make[2]: Entering directory
`/var/tmp/portage/alsa-utils-1.0.11_rc2/work/alsa-utils-1.0.11rc2/speaker-test'
if x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include   
-march=opteron -ggdb3 -pipe -MT speaker-test.o -MD -MP -MF
".deps/speaker-test.Tpo" -c -o speaker-test.o speaker-test.c; \
then mv -f ".deps/speaker-test.Tpo" ".deps/speaker-test.Po"; else rm -f
".deps/speaker-test.Tpo"; exit 1; fispeaker-test.c: In function `main':
speaker-test.c:753: error: `LC_ALL' undeclared (first use in this function)
speaker-test.c:753: error: (Each undeclared identifier is reported only once
speaker-test.c:753: error: for each function it appears in.)
make[2]: *** [speaker-test.o] Error 1
make[2]: Leaving directory
`/var/tmp/portage/alsa-utils-1.0.11_rc2/work/alsa-utils-1.0.11rc2/speaker-test'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/var/tmp/portage/alsa-utils-1.0.11_rc2/work/alsa-utils-1.0.11rc2/speaker-test'
make: *** [all-recursive] Error 1

!!! ERROR: media-sound/alsa-utils-1.0.11_rc2 failed.
!!! Function src_compile, Line 31, Exitcode 2
!!! make failed

Portage 2.0.53 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r2,
2.6.12-gentoo-r6 x86_64)
=================================================================
System uname: 2.6.12-gentoo-r6 x86_64 AMD Opteron(tm) Processor 242
Gentoo Base System version 1.6.13
dev-lang/python:     2.3.5-r2, 2.4.2
sys-apps/sandbox:    1.2.12
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="amd64"
AUTOCLEAN="yes"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=opteron -ggdb3 -pipe"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env
/usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/lib/fax /usr/lib64/mozilla/defaults/pref
/usr/share/config /usr/share/texmf/dvipdfm/config/
/usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/
/usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/alias
/var/qmail/control /var/spool/fax/etc /var/vpopmail/domains /var/vpopmail/etc"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=opteron -ggdb3 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig buildpkg collision-protect cvs debug distlocks keeptemp
keepwork multilib-strict noauto nostrip sandbox sfperms test"
GENTOO_MIRRORS="ftp://mirror.switch.ch/mirror/gentoo"
LC_ALL="en_GB.UTF-8"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.gentoo.org"
USE="amd64 X acpi alsa audiofile avi berkdb bitmap-fonts bonobo browserplugin
bzip2 chipcard crypt cups curl debug dvd eds emboss encode esd ethereal exif
expat fam ffmpeg flac font-server foomaticdb fortran gcj gd gdbm gif glut gmp
gnome gpm gsm gstreamer gtk gtk2 gtkhtml guile hal hbci idn imagemagick imlib
ipv6 java jp2 jpeg kde lcms ldap libwww lzw lzw-tiff mad mhash mng motif
mozilla mp3 mpeg mysql ncurses network nls nptl nptlonly nsplugin objc objc-gc
ofx ogg oggvorbis opengl pam pcre pdflib perl png postgres python qt quicktime
quotes readline sdl spell ssl svg tcltk tcpd tetex tiff truetype truetype-fonts
type1-fonts udev usb userlocales utf8 vorbis wxgtk1 xine xml xml2 xpm xrandr xv
zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LDFLAGS, LINGUAS, MAKEOPTS, PORTDIR_OVERLAY

alpha, amd64, ia64, ppc, ppc64, x86:

Please mark alsa-driver-1.0.10-r2 stable ASAP. Since the original release, it
fixes a possible oops, and changes the GFP flags to be compatible with 2.6.15.

sparc no longer relevant, it has it's own bug and will be looked into in due
time.

x86 done

stable on ppc64

1.0.10-r2 stable on amd64

Marked ppc stable.

I think we're done then