Fedora Atomic Workstation: Developer tools

Note: Fedora Atomic Workstation has recently been renamed to Team Silverblue. Learn more here.

A while ago, I wrote about using GNOME Builder for GTK+ work on my Fedora Atomic Workstation. I’ve done this with some success since then. I am using the nightly builds of GNOME Builder from the sdk.gnome.org flatpak repository, since I like to try the latest improvements.

As these things go, sometimes I hit a bug. Recently, I ran into a memory leak that caused GNOME Builder to crash and burn. This was happening just as I was trying to take some screenshots for a blog post. So, what to do?

I figured that I can go back to using the commandline, without giving up the flatpak environment that I’m used to now, by using flatpak-builder, which is a commandline tool to build flatpak applications. In my opinion, it should come out-of-the-box with the Atomic Workstation image, just like other container tools. But  that is not the case right now, so I used the convenient workaround of package layering:

$ rpm-ostree install flatpak-builder

flatpak-builder uses a json manifest that describes what and how to build. GTK+ is shipping manifests for the demo apps in its source tree already, for example this one:

https://gitlab.gnome.org/GNOME/gtk/blob/master/build-aux/flatpak/org.gtk.WidgetFactory.json

These manifests are used in the GNOME gitlab instance to build testable flatpaks for merge requests, as can be seen here:

https://gitlab.gnome.org/GNOME/gtk/-/jobs/24276/artifacts/browse

This is pretty amazing as a way to let interested parties (designers, translators, everybody) test suggested changes without having to go through a prolonged and painful build process of ever-changing dependencies (the jhbuild experience). You can read more about it in Carlos‘ and Jordan’s posts.

For me, it means that I can just use one of these manifests as input to flatpak-builder to build GTK+:

$ flatpak-builder build \
   build-aux/flatpak/org.gtk.WidgetFactory.json

This produces a local build in the build/ directory, and I can now run commands in a flatpak sandbox that is populated with the build results like this:

$ flatpak-builder --run build \
   build-aux/flatpak/org.gtk.WidgetFactory.json \
   gtk4-widget-factory

A few caveats are in order when you are using flatpak-builder for development:

flatpak-builder will complain if the build/ directory already exists, so for repeated building, you should add the –force-clean option.

The manifest we are using here is referring to the main GTK+ git repository, and will create a clean checkout from there, ignoring local changes in your checkout. To work around this, you can replace the https url pointing at the git repository by a file: url pointing at your checkout:

 "url": "file:///home/mclasen/Sources/gtk"

You still have to remember to create a local commit for all the changes you want to go into the build. I have suggested that flatpak-builder should support a different kind of source to make this a little easier.

Once you have the basic setup working, things should be familiar. You can get a shell in the build sandbox by using ‘sh’ as the command:

$ flatpak-builder --run build \
  build-aux/flatpak/org.gtk.WidgetFactory.json \
  sh

flatpak-builder knows to use the sdk as runtime when setting up the sandbox, so tools like gdb are available to you. And the sandbox has access to the display server, so you can run graphical apps without problems.

In the end, I got my screenshots of the font chooser, and this setup should keep me going until GNOME Builder is back on track.

A font update

At the end of march I spent a few days with the Inkscape team, who were so nice to come to the Red Hat Boston office for their hackfest. We discussed many things, from the GTK3 port of Inkscape, to SVG and CSS, but we also spent some time on one of my favorite topics: fonts.

Font Chooser

One thing Tav showed me which I was immediately envious of is the preview of OpenType features that Inkscape has in its font selector.

Clearly, we want something like that in the GTK+ font chooser as well. So, after coming back from the hackfest, I set out to see if I can get this implemented. This is how far I got so far, it is available in GTK+ master.

This really helps understanding which glyphs are affected by a font feature. I would like to add a preview for ligatures as well, but harfbuzz currently does not offer any API to get at the necessary information (understandably — its main focus is applying font features for shaping) and I’m not prepared to parse those font tables myself in GTK+. So, ligatures will have to wait a bit.

