Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#62468 - [libmypaint] is not detected by gimp build system because of minor-versioning patch

Attached to Project: Arch Linux
Opened by David Gowers (likytau) - Thursday, 25 April 2019, 11:21 GMT
Last edited by Levente Polyak (anthraxx) - Tuesday, 10 September 2019, 20:38 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


Description: Building gimp from git fails at the 'configure' step because the Arch package specifically patches libmypaint to install its .pc files as /usr/lib/pkgconfig/libmypaint{,-gegl}-1.3.pc rather than the standard /usr/lib/pkgconfig/libmypaint{,-gegl}.pc.

Presumably, this failure also occurs in all other projects which use pkgconfig to get compilation flags for libmypaint.

Version: libmypaint 1.3.0-6

Log excerpt:

checking for OPENEXR... yes
checking for WEBP... yes
checking for WEBPMUX... yes
checking for WEBPDEMUX... yes
checking for LIBHEIF... yes
checking for LIBBACKTRACE... no
checking for LIBUNWIND... yes
checking for LIBMYPAINT... no
configure: Eeeeeeeeeeeeeeeeeeeeek! Missing dep: libmypaint >= 1.3.0
checking for MYPAINT_BRUSHES... yes
checking for WEBKIT... yes
checking for SVG... yes
checking for gtk-encode-symbolic-svg... gtk-encode-symbolic-svg
checking for POPPLER... yes
checking for POPPLER_DATA... yes

Error: GIMP configuration failed.

- Error: missing dependency libmypaint >= 1.3.0

Further comments:

It's possible to skip the detection process and force the result by exporting the variables LIBMYPAINT_CFLAGS=$(pkg-config --cflags 'libmypaint-1.3 >= 1.3.0') and LIBMYPAINT_LIBS (pkg-config --cflags --libs 'libmypaint-1.3 >= 1.3.0') before invoking

I'm aware that this is the result of a patch backported from libmypaint 2.x to 1.x, intended to enable the coexistence of (for example) libmypaint 2.0 and libmypaint 2.1. However, given that all active development on libmypaint occurs on the 2.x branch, it is not at all clear why Arch should by default require the user to take special measures to compile with libmypaint 1.x.

Upstream GIMP devs regard this as mispackaging, AFAICS (link below).

Steps to reproduce:

git clone
cd gimp automatically runs configure

Upstream bug report:
This task depends upon

Closed by  Levente Polyak (anthraxx)
Tuesday, 10 September 2019, 20:38 GMT
Reason for closing:  Fixed
Additional comments about closing:  1.4.0-1
Comment by David Gowers (likytau) - Thursday, 25 April 2019, 11:25 GMT
Oops, missed converting that second export to bash syntax. That should read:

LIBMYPAINT_CFLAGS=$(pkg-config --cflags 'libmypaint-1.3 >= 1.3.0')
LIBMYPAINT_LIBS=$(pkg-config --cflags --libs 'libmypaint-1.3 >= 1.3.0')

Comment by Félix Piédallu (Salamandar3500) - Thursday, 22 August 2019, 16:04 GMT
Where's that bug at ?
The upstream code creates libmypaint.pc, but Arch has a specific patch that changes that:

-pkgconfig_DATA = libmypaint.pc
+pkgconfig_DATA = libmypaint-@LIBMYPAINT_API_PLATFORM_VERSION@.pc

The very goal of pkg-config is to have the **same** file names in every distro, but the arch-specific patch deceives that.
Comment by Jehan (Jehan) - Sunday, 25 August 2019, 00:50 GMT
Hi all,

I am one of the GIMP devs who worked together with the libmypaint developers to version properly their library, starting the v2. I made an account here specifically for this report. :-)

If the goal of your patch on libmypaint v1 is to make sure that you can install both v1 and v2 side by side, this is unnecessary. If we did things right, there should be no name clash between any of the v1 and v2 files (if you find any, please report to libmypaint). And in particular there is no name clash on the pkg-config file as the new pkg-config files for v2 is correctly named `libmypaint-2.0.pc`.

