Fedora: Laptop Hardware Enablement (hint: we’re hiring)

So, since September I have¬†transitioned to a new job, from¬†working on Fleet Commander full time with Oliver, to managing a¬†team whose job is to make sure that a number of laptops (to be defined) are well supported in Fedora, and therefore upstream kernel, Wayland, MESA and GNOME. I’m honored to be working among great people in this space: Hans de Goede, Peter Jones, Christian Kellner and Benjamin Berg.

If you want more details as to the plans of the team, please watch the talk Hans gave at DevConf that you can watch on YouTube.

Of course, I’ll still be managing the Fleet Commander project, which is coming along pretty nicely. Currently Oliver is focusing on the FreeIPA integration.

By the way, I’m hiring a Senior Software Engineer for the team, we’re looking for someone with consumer & enterprise ¬†hardware enablement related skills to help with TPM2 support for x86_64, POWER and ARM in Fedora, people willing to work from Munich are preferred, but we’re open to strong candidates¬†working remotely, if you think this is for you¬†get in touch with me and/or apply.


Rust ūüĖ§ GNOME Hackfest – Mexico City, 2017

Glorieta del √Āngel de la Independencia, Credits: laap mx@flicker cc-by-nc-nd

As you know a bunch of GNOMies have been in touch with Rustaceans to improve the Rust and GNOME binding integration. To accelerate the effort, we have decided to organize a hackfest soon-ish. After¬†some digging and given that the great Federico has been involved in the effort we’ve figured that it was rather poetic to do it in Mexico City, birthplace of GNOME! Check out the wiki page for more details.

We will be meeting at the Red Hat office from the 29th to the 31st of March to try to advance the state of GObject bindings and try to make Rust emit GObject code as well. Get in touch with me or Federico if you want to attend!


First Rust+GObject coding session

Last Wednesday, Nicholas Matsakis from Rust/Mozilla and I sat down on a video chat to start getting our hands dirty on moving ahead with making Rust a part of the GNOME ecosystem.

While there are two efforts to produce GNOME bindings for Rust, gi-rust and gtk-rs, however none of them provided the means to emit GObject subclases so we decided to tackle this problem.

During the first half of the session we reviewed how GObjects are created from C, I used Vala’s output to illustrate how this is done. We didn’t dive¬†on too much detail on how properties and signals are emitted nor interfaces, however¬†we focused on detail on how to inherit from a GObject.

After that we went ahead and wrote what, probably, is the first piece of Rust code that emits a GObject in this playground repo. Nothing too fancy, but a starting point to get us somewhere.

