Fedora26, jhbuild and gnome-shell

Ok, so in my previous previous post I wrote about not being able to restore my build in time. Given the fact that reinstalling the OS would take more time, I took a shot at rebuilding gnome-shell (with the beloved jhbuild, of course) inside a virtual machine, on a Fedora26 OS.

This was the first step towards fixing my issue. As you will see, this post aims at helping newcomers install gnome-shell on their machines by describing all the issues that I encountered while building.

First thing you want to do is read the jhbuild guide that can be found here and then install jhbuild.

Before going further, we have some things to take out of the way. To start with, comands that are bolded are run as a normal user, while the ones that are red are run with root privileges (the only commands that use root privileges are the ones that start with ‘dnf’). Another important color is this weird one (called magenta) which is used for errors (also, the error strings begin with some variation of the ‘error’ string or ‘package not found’).

The next thing you need to know is that whenever some jhbuild command fails, (usually) you will be presented with the following menu (sometimes you get just some of the options, but the ones we’ll use are available everytime):

 [1] Rerun phase configure

 [2] Ignore error and continue to build

 [3] Give up on module

 [4] Start shell

 [5] Reload configuration

 [6] Go to phase “wipe directory and start over”

 [7] Go to phase “clean”

 [8] Go to phase “distclean”

Ending up here, you will need to run some commands in order to fix the issue. After the problem is fixed, you’ll need to resume and rerun the command that failed. So, how do you do that? Well, you have two options (a complex one, and an easier one):

  1. (The complex option) You choose the ‘Start shell’ option from the menu above, that will spawn another shell nested inside the current one. You will then run the command that fixes the issue in this new nested shell, then (after the command has finished running) exit this shell (press CTRL+D or use the exit command). Exiting the nested shell will bring you back to the previous shell (the one inside of which you first ran a command, and then it failed giving you the above menu) which will prompt you with the above menu again. Since you now fixed the problem, you need to choose the ‘Rerun phase configure’ one.
  2. (The easy option) Instead of using a nested shell, you simply open another terminal and run the command that should fix your problem. Then you return to the first shell, which will still have the menu as the last thing it printed back to you, and you will just choose ‘Rerun phase configure’.

Option 2 is more straight-forward, as option 1 can confuse you a bit (having a million nested shells isn’t quite helpful, either).

Also, keep a separate tab for the commands that are run as root, as you will only use it for commands starting with ‘dnf’ (which require root privileges). This will make the workflow a bit smoother (you won’t have to log as root a million times).