Another thing I would like to explore at some point is possible approaches for letting users apply font features to smaller fragments of text, like a headline or a single word. This could be a ‘font tweak’ dialog or panel. If you have suggestions or ideas for this, I’d love to hear them.

At the request of the Inkscape folks, I’ve also explored a backport of the new font chooser capabilities to the 3.22 branch, but since this involves new API, we’re not sure yet which way to go with this.

Font Browser

While doing font work it is always good to have a supply of featureful fonts, so I end up browing the Google web fonts quite a bit.

Recently, I stumbled over a nice-looking desktop app for doing so, but alas, it wasn’t available as a package, and it is written in rust, which I know very little about (I’m hoping to change that soon, but that’s a topic for another post).

But I’ve mentioned this app on #flatpak, and just a few days later, it appeared on flathub, and thus also in GNOME software on my system, just a click away. So nice of the flathub team!

The new flathub website is awesome, btw. Go check it out.

The best part is that this nice little app is now available not just on my bleeding-edge Fedora Atomic Workstation, but also on Ubuntu, Gentoo and even RHEL, thanks to flatpak.  Something we could only dream of a few years ago.

 

Fedora Atomic Workstation: Beta

Note: Fedora Atomic Workstation has recently been renamed to Team Silverblue. Learn more here.

The Beta release of Fedora 28 is out, and it contains the usual assortment of good stuff:

  • better battery life
  • Thunderbolt support
  • guest additions  make Fedora work better in VirtualBox
  • the latest GNOME release brings polish and new applications
  • updated versions of tons of popular software

The announcement was highlighting all the ways in which you can try it out: there are isos for Workstation, Server and Atomic Host. One thing it forgot to point out is that you can also try Fedora 28 Beta in the form of the Atomic Workstation.

How do you get it ?

To install Fedora Atomic Workstation from scratch, use this iso:

https://download.fedoraproject.org/pub/fedora/linux/releases/test/28_Beta/AtomicWorkstation/x86_64/iso/Fedora-AtomicWorkstation-ostree-x86_64-28_Beta-1.3.iso

If you already have an Atomic Workstation installation of Fedora 27, you can jump to Fedora 28 Beta with the rpm-ostree rebase command:

# rpm-ostree rebase atomic:fedora/28/x86_64/workstation

This assumes you have already an ostree remote pointing at the Fedora atomic repository. If not, this command creates one:

# ostree remote add --set=gpgkeypath=/etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-28-primary atomic https://kojipkgs.fedoraproject.org/atomic/repo
Whats new ?

Besides all the general Fedora 28 news, there are some improvements that are specific to the Atomic Workstation.

The version of GNOME software that is included in the Beta is now able to update the OS image. This is an outcome of our effort to close the feature gaps between the traditional and Atomic Workstation variants. I hope we can close a few more before Fedora 28 is released.

Where to learn more ?

The Project Atomic website has lots of useful information about Atomic and related technologies, such as this Introduction to Atomic Workstation.

And the #atomic irc channel on freenode is a good place to get answers to Atomic Workstation questions. Feel free to come by!

Update: Don’t forget that a fresh Atomic Workstation installation currently comes without any pre-configured flatpak remotes. You need to add one before GNOME Software can show you flatpak apps. The flathub remote can be added by clicking on this link:

https://flathub.org/repo/flathub.flatpakrepo

 

Fedora Atomic Workstation: Almost fool-proof

Note: Fedora Atomic Workstation has recently been renamed to Team Silverblue. Learn more here.

I’ve had a little adventure with my Fedora Atomic Workstation this morning and almost missed a meeting because I couldn’t get to a desktop session.
I’ve been using the rawhide branch of Fedora Atomic Workstation to keep up to speed with the latest developments in Fedora. As is expected of rawhide,  recently, it would not get me to a login screen (much less a working desktop session). I’ve just booted back into my working image and ignored this for a few days.

The Adventure begins

