Hi everyone!

It's been about two weeks since UbuCon Asia (Ubuntu Conference Asia) concluded (fun fact: 13 weeks since I wrote the initial draft, so 15 now), and I'm really starting to miss it.

This blog is being posted after my GNOME Asia post as it was really hard to pack all the emotions and memories in just one blog, but here we go.

It all started as a wild idea to host GNOME Asia a year or two back. Gradually, it transformed into a joint event between UbuCon and GNOME Asia and eventually into UbuCon Asia 2024.

Why Jaipur?

This was one of the most frequently asked questions throughout the conference.

Interestingly, the local team (us) wasn't based in Jaipur. We were spread across India, with me in the Delhi area, some members in Maharashtra, and one in Karnataka. Managing Jaipur's affairs, as you can imagine, wasn't exactly a breeze.

So why did we choose it? When the initial idea came up, a friend and I ruled out cities that were overcrowded, too hot (we weren't entirely right there, but rain saved us lol), or lacking in the cultural heritage we wanted to showcase. We also wanted to pick a city with a budding tech scene, rather than an established one.

After much deliberation, we ruled out Bengaluru, Delhi, Mumbai, and Hyderabad. Jaipur, being relatively closer to me and ticking all the right boxes, became the chosen one!

In the end, we found the best college we could have in Jaipur, with a phenomenal volunteer team.

Why did we organize it?

Initially, the plan was to host GNOME Asia because GNOME is a community I deeply love. Having attended many GNOME events, I always wondered, "What if we host one in India?" With the largest population, immense Git activity, and a mature tech audience, India seemed perfect. But the sheer effort required always held me back - I'm just a developer who loves to code more than to manage people :)

The UbuCon planning began after GUADEC 2023, where I met Mauro at the Canonical booth. This led to rebooting Ubuntu India, with hosting UbuCon Asia as our first official activity.

I hesitated when asked to host UbuCon Asia but couldn't resist the challenge. Bhavani (my co-lead) also proposed hosting in Bangalore, so we combined our bid with my proposal for Jaipur. To our delight, we won! Although discussions for a joint venture with the GNOME team didn't pan out, we forged ahead with UbuCon Asia.

The Challenges We Faced

Although my role was initially to oversee and allocate tasks, I found myself involved in everything, which was hectic. Thankfully, the whole team worked as one on event days and without them, I wouldn't have been able to handle the last two days of the event.

Managing Jaipur's affairs remotely was tough, but the college we partnered with was incredibly supportive. Their students volunteered tirelessly.

Unexpectedly, our stage hosts backed out of the event just a day before due to placement drive in college, causing a session delay on the first day. Visa letter delays (Caused due to the Bangladesh crisis) and funding challenges due to Indian remittance laws were additional hurdles.

How It All Ended

Despite everything, we pulled it off, and dare I say, even better than many seasoned organizers might have! Seeing the community gather in India for UbuCon Asia was amazing.

We had Ubuntu and CDAC booths, delicious food (thanks to FOSS United and OnlyOffice), and lots of goodies for attendees. A proper Indian lunch with dessert, coffee breaks with Rajasthani and Indian snacks, a conference dinner, and subsidized day trips - all funded, were a relief.

Considering just weeks ago we were struggling to break even and were partially at a loss, to end with a surplus instead was truly relieving.

Fun fact: Leftover funds helped us host the release party at GNOME Asia 2024 and will support UbuCon India 2025 and UbuCon Asia 2025.

In my opening note, I joked, "I'm excited for the conference to end," but now I realize how wrong I was.

I enjoyed every moment of it. I wasn't able to attend more than one talk because when you are the lead, you just can't sit, you have to work the hardest and keep everything together, but that work also gave me lots of enjoyment and satisfaction.

My favorite feedback? "We knew it was your first time organizing at this scale because we saw how tense and hardworking you were, ensuring everything ran smoothly, which it did."

I regret not being able to meet many people I wanted to in more depth. Like Debian India folks, Aaditya Soni from AWS Rajasthan, Vishal Arya from FOSS United, Rudra the reviver of Ubuntu Unity and more.

We truly had astonishing people attend and I just wish to re-witness it all from an attendee's perspective now :P

The aftermovie can be viewed at - https://youtu.be/Ul8DQh3yroo?si=U2F3wi6mKBIVPJ6g :D

Future Plans?

Well... UCA'24 was draining and I don't want to think of another event for a while haha (This didn't last long considering the release party we hosted xD).

We are currently working on creating smaller regional Ubuntu communities in India, and hopefully organise UbuCon India.

So if you are a sponsor, please reach out, we can really use your help in the initiative :)

Also, if you want to be a part of the Ubuntu India LoCo community, let me know and we can have a conversation about it ;)

A special thanks to Canonical, CDAC, FOSS United, Only Office and Ubuntu Korea for their sponsorship :)

24 Dec 2024 7:30pm GMT

I have just released version 0.14 of CapyPDF. This release has a ton of new functionality. So much, in fact, that I don't even remember them all. The reason for this is that it is actually starting to see real world usage, specifically as the new color managed PDF exporter for Inkscape. It has required a lot of refactoring work in the color code of Inkscape proper. This work has been done mostly by Doctormo, who has several videos on the issue.

The development cycle has consisted mostly of him reporting missing features like "specifying page labels is not supported", "patterns can be used for fill, but not for stroke" and "loading CMYK TIFF images with embedded color profiles does not work" and me then implementing said features or finding out how how setjmp/longjmp actually works and debugging corrupted stack traces when it doesn't.

Major change coming in the next version

