JHBuild on Silverblue

Project Discussion
1

Has anybody figured a way to use jhbuild on Silverblue? While most of the development can be done with Builder+Flatpak or in fedora-toolbox, there are still a few areas where jhbuild is stiill pretty much required, such as contributing to gnome-shell and mutter.

So, is there currently a way to use jhbuild to build, and, importantly, run if not the whole GNOME session, then at least gnome-shell?

2

Maybe try the fedora-toolbox, it is a pet container that you can install with rpm-ostree install fedora-toolbox. My bad, I didn’t read correctly. Please disregard my comment in that case. Nothing to see here, move along. But after reading here https://media.readthedocs.org/pdf/builder/latest/builder.pdf. Why couldn’t you use the fedora-toolbox pet container?

3

I can build via jhbuild in toolbox, true. However, I don’t think I can run the full session there.

4

You should be able to install gnome-builder as per normal for using dnf then execute with gnome-builder. If jhbuilder needs to run in the same session you could use something like podman ps to see the id of your fedora-toolbox container then podman attach <ID> to attach to the running container. Maybe add --run gnome-builder to the attach command.

5

gnome-builder is available as Flatpak, but that’s irrelevant here, because it cannot be used for this particular case and I have to use jhbuild.

6

Okay, I understand Builder is available as a Flatpak. I jumped to an erronius conclusion as to why you needed jhbuild.

7

You should be able to, fedora-toolbox runs as a fully privileged container.

8

Running jhbuild run gnome-shell --replace in an existing session doesn’t seem to work, shell just crashes without outputting anything (haven’t looked at journal yet). As doesn’t just gnome-shell --replace in toolbox. I’ll look into running the whole session later, maybe that’ll work.

Edit: Can I somehow start toolbox from a GDM session file?

9

Ah, yeah that probably won’t work… I was more thinking of running the shell windowed in its own dbus session.

10

I’d use a nested session, but I need smooth scrolling and touchpad gestures to work (so Wayland, so even --replace won’t be enough) and at the same time not to conflict with the system ones, so I need gnome-shell in the actual session. :confused:

VMs won’t do it for the same reason.

11

What sort of development/testing do want to do with jhbuild? Knowing that might give people more ideas to suggest a workflow that works with Silverblue.

I would expect that gnome-shell --replace from within the toolbox shouldn’t be too hard to get working, but as you say, that doesn’t work with Wayland - which is the primary target of gnome-shell these days.

For developing with with true system components - the kernel, gnome-shell, Network Manager, etc - then the workflow needs to involve a VM or second machine.There’s no way of having a reasonable cycle time if you have to reboot your machine. I have a lot of ideas about how we could come up with a nice second machine or VM workflow - If someone is interested in working on that, I’d be happy to help figure out a direction - but not much practical to offer at this point.

Without a VM, some combination of ‘rpm-ostree usroverlay’, compiling in a container, syncing over /usr, and login/logout cycles is probably your best bet, but isn’t going to be a lot of fun.

12