But since it didn’t go away by itself, yesterday, I decided to see if I can debug it a bit. Looking at the journal for the last unsuccessful boot gave some hints:

gnome-shell[2934]: Failed to create backend: Failed to initialize renderer: Missing extension for GBM renderer: EGL_KHR_platform_gbm
gnome-session-binary[2920]: WARNING: App 'org.gnome.Shell.desktop' exited with code 1
gnome-session-binary[2920]: Unrecoverable failure in required component org.gnome.Shell.desktop

Poking the nearest graphics team member about this, I was asked to provide the output of eglinfo in this situation. Since I had an hour to spare before the meeting, I booted back into the broken image in runlevel 3, logged in on a vt, … and found that eglinfo is not in the OS image.

Well, thats easy enough to fix on an Atomic system, using package layering:

rpm-ostree install egl-utils

After that, I proceeded to reboot to get to the OS image with the newly added layer, and when I got to the boot prompt, I realized my mistake: rpm-ostree never replaces the booted image, since it (reasonably) assumes that the booted image is ‘working’.  But it only keeps two images around, so it had to replace the other one – which was the image which successfully boots to my desktop.

Now, at the boot prompt, I was faced with the choice between

  • the broken image
  • the broken image + egl-utils

Ugh. Not what I had hoped for. And my meeting starts in 50 minutes. Admittedly, this was entirely my fault. rpm-ostree behaved as it should and as documented. Since it is a snow day, I need to do the meeting from home and need a web browser for that.

So, what can be done? I remembered that ostree is ‘like git for binaries’, so there should be history, right? After some fiddling with the ostree commandline, I found the log command that shows me the history of my local repository. But sadly, the output was disappointing:

$ ostree log fedora/rawhide/x86_64/workstation
commit fa09fd6d2551a501bcd3670c84123a22e4c704ac30d9cb421fa76821716d8c20
ContentChecksum: 74ff34ccf6cc4b7554d6a8bb09591a42f489388ba986102f6726f9e662b06fcb
Date: 2018-03-20 10:27:42 +0000
Version: Rawhide.20180320.n.0
(no subject)

<< History beyond this commit not fetched >>

rpm-ostree defaults to only keeping the latest commit in the local repository, a bit like a shallow git clone. Thankfully, just like git, ostree is versatile, and bit more searching brought me to the pull command, and its –depth option:

# ostree pull --depth=5 onerepo fedora/rawhide/x86_64/workstation

Receiving metadata objects: 698/(estimating) 2.2 MB/s 23.7 MB

This command writes to the local repo in /sysroot/ostree/repo and thus needs to be run as root.

Now ostree log showed a few older commits. I had to bump the depth a few times to find the last working commit. Then, I made that commit available for booting into again, using the depoy command:

# ostree admin deploy 76723f34b8591434fd9ec0

where that hex string is a prefix of the commit ID of the last working commit.  This command also needs to be run as root.

Now a quick reboot, and… the boot loader menu had an entry for the working image again. I made it back to my desktop with 5 minutes to spare before the meeting. Phew!Update: Since you might be wondering, the output of eglinfo was:

eglinfo: eglInitialize failed

Fedora Atomic Workstation: Ruling the commandline

Note: Fedora Atomic Workstation has recently been renamed to Team Silverblue. Learn more here.

In my recent posts, I’ve mostly focused on finding my way around with GNOME Builder and using it to do development in Flatpak sandboxes. But I am not really the easiest target audience for an IDE like GNOME Builder, having spent most of my life on the commandline with tools like vim and make.

So, what about the commandline in an Atomic Workstation environment? There are many container tools, like buildah, atomic, oc, podman, and so on. I am not going to talk about these, since I don’t know them very well, and they are covered, e.g. on www.projectatomic.io.

But there are a few commands that are essential to life on the Atomic Workstation: rpm-ostree and flatpak.

rpm-ostree

