Monthly Archives: October 2023

Ubuntu, Oh My Zsh, Powerlevel10k and Meslo fonts

I haven’t been using Ubuntu for a while, but I wanted to give it another try. I’m using my Ansible playbook for installing ZSH, Oh My Zsh, and p10k (Powerlevel10k), so I thought everything would work like a charm.

However, after running the playbook and restarting, the terminal did not look quite right:

You see the OS logo before the “>” is not displayed, and other icon fonts (I’m using exa/eza instead of “ls”) are missing, too (e.g., the one for YAML and Markdown files). In Arch, I knew how to solve icon problems for exa. Here in Ubuntu, I never experimented in that respect.

However, the p10k GitHub repository provides many hints in that respect. Unfortunately, Ubuntu does not provide packages for Nerd fonts. However, the p10k GitHub repository provides some Meslo fonts that can be directly downloaded.

The commands to solve the problem (provided you already have “fontconfig” and “wget” installed, otherwise, do install them) are:

And then issue

You can verify that they are now installed:

Now, reboot (this seems to be required), and the next time you open the terminal, everything looks fine (note the OS icon and the icons for YAML and Markdown files):

Of course, you could also download another Nerd font from the corresponding GitHub repository, but this procedure seems to work like a charm, and you use the p10k recommended font (Meslo).

By the way, the Gnome Text Editor automatically uses the new icon fonts. Other programs like Kate (which I use in Gnome as well) have to be configured to use the Meslo font.

Dell OptiPlex 5040 MiniTower: upgrading SSD

I am writing this report about my (nice) experience upgrading the SSD (1 TB) to my Dell OptiPlex 5040 MiniTower. That’s an old computer (I bought it in 2016), but it’s still working great. However, its default SSD of 256 GB was becoming too small for Windows and my Linux distributions. This computer also came with a secondary mechanical hard disk (1 TB).

DISCLAIMER: This is NOT meant to be a tutorial; it’s just a report. You will do that at your own risk if you perform these operations! Ensure you did not void the warranty by opening your laptop.

I wrote this blog post as a reminder for myself in case I have to open this desktop again in the future!

To be honest, my plan was to add the new SSD as an additional SSD, but, as described later, I found out that the mechanical hard disk was a 2.5 one, so I replaced the old SSD with the new one (after cloning it). I’ve used a “FIDECO YPZ220C” to perform the offline cloning, which worked great!

This is the BIOS status BEFORE the upgrade:

I seem to remember that “RAID” is required to have Linux installed on such a machine.

This is the new SSD (a Samsung 870 EVO, 1 TB, SATA 2.5”):

The cool thing about this desktop PC, similar to other Dell computers I had in the past, is that you don’t need a screwdriver: you disassemble it just with your hands. However, I suggest you have a look at a disassembling video like the one I’ve used: I know the video is about a Dell Optiplex 7040 MT, while mine is a Dell Optiplex 5040 MT, but their shapes and internals look the same. On the contrary, the Dell Optiplex 5040 SmallFactor videos are not useful because there’s a huge difference between my MiniTower and a SmallFactor 5040.

These are a few photos of the disassembling, showing the handles to use to open the computer, disconnect a few parts, and access the part holding the 2.5 drives.

This is the part holding the two 2.5 drives (as I said, at this point, I realized that also the mechanical hard disk is occupying one such place):

The SSD (I will replace) is the first one on top.

It’s easy to remove that: just use the handles to pull it off:

There are no screws to remove: you just enlarge the container to remove the SSD and insert the new one.

As I said above, I inserted the new one after performing the offline cloning.

Once I closed the desktop, the BIOS confirmed that the new SSD was recognized! 🙂

Now, some bad news (which is easy to fix, though): if you use a partition manager, e.g., in Linux, the SSD is seen as 1 TB, but the partitions are based on the original source SSD, so you end up with lots of free space that you cannot use!

For example, here’s the output of fdisk, which understands there’s something wrong with the partition table:

It also suggests that it’s not a good idea to try to fix it when one of the partitions is mounted.

Using a live ISO, e.g., the one from EndeavourOS, is just a matter of fixing the partition table as follows.

Now, you have access to the whole space in the disk.

For example, this is the output of “gparted” (Yes, I have a few Linux distributions installed on this PC):

That’s all! 🙂

