Planet GNOME

I honestly wasn’t sure I was going to make it to GUADEC.

For months, the travel committee and I had been going back and forth trying to get all the documents needed for my visa application. The visa took longer than expected. I even lost hope at some point, and eventually got it just four days before my travel date.

This was my first GUADEC, and I was really looking forward to finally meeting the GNOME community in person.

I was also going to give a talk about my Outreachy project, which was probably something I should have been more nervous about than I was.

So between getting everything ready at the last minute, travelling from Kenya to Spain, and preparing for my talk, there was quite a lot going on.

But I made it to A Coruña.

Appreciation

I want to appreciate the people who made it possible for me to be there.

A big thank you to the GUADEC organizers and volunteers for all the work they put into making the event happen. I know there is a lot of work that goes on behind the scenes, and I really appreciate the time and effort that went into making everyone feel welcome.

I also want to especially thank the travel committee. I know the visa process wasn’t straightforward, and they spent months helping me get the right documents together and working through everything with me. Getting the visa just four days before my trip made the whole process even more stressful, so I really appreciate that they didn’t give up on it.

And of course, I want to thank my mentor, Lucas Baudin, for the support and guidance throughout my Outreachy internship. Having someone to learn from and ask questions along the way made the experience much easier.

Meeting the GNOME Community

This was probably the part I was most excited about.

For months, I had interacted with people through GitLab, Matrix, emails, and meetings, and it felt so nice to finally meet them in person.

I got to meet contributors from different parts of the GNOME community, and I loved hearing about what everyone was working on. Some conversations were technical, some were about the community, and some had absolutely nothing to do with GNOME.

I came to GUADEC wanting to meet the community.

I definitely did.

Sharing My Outreachy Experience

I also got the opportunity to speak about my Outreachy project during GUADEC.

During my internship, I had been working on Papers, improving its document signing features. Most of the work happened from my laptop in Kenya, so being able to stand in front of the GNOME community and share what I had been working on felt a little strange, in a good way.

Outreachy gave me the opportunity to contribute to a project I hadn’t worked on before, but it also taught me a lot about working in an open source community.

Giving the talk was definitely one of the highlights of GUADEC for me. I was a little nervous before getting on stage, but once I started, it felt much easier than I had expected.

What I liked most was the conversations afterwards. Different contributors came up to ask questions and share their thoughts, and it was really nice to continue those conversations outside the presentation.

Learning and Sharing

Throughout the conference, I attended talks covering a wide range of topics, including GNOME development, design, accessibility, and the future of the project.

I got to learn about projects I had never come across before, which was one of the things I really enjoyed. There was always something new to discover.

I also appreciated seeing how diverse the GNOME community is, and how much the community cares about making GNOME a welcoming and inclusive space for people from different backgrounds. Coming from Kenya, it was especially nice to see people from different parts of the world coming together around the same project.

Bringing the Experience Back to Kenya

Returning home, I wanted to ensure that the knowledge and inspiration I gained at GUADEC would benefit others as well.

I recently started the GNOME Kenya community, where we hope to introduce more people to GNOME and open source contribution. We are beginning with translation efforts while also encouraging contributors to explore development, documentation, design, and other areas that match their interests.

We are also having our first meetup soon, where we will officially introduce GNOME Kenya and GNOME to the community in Kenya.

My goal is to make GNOME more accessible to new contributors in Kenya and help build a sustainable local community that contributes back to the global project.

Looking Ahead

I came back from GUADEC with a lot to think about, and even more excitement to keep contributing to GNOME.

 I look forward to contributing more, supporting new contributors, and hopefully attending future GUADECs, InshaAllah!

The timeline for Google Summer of Code is coming to an end, and us interns are piecing together the final touches to our projects for submission. Thanks to the help of my mentors, and the duck sitting on my monitor, the algorithm that beats the heart of Vocab Crosswords in GNOME Crosswords has been tremendous strides in accuracy and testability. The primary focus shifted to getting the algorithm landed by the end of the summer, and working on the frontend of the application post-GSoC.

Unit Tests

At GUADEC, with the help of Federico, I created unit tests to see how my functions reacted in a given circumstance. Jonathan and I worked on creating different circumstances for the run and helper functions.

Optimization

For user optimization, we don’t want to keep the board at a strict 30×30 grid and only allow for the first viable option. We decided to incorporate a new function to trim the dimensions of the generated grids based on the outermost edges of the letters, create a new board based on the newly calculated dimensions, trim that board down respectively, and copy the words over in the exact respective format. This is due to the libipuz grid’s origin point (0, 0) being fixed at the uppermost left corner cell. All in all, the trimming function essentially does this:

Additionally, it is pretty ideal to have some leeway of choice on how you want your puzzle to look. Some puzzles might generate lanky, while others extensively branched out all the way to the maximum borders, and the rest perhaps condensed together. The ability to rearrange the ordering of the words is already a feature in Crosswords thanks to PuzzleTask. But, it is for known grids of typically 15×15 sandwiched together. What is different with the vocab puzzle is that the rearrangement must still respect the same constraints of intersecting at a single letter nodal point, words cannot be on top of nor right next to each other (edge of nodes must respect space), and no islands (all words must share at least one node with another word). For instance, grids A and B here pertain the same words 1 through 6, but these words can connect differently on the graph, producing two options to choose from.

Tested, I achieved these 3 different versions of grids based off the same word bank:

           

Island Checking

The final component I will implement within GSoC’s timeline is checking for islanding words. Say a user provides a list of words and one word absolutely cannot intersect with any other word, it shares no node. The backtracking algorithm will spend a lot of time trying to place it, or invalidate any graph generation at all. We want to check beforehand if a word would not belong along the rest, and warn the user about it. Because there are many alphabets that exist, we are going to analyze the sets of characters as guint64 bitsets and GHashTable. Every unique character gets its own bit-slot, and every word’s 64-bit mask is compared to available words using bit operations.

I’m happy to announce that the SparkleShare project will receive a grant from the NLnet Foundation’s NGI0 Commons fund!

SparkleShare and NGI0 Commons Sync files with Git

SparkleShare is a Free and Open Source collaboration app. It allows people who are not software developers or otherwise technical (designers, lawyers, students, academics, etc.) to work together and share files in projects that use the Git version control system.

SparkleShare provides an automatic sync algorithm and a friendly user interface to review changes and restore files from history.

What happened?

SparkleShare has been around since 2010. I guess that makes it an “old” project now… Since then, the Mono/C# community active around that time has all but disbanded. The platform underneath slowly started to rot.

Eventually the app had to be removed from Flathub, also due to my own maintainer burnout. Providing maintenance and support next to a full-time job proved too much.

But that’s no longer an issue.

Now I have an opportunity to rebuild and address long-standing issues and feature requests. I have renewed energy to bring back the project better than ever!

The work

The funding proposal is to finish porting to Rust, bring SparkleShare in line with modern security and privacy practices, and design a fresh user interface informed by years worth of community feedback.

The goal is to get a Linux release back on Flathub. I’m planning to post frequent updates, so subscribe or follow me on GitHub or the Fediverse.

In these turbulent times, one frequently needs to run some tooling in a sandbox. The goal is mainly to reduce the blast radius: make it so programs within the sandbox cannot damage the host system (e.g. delete or overwrite something unintended), but also, to a lesser extent, to hide most of the filesystem to avoid exfiltrating sensitive data.

Recently, Bartosz Taudul (of Tracy fame) showed how to use systemd-nspawn for this purpose. He creates a container configuration, installs a distro inside, and bind-mounts some cache and project folders from the host. The mounts have an overlayfs on top, so within the container, tools can write over the files, but those writes do not affect the host filesystem.

I also want to share my sandboxing approach. My goal was to make it easy to use and reduce friction as much as possible, so that I always have a sandbox at my fingertips.

The result boils down to spawning a container-like environment, sharing enough of the host filesystem read-only to make all host binaries runnable, and sharing the current working directory read-write. Within this sandbox, you don’t need to install a separate distro—everything from your host just works, while the filesystem is kept mostly isolated (except for the folder where you run the sandbox).

For example, I’ll run the script in a Tracy checkout.

┌ ((8c8d451a)) ~/s/c/tracy └─ box fish Welcome to fish, the friendly interactive shell Type help for instructions on how to use fish yalter@sandbox ~/s/c/tracy>

I can run the build since all my host binaries are accessible:

yalter@sandbox ~/s/c/tracy> meson setup build The Meson build system Version: 1.11.2 Source dir: /home/yalter/source/cpp/tracy Build dir: /home/yalter/source/cpp/tracy/build Build type: native build Project name: tracy Project version: 0.13.1 C++ compiler for the host machine: /usr/bin/ccache c++ (clang 22.1.8 "clang version 22.1.8 (AerynOS)") C++ linker for the host machine: c++ ld.lld 22.1.8 Host machine cpu family: x86_64 Host machine cpu: x86_64 Checking if define "_MSC_VER" exists: NO Run-time dependency threads found: YES Found pkg-config: YES (/usr/bin/pkg-config) 2.5.1 Build targets in project: 1 Found ninja-1.13.2 at /usr/bin/ninja yalter@sandbox ~/s/c/tracy> ninja -C build ninja: Entering directory `build' [2/2] Linking target libtracy.so

The home folder contains the working directory, and is otherwise mostly empty:

yalter@sandbox ~/s/c/tracy> ls -l ~ total 0 drwx------ 4 1000 1000 80 Aug 9 20:20 source/

I can write into the home folder, but the write will go into a tmpfs, and will not affect the host system:

yalter@sandbox ~/s/c/tracy> touch ~/evil yalter@sandbox ~/s/c/tracy> ^D ┌ ((8c8d451a)) ~/s/c/tracy └─ cat ~/evil cat: /home/yalter/evil: No such file or directory

Only changes to the Tracy folder, where I ran the sandbox, persisted on the host, all with correct user ID and everything:

┌ ((8c8d451a)) ~/s/c/tracy └─ ls -l build/ total 28K drwxr-xr-x 1 yalter yalter 48 Aug 9 20:21 libtracy.so.p drwxr-xr-x 1 yalter yalter 496 Aug 9 20:21 meson-info drwxr-xr-x 1 yalter yalter 56 Aug 9 20:21 meson-logs drwxr-xr-x 1 yalter yalter 310 Aug 9 20:21 meson-private drwxr-xr-x 1 yalter yalter 40 Aug 9 20:21 meson-uninstalled -rw-r--r-- 1 yalter yalter 5,3K Aug 9 20:21 build.ninja -rw-r--r-- 1 yalter yalter 545 Aug 9 20:21 compile_commands.json -rwxr-xr-x 1 yalter yalter 14K Aug 9 20:21 libtracy.so The box script #

I use Bubblewrap to spawn the sandbox. This is an unprivileged sandboxing tool used by Flatpak (though, I hear there are plans to replace it with something else).

The script itself composes a long bwrap invocation. Let’s look at some of the parts.

#!/usr/bin/env bash set -euo pipefail # Export ALLOW_NET=0 to disable network access inside the sandbox. # # Keep in mind that if your X11/Xwayland doesn't check Xauth, # then network access lets the sandbox connect to your X11 # via an abstract Unix socket. This is quite dangerous. ALLOW_NET="${ALLOW_NET:-1}" # The current folder that we're binding read-write. REPO="$(readlink -f .)" BWRAP=( bwrap --die-with-parent # Unshare (isolate) a bunch of things inside the sandbox. --unshare-pid --unshare-uts --unshare-cgroup-try --unshare-user-try --cap-drop ALL # Create/mount important folders. --proc /proc --dev /dev --tmpfs /tmp --tmpfs /var --dir /run --dir /etc --hostname sandbox # Warning: this script shares all environment variables. # If on your system the environment can contain secrets, # you may want to clear them: # --clearenv # Bind the current folder read-write and chdir there. --bind "$REPO" "$REPO" --chdir "$REPO" ) # --- Read-only system binds --- SYS_RO_BINDS=( # Folders with binaries and libraries. /usr /bin /sbin /lib /lib64 # Random configuration files that programs tend to need. /etc/alternatives /etc/nsswitch.conf /etc/hosts /etc/localtime /etc/timezone /etc/pki /etc/ca-certificates /etc/ssl /etc/crypto-policies /etc/fonts # I fill these as I bump into problems, more or less. /etc/java /etc/texlive /var/lib/texmf /usr/lib/jvm /usr/share/java ) # Bind all of them read-only. for p in "${SYS_RO_BINDS[@]}"; do [[ -e "$p" ]] && BWRAP+=( --ro-bind "$p" "$p" ) done BWRAP+=( --ro-bind-try /etc/ld.so.cache /etc/ld.so.cache ) # resolv.conf is fun because it's a symlink into /run, # a folder which we do not want to expose. RESOLV_REAL="$(readlink -f /etc/resolv.conf 2>/dev/null || true)" if [[ -n "$RESOLV_REAL" && -f "$RESOLV_REAL" ]]; then BWRAP+=( --ro-bind "$RESOLV_REAL" /etc/resolv.conf ) fi # Unshare the network if needed. if [[ "$ALLOW_NET" -eq 0 ]]; then BWRAP+=( --unshare-net ) fi # Create a fresh home directory. # The username and the path is the same as on the host # so that everything keeps working. BWRAP+=( --setenv HOME "$HOME" --dir "$HOME" ) # --- Home read-only binds --- HOME_RO_BINDS=( .cargo/bin .cargo/config.toml .local/bin .local/lib/node_modules .rustup .fonts .local/share/fonts .local/share/nvim/site/parser .gitconfig .config/git .config/tmux .cache/ms-playwright .cache/corepack ) for rel in "${HOME_RO_BINDS[@]}"; do [[ -e "$HOME/$rel" ]] && BWRAP+=( --ro-bind "$HOME/$rel" "$HOME/$rel" ) done # --- Home overlays --- # The sandbox can write here, but the changes # will not affect the host filesystem. HOME_TMP_OVERLAYS=( .cache/fontconfig .cargo/registry .cargo/git .gradle .npm .cache/npm .local/share/pnpm/store .cache/yarn .cache/cpm .texlive2023 ) for rel in "${HOME_TMP_OVERLAYS[@]}"; do [[ -d "$HOME/$rel" ]] && BWRAP+=( --overlay-src "$HOME/$rel" --tmp-overlay "$HOME/$rel" ) done # Set up $PATH with the paths that we have inside this sandbox. BWRAP+=( --setenv PATH "$HOME/.cargo/bin:$HOME/.local/bin:/usr/local/bin:/usr/bin:/bin" ) # Execute our big commandline and pass it # the rest of the arguments (the command to run). CMD=( "${@:-bash}" ) exec "${BWRAP[@]}" "${CMD[@]}"

Many lines, but most of them are just listing directories to mount.

If you want to run GUI apps in the sandbox, you’ll need to create an XDG_RUNTIME_DIR and mount a Wayland socket:

# Export PASS_WAYLAND=1 to enable Wayland access. # Warning: it is currently NOT SANDBOXED (e.g. with security-context protocol). # See https://niri-wm.github.io/niri/Security-Model.html#unsandboxed-clients # for an example of what that implies. PASS_WAYLAND="${PASS_WAYLAND:-0}" # Export PASS_DRI=1 to enable DRI (GPU) access for hardware acceleration. PASS_DRI="${PASS_DRI:-0}" # Export PASS_X11=1 to enable X11 (Xwayland) access. PASS_X11="${PASS_X11:-0}" if [[ "$PASS_DRI" -eq 1 && -d /dev/dri ]]; then BWRAP+=( --dev-bind /dev/dri /dev/dri ) fi # EGL complains without this. BWRAP+=( --ro-bind /sys /sys ) # Wayland: bind only the socket into a fresh runtime dir. XDG_RT="${XDG_RUNTIME_DIR:-}" WAYLAND_SOCK="${WAYLAND_DISPLAY:-wayland-0}" if [[ "$PASS_WAYLAND" -eq 1 && -n "$XDG_RT" && -S "$XDG_RT/$WAYLAND_SOCK" ]]; then BWRAP+=( --dir /run/user --dir /run/user/1000-sbox --bind "$XDG_RT/$WAYLAND_SOCK" "/run/user/1000-sbox/$WAYLAND_SOCK" --setenv XDG_RUNTIME_DIR /run/user/1000-sbox --setenv WAYLAND_DISPLAY "$WAYLAND_SOCK" ) else BWRAP+=( --unsetenv WAYLAND_DISPLAY ) fi # X11. DISPLAY_VAR="${DISPLAY:-}" if [[ "$PASS_X11" -eq 1 && -n "$DISPLAY_VAR" && -d /tmp/.X11-unix ]]; then BWRAP+=( --ro-bind /tmp/.X11-unix /tmp/.X11-unix --setenv DISPLAY "$DISPLAY_VAR" ) else # Make it harder for accidental X11: unset DISPLAY. BWRAP+=( --unsetenv DISPLAY ) fi

That’s about it for the script. If needed, it’s easy to mount more folders by adding them into one of the arrays. The script doesn’t require elevated privileges to run.

Just remember that the folder where you run it is mounted read-write with the sandbox. When I want to run a dangerous command without affecting the files in the repository I’m working on, I just make a temporary copy:

project > cd .. > git clone project project2 > cd project2 project2 > box fish project2@sandbox > ...some dangerous command... ... project2@sandbox > ^D project2 > cd .. > rm -rf project2

Another trick I recently did: I created a read-only GitHub personal access token, and automatically put it into $GH_TOKEN in the sandbox. This way, commands like gh pr list work in the sandbox without having any write access.

Conclusion #

This is very much not a polished tool, but rather a script I’ve been adding on to here and there for several months. I wanted to share it because I think it’s fairly generic (works on both Fedora and AerynOS at least), and avoids a number of pain points with other sandboxing approaches:

• no extra setup required, just one command
• no separate distro installation, uses the host system binaries and libraries directly. As a corollary, anything you build inside this sandbox will work on the host
• no manual folder binding, passes through the current folder
• paths and UID match the host, no broken file permissions
• no sudo needed

One limitation is that I haven’t been able to make podman run inside this sandbox yet. I tried once briefly, but kept hitting weird errors. Maybe it needs some capabilities exposed; not sure.

This is also obviously not intended as a bulletproof sandbox for running fully untrusted code, in fact I wouldn’t be too surprised if I left some gaping holes by mistake (please let me know if I did).

Hey, I’m Philipp. I’m a GNOME Design Team member and I have been contributing to GNOME design as a volunteer for several years. I’m excited to share with you that I have joined the Sovereign Tech Agency as a fellow for GNOME Design & Community Management. Check out the other fellows in the official announcement.

Introduction

I originally started contributing to GNOME to improve the software I use myself. However, what motivates me to stay involved long-term are my political values. Our modern lives, from communication and education to political discourse, are shaped by digital tools, and I believe that it’s essential for a free and democratic society to ensure free and independent access to these technologies. To achieve this goal, end-user devices based on free and open-source software are key, and the GNOME desktop and its app ecosystem offer a powerful alternative to proprietary platforms.

In recent years, I have had the privilege of joining the exceptionally skilled and motivated GNOME community as a volunteer, and have experienced how rewarding it is to contribute to a project with such a broad societal impact. At the same time, it’s been a challenge to find a balance between my job, my contributions to GNOME, and my personal life. I’ve contributed to GNOME in my free time, in the evenings, and during vacations. This two-year fellowship is a great honor and marks a significant change in my life. It is a unique opportunity for me to devote my skills and experience entirely to a project I strongly believe in.

Activities

During my two-year fellowship, I will support GNOME maintainers and developers with design feedback and reviews, create mockups, and coordinate efforts to standardize design patterns. My other activities focus on lasting improvements through two strategic initiatives: expanding the design community to increase capacity and enhancing our design tooling to reduce overhead and simplify onboarding. The following activities may change over the course of the two-year fellowship, as I will adapt them to the needs of the community.

Community growth

I know from my own experience that it is hard to get started with GNOME design. While code contributions are often contained within the boundaries of a single app, design activities spread across multiple projects and often lack a clear entry point or primary contact. Also, not all tasks are newcomer friendly and many require cross‑project knowledge or historical context. I want to make design work more discoverable, simplify onboarding with clear contribution paths and approachable tasks, and retain contributors long term by integrating them into the community.

To attract new contributors, I will increase the visibility of design work by writing regular blog posts, giving presentations, and running workshops at conferences and hackathons. New contribution opportunities for newcomers will be created with clear instructions for independent activities such as collecting state‑of‑the‑art examples, running accessibility and user tests, and creating mockups. Design reviews will be used as mentorship opportunities, pairing regular design contributors with experienced designers for peer review and knowledge sharing. I plan to improve our team governance with clear membership criteria and focus areas, and integrate sustained contributors into the team and its processes. Finally, I want to provide grant writing support to enable contributors to sustain their contributions long-term.

Tooling improvements

User interface mockups are an important tool to communicate with developers. Outdated mockup templates, incomplete documentation, and non‑specialized software create unnecessary overhead, especially for newcomers. Therefore, I will extend and update the mockup templates for our current tool, Inkscape, and evaluate the open‑source UX design tool Penpot for managing our design system. If it proves suitable, I will build a component library to simplify mockup creation and keep assets synced with our stylesheet.

What’s next

I want to blog about my fellowship activities and design work in general, so expect regular updates here. If you’re interested in contributing to GNOME design, check out the Design Team page on the Welcome to GNOME website, familiarize yourself with the Human Interface Guidelines, and join our Matrix channel. If you’re a GNOME developer feel free to reach out to me via Matrix and involve me in design reviews.

Week 27

This week's icon is for Zach Leytus's project:
KawaiiFi: "Wi-Fi scanner and analyzer"

Check out all weekly app icons created so far in the gallery and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Funded by community sponsors (every little helps!).

Week 26

This week's icon is for Sjoerd Stendahl's project:
Lockpicker: "Recover passwords from their hash"

Check out all weekly app icons created so far in the gallery and follow my icon creation adventures as they happen (including sketches) on the Fediverse.

Need icons?

I love designing icons and am happy to contribute them free of charge when your project is Free and Open Source. Funded by community sponsors (every little helps!).

I’m pleased to announce that NVIDIA is now supporting the LVFS as a premier sponsor.

The rollout of the NVIDIA DGX Spark firmware using fwupd is going very well indeed, with downloads continuing to increase every day.

This now takes us to 4 OEMs sponsoring LVFS, which means we’ve successfully reached the funding target we set for ourselves last year. More exciting announcements coming soon!