First of all, there’s rpm-ostree, which is the commandline frontend to the rpm-ostreed daemon that manages the OS image(s) on the Atomic Workstation.

You can run

rpm-ostree status

to get some information about your OS image (and the other images that may be present on your system). And you can run

rpm-ostree upgrade

to get the latest update for your OS image (the terminology clash here is a bit unfortunate; rpm-ostree calls an upgrade what most Linux distros and packaging tools call an update).

You can run this command as normal user in a terminal, and rpm-ostreed will present you with a polkit dialog to do its privileged operations. Recently, rpm-ostreed has also gained the ability to check for and deploy upgrades automatically.

An important thing to keep in mind is that rpm-ostree never changes your running system. You have to reboot into the new image to see the changes, so

systemctl reboot

should be in your repertoire of commands as well. Alternatively, you can use the –reboot option to tell rpm-ostree to reboot when the upgrade command completes.

flatpak

The other essential command is flatpak. Where rpm-ostree controls your OS image, flatpak rules the applications. flatpak has many commands that are worth exploring, I’ll only mention the most important ones here.

It is quite common to have more than one source for flatpaks enabled.

flatpak remotes

lists them all. If you want to find applications, then

flatpak search

will do that for you, and

flatpak install

will let you install what you found. An important detail to point out here is that applications can be installed in system-wide (in /var) or per-user (in ~/.local/share). You can choose the location with the –user and  –system options. If you choose to install system-wide, you will get a polkit prompt, since this is a privileged operation.

After installing applications, you should keep them up-to-date by installing updates. The most straightforward way to so is to just run

flatpak update

which will install available updates for all applications. To just check if updates are available, you can use

flatpak remote-ls --updates
Launching applications

Probably the most important thing you will want to do with flatpak is to run applications. Unsurprisingly, the command to do so is called run, and it expects you to specify the unique application ID:

flatpak run org.gnome.gitg

This is certainly a departure from the traditional commandline, and could be considered cumbersome (even though it has bash completion for the application ID).

Thankfully, flatpak has recently gained a way to recover the familiar interface. It now installs shell wrappers for the flatpak run command in ~/.local/share/flatpak/bin. After adding that directory to your PATH, you can run gitg like this:

org.gnome.gitg

If (like me), you are still not satisfied with this, you can add a shell alias to get the traditional command name back:

PATH=$PATH:$HOME/.local/share/flatpak/bin
alias gitg=org.gnome.gitg

Now gitg works again, as it used to. Nice!

 

Fedora Atomic Workstation: Trying things out the easy way

Note: Fedora Atomic Workstation has recently been renamed to Team Silverblue. Learn more here.

If you’ve followed my posts about my first steps with Fedora Atomic Workstation, you may have seen that I’ve had to figure out how to make codecs work in the firefox that is included in the OS image. And then I had to work around some issues with the layered packages that I used for that when I rebased to a newer OS.

But maybe there is a better way to go about this?

Flatpak is the preferred way to install applications on the Atomic Workstation, so maybe that is the way to go. So far, all the flatpaks I’ve installed have come from Flathub, which is a convenient place to find all sorts of desktop apps. But firefox is not there (yet).

Thankfully, flatpak is fundamentally decentralized by design. There is nothing special about Flathub, flatpak can easily install apps from many different sources. A quick search yielded this unofficial firefox flatpak repository, with easy-to-follow instructions. Just clicking on this link will also work. If you open it with a sandboxed firefox, you will see the URI portal in action:

One nice aspect of this is that the nightly firefox is not just a one-off package that I’ve installed, it will receive updates just like any other app on my system. An important detail when it comes to web browsers!

Another nice aspect is that I did not have to remove the firefox that is already installed (I couldn’t anyway, since it is part of the immutable OS image). The two can peacefully coexist.

This is true not just for firefox, but in general: by isolating apps and their dependencies from each other, flatpak makes it very easy to try out different versions of apps without pain.

Want to try some bleeding-edge GNOME apps instead of the stable versions that are available on Flathub? No problem,  just enable the GNOME nightly repository like this:

