Bug 257493

Summary: games/gnome-mahjongg: 'stage' tries to install directly to LOCALBASE
Product: Ports & Packages Reporter: John Hein <jcfyecrayz>
Component: Individual Port(s)Assignee: freebsd-gnome (Nobody) <gnome>
Status: New ---    
Severity: Affects Some People CC: jcfyecrayz, tcberner
Priority: --- Flags: bugzilla: maintainer-feedback? (gnome)
Version: Latest   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
[patch] games/gnome-mahjongg - fix 'stage' writing to LOCALBASE jcfyecrayz: maintainer-approval? (tcberner)

Description John Hein 2021-07-29 20:50:00 UTC
'make -C /usr/ports/games/gnome-mahjongg stage' fails when run as a user that does not have write permission in LOCALBASE.  It tries to install a file directly to LOCALBASE instead of the 'work/stage' dir.

This worked fine in Nov 2020 when this port was updated to 3.38.2, but now fails - probably(?) due to changes in meson.

===>  Staging for gnome-mahjongg-3.38.3
===>   Generating temporary packing list
 .
 .
Running custom install script '/usr/local/bin/meson --internal gettext install --subdir=po --localedir=share/locale --pkgname=gnome-mahjongg'
Running custom install script '/usr/local/bin/glib-compile-schemas /usr/local/share/glib-2.0/schemas'
--- stdout ---

--- stderr ---
Failed to create file “/usr/local/share/glib-2.0/schemas/gschemas.compiled.43UL70”: Permission denied

FAILED: install script '/usr/local/bin/glib-compile-schemas /usr/local/share/glib-2.0/schemas' exit code 1, stopped
FAILED: meson-install 
/usr/local/bin/meson install --no-rebuild
ninja: build stopped: subcommand failed.
*** Error code 1
Comment 1 John Hein 2021-07-29 21:16:41 UTC
It seems that it's not a meson change, but it IS the change from 3.38.2 to 3.38.3 after all that is triggering the problem.

Using the latest meson in ports (0.58.1) and 3.38.2 works fine ('make stage' as a regular user does not tail).  3.38.2 does not even try to run glib-compile-schemas whereas 3.38.3 runs glib-compile-schemas but does not obey DESTDIR ('/usr/local/bin/glib-compile-schemas /usr/lcoal/share/glib02.0/schemas').

Committer CC'd.
Comment 2 John Hein 2021-07-29 21:19:14 UTC
Here's the difference between 3.38.2 and .3 that causes 3.38.3 to run glib-compile-schemas:

--- gnome-mahjongg-3.38.2/meson_options.txt     2020-10-03 10:16:30.594575400 -0600
+++ gnome-mahjongg-3.38.3/meson_options.txt     2020-11-01 02:39:32.629650000 -0700
@@ -1,2 +1,2 @@
-option('compile-schemas', type: 'feature', value : 'disabled', description : 'Compile GSettings schemas on install')
-option('update-icon-cache', type: 'feature', value : 'disabled', description : 'Update icon cache')
+option('compile-schemas', type: 'feature', value : 'enabled', description : 'Compile GSettings schemas on install')
+option('update-icon-cache', type: 'feature', value : 'enabled', description : 'Update icon cache')


That is, it was disabled for 3.38.2
Comment 3 John Hein 2021-07-29 21:20:22 UTC
Now... how to get meson to invoke glib-compile-schemas so it writes to work/stage for 'make stage'.
Comment 4 John Hein 2021-07-29 21:40:41 UTC
It looks like the module in meson's modules/gnome.py writes to 'prefix'/'datadir' if 'glib_compile_schemas' is enabled.  Without any 'DESTDIR' in front of it.

Maybe it's just right to disable glib_compile_schemas for 'stage'.  'install' will run it via Keywords/glib-schemas.ucl
Comment 5 John Hein 2021-07-29 22:26:38 UTC
I think this might be the right fix:

CONFIGURE_ARGS+=        -Dcompile-schemas=disabled -Dupdate-icon-cache=disabled


We may also have always been missing USES+=gtk-update-icon-cache for this port as well - it does store files in share/icons.
Comment 6 John Hein 2021-07-29 22:30:16 UTC
(In reply to John Hein from comment #5)
Never mind on the comment about USES+=gtk-update-icon-cache.  INSTALLS_ICONS=yes takes care of that.
Comment 7 John Hein 2021-07-30 21:58:46 UTC
Created attachment 226809 [details]
[patch] games/gnome-mahjongg - fix 'stage' writing to LOCALBASE

This patch disables the attempt to run glib-compile-schemas and gtk-update-icon-cache during 'make stage'.  Both of these were trying to write to LOCALBASE instead of the staging dir (work/stage) which triggered a 'permission denied' issue if running 'make stage' as a regular user.  And both are already done anyway by the gnome ports infrastructure at 'install' time (or if installing from pkg, at the time the of the 'pkg install').

There is also a change in ordering in the Makefile for the USES line (prodded by portlint's whine).

There is no need to bump the PORTREVISION - there is no change in the package.

I tested in poudriere (testport -i to get interactive mode) by creating a regular user and doing 'make clean stage' as the regular user.  Without the patch it fails (as expected) - with the patch it passes 'make stage stage-qa check-plist' as the regular user and 'make install' as root.


QA:
 - portlint: ok (1 less warning after patch)
 - testport: ok (11-stable/amd64)
Comment 8 John Hein 2021-08-16 15:05:29 UTC
Maintainer timeout.  Has anyone had a chance to look at this?