So, This is where the ‘things you need to know’ section ends, and where the ‘let’s build gnome-shell already, dude’ section starts. Commands will be run in sequence:

  1. Use the command: jhbuild sysdeps (this command will show you information about the packages needed, and whether the packages are ok, out-of-date or uninstalled).
  2. Use the command: jhbuild sysdeps –install (this command will install any of the packages that are uninstalled, or will try to update those that are out-of-date).
    • This command may fail with the following error: Error: python-gobject package not found. If this happens, you need to use the following command: dnf install pygobject2.x86_64.
  3. From the menu, choose ‘Rerun phase configure’, which will resume the jhbuild sysdeps –install command.
    • This command may fail with the following error: Error: dbus-python package not found. If this happens, you need to use the following command: dnf install dbus-python-devel.x86_64.
  4. From the menu, choose ‘Rerun phase configure’, which will resume the jhbuild sysdeps –install command which will succeed.
  5. Now we need to install the system dependencies for gnome-shell specifically, using the command: jhbuild sysdeps –install gnome-shell.
  6. Now we’ll begin installing gnome-shell with the jhbuild build gnome-shell command.
    • This command may fail with the following error: *** Error during phase build of gobject-introspection: ########## Error running make -j 2  *** [6/71]. If we scroll up a bit, just above the previous error, we’ll see a more detailed error: gcc: error: /usr/lib/rpm/redhat/redhat-hardened-cc1: No such file or directory. If this happens, you need to use the following command: dnf install redhat-rpm-config.
  7. From the menu, choose ‘Rerun phase configure’, which will resume the jhbuild build gnome-shell command.
    • This command may fail with the following error: *** Error during phase configure of geoclue: ########## Error running ~/jhbuild/checkout/geoclue/autogen.sh –prefix ~/jhbuild/install –disable-Werror –with-systemdsystemunitdir=no –disable-static –disable-gtk-doc  *** [32/71]. If we scroll up a bit, just above the previous error, we’ll see two more detailed errors:
      • Package ‘avahi-client’, required by ‘virtual:world’, not found
      • Package ‘avahi-glib’, required by ‘virtual:world’, not found
    • Fix the two erros by running: dnf install avahi-glib-devel.x86_64.
  8. From the menu, choose ‘Rerun phase configure’, which will resume the jhbuild build gnome-shell command.
    • This command may fail with the following error: *** Error during phase build of WebKit: ########## Error running ninja *** [40/71]. No need to fix this, go to step 9.
  9. Since we don’t need to build Webkit, we pick the ‘Give up on module’ option from the menu. This will simply skip building WebKit and will build the next module in the list of modules built by the jhbuild build gnome-shell command.
    • This command may fail with the following error: *** Error during phase configure of gnome-desktop: ########## Error running ~/jhbuild/checkout/gnome-desktop/autogen.sh –prefix ~/jhbuild/install –disable-Werror –with-gnome-distributor=JHBuild –disable-static –disable-gtk-doc  *** [51/71]. If we scroll up a bit, just above the previous error, we’ll see a more detailed error: Package ‘libseccomp’, required by ‘virtual:world’, not found. If this happens, you need to use the following command: dnf install libseccomp-devel.x86_64.
  10. From the menu, choose ‘Rerun phase configure’, which will resume the jhbuild build gnome-shell command.
    • This command may fail with the following error: *** Error during phase configure of libinput: ########## Error running meson –prefix ~/jhbuild/install –libdir lib  –buildtype=debugoptimized -Ddisable_gtkdoc=true ~/jhbuild/checkout/libinput *** [66/71]. If we scroll up a bit, just above the previous error, we’ll see a more detailed error:
        • Meson encountered an error in file meson.build, line 513, column 1:
        • Program “valgrind” not found or not executable
    • Fix the error by running: dnf install valgrind-devel.x86_64.
  11. From the menu, choose ‘Rerun phase configure’, which will resume the jhbuild build gnome-shell command. And it will succeed with the following message:
      • *** the following modules were not built *** [71/71]
      • WebKit gnome-online-accounts libgdata evolution-data-server gnome-shell
  12. Now we’ll use the following command: jhbuild buildone gnome-shell.
    • This command may fail with the following error: *** Error during phase configure of gnome-shell: ########## Error running meson –prefix ~/jhbuild/install –libdir lib  –buildtype=debugoptimized -Ddisable_gtkdoc=true ~/jhbuild/checkout/gnome-shell *** [1/1]. If we scroll up a bit, just above the previous error, we’ll see a more detailed error:
        • Meson encountered an error in file meson.build, line 72, column 0:
        • Native dependency ‘libecal-1.2’ not found
    • Fix the error by running: dnf search evolution-data-server-devel.
  13. From the menu, choose ‘Rerun phase configure’, which will resume the jhbuild buildone gnome-shell command. And it will succeed.


Wow. Congratz! You built gnome-shell! Now let’s try to run it. Before that, another thing you should know is that gnome-shell can rely one of the two backends: X11 or Wayland. The default is Wayland. The question that you may ask youself is: how the hell am I going to choose which one of them to use? Well, you’re in luck, there’s an answer for that too.

When you power up your pc/laptop (or after restarting, for that matter), you will have to choose which account to log into, after you do that, you’ll have to type in the password for that account. Just near the ‘Sing In’ button, you have a small gear that you can click on. Upon clicking, a popup pops up (duh), having (by default, unless you altered this somehow) 3 choices: GNOME, GNOME Classic, GNOME on Xorg. The predefined choice usually is GNOME.

GNOME uses Wayland, while GNOME on Xorg uses X11.

Running gnome-shell:

  • On Wayland: jhbuild run gnome-shell -r –nested
    • A new window will open and there you’ll have your gnome-shell instance.
    • Just closing the new window will terminate the new gnome-shell instance.
  • On X11: jhbuild run gnome-shell -r
    • This will basically replace your current gnome-shell instance with the one built with jhbuild.
    • In order to replace it back with the default gnome-shell (not the one built with jhbuild) run the following command from within another terminal: /usr/bin/gnome-shell -r.


So, I hope I covered most of the build issues that can occur (the ones above are the ones that I experienced, but there is a pretty big chance that you’re going to run into them as well). Have fun breaking the build! 🙂


P.S. Just noticed that the single () and double () dashes appear awkward when bolded… Sorry about that.


Wrapping up GSoC 2017

So, GSoC ends in a short while and I want to take advantage of that and show a preview of both features that we’ve worked on :).

As I have described here and here, I worked on the gnome-shell search results and made them look different and then I added system actions to the mix. Without further ado, let’s see how they turned out.