flatpak remote-add --user --from gnome-apps-nightly https://sdk.gnome.org/gnome-apps-nightly.flatpakrepo

And then the nightly apps will be available for installation next to their stable counterparts. Note that GNOME software will indicate the source for each app in the search results.

Trying out new software has never been safer and easier!

Sorry for the wrong-colored screenshots in this post – there is still a price to pay for living on the bleeding edge of rawhide, even if Atomic Workstation makes it much safer.

Recipes hackfest, day 1

It has been a bit quiet around GNOME recipes recently, since most of us have other obligations. But this is about to change; we’re currently having a hackfest about GNOME recipes in Jogyakarta, Indonesia, and we’ve already made some interesting plans for for future work in this app.

The hackfest takes place at the AMIKOM university in Jogyakarta.

Outreach

Before the event started, we had an outreach day where our group met some of the students and talked to them about GNOME and what we do. I was unfortunately not able to make it in time for that part, but I hear that it was a good day.

Review

The hackfest itself started on Wednesday. We collected a list of goals and tasks, and started the day with a walkthrough/review of both GNOME recipes and the Endless cooking app.

Storage

A good part of the first day was spent discussing the storage layer of recipes. What we have now is very home-grown and primitive. I was hoping for somebody to show up and write a proper storage layer for me. That hasn’t happened …until now.

The outcome of our discussion is a plan to use the technologies from the Endless knowledge libs to store recipes and other data. Some adaptations will be necessary since most Endless knowledge apps are basically readonly, in contrast to GNOME recipes, which has a strong focus on creating and editing recipes. But we have a fairly concrete plan for what needs to happen.

And to not lose the momentum, we’ve set ourselves a goal to present on this at Guadec. No pressure!

Contributions

The other big topic we tackled on the first day is encouraging more recipe contributions. We had a good start last year, when we collected around 60 recipes, but it would be good to have some more. We’ve come up with several ideas for this.

Local recipes

One idea is that we will start accepting recipes in languages other than English, since translating a recipe into English is a big extra hurdle that makes contributing harder.

There were several fascinating tangents in this discussion. One thing we discussed at some length is the challenges of translating recipes. To do a good job at that takes a lot more effort than just translating the words; you may have to substitute ingredients for what is available in other parts of the world, and find out about local variations of ingredients, and so on. And to add an extra twist to this, the translation here will go from a local language to English, which is the opposite of what our translation teams normally do.

The exact form that this will take is not quite decided yet. We may end up introducing a concept like “recipe packs”, say: “Indonesian recipes”, and those might only be available in a local language.

A contest

Another idea for contributions is to have a contest for contributing recipes. The details will have to be worked out, but the prizes could include a prominent spot in the ‘featured chefs’ section, or having your recipe featured on the front page.

Cook it!

We can do a contest online, but since this is about cooking and food, it might also be very nice to do this as a local get-together. This could not only include entering recipes together, but also cooking them, taking photos, and eating them. We will try this idea in one or two locations.

A hackfest for food – maybe that’s a cookfest ?

We ended this very productive first day with a very pleasant dinner.  On to day 2!

 

Fedora Atomic Workstation on the road

Note: Fedora Atomic Workstation has recently been renamed to Team Silverblue. Learn more here.

I am currently travelling with my laptop, after I’ve recently switched it to Fedora Atomic Workstation and then rebased to rawhide.

While I am sitting by the pool, I have some time to ponder: how has it been going ?

I have upgraded to a newer image a few times now, and I won’t lie: rawhide is still rawhide. Sometimes, the new image was a disappointment and would not give me a working system. In one case, it hung before getting to the login screen. The typical rawhide experience.

In the past, hitting such a bad compose meant a painful struggle to recover: Boot into single user-mode, do some live debugging, try to find a few problematic packages to downgrade, work around breakage, etc. You end up with a half-working system in a mixed state, and hope that the next update will get you back on track.

