Since we have 2.6.24 stable in the snapshot, I'd like to get an updated ALSA. If you guys have no objections, add the arches and target KEYWORDS. Otherwise, feel free to close this.
For The Record, I've been using and testing this version daily using stable amd64, and I consider it to be "commit ready" for the mentioned arch.
sounds good to me but we should get Tony's opinion too (chainsaw)
Yes, 1.0.16 is ready for you. Note that there is no alsa-driver ebuild for 1.0.16; testing has primarily happened on AMD64.
Target KEYWORDS: media-libs/alsa-lib-1.0.16.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 sh sparc x86" media-plugins/alsa-plugins-1.0.16.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 ppc ppc64 sh sparc x86" media-sound/alsa-firmware-1.0.16.ebuild:KEYWORDS="amd64 ppc ppc64 sparc x86" media-sound/alsa-headers-1.0.16.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 sh sparc x86" media-sound/alsa-tools-1.0.16.ebuild:KEYWORDS="amd64 ~mips ppc ppc64 sparc x86" media-sound/alsa-utils-1.0.16.ebuild:KEYWORDS="alpha amd64 arm hppa ia64 ~mips ppc ppc64 sh sparc x86" Should alsa-oss be bumped or does it not need it?
(In reply to comment #4) > Should alsa-oss be bumped or does it not need it? 1.0.15 is the newest available; see http://www.alsa-project.org/main/index.php/Download
ppc64 stable
updating to alsa-lib-1.0.16 breaks (at least) skype on my amd64 box (with 1.0.15 everything works fine).
(In reply to comment #7) > updating to alsa-lib-1.0.16 breaks (at least) skype on my amd64 box (with > 1.0.15 everything works fine). I'm assuming this is 2.0.0.68 and not 1.4.0.118? Otherwise, if 2.0.0.63/68 works that should go stable now as well. Note that Skype is a closed binary that we have no control over. If this breaks other applications, that is more severe. Please be sure to test aplay. Also, I need your emerge --info to make this report meaningful.
It's broken teamspeak here, wine, and 32bit firefox [all 32bit apps it seems are broken with dmix]. Everything is fine on .15. Midori ken # emerge --info Portage 2.1.5_rc2 (default-linux/amd64/2007.0, gcc-4.2.3, glibc-2.7-r2, 2.6.24-gentoo-r4 x86_64) ================================================================= System uname: 2.6.24-gentoo-r4 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz Timestamp of tree: Fri, 11 Apr 2008 13:34:02 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.5 dev-lang/python: 2.4.4-r9, 2.5.1-r5 dev-python/pycrypto: 2.0.1-r6 sys-apps/baselayout: 1.12.12 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.62 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18.50.0.1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.24 ACCEPT_KEYWORDS="amd64 ~amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-Os -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx -msse2 -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-Os -march=native -mtune=native -fomit-frame-pointer -pipe -mmmx -msse2 -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect cvs distlocks metadata-transfer multilib-strict parallel-fetch sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="ftp://ftp.uni-erlangen.de/pub/Linux/gentoo http://distro.ibiblio.org/pub/linux/distributions/gentoo/" LANG="en_US.UTF-8" LC_ALL="en_US.UTF-8" LDFLAGS="-Wl,-O1,--as-needed" MAKEOPTS="-j3" PKGDIR="/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /home/ken/projects/kenscodepit/gentoo-overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl alsa amd64 berkdb bitmap-fonts cairo cli cracklib crypt cups dbus divx4linux doc dri dv dvd dvdread dvi encode fame ffmpeg flac fortran gdbm glitz gpm iconv imap isdnlog java jpeg kdeenablefinal mad midi mmx mp3 mpeg mplayer mudflap ncurses nls nptl nptlonly ogg opengl openmp oss pam pcre perl png pppd python qt4 quicktime readline reflection session source spell spl sqlite sse sse2 ssl subtitles svg symlink tcpd theora truetype truetype-fonts type1-fonts unicode vim vim-syntax vorbis xml xorg xvid zlib" ALSA_CARDS="usb-audio hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Possible AMD64 multilib issue being investigated, other arches feel free to test and keyword.
There's no multilib issue. The emul-libs need to be updated, but we need the drivers stable in the tree for x86 first. So, x86 stable, emul-libs, emul-libs stable, then amd64 stable... nothing breaks in stable, then...
(In reply to comment #11) > There's no multilib issue. The emul-libs need to be updated, but we need the > drivers stable in the tree for x86 first. > > So, x86 stable, emul-libs, emul-libs stable, then amd64 stable... nothing > breaks in stable, then... > x86 done, with tsunams blessing
This version of alsa-libs introduced a new rdep on python via smixer-python.so. This is somewhat undesirable as alsa-lib is used in emul-x86-linux and no 32bit python libs exist. Blocking that release. emul-miranda ROOT # qlist -oe alsa-lib | scanelf -f - -n | grep python ET_DYN libpthread.so.0,libdl.so.2,libutil.so.1,libm.so.6,libpython2.4.so.1.0,libasound.so.2,libc.so.6 /usr/lib32/alsa-lib/smixer/smixer-python.so
ppc stable
(In reply to comment #13) > This version of alsa-libs introduced a new rdep on python via smixer-python.so. > > This is somewhat undesirable as alsa-lib is used in emul-x86-linux and no 32bit > python libs exist. Blocking that release. > > emul-miranda ROOT # qlist -oe alsa-lib | scanelf -f - -n | grep python > ET_DYN > libpthread.so.0,libdl.so.2,libutil.so.1,libm.so.6,libpython2.4.so.1.0,libasound.so.2,libc.so.6 > /usr/lib32/alsa-lib/smixer/smixer-python.so > can we not ship smixer-python.so? what links to it?
What about =media-libs/alsa-oss-1.0.15? It has certainly been in the tree long enough.
Marked stable for HPPA: media-plugins/alsa-plugins-1.0.16 media-sound/alsa-utils-1.0.16 media-libs/alsa-lib-1.0.16 media-sound/alsa-headers-1.0.16
The python linking problem can be worked around for now by adding --disable-python to the econf line in the ebuild when building the library for the emul-* packages. It would be nice if the alsa team could add USE=python to the ebuild in the future, since linking against python is optional anyway.
Marked =media-sound/alsa-headers-1.0.16 =media-libs/alsa-lib-1.0.16 =media-plugins/alsa-plugins-1.0.16 =media-sound/alsa-utils-1.0.16 stable on Alpha.
(In reply to comment #16) > What about =media-libs/alsa-oss-1.0.15? It has certainly been in the tree long > enough. > Yes, please add that to the list if you haven't already.
--- sparc --- Tested: =media-sound/alsa-headers-1.0.16 =media-libs/alsa-lib-1.0.16 =media-sound/alsa-utils-1.0.16 All compile fine, all tests passed, no collisions. Binaries and init scripts provided by alsa-utils work properly with test sounds and configurations. Configuration and shared objects from alsa-lib functioning normally. Compiling against alsa-lib and alsa-headers seems to work. Generally, sound system after upgrade works as under alsa-*-1.0.14 (tested with a variety of applications). Tested on a Sun CS4231. alsa-lib USE="midi -alisp -debug -doc" alsa-utils USE="midi nls" emerge --info: Portage 2.1.4.4 (default-linux/sparc/sparc64/2007.0/server, gcc-4.1.2, glibc-2.6.1-r0, 2.6.23-gentoo-r8 sparc64) ================================================================= System uname: 2.6.23-gentoo-r8 sparc64 sun4u Timestamp of tree: Wed, 16 Apr 2008 18:34:01 +0000 ccache version 2.4 [disabled] app-shells/bash: 3.2_p17-r1 dev-lang/python: 2.4.4-r9 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.7.9-r1, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="sparc" CBUILD="sparc-unknown-linux-gnu" CFLAGS="-O2 -mcpu=ultrasparc -pipe" CHOST="sparc-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -mcpu=ultrasparc -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distlocks metadata-transfer sandbox sfperms strict test unmerge-orphans userfetch" GENTOO_MIRRORS="http://adelie.polymtl.ca/ http://gentoo.arcticnetwork.ca/ " MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="aalib alsa apache2 berkdb blas bzip2 cgi cli cracklib crypt curl dedicated dri fftw flac fortran ftp gdbm gpgme gpm iconv isdnlog jabber javascript lapack latex ldap libcaca maildir mailwrapper midi mime mp3 msn mudflap mysql ncurses nethack nls nptl nptlonly ogg openmp pam pcre perl php ppds pppd python readline reflection samba session slang snmp sparc spell spl ssl tcl tcpd tetex truetype unicode vim-syntax vorbis xinetd xml xorg zlib" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" VIDEO_CARDS="dummy fbdev glint mach64 mga r128 radeon sunbw2 suncg14 suncg3 suncg6 sunffb sunleo tdfx v4l voodoo" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Sparc stable for: ================= alsa-headers-1.0.16 alsa-lib-1.0.16 alsa-utils-1.0.16 alsa-tools-1.0.16 alsa-plugins-1.0.16 alsa-oss-1.0.15 (For me, tested with ens1371.) alsa-firmware not installed or tested. Thanks, Aaron.
(In reply to comment #18) > The python linking problem can be worked around for now by adding > --disable-python to the econf line in the ebuild when building the library for > the emul-* packages. > > It would be nice if the alsa team could add USE=python to the ebuild in the > future, since linking against python is optional anyway. > Added in alsa-lib-1.0.16-r1
amd64 stable
(In reply to comment #24) > amd64 stable > how come alsa-driver-1.0.16 is still masked ~amd64?
*** Bug 202419 has been marked as a duplicate of this bug. ***
(In reply to comment #25) > (In reply to comment #24) > > amd64 stable > > > > how come alsa-driver-1.0.16 is still masked ~amd64? > Because it's not maintained by alsa herd (just me, incidentally), and it will remain keyworded unstable.
ia64 stable
Well some arch teams stabilized only part of list. Please stabilize parts that were missed: media-libs/alsa-oss-1.0.15: alpha amd64 hppa ia64 ppc x86 media-sound/alsa-firmware-1.0.16: sparc media-sound/alsa-utils-1.0.16: arm sh media-plugins/alsa-plugins-1.0.16: arm sh media-libs/alsa-lib-1.0.16: arm sh media-sound/alsa-headers-1.0.16: arm sh Well, alsa-oss and alsa-firmware I suppose are not that important for release. All other parts were updated in release...
alsa-oss is now stable for HPPA too.
ia64/x86 stable, and i've dropped sparc keyword on alsa-firmware, no hardware to test
Stabilized alsa-oss-1.0.15 on alpha.
alsa-libs seems to be expecting python2.5 even when it isn't available on the system. (fresh install 0x86_64)
Sorry about that, alsa-oss marked ppc stable.
arm/sh stable
