Summary: | x11-libs/gtk+:3 emake failed; Can't recognize the image file format for file ....png | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | r3lgar <r3lgar> |
Component: | Current packages | Assignee: | Gentoo Linux Gnome Desktop Team <gnome> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | bkohler, sul |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=645276 https://bugs.gentoo.org/show_bug.cgi?id=264647 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | gtk+-3.22.19:20171021-125241.log.gz |
Description
r3lgar
2017-10-22 04:08:28 UTC
Created attachment 499604 [details]
gtk+-3.22.19:20171021-125241.log.gz
Smells like some odd issues with gdk-pixbuf for you, but not sure what's going on exactly. Do you still experience the issue? > Do you still experience the issue?
Yes, even with fresh stage3 with my portage configs.
I used this command before running emerge :
> export XDG_DATA_DIRS=/usr/share
GTK+3 now compiles successfully for me.
*** Bug 644136 has been marked as a duplicate of this bug. *** XDG_DATA_DIRS is not reset by xdg-utils.eclass. Not sure it should anyway as having invalid value will probably break more than just gtk+ compilation. FTR, this variable is managed in Gentoo through /etc/env.d: /etc/env.d/30xdg-data-local:XDG_DATA_DIRS="/usr/local/share" /etc/env.d/30xdg-data-local:COLON_SEPARATED="XDG_DATA_DIRS XDG_CONFIG_DIRS" /etc/env.d/90xdg-data-base:XDG_DATA_DIRS="/usr/share" /etc/env.d/99xdg-gdm:XDG_DATA_DIRS="/usr/share/gdm" Could you paste the exact content of the variable on the original system and trace back where it is set ? bug 644136 has that info. The thing is, that xdg-utils isn't installed at that point, and gdk-pixbuf is failing. xdg-utils is what installs the /etc/env.d file for /usr/share and /usr/locale/share XDG_DATA_DIRS. I guess that might fine to not have it, but if something else installs it, e.g mesa[openmax], then you end up with XDG_DATA_DIRS set, but /usr/share not contained in it. Of course xdg-utils installs a bunch of perl stuff, and we don't really want that either pulled in too easily. (In reply to Mart Raudsepp from comment #7) > I guess that might fine to not have it, but if something else installs it, > e.g mesa[openmax], then you end up with XDG_DATA_DIRS set, but /usr/share > not contained in it. I meant, if something else installs an env.d file that adds to XDG_DATA_DIRS. mesa[openmax] is one, gdm is another (but for gdm you'll likely to have xdg-users already). That said, now I remember Ben did tests with XDG_DATA_DIRS="" gdk-pixbuf-..., which failed. But maybe these tests should be repeated with an UNset XDG_DATA_DIRS, not set to empty string. Actually, it already says that it's fine if it's unset. So I see various solutions here: 1) Make sure /usr/share and /usr/local/share are always in env.d, via some small package that drops then in and is pulled in much earlier and in RDEPEND of a few important things 2) As 1), but just ensure the base one is pulled in when you are installing your own /etc/env.d with XDG_DATA_DIRS entries, so e.g depended on by mesa[openmax] and gdm and whatever else we find 3) Tweak the /etc/profile env.d apparatus to handle XDG_DATA_DIRS special and always append or prepend /usr/share, and maybe /usr/local/share 4) Your idea here I like 2), but has the caveat of ideally having to find all the existing ones that do this to env.d and remembering to cover it in the future. After that I mght like 4) and then 1). (In reply to Mart Raudsepp from comment #9) > 2) As 1), but just ensure the base one is pulled in when you are installing > your own /etc/env.d with XDG_DATA_DIRS entries, so e.g depended on by > mesa[openmax] and gdm and whatever else we find @x11 - maybe we should add xdg-utils to mesa[openmax] RDEPEND until we figure a better solution out? Emerging x11-misc/xdg-utils provides XDG_DATA_DIRS. Otherwise, the variable is not set and x11-libs/gtk+ fails to build on the before mentioned line. After emerging x11-misc/xdg-utils and having installed mesa[openmax], the content of XDG_DATA_DIRS is as follows: /usr/local/share:/usr/share:/usr/share/mesa/xdg I would add x11-misc/xdg-utils as a possible depend to x11-libs/gtk+:3 to circumvent this issue. (In reply to Andy Mender from comment #11) > I would add x11-misc/xdg-utils as a possible depend to x11-libs/gtk+:3 to > circumvent this issue. No, it's not gtk+ related. Other stuff that follows the standard could break just as well. It just happens the gtk stack showed the issue very visibly. mattst88 ACKed a temporary addition of it to mesa[openmax] until we figure out a better solution (see comment #9). I'll see if he'll do the change himself soon with maybe other batched changes, or I'll commit it soon myself. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3df07552decade334030ee8b793e40a34a9a2688 commit 3df07552decade334030ee8b793e40a34a9a2688 Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2018-02-24 10:44:36 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2018-02-24 10:56:49 +0000 media-libs/mesa: depend on xdg-utils for USE=openmax to not break XDG specs This is currently necessary due to the installation of 99mesaxdgomx with USE=openmax. Ideally we wouldn't depend on xdg-utils as a whole with its perl deps, but that's pending changed there. Unbreak things for the not so common case of mesa USE=openmax for the time being. Bug: https://bugs.gentoo.org/635040 Bug: https://bugs.gentoo.org/264647 Package-Manager: Portage-2.3.19, Repoman-2.3.6 media-libs/mesa/mesa-17.1.10.ebuild | 7 +++++-- media-libs/mesa/mesa-17.2.8.ebuild | 5 ++++- media-libs/mesa/mesa-17.3.5.ebuild | 5 ++++- media-libs/mesa/mesa-18.0.0_rc4.ebuild | 5 ++++- media-libs/mesa/mesa-9999.ebuild | 5 ++++- 5 files changed, 21 insertions(+), 6 deletions(-)} media-libs/mesa no longer has IUSE=openmax. Removing x11@ from cc. |