Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 587004 - media-gfx/gimp-2.9.2-r1: fails to build with XDG_* variables preset
Summary: media-gfx/gimp-2.9.2-r1: fails to build with XDG_* variables preset
Status: RESOLVED OBSOLETE
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Sergey Torokhov
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-25 06:17 UTC by Michał Górny
Modified: 2020-09-02 21:54 UTC (History)
2 users (show)

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


Attachments
Build log (media-gfx:gimp-2.9.2-r1:20160625-060805.log,33.12 KB, text/x-log)
2016-06-25 06:17 UTC, Michał Górny
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-06-25 06:17:59 UTC
Created attachment 438698 [details]
Build log

/usr/bin/glib-compile-resources \
  --sourcedir=. --generate-source \
  --target=gimp-color-picker-cursors.c gimp-color-picker-cursors.gresource.xml
/usr/bin/glib-compile-resources \
  --sourcedir=. --generate-source \
  --target=gimp-tool-cursors.c gimp-tool-cursors.gresource.xml
failed to load "./cursor-bad.png": Couldn't recognize the image file format for file './cursor-bad.png'
failed to load "./cursor-color-picker.png": Couldn't recognize the image file format for file './cursor-color-picker.png'
gimp-color-picker-cursors.gresource.xml: Child process exited with code 1.
gimp-tool-cursors.gresource.xml: Child process exited with code 1.


I suspect that's because it relies on XDG_CONFIG_DIRS being valid, and the ebuild does not reset it.
Comment 1 Sebastian Pipping gentoo-dev 2016-07-22 17:47:55 UTC
It turned out to be XDG_DATA_DIRS.


commit b2df37876a3017c1870be801814733b51c169de1
Author: Sebastian Pipping <sping@g.o>
Date:   Fri Jul 22 19:41:51 2016 +0200

    media-gfx/gimp: Sane XDG_DATA_DIRS (bug #587004)
    
    Package-Manager: portage-2.2.28

 media-gfx/gimp/gimp-2.9.2-r2.ebuild | 1 +
 media-gfx/gimp/gimp-2.9.4.ebuild    | 1 +
 media-gfx/gimp/gimp-9999.ebuild     | 1 +
 3 files changed, 3 insertions(+)

https://github.com/gentoo/gentoo/commit/b2df37876a3017c1870be801814733b51c169de1


If you think that /usr/share alone is not good enough, I welcome ideas on how to best query the system config value (minus /usr/local for bindist) from inside the ebuild.
Comment 2 Anton 2017-03-26 15:21:46 UTC
(In reply to Sebastian Pipping from comment #1)
> It turned out to be XDG_DATA_DIRS.
> 
> 
> commit b2df37876a3017c1870be801814733b51c169de1
> Author: Sebastian Pipping <sping@g.o>
> Date:   Fri Jul 22 19:41:51 2016 +0200
> 
>     media-gfx/gimp: Sane XDG_DATA_DIRS (bug #587004)
>     
>     Package-Manager: portage-2.2.28
> 
>  media-gfx/gimp/gimp-2.9.2-r2.ebuild | 1 +
>  media-gfx/gimp/gimp-2.9.4.ebuild    | 1 +
>  media-gfx/gimp/gimp-9999.ebuild     | 1 +
>  3 files changed, 3 insertions(+)
> 
> https://github.com/gentoo/gentoo/commit/
> b2df37876a3017c1870be801814733b51c169de1
> 
> 
> If you think that /usr/share alone is not good enough, I welcome ideas on
> how to best query the system config value (minus /usr/local for bindist)
> from inside the ebuild.

Yes, hard-coding /usr/share seems to be breaking things for the Prefix project. Would it be possible to prepend or append /usr/share to the existing value of XDG_DATA_DIRS instead?

"The Gentoo Prefix project develops and maintains a way of installing Gentoo systems in a non-standard location, designated by a "prefix"". The environment variables such as XDG_DATA_DIRS are used to tell programs where to find their staff -- which is almost never in its default location.
Comment 3 Sebastian Pipping gentoo-dev 2017-03-29 12:59:07 UTC
(In reply to Anton from comment #2)
> Yes, hard-coding /usr/share seems to be breaking things for the Prefix
> project. Would it be possible to prepend or append /usr/share to the
> existing value of XDG_DATA_DIRS instead?
> 
> "The Gentoo Prefix project develops and maintains a way of installing Gentoo
> systems in a non-standard location, designated by a "prefix"". The
> environment variables such as XDG_DATA_DIRS are used to tell programs where
> to find their staff -- which is almost never in its default location.

If our options are:

  # a) Shy default
  export XDG_DATA_DIRS=${XDG_DATA_DIRS:-/usr/share}

  # b) Append
  export XDG_DATA_DIRS="${XDG_DATA_DIRS}${XDG_DATA_DIRS:+:}/usr/share"

  # c) Prepend
  export XDG_DATA_DIRS="/usr/share${XDG_DATA_DIRS:+:}${XDG_DATA_DIRS}"

then (a) and (b) should ensure that something within the prefix from externally set XDG_DATA_DIRS makes it through and wins.

I wonder if we need to care about failing builds for when XDG_DATA_DIRS is set to something bogus, unreadable etc.  I'm happy about any guidance with this.
Comment 4 Fabian Groffen gentoo-dev 2017-03-29 13:36:00 UTC
is that value recorded by the build system somewhere?  If so, isn't using "${EPREFIX}/usr/share" enough?
Comment 5 Sebastian Pipping gentoo-dev 2017-03-29 13:41:51 UTC
(In reply to Fabian Groffen from comment #4)
> is that value recorded by the build system somewhere?  If so, isn't using
> "${EPREFIX}/usr/share" enough?

Fabian,
please help me understand what you mean by recorded -- stored into a file -- and what scenario (or which two scenarios) this is about.

Anton,
is your XDG_DATA_DIRS set to something other than "${EPREFIX}/usr/share" and if so would that value impose troublesome limitations on your setup?
Comment 6 Fabian Groffen gentoo-dev 2017-03-29 13:47:44 UTC
sorry, I could've been a lot clearer.

I don't know what the build system is doing with the exported variable (from your commit).  If it's only used during compilation/testing as some tmp env in a  temp directory, it doesn't matter that it isn't prefixed.  However, if the build records the value of the variable in an init script, or embedded in C-code as default, etc., then the value must be prefixed, to match at runtime.

From comment #0 it's unclear it seems to suggest this is pkg_postinst or something, in which case it certainly needs EPREFIX in XDG_CONFIG_DIRS.  (In that case it should also NOT be necessary to respect anything from the calling env, for repeatability etc.)