Hello! I’m working on an interesting project this month, related to open source Linux operating systems. Actually I’m not working on it this week, I’m instead battling with vinyl floor tiles. Don’t let anyone tell you they are easy to fit. But I think on the 5th attempt I’ve got the technique. The wooden mallet is essential.

When I started these “status update” posts, back in 2021 , I imagined they’d be to talk about open technology projects I was working on, mixed with a bit of music and art and so on. In fact I write more about politics these days. Let me explain why.

In my book review earlier this year I mentioned economics dude Gary Stevenson. I still didn’t read his book but I do watch all his videos now and I’m learning a lot.

I learned a bit about the housing crisis, for example. The housing crisis in Manchester had several major effects on my life. I just read today in The Manchester Mill that the average rent in Salford jumped from £640/mo to £1,121/mo in a decade.

(Lucky for me, I got into computers early in life, and nobody understands their secrets so they still have to pay a good salary to those of us who do. So far I’ve weathered the crisis. Many of my friends don’t have that luck, and some of them have been struggling for 15 years already. Some even had to become project managers .)

Until about 2020, I assumed the Manchester housing crisis was caused by people moving up from London. Galicia had some cheap ass rents when I arrived and it’s only around 2021, when they started suddenly doubling just as I’d seen happen in Manchester, that I realised the same crisis was about to play out here as well, and perhaps it wasn’t entirely the fault of Gen-X Londoners. I thought, maybe it’s a Europe-wide housing crisis?

Let me summarize the video Gary Stevenson did about the housing crisis ( this one ), to save you 28 minutes. It’s not just houses but all types of asset which are rapidly going up in price, and it’s happening worldwide. We notice the houses because we need them to live normal lives, unlike other types of asset such as gold or government bonds which most of us can live without.

The most recent video is titled like this: “Is the economy causing a mental health crisis? “. I’ve embedded it below. ( It’s hosted on a platform controlled by Google, but Gary is good enough to turn off the worst of the YouTube ads, those bastards that pop up during a video in mid-sentence or while you’re figuring out a yoga pose .)

My answer to that question, when I saw it, was “ Yes, obviously “. For example, if rent increases by 75% in your city and you’re forced back into living with your parents age 35, it’s tough to deal with alright. What do you think?

But the video is about more than that. The reason asset prices are through the roof is because the super rich are taking all the assets . The 1% have more money than ever. Wealth inequality is rapidly rising, and nothing is stopping it. For thousands of years, the aristocracy owned all the land and castles and manor houses, and the rest of us had a few cabbages and, perhaps if you were middle class, a pig.

The second half of the 20th century levelled the playing field and put in place systems which evened things out and meant your grandparents maybe could buy a house. The people in charge of those systems have given up, or have been overpowered by the super rich.

In fact, the video “Is the economy causing a mental health crisis?” is about the effect on your mental health when you realize that all of society as you know it is headed towards complete collapse.

(Lucky for me, I grew up thinking society was headed for collapse due to the climate crisis, so I listened to a lot of punk rock and over-developed my capacity for nihilism. Maybe my mind looks for crises everywhere? Or maybe I was born in a time well-supplied with global crises. I share a birthday with the Chernobyl disaster.)

So how does all this relate back to open technology?

Maybe it doesn’t. I went to the GNOME conference last month and had very little overtly “political” conversations. We chatted about GNOME OS, live-streaming, openQA, the GNOME Foundation, the history of the GNOME project, accessibility at conferences, our jobs, and so on. Which was great, I for some reason find all that stuff mega interesting. (Hence why I went there instead of a conference about 21st century world politics).

Or maybe it does. Tech is part of everyone’s lives now. Some of the most powerful organizations in the world now are tech companies and they get their power from being omnipresent. Software engineers built all of this. What were we thinking?

I think we just enjoyed getting paid to work on fun problems. I suppose none of today’s tech billionaires seemed like particularly evil-minded people in the mid 2000s. Spotify used to talk about reducing MP3 piracy, not gutting the income streams of 95% of professional recording artists. Google used to have a now laughable policy of “Don’t be evil”.

There is one exception who were clearly evil bastards in the 2000s as well. The US anti-trust case against Microsoft, settled in 2001, is an evidence trail of lies and anti-competitive behaviour under Bill Gates’ leadership. Perhaps in an attempt to one-up his predecessor, the Satya Nadella Microsoft is now helping the far-right government of Israel to commit war crimes every day. No Azure for Apartheid . At least they are consistent, I suppose.

In fact, I first got interested in Linux due to Microsoft. Initially for selfish reasons. I was a child with a dialup internet connection, and I just wanted to have 5 browser windows open without the OS crashing. (For younger readers — browser tabs weren’t invented until the 21st century).

