This thing is multiborked, doesn't compile, crashes, hasn't been updated for ages and generally just needs to catch up w/ current upstream or be removed.
zypher hasn't touched avidemux in a year and a half and doesn't seem to be around anymore. i'll go through the open bugs and try to get it back on its feet.
actually, it looks like someone's already got it covered (bug #150175).
(In reply to comment #1) > zypher hasn't touched avidemux in a year and a half and doesn't seem to be > around anymore. i'll go through the open bugs and try to get it back on its > feet. > If you do, then, please : a) Remove all the automagic dependencies. This should be fixed in version 2.4 upstream, but afaik it's not released yet. You can grab a patch I had attached for a 2.3 preview somewhere in the bugzilla. b) Remove all the internal statically built libs (for ex. ffmpeg). This is useless and cause extra maintainance when, for example, there is a security problem in the lib or an api change of a lib that it depends on (hey, why the current version in the tree doesn't build with the latest x264 svn? ...). I'm not aware of any fix for this yet and such a patch might be painful to write. Obviously, the way to go is to merge that external lib support upstream so that it won't be a problem for future versions. This does not seem to be an option to remove it since it's a popular "alive upstream" package so we're there... Some time ago I would have liked to remove it, but since the automagic patch has been merged upstream, we will not have any choice but readding it later on. Regarding bug #157814 we'll have to p.mask it until, at least, 2.4 is out.
p.masked sorry for the delay
*** Bug 161199 has been marked as a duplicate of this bug. ***
Will you guys get a clue! avidemux-2.3 FINAL was released 12/2/2006. It compiles just fine given a proper ebuild. Why just wait until 2.4. Why not wait until 6.66?
thanks for your proper ebuild. i think you forgot to attach it though. you'll also have to fix the bugs that are blocking this one and find a maintainer so we can unmask it. :P
(In reply to comment #3) > b) Remove all the internal statically built libs (for ex. ffmpeg). This is > useless and cause extra maintainance when, for example, there is a security > problem in the lib or an api change of a lib that it depends on (hey, why the > current version in the tree doesn't build with the latest x264 svn? ...). I'm > not aware of any fix for this yet and such a patch might be painful to write. > Obviously, the way to go is to merge that external lib support upstream so that > it won't be a problem for future versions. Agreed, this is my biggest reason for not wanting to support it. Upstream is active though, so there might be a chance of getting it fixed, if someone wants to work with them. 2.3.0 fails QA checks as well, so I recommend not bumping.
QA Notice: Package has poor programming practices which may compile fine but exhibit random runtime failures. slice.c:157: warning: incompatible implicit declaration of built-in function 'printf' timer.c:127: warning: incompatible implicit declaration of built-in function 'abort' timer.c:144: warning: incompatible implicit declaration of built-in function 'abort'
Hell, avidemux is actually a video editor that works and you guys remove it! Insane! Mark it as unstable, but DON'T hardmask it!
(In reply to comment #10) > Hell, avidemux is actually a video editor that works and you guys remove it! > Insane! > Mark it as unstable, but DON'T hardmask it! Oh, really insightful... :P Now after you've read the 8 bugs this one depends on, then come back; until then, no shut up if you have nothing useful to say. Thanks.
Guys, complaining isn't going to help. We need code. It doesn't matter how great and wonderful a package it is if it doesn't work. We don't keep broken packages in our tree, period. If you want to help, please post patches.
Did this really depend on all mentioned bugs ? It seems to me more like "everything fixed in 2.3, but 2.3 didn't compile for unspecified reason" ... or worse, it WILL compile, only you don't like some warnings it produces.
By the way, p.masking does not imply that it's going to be deleted. From the handbook you can read : package.mask means that the package has been found corrupt, unstable or worse and has been deliberately marked as do-not-use. Which is actually the case. You are free to unmask it or use an overlay. For those complaining about 2.3 not being in the tree, comment #3 applies to 2.3. I had a look at how to remove internal ffmpeg, it might not be that easy, they have custom wrappers (that could be moved to a different file imho) and use libswscale, what gentoo's ffmpeg is not currently doing.
Created attachment 107944 [details] little changes to the original, works for me This ebuild works for me, I will also add the both patches, which have to move to files directory. They may be wrong, I don't test this right, but as I already say, it works for me.
Created attachment 107946 [details] little changes to the original, works for me This ebuild works for me, I will also add the both patches, which have to move to files directory. They may be wrong, I don't test this right, but as I already say, it works for me.
Created attachment 107948 [details] patch file no. 1
Created attachment 107949 [details] patch file no. 2
Oh, I'm so stupid, I should name the files right. The files are: my 'little changes' has to be named: avidemux-2.3.0-r1.ebuild patch file 1: avidemux-2.3.0-configure.patch patch file 2: avidemux-2.3.0-dts.patch Regards Lars
(In reply to comment #16) > Created an attachment (id=107946) [edit] > little changes to the original, works for me > > This ebuild works for me, I will also add the both patches, which have to move > to files directory. They may be wrong, I don't test this right, but as I > already say, it works for me. > Add a diff, not a new ebuild.
Sorry that I'm ask, but a diff from what? From the ebuild? I've done no changes to the source avidemux-2.3.0.tar.bz2 I only checked the berkano avidemux-2.3.0_pre2.ebuild to the current avidemux-2.3.0.ebuild and fix some changes. Thats all. I've done the changes with the famous emacs ediff tool. The result is a new ebuild, not a diff. ;-) If you need yet a diff, please, take my ebuild, take the one in the portage and do a diff by yourself. For the future I will post diffs here. The patches are direct from the berkano portage overlay, I only rename it to the names, the current ebuild would get. Source from: http://berkano.net/svn/berkano-overlay/media-video/avidemux/ Big thanks to berkano. Kind Regards Lars
A diff between : http://sources.gentoo.org/viewcvs.py/gentoo-x86/media-video/avidemux/avidemux-2.3.0.ebuild?rev=1.2&view=markup and your ebuild with a command like : diff -u old new that's to easily understand what your ebuild improves to the current one in portage. Of course comments on the changes are also very welcome ;)
(In reply to comment #19) > Oh, I'm so stupid, I should name the files right. > The files are: > > my 'little changes' has to be named: avidemux-2.3.0-r1.ebuild > patch file 1: avidemux-2.3.0-configure.patch > patch file 2: avidemux-2.3.0-dts.patch > > Regards > Lars > Actually, those patches are already in there. :)
A couple of points on this issue. Hard masking through lack of maintenance seems to me a lazy cop-out. Continuing to hardmask and not version bump because of QA failures (see Comment #8) is also a non-solution. Do we also hardmask or resist version bumps for the hundred or so other core packages in the portage tree that exhibit this behaviour ? Try a `ls /var/log/portage/ | xargs grep "QA Notice: Package has poor programming" | awk -F: '{print $1,$2}' | uniq` sometime. You'll note key packages such as the following fall into this category: net-misc/openssh sys-apps/hal sys-libs/pam x11-base/xorg-server x11-libs/gtk+ dev-libs/glib and so on... The existence of it's internal ffmpeg libs are there for the same reason MPlayer packages it's own version of ffmpeg libs - FFmpeg's libs change radically from week to week with no formal release other than SVN snapshots. Relying on such a dynamic set of external libs would be almost impossible to support and almost certainly break the package within a short space of time. Trying to remove the internal ffmpeg libs would be a lot of work for a negative gain. To summarise: avidemux-2.0.42-r1 - Doesn't use x264 avidemux-2.1_pre1 - Doesn't compile against latest x264 (USE flag removed) avidemux-2.3 - Does compile against latest x264 So the only work left to do is: * Commit the configure script patch so that USE flags are respected and dependencies are not automatically used if detected (possibly also backporting the patch to 2.0.42 and 2.1 as revisions) * Unmask all p.masked avidemux packages leaving 2.0.42-r1 as stable, 2.1_pre1 and 2.3 as keyword masked I'm not sure how complete the configure script patch is, time permitting I'll try and take a look at it later today.
(In reply to comment #24) > A couple of points on this issue. > > Hard masking through lack of maintenance seems to me a lazy cop-out. > > Continuing to hardmask and not version bump because of QA failures (see Comment > #8) is also a non-solution. > Do we also hardmask or resist version bumps for the hundred or so other core > packages in the portage tree that exhibit this behaviour ? Yes. We do mask any package that has as many problems as avidemux. > Try a `ls /var/log/portage/ | xargs grep "QA Notice: Package has poor > programming" | awk -F: '{print $1,$2}' | uniq` sometime. > > You'll note key packages such as the following fall into this category: > net-misc/openssh > sys-apps/hal > sys-libs/pam > x11-base/xorg-server > x11-libs/gtk+ > dev-libs/glib > and so on... No. Those packages have compiler warnings that match an arbitrary set chosen by one dev. They have nothing to do with QA problems. > The existence of it's internal ffmpeg libs are there for the same reason > MPlayer packages it's own version of ffmpeg libs - FFmpeg's libs change > radically from week to week with no formal release other than SVN snapshots. Are you aware of how many times that's turned into a major maintenance headache, causing broken systems and security problems? Why on earth would we want to take on yet another branch of ffmpeg, not to mention an unmaintained one? MPlayer has an active maintainer who is very close to upstream and still manages to cause ffmpeg breakage every couple months. > Relying on such a dynamic set of external libs would be almost impossible to > support and almost certainly break the package within a short space of time. > Trying to remove the internal ffmpeg libs would be a lot of work for a negative > gain. Yet we do it for xine-lib, blender, gpac... Go figure. Must be a lazy cop-out. > So the only work left to do is: > * Commit the configure script patch so that USE flags are respected and > dependencies are not automatically used if detected (possibly also backporting > the patch to 2.0.42 and 2.1 as revisions) > * Unmask all p.masked avidemux packages leaving 2.0.42-r1 as stable, 2.1_pre1 > and 2.3 as keyword masked * Find a maintainer willing to either decouple ffmpeg from avidemux, or will keep an overlay of patches to keep the internal version consistent with the versions in the tree.
(In reply to comment #25) >> Hard masking through lack of maintenance seems to me a lazy cop-out. >> >> Continuing to hardmask and not version bump because of QA failures (see >> Comment >> #8) is also a non-solution. >> Do we also hardmask or resist version bumps for the hundred or so other core >> packages in the portage tree that exhibit this behaviour ? > Yes. We do mask any package that has as many problems as avidemux. Interesting... >> Try a `ls /var/log/portage/ | xargs grep "QA Notice: Package has poor >> programming" | awk -F: '{print $1,$2}' | uniq` sometime. >> >> You'll note key packages such as the following fall into this category: >> net-misc/openssh >> sys-apps/hal >> sys-libs/pam >> x11-base/xorg-server >> x11-libs/gtk+ >> dev-libs/glib >> and so on... > No. Those packages have compiler warnings that match an arbitrary set chosen > by one dev. They have nothing to do with QA problems. Your statement makes no sense. They match the exact same QA problem mentioned in Comment #8, yet these core packages are not hardmasked and the QA warnings are left as warnings. >> The existence of it's internal ffmpeg libs are there for the same reason >> MPlayer packages it's own version of ffmpeg libs - FFmpeg's libs change >> radically from week to week with no formal release other than SVN snapshots. > Are you aware of how many times that's turned into a major maintenance > headache, causing broken systems and security problems? No, can you name one instance ? How can letting avidemux use it's own source be a maintenance headache ? > Why on earth would we want to take on yet another branch of ffmpeg, not to > mention an unmaintained one? We're not, we're allowing the package to use it's own internal libs. > MPlayer has an active maintainer who is very close to upstream and still > manages to cause ffmpeg breakage every couple months. This is utter nonsense. FFmpeg and MPlayer packages are totally seperate packages, and MPlayer uses it's own internal ffmpeg libs. >> Relying on such a dynamic set of external libs would be almost impossible to >> support and almost certainly break the package within a short space of time. >> Trying to remove the internal ffmpeg libs would be a lot of work for a >> negative gain. > Yet we do it for xine-lib, blender, gpac... Go figure. Must be a lazy > cop-out. No we don't, those packages already have the configure option to use either internal or external ffmpeg libs, external is usually (not always, check the Changelogs) favoured because it adds extra functionality. >> So the only work left to do is: >> * Commit the configure script patch so that USE flags are respected and >> dependencies are not automatically used if detected (possibly also >> backporting the patch to 2.0.42 and 2.1 as revisions) >> * Unmask all p.masked avidemux packages leaving 2.0.42-r1 as stable, >> 2.1_pre1 and 2.3 as keyword masked > * Find a maintainer willing to either decouple ffmpeg from avidemux, or will > keep an overlay of patches to keep the internal version consistent with the > versions in the tree. Versions of what ? FFmpeg's libavformat/libavcodec lib is an internal lib of avidemux, in exactly the same way that it is for MPlayer, I can't be any more clearer than this. If you were perhaps attempting to argue that avidemux installed it's own version of libavformat.so or libavcodec.so so that it interfered with or confused those apps. that compiled against the external ffmpeg's libavformat.so or libavcodec.so, then I could understand, but it doesn't. It compiles one binary called 'avidemux2' with it's own internal libs linked in. With all due respect, it would seem your basic understanding of how FFmpeg's libs work and the different ways in which they maybe distributed is fundamentally flawed. Might I suggest you speak with Diego Petteno (flameeyes) before continuing further with this or any other 'media-video' package.
People stop ranting here! This thing will remain package.masked until it does not sucks goats nuts (see all the linked bugs here).
> > No. Those packages have compiler warnings that match an arbitrary set chosen > > by one dev. They have nothing to do with QA problems. > > Your statement makes no sense. They match the exact same QA problem mentioned > in Comment #8, yet these core packages are not hardmasked and the QA warnings > are left as warnings. And if you look closely, I not only posted that comment, but put avidemux 2.3.0 into the tree. :) It's not going to get removed from the tree while there is an active upstream that is working on fixing the problems. It might be masked for a bit longer, I know it's a minor annoyance, but simple to fix once and you're done.
(In reply to comment #26) > Your statement makes no sense. They match the exact same QA problem mentioned > in Comment #8, yet these core packages are not hardmasked and the QA warnings > are left as warnings. I'm not sure what you're talking about. Comment #8 is Steve saying he agrees that having an internal ffmpeg is a problem. That is the main reason for the masking. Well, that and the list of bugs at the top of this report. I may be mistaken, but I don't believe the QA checks he mentions are the same as the compile warning filtering stuff that just got added to portage. In the majority of cases, those warnings are just that - warnings. Also note that said core packages are actively maintained. > No, can you name one instance ? > How can letting avidemux use it's own source be a maintenance headache ? Read comment #3, or try a comment search for dsputil_mmx for one example (http://tinyurl.com/29864j). You can see http://www.gentoo.org/proj/en/desktop/video/xine.xml for some info on why external ffmpeg is preferred in regard to xine, the reasons are the same here. Also see below. > Versions of what ? > FFmpeg's libavformat/libavcodec lib is an internal lib of avidemux, in exactly > the same way that it is for MPlayer, I can't be any more clearer than this. > > If you were perhaps attempting to argue that avidemux installed it's own > version of libavformat.so or libavcodec.so so that it interfered with or > confused those apps. that compiled against the external ffmpeg's libavformat.so > or libavcodec.so, then I could understand, but it doesn't. > It compiles one binary called 'avidemux2' with it's own internal libs linked > in. > > With all due respect, it would seem your basic understanding of how FFmpeg's > libs work and the different ways in which they maybe distributed is > fundamentally flawed. With all due respect, it seems you haven't considered that building an internal version of a library still requires linking with other libraries on the system. Also, you seem to have forgotten that ffmpeg and friends like to break ABI every other month. For example, what happens when you try to compile avidemux against a version of x264-svn that is incompatible with it's internal ffmpeg version? Yay, bug #143664! Look hard at this bit: "Unfortunately, media-video/mplayer-1.0_pre20060810 requires the new x264-svn, so that it is now not possible to have avidemux and the current mplayer on the same system." Good fun to be had by all, yours thanks to incompatible internal versions of the ffmpeg library. Guess what happens when we have a security bug in libavcodec like, say, CVE-2005-4048? Yep, we get to dig through not only ffmpeg, but every package that contains an internal ffmpeg to determine if they're affected, and if they are we get to patch, bump, and/or stable fixed versions, and in some cases issue GLSAs for each package. http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-4048 http://www.gentoo.org/security/en/glsa/glsa-200602-01.xml http://www.gentoo.org/security/en/glsa/glsa-200603-03.xml http://www.gentoo.org/security/en/glsa/glsa-200601-06.xml I'm not saying these problems aren't solvable or manageable, but they do require someone to be paying close attention to them. That is what I mean when I say we need an __active maintainer__ for avidemux who can either make it work with an external ffmpeg, or is willing to keep the internal version in such a state that is secure and compatible with the media libraries we have in the portage tree. Perhaps you also might have also overlooked that it is not my requirement that avidemux use an external ffmpeg, but it was first requested by aballier and confirmed by beandog, both members of the video project, and who I trust know their shit. > Might I suggest you speak with Diego Petteno (flameeyes) before continuing > further with this or any other 'media-video' package. Would that be the Diego Pettenò who spent considerable time and effort separating the internal ffmpeg libraries from xine-lib and pushing it upstream, and who also wrote this? http://farragut.flameeyes.is-a-geek.org/articles/2006/07/06/how-many-copies-of-ffmpeg I don't think that really helps your case. If you want to argue this further we can do it through email. Bugzilla really isn't the place for this kind of discussion. Thanks.
Created attachment 108999 [details, diff] avidemux-2.3.0-twolame.patch Use >=media-sound/twolame-0.3.6 rather than it's own internal toolame lib. Patch for the ebuild is coming. Tested by opening an avi, and saving the audio stream into mp2 using TWOLAME. Seems to work fine. Hope that help. So, you want to do it with all the internal libs (not only ffmpeg) ? Actually, I see parts from media-libs/libmpeg2, media-video/mjpegtools, and from libass (http://sourceforge.net/projects/libass). Someone can list all the targets ? Thanks.
Created attachment 109000 [details, diff] avidemux-2.3.0.ebuild.patch Patch for the current ebuild. The patch for twolame must be applied against current ones (after avidemux-2.3.0-configure.patch).
Oh yeah, thank you very much for the patch Fabrice. I just commited it, with some minor changes. Some comments about it : - your configure.in changes would have been much simpler by using PKG_CHECK_MODULES from the autotools - iirc C standards state that system .h files should be included with <toto.h> rather than "toto.h". This is only cosmetics, I changed that. - you added $(TWOLAME_LIBS) to LDFLAGS, this is semantically wrong although it will work most of the times, it will fail if you use as-needed, I moved that part to LDADD. See http://www.gentoo.org/proj/en/qa/asneeded.xml for details. Could you please send that patch upstream also ? They'll probably want a configure switch to build internal or external twolame, but if it's not merged this work will have to be redone when 2.4 will be out. From 2.4 svn, I can see some internal libs : ffmpeg of course a52dec libass libmad libmpeg2 mjpegtools they've been moved to a separate directory in 2.4, it's easier to check there imho.
Old versions removed from the tree
Created attachment 109030 [details, diff] avidemux-2.3.0-twolame.patch (new) (In reply to comment #32) > Some comments about it : > - your configure.in changes would have been much simpler by using > PKG_CHECK_MODULES from the autotools > - iirc C standards state that system .h files should be included with <toto.h> > rather than "toto.h". This is only cosmetics, I changed that. > - you added $(TWOLAME_LIBS) to LDFLAGS, this is semantically wrong although it > will work most of the times, it will fail if you use as-needed, I moved that > part to LDADD. See http://www.gentoo.org/proj/en/qa/asneeded.xml for details. Ok, thanks. Here is a new patch (you can delete the oldest), using PKG_CHECK_MODULES, and which fix the external/internal switch. Seems to work fine with both choices. I will commit it to upstream later. This produce the following output at ./configure time : ./configure --with-extern-twolame -------------------------------- checking for TWOLAME... yes checking which twolame support... external [...] GTK+ version : 2.10.9 TwoLAME support : external TwoLAME version : 0.3.8 -------------------------------- ./configure --without-extern-twolame -------------------------------- checking which twolame support... builtin [...] GTK+ version : 2.10.9 TwoLAME support : builtin TwoLAME version : 0.3.6 --------------------------------
Final patch sent to upstream. http://developer.berlios.de/patch/?func=detailpatch&patch_id=1870&group_id=1402 Not exactly the same as the previous one ( attachment (id=109030) ), I fixed two or three minor problems. You will not see any difference if you decide in the ebuild to force the --with-extern-twolame option.
Thanks Fabrice, patch updated with some minor changes : - builtin variable assignments moved to an else statement - removed lines from configure.in as they are set by PKG_CHECK_MODULES : TWOLAME_CFLAGS=`$PKG_CONFIG twolame --cflags` TWOLAME_LIBS=`$PKG_CONFIG twolame --libs` I really hope this will be merged upstream.
Not to rant. But can someone please explain me why my favorite distro keeps removing stuff that is readily available in other distributions? I never had one problem with avidemux and hardmasking / removing seems just silly to me.I mean look at the list: xmms Styleclock (works perfect but gets thrown out of portage nevertheless) Netpanzer (just got fixed after about a year of hardmasking) Now it's avidemux What I don't understand is that these packages are readily available in any other distro. Can some please explain to me why Gentoo is different?
Additional info from the avidemux website: Gentoo Portage only contains very old version of avidemux and does not provide an easy way to build multithreaded spidermonkey. Please use Dooobedoobedo svn ebuild or Berkano's overlay http://www.doobedoobedo.f2s.com/avidemux-svn.tar.bz2 http://berkano.net/svn/berkano-overlay/media-video/avidemux/
Those informations are outdated, we've been having threadsafe spidermonkey for months now and avidemux 2.3 is the latest version available. I think the masking reason explains everything and in my opinion any arguing about it without sending patches or being a dev that wants to maintain it is void.
Created attachment 110207 [details] config.log from emerge error CPU type : x86_64 ADM64 checking for Altivec ... no cpu done Generating prefs if needed...(srcdir: <.> pwd:</var/tmp/portage/media-video/avidemux-2.3.0/work/avidemux_2.3.0>) Regeneration preferences definitions configure: error: conditional "HAVE_FREETYPE" was never defined. Usually this means the macro was only invoked conditionally. !!! Please attach the following file when filing a report to bugs.gentoo.org: !!! /var/tmp/portage/media-video/avidemux-2.3.0/work/avidemux_2.3.0/config.log !!! ERROR: media-video/avidemux-2.3.0 failed. =============================================================================== Above is an extract from emerge avidemux - below is emerge --info emerge --info Portage 2.1.2-r9 (default-linux/amd64/2006.1, gcc-4.1.2, glibc-2.5-r0, 2.6.17-gentoo-r4 x86_64) ================================================================= System uname: 2.6.17-gentoo-r4 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ Gentoo Base System release 1.12.9 Timestamp of tree: Wed, 14 Feb 2007 14:58:01 +0000 dev-java/java-config: 1.3.7, 2.0.31-r3 dev-lang/python: 2.3.6, 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.20 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=athlon64 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/NX/etc /usr/NX/home /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=athlon64 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks fixpackages metadata-transfer parallel-fetch 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="X a52 aac acl acpi alsa amd64 bash-completion berkdb bitmap-fonts cairo cdr cli cracklib crypt cups dbus dlloader dmi dri dts dv dvd dvdr dvdread encode esd exif fam ffmpeg fortran gdbm gif gphoto2 gstreamer gtk gtk2 hal iconv ieee1394 imagemagick ipv6 isdnlog jpeg kde libg++ lirc mad matroska midi mime mp3 mpeg musicbrainz mysql mythtv ncurses nls nptl nptlonly nvidia ogg oggvorbis openal opengl oss pam pcre pdf perl png postgres ppds pppd python qt qt3 qt3support qt4 quicktime readline reflection sdl session spell spl sqlite ssl subversion tcpd tetex theora threads tiff transcode truetype-fonts type1-fonts ukcid unicode v4l vcd vorbis x264 xine xml xorg xosd xv xvid xvmc zlib" ALSA_CARDS="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" 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 nv" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Hello, while compiling along on my merry way I saw a few lines like: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -I.. -DHAVE_AV_CONFIG_H -DHAVE_MMX -O3 -Iamr_float -I../avidemux/ADM_lavutil -I../ADM_lavutil -I/usr/include/malloc -I/usr/include/libxml2 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -march=k8 -O2 -pipe -O2 -falign-loops=16 -c vc1dsp.c Since my CFLAGS are quite sane I don't know where that -O3 came from. /etc/make.conf: CFLAGS="-march=k8 -O2 -pipe" Next... x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -I.. -DHAVE_AV_CONFIG_H -DHAVE_MMX -O3 -Iamr_float -I../avidemux/ADM_lavutil -I../ADM_lavutil -I/usr/include/malloc -I/usr/include/libxml2 -I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -march=k8 -O2 -pipe -O2 -falign-loops=16 -c -o snowdsp_mmx.o `test -f 'i386/snowdsp_mmx.c' || echo './'`i386/snowdsp_mmx.c Now I haven't really investigated this much further but I'm on x86-64 and: `test -f 'i386/snowdsp_mmx.c' is just a bit disconcerting. As do these: i386/snowdsp_mmx.c:28: warning: cast from pointer to integer of different size lls.c:54: warning: initialization from incompatible pointer type swscale_template.c:3062: warning: assignment makes integer from pointer without a cast swscale_template.c:3070: warning: cast from pointer to integer of different size I did see that this at least has the ~amd64 keyword (even though it is p.masked) but I have some reservations about its 64bit robustness.
> i386/snowdsp_mmx.c:28: warning: cast from pointer to integer of different size > lls.c:54: warning: initialization from incompatible pointer type > swscale_template.c:3062: warning: assignment makes integer from pointer without > a cast > swscale_template.c:3070: warning: cast from pointer to integer of different > size > > I did see that this at least has the ~amd64 keyword (even though it is > p.masked) but I have some reservations about its 64bit robustness. Yet another reason to not unmask it until it can use an external ffmpeg version. snowdsp_mmx.c and swscale are part of ffmpeg included in avidemux, which is obviously unmaintained and will never be (or will be updated in next avidemux release).
Created attachment 113874 [details] 2.4 Preview 1 This is just an ugly hack of the 2.3 ebuild to 2.4 preview 1. It seems to compile and work, but I haven't got the qt interface working/compiling (no idea why - possibly just a missing option to configure) Also the executable is now avidemux_gtk for the gtk gui version. Cheers, Alan.
(In reply to comment #43) > Created an attachment (id=113874) [edit] > 2.4 Preview 1 > > This is just an ugly hack of the 2.3 ebuild to 2.4 preview 1. > > It seems to compile and work, but I haven't got the qt interface > working/compiling (no idea why - possibly just a missing option to configure) > > Also the executable is now avidemux_gtk for the gtk gui version. > > Cheers, > > Alan. > emerge --info Portage 2.1.2.3 (default-linux/amd64/2006.1/desktop, gcc-4.1.2, glibc-2.5-r1, 2.6.20-gentoo-r4 x86_64) ================================================================= System uname: 2.6.20-gentoo-r4 x86_64 Dual-Core AMD Opteron(tm) Processor 1212 Gentoo Base System release 1.12.10 Timestamp of tree: Sun, 15 Apr 2007 11:00:01 +0000 dev-java/java-config: 1.3.7, 2.0.31-r5 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.16 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.20-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=opteron -mtune=opteron -O2 -pipe -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/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo" CXXFLAGS="-march=opteron -mtune=opteron -O2 -pipe -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks fix-packages metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="ftp://sunsite.informatik.rwth-aachen.de/pub/Linux/gentoo http://ftp.gentoo.skynet.be/pub/gentoo/" LANG="de_DE" LINGUAS="de en_US" MAKEOPTS="-j4" 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 --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/sunrise /usr/local/xeffects/trunk /usr/local/xeffects/experimental /usr/local/gnome-experimental" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X Xgl a52 aac acpi alsa amd64 bash-completion berkdb beryl bitmap-fonts bzip2 cairo cdr chroot cli cracklib crypt cups curl dbus directfb dri drscheme dts dvd dvdr dvdread eds emboss encode expat fam ffmpeg firefox flac fortran ftp gaim gdbm gif gimpprint gnome gnutls gphoto2 gpm gstreamer gtk gtk2 hal iconv imagemagick ipv6 isdnlog java jpeg jpeg2k libg++ mad midi mikmod mjpeg mp3 mp4 mpeg nautilus ncurses nfs nls nptl nptlonly nsplugin ntfs ogg opengl openssl pam pcre pdf perl pic png ppds pppd print profile python quicktime rdesktop readline reflection samba screen sdl session sockets socks5 source speex spell spl ssl tcl tcltk tcpd themes tiff tk truetype truetype-fonts type1-fonts unicode usb vorbis wxwindows xgl xml xorg xprint xv xvid zlib" ALSA_CARDS="intel8x0" 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" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en_US" USERLAND="GNU" VIDEO_CARDS="vesa vga nvidia nv" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS avidemux-2.4 pre1 doen't compile for me. cs.po:1175: end-of-line within string cs.po:1174: missing `msgstr' section cs.po:3301: end-of-file within string cs.po:3094: missing `msgstr' section /usr/bin/msgmerge: found 4 fatal errors make[3]: *** [cs.po] Error 1 make[3]: *** Waiting for unfinished jobs.... ............................................rm -f cs.gmo && /usr/bin/gmsgfmt -c --statistics -o cs.gmo cs.po ........... done. .........................................................................................................................rm -f ru.gmo && /usr/bin/gmsgfmt -c --statistics -o ru.gmo ru.po rm -f es.gmo && /usr/bin/gmsgfmt -c --statistics -o es.gmo es.po 1224 translated messages, 184 untranslated messages.. ................... done. 89 translated messages, 193 untranslated messages. 16 translated messages, 185 fuzzy translations, 1207 untranslated messages. make[3]: Leaving directory `/var/tmp/portage/media-video/avidemux-2.4-r1/work/avidemux_2.4_preview1/po' make[2]: *** [stamp-po] Error 2 make[2]: Leaving directory `/var/tmp/portage/media-video/avidemux-2.4-r1/work/avidemux_2.4_preview1/po' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/media-video/avidemux-2.4-r1/work/avidemux_2.4_preview1' make: *** [all] Error 2 !!! ERROR: media-video/avidemux-2.4-r1 failed. Call stack: ebuild.sh, line 1614: Called dyn_compile ebuild.sh, line 971: Called qa_call 'src_compile' ebuild.sh, line 44: Called src_compile avidemux-2.4-r1.ebuild, line 109: Called die full log at http://rafb.net/p/NC0qEZ52.html
seems to be working now. i justes merged qt4 and now it works. even if the configure says qt4 no
An ebuild for 2.4.0_pre2 is in berkano overlay (as well as a 2.4 svn branch ebuild): http://svn.liveforge.org/berkano/trunk/media-video/avidemux/ I know it's not the way the devs here want to see it, but it works, which is what is important to most end-users.
In reply to comment #46 : That ebuild doesn't respect any USE flag, is really awful, other than this using cmake you hide a lot of warnings to the users. From Berkano svn ebuild (24000) you can get something which respects use flags and shows wanings.
http://svn.liveforge.org/berkano/trunk/media-video/avidemux/avidemux-2.4.0_pre2-r1.ebuild is done the "traditional" way. The problem is, Avidemux is switching to cmake, so future versions will need to be built that way.
*** Bug 190566 has been marked as a duplicate of this bug. ***
Created attachment 129678 [details] avidemux-2.4_pre2.ebuild ebuild for avidemux 2.4 preview2 some useflags don't yet work as expected because configure doesn't offer proper --with/--without or --enable/--disable options.
I have encountered a problem with the latest avidemux-2.4_pre2.ebuild: I get blocked packages: media-libs/libdca blocks media-libs/libdts This is because I have another package installed that requires libdts. libdts and libdca are mutually exclusive as far as I know and packages that needs dts support should requirer either one. I found the solution here: http://forums.gentoo.org/viewtopic-t-585719.html I replaced one line in the avidemux-2.4_pre2.ebuild: original line: dts? ( media-libs/libdca ) replaced by: dts? ( || ( media-libs/libdca media-libs/libdts ) ) Any comments?
I am sorry, I was too fast. I was doing this change before a big emerge -auvDN world , so I finally encountered this error now: checking for dts_internal.h... no configure: WARNING: dts.h is there but I also need dts_internal.h to compile libdca/libdts. Please copy dts_internal.h where dts.h is configure: error: libdca support requested but not found !!! Please attach the following file when filing a report to bugs.gentoo.org: !!! /var/tmp/portage/media-video/avidemux-2.4_pre2/work/avidemux_2.4_preview2/config.log * * ERROR: media-video/avidemux-2.4_pre2 failed. * Call stack: * ebuild.sh, line 1654: Called dyn_compile * ebuild.sh, line 990: Called qa_call 'src_compile' * ebuild.sh, line 44: Called src_compile * avidemux-2.4_pre2.ebuild, line 94: Called econf '--with-libdca' '--without-aften' '--with-lame' '--with-vorbis' '--with-faac' '--with-faad2' '--with-oss' '--without-esd' '--without-arts' '--with-libsdl' '--enable-nls' '--with-freetype2' '--without-fontconfig' '--disable-altivec' '--with-extern-twolame' '--with-newfaad' * ebuild.sh, line 591: Called die * * econf failed * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/media-video:avidemux-2.4_pre2:20071009-130110.log'. * This ebuild is from an overlay: '/usr/local/portage/' * * Messages for package media-video/avidemux-2.4_pre2: * * ERROR: media-video/avidemux-2.4_pre2 failed. * Call stack: * ebuild.sh, line 1654: Called dyn_compile * ebuild.sh, line 990: Called qa_call 'src_compile' * ebuild.sh, line 44: Called src_compile * avidemux-2.4_pre2.ebuild, line 94: Called econf '--with-libdca' '--without-aften' '--with-lame' '--with-vorbis' '--with-faac' '--with-faad2' '--with-oss' '--without-esd' '--without-arts' '--with-libsdl' '--enable-nls' '--with-freetype2' '--without-fontconfig' '--disable-altivec' '--with-extern-twolame' '--with-newfaad' * ebuild.sh, line 591: Called die * * econf failed * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/media-video:avidemux-2.4_pre2:20071009-130110.log'. * This ebuild is from an overlay: '/usr/local/portage/' * So it seems I cannot use libdts. Does libdca provide "dts_internal.h" ? I currently "solved" the issue by adding the use flag -dts to avidemux. I think I may not need it for now.
_pre2 is looking for libdca/dts 0.0.2 which is using -ldts to link and dts_ symbols which have been replaced by dca_ in libdca 0.0.5. so it cannot work without patching configure and sources. it might have been fixed in upstream trunk.. _pre2 ain't a good release, or release at all.
Soooo... is this bug actually going anywhere?
Now we have avidemux 2.4 Preview 3, aka r3688, aka RC1. What about it?
Ebuild for preview3 in berkano overlay: http://svn.liveforge.org/berkano/trunk/media-video/avidemux/avidemux-2.4.0_pre3.ebuild
Status update.. - avidemux-2.3.0 is still in tree, masked and this bug report is for it. - avidemux-2.4_pre3 is now in tree, unmasked, replacing 2.3.0 I suggest we wait for an while.. and if 2.4_pre3 turns out to be working good enough for most people, we punt 2.3.0 and close this. Sounds about right?
2.3.0 is gone.
