If masking libjpeg releases newer than jpeg-6, many packages just fail to emerge. Reproducible: Always Steps to Reproduce: 1. Add '>=media-libs/jpeg-7' to /etc/portage/package.mask' 2. Try to emerge gimp Actual Results: Calculating dependencies... done! !!! All ebuilds that could satisfy ">=media-libs/jpeg-6b-r2:0" have been masked. !!! One of the following masked packages is required to complete your request: - media-libs/jpeg-8b (masked by: package.mask) - media-libs/jpeg-8a (masked by: package.mask) (dependency required by "media-gfx/gimp-2.6.8" [ebuild]) (dependency required by "gimp" [argument]) Expected Results: the package should emerge cleanly The releases newer than libjpeg6b have unclear future, and might be superseded by libjpeg-turbo project: http://libjpeg-turbo.virtualgl.org/ There is a long discussion about the upgrade of libjpeg for fedora14. And libjpeg-turbo is being considered as a better alternative to current IJG releases: http://lists.fedoraproject.org/pipermail/devel/2010-May/136556.html A relevant comment from the original libjpeg maintainer: http://lists.fedoraproject.org/pipermail/devel/2010-May/136976.html The new features which have been introduced into libjpeg7/8 are not necessarily a good thing and are criticized: http://hardwarebug.org/2010/02/01/ijg-swings-again-and-misses/ The bottom line: it would be very nice to keep an option to use libjpeg-6 in gentoo until the upstream disputes get resolved.
nope, only jpeg-8 or above is supported, the rest is only compat ebuilds for binary-only software
jpeg-turbo won't be available in gentoo before fedora & jpeg-turbo upstream catches up with API/ABI, here: http://sourceforge.net/tracker/?group_id=303195&atid=1278161
quoting jpeg-turbo upstream: "We are currently stabilizing the code for 1.0.0 so that the Fedora Project can start using it in Fedora 14, but as soon as 1.0.0 is released, jpeg v8 support is the first feature on tap for 1.1."
(In reply to comment #2) > jpeg-turbo won't be available in gentoo before fedora & jpeg-turbo upstream > catches up with API/ABI, here: > > http://sourceforge.net/tracker/?group_id=303195&atid=1278161 There is an opinion that the guy who has taken over the IJG branch of libjpeg should not have broken ABI unnecessarily in the first place. Would you be happy if he keeps breaking ABI and everyone would need to catch up? But from the technical point of view, what is the problem for gentoo to deal with jpeg slots properly?
(In reply to comment #3) > quoting jpeg-turbo upstream: > > "We are currently stabilizing the code for 1.0.0 so that the Fedora Project > can start using it in Fedora 14, but as soon as 1.0.0 is released, jpeg v8 > support is the first feature on tap for 1.1." Please read another comment there: "After further investigation, I have some concerns about moving to the jpeg-8 code base in general." Does gentoo have a backup plan in the case if IJG releases get deprecated?
graphics team is not intrested -> uses obsolete API -> moving to maintainer-wanted for new packages
*** Bug 327565 has been marked as a duplicate of this bug. ***
libjpeg-turbo-1.0.0 breaks xulrunner's compilation: https://sourceforge.net/tracker/?func=detail&atid=1278158&aid=3033842&group_id=303195
So... all this boils down to 2 issues now: - **important** Comment #8, xulrunner or libjpeg-turbo to be fixed so they don't conflict. - **minor** Comment #2, really, it would be nice if it was possible to get jpeg-8b version of libjpeg-turbo.
Thanks for adding ebuild to portage, so that we have something to test. I think this problem is quite important too: http://sourceforge.net/tracker/?func=detail&aid=3023672&group_id=303195&atid=1278158
I've successfully moved all my gentoo system to libjpeg-turbo. The only 2 problems is xulrunner and digikam which seems uses jpeg8 features.
(In reply to comment #9) > So... all this boils down to 2 issues now: > > - **important** Comment #8, xulrunner or libjpeg-turbo to be fixed so they > don't conflict. I have submitted a patch here: https://sourceforge.net/tracker/index.php?func=detail&aid=3049808&group_id=303195&atid=1278160
(In reply to comment #11) > and digikam which seems uses jpeg8 features. Could you provide some step by step instructions about how to reproduce problems with digikam and how it manifests itself? It builds fine for me (after changing dependencies to 'virtual/jpeg' for a bunch of kde packages). But I could not test digikam after building, because I don't known how to cleanly run a full kde environment in chroot. And I don't want to mess up my primary system by upgrading it to ~amd64 stuff.
(In reply to comment #13) > (In reply to comment #11) > > and digikam which seems uses jpeg8 features. > > Could you provide some step by step instructions about how to reproduce > problems with digikam and how it manifests itself? digikam build fine now. I forgot remove jpeg-8 patch from ebuild last time.
(In reply to comment #9) > So... all this boils down to 2 issues now: > > - **important** Comment #8, xulrunner or libjpeg-turbo to be fixed so they > don't conflict. Also FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=584652 https://bugzilla.mozilla.org/show_bug.cgi?id=573948 Looks like Mozilla is switching to libjpeg-turbo. And the distros which don't privide libpeg-turbo package will have to use internal copy of libjpeg-turbo bundled with Mozilla sources instead of the system library.
libjpeg-turbo-1.0.1 has been released, it works fine with xulrunner now.
I did some tests with libjpeg-turbo 1.0.1 both on my desktop (Gentoo) and on a netbook (Ubuntu 10.04). These are the results: Athlon 4850e (dual core 64bit cpu, 32 bit userspace) working at 2.5 Ghz, converting a not-so-large RGB PPM image (7200x4500) to and from JPEG (average of 5 runs): time convert image.ppm image.jpg libjpeg-classic real 2.709s user 2.364s sys 0.318s libjpeg-turbo real 1.646s user 1.301s sys 0.317s time convert image.jpg image.ppm libjpeg-classic real 2.130s user 1.703s sys 0.359s libjpeg-turbo real 1.292s user 0.872s sys 0.356s Acer Aspire One 532h netbook with a Atom N450 cpu (64 bit userspace) working at 1.67 Ghz, the same test gives: time convert image.ppm image.jpg libjpeg-classic real 5.763s user 5.996s sys 0.770s libjpeg-turbo real 2.612s user 2.900s sys 0.720s time convert image.jpg image.ppm libjpeg-classic real 4.588s user 3.816s sys 0.858s libjpeg-turbo real 2.602s user 1.692s sys 0.868s Occasionally I use the netbook to stream video from the integrated webcam to another pc with this gstreamer pipeline: gst-launch-0.10 v4l2src ! video/x-raw-yuv,width=640,height=480 ! ffmpegcolorspace ! jpegenc ! multipartmux ! udpsink host=192.168.1.2 port=5000 With the frequency forced to 1GHz the cpu usage is: libjpeg-classic 37-38% libjpeg-turbo 10-11% With the frequency forced to 1.67Ghz the cpu usage is: libjpeg-classic 22-23% libjpeg-turbo 6-7% When the default ondemand governor is used, with libjpeg-turbo the frequency stays mostly at 1 Ghz, while with libjpeg-classic it divides almost equally between 1 Ghz and 1.67Ghz, with the obvious consequences in terms of battery life. I think that in terms of benefits for the users it would be advisable to drop jpeg-8 and switch to libjpeg-turbo. Nobody is really using the new v8 API anyway.
Samuli contact me on irc when you have time today please, wanna discuss a few things with you.
Many ebuilds depend on media-libs/jpeg instead of virtual/jpeg. Because of it, I get many "blocks" when I try to emerge libjpeg-turbo. I think I should fill bugs about this issue. Is modifying media-libs/jpeg to virtual/jpeg correct ?
Just adding a note that latest libjpeg-turbo svn has support for jpeg 7 and 8 abis (as well as 6.2).
http://git.overlays.gentoo.org/gitweb/?p=dev/anarchy.git;a=commitdiff;h=860b92252fed3280ac6ec92ccca9cde9caf92d3e snapshot with --jpeg8 enabled by default :)
adding another note that i just read not all "features" in ijg's jpeg8 are actually supported, some are just silently ignored. +Not supported: + +-- libjpeg: DCT scaling in compressor + cinfo.scale_num and cinfo.scale_denom are silently ignored. + +-- libjpeg: IDCT scaling extensions in decompressor + libjpeg-turbo still supports IDCT scaling with scaling factors of 1/2, 1/4, + and 1/8 (same as libjpeg v6b.) + +-- libjpeg: Fancy downsampling in compressor + cinfo.do_fancy_downsampling is silently ignored. + +-- libjpeg: Arithmetic coding/decoding + Not supported due to patent concerns. + +-- jpegtran: Scaling + Seems to depend on the DCT scaling feature, which isn't supported.
1.0.90 snapshot is in tree, this always enabled jpeg-8 support.
In case anyone is interested, Fedora 14 came out with libjpeg-turbo: http://lists.fedoraproject.org/pipermail/announce/2010-November/002875.html
I have installed libjpeg-turbo-1.0.90 as follow: - unmerge jpeg-6b-r9 and jpeg-8b - keyword media-libs/libjpeg-turbo-1.0.90 with echo "media-libs/libjpeg-turbo-1.0.90 **" >> /etc/portage/package.keywords - put jpeg-6b-r9 and jpeg-8b as privided echo "media-libs/jpeg-6b-r9" >> /etc/portage/profile/package.provided echo "media-libs/jpeg-8b" >> /etc/portage/profile/package.provided - emerge media-libs/libjpeg-turbo-1.0.90 Everything for me. libjpeg-turbo should provide virtual-jpeg, and all ebuild should depend on virtual-jpeg (which is not the case ATM) to give users the choice.
Yup, it's matter of converting http://tinderbox.dev.gentoo.org/misc/rindex/media-libs/jpeg to http://tinderbox.dev.gentoo.org/misc/rindex/virtual/jpeg but there's no official upstream release yet with jpeg8 support, the 1.0.90 is a snapshot, so I haven't kept any hurry on converting the tree yet... anyway, once it's done, libjpeg-turbo will get KEYWORDS="~amd64 ~x86", not before
(In reply to comment #26) > Yup, it's matter of converting > > http://tinderbox.dev.gentoo.org/misc/rindex/media-libs/jpeg > > to > > http://tinderbox.dev.gentoo.org/misc/rindex/virtual/jpeg > > but there's no official upstream release yet with jpeg8 support, the 1.0.90 is > a snapshot, so I haven't kept any hurry on converting the tree yet... > > anyway, once it's done, libjpeg-turbo will get KEYWORDS="~amd64 ~x86", not > before > Yeap, I know all that I am not *pushing* things, I was just voicing my opinion. Hopefully 1.1 will be there soon.
(In reply to comment #25) > Everything for me. Hmm I spoke too soon, media-libs/libjpeg-turbo-1.0.90 only installs libjpeg.so.8.0.2, so apps depend on jpeg6 are broken. media-libs/libjpeg-turbo-1.0.1 only provides libjpeg.so.62.0.0. Is there a way to let media-libs/libjpeg-turbo-1.0.90 install both libjpeg.so.8.0.2 and libjpeg.so.62.0.0?
(In reply to comment #28) > (In reply to comment #25) > > > Everything for me. > > Hmm I spoke too soon, media-libs/libjpeg-turbo-1.0.90 only installs > libjpeg.so.8.0.2, so apps depend on jpeg6 are broken. > media-libs/libjpeg-turbo-1.0.1 only provides libjpeg.so.62.0.0. > > Is there a way to let media-libs/libjpeg-turbo-1.0.90 install both > libjpeg.so.8.0.2 and libjpeg.so.62.0.0? > it's possible but won't be done, use the original slotted jpeg for binary-only packages: emerge -av1 media-libs/jpeg:62
(In reply to comment #25) > I have installed libjpeg-turbo-1.0.90 as follow: > > - unmerge jpeg-6b-r9 and jpeg-8b > - keyword media-libs/libjpeg-turbo-1.0.90 with > echo "media-libs/libjpeg-turbo-1.0.90 **" >> /etc/portage/package.keywords > - put jpeg-6b-r9 and jpeg-8b as privided > echo "media-libs/jpeg-6b-r9" >> /etc/portage/profile/package.provided > echo "media-libs/jpeg-8b" >> /etc/portage/profile/package.provided > - emerge media-libs/libjpeg-turbo-1.0.90 > > Everything for me. libjpeg-turbo should provide virtual-jpeg, and all ebuild > should depend on virtual-jpeg (which is not the case ATM) to give users the > choice. > I have started to move the tree from media-libs/jpeg to virtual/jpeg, if you have a package that still has incorrect dep that you know will work fine please open a bug.
*** Bug 344583 has been marked as a duplicate of this bug. ***
For the record: Don't do what bug 344689 does. The only stable provider for virtual/jpeg is media-libs/jpeg, there is no need for revbumps, it's only pointless recompiles for stable users.
(In reply to comment #32) > For the record: > Don't do what bug 344689 does. > The only stable provider for virtual/jpeg is media-libs/jpeg, there is no need > for revbumps, it's only pointless recompiles for stable users. > And pointless testing (there is nothing to test!) for arch teams. Wastes everyones time
(In reply to comment #29) > > Is there a way to let media-libs/libjpeg-turbo-1.0.90 install both > > libjpeg.so.8.0.2 and libjpeg.so.62.0.0? > > > > it's possible but won't be done, use the original slotted jpeg for binary-only > packages: > emerge -av1 media-libs/jpeg:62 May I ask why not? Can't we just have some use flags (jpeg6 or compat, whatever), that is the reason behind this?
Package is missing from SRC_URI. SRC_URI="http://dev.gentoo.org/~anarchy/dist/${P}.tar.bz2"
(In reply to comment #35) > Package is missing from SRC_URI. > > SRC_URI="http://dev.gentoo.org/~anarchy/dist/${P}.tar.bz2" > Sorry, I'm referring to version 1.0.90: SRC_URI="http://dev.gentoo.org/~anarchy/dist/libjpeg-turbo-1.0.90.tar.bz2"
(In reply to comment #36) > Sorry, I'm referring to version 1.0.90: 1.0.90 is not in portage. use -r1
I replaced system jpeg8b to libjpeg-turbo-1.90-r1. It seems to work well. The following packages installed on my system depend on media-libs/jpeg instead of virtual jpeg: app-admin/testdisk dev-games/openscenegraph dev-java/icedtea dev-libs/DirectFB dev-perl/GD dev-python/wxpython games-action/openastromenace games-arcade/bumprace games-puzzle/neverball games-rpg/freedroid games-rpg/freedroidrpg games-strategy/scorched3d media-gfx/dcraw media-gfx/fbida media-gfx/fontforge media-gfx/transfig media-plugins/gst-plugins-jpeg media-video/motion media-video/mvc net-libs/libvncserver www-plugins/gnash x11-libs/wxGTK After fixing deps to use virtual/jpeg they compile well and seems to work.
For me, using libjpeg-turbo I got build failures for media-gfx/sane-backends and media-gfx/imagemagick both complaining about missing .la files: grep: /usr/lib64/libjpeg.la: No such file or directory /bin/sed: can't read /usr/lib64/libjpeg.la: No such file or directory libtool: link: `/usr/lib64/libjpeg.la' is not a valid libtool archive make[2]: *** [libsane.la] Fehler 1 should I report a bug for each and let this bug depend on them?
(In reply to comment #39) > For me, using libjpeg-turbo I got build failures for media-gfx/sane-backends > and media-gfx/imagemagick both complaining about missing .la files: > grep: /usr/lib64/libjpeg.la: No such file or directory > /bin/sed: can't read /usr/lib64/libjpeg.la: No such file or directory > libtool: link: `/usr/lib64/libjpeg.la' is not a valid libtool archive > make[2]: *** [libsane.la] Fehler 1 > > should I report a bug for each and let this bug depend on them? > It's not a bug. The removal of libjpeg.la is intentional to prevent overlinking of packages. You need to run 'lafilefixer --justfixit' after switching system over from media-libs/jpeg one.
(In reply to comment #40) > You need to run 'lafilefixer --justfixit' after switching system over from > media-libs/jpeg one. > samuli, thanks for the hint! it works now---
(In reply to comment #38) Most of these packages aren't fixed yet. I'll create appropriate bug reports and will depend them on this bug as well.
jpeg turbo appears to be good and a drop in replacement to the jpeg libraries.
You might also make this dependent on bugs 349945, 349947
Also Firefox is planned to release it's next release compiled against this package.
(In reply to comment #45) > Also Firefox is planned to release it's next release compiled against this > package. > Incorrect, we will not replace jpeg-6b in firefox until we branch. 4.0 will still use the much depreciated 6b.
(In reply to comment #46) > Incorrect, we will not replace jpeg-6b in firefox until we branch. 4.0 will > still use the much depreciated 6b. It surely depends on Mozilla's own schedule, and the plans related to libjpeg-turbo may change. But right now it looks like they will try to switch to libjpeg-turbo in firefox 4.1: https://bugzilla.mozilla.org/show_bug.cgi?id=573948#c139
(In reply to comment #47) > (In reply to comment #46) > > Incorrect, we will not replace jpeg-6b in firefox until we branch. 4.0 will > > still use the much depreciated 6b. > > It surely depends on Mozilla's own schedule, and the plans related to > libjpeg-turbo may change. But right now it looks like they will try to switch > to libjpeg-turbo in firefox 4.1: > https://bugzilla.mozilla.org/show_bug.cgi?id=573948#c139 > Okay as I work closely with upstream I am well aware of what the schedule is and when it will happen. When we branch that will be the start of the 4.1 development cycle. It is expected to be landed at that time, this is all irrelevant to gentoo tho as we use system jpeg no matter what, so it will be up to the user to decide if they want to use media-libs/jpeg or media-libs/libjpeg-turbo. With that said there is no need for any further discussion on the mozilla products.
(In reply to comment #44) > You might also make this dependent on bugs 349945, 349947 Since you opened these bugs, please mark them as blokers of this bug. (In reply to comment #45) > Also Firefox is planned to release it's next release compiled against this > package. Current firefox compiles and works without any problems with libjpeg-turbo.
(In reply to comment #48) > this is all irrelevant to gentoo tho as we use system jpeg no matter what, so > it will be up to the user to decide if they want to use media-libs/jpeg or > media-libs/libjpeg-turbo. If firefox also starts using libjpeg-turbo JCS_EXTENSIONS extension in the future and drops local color conversion hacks (which makes a lot of sense), then using media-libs/jpeg will be difficult for the users. But it's indeed irrelevant because gentoo is likely to get a good libjpeg-turbo support by that time. (In reply to comment #49) > Current firefox compiles and works without any problems with libjpeg-turbo. Yes, this issue has been addressed some time ago. See comment 12
The static-libs USE flag is missing from virtual/jpeg ...
Hand-tweaked ebuild to work with new upstream (1.1.0) full release, seems to work fine on ~x86 system. There aren't any directories named "debian" or "extra" in the new upstream. Hope those weren't important. /usr/lib/libturbojpeg.la and /usr/lib/libjpeg.la keep getting installed with -static-libs. Removing them and running "lafilefixer --justfixit 1> /dev/null" plus "revdep-rebuild -p" reveals no obvious problems.
libjpeg-turbo-1.1.0 in tree, and whole gentoo-x86 converted to use virtual/jpeg (except for binary-only pkgs which need to stay using media-libs/jpeg:62 because you can't have 2 versions of libjpegturbo.so in the same system ...)
(In reply to comment #53) > libjpeg-turbo-1.1.0 in tree, and whole gentoo-x86 converted to use virtual/jpeg what about media-gfx/splashutils? still depends on >=media-libs/jpeg-6b:0....
(In reply to comment #54) > what about media-gfx/splashutils? still depends on >=media-libs/jpeg-6b:0.... Then you should open a bug for this package and add it to this tracker, the same I did for packages I spotted on my systems.
(In reply to comment #55) > Then you should open a bug for this package and add it to this tracker, the > same I did for packages I spotted on my systems. done, bug #356939
Reopening until splashutils is fixed.