Something has kept me interested in open operating systems, even in this modern era when you can download an MP3 in 5 seconds instead of 5 consecutive evenings. It’s partly the community of fun people around Linux. It’s partly that it led me to the job that has seen me through the housing crisis so far. And its partly the sense that we are the alternative to Big Tech.

Open source isn’t going to “take over the world”. That’s what Microsoft, Spotify and Google were always going to do (and have now done). I’m honestly not sure where open source is going. Linux will go wherever hardware manufacturers force it to go, as it always has done.

GNOME may or may not make it mainstream one day. I’m all for it, if it means some funding for localsearch maintainers. If it doesn’t, that’s also fine, and we don’t need to be part of some coherent plan to save the world or to achieve a particular political aim. Nothing goes according to plan anyway. Its fine to work on stuff just cus its interesting.

What we are doing is leading by example, showing that its possible to develop high quality software independently of any single corporation. You can create institutions where contributors do what we think is right, instead of doing what lunatics like Sam Altman or Mark Zockerborg think.

At the same time, everything is political.

What would happen if I travelled back to 2008 and asked the PHP developers building Facebook: “Do you think this thing could play a determining role in a genocide in Myanmar?”

I met someone this weekend who had just quit Spotify. She isn’t a tech person. She didn’t even know Bandcamp exists. Just didn’t want to give more money to a company that’s clearly evil. This is the future of tech, if there is any. People who pay attention to the world, who are willing to do things the hard way and stop giving money to people who are clearly evil.

This week is still largely focused on finalizing API/ABI for the 1.0 of Foundry in a few weeks.

Foundry

• Did a bunch of work on LLM completion and and conversation APIs. They are not focused on supporting everything possible but instead making some of the common stuff extremely simple. That goes for both the model size of things and the UI side of things.

  For example, heavy usage of GListModel everywhere we can.

• Created new abstractions for LlmTool, LlmToolProviders, and the actual call of a tool (aptly, LlmToolCall). One reason this all takes so much time to scaffold is that you want to allow some amount of flexibility when connecting models, but also avoid too much API surface area.

  I think I’ve managed to do that here.

• Landed Ollama implementation of the FoundryLlmConversation API. The ollama server appears to be stateless, which means copying the conversation over-and-over as you go. I guess this at least gives you an idea of your context window.

• Setup a couple tool call implementations to test out that infrastructure. For example, it’s really easy to tell the model that you build with build tool and then provide it the results.

• Fixed some licensing issues where I mostly just forgot to update the headers when copying them over. Things should be in a good place now for distributions to adhere to their SPDX rules.

• Language settings now have a very last resort setting which are the “defaults” we ship with the library. That is just sensible stuff like using 4 spaces for tabs/indent in Python.

  Settings at any layer can override these values.

• Lots of work on project templates. We have both GTK 4 and Adwaita templates again. They support C/Python/rust/JavaScript like Builder does too.

  But this time I tried to go a bit further. They should have a bunch of integration bits setup which we didn’t get to before.

• Setup an example Flatpak manifest for applications wanting to use libfoundry (see examples/flatpak/ ) that should help get you started.

• Setup i18n/l10n for libfoundry . I don’t think anything is consuming translations for GNOME 49 though, so mostly just gets us up and running for 50.

• Landed some new API for working with the stage/index within FoundryGitVcs . Tested it with a speed-run challenge a bit later on in this report.

Assist

• To test out the LLM APIs and ensure they can actually be used I did a speed-run to implement a “Foundry-based Developer Chat” with a time limit of two hours.

  The reality is that I’m still _much_ faster writing code with all of my templates and snippets than I thought.

  The new templates in Foundry are killer though.

• It requires a model which supports tool calls if you want to do anything interesting with it. I’m not sure if there are models which can do both written output _and_ tool-calls which makes this a bit annoying to wait while it figures out it should call a tool.

• While doing this, I realized a bunch of little things to fix in the LLM APIs. One piece still missing that I’d want to have in the future is the ability for specialized FoundryLlmMessage which not only have text content but typed data as well.

  For example, a tool call that is essentially a ls should really display the output as an interactive directory list and not text.

  But since this was a speed run, I did not implement that. Only made sure that the APIs could adapt to it in the future.

Staged

• Started another speed-run app to test out the version control engine we have in Foundry. This one is basically just to replace my very quick use of git-gui to line stage patches.

  Came up with a neat way to highlight old/new versions of a file and then display them with GtkListView instead of using a source view. No reason to power up the editing infrastructure if you’ll never be editing.

Manuals

• Discovered I wasn’t getting notifications since the move to the GNOME/ namespace so flushed out the backlog of MR there.

GtkSourceView

• Fix click-through on the overview map which broke again during this development cycle. My fault for not reviewing and/or testing better.

