New installation promps error: Settings schema 'org.gnome.Mahjongg' is not installed

[Eonfge]

Setup

[kevin@kevinfedora ~]$ flatpak info org.gnome.Mahjongg

GNOME Mahjongg - Match tiles and clear the board

          ID: org.gnome.Mahjongg
         Ref: app/org.gnome.Mahjongg/x86_64/stable
        Arch: x86_64
      Branch: stable
     Version: 3.38.2
     License: GPL-2.0+ and CC-BY-SA-3.0
      Origin: flathub
  Collection: org.flathub.Stable
Installation: system
   Installed: 3,7 MB
     Runtime: org.gnome.Platform/x86_64/3.38
         Sdk: org.gnome.Sdk/x86_64/3.38

      Commit: 6bd3b82e103aedc3af9ac4c414eadea91ed6d2f269d59070fa75c0fdf0a9a453
      Parent: 3e942cf71a5ae4085244918a90108d835d1acad1a28dd421a87562d683441b46
     Subject: Updated to 3.38.2 (db81f050)
        Date: 2020-10-18 23:13:42 +0000

Stacktrace

[kevin@kevinfedora ~]$ flatpak run org.gnome.Mahjongg 
Gtk-Message: 08:32:18.382: Failed to load module "canberra-gtk-module"
Gtk-Message: 08:32:18.382: Failed to load module "pk-gtk-module"
Gtk-Message: 08:32:18.383: Failed to load module "canberra-gtk-module"
Gtk-Message: 08:32:18.383: Failed to load module "pk-gtk-module"

(gnome-mahjongg:2): GLib-GIO-ERROR **: 08:32:18.385: Settings schema 'org.gnome.Mahjongg' is not installed

[Obsidien]

New upstream co-maintainer here, so I’m discovering a bit the code.

Looks like there are two compilation options, compile-schemas and update-icon-cache (added in commit cf5d3b69ad7f5d0eaead5efd60629008a2566b35), that are both disabled by default. @bilelmoussaoui did you already see something like that? Shouldn’t the best practice be to enable that by default?

[Eonfge]

that are both disabled by default.

Well that's bloody stupid. 🤦

Yes, enable by default upstream, and second, put them on true in the Flatpak Manifest because we need em!

[Obsidien]

I’ve mailed Alberto to understand its use case. I plan a 3.38.3 release this week-end as a fix.

[aruiz]

that are both disabled by default.

Well that's bloody stupid. facepalm

I'd refrain from this type of language to refer to other fellow maintainer's choices in the absence of background information.

I took the same approach as other meson projects in GNOME (I don't remember as of now which ones specifically) and the rationale here is that most of the time the meson scripts are run by the developers and not packagers and require root/privileged access to modify your host configuration. Typically packagers would run this as part of post-install operations in rpm/deb and the like. Otherwise this would be prompting for root access every time a developer is cycling through changes, not to mention that nothing guarantees that you'd be installing schemas to a path where the system wide configuration will pick it up.

It is desirable that this is enabled explicitly so that people who use those flags hint that they know what they are doing and run these privileged operations at their own risk.

Yes, enable by default upstream,

-1

and second, put them on true in the Flatpak Manifest because we need em!

+1

[Obsidien]

and require root/privileged access to modify your host configuration

Do some really install dev’ things directly on their host environment? That looks like a quite bad practice, that I’d happily discourage… JHbuild has its own setup of things (and runs in its own container here anyway), containers-based builds also need the commands to run, of course, so I’d preferably enable this two options upstream, allowing people who need it to set them off.

and second, put them on true in the Flatpak Manifest because we need em!

Anyway, that should probably be done, with or without a new release.

[bilelmoussaoui]

Except those commands are ran based on the build prefix, it's not necessarily something that requires root permissions and iirc most of GNOME projects have those always enabled to avoid cases like these where the packager isn't aware of the extra option to enable.

[Eonfge]

@aruiz I think that I vocalized my discontent in stronger words then absolutely necessary. It's more the fact that a prominent application has been broken for more then a week (original update: #8 ) that made me react vocally. My apologies to you, as you're not directly involved in the distribution here.

On the topic of compiler-instructions, I don't remember any other GNOME application that does it so. I've recently updated GNOME applications like Maps, Contacts, Calendar and others, and all of them generate schemes on meson install. I'm not sure if there is any hard rule regarding that, but schemes are normally included in the installation process.

[aruiz]

Except those commands are ran based on the build prefix, it's not necessarily something that requires root permissions and iirc most of GNOME projects have those always enabled to avoid cases like these where the packager isn't aware of the extra option to enable.

That's true for the icons but not for the schema, the pkg-config prefix is used as of now as they did in the package I copied it from (which again, at this point I have forgotten).

If GNOME is has a more consistent approach to this I will leave it up to @Obsidien to update the upstream package accordingly, I don't have a strong opinion here, just stating the background rationale.

[Eonfge]

I made #10 to remedy the issue

[Obsidien]

I’ve just released 3.38.3 that enables the two options by default.

[Obsidien]

Wait before updating to 3.38.3, there will be a 3.38.4.

[ovitters]

This broke the build for distributions.

[tonydiep]

As a user, Mahjongg is not starting for me. I see this error "(gnome-mahjongg:2): GLib-GIO-ERROR **: 13:43:58.004: Settings schema 'org.gnome.Mahjongg' is not installed"

Is there anything I can do as a user to make this work? Or, do I wait for a new release to fix this?

[bilelmoussaoui]

@tonydiep i've merged #10 which should fix your issue, an update should be there in few hours.

[Eonfge]

@bilelmoussaoui Thanks for addressing the issue. Perhaps good to think about in the future: How will we escalate these kind of issues in the future? In this case, a prominent GNOME application was non-functional for a month.

I'll close the issue for now and hope that we can think of ways to streamline such a process in the future.

[tonydiep]

Could add tests that actually install the program and then run it. Test console output from starting program. Test that application window exists.