Propagate the configuration setting through an envvar, check the envvar in the compositor.
Needed because querying AccountsSettings for this information fails, due to Ubuntu-only
"InputSources" interface. So you're stuck on US layout without this hack.
We don't have a functional content-hub transfer test, so this slipped through the cracks during testing.
(The background setting in LSS would be an easy one, but that calls an AccountsSetting function that
doesn't exist outside of Ubuntu, so it wouldn't work anyway.)
- Patch has been merged, fetch merged one & update comment (hash is unchanged, checked)
- We now have a CMake modern enough for pkg_get_variable DEFINE_VARIABLES, use it
- substituteInPlace --replace is deprecated
- with lib; in meta is frowned-upon
LAL manages desktop file parsing for various parts of the Lomiri environment. It also handles turning them into SystemD services tracked in the background.
And due to how things work one, it's code is also SystemD-launched by itself.
When we package applications with desktop files, we don't want the Exec values to be absolute, so we patch out absolute paths.
Without absolute paths, PATH is expected to have the path to the executables. But our PATHs don't always contain i.e. /run/current-system/sw/bin.
Services launched by SystemD are one such instance. If LAL code is run under SystemD's restricted reduced PATH, then it fails to find the requested executables.
This is what happens to content-hub, and it causes all transfer requests to be met with an immediate "could not launch peer"-like error, and a transfer being stuck halfway.
To work around this (I wouldn't call this a real solution?), patch LAL code to:
- also propagate whatever PATH it currently *does* have to its launched applications
- postfix the PATH it has with /run/current-system/sw/bin, to give it a decent fallback
These changes allow for lomiri-filemanager-app to be launched via a content-hub request from lomiri-system-settings (i.e. the background selection).
Needs a GLib change to be fixed, which needs a staging cycle, which I was told won't happen in time anymore.
Luckily it's not a crucial component for the desktop mode.
This was achieved using the following command:
sd 'wrapGAppsHook\b' wrapGAppsHook3 (rg -l 'wrapGAppsHook\b')
And then manually reverted the following changes:
- alias in top-level.nix
- function name in wrap-gapps-hook.sh
- comment in postFixup of at-spi2-core
- comment in gtk4
- comment in preFixup of 1password-gui/linux.nix
- comment in postFixup of qgis/unwrapped-ltr.nix and qgis/unwrapped.nix
- comment in postFixup of telegram-desktop
- comment in postFixup of fwupd
- buildCommand of mongodb-compass
- postFixup of xflux-gui
- comment in a patch in kdePackages.kde-gtk-config and plasma5Packages.kde-gtk-config
- description of programs.sway.wrapperFeatures.gtk NixOS option (manual rebuild)
The UserMetrics service expects AppArmor to be available, and its database access breaks when that's not the case.
Details: https://gitlab.com/ubports/development/core/libusermetrics/-/issues/8
We need to set an envvar for it to work AppArmor-less, but that requires system config knowledge.
Solve this by telling the D-Bus service to look for & launch a systemd service, which we will later create in the Lomiri module.
The only part this really affects for us is Lomiri's First-Time-Launch Wizard, which uses the found & filtered
locale identifiers for a language selection & gets stuck unless at least 1 valid language has been found.
This makes the wizard process completable, in case we ever re-enable it.
The nixpkgs-unstable channel's programs.sqlite was used to identify
packages producing exactly one binary, and these automatically added
to their package definitions wherever possible.
LUITK uses QML2_IMPORT_PATH for finding themes, both additional ones & the default.
If it can't find its default theme, most LUITK apps are displayed as solid-black.
Fix by adding the new variable to its list of considered envvars.