• Now that we have GNOME CI doing LSAN/ASAN/UBSAN/coverage/scanbuild I went ahead and fixed a bunch of leaks that are part of the testsuite.

  Additionally, it helped me find a few that were there in everyday code use, so that is always a lovely thing to fix.

Ptyxis

• Merge some last minute string changes before we can’t anymore.

• Still having to unfortunately close issues which come from Debian not sourcing /etc/profile.d/vte.sh by default, thus breaking integration features.

  The good news I hear is that will be changing before long.

• Other good news is that Ptyxis has landed in the 25.10 builds and will also be landing in Debian unstable in the near future as the default terminal.

• After some back-and-forth I merged support for the kgx palette as the “GNOME” palette in Ptyxis. My very hopeful desire is that this becomes something maintained by the design team. The problem is just that terminal colors are a huge piles of hacks on hacks.

• Nightly builds should be fixed. Apparently something changed in the CI setup and since we’re under chergert/ptyxis/ and not GNOME/ it didn’t get automatically applied.

• Some styling changed in libadwaita this cycle and I needed to adapt how we propagate our styling to tab close buttons.

  Really though, this all just needs to be redone (like Text Editor and Builder) to use var() properly in CSS.

Libspelling

• Merged patch improving life-cycle tracking of the piecetable/b+tree regions (branches/leaves).

Sysprof

• More code review and future feature planning so we can land GSoC things after I branch for 49 (very soon I hope).

Other

• Turned 41, saw Stevie Ray Vaughan’s broadcaster guitar, finally had the “weird” pizza at Lovely’s fifty/fifty, jammed at MoPOP with my niece.

• Lots of random little things this week to lend a hand/ear here or there as we get closer to release.

Misc news about the gedit text editor, mid-August edition! (Some sections are a bit technical).

Code Comment plugin rewritten

I forgot to talk about it in the mid-July news, but the Code Comment plugin has been rewritten in C (it was previously implemented in Python) and the bulk of it is implemented as re-usable code in libgedit-tepl. The implementation is now shared between Enter TeX and gedit.

File loading and saving: a new GtkSourceEncoding class

I've modified the GtkSourceEncoding class that is part of libgedit-gtksourceview, and adapted gedit accordingly. The new version of GtkSourceEncoding comes from an experiment that I did in libgedit-tepl several years ago.

GtkSourceEncoding represents a character set (or "charset" for short). It is used in combination with iconv to convert text files from one encoding to another (for example from ISO-8859-15 to UTF-8).

The purpose of the experiment that was done in libgedit-tepl (the TeplEncoding class) was to accomodate the needs for a uchardet usage (note that uchardet is not yet used by gedit, but it would be useful). uchardet is a library to automatically detect the encoding of some input text. It returns an iconv-compatible charset, as a string.

It is this string - returned by uchardet - that we want to store and pass to iconv unmodified, to not lose information.

The problem with the old version of GtkSourceEncoding: there was a fixed set of GtkSourceEncoding instances, all const (so without the need to free them). When trying to get an instance for an unknown charset string, NULL was returned. So this was not appropriate for a uchardet usage (or at least, not a clean solution: with the charset string returned by uchardet it was not guaranteed that a corresponding GtkSourceEncoding instance was available).

Since GtkSourceEncoding is used in a lot of places, we don't want to change the code to represent a charset as just a string. And a simple string is anyway too basic, GtkSourceEncoding provides useful features.

So, long story short: the new GtkSourceEncoding class returns new instances that must be freed, and has a constructor that just makes a copy of the charset string (there is the get_charset() method to get back the string, unmodified).

So gedit can keep using the GtkSourceEncoding abstraction, and we are one step closer to being able to use uchardet or something similar!

Know more about the gedit's maintainer

I now have a personal web site, or more accurately a single web page :
wilmet-software.be (Sébastien Wilmet)

