af1d2bd13a
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). |
||
|---|---|---|
| .. | ||
| applications | ||
| data | ||
| development | ||
| qml | ||
| services | ||
| default.nix | ||