Portage 2.1.2_rc2-r5 (default-linux/amd64/2006.1, gcc-4.1.1, glibc-2.5-r0, 2.6.19 x86_64) ================================================================= System uname: 2.6.19 x86_64 Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz Gentoo Base System version 1.12.6 Last Sync: Thu, 07 Dec 2006 19:30:01 +0000 dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 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 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r1 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -fomit-frame-pointer -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/X11/xkb" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/terminfo" CXXFLAGS="-O2 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --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="amd64 X a52 aac acpi aiglx aim alsa aotuv asf bash-completion berkdb bitmap-fonts boo bzip2 cairo cdparanoia cdr cli cracklib crypt cups dga dlloader dmi dri dts dvd elibc_glibc examples fam fbcon ffmpeg firefox flac fortran ftp gdbm gif glitz gnome gpm gstreamer gtk2 gtkhtml hal hardened ica iconv imap input_devices_evdev input_devices_keyboard input_devices_mouse ipv6 isdnlog jabber javascript jpeg jpeg2k kerberos kernel_linux krb4 ldap libg++ libwww lm_sensors mad matroska matrox mime mng mono mozsvg mp3 mpeg msn musepack ncurses nls nptl nptlonly nsplugin ogg oggvorbis openal opengl pam pcmcia pcre pdf perl png pnp posix ppds pppd python quicktime readline reflection samba sdl session sndfile soap sockets speex spell spl sqlite3 ssl sv syslog szip tcl tcpd tga theora tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU v4l2 vcd video_cards_apm video_cards_ark video_cards_ati video_cards_chips video_cards_cirrus video_cards_cyrix video_cards_dummy video_cards_fbdev video_cards_glint video_cards_i128 video_cards_i810 video_cards_mga video_cards_neomagic video_cards_nv video_cards_rendition video_cards_s3 video_cards_s3virge video_cards_savage video_cards_siliconmotion video_cards_sis video_cards_sisusb video_cards_tdfx video_cards_tga video_cards_trident video_cards_tseng video_cards_v4l video_cards_vesa video_cards_vga video_cards_via video_cards_vmware video_cards_voodoo vorbis vorbis-psy wifi wmf wxwindows x264 xchattext xine xml xorg xvid yahoo zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
That's a wonderful news... Reopen with exact ebuild name, including category.
Hmmm...
no clue what you want done, please provide more info.
I think that's what he meant, I had discussed it with Diego some months ago and I totally forgot about it. aotuv is a modified libvorbis that that was made to improve sound quality. See : http://www.geocities.jp/aoyoume/aotuv/ It comes as a patch over libvorbis or as a standalone, already patched, libvorbis version. For now we control it via the aotuv useflag over libvorbis, but I do not really like this : this changes the code and might be a problem wrt to keywords. What Diego proposed is to introduce a new virtual and a standalone libvorbis-aotuv. If you have anything against that idea, please speak now ;)
*** Bug 110470 has been marked as a duplicate of this bug. ***
I read somewhere that Release 1 (a.k.a. v4.51) of the aoTuV tuning work will be included in the next release of libvorbis, for whatever that's worth. Can't find the reference.
(In reply to comment #6) > I read somewhere that Release 1 (a.k.a. v4.51) of the aoTuV tuning work will be > included in the next release of libvorbis, for whatever that's worth. Can't > find the reference. That's very interesting, that would save all the work of replacing every dep on libvorbis by the virtual for ex. If you can find the reference or a schedule for that inclusion, that'll be very nice if you could let me know ;)
Best I can do - see Monty's (main dev of Vorbis) comments by searching for AoTuV: http://www.xiph.org/minutes/2006/10/200610_meeting.txt My proposal, until (if) a new revision of libvorbis is released, would be to patch libvorbis-1.1.2 by default with AoTuV R1 and add a "vanilla" use flag for those who don't want it. R1 has been in heavy use for the past year+ by many, every listening test applauds it, Monty likes it, and the author is responsive. Better to offer increased encoding quality and speed to all Gentoo users by default, I think.
media-libs/libvorbis-aotuv-1.1.2 can't be added because of bug 186716, waiting for aotuv upstream to release a new version. or better yet, libvorbis to finally apply aotuv fixes for next release.
just thought i'd mention there's a new b5.5 aotuv release against libvorbis 1.2.0, http://www.geocities.jp/aoyoume/aotuv/
I would vote for simply re-adding the aotuv use flag to libvorbis since it applies cleanly to the latest version again.
Unless another decision is reached, I would like to put the aotuv patch and useflag back in for libvorbis-1.2.0. In the meantime the patched ebuild is available in berkano overlay.
(In reply to comment #12) > Unless another decision is reached, I would like to put the aotuv patch and > useflag back in for libvorbis-1.2.0. In the meantime the patched ebuild is > available in berkano overlay. > libvorbis-1.2.1 was tagged in upstream version control few days ago, expecting tarball to show up anyday now... so does this version of aotuv also work with current trunk and why wasn't it applied there? also it concerns me does it involve silent API/ABI breakage when the patch is applied/not applied?
(In reply to comment #13) > (In reply to comment #12) > > Unless another decision is reached, I would like to put the aotuv patch and > > useflag back in for libvorbis-1.2.0. In the meantime the patched ebuild is > > available in berkano overlay. > > Frankly, conditional patching is *really* ugly; please add it as a new package instead. I think the decision is reached but nobody had the courage to do it because it was supposed to get merged upstream ;)
(In reply to comment #8) > My proposal, until (if) a new revision of libvorbis is released, would be to > patch libvorbis-1.1.2 by default with AoTuV R1 and add a "vanilla" use flag for > those who don't want it. > > R1 has been in heavy use for the past year+ by many, every listening test > applauds it, Monty likes it, and the author is responsive. Better to offer > increased encoding quality and speed to all Gentoo users by default, I think. Everything that you say is true, and I couldn't agree more strongly. Aoyumi's tunings massively increase the quality of the vorbis encoder. Anyone who has half a clue about vorbis as a format is already using aoTuV (paradoxically, it seems that Windows users seem to have more of a clue as to the availability and worthiness of the aoTuV patched encoder than do its open-source supporting proponents). And it's long been the recommended encoder by the folks over at Hydrogenaudio. However this bug is resolved, the fact that Gentoo users don't have easy access to the aoTuV encoder is a terrible shame. (In reply to comment #4) > libvorbis version. For now we control it via the aotuv useflag over libvorbis, > but I do not really like this : this changes the code and might be a problem > wrt to keywords. With all due respect, this is a nebulous objection. We used to have aoTuV support by way of a USE flag and I don't recall a single problem in relation to it. I have always used it on various arches and continue to use it now by way of an ebuild in an overlay. Nor do I recall a single problem ever being reported with the binaries built from aoTuV patched sources that get distributed and consumed by numerous satisfied users including myself (the rarewares.org stuff for example). If it ain't broke - why fix it? (In reply to comment #13) > also it concerns me does it involve silent API/ABI breakage when > the patch is applied/not applied? Um, no - it causes absolutely no breakage whatsoever. I have no idea where you got that notion from. (In reply to comment #4) > What Diego proposed is to introduce a new virtual and a standalone > libvorbis-aotuv. There are numerous ebuilds in portage that introduce third party patches by way of a USE flag and, quite frankly, some of these patches are both more intrusive and more obscure. Imagine if different packages and new virtuals were introduced for all of these cases - what would be the point? As such, I cannot understand why continuing to support such an incredibly worthy and widely used and tested patch is suddenly such a big deal. The phrase "mountains out of molehills" springs to mind. I, for one, would like aoTuV support back. > Unless another decision is reached, I would like to put the aotuv patch and > useflag back in for libvorbis-1.2.0. In the meantime the patched ebuild is > available in berkano overlay. That would be great.
Just a note that the version against 1.2.1_rc1 is here: http://www.geocities.jp/aoyoume/aotuv/test_version/aotuv-b5.5_20080521_RC1.tar.bz2
Noted and committed to berkano overlay. And let the record show that I agree with comment #15. I think it is too much overhead to introduce a virtual for this. But, we really need to put aoTuV back into portage. So if nobody steps up and does the work for the virtual, I propose to reintroduce the aotuv useflag, or alternatively, patch by default and offer a vanilla useflag to disable the patch.
Thank you kindly for re-adding the patch to portage, Ben. It works well on x86. Resolved/closed, finally? On a side note, Vorbis w/aoTuV @32kbps (-q -2) is remarkable, though not listenable for long periods of time.
