Stabilize media-video/mjpegtools-1.9.0_rc3.
*** Bug 245559 has been marked as a duplicate of this bug. ***
I request to have it stabilized, too, as mjpegtools-1.8* don't compile using gcc-4.3* I'm running amd64 and it works fine here.
I request that it not be marked stable yet as I'm experiencing problems with yuvdeinterlace in mjpegtools-1.9.0_rc3. yuvdeinterlace is fixed for me in version 1.9.0_rc4
(In reply to comment #3) > I request that it not be marked stable yet as I'm experiencing problems with > yuvdeinterlace in mjpegtools-1.9.0_rc3. yuvdeinterlace is fixed for me in > version 1.9.0_rc4 > I vote we wait for 1.9.0 release.
(In reply to comment #4) > (In reply to comment #3) > > I request that it not be marked stable yet as I'm experiencing problems with > > yuvdeinterlace in mjpegtools-1.9.0_rc3. yuvdeinterlace is fixed for me in > > version 1.9.0_rc4 > > > > I vote we wait for 1.9.0 release. > beandog, I don't see any bugs on 1.9.0. Let's do it - (needed for gcc-4.3 stab) Keywords: mjpegtools-1.9.0: ~alpha ~amd64 ~ppc ~ppc64 ~sparc ~x86
this is high priority
Needed for gcc-4.3 stabilization. Good to go.
ppc64 stable
amd64/x86 stable
ppc stable
I run a headless (X-less) server that includes mjpegtools and it's trying to update from 1.8.0-r1 to 1.9.0 as a result of stabilisation. I get build errors as a result of the lack of X11: creating png2yuv (cd .libs && rm -f liblavrec.la && ln -s ../liblavrec.la liblavrec.la) /bin/sh ../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -march=prescott -O2 -pipe -fomit-frame-pointer -fno-strict-aliasing -pthread -Wall -Wunused -Wl,-O1 -o lav2wav lav2wav.o ../utils/libmjpegutils.la liblavfile.la -lm /bin/sh ../libtool --tag=CC --mode=link i686-pc-linux-gnu-gcc -march=prescott -O2 -pipe -fomit-frame-pointer -fno-strict-aliasing -pthread -Wall -Wunused -Wl,-O1 -o lav2yuv lav2yuv-lav2yuv.o lav2yuv-lav_common.o ../utils/libmjpegutils.la liblavfile.la liblavjpeg.la -lm i686-pc-linux-gnu-gcc -shared .libs/liblavplay_la-liblavplay.o .libs/liblavplay_la-audiolib.o -Wl,--rpath -Wl,/var/tmp/portage/media-video/mjpegtools-1.9.0/work/mjpegtools-1.9.0/lavtools/.libs -Wl,--rpath -Wl,/var/tmp/portage/media-video/mjpegtools-1.9.0/work/mjpegtools-1.9.0/utils/.libs -L/var/tmp/portage/media-video/mjpegtools-1.9.0/work/mjpegtools-1.9.0/utils/.libs ./.libs/liblavfile.so -L/usr/lib /usr/lib/libSDL.so -lpthread ./.libs/liblavjpeg.so ../utils/.libs/libmjpegutils.so -lX11 -lm -march=prescott -pthread -Wl,-O1 -Wl,-soname -Wl,liblavplay-1.9.so.0 -o .libs/liblavplay-1.9.so.0.0.0 /usr/lib/gcc/i686-pc-linux-gnu/4.1.2/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lX11 collect2: ld returned 1 exit status make[2]: *** [liblavplay.la] Error 1 I don't believe it used to require X11, and the RDEPEND still has X as an optional dependency based on USE flags.
Stable on alpha.
(In reply to comment #11) > I run a headless (X-less) server that includes mjpegtools and it's trying to > update from 1.8.0-r1 to 1.9.0 as a result of stabilisation. I get build errors > as a result of the lack of X11: > ... Looking into this further I've tracked it down to "lavtools/Makefile.in", which contains the following: @HAVE_V4L_TRUE@am__append_4 = ${X_LIBS} -lX11 I have V4L enabled (the server does indeed have a USB-connected camera), but the makefile wrongly assumes that means X as well. Removing that "-lX11" makes things work for me, but I'm not sure what the ramifications are for other people's USE flag combinations.
(In reply to comment #13) (In reply to comment #11) I have the same problem as these two. I have USE=-X and the ebuild correctly configures with --without-x, but the Makefile adds in -lX11 anyway. This same condition happens with both 1.9.0_rc4 and the "stable" 1.9.0, but doesn't happen with 1.9.0_rc3. I'm not sure what happened here.
spoke too soon; actually this bug does also exist in 1.9.0_rc3.
To my untrained eye it was this commit made a couple of weeks ago to the upstream source: http://mjpeg.cvs.sourceforge.net/viewvc/mjpeg/mjpeg_play/lavtools/Makefile.am?r1=1.117&r2=1.118 From their changelog: Need to add back, but conditionally, ${X_LIBS} -lX11. Can't use HAVE_X because OSX 10.5 has X but adding extra -lX11 options causes problems. Use HAVE_V4L in hopes that only linux systems will be affected. I think this is an upstream bug.
(In reply to comment #16) > I think this is an upstream bug. Could you please report it or check if the upstream repository has already a fix?
(In reply to comment #17) > Could you please report it or check if the upstream repository has already a > fix? > Done: https://sourceforge.net/mailarchive/forum.php?thread_name=499E6A37.9090209%40hickinbottom.com&forum_name=mjpeg-developer
sparc stable, closing
Hi guys, I think closing this bug is not what we want. mjpegtools HAS a bug with the current ebuild (see above, -lX11 problem). So setting this to resolved and adding the stable arch flags to the ebuild while some is posting that he has opened a bug on the upstream looks ugly. I'm sorry if I have misunderstand something. This problem still occurs in media-video/mjpegtools-1.9.0 which is current X86 stable. greez Damage
Note that I've just had an email from the mjpegtools list (following up my report in comment#18): http://sourceforge.net/mailarchive/message.php?msg_id=27446907 I've tried this version from CVS and it does build on a Gentoo without X11 installed. Either the recent commit could be bundled into a patch for 1.9.0, or else it would be picked up anyway in the next mjpegtools release and ebuild update. I'm not personally waiting for this (masking 1.9.0 works for me), but wanted to report this update here.