Seemingly non-functional on PostMarketOS.

[Inderix]

Describe the bug

GSConnect Settings does not open, nor does the extension appear to be doing much of anything

Steps to reproduce

1. Install from Extension Manager/GNOME Extensions on PostmarketOS
2. Attempt to open extension settings (From Extension Manager or GNOME Extensions app)
3. Observe bug.
   Quick Settings > GSConnect > Mobile Settings also does not work.

Expected behavior

GSConnect settings opens, error notifications about missing dependencies as needed, the usual first-run experience.

GSConnect version

58

Installed from

Extension Manager

GNOME Shell version

47

Linux distribution/release

PostMarketOS Edge aarch64

Paired device(s)

N/A

KDE Connect app version

N/A

Plugin(s)

N/A

Support log

N/A, as I cannot reach the button for generating the log.

Screenshots

No response

Notes

gnome-extensions info [email protected] returns that the extension is enabled and it's current state is "active"
when running gnome-extensions prefs [email protected], the command returns no output and then exits to prompt.

I originally was trying to use the extension on PostmarketOS's latest stable branch, which only has Gnome 46 for the time being still. I upgraded to Edge (which provides G47) in hopes of it working, but as you can see by this report, it does not.

[daniellandau]

Interesting. What form factor device is this? As in normal gnome shell or mobile?

[Inderix]

I'm running the normal PC/desktop/tablet Gnome Shell, I haven't tested with Phosh.

[daniellandau]

Phosh definitely wouldn't work, I was thinking about the mobile version if gnome shell. I think I could get postmarketos going on some device during the next few weeks to check.

[Inderix]

Ah, I'm just using bone stock gnome shell yeah.
I'll keep an eye on this thread, if there's anything you want me to test specifically feel free to let me know

[daniellandau]

You might want to check that you have openssl installed, although I don't think this should be the symptom exactly then.

Does postnarketos nowadays ship with systemd? Or journald? If there's anything relevant looking in the normal system logs, that might be helpful

[Inderix]

When I installed PostMarketOS, I ended up with OpenRC, PmOS is currently transitioning from OpenRC to Systemd, and I'm not sure where they are in that process. Journald does not appear in my system either. PostmarketOS provides logread from busybox, but this showed nothing related to Gnome Shell. I checked dmesg as well just in case, but it turned up empty too.
I did notice that OpenSSL wasn't installed to my system, which I've now installed, as you said already, this didn't fix it, but it is one more thing confirmed at least.

[ferdnyc]