The API for CapyPDF is not stable, but in the next release it will be extra unstable. The reason is C strings. Null terminated UTF-8 strings are a natural text format for PDF, as strings in PDF must not contain the zero glyph. Thus there are many functions like this in the public C API:

void do_something(const char *text);

This works and is simple, but there is a common use case it can't handle. All strings must be zero terminated so you can't point to a middle of an existing buffer, because it is not guaranteed to be zero terminated. Thus you always have to make a copy of the text you want to pass. In other words this means that you can't use C++'s string_view (or any equivalent string) as a source of text data. The public API should support this use case.

Is this premature optimization? Maybe. But is is also a usability issue as string views seem to be fairly common nowadays. There does not seem to be a perfect solution, but the best one I managed to crib seems to be to do this:

void do_something(const char *text, int32_t len_or_negative);

If the last argument is positive, use it as the length of the buffer. If i is negative then treat the char data as a zero terminated plain string. This requires changing all functions that take strings and makes the API more unpleasant to use.

If someone has an idea for a better API, do post a comment here.

23 Dec 2024 3:54pm GMT

Prerequisite

I have been an Outreachy GNOME intern for a while now. GNOME is a free and open-source desktop environment for Linux and similar systems. It consists of quite a number of projects that make up the entire overall system, and the one I am working on for my internship is Librsvg.

About Librsvg: It is a small library to render Scalable Vector Graphics (SVGs) associated with GNOME projects.

Struggles

Initially, my struggle was with the programming language because Rust wasn't my primary language before I started the internship. This led to the struggle of understanding the codebase. But let's be honest, it's written in Rust, and it takes quite some time to fully onboard. Luckily, my internship is centered around implementations to handle the SVG2 text layout algorithm. Plus, a programming language is just a tool to get the job done and should not be a hindrance if you are willing to learn and put in the work.

During the course of the internship, I have also struggled with some domain-specific terminologies like Bi-di, glyphs, and how the existing program handles SVGs such as nested Bi-di and rendering. The struggle of understanding domain terminologies and how the program executes is natural. The steps to overcoming those struggles are crucial for growth and development.

What stood out towards helping me understand these struggles is the guidance of my mentor, Federico. We set up regular meetings, and whatever is discussed is noted in our shared pad for future reference and documentation. He also made it easy for me to ask questions by making it clear that "no question is too dumb to ask," and he never takes offense when I re-ask a question he has already answered and I forgot.

In our last meeting, he said something that stuck with me. When I told him a particular task felt overwhelming, he said, "I understand you; it is expected to be overwhelming to anyone," with a big smile. His understanding and patience have been instrumental in my progress and Federico's encouragement to ask any question, no matter how small, has been invaluable in building my confidence.

Tackling Tasks

I have completed a few tasks, and the way I approach them is by tackling them head-on. I do research where required and push for review. Never underestimate the power of reviews toward the completion of a task.

Overall, keep an open mind, be ready to learn, and always ask questions. If you have bad memory like mine, write things down as they come.

Final Thoughts

Keep in mind that struggles are part of the journey. You cannot run or shy away from what needs to be done, so why not just do it in time and have the rest of the time to understand your mistakes, reiterate on them, overcome them, and tag it as a win for yourself and a story to share with others.

Looking forward to sharing more of my internship progress with you soon!

See you in the next chapter-cheers!

23 Dec 2024 9:15am GMT

Not all of my projects this December are code related. In fact a lot of them have been house maintenance things, joy of home ownership and all.

This week was spent building my new office and music space. I wanted a way to have my amplifiers and guitars more accessible while also creating a sort of "dark academia" sort of feeling for working.

The first step was to get the guitars mounted on the walls. I was looking for something blending artistic showpiece and functional use.

After that I quickly framed them in. Just quarter round with the hard edge inwards, 45° miter, some caulking, easy peasy.

My last office had Hale Navy as the color, but the sheen was too much that it made it difficult to actually see the color. This time I went flat and color drenched the space (so ceilings, trim, etc all in matching tone).

Then somewhat final result is here. I still want to have a lighting story for these that doesn't involve a battery so some electrical fish taping is likely in my future.

I also converted the wide closet into a workstation area with the studio monitors for recording. But that is still partially finished as I need to plane all the slats for the slat wall, frame the builtin, and attach the countertop.

20 Dec 2024 5:46pm GMT

Update on what happened across the GNOME project in the week from December 13 to December 20.

GNOME Core Apps and Libraries

Sam Thursfield says

Carlos Garnacho implemented a clever optimisation in the LocalSearch filesystem indexer, which reduces memory usage when crawling large folders. See the MR for details and a before and after comparison.

Khalid Abu Shawarib reports

User Sharing, is a small package that binds together various free software projects to bring easy to use, user-level file sharing to the masses. Earlier this week, a merge request has landed that ports all of the application code over from C to Rust! The file sharing service still retains the same functionality.

See this post for more details.

Libadwaita

Building blocks for modern GNOME apps using GTK4.

Alice (she/her) says

libadwaita now has Adaptive Preview in GTK inspector, a way to test layouts on smaller screen sizes - similar to responsive layout mode in Firefox inspector, device toolbar in Chrome etc. See https://blogs.gnome.org/alicem/2024/12/19/mobile-testing-in-libadwaita/ for more details

Software

Lets you install and update applications and system extensions.

Adrien Plazas announces

Software received a brand new systemd-sysupdate plugin. That was one of the last pieces needed to complete the migration of GNOME OS from OSTree to systemd-sysupdate. Read more in this short blog post.

Calendar

A simple calendar application.

Titouan Real says

