Created attachment 858657 [details] build log I get "ERROR: Program 'gs' not found or not executable" when building =x11-libs/cairo-1.17.6-r1 (see log).
Created attachment 858659 [details] emerge --info
Created attachment 858689 [details, diff] patch for the ebuild Tests depend on app-text/ghostscript-gpl (causing the error in the log), and additionally: - gnome-base/librsvg - app-text/poppler (meson.build referred poppler-glib, which had to be patched)
Created attachment 858691 [details, diff] patch fixing poppler name in meson.build
(In reply to MW from comment #3) > Created attachment 858691 [details, diff] [details, diff] > patch fixing poppler name in meson.build Can you make a merge request upstream for this?
(In reply to Matt Turner from comment #4) > Can you make a merge request upstream for this? I may very well have misunderstood this, but at least in Debian (and possibly in other distros too) there seems to exist an so-file for poppler-glib, whereas in Gentoo, the poppler-glib package seems to have been removed ages ago to be replaced by just poppler. If poppler-glib still is a thing outside Gentoo, I don't think this would fly upstream.
(In reply to MW from comment #5) > (In reply to Matt Turner from comment #4) > > Can you make a merge request upstream for this? > > I may very well have misunderstood this, but at least in Debian (and > possibly in other distros too) there seems to exist an so-file for > poppler-glib, whereas in Gentoo, the poppler-glib package seems to have been > removed ages ago to be replaced by just poppler. If poppler-glib still is a > thing outside Gentoo, I don't think this would fly upstream. > mattst88@framework gentoo % qlist poppler | grep 'pc$' > /usr/lib64/pkgconfig/poppler-cpp.pc > /usr/lib64/pkgconfig/poppler-glib.pc > /usr/lib64/pkgconfig/poppler.pc app-text/poppler provides poppler-glib. So I'm assuming your patch is wrong... but I don't know how or why poppler on your system wouldn't provide poppler-glib.
cairo's ebuild has this line: > RESTRICT="!test? ( test ) test" # Requires poppler-glib, which isn't available in multilib So maybe you were somehow trying to build tests?
(In reply to Matt Turner from comment #6) > > mattst88@framework gentoo % qlist poppler | grep 'pc$' > > /usr/lib64/pkgconfig/poppler-cpp.pc > > /usr/lib64/pkgconfig/poppler-glib.pc > > /usr/lib64/pkgconfig/poppler.pc > > app-text/poppler provides poppler-glib. > > So I'm assuming your patch is wrong... but I don't know how or why poppler > on your system wouldn't provide poppler-glib. Strange... On my system, I get: ~ # qlist poppler | grep 'pc$' /usr/lib64/pkgconfig/poppler.pc /usr/lib64/pkgconfig/poppler-cpp.pc /usr/share/poppler/cMap/Adobe-CNS1/Adobe-CNS1-B5pc /usr/share/poppler/cMap/Adobe-CNS1/UCS2-B5pc /usr/share/poppler/cMaps/UCS2-B5pc /usr/share/poppler/cMaps/Adobe-CNS1-B5pc /usr/share/pkgconfig/poppler-data.pc (In reply to Matt Turner from comment #7) > cairo's ebuild has this line: > > > RESTRICT="!test? ( test ) test" # Requires poppler-glib, which isn't available in multilib > > So maybe you were somehow trying to build tests? Yes, I'm building with FEATURES="test" and USE="test", but ~ # eselect profile show Current /etc/portage/make.profile symlink: default/linux/amd64/17.1/no-multilib
I suspect poppler's IUSE=cairo flag controls whether poppler-glib is installed. > Yes, I'm building with FEATURES="test" and USE="test" Ah, ever though tests are restricted, you're still setting USE=test. I... don't think you should do that.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4350d1484c0ab46f8f74f973438e47ec24e2c01b commit 4350d1484c0ab46f8f74f973438e47ec24e2c01b Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2023-03-25 02:19:44 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2023-03-25 02:20:31 +0000 x11-libs/cairo: Disable building tests Even though tests are restricted, it's still possible to set USE=test and then configure will fail with missing dependencies. Closes: https://bugs.gentoo.org/902775 Signed-off-by: Matt Turner <mattst88@gentoo.org> x11-libs/cairo/cairo-1.17.8.ebuild | 6 +++--- x11-libs/cairo/cairo-9999.ebuild | 6 +++--- 2 files changed, 6 insertions(+), 6 deletions(-)
(In reply to Matt Turner from comment #9) > I suspect poppler's IUSE=cairo flag controls whether poppler-glib is > installed. > > > Yes, I'm building with FEATURES="test" and USE="test" > > Ah, ever though tests are restricted, you're still setting USE=test. I... > don't think you should do that. i.e. you can and should just set FEATURES=test if you want tests. Don't mess with USE=test.
(In reply to Matt Turner from comment #9) > > Yes, I'm building with FEATURES="test" and USE="test" > > Ah, ever though tests are restricted, you're still setting USE=test. I... > don't think you should do that. Perhaps not, but I'm trying to understand what is actually going on here. The line > RESTRICT="!test? ( test ) test" # Requires poppler-glib, which isn't available in multilib says poppler-glib is unavailable in multilib, but I'm running no-multilib. Additionally, - I don't have any poppler-glib on my system. - The source code does not appear to reference poppler-glib anywhere, but it uses poppler in multiple places. - All tests pass if I change poppler-glib -> poppler. Forcefully setting -Dtests=disabled seems like the wrong approach, IMHO. (In reply to Sam James from comment #11) > i.e. you can and should just set FEATURES=test if you want tests. Don't mess > with USE=test. Hmm, ok. If I remove test from USE but keep it in FEATURES, emerge wants to rebuild a couple of packages without test (which demonstrably have passed). The test USE flag should be possible to set independently, according to https://packages.gentoo.org/useflags/test
(In reply to MW from comment #12) > (In reply to Matt Turner from comment #9) > > > Yes, I'm building with FEATURES="test" and USE="test" > > > > Ah, ever though tests are restricted, you're still setting USE=test. I... > > don't think you should do that. > > Perhaps not, but I'm trying to understand what is actually going on here. > The line > > RESTRICT="!test? ( test ) test" # Requires poppler-glib, which isn't available in multilib > says poppler-glib is unavailable in multilib, but I'm running no-multilib. > Additionally, > > - I don't have any poppler-glib on my system. > - The source code does not appear to reference poppler-glib anywhere, but > it uses poppler in multiple places. > - All tests pass if I change poppler-glib -> poppler. > > Forcefully setting -Dtests=disabled seems like the wrong approach, IMHO. > Yeah, circular deps are fine for tests anyway. Let me look. > (In reply to Sam James from comment #11) > > i.e. you can and should just set FEATURES=test if you want tests. Don't mess > > with USE=test. > > Hmm, ok. If I remove test from USE but keep it in FEATURES, emerge wants to > rebuild a couple of packages without test (which demonstrably have passed). > The test USE flag should be possible to set independently, according to > https://packages.gentoo.org/useflags/test It can be, but shouldn't be.
You need to report this upstream if you think it's fine without 'poppler-glib' (USE=-cairo on poppler). But it sounds like you just have poppler[cairo] on and then tests passed. For me, they've been running at least 15 minutes and seem to be hanging.
commit 62cf35e04c65efdc6b5a8ed2670c9b48451571ea (HEAD -> master, origin/master, origin/HEAD) Author: Sam James <sam@gentoo.org> Date: Sat Mar 25 08:07:29 2023 +0000 x11-libs/cairo: further test plumbing - Only build tests for native ABI because poppler[glib] isn't available for multilib. - Depend on poppler[glib] for tests. - Depend on ghostscript for tests. But we keep tests restricted for now because they seem to hang for me and there's a rather elaborate test setup in CI: https://gitlab.freedesktop.org/cairo/cairo/-/blob/master/.gitlab-ci.yml. This partly reverts commit 4350d1484c0ab46f8f74f973438e47ec24e2c01b. Signed-off-by: Sam James <sam@gentoo.org> Further investigation of the backends and such needed to run tests reliably (and possible e.g. virtualx involvement) should be done in a separate bug.
Thanks, I will look at this in my virtual Debian environment too before potentially reporting poppler-glib -> poppler upstream. Too laggy connection to test right now (sitting on a train).
