I've committed faad2-2.0-r8, that depends on mpeg4ip as it uses always the external version of libmp4v2 (provided by mpeg4ip). For this reason I had to drop a lot of keywords. Arches please test mpeg4ip and faad2 and mark them as such, consider that -r8 is the target stable as soon as possible. Thanks, Diego
There are file conflicts between mpeg4ip and faad2 ebuilds: existing file /usr/lib/libmp4v2.a is not owned by this package existing file /usr/lib/libmp4v2.la is not owned by this package existing file /usr/include/mp4.h is not owned by this package existing file /usr/include/mpeg4ip.h is not owned by this package
Unmerge old faad, remove the stale .la files, and then emerge the new one.
I did it, and it didn't help. All those files belongs to mpeg4ip ebuild after is emerged.
(In reply to comment #3) > I did it, and it didn't help. All those files belongs to mpeg4ip ebuild after > is emerged. They are supposed to belong to mpeg4ip.. faad2 includes an outdated version, it will use the installed version if its there.
(In reply to comment #4) > They are supposed to belong to mpeg4ip.. faad2 includes an outdated version, it > will use the installed version if its there. It seems that for me faad2-2.0-r8 try to overwrite those files. I have tried twice.
arg I think this solution does work.. we need to move libmp4v2 out of the mpeg4ip package... because mpeg4ip depends on ffmpeg which depends on faad2.. circular dep... I'm going to try to make a separate package
I've added media-libs/libmp4v2 in faad2 you can replace the mpeg4ip dep with libmp4v2 remove patch 010_all_configure-mpeg4ip.patch (because libmp4v2 does not provide mpeg4ip-config) We should also check the packages that depend on faad2 to see if they could use just libmp4v2 instead. sparc: I dropped your keyword from app-pda/gtkpod-0.99.0 because it now depends on libmp4v2 too ... and I'm too lazy to file a new bug.
The patch has to be changed, not dropped. Let me wake up and I'll do.
Updating version to test, -r8 was in a circular dep with ffmpeg and mpeg4ip.
Still getting it with -r9: >>> Completed installing faad2-2.0-r9 into /var/tmp/portage/faad2-2.0-r9/image/ * checking 24 files for package collisions existing file /usr/include/mp4.h is not owned by this package existing file /usr/lib64/libmp4v2.a is not owned by this package existing file /usr/lib64/libmp4v2.la is not owned by this package [skipping portage blurb] package media-libs/faad2-2.0-r9 NOT merged These files are owned by freshly installed media-libs/libmp4v2-1.4.1 (not leftovers), according to equery belongs.. George
I'm not an arch tester, but: I'm getting "<media-libs/faad2-2.0-r9 (is blocking media-libs/libmp4v2-1.4.1)" when updating to -r9.
remove <faad2-2.0-r9 ie.. remove faad2
(In reply to comment #11) > I'm not an arch tester, but: I'm getting "<media-libs/faad2-2.0-r9 (is blocking > media-libs/libmp4v2-1.4.1)" when updating to -r9. I've got the same. But emerge -C faad2 && emerge faad2 fixed for me.
(In reply to comment #13) > > I've got the same. But emerge -C faad2 && emerge faad2 fixed for me. > Thanks, that took care of the problem for me as well. I just wondered if the occurence of the block was normal behavior or indicated something wrong with the ebuild.
no its normal intenteded behavior.. they have to block each other because <faad2-2.0-r9 and libmp4v2 provide the same files (libmp4v2.so, mp4.h, etc)
The result is intended, the behaviour is a bug. faad2-2.0-r9 depends on libmp4v2-1.4.1, libmp4v2-1.4.1 has a block on <faad2-2.0-r9. Instead of resolving the block (first upgrade to faad2-2.0-r9) it stops. workaround is: emerge --nodeps faad2 && emerge libmp4v2 portage bug @ http://bugs.gentoo.org/show_bug.cgi?id=79606
(In reply to comment #16) > workaround is: emerge --nodeps faad2 && emerge libmp4v2 This is wrong, you need to unmerge faad2.. then re-emerge it.. it builds against a library provided by libmp4v2 (instead of the copy it has). It is the intended behavior.
got the ~sparc
added ~ppc64
On my latest sync, media-libs/faad2-2.0-r9 depends on media-libs/libmp4v2. media-libs/libmp4v2 is blocking media-libs/faad2-2.0-r9. This is on ~amd64. Rather interesting, isn't it?
libmp4v2 blocks <faad2-2.0-r9 Solution: emerge unmerge faad2 && emerge faad2
Marked ~ppc.
I emerged faad2-2.0-r9 on alpha without any problems. To test it I emerged media-video/vlc-0.8.1-r1 with use USE="aac" and was able to play aac files fine. media-libs/libmp4v2, a new dependency of faad2, will need ~alpha too. I didn't experience any problems emerge'ing libmp4v2 and didn't have any problems running vlc or easytag (bug #111427).
well as there is no other bug report about faad2 and this likely looked upon: i have package collision with xmms use flag (it seems that this forces libmp4v2 to be build in some way), on the other hand with -xmms faad2-2.0-r9|r10 emerges cleanly.
Created attachment 77479 [details, diff] build faad2-xmms plugin against external libmp4v2 can confirm the package collision when building with 'xmms' useflag. Attached is a patch which fixes configure script and Makefiles to link against external libmp4v2. Plus fixing the plugin as there is a small API change between included and external(newer) version of libmp4v2.
When is faad2 going to have a new realease? There are changes in CVS 15 months old but still arent in the faad2 release! Specifically I am referring to the libmp4 xmms plugin. The CVS version has AAC tag support for the xmms playlist. What have the faad2 guys been doing?
I am also hitting on this bug...emerging faad2 dies with xmms keyword. USE="-xmms" allows faad2 to compile cleanly. Portage 2.1_pre4-r1 (default-linux/amd64/2005.1, gcc-3.4.5, glibc-2.3.6-r2, 2.6.15-gentoo-r2 x86_64) ================================================================= System uname: 2.6.15-gentoo-r2 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ Gentoo Base System version 1.6.14 dev-lang/python: 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 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-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O3 -march=athlon64 -pipe -funroll-all-loops -fpeel-loops -ftracer -funswitch-loops -funit-at-a-time -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/share/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon64 -pipe -funroll-all-loops -fpeel-loops -ftracer -funswitch-loops -funit-at-a-time -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.osuosl.org" MAKEOPTS="-j3" PKGDIR="/usr/portage/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 aalib acpi aim alsa apache2 artworkextra avi bash-completion berkdb bitmap-fonts browserplugin bzip2 cd cddb cdr chroot clamav crypt css cups curl dbus divx4linux dv dvd dvdr dvdread eds emboss encode esd evo exif fame ffmpeg firefox flac flash foomaticdb fortran gdbm gif gnome gpm gstreamer gtk gtk2 hal ieee1394 imagemagick imlib java javascript jikes jpeg lcms ldap libcaca live lzo lzw lzw-tiff mad mbox mng mono mozilla moznocompose moznoirc moznomail moznosvg mp3 mpeg nautilus ncurses network nls nptl nptlonly nsplugin nvidia offensive ogg opengl oss pam pcre pdflib perl pic png posix ppds python quicktime readline real sdl smp speex spell sqlite ssl svg tcltk tcpd theora tiff truetype truetype-fonts type1-fonts unicode usb userlocales vcd videos vorbis wmf xine xml xml2 xmms xpm xv xvid xvmc zlib elibc_glibc input_devices_keyboard input_devices_mouse kernel_linux userland_GNU video_cards_nvidia" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LANG, LC_ALL, LDFLAGS, LINGUAS
The current CVS version of FAAD2 is using a bastardised GPL2 that's GPL incompatible. And the failure with +xmms is now fixed in -r11.
heya.. this bug still exists... the xmms plugin collision has been fixed. alpha, arm, hppa, ia64, mips and ppc-macos still need to add ~arch to faad2-2.0-r11 and its dependencies.. hurry up, we're going to move it to stable soon.
xmms plugin still doesn't work with -r11. The patch from bug #120799 isn't enough. -- /usr/lib64/xmms/Input/libmp4.so: undefined symbol: MP4GetTrackAudioType -- Seems nobody even tried it before declaring it as "fixed" :/ I even mentioned the problem already in comment #25( plus providing a working patch which somehow simply got ignored :/)
(In reply to comment #30) > xmms plugin still doesn't work with -r11. The patch from bug #120799 isn't > enough. > -- > Seems nobody even tried it before declaring it as "fixed" :/ > I even mentioned the problem already in comment #25( plus providing a working > patch which somehow simply got ignored :/) the same patch is in bug #123569, I guess we somehowed missed it here, waiting for sound@ to apply it.
Marked faad2-2.0-r11 ~alpha.
2.0-r11 stable on hppa.
has this patch been appiled yet? its been several months aside from stable comments that anyone has said anything
It appears that -r12 is OK, it's still ~ though
arm, ia64, mips, ppc-macos *please mark a newer version testing and stable ASAP or decide yourself to drop the keywords and mask the flag* 2.0-r7 *won't work in current systems anymore after the autotools changes and I won't be fixing it (because I've done that already)*
ppc-macos dropped
faad2-2.0-r13 builds with libmp4v2-1.5 on mips Portage 2.1-r2 (default-linux/mips/2006.1/ip30/o32/nptl, gcc-4.1.1, glibc-2.3.6-r4, 2.6.17.10-mipsgit-20060618 mips64) ================================================================= System uname: 2.6.17.10-mipsgit-20060618 mips64 R10000 V3.4 FPU V0.0 Gentoo Base System version 1.12.1 app-admin/eselect-compiler: [Not Present] dev-java/java-config: [Not Present] dev-lang/python: 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.12 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.13-r3 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.14.4 ACCEPT_KEYWORDS="mips" AUTOCLEAN="yes" CBUILD="mips-unknown-linux-gnu" CFLAGS="-O2 -march=mips4 -pipe -fomit-frame-pointer -ftracer -fforce-addr" CHOST="mips-unknown-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-O2 -march=mips4 -pipe -fomit-frame-pointer -ftracer -fforce-addr" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks metadata-transfer 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" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="berkdb bitmap-fonts cli cracklib dlloader fortran gdbm gpm iconv ip30 isdnlog libwww mips nls nptl nptlonly pam pcre perl pppd python readline reflection sdl session spl ssl tcpd truetype-fonts type1-fonts xorg elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux userland_GNU video_cards_dummy video_cards_fbdev video_cards_impact video_cards_newport video_cards_v4l" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
(In reply to comment #38) > faad2-2.0-r13 builds with libmp4v2-1.5 on mips We don't care whether it builds. Does it work?
Looks like this bug is resolved wrt, 06 Jan 2007; Stuart Longland <redhatter@gentoo.org> faad2-2.0-r13.ebuild: Tested and added ~mips keyword as per Flameeyes' request.