GNOME Calendar, your favorite calendaring application, got a much improved event editor for GNOME 48!

• Adaptive Calendar Selector: The calendar selector dropdown has been updated to use a standard widget, fixing multiple issues along the way;
• Better Date and Time Entries: entries feature better keyboard navigation and better parsing;
• Modernized Layout: The new layout is more compact, easier to read, and is more in line with modern design patterns.

Support for timezone editing is also in the testing phase in this merge request. If you would like to help, you can grab the Flatpak artifacts (or build yourself using GNOME Builder), and report any bug you may find. We recommend only using a throwaway calendar for testing.

GNOME Circle Apps and Libraries

Tuba

Browse the Fediverse.

Evangelos "GeopJr" Paterakis announces

Tuba 0.9 is now available, with many new features and bug fixes!

✨ Highlights:

• Audio Visualizer
• Accent Colors and other GNOME 47 changes
• Focus Picker
• Account Suggestions for new accounts
• Scheduled & Draft Posts
• Full emoji reaction support for supported backends
• FediWrapped
• Viewing which ones of the people you follow also follow an account
• Placing favorite lists to the sidebar
• Poll animations, refresh and show results button
• Windows installer
• And much more!

Happy Holidays! ❄️

Third Party Projects

دانیال بهزادی announces

We're excited to announce the release of Carburetor version 5.0.0, our user-friendly tool for setting up a TOR proxy effortlessly! This release comes with a special significance as we celebrate the longest night of the year, known as Yalda in Persian culture. Yalda symbolizes the endurance of darkness, reminding us that even the longest nights eventually give way to dawn. This resonates deeply with those living under tyranny, as we hold onto hope for a brighter future and the eventual liberation from oppression.

In a momentous turn of events, we also extend our heartfelt congratulations to the brave Syrians around the world on the departure of Bashar Al-Asad, a symbol of tyranny. We hope this new chapter brings them closer to freedom and access to a truly open Internet. With Carburetor, we aim to empower users to prioritize their privacy and security, ensuring that the tool is used for the right reasons-helping others and safeguarding personal information, rather than as a means of mandatory connectivity.

Happy Yalda and cheers to a brighter future! 🌟

Parabolic

Download web video and audio.

Nick says

Parabolic V2024.12.0 is here! This update contains a redesigned Qt application, new features and various bug fixes.

Here's the full changelog:

• Added the ability to toggle the inclusion of a media's id in its title when validated in the app's settings
• Added the option to export a download's media description to a separate file
• Restored the ability for Parabolic to accept a URL to validate via command line arguments
• Fixed an issue where auto-generated subtitles were not being embed in a media file
• Fixed an issue where downloading media at certain time frames were not respected
• Fixed an issue where video medias' thumbnails were also cropped when crop audio thumbnails was enabled
• Fixed an issue where the previously used download quality was not remembered
• Redesigned the Qt version's user interface with a more modern style
• Updated yt-dlp to 2024.12.13

Nick reports

Parabolic V2024.12.1 was also released this week! It contains various bug fixes for issues users were experiencing.

Here's the full changelog:

• Fixed an issue where generic video downloads would sometimes incorrectly convert to another file type
• Fixed an issue where subtitles were not downloaded properly
• Fixed an issue where desktop notifications were not being displayed

That's all for this week!

See you next week, and be sure to stop by #thisweek:gnome.org with updates on your own projects!

20 Dec 2024 12:00am GMT

In late June 2024 I got asked to take over the work started by Jerry Wu creating a systemd-sysupdate plugin for Software. The goal was to allow Software to update sysupdate targets, such as base system images or system extension images, all while respecting the user's preferences such as whether to download updates on metered connections. To do so, the plugin communicates with the systemd-sysupdated daemon via its org.freedesktop.sysupdate1 D-Bus interface.

I didn't know many of the things required to complete this project and it's been a lot to chew in one bite for me, hence how long it took to complete. I'm happy it's finally done, but I'm certain it's riddled with bugs despite my best efforts, and I'm not happy it's a single gigantic C file. It needs to be split into modules, but that's an effort for another time as getting it to work at all was a challenge already. I'm happy I learned a lot along the way. Thanks a lot to Codethink, to the GNOME Foundation, to the Sovereign Tech Agency and for sponsoring this work. Thanks a lot to Abderrahim Kitouni, Adrian Vovk, Philip Withnall and all the other persons who helped me complete this project. 🙂

This was one of the last pieces of software needed to complete the migration of GNOME OS from OSTree to sysupdate. While OSTree is great for operating systems, it has a significant drawback: it can't support SecureBoot because it can't support Unified Kernel Images, and SecureBoot requires a signed Unified Kernel Image for its chain of trust. While its A/B partitioning system makes sysupdate more storage hungry and less flexible than OSTree, it allows it to support Unified Kernel Images, to sign them, and to be part of SecureBoot's chain of trust, ensuring the system hasn't been maliciously tempered. This will make GNOME OS more secure and its boot trusted. Read more of trusted boot from Lennart Poettering.

Erratum: Timothée Ravier stated that OSTree can support trusted boot and measured boot, see this demostration.

You should be able to test this plugin in GNOME OS soon. Please report any issues with the systemd-sysupdate tag, and the GNOME OS one if relevant. We want to be very sure that this works, as it's vital that users know whether or not their system is up to date, especially if there are security-related fixes involved.

19 Dec 2024 11:00pm GMT

In line with traditions, it's time for the yearly end-of-the year Maps blog post!

There's been some quite nice happenings this year when it comes to Maps (and the underlaying libshumate, our map widget library).

Vector Map Enabled by Default