gedit is a 27-years-old project, the first lines were written in 1998 (and normally it won't be part of the 27 Club !). I've been a contributor to the project for 14 years, so more than half the project existence. Time flies!

Robust file loading - some progress

After the rework of GtkSourceEncoding (which is part of the File Loading and Saving subsystem in libgedit-gtksourceview), I've made good progress to make the file loading more robust - although there is more work still to do.

It is a basis in programming to check all program input. gedit makes things a bit harder to accomplish this. To open a document :

• There is first the problem of the character encoding. It is not sufficient for a general-purpose text editor to accept only UTF-8. So text files can be almost anything in binary form.
• Then gedit allows to open documents containing invalid characters in the specified or auto-detected encoding. With this, documents can really be anything in binary form.
• Finally the GtkTextView widget used at the heart of gedit has several limitations: (1) very big files (like log files or database dumps) are not supported, a limit on the content size must be set (and if reached, still allow to load the file with truncated content). (2) very long lines cause performance problems and can freeze the application.

So, the good news is that progress has been made on this. (There is only a good news, let's stay positive!).

If you appreciate the work that I do in gedit, I would like to know your feedback, what I should improve or which important feature is missing. You can contact me by email for example, or on a discussion channel . Thank you :-) !

Ciao a tutti!

In this blog, I'm pumped to share my experience attending GUADEC 2025 held in Brescia, Italy.

Let's start :)

During the conference, I presented multiple talks -

My main talk on GNOME Internships, Google Summer of Code, Outreachy

Lightning talk on Need for GUADEC and Regional events

Lightning talk on GNOME Extensions as the gateway ****

BoF on GNOME Foundation Internships - Unrecorded 😅

The main talk was on Day 1 of the conference, which was quite exciting. I had the pleasure of sharing my journey and insights on how to leverage FOSS internships like GSoC and Outreachy to build a successful career in open source.

Attending this conference was far from easy. Due to the tragic Air India flight incident, I had to scrap my original travel plans and book a last-minute alternative to Italy. It was stressful — both emotionally and financially, but I was determined to make it to GUADEC.

Another trouble was with Visa; I had to apply for a Schengen Visa, which was hectic to say the least. Submitting 150+ pages of documents and waking up the GNOME Foundation team at night (their time) just to get some random letters the VFS office (embassy delegates) wanted during the submission process was bliss. So sincere thanks to Steven (ED), Anisa, Kristi, Rosanna, Asmit and others for helping me out with this at the very last minute. You all are heroes!

I usually carry double the required documents just to be on the safe side, but this was just something else.

Anyway, let's proceed with the blog :D

The touchdown

Due to a lack of flights to Brescia, I had to take a flight to Milan and then travel by train to Brescia.

But, since this was my first conference after graduating the same month (yipeee), I fortunately was able to extend my trip for the first time ever.

This let me explore Italy, a dream come true. I visited Milan and the Monza circuit before heading to Brescia.

I have no clue about racing, but visiting the Monza circuit was a surreal experience. The history, the cars, and the atmosphere were just amazing.

The pre-conference party

After some nice struggles with public transport in Brescia (I loved it afterwards though), I decided to take a 20-minute walk to the venue of the pre-conference party.

I don't mind walking, but as I was waiting for the bus, initially, I got late and had to walk fast. The worst part? The bus that didn't allow me to board was constantly catching up to me for half the journey, boosting the frustration.

But well... I finally reached! Met some of my friends and had nice conversations with the organisers, attendees, speakers and some really engaging discussions with Mauro from Canonical.

After which, he consented to me kidnapping him for an Indian dinner. The place we got to was closed (I hate Google Maps), but fortunately, we found another Indian restaurant in very close proximity.

We had tons of exchanges about the future of Ubuntu, Canonical and GNOME. It was great to meet in person after GUADEC 2023.

The first day of the conference

The first day was quite good, got to attend the talks which I was looking forward to and was also able to help with the Ubuntu booth setup (well, not much but somewhat?).

After tackling some great wifi chip delights, we were able to get the anonymous forms up and running for the booth.

And then came my talk. Maria Majadas introduced me (she is awesome btw!), and after some setup tackling, I was able to present my talk on "Making a career out of FOSS Internships GSoC/Outreachy".

I had to rush a bit due to the time constraints, but I was able to cover most of the points I wanted to. So yay!

Afterwards, I was able to volunteer for moderating the talk, "The state of GTK" by Matthias, which was quite insightful. It was great to see the progress GTK has made and the future plans.

We then had a great panel discussion, which was quite a nice twist.

Later Arti and Sri (Who both are awesome), whom I met for the first time in person, invited me for some snacks and drinks. The stories they shared were just so amazing and inspiring. Due to them, for the first time at GUADEC, I was able to have normal conversations and not just very professional ones. This elevated the conference 10x for me.

If you both are reading this, I just want to say you both are amazing, and I hope to see you again soon!

Then Mauro kidnapped me for a nice Italian dinner. We found a nice pizzeria with amazing views and food. I let him order for me, just like he did with me, haha.

And I have to say, that was the best pizza I ever had.

Also, I learned some new pizza cutting tricks and info on why you should NEVER share Pizza (apart from exchanging slices to try). This will stay with me for life xD.

Oh man, that was a lot for the first day. I was exhausted but happy.

The second day of the conference

On the second day, the highlight talks for me were "Getting Things Done in GNOME", "State of the Shell" and "Have a GTK app with no tests? No Problem!" (Which I had the pleasure to attend and moderate).

I also gave another lightning talk on "Why do we need GUADEC or GNOME events?" which was quite fun. I shared my experiences and insights on the importance of such events in fostering community and collaboration.

Thanks to Rosanna for giving me the idea to do so. It was really great to share my thoughts and experiences with the community.

After the conference, I took a detour to visit the beautiful Brescia Castle. The views were out of this world. I also, instead of taking the bus to the top or climbing up stairs, took the gravel path around the castle (It had fences which I decided to jump over :)). But it was worth it, climbing this way allowed me to see every corner of the city layer by layer. That you can't beat!

