Portage 2.1.7.6 (default/linux/x86/10.0, gcc-4.4.2-asneeded, glibc-2.11-r0, 2.6.32-rc8 i686) ================================================================= System uname: Linux-2.6.32-rc8-i686-Quad-Core_AMD_Opteron-tm-_Processor_2350-with-gentoo-2.0.1 Timestamp of tree: Sun, 22 Nov 2009 13:30:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.0_p33 dev-java/java-config: 1.3.7-r1, 2.1.9-r1 dev-lang/python: 2.6.2-r2, 3.1.1-r1 dev-python/pycrypto: 2.0.1-r8 dev-util/ccache: 2.4-r8 dev-util/cmake: 2.6.4-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.5.2-r2 sys-apps/sandbox: 2.1 sys-devel/autoconf: 2.13, 2.65 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10.2, 1.11 sys-devel/binutils: 2.20 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.30-r1 ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="*" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openfire/resources/security/ /opt/openjms/config /usr/lib/ccs/conf /usr/lib/fax /usr/share/bufrtables /usr/share/config /usr/share/qpsmtpd/plugins /var/bind /var/lib/hsqldb /var/phxd /var/spool/fax/etc /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-O2 -pipe" DISTDIR="/var/cache/distfiles" FEATURES="assume-digests ccache distlocks fixpackages news parallel-fetch protect-owned sandbox sfperms split-log strict test test-fail-continue unmerge-orphans userfetch" GENTOO_MIRRORS="http://ftp.uni-erlangen.de/pub/mirrors/gentoo" INSTALL_MASK=" /usr/share/doc /usr/share/info" LDFLAGS="-Wl,-O1" MAKEOPTS="-j14" PKGDIR="/var/spool/portage/packages" PORTAGE_COMPRESS="" PORTAGE_CONFIGROOT="/" 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="/var/cache/portage/tree-tinderbox" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl berkdb bzip2 cli cracklib crypt cups dri fortran gdbm gpm iconv ipv6 java5 java6 modules mudflap ncurses nls nostatic nptl nptlonly openmp pam pcre perl pppd python qt3support readline reflection ruby session spl ssl sysfs tcpd unicode x86 xorg zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul 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 auth_digest" ELIBC="glibc" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, LANG, LC_ALL, LINGUAS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Created attachment 211145 [details] Build log
The real solution is to lastrite this dummy transition package I added, http://tinderbox.x86.dev.gentoo.org/misc/rindex/media-libs/libmpcdecsv7 From those new audacious can play SV8 format by ffmpeg now, old k3b will be removed, and rest can just drop their USE musepack since it's only for SV7 anyway. It's a shame xine-lib is unable to use ffmpeg's musepack backend to play modern SV8 format though :(
xine's dead…
(In reply to comment #3) > xine's dead… > Heh, but it Darren Salt still ported latest xine-lib to the new libmpcdec API in latest (now in portage) so that's resolved. The rest can simply lose the dep, and this can be masked and removed
Only need those 2 open bugs, 295051 and 301304 closed and this can be killed off tree.
So this b0rks because of a regression(*) in an autoconf version that is ~arch masked. If it's a patched tarball, why it needs eautoreconf in the first place? That aside, very few actually ported their apps to the new API, and who didn't just loses musepack USE flag. Sounds like a plan. -- * http://lists.gnu.org/archive/html/bug-autoconf/2010-02/msg00011.html
(In reply to comment #6) > So this b0rks because of a regression(*) in an autoconf version that is ~arch > masked. If it's a patched tarball, why it needs eautoreconf in the first place? > > That aside, very few actually ported their apps to the new API, and who didn't > just loses musepack USE flag. > > Sounds like a plan. Sorry, but I fail to see a valid reason why this hack should be kept in tree. All the reverse deps, including xine-lib, k3b, audacious, ffmpeg, gstreamer, vlc... support the new API. I know of only media-sound/cmus and media-sound/moc that don't support it yet. And with this old lib they wouldn't be able to play any newly encoded files anymore, as the old API does not support the SV8 format. So removing as planned.
(In reply to comment #7) > I know of only media-sound/cmus and media-sound/moc that don't support it yet. media-libs/tunepimp also; plus media-sound/mpd has issues when built with sv8 lib Too bad, these happen to be the only apps that I for one care of. > And with this old lib they wouldn't be able to play any newly encoded files > anymore, as the old API does not support the SV8 format. Yes, and knowing this, one wouldn't encode to the new format for the time being.
(In reply to comment #8) > (In reply to comment #7) > > I know of only media-sound/cmus and media-sound/moc that don't support it yet. > > media-libs/tunepimp also; plus media-sound/mpd has issues when built with sv8 > lib > Too bad, these happen to be the only apps that I for one care of. libtunepimp is dead too; "libtunepimp uses the old RDF WebService and should not be used in new development." [1] we should look into lastriting soon. [1] http://musicbrainz.org/doc/libtunepimp and I've tested mpd with new musepack when we did the migration, and it worked fine. whatever issues you might have with it, the solution is not to preserve dead API...
(In reply to comment #9) > libtunepimp is dead too; "libtunepimp uses the old RDF WebService and should > not be used in new development." [1] we should look into lastriting soon. > > [1] http://musicbrainz.org/doc/libtunepimp Okay, but that's a note for software developers, not package maintainers. And there are few packages in the tree that still depend on tunepimp. Oh wait, I know, USE=-musicbrainz, right? > and I've tested mpd with new musepack when we did the migration, and it worked > fine. whatever issues you might have with it, the solution is not to preserve > dead API... I see. Well, actually I don't. Only if you meant to say 'decision' instead of 'solution'?
media-sound/moc, and media-sound/cmus fixed to support SV8 API. USE musepack restored in both. media-libs/tunepimp was always broken with it (it was automagic depend, and the ebuild never listed it as depend in the first place) and since the library is dead wrt upstream, pending removal when they close the RTF service for good media-sound/mpd is fine with new API, open a new bug with sufficient information for reproducing the said "problems" libmpcdec* removed from tree, handled by blockers from musepack-tools instead now
(In reply to comment #11) > media-sound/moc, and media-sound/cmus fixed to support SV8 API. USE musepack > restored in both. Good. > media-libs/tunepimp was always broken with it (it was automagic depend, and the > ebuild never listed it as depend in the first place) Kudos to tunepimp maintainer. > media-sound/mpd is fine with new API, open a new bug with sufficient > information for reproducing the said "problems" Well, if you don't use the software on the daily basis and briefly tested it, you'll hardly spot them "problems", so I count those quotes to typical ignorance. I'll file the bug upstream, though the mpd devs aren't the most friendliest devs out there either.