If you're not getting Mobile Settings, check that gjs is installed. It shouldn't be possible to install GNOME Shell without it, but apparently it can happen (#1513). Without the JavaScript engine, nothing works.

[Inderix]

I can confirm that gjs is installed correctly, however Mobile Settings still does not work.

[ferdnyc]

Hrm. And is the GSConnect daemon running? ps -ef |grep gjs should show a process running $HOME/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js, among (possibly) others.

If not, what happens if you start it manually? (gjs -m $HOME/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js) Does that bring GSConnect to life?

[ferdnyc]

(Fixed the path with my home directory in it, since that's unlikely to work for you.)

[ferdnyc]

Oh, and just to double-check, you DO NOT have kdeconnectd from KDE installed/running, right? It'll prevent GSConnect from functioning if it's also in use.

[Inderix]

I think you're onto something here!
Running ps -ef |grep gjs shows that GSConnect is not running.
Manually starting GSConnect at first gives no output, but doesn't exit to prompt. While this is happening, opening Mobile Settings in the GSConnect quick settings tile provides this output:
`/usr/bin/env: unrecognized option: S
BusyBox v1.37.0 (2024-12-14 19:59:50 UTC) multi-call binary.

Usage: env [-i0] [-u NAME]... [-] [NAME=VALUE]... [PROG ARGS]

Print current environment or run PROG after setting up environment

-, -i	Start with empty environment
-0	NUL terminated output
-u NAME	Remove variable from environment`

This looks to me that GSConnect isn't meshing well with BusyBox? I'm not sure enough to say that myself.

I can also confirm that KDE Connect is not installed or running. I don't have any KDE or even Qt applications installed on here

[Inderix]

Github broke the markdown but you get the gist of it

[ferdnyc]

`/usr/bin/env: unrecognized option: S

Aha! Yes. The problem is, then, that the first line of $HOME/.local/share/gnome-shell/extensions/[email protected]/service/daemon.js is:

#!/usr/bin/env -S gjs -m

...and BusyBox env apparently does not support the -S flag to env.

If you edit that to this:

#!/usr/bin/env gjs -m

...GSConnect should probably work better for you. Assuming BusyBox's env will interpret gjs -m as two separate arguments automatically.

...The overall solution to this, though, becomes tricky. On systems that need the -S flag, well, they NEED the -S flag. So it's not really workable to just remove it. I'll have to think on that.

[ferdnyc]

You'll also want to edit $HOME/.local/share/gnome-shell/extensions/[email protected]/gsconnect-preferences, and remove the -S from the first line of that file as well. That'll fix access to Mobile Settings.

The solution there, though, is clearer. Internally, we should stop trying to run that as an executable, and instead launch gjs -m <path_to_gsconnect-preferences> explicitly. We'll just have to take it on faith that gjs is in the $PATH, if we're running. (Or maybe there's some way to query the path for the current JavaScript engine executable, and use that path as the binary to launch. Like using ${CMAKE_COMMAND} in a CMake execute_process() call.)

[Inderix]

Making the adjustments in both daemon.js and gsconnect-preferences, gjs -m $HOME/.local/share/gnome-shell/extensions/gsconnect\@andyholmes.github.io/service/daemon.js now returns env: can't execute 'gjs -m': No such file or directory

[ferdnyc]

Crap. That means that BusyBox env doesn't support launching command lines at all.

Well, in that case, you can edit those shebangs to instead be:

#!/usr/bin/gjs -m

That avoids involving BusyBox at all. It assumes the location of gjs, but it's a safe assumption.

[ferdnyc]

(Or maybe there's some way to query the path for the current JavaScript engine executable, and use that path as the binary to launch. Like using ${CMAKE_COMMAND} in a CMake execute_process() call.)

For the record, that does not appear to be possible in Gjs currently! How annoying.

I've submitted a feature request.

[Inderix]

Awesome!
Thank you so much for the workaround, I'll poke around with it

[daniellandau]

I wouldn't mind hardcoding /usr/bin/gjs. IMO it's more important to support postmarketos out of the box than custom gjs interpreters in custom paths. The people who need that can do the necessary patching, e.g. I think nixos users already use gsconnect as packaged in nix?

[ferdnyc]

@daniellandau

I wouldn't mind hardcoding /usr/bin/gjs.

That may be the best option, ultimately. My feature request was marked as non-actionable; support for an equivalent to Node's process.execPath has apparently been stalled on a request for functionality in glib that's SO old, the issue number is GNOME/glib#31. (That makes it 19 years old, FTR.)

Meanwhile, I floated another hare-brained idea on GNOME's Discourse: That gjs revive Node's old half-hearted attempt to standardize an .mjs file extension to specifically indicate that a file is an ECMAScript module, and implicitly activate module support so that it doesn't need to have the -m flag on the command line.

If gjs myModule.mjs were equivalent to gjs -m myModule.js, then we could rename our files to .mjs, the shebangs wouldn't need the -m flag, and therefore wouldn't require the -S flag to use them with /usr/bin/env.

But that's gotten all of 10 views and no responses, so... not holding my breath.

[ferdnyc]

Now that I think about it, there is another option.

We already have code (in shell/utils.js) that runs on every extension startup and checks that the "runnable" JS files have their execute bits set. (Necessary because Github Actions strips execute bits from files it packages as build artifacts, for security reasons.)

If we were to include an additional simple "canary" script with a shebang line, like:

#!/usr/bin/env -S gjs -m

function main() {
    console.log("Success!");
    return;
}

main();

Then, after we've ensured that that file had its execute bit set, we can attempt to execute it using Gio.Subprocess.

• If it exits normally, we know that #!/usr/bin/env -S shebangs are supported on the current system.

• If it exits with an error, then we can safely assume the problem is with /usr/bin/env. (Or gjs is missing, but if that were the case we couldn't be running the code in shell/utils.js.)

So, if that check fails, the startup code could then take the additional step of rewriting the shebang lines for all the other (three) executable files so they use #!/usr/bin/gjs -m instead of #!/usr/bin/env -S.

(In fact, maybe it SHOULD fix the test script's shebang as well. That'll ensure the test succeeds on future startups (until GSConnect is updated). That way we can avoid wasting time at every startup, attempting to rewrite shebangs that have already been fixed.)

Fortunately we don't support Windows, where modifying files that are open in the current process (because you're running the code they contain) tends to break. On Linux it should be fine, though.

I don't relish writing a bare-bones JS implementation of sed, but... it's only the first 30 or so bytes of each file, and we have full control over the exact strings used so it's not like it has to do any fuzzy matching.