The biggest change, by large that's happened in 2024 is that we finally did the switch to client-side rendered vector tiles with all the benefits this brings us:

• A "GNOME-themed" map style
• Properly support dark mode
• Localized labels for places (countries, towns, and so on…)
• POI icons can now be directly clicked on the map, bringing up information of place
  

More Use of Modern libadwaita Widgets

Works has continued replacing the old deprecated GtkDialog instances, instead using libadwaita's new dialogs, which also has the benefit of being adaptive for small screen sizes. Right now the only remaining instance of the old dialog type is the sharing "Send to" dialog.

Since the 47 release, the OSM POI editing dialog has received a refreshed look-and-feel based on Adwaita widgets, designed by Brage Fuglseth, and initial draft implementation by Felipe Kinoshita.

More Visual Improvements

Also since the September release, some more UI refinements have been made.

The action of starring a place now has an accopanying animation to help give a visual clue of the change.

The headerbar icon for showing the menu listing stored favorites now uses the same icon as GNOME Web (Epiphany), the "books on a libray shelf" icon.

Spinner widgets (for showing progress) has been updated to the new Adwaita variant with a refreshed design.

And the toggle buttons for selecting routing mode (walk, bike, car, transit) now uses the new Adwaita ToggleGroup icon buttons.

Public Transit Routing Using Transitous

I have mentioned the Transitous previously and since 47.0 Maps uses Transitous to provide public transit directions for regions that weren't already covered by our existing plugins and their provided regions.

During the last few months works has progressed on an updated version of MOTIS (the backend used by Transious) that will give better performance, among otheres.

Maps will also soon transition to the new API when Transitous switches over to it.

And speaking of Transitous and MOTIS.

At FOSDEM 2025 me, Felix Gündling, and Jonah Brüchert will give a presentation of MOTIS, Transitous, and the integration into Maps.

https://fosdem.org/2025/schedule/event/fosdem-2025-4105-gnome-maps-meets-transitous-meets-motis/

And until next time, happy holidays!

19 Dec 2024 8:46pm GMT

Lately I've been working on touch controls overlays in Highscore¹, and quickly found out that previewing them across different screen sizes is rather tedious.

Currently we have two ways of testing UIs on a different screen size - resize the window, or run the app on that device. Generally when developing, I do the former since it's faster, but what dimensions do I resize to?

HIG lists the 360×294px dimensions, but that's the smallest total size - we can't really figure out the actual sizes in portrait and landscape with this. Sure, we can look up the phone sizes, check their scale factor, and measure the precise panel sizes from screenshots, but that takes time and that's a lot of values to figure out. I did make such a list, and that's what I used for testing here, but, well, that's a lot of values. I also discovered the 294px height listed in HIG is slightly wrong (presumably it was based on phosh mockups, or a really old version) and with older phosh versions the app gets 288px of height, while with newer versions with a slimmer bottom bar it gets 313px.

Now that we know the dimensions, the testing process consists of repeatedly resizing the window to a few specific configurations. I have 31 different overlay, each with 7 different layouts for different screen sizes. Resizing the window for each of them gets old fast, and I really wished I had a tool to make that easier. So, I made one.

This is not a separate app, instead it's a libadwaita feature called adaptive preview, exposed via GTK inspector. When enabled, it shrinks the window contents into a small box and exposes UI for controlling its size: specifically, picking the device and shell from a list. Basically, same as what web browsers have in their inspectors - responsive design mode in Firefox etc.

It also allows to toggle whether window controls are visible - normally they are disabled on mobile, but mobile gnome-shell currently keeps them enabled as not everything is using AdwDialog yet.

It can also be opened automatically by specifying the ADW_DEBUG_ADAPTIVE_PREVIEW=1 environment variable. This may be useful if e.g. Builder wants to include it into its run menu, similar to opening GTK inspector.

If the selected size is too large and doesn't fit into the window, it scrolls instead.

What it doesn't do

It doesn't simulate fullscreen. Fullscreen is complicated because in addition to hiding shell panels almost every app that supports it changes the UI state - this is not something we can automatically support.

It also doesn't simulate different scale factors - it's basically impossible to do with with how it's implemented.

Similarly, while it does allow to hide the window controls, if the app is checking them manually via GtkSettings:gtk-decoration-layout, it won't pick that up. It can only affect AdwHeaderBar, similarly to how it's hiding close button on the sidebars.

Future plans

It would be good to display the rounded corners and cutouts on top of the preview. For example, the phone I use for testing has both rounded corners and a notch, and we don't have system-wide support for insets or safe area just yet. I know the notch dimensions on my specific phone (approximately 28 logical pixels in height), but obviously it will vary wildly depending on the device. The display panel data from gmobile may be a good fit here.

We may also want to optionally scale the viewport to fit into the window instead of scrolling it - especially for larger sizes. If we have scaling, it may also be good to have a way to make it match the device's DPI.

Finally, having more device presets in there would be good - currently I only included the devices I was testing the overlays for.

---

Adaptive preview has already landed in the main branch and is available to apps using the nightly SDK, as well as in GNOME OS.

So, hopefully testing layouts on mobile devices will be easier now. It's too late for me, but maybe the next person testing their app will benefit from it.

---

1. gnome-games successor, which really deserves a blog post of its own, but I want to actually have something I can release first, so I will formally announce it then. For now, I'm frequently posting development progress on the Fediverse

19 Dec 2024 1:36pm GMT

Two weeks ago we got together in Berlin for another (Un)boiling The Ocean event (slight name change because Mastodon does not deal well with metaphors). This time it was laser-focused on local-first sync, i.e. software that can move seamlessly between real-time collaboration when there's a network connection, and working offline when there is no connection.