The next step is to figure out how to take this and turn it into something that a Rust developer would find Rust-like. One of the options we’re exploring is to use Rust macros and try something like this:

  class Foo : Bar {
    fn method_a () -> u8 {

The other alternative would be to decorate structs, traits and whatnot, but this would be a bit more cumbersome. Turns out that Rust’s macro system is quite powerful and allows you to define a custom syntax.

That’s the progress so far, the next step would be to try to start implementing¬†some bits and pieces for the macro and see how far we can get.¬†I’d like to thank Mozilla and Nicholas specially for the amount of attention and effort they are putting into this, I must say I’m quite excited and looking forward to make progress on this effort.

Stay tuned, and if you’d like to help don’t hesitate to reach out to us!

Thoughts on DX: GNOME and Rust

A few months ago I spent some time to learn some basic Rust, I was interested in¬†getting an informed view of the language, specifically about the¬†safety and concurrency idioms as well as its compatibility with the C ABI and automatic memory management¬†while being¬†non GCed. I must say I was pleasantly surprised with the tooling, cargo is a breeze and crates.io is a wonderful resource. More recently though I’ve been investing time to actually understand¬†the memory ownership model and how it plays with channels/concurrency. I must say that what these guys have achieved is really clever with a language that once you get the grasp of things feels actually really nice to use.


For a long while now I’ve been worried that the GNOME project would struggle to grow its contribution and stay attractive if it stuck to C in the long run (i.e. next 10-20 years). GObject hasn’t really caught on beyond the GNOME ecosystem. So we’re basically maintaining a whole low level framework, and we have to come up with something by ourselves everytime a new technology comes in (i.e. JSON, REST…). Given our limited resources, I’ve been wondering if there are better alternatives.

For people wanting to contribute to the core libraries consumed by the ecosystem, the only options are C and Vala.¬†Vala has been a great tool for prototyping, I love it myself, but¬†debugging it is a nightmare, it’s filled with security issues and even if we fixed those really difficult problems, we’d be maintaining our own language on top of everything else. I would like to see us maintaining less stuff other than a desktop and the application development framework, not more.

I trully believe Rust gives us a way out of this situation, with certain nice side benefits, Rust really ticks¬†most boxes: C ABI compatibility, safety, modern syntax, vibrant community, ever growing set of libraries and tools and a culturally aligned organization backing it: Mozilla. So when Federico made the brave step of start using it in one of our libraries I was very encouraged by the notion that this might actually happen. I’ve been pleasantly surprised to see positive reactions to his effort by many core developers on twitter.

Now, imagine for a moment, that we decide to somewhat¬†embrace Rust in our libraries, and we start adopting it in places like GTK+. Suddenly we have the opportunity to engage in the¬†growing enthusiasm around Rust, and we have a channel to technologies and tools being built outside of our own community such as WebRenderer,¬†Servo…

Additionally, we release ourselves from the burden of maintaining core libraries for everything so we can focus on producing a great desktop and application development story.

Ultimately though, there are many challenges, achieving full GObject compatibility can be difficult, we would need to be able to consume GI bindings from Rust and eventually emit GI bindings too, and in the end it would be up to the core of the community to lead an effort like this so there needs to be consensus too. It is quite a bit of work, but I believe it is worth considering as it might give us back a lot resources to focus on other stuff.

Please don’t read this as a formal proposal, I think something like that should come,¬†I’m mostly putting my thoughts on this out there and see what the rest of the community thinks.

Need an ARM board to do GNOME development?

Now that the donations are in, it’s time to start putting them to use. If there’s any cool project you would like to use one of the available ARM boards or if you’re interested in doing enablement of those boards to make GNOME run on them please get in touch with me on IRC or drop me a line at aruiz¬† gnome org.

I have to note that requests to use them as your home server or for non-GNOME related stuff are discouraged, these boards were donated with the purpose of improving support for the ARM ecosystem in GNOME.

Here’s the list of the HW and who has them.

There are a few Banana Pi available (most with a Mali 400 GPU and two BPi M2s with a PowerVR SGX54MP2), so these are trickier to get GNOME Shell running on, if anyone enjoys reverse engineering GPUs, Malis are very popular these days and they get very little love as the Lima project is a bit silent for some time now. People looking into porting llvmpipe to ARM are also more than welcome!

As per the Qualcomm boards, they run with the freedreno driver (by the way, props to Rob Clark for his amazing work on this driver) and I was able to run a GNOME on Wayland  on them using the official Debian image, so they are more suitable if you want to focus on the upper layers of the stack.

I would like to reiterate my gratitude to Banana Pi and Qualcomm for their generosity for the hardware, as well as ARM and Codethink for the server side stuff that is already being used in our GNOME Continuous efforts.

And of course, I’m going to GUADEC! I’ll be taking the boards with me, so if you think you have something interesting to do with them and you are attending just find me around.


GNOME Foundation is looking for ARMv7 hardware

The GNOME Continuous effort is proving a great way for the project to achieve, however right now we’re only building and testing things on Intel based architectures. As ARM devices like the Raspberry Pis, Cubieboards, C.H.I.P.s and the just announced Endless Mini become more prominent we want to make sure GNOME software is ready for those platforms as well to the extent possible.
gnomelovesarmSo I have asked the board for permission to try to reach out to organizations willing to donate ARMv7 servers to the GNOME Foundation for our continuous infrastructure. If you know of any organization (company, foundation, university…) with access to such hardware that might be willing to lend or donate it to us please get in touch with me at aruiz at gnome dot org.

Note that we don’t really need physical access to the hardware as long as it’s connected 24/7 on a decent internet connection.

Thanks a lot!

Updates on GNOME Calculator

GtkBuilder templates

Last GUADEC Michael Catanzaro asked for help out loud trying to find a new maintainer and I decided to take the bullet. For a couple of months I felt a bit guilty since I was merely doing new tarballs containing pretty much just translations.

However at some point a couple of months ago I sat down and started reviewing patches people were submitting and got up to speed with the current state in bugzilla, the review process allowed me to get familiar enough with the codebase to start finding things I would enjoy doing.

The biggest task I’ve been trying to accomplish is to move all the UI code to GtkBuilder .ui files and rework the codebase to use them as reusable templates. Vala has great support for this, here’s an example on how to create a MathWindow class, with a widget as a private member and a callback:

This has allowed me to remove quite a few lines of code making the project a bit more maintainable. It has been also a good opportunity to get familiar with gresource

DX Hackfest & XDG App

During the DX hackfest I spent some time to package GNOME Calculator as an XDG App, the only problem the app had was that it was using gvfs to retrieve currency data from the network. I ported this to ye’olde libsoup and everything went on smoothly. On the third day I caught a bad case of food poisoning so on the last day of the hackfest I was rather useless.

I would like to thank Philip Withnall for organizing the hackfest, Javier Hernandez for hosting me in his couch, our friends from the Betacowork space in Brussels for coping yet another year with the GNOME and LibreOffice hackers, and the GNOME Foundation as well as many other companies for sponsoring people to attend.