An ostree-based system like Fedora Atomic Workstation makes the recovery painless. In the case I mentioned, I simply rebooted, selected my previous, working image from the grub menu, and was back to a working system in 3 minutes. No time lost.

The tree that didn’t work is still present on my system. If I wanted, I could make changes to it in an attempt to understand and fix the problem and try booting it again. Having both trees on the system is useful even if I just want to report the problem, since rpm-ostree can tell me what exactly changed between the working and the broken tree:

$rpm-ostree db diff d15a65950972 21ac24694b6e
ostree diff commit old: d15a65950972
ostree diff commit new: 21ac24694b6e
Upgraded:
 apr 1.6.3-5.fc28 -> 1.6.3-6.fc29
 atomic 1.21.1-1.fc28 -> 1.22.1-1.fc29
 ...
Removed:
 NetworkManager-glib-1:1.10.2-1.fc28.x86_64
 libnm-gtk-1.8.10-2.fc28.2.x86_64
 ...
Added:
 authselect-0.3-3.fc29.x86_64
 authselect-libs-0.3-3.fc29.x86_64
 ...

(I found the checksums to pass to rpm-ostree db diff by looking for the Commit fields in the output of rpm-ostree status)

Or I can simply wait for the next compose to see if rawhide ‘fixed itself’. Even if it takes more than one compose before things get back to working, this is a safe thing to do: ostree will never replace the current image that I am booted into. This makes it entirely safe to try newer composes until I find one that works for me.

It would of course be nice if broken composes never made it to my system. The current efforts at ‘gating’ updates in Fedora should get us to a place where we detect non-booting composes before they get sent out to users. But even in this (hopefully not too distant) future, the easy rollback with Atomic Workstation provides a useful safety net.

Automated QA will never be able to detect every problem that could affect my workflow. Maybe the system boots fine, but frequently loses network connections, or maybe it can’t handle my dual-monitor setup, or something else… I may only discover the problem hours later. But up until I run rpm-ostree upgrade again, I can just reboot back into my previous image.

ostree provides fearless upgrades.

Just right for the poolside.

Fedora Atomic Workstation: Works on the beach

Note: Fedora Atomic Workstation has recently been renamed to Team Silverblue. Learn more here.

My trip is getting really close, so I decided to upgrade my system to rawhide. Wait, what ? That is usually what everybody would tell you not to do. Rawhide has this reputation for frequent breakage, and who knows if my apps will work any given day. Not something you want to deal with while traveling.

Image result for project atomic logo

With rpm-ostree, installing a newer OS is very similar to updating your current OS: a new image is downloaded in the background, and when the download is complete, you boot into the new image. The previous image is still available to boot back into, as a safety net.  That is the reason that I felt confident enough to try this a day before a major trip:

rpm-ostree rebase \
   fedora-ws-rawhide:fedora/rawhide/x86_64/workstation
systemctl reboot

I would love to say that things went perfectly and I was back to a working system in 10 minutes. But it was not quite as easy, and i did encounter a few (solvable) problems. It is worth pointing out that while I was solving these problems, rpm-ostree had already downloaded all of the rawhide image, but I was still safely running my F27 OS. At no point was there a mess of a half-upgraded system with a mix of old and new rpms. I was running my old system until I had solved all the problems and had a OS image that was ready, and then I booted into it. A safe, atomic switch.

Problem 1: The rpmfusion repo is not available for f28 yet. It is a common occurrence that 3rd party repositories lag behind the Fedora releases a bit, so this is not surprising. It is a bit unfortunate that i had to remove my layered rpms from the repository to work around this.

Problem 2: buildah now in the base image. This is a good thing, of course, but it caused rpm-ostree to complain about the conflict between the OS image and the layered package. In this case, I removed the layered rpm without any qualms.

Problem 3: Rawhide repositories had a bad day. For some reason,  they were missing the repomd.xml file today.