The New p2panda

This event was the next step in our ongoing collaboration with the p2panda project. p2panda provides building blocks for local-first software and is spearheaded by Andreas Dzialocha and Sam Andreae. Since our initial discussions in late 2023 they made a number of structural changes to p2panda, making it more modular and easier to use for cases like ours, i.e. native GNOME apps.

This new version of p2panda shipped a few weeks ago, in the form of a dozen separate Rust crates, along with a new website and new documentation.

On Saturday night we had a little Xmas-themed release party for the new p2panda version, with food, Glühwein, and two talks from Eileen Wagner (on peer-to-peer UX patterns) and Sarah Grant (on radio communication).

The Hackfest

Earlier on Saturday and then all day Sunday we had a very focused and productive hackfest to finally put all the pieces together and build our long-planned prototype codenamed "Aardvark", a local-first collaborative text editor using the p2panda stack.

Our goal was to put together a simple Rust GTK starter project with a TextView, read/write the TextView's content in and out of an Automerge CRDT, and sync it with other local peers via p2panda running in a separate thread. Long story short: we pulled it off! By the end of the hackfest we had basic collaborative editing working on the local network (modulo some bugs across the stack). It's of course still a long road from there to an actual releasable app, but it was a great start.

The reason why we went with a text editor is not because it's the easiest thing to do - freeform text is actually one of the more difficult types of CRDT. However, we felt that in order to get momentum around this project it needs to be something that we ourselves will actually use every day. Hence, the concrete use case we wanted to target was replacing Hedgedoc for taking notes at meetings (particularly useful when having meetings at offline, where there's no internet).

While the Berlin gang was hacking on the text editor, we also had Ada, a remote participant, looking into what it would take to do collaborative sketching in Rnote. This work is still in the investigation stage, but we're hopeful that it will get somewhere as a second experiment with this stack.

Thanks to everyone who attended the hackfest, in particular Andreas for doing most of the organizing, and Sam Andreae and Sebastian Wick, who came to Berlin specifically for the event! Thanks also to Weise7 for hosting us, and offline for hosting the release party.

The Long Game

Since it's early days for all of this stuff, we feel that it's currently best to experiment with this technology in the context of a specific vertically integrated app. This makes it easy to iterate across the entire stack while learning how best to fit together various pieces.

However, we're hoping that eventually we'll settle on a standard architecture that will work for many types of apps, at which point parts of this could be split out into a system service of some kind. We could then perhaps also have standard APIs for signaling servers (sometimes needed for peers to find each other) and "dumb pipe" sync/caching servers that only move around encrypted packets (needed in case none of the other peers are online). With this there could be many different interchangeable sync server providers, making app development fully independent of any specific provider.

This is all still pretty far out, but we imagine a world where as an app developer the only thing you need to do to build real-time collaboration is to integrate a CRDT for your data, and use the standard system API for the sync service to find peers and send/receive data.

With this in place it should be (almost) as easy to build apps with seamless local-first collaboration as it is to build apps using only the local file system.

Next Steps

It's still early days for Aardvark, but so far everyone's very excited about it and development has been going strong since the hackfest. We're hoping to keep this momentum going into next year, and build the app into a more full-fledged Hedgedoc replacement as part of p2panda's NGI project by next summer.

That said, we see the main value of this project not in the app itself, but rather the possibility for our community to experiment with local-first patterns, in order to create capacity to do this in more apps across our ecosystem. As part of that effort we're also interested in working with other app developers on integration in their apps, making bindings for other languages, and working on shared UI patterns for common local-first user flows such as adding peers, showing network status, etc.

If you'd like to get involved, e.g. by contributing to Aardvark, or trying local-first sync in your own app using this stack feel free to reach out on Matrix (aardvark:gnome.org), or the Aardvark repo on Github.

Happy hacking!

18 Dec 2024 5:21pm GMT

This is a heads up that if you file an issue in the libinput issue tracker, it's very likely this issue will be closed. And this post explains why that's a good thing, why it doesn't mean what you want, and most importantly why you shouldn't get angry about it.

Unfixed issues have, roughly, two states: they're either waiting for someone who can triage and ideally fix it (let's call those someones "maintainers") or they're waiting on the reporter to provide some more info or test something. Let's call the former state "actionable" and the second state "needinfo". The first state is typically not explicitly communicated but the latter can be via different means, most commonly via a "needinfo" label. Labels are of course great because you can be explicit about what is needed and with our bugbot you can automate much of this.

Alas, using labels has one disadvantage: GitLab does not allow the typical bug reporter to set or remove labels - you need to have at least the Planner role in the project (or group) and, well, suprisingly reporting an issue doesn't mean you get immediately added to the project. So setting a "needinfo" label requires the maintainer to remove the label. And until that happens you have a open bug that has needinfo set and looks like it's still needing info. Not a good look, that is.

So how about we use something other than labels, so the reporter can communicate that the bug has changed to actionable? Well, as it turns out there is exactly thing a reporter can do on their own bugs other than post comments: close it and re-open it. That's it [1]. So given this vast array of options (one button!), we shall use them (click it!).

So for the forseeable future libinput will follow the following pattern:

• Reporter files an issue
• Maintainer looks at it, posts a comment requesting some information, closes the bug
• Reporter attaches information, re-opens bug
• Maintainer looks at it and either: files a PR to fix the issue or closes the bug with the wontfix/notourbug/cantfix label