The reason why the correct versionning was not backported to v1, upstream, and **must not** be backported was exactly the reason why this report is opened today: it breaks existing builds for no good reason. There would have been a reason, say if libmypaint had continued to not properly version its files, hence both v1 and v2 were named `libmypaint.pc`. Fortunately this has not happened, and how the v1 is versionned is just to be seen as a historical anomaly (which is quite common in early history of many software).

Could this patch be removed please? :-)
Comment by Levente Polyak (anthraxx) - Sunday, 25 August 2019, 10:02 GMT
Hi Jehan, thanks for reaching out!

That is indeed a reasonable explanation/reasoning to get this changed back. In fact, it wasn't done on purpose, at least not from us on the official side. Back than we had some maintainers resign and leaving back gimp, at that specific point in time nobody wanted to maintain it, so eworm and me took on the quest and needed to gain package specific knowledge that was left behind.
While I helped getting gimp to 2.10.0, wich included the requirement of libmypaint, I was in the need to bring libmypaint into the official repo. It was moved over from the non-official userbase maintained AUR where I just did a basic sanity and non-maliciousness check of the build scripts and the patch that was included which we expected to have some reason and it was an official change from the source tree, therefor we just moved it as is into the repos and the real decision to do so was done by the previous (non-official) maintainer. It indeed seems to be a suboptimal decision and we shouldn't have moved that patch along, which became quite clear today and I will stage the removal and rebuild packages :)
Comment by Jehan (Jehan) - Sunday, 25 August 2019, 10:07 GMT
Awesome. Thanks Levente Polyak! :-)
Comment by Félix Piédallu (Salamandar3500) - Tuesday, 27 August 2019, 13:48 GMT
Great, thanks !
Comment by Levente Polyak (anthraxx) - Wednesday, 04 September 2019, 21:06 GMT
@Jehan @ Félix: heads-up, libmypaint 1.4 with dropped patches will hit the repos soon, currently going through testing
Comment by Eli Schwartz (eschwartz) - Wednesday, 04 September 2019, 21:31 GMT
BTW the version in testing now has conflicts with community/mypaint which contains libmypaint stuff inside.
Comment by Levente Polyak (anthraxx) - Wednesday, 04 September 2019, 21:34 GMT
@eschwartz: thats there since the package exists, not related to any of this bug or changes
Comment by Eli Schwartz (eschwartz) - Wednesday, 04 September 2019, 21:38 GMT
The file conflicts did not used to exist, because the version 1.x install of libmypaint installed, per this bug report, using versioned paths. I know this, because I currently have the following packages installed:


And when I pacman -Syu, I get file conflicts, instead of package conflicts=()
Comment by Eli Schwartz (eschwartz) - Wednesday, 04 September 2019, 21:39 GMT

$ pkgfile -v /usr/include/libmypaint/mypaint-brush-settings-gen.h
testing/libmypaint 1.4.0-1 /usr/include/libmypaint/mypaint-brush-settings-gen.h
community/mypaint 1.2.1-7 /usr/include/libmypaint/mypaint-brush-settings-gen.h
$ pkgfile -v /usr/include/libmypaint-1.3/mypaint-brush-settings-gen.h
extra/libmypaint 1.3.0-6 /usr/include/libmypaint-1.3/mypaint-brush-settings-gen.h
Comment by Levente Polyak (anthraxx) - Wednesday, 04 September 2019, 21:42 GMT
will add a conflicts to mypaint, which is orphan for a quite long period of time btw
Comment by Félix Piédallu (Salamandar3500) - Thursday, 05 September 2019, 07:14 GMT
Hi @eschwartz,
Read the mypaint pkgconfig file. You'll find it's not a valid pc file (the prefix is /build/…). I guess there's no reason to keep this file, and resolve the conflict with libmypaint by removing it in pkg().