Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 327487 - [TRACKER] Use virtual/jpeg (for media-libs/libjpeg-turbo)
Summary: [TRACKER] Use virtual/jpeg (for media-libs/libjpeg-turbo)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: All Linux
: High enhancement with 1 vote (vote)
Assignee: Samuli Suominen (RETIRED)
URL:
Whiteboard:
Keywords: Tracker
: 327565 344583 (view as bug list)
Depends on: 344689 345157 347951 347952 347953 347954 347956 347958 347960 347961 347963 347965 347966 347967 347969 347971 347973 347975 347977 347979 347980 347982 347983 349598 356939 357421 357423
Blocks:
  Show dependency tree
 
Reported: 2010-07-08 14:21 UTC by Siarhei Siamashka
Modified: 2011-03-27 07:00 UTC (History)
28 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Siarhei Siamashka 2010-07-08 14:21:00 UTC
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.
Comment 1 Samuli Suominen (RETIRED) gentoo-dev 2010-07-08 14:23:40 UTC
nope, only jpeg-8 or above is supported, the rest is only compat ebuilds for binary-only software
Comment 2 Samuli Suominen (RETIRED) gentoo-dev 2010-07-08 14:27:31 UTC
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

Comment 3 Samuli Suominen (RETIRED) gentoo-dev 2010-07-08 14:30:37 UTC
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."
Comment 4 Siarhei Siamashka 2010-07-08 14:34:43 UTC
(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?
Comment 5 Siarhei Siamashka 2010-07-08 14:41:22 UTC
(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?
Comment 6 Samuli Suominen (RETIRED) gentoo-dev 2010-07-09 07:32:31 UTC
graphics team is not intrested -> uses obsolete API -> moving to maintainer-wanted for new packages
Comment 7 Samuli Suominen (RETIRED) gentoo-dev 2010-07-09 07:32:46 UTC
*** Bug 327565 has been marked as a duplicate of this bug. ***
Comment 8 Samuli Suominen (RETIRED) gentoo-dev 2010-07-23 23:33:55 UTC
libjpeg-turbo-1.0.0 breaks xulrunner's compilation:

https://sourceforge.net/tracker/?func=detail&atid=1278158&aid=3033842&group_id=303195
Comment 9 Samuli Suominen (RETIRED) gentoo-dev 2010-07-29 15:56:09 UTC
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.
Comment 10 Siarhei Siamashka 2010-07-30 00:33:07 UTC
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
Comment 11 Sasha Medvedev 2010-07-30 08:08:38 UTC
I've successfully moved all my  gentoo system to libjpeg-turbo. The only 2 problems is xulrunner and digikam which seems uses jpeg8 features.
Comment 12 Siarhei Siamashka 2010-08-20 23:50:01 UTC
(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
Comment 13 Siarhei Siamashka 2010-08-21 12:25:45 UTC
(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.
Comment 14 Sasha Medvedev 2010-08-21 19:51:24 UTC
(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. 
Comment 15 Siarhei Siamashka 2010-08-24 10:40:06 UTC
(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.
Comment 16 Siarhei Siamashka 2010-09-10 23:58:12 UTC
libjpeg-turbo-1.0.1 has been released, it works fine with xulrunner now.
Comment 17 Giacomo Perale 2010-09-12 10:59:11 UTC
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.
Comment 18 Jory A. Pratt gentoo-dev 2010-09-12 20:29:42 UTC
Samuli contact me on irc when you have time today please, wanna discuss a few things with you.
Comment 19 Thomas Pegeot 2010-10-11 16:54:54 UTC
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 ? 
Comment 20 Mikael Magnusson 2010-10-11 22:38:01 UTC
Just adding a note that latest libjpeg-turbo svn has support for jpeg 7 and 8 abis (as well as 6.2).
Comment 21 Jory A. Pratt gentoo-dev 2010-10-12 02:58:49 UTC
http://git.overlays.gentoo.org/gitweb/?p=dev/anarchy.git;a=commitdiff;h=860b92252fed3280ac6ec92ccca9cde9caf92d3e

snapshot with --jpeg8 enabled by default :) 
Comment 22 Mikael Magnusson 2010-10-12 04:13:29 UTC
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.                       
Comment 23 Jory A. Pratt gentoo-dev 2010-10-21 13:33:23 UTC
1.0.90 snapshot is in tree, this always enabled jpeg-8 support.
Comment 24 Alec Meyers 2010-11-02 18:42:24 UTC
In case anyone is interested, Fedora 14 came out with libjpeg-turbo:

http://lists.fedoraproject.org/pipermail/announce/2010-November/002875.html
Comment 25 Ming-Wei 2010-11-05 12:30:38 UTC
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.
Comment 26 Samuli Suominen (RETIRED) gentoo-dev 2010-11-05 12:47:56 UTC
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
Comment 27 Ming-Wei 2010-11-05 19:08:14 UTC
(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.
Comment 28 Ming-Wei 2010-11-06 09:53:15 UTC
(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?
Comment 29 Samuli Suominen (RETIRED) gentoo-dev 2010-11-06 10:03:10 UTC
(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
Comment 30 Jory A. Pratt gentoo-dev 2010-11-07 19:41:51 UTC
(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.
Comment 31 Jory A. Pratt gentoo-dev 2010-11-07 20:49:04 UTC
*** Bug 344583 has been marked as a duplicate of this bug. ***
Comment 32 Samuli Suominen (RETIRED) gentoo-dev 2010-11-08 15:50:18 UTC
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.
Comment 33 Samuli Suominen (RETIRED) gentoo-dev 2010-11-08 15:50:55 UTC
(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
Comment 34 Ming-Wei 2010-11-09 10:17:15 UTC
(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?
Comment 35 Vítor Brandão (noisebleed) 2010-11-15 17:25:59 UTC
Package is missing from SRC_URI.

SRC_URI="http://dev.gentoo.org/~anarchy/dist/${P}.tar.bz2"
Comment 36 Vítor Brandão (noisebleed) 2010-11-15 17:27:49 UTC
(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"
Comment 37 Samuli Suominen (RETIRED) gentoo-dev 2010-11-15 17:37:01 UTC
(In reply to comment #36)
> Sorry, I'm referring to version 1.0.90:

1.0.90 is not in portage. use -r1
Comment 38 Andrew Savchenko gentoo-dev 2010-11-22 00:21:06 UTC
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.
Comment 39 Martin Gysel (bearsh) 2010-12-04 10:57:07 UTC
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?
Comment 40 Samuli Suominen (RETIRED) gentoo-dev 2010-12-04 11:01:26 UTC
(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.
Comment 41 Martin Gysel (bearsh) 2010-12-04 11:23:54 UTC
(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---
Comment 42 Andrew Savchenko gentoo-dev 2010-12-06 21:54:07 UTC
(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.
Comment 43 dE 2010-12-28 11:08:40 UTC
jpeg turbo appears to be good and a drop in replacement to the jpeg libraries.
Comment 44 dE 2010-12-28 11:12:06 UTC
You might also make this dependent on bugs 349945, 349947
Comment 45 dE 2010-12-28 11:24:32 UTC
Also Firefox is planned to release it's next release compiled against this package.
Comment 46 Jory A. Pratt gentoo-dev 2010-12-28 13:17:09 UTC
(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.
Comment 47 Siarhei Siamashka 2010-12-28 13:35:05 UTC
(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
Comment 48 Jory A. Pratt gentoo-dev 2010-12-28 15:56:52 UTC
(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.
Comment 49 Andrew Savchenko gentoo-dev 2010-12-28 16:57:40 UTC
(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.
Comment 50 Siarhei Siamashka 2010-12-28 19:30:25 UTC
(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
Comment 51 Marcel Partap 2011-01-20 12:10:30 UTC
The static-libs USE flag is missing from virtual/jpeg ...
Comment 52 Rebecca Menessec 2011-02-27 08:28:07 UTC
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.
Comment 53 Samuli Suominen (RETIRED) gentoo-dev 2011-02-28 18:13:04 UTC
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 ...)
Comment 54 Martin Gysel (bearsh) 2011-02-28 20:50:30 UTC
(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....
Comment 55 Andrew Savchenko gentoo-dev 2011-03-01 06:06:25 UTC
(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.
Comment 56 Martin Gysel (bearsh) 2011-03-01 08:02:54 UTC
(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

Comment 57 Serkan Kaba (RETIRED) gentoo-dev 2011-03-13 06:48:14 UTC
Reopening until splashutils is fixed.