Obviously the close/reopen stage may happen a few times. For the final closing where the issue isn't fixed the labels actually work well: they preserve for posterity why the bug was closed and in this case they do not need to be changed by the reporter anyway. But until that final closing the result of this approach is that an open bug is a bug that is actionable for a maintainer.

This process should work (in libinput at least), all it requires is for reporters to not get grumpy about issue being closed. And that's where this blog post (and the comments bugbot will add when closing) come in. So here's hoping. And to stave off the first question: yes, I too wish there was a better (and equally simple) way to go about this.

[1] we shall ignore magic comments that are parsed by language-understanding bots because that future isn't yet the present

18 Dec 2024 3:21am GMT

The developers of Git have been considering switchibg build systems for a while. No definitive decision have been made as of yet, but they gave merged Meson build definitions in the main branch. Thus it now possible, and even semi-supported, to develop and build Git with Meson instead of the vintage Makefile setup (which, AFAICT, remains as the default build system for now).

The most interesting thing about this conversion is that the devs were very thorough in their evaluation of all the different possibilities. Those who are interested in the details or are possibly contemplating a build system switch on their own are recommended to read the merge's commit message.

Huge congratulations for everyone involved and thank you for putting in the work (FTR i did not work on this myself).

17 Dec 2024 4:43pm GMT

Last week we released systemd v257 into the wild.

In the weeks leading up to this release (and the week after) I have posted a series of serieses of posts to Mastodon about key new features in this release, under the #systemd257 hash tag. In case you aren't using Mastodon, but would like to read up, here's a list of all 37 posts:

• Post #1: Fully Locked Accounts with systemd-sysusers
• Post #2: Combined Signed PCR and Locally Managed PCR Policies for Disk Encryption
• Post #3: Progress Indication via Terminal ANSI Sequence
• Post #4: Multi-Profile UKIs
• Post #5: The New sd-varlink & sd-json APIs in libsystemd
• Post #6: Querying for Passwords in User Scope
• Post #7: Secure Attention Key Logic in systemd-logind
• Post #8: systemd-nspawn --bind-user= Now Copies User's SSH Key
• Post #9: The New DeferReactivation= Switch in .timer Units
• Post #10: Support for the New IPE LSM
• Post #11: Environment Variables for Shell Prompt Prefix/Suffix
• Post #12: sysctl Conflict Detection via eBPF
• Post #13: initrd and µcode UKI Add-Ons
• Post #14: SecureBoot Signing with the New systemd-sbsign Tool
• Post #15: Managed Access to hidraw devices in systemd-logind
• Post #16: Fuzzy Filtering in userdbctl
• Post #17: MAC Address Based Alternative Network Interface Names
• Post #18: Conditional Copying/Symlinking in tmpfiles.d/
• Post #19: Automatic Service Restarts in Debug Mode
• Post #20: Filtering by Invocation ID in journalctl
• Post #21: Supplement Partitions in repart.d/
• Post #22: DeviceTree Matching in UKIs
• Post #23: The New ssh-exec: Protocol in varlinkctl
• Post #24: SecureBoot Key Enrollment Preparation with bootctl
• Post #25: Automatically Installing confext/sysext/portable/VMs/container Images at Boot
• Post #26: Designated Maintenance Time in systemd-logind
• Post #27: PID Namespacing in Service Management
• Post #28: Marking Experimental OS Releases in /etc/os-release
• Post #29: Decoding Capability Masks with systemd-analyze
• Post #30: Investigating Passed SMBIOS Type #11 Data
• Post #31: Initializing Partitions from Character Devices in repart.d/
• Post #32: Entering Namespaces to Generate Stacktraces
• Post #33: ID Mapped Mounts for Per-Service Directories
• Post #34: A Daemon for systemd-sysupdate
• Post #35: User Record Modifications without Administrator Consent in systemd-homed
• Post #36: DNR DHCP Support
• Post #37: Name Based AF_VSOCK ssh Access

I intend to do a similar series of serieses of posts for the next systemd release (v258), hence if you haven't left tech Twitter for Mastodon yet, now is the opportunity.

16 Dec 2024 11:00pm GMT

I am delighted to announce that I am mentoring Adetoye Anointing for the December 2024 round of Outreachy. Anointing will be working on librsvg, on implementing the SVG2 text layout algorithm. This is his first blog post about the internship.

There is a lot of work to do! Text layout is a complex topic, so rather than just saying, "go read the spec and write the code", Anointing and I have decided to have a little structure to our interactions:

• We are having two video calls a week.

• During the calls, I'm sharing my screen to walk him through the code.

• I'm using my friend Abrahm's Pizarra and a Wacom tablet to have a "digital chalkboard" where I can quickly illustrate explanations while Anointing and I chat:

• Conveniently, Pizarra also produces SVG files from whatever you doodle in it, so it's easier to include the drawings in other documents.

• We are using a shared document in pad.gnome.org as a development journal. Here I can write long explanations, leave homework, link to stuff, etc. Anointing can put in his own annotations, questions, or anything else. I'm hoping that this works better than scrolling through a Matrix chat channel.

I have big hopes for this project. Please welcome Anointing if you see him around the Rust ♥️ GNOME channel!

13 Dec 2024 10:27pm GMT

Table of Contents

• Table of Contents
• 1. Introduction
• 2. Achievements
  • 2.1. Major achievements
  • 2.2. Minor achievements
  • 2.3 Minor annoyances/bugs that were also fixed in 2024
  • 2.3. Our brand new and renewed partnerships
  • Expressing my gratitude

1. Introduction

Time is passing by very quickly and another year will go as we approach the end of 2024. This year has been fundamental in shaping the present and the future of GNOME's Infrastructure with its major highlight being a completely revamped platform and a migration of all GNOME services over to AWS. In this post I'll try to highlight what the major achievements have been throughout the past 12 months.

