If you are familiar with GNOME Boxes internals you are aware that our secret sauce is libosinfo. It does the OS image detection and provides us with a database of devices, preferences, and compatibility for the operating systems we support.
In the world of traditional package management tools, osinfo-db is the package responsible for delivering updates about new operating system’s releases, fixes, and improvements that Boxes will consume. So whenever you wonder why the newest EndlessOS or the newest Debian release isn’t listed in the Boxes download section, it is likely that osinfo-db is outdated.
The pipeline from upstream -> distros -> to users is extremely valuable for apps and libraries. It is our “integration testing” phase. But for data-only packages like osinfo-db, we noticed that most users’ complains are regarding the package being outdated. We rarely see bugs introduced by osinfo-db updates. The very separation of the dataset (osinfo-db) and the library (libosinfo) is the reason for us to feel confident about contentiously delivering the dataset directly to our users.
For this reason, Flatpak users of GNOME Boxes will now benefit from the OsinfoDb Flatpak extension. It allows us to deliver osinfo-db updates direclty to users without updating the entire Boxes Flatpak. If you are receiving automatic updates in GNOME Software, the osinfo-db update is seamlessly.
Boxes still bundles its own osinfo-db data for those that don’t want to consume the extension. This will be updated whenever the Boxes Flatpak is updated, so expect it in a slower cadence.
Nothing is required from users to transition to this. Flatpak will pull the extension for you once you update Boxes.
This year’s edition was once again a blast. The best opportunity to put faces into the names we interact daily throughout the communication channels of our community, and to meet new folk.
Once again a volunteer, this year a chaired the sessions in the auditorium during the first day, organized one of the newcomers activities, and the football game. Don’t forget to check out the conference photos.
Lots of work got done, as you must have read from other posts in Planet GNOME. It was no different for Boxes. Our annual Birds of a Feather session was more of a whole afternoon chat under the shadow in front of the university cafeteria. We managed to count with the presence of very experienced members of our community to give us some valuable insights on how we can sanely introduce new features and optimize the existing ones.
We discussed the challenges and possibilities of the OVF support, enabling us to Import and Export virtualization appliances allowing users to easily share their VMs with each other, and perform migrations and backups. That is work that has already started and will be partially shipped in 3.30, and later complemented in the next cycle.
There we often heard of feature requests for enhancements we already landed. Therefore justifying my recent work in the new machine assistant to make the “Download an OS” page, and remote connections more discoverable. Expect more work in this area, making it easier for users to find and benefit from features we already have, such as: bridged network, file sharing, clipboard integration, notifications passthrough, multiple brokers, etc…
Another relevant topic fairly discussed during our meeting was the integration of Boxes into the Purism mobile development workflow as a simulator in which they could easily run their Flatpak bundles built with GNOME Builder. Alberto Fanjul participated in the discussions describing their requirements and suggesting features. Expect some interesting work in this regard for our next development cycle.
A few more specific topics were discussed related to changes under the hood related to speeding up things and making some processes more fail-proof.
GUADEC was also an opportunity for me to meet our Google Summer of Code mentee Adi Manglik, and chat about his challenges adding Power consumption capabilities to GNOME Usage and of being a newcomer in our community.
I would like to thank the GUADEC organizers for hosting an amazing conference. The Social Events were great, from the sangria at the beach party to the guided tour to Alcazaba ending with a delightful party at the sunset with incredible flamenco dances, it is all fantastic with friends.
Last but not least, I’d like to thank my employer Red Hat for sponsoring my trip! I hope to see you all again very soon!
Just passing by to say that I am looking forward to see you all later this week in Almeria. The conference program sounds very promising and the host city is looking outstanding.
I have to admit that Boxes is a bit late for the Flatpak party, but that’s not a problem. The technical difficulties of getting a virtualization hypervisor to run inside the flatpak sandbox are mostly overcomed. This way, contributing to Boxes has never been easier.
In the following sections I will describe the step-by-step process of making your first code contribution to GNOME Boxes.
Get GNOME Builder
Builder makes it very easy to download and build GNOME applications with just a couple of clicks. It will also make your life easier while writing the code.
That’s it! Now that you have the project built and can run it, we can start looking into fixing bugs.
Finding an issue to hack
You can have an overview of the ongoing work in the project by browsing our kanban board. We also have issues tagged as Newcomers if you are making your first contribution and want to start hacking on something easy.
Create a GitLab account and fork the project
Visit gitlab.gnome.org and create an account. GitLab will pop up a banner asking you to add your SSH keys to your profile, or you can go directly to edit your profile.
After your profile has been properly setup, it is time to fork the project!
Go to the Boxes project page and click the Fork button. This will create your own copy of the git repository under your personal namespace in GitLab.
Finally, get your fork URL and add to your local git repository as a remote:
git remote add fork $project_url
Making changes and submitting your code
After building Boxes and finding an issue to work, it is time to dive into the codebase. Edit the files and press the GNOME Builder “play” button to see your changes take effect.
A message with a link to create a merge request will be printed in your terminal. Click it, describe your changes, and Submit!
3. Follow up on the feedback
Me and other developers will review your work and recommend changes if necessary. We will iterate over and over until your contributions are ready to be merged.
4. Celebrate your first contribution!
Further reading
The steps described above are based on the GNOME Newcomers initiative. We have a detailed step-by-step process of making contributions and you should definitely check it out. It has pointers about documentation, tips about finding the right approach to dive into the code base, and examples.
It might seem at first sight that Boxes is a simple application, and that is partially true if you ignore the deep stack under the hood responsible for making virtualization simple™. The various modules (some of them gigantic such as qemu, libvirt, freerdp…) need to be setup in perfect harmony for us to boot a whole operating system with its essential functionalities.
The GNU/Linux distribution model has historically delegated to downstream packagers the responsibility of integrating dependencies in order to provide an application to their end users. This model has worked for some for many decades, but it has fundamental flaws that “trickle down” making the upstream developers’ life miserable.
Don’t get me wrong, bugs are mostly our fault, but a significant amount of bug reports I receive consist of issues I cannot reproduce in my development environment. A combinatorial explosion of package versions, build flags, and/or pivotal architecture differences between distros.
Therefore this is the first and foremost benefit we get from shipping Boxes as a Flatpak.
Another difficulty we face during our development cycle is having the ability of having designers, translators, and marketing folk being able to run our latest snapshot or a specific work-in-progress tree. With the GitLab continuous integration combined with Flatpak we can spin bundles at any moment, and they can be installed within a couple of clicks, alongside other versions of the same app! This is The Future!
Having our apps widely available is another concern we have. Many distributions which stick to the package model also support Flatpak. Besides that, there are new players which are essentially different. Container-based desktop operating systems are a thing now too.
Software is never done…
There are indeed downsides of running Boxes in a Flatpak in comparison with a well crafted build of dependencies bottom-up. But these are issues that can be solved and are going to be prioritized in our TODO list.
Running Boxes in a Flatpak TODAY you won’t have yet:
A bridged network between host and guests.
The ability of installing an image from a physical device.
Access to your system’s libvirtd (we run our own libvirtd in the sandbox).
Shared folders.
USB redirection.
$YOUR_ISSUE_HERE
The list above is far from complete, and I would like to count on you to experiment with the Flatpak and report issues you might encounter. Use the label “flatpak” to collect points which you can later exchange for beers or other beverages of your choice. 😉
This blog post is outdated. After a couple of years we decided to move remote connections into a standalone application. GNOME Connections. Read more about it at https://feborg.es/announcing-gnome-connections
Boxes has been the go-to option for easy virtual machine setups in GNOME for quite some time, but some people don’t know that our beloved application can also act as a remote viewer.
The “Enter URL” option in the new machine assistant is how you get a new remote machine added to your collection. It supports addresses of Spice and VNC servers and oVirt and Libvirt brokers. You can also paste the URL of an operating system image (iso, img, qcow, etc…) and Boxes will download and boot it for you.
However, there is life out of our GNU/Linux boxes and we need to stay connected. Windows is extremely popular and it ships a RDP server by default, making the adoption of open alternatives a bit unhandy there.
Imagine you have clients running Windows that need your remote support, or you couldn’t convince your family back home to switch to GNU/Linux, etc…
This feature is powered by FreeRDP. For convenience, I wrote a glib wrapper around the essential freerdp API so we can consume it via gobject-introspection in GNOME Boxes and others could reuse it for their own applications.
Heavily inspired in the gtk-vnc API, I decided to name it gtk-frdp. So original! 😉
If you are interested in writing a RDP client of your own, or maybe port an existent one to gtk-frdp, you can achieve it with a few lines of code such as below (I choose Python for legibility, but it could be any gobject-introspected language of your choice).
It is been a long time coming, but I finally decided to take a moment to summarize the Boxes happenings in the last six months. And a lot has happened!
Firstly, I haven’t stated in this blog that I am maintaining Boxes for the last couple of releases. It’s been an exciting learning journey and I cannot thank Zeeshan Ali enough for paving the way for me.
3.28 has many internal changes and enhancements worth enumerating, therefore I am going to highlight the most relevant ones IMO.
Distro hoping was my hobby back in the days when distros were really different from each other. I feel that this is somehow coming back now with new players targeting the desktop market, such as Endless OS and Pop!_OS.
Boxes intents to make it easy for people to try new operating systems from the comfort of their current system. Whether you want to explore, run something in a contained environment, perform something risky and easily recover your installation, Boxes wants to make it simple.
Libgd was an experimental ground for us to introduce many widgets, including our re-sizable icon views with their selection-mode and convenient API. Boxes no longer needs libgd for that since Gtk+ has been evolving along the years and more modern widgets have been gradually introduced.
We ported the notifications from GdNotifications to GtkRevealer, and now the content views are GtkFlowBox and GtkListBox.
Visually it should look no different to the end-user, but for developers it means a significant code simplification.
The migration to GitLab is another bit that shouldn’t make a difference from an end-user point of view, but is indeed a big deal for everyone involved in development.
The word is that nobody ever wrote autotools files from the scratch, ever, but copied from an existing working project and tweaked it. I am no different. My understanding of autotools has been always superficial despite trying to learn it a few times.
No disrespect for those who came before. I acknowledge the needs of ancient times and I wouldn’t bash more something that’s so far from my domain.
The learning curve for Meson made me finally have the motivation to understand build systems. The cleanness of syntax and file structure is definitely medicine for my organizational obsession.
Special thanks to Iñigo Martínez for his dedication to help porting many of our components to Meson.
Handle mime-types
Yep yep, double click on an image/iso file and install!
That’s All Folks!
Many bugfixes landed in this cycle, so I encourage you to check it out.
GNOME Boxes 3.28 is the resulting work of 57 contributors!
This time we are enabling you to install many other operating system virtual machines right from inside Boxes. A moving picture is better than words, so watch the preview below:
The list is populated by libosinfo, which gets updated shortly after every new OS release. If you don’t see your favorite distro there, please send us a patch.
This feature will feature GNOME 3.28.
Happy virtualization!