This is a good reminder that as long as you are using package layering, you haven’t really left the world of yum repositories and out-of-sync mirrors behind. rpm-ostree has to check the yum repositories for updates to the layered packages, which means that it can be hit by the same issues as dnf on a traditional Fedora workstation.

For my rebase to proceed,  I had to remove everything that was layered on top of the OS image. After I did that, rpm-ostree no longer needed to look at yum repositories, and switched my system to the already-downloaded rawhide image.

After the reboot, I’m now running rawhide… and all my applications are just the same as they were before. A nice aspect of the Atomic Workstation approach is that (flatpak) applications are decoupled from the OS. I can update the one without the other. We are not entirely there yet: as you can see in the screenshot below, a number of applications are still installed as part of the OS image.

More importantly, the screenshot shows that GNOME software will support updating the OS on the Atomic Workstation in Fedora 28. It does so by talking to the rpm-ostree daemon.

Switching from one Fedora release to the next ls already working pretty well in the last few releases. With the Atomic Workstation, it can become as undramatic as installing the latest updates.

One could almost do it on the beach.

Fedora Atomic Workstation for development

Note: Fedora Atomic Workstation has recently been renamed to Team Silverblue. Learn more here.

I’m frequently building GTK+.  Since I am using Fedora Atomic Workstation now, i have to figure out how to do GTK+ development in this new environment. GTK+ may be a good example for the big middle ground of things that are not desktop applications, but also not part of the OS itself.

Image result for project atomic logo

Last week I figured out how to use a buildah container to build release tarballs for GNOME modules, and I actually used that setup to produce a GTK+ release as well.

But for fixing bugs and other development, I generally need to run test cases and demo apps, like the venerable gtk-demo. Running these outside the container does not work, since the GTK+ libraries I built are linked against libraries that are installed inside the container and not present on the host, such as libvulkan. I could of course resort to package layering to install them on the host, but that would miss the point of using Atomic Workstation.

The alternative is running the demo apps inside the container, which should work – its the same filesystem that they were built in. But they can’t talk to the compositor, since the Wayland socket is on the outside: /run/user/1000/wayland-0. I tried to work around this by making the socket visible in the container, but my knowledge of container tools and buildah is too limited to make it work. My apps still complain about not being able to open a display connection.

What now ? I decided that while GTK+ is not a desktop application, I can treat my test apps like one and write a flatpak manifest for them. This way, I can use GNOME builders awesome flatpak support to build and run them, like I already did for  GNOME recipes.

Here is a minimal  flatpak manifest that works:

{
  "id" : "org.gtk.gtk-demo",
  "runtime" : "org.gnome.Sdk",
  "runtime-version" : "master",
  "sdk" : "org.gnome.Sdk",
  "command" : "gtk4-demo",
  "finish-args" : [
    "--socket=wayland"
  ],
  "modules" : [
   {
     "name" : "graphene",
     "buildsystem" : "meson",
     "builddir" : true,
     "sources" : [
       {
         "type" : "git",
         "url" : "https://github.com/ebassi/graphene.git"
       }
     ]
   },
   {
     "name" : "gtk+",
     "buildsystem" : "meson",
     "builddir" : true,
     "sources" : [
       {
         "type" : "git",
         "url" : "https://gitlab.gnome.org/GNOME/gtk.git"
       }
     ]
   }
 ]
}

After placing this json file into the toplevel directory of my  GTK+ checkout, it appears as a new build configuration in GNOME builder:

If you look closely, you’ll notice that I added another manifest, for gtk4-widget-factory. You can have multiple manifests in your tree, and GNOME builder will let you switch between them in the Build Preferences.

After all this preparation, I can now hit the play button and have my demo app run right from inside GNOME builder. Note that the application is running inside a flatpak sandbox, using the runtime that was specified in the Build Preferences, so it is cleanly separated from the OS. And I can easily build and run against different runtimes, to test compatibility with older GNOME releases.

This may be the final push that makes me switch to GNOME Builder for day-to-day development on Fedora Atomic Workstation: It just works!

css.php