2. Achievements

In the below is a list of individual tasks and projects we were able to fulfill in 2024. This section will be particularly long but I want to stress the importance of each of these items and the efforts we put in to make sure they were delivered in a timely manner.

2.1. Major achievements

1. All the applications (except for ego, which we expect to handle as soon as next week or in January) were migrated to our new AWS platform (see GNOME Infrastructure migration to AWS)
2. During each of the apps migrations we made sure to:
   1. Migrate to sso.gnome.org and make 2FA mandatory
   2. Make sure database connections are handled via connection poolers
   3. Double check the container images in use were up-to-date and GitLab CI/CD pipeline schedules were turned on for weekly rebuilds (security updates)
   4. For GitLab, we made sure repositories were migrated to an EBS volume to increase IO throughput and bandwidth
3. Migrated away our backup mechanism away from rdiff-backup into AWS Backup service (which handles both our AWS EFS and EBS snapshots)
4. Retired our NSD install and migrated our authoritative name servers to CloudNS (it comes with multiple redundant authoritative servers, DDOS protection and automated DNSSEC keys rotation and management)
5. We moved away from Ceph and the need to maintain our own storage solution and started leveraging AWS EFS and EBS
6. We deprecated Splunk and built a solution around promtail and Loki in order to handle our logging requirements
7. We deprecated Prometheus blackbox and started leveraging CloudNS monitoring service which we interact with using an API and a set of CI/CD jobs we host in GitHub
8. We archived GNOME's wiki and turned it into a static HTML copy
9. We replaced ftpadmin with the GNOME Release Services, thanks speknik! More information around what steps should GNOME Maintainers now follow when doing a module release are available here. The service uses JWT tokens to verify and authorize specific CI/CD jobs and only allows new releases when the process is initiated by a project CI living within the GNOME GitLab namespace and a protected tag. With master.gnome.org and ftpadmin being in production for literally ages, we wanted to find a better mechanism to release GNOME software and avoid a single maintainer SSH key leak to allow a possible attacker to tamper tarballs and potentially compromise milions of computers running GNOME around the globe. With this change we don't leverage SSH anymore and most importantly we don't allow maintainers to generate GNOME modules tarballs on their personal computers rather we force them to use CI/CD in order to achieve the same result. We'll be coming up shortly with a dedicated and isolated runner that will only build jobs tagged as releasing GNOME software.
10. We retired our mirroring infrastructure based on Mirrorbits and replaced it with our CDN partner, CDN77
11. We decoupled GIMP mirroring service from GNOME's one, GIMP now hosts its tarballs (and associated rsync daemon) on top of a different master node, thanks OSUOSL for sponsoring the VM that makes this possible!

2.2. Minor achievements