The third day of the conference

As you can guess by now, it was great as well, and I gave another talk - "GNOME Extensions: the gateway drug to GNOME" and also helped in moderating some sessions.

Also, I'll highly recommend you to watch the talk on Gnurd - https://www.youtube.com/live/Z7F3fghCQB4?si=H_HgN6IHeRdSVu10&t=27391 It was nice!

And we ended the day with a great dinner celebrating 25 years of GUADEC. The food was amazing, the company was great, and the atmosphere was just perfect.

The BoFs

Being a GNOME GSoC'22 Intern, and now a part of the GNOME Internship Committee, I had my fourth and final talk (kind of), GNOME Internship Committee Meetup, where we discussed the future of the program, the challenges we face, and how we can improve it.

Thanks, Felipe, for organising it and inviting me to be a part of it. It was great to see the progress we have made and the plans we have for the future.

The next day, I attended the "GTK Settings Hackfest" BoF, and it reminded me why physical meetups are so powerful. Discussing my blockers directly with the maintainers and fixing stuff together. It can't get more delightful than that!

We then went to Lake Iseo for a trip. And the picture will give you a glimpse of the beauty of the place.

The Bergamo tour

The tour was a great opportunity to check out Bergamo and interact with people.

Special shoutout to Ignacy for being my partner in crime for clicking pictures, haha. The skyline, the view from the top and the food were just amazing. We had a great time exploring the city and taking pictures.

It was also Federico's birthday, so we celebrated it with a cake and some drinks. Celebrating the founder at the 25th GUADEC was the cherry on top.

Federico also gave great insights about Coffee. I was looking forward to buying a Bialetti Moka pot, but I wasn't sure. But after his advice, I splurged. And I have to say, it was worth it. The coffee is just amazing, and the experience of making it is just delightful. Instant is not the same anymore :(.

So thanks to Federico, I now have a taste of Italy at home, haha.

Meeting people

At last, I met many new people and got to learn a lot. Made new friends, got to meet people I look up to and many more.

I hope I wasn't that introverted, but yeah, slowly getting comfortable around new people, especially thanks to Arti and Sri for making me feel comfortable and helping me break the ice.

The End

This GUADEC was just awesome. And I was also able to visit 4 cities in Italy, which was a dream come true. Normally, due to college, I couldn't visit any other city than the conference city, but this time I was able to extend my trip and explore Italy a bit.

Thanks to all the people for making the event so great. It was an experience like no other. I would also like to thank GNOME Foundation for sponsoring the trip :) I hope I used it to the fullest and made the most out of it. :D

I also renewed my GNOME Foundation membership just recently, which is awesome.

Foundry

This week was largely around getting the new template engine landed so it can be part of the 1.0 ABI. Basically just racing to get everything landed in time to commit to the API/ABI contract.

• FoundryTextBuffer gained some new type prerequisites to make it easier for writing applications against them. Since Foundry is a command line tool as well as a library, we don’t just use GtkTextBuffer since the CLI doesn’t even link against GTK. But it is abstracted in such a way that the GTK application would implement the FoundryTextBuffer interface with a derived GtkSourceBuffer .

• FoundryTextSettings has landed which provides a layered approach to text editor settings similar (but better) than we have currently in GNOME Builder. There is a new modeline implementation, editorconfig, and gsettings backed settings provider which apply in that order (with per-file overrides allowed at the tip).

  Where the settings-backed implementation surpasses Builder is that it allows for layering there too. You can have user-overrides by project, project defaults, as well as Foundry defaults.

  I still need to get the default settings per-language that we have already (and are mostly shared with Text Editor too) as reasonable defaults.

• To allow changing the GSettings-based text settings above, the foundry settings set ... command gained support for specific paths using the same :/ suffix that the gsettings command uses.

• Spent some time on the upcoming chat API for models so I can experiment with what is possible when you control the entire tools stack.

• Dropped some features so they wouldn’t be part of the 1.0. We can implement them later on as time permits. Specifically I don’t want to commit to a MCP or DAP implementation yet since I’m not fond of either of them as an API.

• The FoundryInput subsystem gained support for license and language inputs. This makes it much simpler to write templates in the new internal template format.