For now finishing Add transparent panel adapting to background image characteristics (!404) · Merge requests · GNOME / gnome-shell · GitLab (can be done in a VM) and fixing "Stick-to-finger" gesture behavior (#516) · Issues · GNOME / gnome-shell · GitLab (not only a VM wouldn’t work because it wouldn’t pass neither smooth scrolling nor swipe events, but the swipe events require a Wayland session, so gnome-shell --replace won’t suffice either. Second machine wouldn’t work either, while I have another laptop, touchpad is dead there + it wasn’t multitouch to begin with)

So yeah, it’s probably rpm-ostree usroverlay and syncing stuff from container. I did that previously, but it wasn’t a good setup :confused:

The farthest I got with jhbuild in toolbox is to successfully run gtk3-demo, but it can be done with Builder+Flatpak anyway.

13

Apple Magic Trackpad + usb bluetooth adapter + usb pasthrough? :confused:

14

That could actually be a good option, though not completely sure it would work. I don’t have an external touchpad though :slight_smile:

15

I haven’t looked at what gnome-shell --replace involves, but you can already hack on random D-Bus services running on the user bus inside the toolbox.

Given that $HOME is shared between the host and the toolbox, I can imagine hacking up the host to look at the same development prefix as the toolbox, and then do the actual spawning of the binary from the host. Certainly it would be nice not to have to hack up the host, though. :slight_smile:

16

gnome-shell --replace isn’t really even enough, because Wayland :slight_smile:

17

Sorry for reviving an old thread, recent convert here :blush:

It already works. Not as well as with “regular” Fedora - main issue is that only apps available inside the toolbox are visible - but good enough for (non-wayland) testing.

Mmh, given that gnome-shell is a bit less system-ey (runs in the user session), what do you think the chances are of getting it to work?

On non-Silverblue, the following works (on a tty):

$ XDG_SESSION_TYPE=wayland dbus-run-session jhbuild run gnome-session
$ # or "dbus-run-session jhbuild run gnome-shell --wayland"

But it fails in a toolbox because it cannot communicate with systemd/logind:

$ dbus-run-session jhbuild run gnome-shell --wayland --display-server  

(gnome-shell:14806): mutter-WARNING **: 17:39:41.783: Can't initialize KMS backend: Could not get session ID: User 1000 has no sessions 

$ loginctl list-sessions
System has not been booted with systemd as init system (PID 1). Can't operate.
Failed to create bus connection: Host is down

I don’t know how hard it would be to allow that, nor whether this is the problem that prevents it from working or merely the first of many obstacles.

18

From a security point of view, the toolbox’ed environment can do anything that the users normal session can (if nothing else, by running ‘flatpak-spawn --host’) - so if we’re not already passing in access to the system bus, we can certainly do that.

Problems might be:

  • If anything expects shared filesystems on both sides of the system bus (e.g., passing filenames over the system bus)
  • If user namespaces confuse tracking that logind / systemd / d-bus are trying to do
  • If the gnome-shell you are trying to run needs a newer version of a system component

I’m wondering - on non-Silverblue do you have luck running a new session in parallel to your main session? That didn’t used to work very well.

Owen

19

That appears to be working already:

$ gdbus call --system --dest org.freedesktop.login1 \
                                    --object-path /org/freedesktop/login1 \
                                   --method org.freedesktop.login1.Manager.ListSessions 
([('4', uint32 1000, 'fmuellner', 'seat0', objectpath '/org/freedesktop/login1/session/_34'), ('2', 1000, 'fmuellner', 'seat0', '/org/freedesktop/login1/session/_32')],)

But it looks like libsystemd tries to directly access /run/systemd/* instead, and fails:

$ jhbuild run strace mutter --wayland
[...]
getuid()                                = 1000
openat(AT_FDCWD, "/run/systemd/users/1000", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
getuid()                                = 1000
openat(AT_FDCWD, "/run/systemd/users/1000", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
getuid()                                = 1000
getpeername(2, 0x7fff455ce4c0, [128])   = -1 ENOTSOCK (Socket operation on non-socket)
futex(0x7f351d2c5fc8, FUTEX_WAKE_PRIVATE, 2147483647) = 0
ioctl(2, TCGETS, {B38400 opost isig icanon echo ...}) = 0
getpid()                                = 23655
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=118, ...}) = 0
write(2, "\n(mutter:23655): mutter-\33[1;33mW"..., 153
(mutter:23655): mutter-WARNING **: 19:02:23.741: Can't initialize KMS backend: Could not get session ID: User 1000 has no sessions

(Similar issue with loginctl, it’s /run/systemd/system in that case)

Right, but that has always been an issue, and I wouldn’t expect Silverblue to somehow magically fix that.

Yes, it works reasonably well for me. But then those sessions are very transient, it’s launching them, testing some shell stuff and logging out. I rarely run any applications at all there, so there’s not too much state that is in risk of getting messed up.

20

I don’t immediately think it would make sense to always bind mount those in, but I think there’s a general sense that we want to support ‘toolbox create’ with custom arguments - see https://github.com/debarshiray/toolbox/pull/100 - I don’t think we know yet whether that’s:

  • An environment variable as in that PR
  • Extra arguments to toolbox create - toolbox create --volume /run/systemd:/run/systemd
  • A generic passthrough to podman create toolbox create -- --volume /run/systemd:/run/systemd
  • The ability to specify arguments in image labels, ‘atomic run’ style - LABEL com.github.debarshiray.toolbox.args ...

I’d trying hacking the toolbox script (you can run it directly from a git checkout) to mount in the relevant directories and see how far you get - and report the results in the above PR :slight_smile:

The two-system (VM or physical system) approach does fix that, which is why I think that’s a better long term approach, but if we can get this working in the short term, even better!

1 Like