1. Retired multiple VMs: splunk, nsd0{1,2}, master, ceph-metrics, gitaly
2. We started managing our DNS using an API and CI/CD jobs hosted in GitHub (this to avoid relying on GNOME's GitLab which in case of unavailability would prevent us to update DNS entries)
3. We migrated smtp.gnome.org to OSCI in order to not lose IP reputations and various whitelists we received throughout the years by multiple organizations
4. We deprecated our former internal DNS authoritatives based on FreeIPA. We are now leveraging internal VPC resolvers and Route53 Private zones
5. We deprecated all our OSUOSL GitLab runners due to particularly slow IO and high steal time and replaced them with a new Heztner EX44 instance, kindly sponsored by GIMP. OSUOSL is working on coming up with local storage on their Openstack platform. We are looking forward to test that and introduce new runners as soon as the solution will be made available
6. Retired idm0{1,2} and redirected them to a new FreeIPA load balanced service at https://idm.gnome.org
7. We retired services which weren't relevant for the community anymore: surveys.gnome.org, roundcube (aka webmail.gnome.org)
8. We migrated nmcheck.gnome.org to Fastly and are using Synthetic responses to handle HTTP responses to clients
9. We upgraded to Ansible Automation Platform (AAP) 2.5
10. As part of the migration to our new AWS based platform, we upgraded Openshift to release 4.17
11. We received a 2k grant from Microsoft which we are using for an Azure ARM64 GitLab runner
12. All of our GitLab runners fleet are now hourly kept in sync using AAP (Ansible roles were built to make this happen)
13. We upgraded Cachet to 3.x series and fixed dynamic status.gnome.org updates (via a customized version of cachet-monitor)
14. OS Currency: we upgraded all our systems to RHEL 9
15. We converted all our Openshift images that were using a web server to Nginx for consistency/simplicity
16. Replaced NRPE with Prometheus metrics based logging, checks such as IDM replication and status are now handled via the Node Exporter textfile plugin
17. Migrated download.qemu.org (yes, we also host some components of QEMU's Infrastructure) to use nginx-s3-gateway, downloads are then served via CDN77

2.3 Minor annoyances/bugs that were also fixed in 2024

1. Invalid OCSP responses from CDN77, https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/1511
2. With the migration to USE_TINI for GitLab, no gpg zombie processes are being generated anymore

2.3. Our brand new and renewed partnerships

1. From November 2024 and ongoing, AWS will provide sponsorship and funding to the GNOME Project to sustain the majority of its infrastructure needs
2. Red Hat kindly sponsored subscriptions for RHEL, Openshift, AAP as well as hosting, bandwidth for the GNOME Infrastructure throughout 2024
3. CDN77 provided unlimited bandwidth / traffic on their CDN offering
4. Fastly renewed their unlimited bandwidth / traffic plan on their Delivery/Compute offerings
5. and thanks to OSUOSL, Packet, DigitalOcean, Microsoft for the continued hosting and sponsorship of a set of GitLab runners, virtual machines and ARM builders!

Expressing my gratitude

As I'm used to do at the end of each calendar year, I want to express my gratitude to Bartłomiej Piotrowski for our continued cooperation and also to Stefan Peknik for his continued efforts in developing the GNOME Release Service. We started this journey together many months ago when Stefan was trying to find a topic to base his CS bachelor thesis on. With this in mind I went straight into the argument of replacing ftpadmin with a better technology also in light of what happened with the xz case. Stefan put all his enthusiasm and professionality into making this happen and with the service going into production on the 11th of December 2024 history was made.

That being said, we're closing this year being extremely close to retire our presence from RAL3 which we expect to happen in January 2025. The GNOME Infrastructure will also send in a proposal to talk at GUADEC 2025, in Italy, to present and discuss all these changes with the community.

13 Dec 2024 9:29pm GMT

Early on Builder had the concept of layered settings. You had an application default layer the user could control. You also had a project layer which allowed the user to change settings just for that project. But that was about the extent of it. Additionally, these settings were just stored in your normal GSettings data repository so there is no sharing of settings with other project collaborators. Boo!

With Foundry, I'd like to have a bit more flexibility and control. Specifically, I want three layers. One layer for the user's preferences at the application level. Then project settings which can be bundled with the project by the maintainer for needs specific to the project. Lastly, a layer of user overrides which takes maximum preference.

Of course, it should still continue to use GSettings under the hood because that makes writing application UI rather easy. As mentioned previously, we'll have a .foundry directory we place within the project with storage for both user and project data. That means we can use a GKeyFile back-end to GSettings and place the data there.

You can git commit your project settings if you're the maintainer and ensure that your projects conventions are shared to your collaborators.

Of course, since this is all command-line based right now, there are tab-completable commands for this which again, makes unit testing this stuff easier.

# Reads the app.devsuite.foundry.project config-id gsetting
# taking into account all layers
$ foundry settings get project config-id

# Sets the config-id setting for just this user
$ foundry settings set project config-id "'org.example.app.json'"

# Sets the config-id for the project default which might
# be useful if you ship multiple flatpak manifest like GTK does
$ foundry settings set --project project config-id "'org.example.app.json'"

# Or maybe set a default for the app
$ foundry settings set --global project stop-signal SIGKILL


That code is now wired up to the FoundryContext via foundry_context_load_settings().

Next time I hope to cover the various sub-systems you might need in an IDE and how those services are broken down in Foundry.

13 Dec 2024 5:22pm GMT

Its been an interesting and cold month so far. I made a successful trip to the UK, one of the first times I've been back in winter and avoided being exposed to COVID19 since the pandemic, so that's a step forwards.

I've been thinking a lot about documentation recently in a few different places where I work or contribute as a volunteer. One such place is within openQA and the GNOME QA initiative, so here's what's been happening there recently.

The monthly Linux QA call is one of my 2024 success stories. The goal of the call is to foster collaboration between distros and upstreams, so that we share testing effort rather than duplicating it, and we get issue reports upstream as soon as things break. Through this call I've met many of the key people who are do automated testing of GNOME downstream, and we are starting to share ideas for the future.

What I want for GNOME is to be able to run QA tests for any open merge request, so we can spot regressions before they even land. As part of the STF+GNOME+Codethink collaboration we got a working prototype of upstream QA for GNOME Shell, but to move beyond a prototype, we need to build a more solid foundation. The current GNOME Shell prototype has about 100 lines of copy-pasted openQA code to set up the VM, and this would need to be copied into every other GNOME module where we might run QA tests. I very much do not want so many copies of one piece of code.

I mentioned this in the QA call and Oli Kurz, who is the openQA product owner at openSUSE, proposed that we put the setup logic directly into os-autoinst, which is openQA's test runner. The os-autoinst code has a bare 'basetest' module which must be customed for the OS under test. Each distro maintains their own infrastructure on top of that to wait for the desktop to start, log in as a user, and so on.

Since most of us test Linux, we can reasonably add a more specific base class specific to Linux, and some further helpers for systemd-based OSes. I love this idea as we could now share improvements between all the different QA teams.

So the base test class can be extended, but how do we document its capabilities? I find openQA's existing documentation pretty overwhelming as a single 50,000 word document. It's not feasible for me to totally rework the documentation, but if we're going to collaborate upstream then we need to have some way to document the new base classes.

Of course I also wrote some GNOME specific documentation for QA; but hidden docs like this are doomed to become obsolete. I began adding a section on testing to the GNOME developer guide, but I've had no feedback at all on the merge request, so this effort seems like a dead end.

So what should we do to make the QA infrastructure easier to understand? Let me know your ideas below.

Looking at the problem from another angle, we still lack a collective understanding of what what openQA is and why you might use it. As a small step towards making this clearer, I wrote a comparison of four testing tools which you can read here. And at Oli's suggestion I proposed a new Wikipedia page for openQA.

Please suggest changes here or in the openQA matrix channel. If you're reading this and are a Wikipedia reviewer, then I would greatly appreciate a review so we can publish the new page. We could then also add openQA to the Wikipedia "Comparison of GUI testing tools". Through small efforts like this we can hopefully reduce how much documentation is needed on the GNOME side, as we won't need to start at "what even is openQA".

I have a lot more to say about documentation but that will have to wait for next month. Enjoy the festive season and I hope your 2025 gets off to a good start!

13 Dec 2024 11:39am GMT