Hyprland and Waybar

Up to now, I have shown how to get started with Hyprland with the initial configurations.

Now, I’ll show how to install the mainstream status bar in Hyprland: Waybar. Again, I’m going to do that for Arch Linux. As in the previous posts, I will NOT focus on the look and feel configuration.

Before continuing, the Waybar module for keyboard status (Caps lock and Num lock) requires the user to be part of the “input” group. Ensure your user is part of that group by running “groups”. If not, then add it with

Then, you must log out and log in.

First of all, the official package waybar already supports Hyprland (in the past, you had to install an AUR package). So, let’s install the main packages (as usual, you might want to make sure your packages are up-to-date before going on):

Let’s open a terminal and start Waybar

The result is not that good-looking

Waybar heavily relies on Nerd fonts for icons, and, currently, we don’t have any installed (unless you have already installed a few yourself).

The terminal will also be filled with a few warnings about a few missing things (related to Sway) and errors about failures to connect to MPD.

Let’s quit Waybar (close the terminal from where you launched it), and let’s fix the font problem by installing a few font packages:

Let’s start Waybar again, and this time it looks better:

Try to click on the modules and see what happens. For some of them, the information shown will change (e.g., the time will turn into the date).

Let’s quit Waybar again, and let’s start configuring it. We must create the configuration files for Waybar (by default, they are searched for in “~/.config/waybar”). We can do that by using the default ones:

The above command will copy “config” (with the configuration of Waybar modules, i.e., the “boxes” shown in the bar; The configuration uses the JSON file format) and style.css (for the style).

Let’s edit “config”. At the time of writing, this is the initial part of the configuration file:

The initial parts specify the position and other main configurations. This part must be enabled:

Otherwise, Waybar popups render behind the windows

Let’s edit the modules that must be shown on the bar’s left, center, and right. Of course, this is subjective; here, I show a few examples. The modules starting with “sway” are for the Sway Window Manager, while we’re using Hyprland, and we must use the corresponding ones:

You might want to have a look at the Waybar Wiki for an explanation of the modules.

Remember that for each module you mention here, you can have a configuration in the rest of the file, e.g.:

Otherwise, you get the defaults for that module.

Each module, together with its configuration, is documented in the Waybar Wiki.

Let’s focus on the left and center modules. I’ve opened three workspaces, and here’s the result (note the workspace indicator on the left, and on the center, we see the currently focused window’s title, in this case, Firefox):

By editing the “style.css” file, we can change the workspace indicator so that we better highlight the current workspace:

Restart Waybar, and now the current workspace is well distinguished:

The “tray” module is useful to show applications running in the background, like “skype”, “dropbox,” or the “network-manager-applet”.

Let’s now define a custom module, for example, one for showing a menu for locking the screen, logging out, rebooting, etc. To do that, first, we need to install the AUR package “wlogout”:

Let’s say we want to add it as the last module on the right. We edit the Waybar config file like this:

Then, in the same file, before closing the last JSON element, we define such a module (remember to add a comma after the previously existing last module):

Note that I’ve used a character using the installed Nerd font. Of course, you can choose anything you like. The “wlogout” menu will appear when you click on that module. Let’s restart Waybar and verify that:

By editing the “style.css”, you can customize the style of this custom module, e.g.,

When we’re happy with the configuration, we modify the Hyprland configuration file to start Waybar automatically when we enter Hyprland:

Restart Hyprland and Waybar will now appear automatically.

Finally, you can have several Waybar bars, i.e., instances, in different parts of the screen, each one with a different configuration.

For example, let’s create another Waybar configuration for showing a Taskbar to show all the running applications from all workspaces. This can be useful to quickly look at all the running applications and quickly switch to any of them, especially in the presence of many workspaces.

I create another configuration file in the “~/.config/waybar” directory, e.g., “config-taskbar”, with these contents (you could also configure several Waybar instances in the same configuration file, but I prefer to have one configuration file for each instance):

We can call it from the command line as follows:

Here’s the second instance of Waybar on the bottom, showing all the running applications (from all the workspaces):

Unfortunately, in my experience, not all icons for all running applications are correctly shown: for example, for “nemo”, you get an empty icon in the taskbar. You can click it, but visually, you don’t see that… maybe it has something to do with the icon set. I still have to investigate.

