Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 643496

Summary: x11-libs/gdk-pixbuf-2.36.11: gdk-pixbuf-2.0/2.10.0/loaders.cache not found in merging stage
Product: Gentoo Linux Reporter: Tom-Steve Watzke <tswatzke>
Component: Current packagesAssignee: Gentoo Linux Gnome Desktop Team <gnome>
Status: UNCONFIRMED ---    
Severity: normal CC: ecyoung, herrtimson, jarausch, jstein, perfect007gentleman, water.devil
Priority: Normal    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: gdk-pixbuf-2.36.11 build.log
LC_ALL=C build.log
gdk-pixbuf-2.36.11.ebuild ... fixed
compressed build log

Description Tom-Steve Watzke 2018-01-05 07:48:32 UTC
>>> Installing (1 of 1) x11-libs/gdk-pixbuf-2.36.11::gentoo
 * checking 81 files for package collisions
>>> Merging x11-libs/gdk-pixbuf-2.36.11 to /
 * abi_x86_32.x86: running multilib_pkg_preinst
cp: reguläre Datei '/var/tmp/portage/x11-libs/gdk-pixbuf-2.36.11/image//usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache' kann nicht angelegt werden: Datei oder Verzeichnis nicht gefunden
 * ERROR: x11-libs/gdk-pixbuf-2.36.11::gentoo failed (preinst phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line  124:  Called pkg_preinst
 *   environment, line 3618:  Called multilib_foreach_abi 'multilib_pkg_preinst'
 *   environment, line 3253:  Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib_pkg_preinst'
 *   environment, line 2931:  Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib_pkg_preinst'
 *   environment, line 2929:  Called _multilib_multibuild_wrapper 'multilib_pkg_preinst'
 *   environment, line  550:  Called multilib_pkg_preinst
 *   environment, line 3613:  Called die
 * The specific snippet of code:
 *               cp "${EROOT}"${cache} "${ED}"/${cache} || die;


The loaders.cache cannot be found anywhere in the ${EROOT} directory.
In the previous version 2.36.10-r2 all cache files are there.

If they are not necessary the lines in the ebuild should be removed.
I also could have done this, but I am not sure if they are still needed,
i.e. the cache files.
Comment 1 Jonas Stein gentoo-dev 2018-01-06 21:30:43 UTC
Thank you for the report. Please *attach* the logfiles,
https://wiki.gentoo.org/wiki/Attach_the_logs_to_the_bug_ticket
and reopen this ticket (Status:unconfirmed).

Please remember to set LANG=C

Why do you think the bug is in the component "eclasses"?
Comment 2 Tom-Steve Watzke 2018-01-09 10:06:00 UTC
Created attachment 513852 [details]
gdk-pixbuf-2.36.11 build.log
Comment 3 Tom-Steve Watzke 2018-01-09 10:14:48 UTC
Created attachment 513854 [details]
LC_ALL=C build.log
Comment 4 Tom-Steve Watzke 2018-01-09 10:16:59 UTC
I just set LC_ALL=C and attached a no-color build.log.
As you can see the loaders.cache cannot be found:

cp: cannot create regular file '/var/tmp/portage/x11-libs/gdk-pixbuf-2.36.11/image//usr/lib32/gdk-pixbuf-2.0/2.10.0/loaders.cache': No such file or directory
Comment 5 water.devil 2018-01-14 10:20:08 UTC
Is there a workaround? I have the same issues with 2.36.11 and 2.36.10-r2!

Many thanks
Comment 6 Tom-Steve Watzke 2018-01-19 13:04:49 UTC
Created attachment 515310 [details]
gdk-pixbuf-2.36.11.ebuild ... fixed

I finally found the issue.
The caches could not be copied over to the image,
because the directory to be copied in, does not exist.

Therefore I fixed the ebuild and added: 

mkdir -p "${ED}/usr/$(get_libdir)/${PN}-2.0/2.10.0"
Comment 7 Perfect Gentleman 2018-02-10 08:32:44 UTC
confirm
Comment 8 Brian Evans (RETIRED) gentoo-dev 2018-04-12 16:56:17 UTC
*** Bug 653026 has been marked as a duplicate of this bug. ***
Comment 9 Helmut Jarausch 2018-04-16 15:24:18 UTC
(In reply to Tom-Steve Watzke from comment #6)
> Created attachment 515310 [details]
> gdk-pixbuf-2.36.11.ebuild ... fixed
> 
> I finally found the issue.
> The caches could not be copied over to the image,
> because the directory to be copied in, does not exist.
> 
> Therefore I fixed the ebuild and added: 
> 
> mkdir -p "${ED}/usr/$(get_libdir)/${PN}-2.0/2.10.0"

With that modified ebuild I can install gdk-pixbuf BUT
many applications are broken (e.g. gimp, many browser when trying to save
and image, etc)
One gets
Could not load a pixbuf from icon theme.
This may indicate that pixbuf loaders or the mime database could not be found.
Comment 10 Rick Harris 2018-04-28 11:17:16 UTC
It's because your dev-libs/glib version is lacking gmodule support.

If gdk-pixbuf's build cannot detect a working glib with gmodule support, it won't build the libpixbufloader-* files.

If no libpixbufloader-* files are built, generation of loaders.cache will fail (and so then can't be copied because it doesn't exist).

Here are the offending parts from your build.log's ./configure:

checking for GLIB - version >= 2.48.0... yes (version 2.54.0)
checking whether to build gmodulized gdk-pixbuf... yes
checking whether dynamic modules work... no

The lack of gmodule support is a bug in >=dev-libs/glib-2.54 when using the new Meson build system instead of sticking with the proven to work autotools build system.

So, not strictly a gdk-pixbuf bug but affected by the way >=dev-libs/glib-2.54 can be mis-built (and not in main tree yet).
Comment 11 Mart Raudsepp gentoo-dev 2019-01-21 11:44:31 UTC
So is this bug essentially INVALID or gnome-overlay only?
Or should we handle something about potentially missing gmodule support in some situations (perhaps some prefix systems)?

Main tree glib-2.58.2 is still using autotools; I don't think I will convert it to meson in main tree before 2.59/2.60 series, and I'd suspect it's fine for meson in those versions by now..
Comment 12 tt_1 2019-01-21 11:46:23 UTC
I think that this is a problem for cross compiling, isn't it?
Comment 13 Mart Raudsepp gentoo-dev 2019-01-21 12:26:38 UTC
So you are saying that we need to have the branch that has

touch "${ED}"/${cache} || die

preceded with an appropriate mkdir -p call for that valid use case of cross-compiling (as opposed to meson bugs). OK, will need to think about it and probably do.
Comment 14 tt_1 2019-01-21 17:46:35 UTC
Created attachment 562390 [details]
compressed build log

This is my build log from trying to cross-emerge from amd64 host to armv7 target. I think it's the same bug? 

It's a dependency of gtk+, unfortunatley.
Comment 15 tt_1 2019-01-24 11:20:43 UTC
I think the cross compile bug I suffer from is a different one, because its not about cache generation but the compilation of the binary itself, which is supposed to load the cache.