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.