First up, the updated gnome-shell results. The idea was that we needed to fit as many results as possible on the screen, making it possible for lower resolutions to handle fitting those results on the screen. At the same time, we had to make sure that the screen won’t be cluttered, or it would’ve turned into a mess.

A peek at how it used to look:


I have to say that even if I like the new design more than the old one, the old one didn’t look bad either. It’s just that it was a lot of unused space that would’ve been useful. So here we have the new one:


This is how the gnome-shell overview looks now. Pretty cool, eh? 🙂

As you can see, the separators between each app and its associated results are now more visible, so you can clearly see the ‘area’ that each app occupies. We are still thinking about some tweaks about the way it looks. Mainly having the content structured as columns (of course, no vertical lines will be drawn). As you can see, app icons (the ones on the left) are aligned, they appear as if they are on the same vertical line. Something similar happens with the smaller icons in the middle, as well. The question is whether we should also align the titles (‘Color’, ‘Online Accounts’, etc. from the picture).

Next up are the system actions, all 6 of them so far. Those are: power off, suspend, lock screen, switch user, log out and lock orientation. Yep, you will be able to press the super key, type ‘power off’, press Enter, press Tab 4 times, press Enter again and voila! You have shut down your OS (bonus: if you press Tab only 3 times, then Enter, you restart your OS. MAGIC!).



Regarding the system actions we are still thinking of some adjustments, like the aspect of the black pill behind each picture, but we aren’t sure right now. I really hope you guys will use the new system actions :D. Who knows, maybe there are more to be added in the future (we coded them in a generic fashion, so adding a new one would be quite easy).

The next target is having a help overlay for gnome-shell so that shortcuts and gestures are easily accessible.

So this was my GSoC 2017 work, I hope you like the outcome and I really hope that what we’ve done is useful to the gnome-shell users :)!

The joy of rebuilding…

I guess we all kind of enjoy breaking things and them fixing them up. It might be one of the reasons we want to be programmers. Find a bug, patch it up, test it, break something with what seemed like a good idea, rollback to an earlier version, fix again… etc. It just never ends. And believe it or not, sometimes it really is fun. Sometimes. Unfortunately for me, what follows is a description of one of the other situations, when you really wouldn’t want your precious build to go nuts, but it does. Spoiler: it does have a happy ending, no worries :).

We all know that this Monday was the dreaded String Freeze for GNOME 3.25 development cycle. I was given a heads up that it would be best to land my two GSoC features (which I described here and here) up until then. Given the fact that the code was all there and all that it needed were some rebases, I was confident enough to say that the two features would land.

I was about 40 minutes behind what appeared to be a successful achievement of finishing on time. The code was functioning right, flawlessly, but the final rebase was not made yet. I had tons of local backup braches, about 16 remote branches on gitlab-test. So, really, what could go wrong? And more, I knew that there would not be conflicts, because I created another local branch and pulled origin master there, and the merge was automatically done with no conflicts. Just a dream.

But, of course, in my excitement, I didn’t build to see if it would work. It had worked up until then, why would it break right now?

Moment of truth came, my final branch (not the one I just mentioned, that was just for testing purposes) was rebased on master and all I needed to do was confirm that it was working. So i ran jhbuild buildone gnome-shell for one last time.

Then hell broke loose. I had some problems with Meson, that would not let me build gnome-shell. Both Florian and Carlos tried to help me with the issue, but jhbuild had other plans for us. Somehow, in the whole process, gnome-shell got wiped out. Entirely. No local branches, bye bye good code, bye bye deadline.

I could not believe it. I was angry, felt tired (as I hadn’t slept more than 3-4 hours per night the previous nights, I really wanted to land the patches), hopeless and I felt like I failed.

Florian did more than he should have, he took my code and gave it the finishing touches and then pushed it on bugzilla, as I was unable to (I still had build problems).

Now for the good part: GNOME search results have a new look and system actions are available in the search results! I was so excited the following day when the patches landed and also felt a relief. I felt like all the effort, sleepless night, frustration and anger (really, wouldn’t you get angry if your build exploded?) were well worth it in the end.

And, oh boy, it was! 🙂

SystemActions are almost done!

So for the past weeks I’ve been working on adding system actions to shell search.

The results so far can be seen in the picture below:


In total, there are 5 actions that have been added: Power off, Suspend, Lock screen, Switch user and Log out (only three of them are available in the picture, but trust me, all five of them are added).