• Allow running foundry template create ./FILE.template to create a set of files or project from a template file. That allows you to interate on your own templates for your project without having to have them installed at the right location.

• Wrote new project templates for empty project, shared library project, and gtk4 projects. Still need to finish the gtk4 project a bit to match feature parity with the version from Builder.

  I very much am happy with how the library project turned out because this time around it supports Gir, Pkgconfig, Vapi generation, gi-doc, and more. I still need to get library potfile support though.

  I also wrote new templates for creating gobjects and gtkwidgets in C (but we can port to other languages if necessary). This is a new type of “code template” as opposed to “project template”. It still allows for multiple files to be created in the target project.

  What is particularly useful about it though is that we can allow projects to expose templates specific to that project in the UI. In Foundry, that means you have template access to create new plugins, LSPs, and services quite easily.

• Projects can specify their default license now to make more things just happen automatically for contributors when creating new files.

• Templates can include the default project license header simply now by doing `{{include “license.c”}} where the suffix gets the properly commented license block.

• The API for expand templates has changed to return a GListModel of FoundryTemplateOutput . The primary motivator here is that I want to be able to have UI in Builder that lets you preview template before actually saving the templates to disk.

• A new API landed that we had in Builder for listing build targets. Currently, only the meson plugin implements the FoundryBuildTargetProvider . This is mostly plumbing for upcoming features.

• The new template format is a bit of amalgamation from a few formats that is just based on my experience trying to find a way to maintain these templates.

  It starts with a GKeyFile block that describes the template and inputs to the template.

  Then you have a series of what looks like markdown code blocks. You can have conditionals around them which allows for optionally including files based on input.

  The filename for the blocks can also be expanded based on template inputs. The expansions are just TmplExpr expressions from template-glib.

  An example can be found at:

  https://gitlab.gnome.org/GNOME/foundry/-/blob/main/plugins/meson-templates/library.project

Template-GLib

• Found some oopsies in how TmplExpr evaluated branches so fixed those up. Last year I wrote most of a C compiler and taking a look at this code really makes me want to rewrite it all. The intermixing of Yacc and GObject Introspection is ripe for improvement.

• Added support for == and != of GStrv expressions.

Other

• Play CI whack-a-mole for ICU changes in nightly SDKs

• Propagate foundry changes to projects depending on it so that we have useful flatpak manifests with minimal feature flags enabled.

• Took a look at some performance issues in GNOME OS and passed along some debugging techniques. Especially useful for when all you got is an array of registers and need to know something.

• Libpeas release for GNOME 49 beta

This is a heads ups that if you install xkeyboard-config 2.45 (the package that provides the XKB data files), some manual interaction may be needed. Version 2.45 has changed the install location after over 20 years to be a) more correct and b) more flexible.

When you select a keyboard layout like "fr" or "de" (or any other ones really), what typically happens in the background is that an XKB parser (xkbcomp if you're on X, libxkbcommon if you're on Wayland) goes off and parses the data files provided by xkeyboard-config to populate the layouts. For historical reasons these data files have resided in /usr/share/X11/xkb and that directory is hardcoded in more places than it should be (i.e. more than zero). As of xkeyboard-config 2.45 however, the data files are now installed in the much more sensible directory /usr/share/xkeyboard-config-2 with a matching xkeyboard-config-2.pc for anyone who relies on the data files. The old location is symlinked to the new location so everything keeps working, people are happy, no hatemail needs to be written, etc. Good times.

The reason for this change is two-fold: moving it to a package-specific directory opens up the (admittedly mostly theoretical) use-case of some other package providing XKB data files. But even more so, it finally allows us to start versioning the data files and introduce new formats that may be backwards-incompatible for current parsers. This is not yet the case however, the current format in the new location is guaranteed to be the same as the format we've always had, it's really just a location change in preparation for future changes.

Now, from an upstream perspective this is not just hunky, it's also dory. Distributions however struggle a bit more with this change because of packaging format restrictions. RPM for example is quite unhappy with a directory being replaced by a symlink which means that Fedora and OpenSuSE have to resort to the .rpmmoved hack. If you have ever used the custom layout and/or added other files to the XKB data files you will need to manually move those files from /usr/share/X11/xkb.rpmmoved/ to the new equivalent location . If you have never used that layout and/or modified local you can just delete /usr/share/X11/xkb.rpmmoved . Of course, if you're on Wayland you shouldn't need to modify system directories anyway since you can do it in your $HOME .

Corresponding issues on what to do on Arch and Gentoo , I'm not immediately aware of other distributions's issues but if you search for them in your bugtracker you'll find them.

## Opaque Things

Very unfortunately, most of my past two weeks have been spent on “opaque things.” Let’s just label that whole bundle “bureaucracy” for now.

## Apology

I owe a massive apology to the GIMP team. These folks have been incredibly patient while the GNOME Foundation, as their fiscal host, sets up a bunch of new paperwork for them. It’s been a slow process.

Due to the above bureaucracy, this process has been even slower than usual. Particularly on GIMP’s big pearl anniversary year, this is especially frustrating for them and the timing is awful.

As long as I am in this role, I accept responsibility for the Foundation’s struggles in supporting the GIMP project. I’m sorry, folks, and I hope we get past the current round of difficulties quickly so we can provide the fiscal hosting you deserve.

## Draft Budget

Thanks to Deepa’s tremendous work teasing apart our financial reporting, she and I have a draft budget to present to the Board on their August 12th regular meeting.

The board has already seen a preliminary version of the budget as of their July 27th meeting and an early draft as of last week. Our schedule has an optional budget review August 26th, another required budget review on September 9th and, if we need a final meeting to pass the budget, we can do that at the September 23rd board meeting. Last year, Richard passed the first on-time GNOME Foundation budget in many years. I’m optimistic we can pass a clear, uncomplicated budget a month early in 2025.

(Our fiscal year is October – September.)

I’m incredibly grateful to Deepa for all the manual work she’s put into our finances during an already busy summer. Deepa’s also started putting in place a tagging mechanism with our bookkeepers which will hopefully resolve this in a more automatic way in the future. The tagging mechanism will work in conjunction with our chart of accounts, which doesn’t really represent the GNOME Foundation’s operating capital at all, as a 501(c)(3)’s chart of accounts is geared toward the picture we show to the IRS, not the picture we show to the Board or use to pass a budget. It’s the same data, but two very different lenses on it.

Understanding is the first step. After a month of wrestling with the data, we now understand it. Automation is the second step. The board should know exactly where the Foundation stands, financially, every year, every quarter, and every month… without the need for manual reports.

## 501(c)(3) Structural Improvements

As I mention in my GUADEC keynote , the GNOME Foundation has a long road ahead of it to become an ideal 501(c)(3) … but we just need to make sure we’re focused on continuous improvement. Other non-profits also struggle with their own structural challenges, since charities can take many different shapes and are often held together almost entirely by volunteers. Every organization is different, every organization wants to succeed.

I had the pleasure of some consultation conversations this week with Amy Parker of the OpenSSL Foundation and Halle Baksh, a 501(c) expert from California. Delightful folks. Super helpful.

One of the greatest things I’m finding about working in the non-profit space is that we have a tremendous support network. Everyone wants us to succeed and every time we’re ready to take the next step, there will be someone there to help us level up. Every time we do, the Foundation will get more mature and, as a result, more effective.

## Travel Policy Freeze

I created some confusion by mentioning the travel policy freeze in my AGM slides. A group of hackers asked me at dinner on the last night in Brescia, “does this mean that all travel for contributors is cancelled?”

No, absolutely not. The travel policy freeze means that every travel request must be authorized by the Executive Director and the President; we have temporarily suspended the Travel Committee’s spending authority. We will of course still sponsor visas for interns and other program-related travel. The intention of the travel policy freeze is to reduce administrative travel costs and add them to program travel, not the other way around.

Sorry if I freaked anyone out. The goal (as long as I’m around) will always be to push Foundation resources toward programs like development, infrastructure, and events.

## Getting Back To Work

Sorry again for the short update. I’m optimistic that we’ll get over this bureaucratic bump in the road soon enough. Thanks for your patience.

One of the things I’m working on at Red Hat is HDR support. HDR is inherently linked to luminance (brightness, but ignoring human perception) which makes it an important parameter for us that we would like to be in control of.

One reason is rather stupid. Most external HDR displays refuse to let the user control the luminance in their on-screen-display (OSD) if the display is in HDR mode. Why? Good question. Read my previous blog post .

The other reason is that the amount of HDR headroom we have available is the result of the maximum luminance we can achieve versus the luminance that we use as the luminance a sheet of white paper has (reference white level). For power consumption reasons, we want to be able to dynamically change the available headroom, depending on how much headroom the content can make use of. If there is no HDR content on the screen, there is no need to crank up the backlight to give us more headroom, because the headroom will be unused.

To work around the first issue, mutter can change the signal it sends to the display, so that white is not a signal value of 1.0 but somewhere else between 0 and 1. This essentially emulates a backlight in software. The drawback is that we’re not using a bunch of bits in the signal anymore and issues like banding might become more noticeable, but since we’re using this only with 10 or 12 bits HDR signals, this isn’t an issue in practice.

This has been implemented in GNOME 48 already, but it was an API that mutter exposed and Settings showed as “HDR Brightness”.

"HDR Brightness" in GNOME Settings

The second issue requires us to be able to map the backlight value to luminance, and change the backlight atomically with an update to the screen. We could work towards adding those things to the existing sysfs backlight API but it turns out that there are a number of problems with it. Mapping the sysfs entry to a connected display is really hard (GNOME pretends that there is only one single internal display that can ever be controlled), and writing a value to the backlight requires root privileges or calling a logind dbus API. One internal panel can expose multiple backlights, the value of 0 can mean the display turns off or is just really dim.

So a decision was made to create a new API that will be part of KMS, the API that we use to control the displays.

The sysfs backlight has been controlled by gnome-settings-daemon and GNOME Shell called a dbus API when the screen brightness slider was moved.

To recap:

• There is a sysfs backlight API for basically one internal panel requires logind or a setuid helper executable
• gnome-settings-daemon controlled this single screen sysfs backlight
• Mutter has a “software backlight” feature
• KMS will get a new backlight API that needs to be controlled by mutter

Overall, this is quite messy, so I decided to clean this up.

Over the last year, I moved the sysfs backlight handling from gnome-settings-daemon into mutter, added logic to decide which backlight to use (sysfs or the “software backlight”), and made it generic so that any screen can have a backlight. This means mutter is the single source of truth for the backlight itself. The backlight itself gets its value from a number of sources. The user can configure the screen brightness in the quick settings menu and via keyboard shortcuts. Power saving features can kick in and dim the screen. Lastly, an Ambient Light Sensor (ALS) can take control over the screen brightness. To make things more interesting, a single “logical monitor” can have multiple hardware monitors which each can have a backlight. All of that logic is now neatly sitting in GNOME Shell which takes signals from gnome-settings-daemon about the ALS and dimming. I also changed the Quick Settings UI to make it possible to control the brightness on multiple screens, and removed the old “HDR Brightness” from Settings.

All of this means that we can now handle screen brightness on multiple monitors and when the new KMS backlight API makes it upstream, we can just plug it in, and start to dynamically create HDR headroom.

tl;dr: I’m asking the biggest users of the LVFS to sponsor the project.

The Linux Foundation is kindly paying for all the hosting costs of the LVFS, and Red Hat pays for all my time — but as LVFS grows and grows that’s going to be less and less sustainable longer term. We’re trying to find funding to hire additional resources as a “me replacement” so that there is backup and additional attention to LVFS (and so that I can go on holiday for two weeks without needing to take a laptop with me).

This year there will be a fair-use quota introduced, with different sponsorship levels having a different quota allowance. Nothing currently happens if the quota is exceeded, although there will be additional warnings asking the vendor to contribute. The “associate” (free) quota is also generous, with 50,000 monthly downloads and 50 monthly uploads. This means that almost all the 140 vendors on the LVFS should expect no changes.

Vendors providing millions of firmware files to end users (and deriving tremendous value from the LVFS…) should really either be providing a developer to help write shared code, design abstractions and review patches (like AMD does) or allocate some funding so that we can pay for resources to take action for them. So far no OEMs provide any financial help for the infrastructure itself, although two have recently offered — and we’re now in a position to “ say yes ” to the offers of help.

I’ve written a LVFS Project Sustainability Plan that explains the problem and how OEMs should work with the Linux Foundation to help fund the LVFS.

I’m aware funding open source software is a delicate matter and I certainly do not want to cause anyone worry. We need the LVFS to have strong foundations; it needs to grow, adapt, and be resilient – and it needs vendor support.

Draft timeline, which is probably a little aggressive for the OEMs — so the dates might be moved back in the future:

APR 2025 : We started showing the historical percentage “fair use” download utilization graph in vendor pages. As time goes on this will also be recorded into per-protocol sections too.

JUL 2025 : We started showing the historical percentage “fair use” upload utilization, also broken into per-protocol sections:

JUL 2025 : We started restricting logos on the main index page to vendors joining as startup or above level — note Red Hat isn’t sponsoring the LVFS with money (but they do pay my salary!) — I’ve just used the logo as a placeholder to show what it would look like.

AUG 2025 : I created this blogpost and sent an email to the lvfs-announce mailing list.

AUG 2025 : We allow vendors to join as startup or premier sponsors shown on the main page and show the badge on the vendor list

DEC 2025 : Start showing over-quota warnings on the per-firmware pages

DEC 2025 : Turn off detailed per-firmware analytics to vendors below startup sponsor level

APR 2026 : Turn off access to custom LVFS API for vendors below Startup Sponsorship level, for instance:

• /lvfs/component/{}/modify/json
• /lvfs/vendors/auth
• /lvfs/firmware/auth

APR 2026 : Limit the number of authenticated automated robot uploads for less than Startup Sponsorship levels.

Comments welcome!