libjpeg.so.8 was removed from emul-linux-x86-baselibs but libs in this -baselibs package and in -gtklibs still link to it. app-emulation/emul-linux-x86-baselibs-r9 has a dep on virtual/jpeg:62[abi_x86_32(-)] but that only provides the .62 lib, not .8 ----------- *emul-linux-x86-baselibs-20131008-r9 (24 Jan 2014) 24 Jan 2014; Samuli Suominen <ssuominen@gentoo.org> +emul-linux-x86-baselibs-20131008-r9.ebuild, files/remove-native: Version without libjpeg.so.8* ----------- !!! existing preserved libs: >>> package: app-emulation/emul-linux-x86-baselibs-20131008-r9 * - /usr/lib32/libjpeg.so.8 * - /usr/lib32/libjpeg.so.8.0.2 * used by /usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-jpeg.so (app-emulation/emul-linux-x86-gtklibs-20131008-r1) * used by /usr/lib32/libImlib.so.1.9.15 (app-emulation/emul-linux-x86-gtklibs-20131008-r1) * used by /usr/lib32/libmng.so.1.0.0 (app-emulation/emul-linux-x86-baselibs-20131008-r9) Use emerge @preserved-rebuild to rebuild packages using these libraries
jpeg-8d-r1 provides the multilib .so.8, and otherwise @preserved-libs will catch the libjpeg.so.8 for now we need multilib gdk-pixbuf (bug 488998) and multilib imlib (no bug open yet?) and multilib libmng (bug 496380) for the ones you reported
I'd also really appreciate if you moved all the masked packages when bumping emul-linux. Now blockers are incorrect. Again.
Also emul-linux-x86-medialibs: !!! existing preserved libs: >>> package: app-emulation/emul-linux-x86-baselibs-20131008-r9 * - /usr/lib32/libjpeg.so.8 * - /usr/lib32/libjpeg.so.8.0.2 * used by /usr/lib32/directfb-1.4-5/interfaces/IDirectFBImageProvider/libidirectfbimageprovider_jpeg.so (app-emulation/emul-linux-x86-medialibs-20131008-r1)
Also affected: app-emulation/emul-linux-x86-gstplugins-20131008 app-emulation/emul-linux-x86-sdl-20131008-r1 * Packages containing binaries and libraries using /usr/lib32/libjpeg.so.8 * will be emerged. ... * /usr/lib32/gstreamer-0.10/libgstjpeg.so -> app-emulation/emul-linux-x86-gstplugins * /usr/lib32/libSDL_image-1.2.so.0.8.4 -> app-emulation/emul-linux-x86-sdl
*** Bug 499426 has been marked as a duplicate of this bug. ***
libmng-2.0.2 raised to SONAME to libmng.so.2 from libmng.so.1 which causes futher issues emul-linux-x86-baselibs -r11 now installs libmng.so.1* but not libmng.so, but the remaining libmng.so.1* are broken wrt this bug (still linking to libjpeg.so.8) so, we'll just delete libmng.so.1* once it's clear they are not required by anything anymore
(In reply to Michał Górny from comment #2) > I'd also really appreciate if you moved all the masked packages when bumping > emul-linux. Now blockers are incorrect. Again. Sorry, I'm not following. Did I miss a step?
(In reply to Samuli Suominen from comment #7) > (In reply to Michał Górny from comment #2) > > I'd also really appreciate if you moved all the masked packages when bumping > > emul-linux. Now blockers are incorrect. Again. > > Sorry, I'm not following. Did I miss a step? # Lars Wendler <polynomial-c@gentoo.org> # Multilib ready ebuild (bug #496218). Collides with emul-linux-x86-baselibs =sys-devel/gettext-0.18.3.2 =virtual/libintl-0-r1 You should have added those to remove-native and unmasked them as well.
(In reply to Michał Górny from comment #8) > (In reply to Samuli Suominen from comment #7) > > (In reply to Michał Górny from comment #2) > > > I'd also really appreciate if you moved all the masked packages when bumping > > > emul-linux. Now blockers are incorrect. Again. > > > > Sorry, I'm not following. Did I miss a step? > > # Lars Wendler <polynomial-c@gentoo.org> > # Multilib ready ebuild (bug #496218). Collides with emul-linux-x86-baselibs > =sys-devel/gettext-0.18.3.2 > =virtual/libintl-0-r1 > > You should have added those to remove-native and unmasked them as well. I don't think so, I didn't touch gettext or libintl, whoever converted them should have done the steps
Why isn't this package masked yet? It breaks library deps of other packages.
Masking it would break much more since remove-native is shared between all versions.
(In reply to Michał Górny from comment #11) > Masking it would break much more since remove-native is shared between all > versions. what means: "emove-native is shared between all versions."?
This is a real PITA.
> This is a real PITA. Indeed. What is needed is a package providing 32-bit libjpeg.so.8 for those of us that use libjpeg-turbo like recommended since 2012-04-24 (News: The default JPEG implementation / Samuli Suominen). As far as I can tell, the jpeg-8d-r1:0 as suggested in #1 will not do because it actively both blocks multilib-capable libjpeg-turbo and is blocked by it. If there is a combination of use flags and use masks that allows them to coexists I wasn't able to find it. One way to resolve this could be to use a trimmed version of the jpeg-8d ebuild that can coexist with libjpeg-turbo, like the quick hack for jpeg-8d-r1:8 in http://forums.gentoo.org//viewtopic-p-7491400.html
Maybe I am being naive, but I do not see how the current emul-linux-x86-baselibs packages could have been generated. On ~amd64 the only thing which provides lib32/libjpeg.so.8 is emul-linux-x86-baselibs and other libraries in this package have broken link dependencies to it. The bug was first reported in emul-linux-x86-baselibs-20131008-r9, so I do not see how the libraries distributed in the subsequent emul-linux-x86-baselibs-20131008-r10/11/12 packages could have been built without either generating linker failures (not being able to find libjpeg.so.8) or linking against libjpeg.so.62 from jpeg-turbo. So to me one solution is obvious. Whoever builds the libraries (with broken dependencies) included in emul-linux-x86-* packages should rebuild them so as link against libjpeg.so.62 to match the 'virtual/jpeg:62[abi_x86_32(-)]' RDEPEND
(In reply to Graham Murray from comment #15) > Maybe I am being naive, but I do not see how the current > emul-linux-x86-baselibs packages could have been generated. On ~amd64 the > only thing which provides lib32/libjpeg.so.8 is emul-linux-x86-baselibs wrong, it's provided by media-libs/jpeg-8d-r1, which everyone can use if this is more than a cosmetic problem (In reply to Jouni Kosonen from comment #14) > http://forums.gentoo.org//viewtopic-p-7491400.html that's nice, but won't go in Portage because it would be rather impossible to provide full jpeg-8 for stable users, and trimmed down for ~arch users since latest revision of jpeg needs to be the one with headers and such well, if all packages would have proper virtual/jpeg:0 instead of virtual/jpeg dependencies, maybe we could add it to Portage but like said, otherwise this will autoresolve soon enough, i'm continuing converting the files still using libjpeg.so.8 or libmng.so.1 and i'm sure others will too as part of normal development process in their packages :)
(In reply to Samuli Suominen from comment #16) > wrong, it's provided by media-libs/jpeg-8d-r1, which everyone can use if > this is more than a cosmetic problem media-libs/jpeg-8d-r1 cannot be installed along side of media-libs/libjpegturbo:0 which is required by some packages. So no, not everyone can use it.
(In reply to Samuli Suominen from comment #16) > (In reply to Graham Murray from comment #15) > > Maybe I am being naive, but I do not see how the current > > emul-linux-x86-baselibs packages could have been generated. On ~amd64 the > > only thing which provides lib32/libjpeg.so.8 is emul-linux-x86-baselibs > > wrong, it's provided by media-libs/jpeg-8d-r1, which everyone can use if > this is more than a cosmetic problem I belong to the "everyone" set of people, but I can't use it. In fact, I think you'd be surprised at how many people actually can't use it.
emul-linux-x86-baselibs-20131008-r14.ebuild contains following line: mv "${ED}"/usr/lib32/{libjpeg.so.8*,libturbojpeg.so.0*} "${ED}${LIBDIR}"/ There is another problem with it -- invalid symlink: /usr/lib32/libjpeg.so -> libjpeg.so.8.0.2 app-emulation/wine fails to build therefore: configure: error: libjpeg development files not found, JPEG won't be supported. This is an error since --with-jpeg was requested. I suppose that libjpeg.so should be moved too.
(In reply to Vasiliy Yeremeyev from comment #19) > There is another problem with it -- invalid symlink: /usr/lib32/libjpeg.so > -> libjpeg.so.8.0.2 Something is wrong on your system. Here, it's: $ file /usr/lib32/libjpeg.so /usr/lib32/libjpeg.so: symbolic link to `libjpeg.so.62.1.0'
Also, which package owns /usr/lib32/libjpeg.so? It shouldn't be the emul package. Here, it's: $ qfile /usr/lib32/libjpeg.so media-libs/libjpeg-turbo (/usr/lib32/libjpeg.so)
(In reply to Nikos Chantziaras from comment #21) /usr/lib32/libjpeg.so belongs to emul-linux-x86-baselibs. That is why I started digging into its ebuild.
20140406 dropped all jpeg playing