The symbolic icons could be changed (the power off one, for example, doesn’t look like the one in the mockup that’s attached to the bug in bugzilla, but that’s trivial to change).

The final touches also include coming up with the list of matching terms for each action (for example, Power off might be matched by either of ‘power’ or ‘shutdown’, etc.).

So I can proudly say that Gnome-shell will soon have system actions present in the search results :).

GSOC on gnome-shell

So this year i’m a GSoC student again :), but this time not on Polari, but on gnome-shell.

Even though the projects are different, they still rely on the same technology (GJS) so it’s definitely easier for me to understand the code at first sight than it was last year.

The first thing i’m working on is this bug and i can happily say that it’s nearly done :). A few minor adjustments and it will look just like in the picture.

There are still some questions about adding transitions (but nothing sure so far) and that’s about it. I’m going to write another post soon, when the search results will look exactly like the mockup!

GNOME Days in Bucharest

From Wednesday up to Saturday we had the pleasure of hosting some very interesting events related to GNOME and open-source.

First of them was the GSoC presentation where previous GSoC students shared their experience with those eager to try it next summer. We had a lot of people interested, thus we nearly filled a whole amphitheater.

The next event (Thursday) was about why open-source is so important not only for individuals, but for the whole world. Here we had Carlos as a speaker and I must say that he did a really great job. He gave away some RedHat swag for those that asked/answered questions.

Carlos talking about open-source

Apart from the fact that it was 19:00 and everyone must have had a tiring day at the university, we still had students interested.


Compared to what was going to happen during the third event, the first two ones were a piece of cake :).

The third event, which was on Saturday, was a small hackfest (we thought that it was going to be small. We couldn’t have been more wrong). So we announced the event, tried to advertise it as well as we could (we got help from our teacher, Răzvan Deaconescu, he also helped us with the space needed for the event and a lot of other stuff, so we are very thankful to him 🙂 ).

Then Saturday came. And then the students came. And then we filled a whole room. Then two rooms. Then three rooms. Then we even needed a fourth one that was half full. Sooo… yeah. We were just amazed.

Here we can see Carlos swimming in a room full of open-source loving students.

The main goal of our event was to at least build a project. You might say that we didn’t ask for that much, right? I mean come on, how hard can it be to follow some instructions and build a project, right? Well, thanks to JHbuild, and it’s wonderful way of ruining our hope, we spent about 3 to 4 hours trying to just build something.

Needless to say that the majority of the students didn’t manage to build anything. But it wasn’t their fault. Since things weren’t that great, we decided that the most we could do was a live demo of how the normal workflow should have been.

The projector was actually working, really.

After Carlos filed a test bug (for Nautilus) on bugzilla, Răzvan went on and fixed it. Thus, we showed them how a bug is found, filed, fixed and pushed on bugzilla for review.

I don’t know what he was taling about, but i tried to troll him 🙂

Afterwards, Carlos asked the audience if at least some of them wanted to go back to the rooms and try to further build their projects OR (pay attention) go grab something to drink. They chose to go back and try to build even more 🙂 (it really happened, yeah). And believe it or not, some of them even fixed some newcomer bugs.

It was an amazing week, an amazing experience and I bet some of the students will still continue to build (a process that will surely take about two more weeks of their innocent lives, thanks to JHbuild, but their perseverance will prevail) and then even contribute to GNOME. We promised some more such events in the future, so get that FlatPak done, PLEASE!

Special thanks to Carlos Soriano and Răzvan Deaconescu, the ones that made this possible! Also, Alexandru Căciulescu helped us with promoting the events so we owe him one :).

My GUADEC experience

It’s been three days since I got back home and I have to say that I already miss being there with all the GNOME community :).

I actually didn’t know how this experience would be. I had never actually been to a GNOME meeting before and all my interaction with the community was purely online.

But man, the whole trip was great. I met really awesome, fun and amazing people that I would enjoy working with. And we actually did that, as some of the time was actually spent rebasing and rewriting the git history of my GSoC project :D.

I was amazed by how friendly everybody was and how quickly I integrated myself into the community. They made it so much easier. It didn’t take more than a few minutes until we started having beer together and cracking jokes. And this was just the first night when I had just arrived there.

The core days involved attending talks throughout the day (with a lunch break and several smaller ones in between the talks). I even volunteered to film two of the presentations and it was fun. I even had my own lightning talk, during which I presented my GSoC work.

The next three days had a schedule that was a bit more relaxed, the BOFs were quite interesting and I learnt quite e few interesting things during them.

I would really like to thank the GNOME foundation for sponsoring me on this trip and for giving me this awesome opportunity!