You can run both instances when Hyprland starts by putting these two lines in the “hyprland.conf” file:

Stay tuned for more posts about Hyprland. 🙂

Maven, parents, aggregators and version update

In this blog post, I will describe a few scenarios where you want to update versions in a multi-module Maven project consistently. In these examples, you have both a parent POM, which is meant to contain common properties and configurations to be inherited throughout the other projects, and aggregator POMs, which are meant to be used only to build the multi-module project. Thus, the parent itself is NOT meant to be used to build the multi-module project.

The source code of the projects used in this post can be found here:

I’m not saying that such a POM configuration and structure is ideal. I mean that it can be seen as a good practice to separate the concept of parent and aggregator POMs (though, typically, they are implemented in the same POM). However, in complex multi-module projects, you might want to separate them. In particular, as in this example, we can have different separate aggregator POMs because we want to be able to build different sets of children’s projects. The aggregators inherit from the parent to make things a bit more complex and interesting. Again, this is not strictly required, but it allows the aggregators to inherit the shared configurations and properties from the parent. However, this adds a few more (interesting?) problems, which we’ll examine in this article.

We’re going to use the standard Maven plugin’s goal: org.codehaus.mojo:versions-maven-plugin:set:

Sets the current project’s version and based on that change propagates that change onto any child modules as necessary.

This is the aggregator1 POM (note that it inherits from the parent and also mentions the parent as a child because we want to build the parent during the reactor, e.g., to deploy it):

Let’s make sure we can build it:

The aggregator2 is similar; here’s the build result:

Note that parent2 has parent1 as a parent:

Let’s say we want to update the version of parent1 consistently. Where do we run the following Maven command?

Let’s try to do that on the aggregator1:

Maybe on the parent1?

It looks like it worked… or it didn’t?

As you can see, it updated only the version of parent1, and now all the other children will refer to an old version. It didn’t work!

In fact, if we try to build the whole project with the aggregator1, it fails:

Before going on, let’s revert the change of version in parent1.

Let’s add references to aggregators in parent1

Let’s run the Maven command on parent1:

That makes sense: the aggregator has the parent as a child, and the parent has the aggregator as a child.

But what if we help Maven a little to detect all the children without a cycle?

It looks like it is enough to “hide” the references to children inside a profile that is NOT activated:

And the update works. All the versions are consistently updated in all the Maven modules:

The important thing is that aggregator2 does not have parent1 as a module (just parent2), or the Maven command will not terminate.

We can also consistently update the version of a single artifact; if the artifact is a parent POM, the references to that parent will also be updated in children. For example, let’s update only the version of parent2 by running this command from the parent1 project and verify that the versions are updated consistently:

Unfortunately, this is not the correct result: the version of parent2 has not been updated. Only the references to parent2 in the children have been updated to a new version that will not be found.

For this strategy to work, parent2 must have its version, not the one inherited from parent1.

Let’s verify that: let’s manually change the version of parent2 to the one we have just set in its children:

And let’s try to update to a new version the parent2:

Nothing has changed… it did not work.

Let’s try and be more specific by specifying the old version (after all, we’re running this command from parent1 asking to change the version of a specific child):

This time it worked! It updated the version in parent2 and all the children of parent2.

Let’s reset all the versions to the initial state.

Let’s remove the “hack” of child modules from parent1 and create a brand new aggregator that does not inherit from any parent (in fact, it configures the versions plugin itself) but serves purely as an aggregator:

Let’s try to run the version update from this aggregator:

It updated the version of the aggregator only! That’s not what we want.

Let’s revert the change.

We know that we can use the artifactId

What if the same child is included in our aggregators aggregator1 and aggregator2? For example:

We get an error if we try to update the version as above because the same module is present twice in the same reactor:

But what if we apply the same trick of the modules inside a profile in this new aggregator project, which is meant to be used only to update versions consistently?

For example,

This time, the version update works even when the same module is present in both our aggregator1 and aggregator2! Moreover, versions are updated only once in the module mentioned in both our aggregators:

Maybe, this time, this is not to be considered a hack because we use this aggregator only as a means to keep track of version updates consistently in all the children of our parent POMs.

As I said, these might be seen as complex configurations; however, I think it’s good to experiment with “toy” examples before applying version changes to real-life Maven projects, which might share such complexity.