Author Archives: Lorenzo Bettini

About Lorenzo Bettini

Lorenzo Bettini is an Associate Professor in Computer Science at the Dipartimento di Statistica, Informatica, Applicazioni "Giuseppe Parenti", Università di Firenze, Italy. Previously, he was a researcher in Computer Science at Dipartimento di Informatica, Università di Torino, Italy. He has a Masters Degree summa cum laude in Computer Science (Università di Firenze) and a PhD in "Logics and Theoretical Computer Science" (Università di Siena). His research interests cover design, theory, and the implementation of statically typed programming languages and Domain Specific Languages. He is also the author of about 90 research papers published in international conferences and international journals.

Java, Maven and Gitpod: Getting Started

2 Replies

I have already blogged about Gitpod, which allows you to spin up fresh development environments from your GitHub projects so that you can code with Visual Studio on the web (that’s just a very reductive definition, so you may want to look at its website for the complete set of features). I have already shown how to use it for Ansible and Molecule.

I honestly prefer to have my IDE (Eclipse) on my computer. However, Gitpod allows you to use an old or less powerful computer to develop applications and systems requiring much computing power and resources. I showed an example for the PineBook Pro: you can use Gitpod to develop Ansible roles and test them with Docker.

Today, I will show how to use Gitpod for Java/Maven projects. This is the first post of a series about Java, Maven, and Gitpod.

NOTE: Although the post focuses on Gitpod, most of the features we will see come from Visual Studio Code and the extensions we will install. Thus, the same mechanisms could be used also on a locally installed Visual Studio Code. In that respect, it is best to get familiar with the main keyboard shortcuts (these will be shown in Visual Studio Code when no editor is opened):

Gitpod provides an example for Java, but it relies on Spring Boot and is probably too complex, especially if you’re not interested in web applications.

In this post, instead, I’ll start with a very basic Java/Maven project. It is intended as a tutorial, so you might want to follow along doing these steps with your GitHub account.

I start by creating a Maven project with the quickstart archetype locally on my computer:

I move it into another directory, for example:

Create a standard “.gitignore”:

Initialize the Git repository and create a first commit:

Finally, I create a new repository on GitHub and push my Git repository there (in this example: https://github.com/LorenzoBettini/java-maven-gitpod-example)

To access Gitpod easily from a GitHub repository, I installed the Gitpod browser extension.

Now, I can start Gitpod for this repository using the button (as I said, you need to use a browser extension; otherwise, you have to prefix the URL appropriately):

Let’s press the “Gitpod” button. (The first time you use Gitpod, you’ll have to accept a few authorizations.).

Press the “Continue with GitHub” button and wait for the workspace to be ready.

NOTE: I’m using the light theme of Visual Studio in Gitpod in this blog post.

Gitpod detected that this was a Maven project and automatically executed the command:

Note that it also created the file “.gitpod.yml”, which we’ll later tweak to customize the default command and other things:

Moreover, it offers to install the Java extension pack:

Of course, we accept it because we want to have a fully-fledged Java IDE (this is based on the Eclipse JDT Language Server Protocol; you might want to have a look at what a Language Server Protocol, LSP, is). We use the arrow to choose “Install Do not Sync” (we don’t want that in all Gitpod workspaces, and we’ll configure the extensions for this project later).

Once that’s installed (note also the recommended extension GitLens, which we might want to install later, let’s use the gear icon to add the extension to our “.gitpod.yml” so that the extension will be automatically installed and available the next time we open Gitpod on this project:

Unfortunately, the “.gitpod.yml” is a bit messed up now (maybe a bug?), and we have to adjust it so that it looks like as follows:

There’s also a warning on top of the file; by hovering, we can see a few warnings complaining that the transitive dependencies of the extension are not part of the file:

Let’s click on “Quick Fix…” and then apply the suggestions to add the extensions to the file (these are just warnings, but I prefer not to have warnings in my development environment):

In the end, the file should look like this:

Note that we have “code lens” in the editor, and we can choose to let Gitpod validate this configuration:

TIP: another extension I always add is “eamodio.gitlens”.

This will rebuild the Docker image for our workspace (see the terminal view at the bottom):

This operation takes some time to complete, so you might want to avoid that for the moment. If you choose to do the operation, in the end, another browser tab will be opened with this new configuration. We can switch to the new browser tab (the “.gitpod.yml” is available in the new workspace, though we still haven’t committed that).

NOTE: I find “mvn install” an anti-pattern, and, especially in this context, it makes no sense to run the “install” phase and run the tests when the workspace starts. In fact, I changed the “init” task to a simpler “mvn test-compile”; this is enough to let Maven resolve the compile and test dependencies when the workspace starts. The Java LSP will not have to resolve them again and will find them in the local Maven cache.

We can take the chance to commit the file by using the corresponding tab in Visual Studio Code and then push it to GitHub (“Sync Changes”):

We could also close the Gitpod tabs and re-open Gitpod (the “.gitpod.yml” is now saved in the GitHub repository), but let’s continue on the open workspace.

Let’s now open a Java file in our project:

We get a notification that the IDE is loading the Java project (this might take a few seconds).

TIP: to quickly open a file knowing (part of) its name, press “Ctrl + P” (see the shortcuts above) and start typing:

We have a fully-fledged Java IDE with “code lens” for running/debugging and parameter names (see the argument passed to “System.out.println”):

For example, let’s use “Run” to run the application and see the output in the terminal view:

Though this project generated by the archetype is just a starting point, we also have a simple JUnit test. Let’s open it.

After a few seconds, the editor is decorated with some “code lens” that allows us to run all the tests or a single test (see the green arrow in the editor’s left ruler). Clicking on the arrow immediately runs the tests or a single test. Right-clicking on such arrows gives us more options, like debugging the test.

On the right pane, we can select the “Testing” tab (depicted as a chemical ampoule) that shows all the tests detected in the project (in this simple example, there’s a single one, but in more complex projects, we can see all the tests). We can run/debug them from there.

Let’s run them and see the results (in this case, it is a complete success); note the decorations showing the succeeded tests (in case of failures, the decorations will be different):

Of course, we could run the tests through Maven in the console, but this would be a more manual process, and the output would be harder to interpret in case of failures: we want to use an IDE to run the tests.

We could also run the tests by pressing “F1” and typing “Run tests” (we’ll then use the command “Java: Run Tests”): we need to do that when a JUnit test case is open in the editor.

Let’s hover on the “assertTrue”, which is a static method of the JUnit library. The IDE will resolve its Javadoc and will show it on a pop-up (the “code lens” for the parameter names is also updated):

We can use the menu “Go to definition” (or Ctrl+click) to jump to our project’s source code and libraries. For example, let’s do that on “assertTrue”. We can view the method’s source code in the class “Assert” of JUnit (note that this editor is read-only, and the name of the file ends with “.class”):

Note that the “JAVA PROJECTS” in the “Explorer” shows the corresponding file. In this case, it is a file in the referred test dependency “junit-4.11.jar” in the local Maven cache (see the POM where this dependency is explicit).

Of course, we have code completion by pressing “Ctrl+Space”; when the suggestions appear, we can start typing to filter them, and substring filtering works as well (see the screenshot below where typing “asE” shows completions matching):

With ENTER, we select the proposal. In this case, if we select one “assertEquals”, which is a static method of “Assert”, upon selection, we will also have the corresponding static import automatically added to the file.

That’s all for the first post! Stay tuned for more posts on Java, Maven, and Gitpod! 🙂

My Ansible Role for KDE

Leave a reply

I have already started blogging about Ansible; in particular, I have shown how to develop and test an Ansible role with Molecule and Docker, also on Gitpod. I have also shown my Ansible role for GNOME.

This blog post will describe my Ansible role for installing the KDE Plasma desktop environment with several programs and configurations. As for the other roles I’ve blogged about, this one is tested with Molecule and Docker and can be developed with Gitpod (see the linked posts above). In particular, it is tested in Arch, Ubuntu, and Fedora.

This role is for my personal installation and configuration and is not meant to be reusable.

The role can be found here: https://github.com/LorenzoBettini/my_kde_role.

The role assumes that at least the basic KDE DE is already installed in the Linux distribution. The role then installs several programs I’m using daily and performs a few configurations (it also installs a few extensions I use).

At the time of writing, the role has the following directory structure, which is standard for Ansible roles tested with Molecule.

The role has a few requirements, listed in “requirements.yml”:

These requirements must also be present in playbooks using this role; my playbooks (which I’ll write about in future articles) have such dependencies in the requirements.

Let’s have a look at the main file “tasks/main.yml”, which is quite long, so I’ll show its parts and comment on the relevant parts gradually.

This shows a few debugging details about the current Linux distribution. Indeed, the whole role has conditional tasks and variables depending on the current Linux distribution.

The file installs a few KDE programs I’m using in KDE.

The “vars/main.yml” only defines a few default variables used above:

As seen above, a few packages have a different name in Ubuntu (Debian), which is overridden.

Then, I configure a few things in the KDE configuration (.ini) files and set a few keyboard shortcuts. The configuration should be self-explanatory.

Then, I ensure Kate is the default editor for textual files (including XML files, which otherwise, would be opened with the default browser); I also configure a few Kate preferences:

Then, I copy a few Konsole profiles (and the corresponding color schemes, see the directory “files/konsole”) and also configure the Yakuake drop-down terminal:

The final part deals with configuring the Kwallet manager to store SSH key passphrases, which, in KDE, has always been a pain to get correctly (at least, now, I have a configuration that I know works on all the distributions mentioned above):

Concerning Molecule, I have several scenarios. As I said, I tested this role in Arch, Ubuntu, and Fedora, so I have a scenario for each operating system. The “default” scenario is Arch, which nowadays is my daily driver.

For Ubuntu, we have a “prepare.yml” file:

The reason for this is explained in my previous posts on Ansible and Molecule.

I have a similar “prepare.yml” for the default scenario, Arch.

I have nothing to verify for this role in the “verify.yml”. I just want to ensure that the Ansible role can be run (and is idempotent) in Arch, Ubuntu, and Fedora.

Of course, this is tested on GitHub Actions and can be developed directly on the web IDE Gitpod.

I hope you find this post useful for inspiration on how to use Ansible to automatize your Linux installations 🙂

A look at Ubuntu 23.10 Mantic Minotaur

2 Replies

Nowadays, I mostly use Arch-based distributions (especially with EndeavourOS). So I haven’t been using Ubuntu for a while and decided to try it again now that the brand new release, 23.10 “Mantic Minotaur”, is available.

I tested it on my Dell XPS 13.

Here we are in the live environment:

Let’s start the installation. This new version of Ubuntu features a new installer, which looks nice. I still feel comfortable with this new installer having already installed Ubuntu many times.

The initial steps are the language, keyboard, and network connection:

In the next step, the installer detected a new version available to download. I said yes. Then, you have to restart the installer, starting from scratch.

By default, Ubuntu proposes a minimal installation when choosing the installation type. However, I prefer to have most of the things installed during this stage, so I chose the “Full Installation”:

Then, we get to the partitioning. As usual, I prefer manual partitioning since I have several Linux distributions installed on my computer. I chose EXT4 as the file system. On Arch, I use BTRFS. However, Ubuntu does not come with good defaults for BTRFS. I dealt with such problems in the past, but now I prefer to stick with EXT4 in Ubuntu and give up on BTRFS snapshots.

Then, we get to the timezone selection (the installer automatically detected my location) and user details. This is as usual.

Interestingly, you can select during the installation the theme and the color accent (that’s nothing special, but it is a nice surprise):

The installation starts; by clicking on the small icon on the bottom right, you can also enable logging on the terminal:

The installation only took a few minutes on this laptop.

Time to restart. Of course, at the first login, you get some updates to install:

The touchpad is already configured with tap-to-click, but it defaults to “natural scrolling” (which I don’t like). That gave me the chance to see the new nice-looking Gnome setting for the touchpad:

I installed Dropbox, and with the Ubuntu extension for “app indicator”, the Dropbox icon appears in the tray bar. It works (mostly: sometimes it always shows as if it is synchronizing, though everything is up-to-date).

Remember that the current icon theme does not show the “Dropbox” folder in Nautilus with overlay.

Connecting an external HDMI monitor works perfectly (so Wayland is not a problem); I prefer to mirror the contents:

Also, GNOME extensions work fine. Despite the new GNOME Version (45), known to have broken all extensions due to an API breakage, the ones I use seem to have been ported and work correctly.

I don’t like the fact that, despite a SWAP partition already present on my disk, the installer did not pick it up: the result is the usage of a small SWAP file, which I don’t like.

I removed this line from the “/etc/fstab”:

I added the line to refer to my existing SWAP partition.

I also enabled ZRAM, which will automatically have precedence over the SWAP partition:

I don’t like the wallpapers shipped with this version (in the screenshot, you can easily tell the GNOME wallpapers from the Ubuntu ones):

However, I typically use Variety for wallpapers, so it’s not a big problem.

IMPORTANT: as I have already blogged, you need additional fonts for “Oh-My-Zsh” with the “p10k” prompt.

All in all, Ubuntu 23.10 seems pretty stable and smooth. I’m using it (not as my daily driver), and for the moment, I’m enjoying it.

Hyprland and notifications with mako

2 Replies

Here’s another post on how to get started with Hyprland.

This time, we’ll see how to configure notifications with mako, a lightweight notification daemon for Wayland, which also works with Hyprland. (you might also want to consider and experiment with an alternative: dunst).

If you followed my previous tutorials, you have no notification daemon installed. You can verify that by running the following command (to issue a notification manually) and by looking at the resulting errors:

Let’s install “mako”:

The nice thing about mako is that you don’t need to start it as a service manually: the first time a notification is emitted, mako will run automatically.

Let’s try to run the above notification command above, and this time, we see the pop-up, by default, on the right top corner of the screen:

You have to click the pop-up to make it disappear.

Each time a program emits a notification, mako will show it. For example, Thunderbird, Firefox, and Chrome will emit notifications that mako will display.

Let’s do some further experiments by manually emitting notifications:

will lead to

You can see that the first argument is the title and formatted in boldface.

You can have a look at mako’s manual (5) about its configuration file and where it is searched for:

An example configuration, usable as a starting point, can be found here: https://github.com/emersion/mako/wiki/Example-configuration.

Each time you modify the configuration, you must reload mako by using one of the following commands:

or

With that example configuration, we can emit a few notifications with different “urgencies”, and see the different colors and positions of the boxes:

If you use EndeavourOS, you will get notifications about new updates and when a reboot is required after a system update (the latter is a “critical” notification):

That’s all! Not too difficult, isn’t it? 🙂

Stay tuned for more posts about Hyprland. 🙂

My Ansible Role for GNOME

Leave a reply

I have already started blogging about Ansible; in particular, I have shown how to develop and test an Ansible role with Molecule and Docker, also on Gitpod.

This blog post will describe my Ansible role for installing the GNOME desktop environment with several programs and configurations. As for the other roles I’ve blogged about, this one is tested with Molecule and Docker and can be developed with Gitpod (see the linked posts above). In particular, it is tested in Arch, Ubuntu, and Fedora.

This role is for my personal installation and configuration and is not meant to be reusable.

The role can be found here: https://github.com/LorenzoBettini/my_gnome_role.

The role assumes that at least the basic GNOME DE is already installed in the Linux distribution. The role then installs several programs I’m using on a daily basis and performs a few configurations (it also installs a few extensions I use).

At the time of writing, the role has the following directory structure, which is standard for Ansible roles tested with Molecule.

The role has a few requirements, listed in “requirements.yml”:

These requirements must also be present in playbooks using this role; my playbooks (which I’ll write about in future articles) have such dependencies in the requirements.

The main file “tasks/main.yml” is as follows:

This shows a few debug information about the current Linux distribution. Indeed, the whole role has conditional tasks and variables depending on the current Linux distribution.

The file installs a few programs, mainly Gnome programs, but also other programs I’m using in GNOME.

The “vars/main.yml” only defines a few default variables used above:

As seen above, the package for “python psutils” has a different name in Arch, and it is overridden.

For Arch, we have to install a few additional packages, which are not required in the other distributions (file “gnome-arch.yml”):

For the Guake dropdown terminal, we install it (see the corresponding YAML file).

The file “gnome-templates.yml” creates the template for “New File”, which, otherwise, would not be available in recent versions of GNOME, at least in the distributions I’m using.

For the search engine GNOME Tracker, I performed a few configurations concerning the exclusion mechanisms. This is done by using the Community “dconf” module:

This also ensures that possibly previous versions of Tracker are not installed. Moreover, while I use Tracker to quickly look for files (e.g., with the GNOME Activities search bar), I don’t want to use “Tracker extract”, which also indexes file contents. For indexing file contents, I prefer “Recoll”, which is installed and configured in my dedicated playbooks for specific Linux distributions (I’ll blog about them in the future).

Then, the file “gnome-configurations.yml” configures a few aspects (the comments should be self-documented), including some custom keyboard shortcuts (including the one for Guake, which, in Wayland, must be set explicitly as a GNOME shortcut):

Then, by using the “petermosmans.customize-gnome” role (see the requirements file above), I install a few GNOME extensions, which are specified by their identifiers (these can be found on the GNOME extensions website). I leave a few of them commented out, since I don’t use them anymore, but I might need them in the future):

Then, we have the files for installing and configuring Flatpak, which I use only to install the GNOME Extension manager:

I installed them system-wide (the “user” option is commented out).

Concerning Molecule, I have several scenarios. As I said, I tested this role in Arch, Ubuntu, and Fedora, so I have a scenario for each operating system. The “default” scenario is Arch, which nowadays is my daily driver.

For Ubuntu, we have a “prepare.yml” file:

The reason why is explained in my previous posts on Ansible and Molecule.

By default, I test that “flatpak” is installed. (see the default variables above: by default, Flatpak is installed)

But I also have a scenario (in Arch) where I run the role without Flatpak:

For this scenario, the “verify.yml” verifies Flatpak is not installed:

Of course, this is tested on GitHub Actions and can be developed directly on the web IDE Gitpod.

I hope you find this post useful for inspiration on how to use Ansible to automatize your Linux installations 🙂

Ubuntu, Oh My Zsh, Powerlevel10k and Meslo fonts

1 Reply

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

Leave a reply

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: https://www.youtube.com/watch?v=gXePa1N_8iI. 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

9 Replies

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

2 Replies

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: https://github.com/LorenzoBettini/maven-versions-example.

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:

Description:
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.

LG GRAM 16 (16Z90P): Adding a second SSD

Leave a reply

I am writing this report about my (nice) experience adding a second SSD (an NVMe, 1 Tb) to my LG GRAM 16, my main laptop that I’ve enjoyed for two years.

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 the laptop again in the future!

I also decided to describe my experience because there seems to be some confusion and doubts about which kind of SSD you can add in the second slot (SATA? or PCI?). At least for this model, LG GRAM 16 (16Z90P), I could successfully and seamlessly insert an NVMe M.2 PCIe3. This is the SSD I added, Samsung SSD 970 EVO Plus (NOTE: this SSD does NOT include a screw for securing the SSD to the board; however, the LG GRAM has a screw in the second slot, so no problem!):

You can also see the internal of the laptop below and what’s written in the second slot.

These are the tools I’ve used:

It’s time to open the back cover. That’s the first time I did that, and I found it not very easy… not impossible, but not even as easy as I thought. Fortunately, there are several videos that show this procedure. In particular, there’s an “official” one from LG, which I suggest to follow: https://www.youtube.com/watch?v=55gM-r2xtmM.

Removing the rubber feet (there are three types) was not easy from the beginning: they are “sticky”, but with a proper tool (the grey one in the picture above), I managed to remove the bigger ones and the one at the top.

For the other smaller ones, I had to use a cutter. Be careful because they tend to jump on your face (mind your eyes). 😉 Moreover, you have to be careful not to use too much force because you might break the bigger ones (in the linked video, you can see that the person breaks the one in the low left corner)

And here’s the back cover with all the screws revealed:

The screws are not of the same type either, so I ensured to remember their places:

Again, removing the cover after removing all the screws might not be straightforward: take inspiration from the linked video above! It took me some effort and a few attempts, but I finally made it! Here’s the removed cover and the internal of the laptop (well organized and neat, isn’t it?):

Now, let’s zoom in on the second SLOT:

You can see that it says NVME and SATA3. I haven’t tried with a SATA3, but, as I said, I had no problem with the Samsung NVME!

IMPORTANT: unplug the battery cable before continuing (at least, that’s what the LG video says). That’s easy: pull it gently.

Remove the screw from the second slot:

Insert the SSD (that’s easy):

And secure it with the screw:

Of course, now we have to reconnect the battery cable!

Let’s take a final look at the result:

OK! Let’s close the laptop: putting the cover back is easier than removing it, but you still have to ensure you close the cover correctly. Put the screws back and the rubber feet (that’s also easy because they are still sticky).

The moment of truth… will the computer recognize the added SSD? Let’s enter the BIOS and… suspense… 😀

IT DOES!!! (see that at the bottom. Yes, I have several Linux distributions installed on this laptop)

I booted into Linux (sorry, I almost never use Windows, and, to be honest, I still haven’t checked whether Windows is happy with the new SSD) and used the KDE partition manager to create a new partition to make a few experiments:

Everything looks fine! In the meantime, I’ve also created another partition for virtual machines on the new SSD, which works like a charm! I haven’t checked whether it’s faster than the primary SSD, which comes with the laptop.

That’s all! 🙂

Hyprland and ssh-agent

Leave a reply

In this post, I’d like to document how to use ssh-agent in Hyprland to store SSH key passphrases.

This is part of my blog series on Hyprland.

Assuming you use SSH keys protected with a passphrase, each time you use an SSH connection with the SSH key, you are prompted for the passphrase.

You can use ssh-agent and ssh-add.

First, start the agent:

Then, use ssh-add to add a specific key (see the documentation) or all the keys:

You are prompted for the passphrase, but then, the passphrase is remembered, and you are not asked anymore (unless the lifetime expires, by default, 1 hour).

Unfortunately, this holds only in the current terminal. It works for other applications started from that terminal. For example, if you start Visual Studio from that terminal and you access a Git repository with your SSH key, the passphrase is reused without prompting you. If you start another terminal or program using its launcher, you are prompted for the passphrase again; moreover, in such a situation, the passphrase is not remembered since you should rerun ssh-add.

Instead, I’d like to be prompted for the passphrase only the first time I use ssh; for the current desktop session, I don’t want to enter the passphrase again. Of course, if I reboot, I’m OK with re-entering the passphrase the first time I need it.

In GNOME, you can rely on its keyring to prompt you for the passphrase and store it for the current session or permanently. In KDE, you have a similar mechanism, which, however, has to be appropriately configured (that’s out of the scope of this post).

In Hyprland, you have to set up such mechanisms manually.

The Arch Wiki, as usual, documents an easy solution, which I’ll report here (I haven’t tried alternatives, but this one is pretty easy to set up).

First (https://wiki.archlinux.org/title/SSH_keys#ssh-agent), add this option to your “~/.ssh/config”:

This way, all SSH clients, including Git, store keys in the agent on first use.

We must ensure an ssh-agent is automatically started when you enter Hyprland.

Again, the Arch Wiki (https://wiki.archlinux.org/title/SSH_keys#Start_ssh-agent_with_systemd_user) tells you how to do that by starting ssh-agent a systemd user service.

Create this file “~/.config/systemd/user/ssh-agent.service” with these contents:

Then ensure the environment variable “SSH_AUTH_SOCK” is set to “$XDG_RUNTIME_DIR/ssh-agent.socket”. For example, in the Hyperland configuration file:

Now, start the service for your user at boot:

Reboot to ensure the environment variable is set correctly and the service is started.

Try to use ssh, and you will be prompted for your passphrase. Try to use ssh again for that passphrase, and you should not be asked for the passphrase. Start a new terminal, use SSH again, even with Git, and you will not be asked for the passphrase. This also works for other programs that need SSH, for example, Visual Studio Code when accessing a Git repository or Unison when connecting through SSH.

From now on, you’ll be asked for the passphrase only the first time you use ssh from any program and never more for that session.

Stay tuned for more posts about Hyprland. 🙂

KDE Plasma and Wayland: one year later

4 Replies

I had blogged about KDE Plasma and Wayland, and now I’m evaluating that again one year later.

In general, it looks like it improved a lot, even though it looked already promising last year.

Again, I’m testing this on EndeavourOS.

When I logged into the Plasma Wayland session with a brand-new user, the system automatically switched to 150% scaling. This is good because my LG GRAM 16 needs at least that scaling level.

Unlike my experiments last year, this is enough to have a nice-looking environment, and even GTK applications look great without blurring! For example, this is the EndeavourOS Welcome application (GTK-based):

Usually, a 150% scaling on this computer is not enough for my eyes, and I prefer 175%. I then configured the new scaling, pressed “Apply,” and everything was applied immediately: no logout was required (instead, on X11, this is usually required to have everything scaled correctly):

Touchpad gestures still work great, but they are still not configurable:

  • 4 Finger Swipe Left –> Next Virtual Desktop.
  • 4 Finger Swipe Right –> Previous Virtual Desktop.
  • 4 Finger Swipe Up –> Desktop Grid.
  • 4 Finger Swipe Down –> Available Window Grid.

Context menus of desktop and other Plasma widgets (e.g., the applications menu) in the presence of fractional scaling look nicer in Wayland than in X11!

For example, in X11, menu entries look too crowded:

While on Wayland, they look nice (the fonts also look better on Wayland):

Concerning GTK applications, my main one is Eclipse. As it was happening when I tried Plasma Wayland last year, the Eclipse splash screen has the title bar and window buttons, which looks strange:

Besides that, Eclipse looks nice:

Note, however, that there are still a few bad things: the Eclipse icon is not recognized, and you get a generic Wayland icon. This happens also in GNOME Wayland. There’s an open bug, but still no solution. Moreover, things like hover pop-ups are dismissed too soon in Wayland.

One last bad thing I noted is that the login manager SDDM does not remember the X11 or Wayland session per user: it just uses the last used session globally. I’m pretty sure it wasn’t like that in the past. I don’t know, though, whether SDDM or Plasma is to blame here 😉

I guess it’s time to use KDE Plasma with Wayland daily and see how it goes. 🙂

Hyprland: getting started (part 2)

8 Replies

This is the second blog post on getting started with Hyprland (see the first post here).

In this article, we install and configure a few other tools. We will also look at the customization of keyboard shortcuts.

Other tools

As noted here https://wiki.hyprland.org/Useful-Utilities/Must-have/, you need an Authentication Agent:

Authentication agents are the things that pop up a window asking you for a password whenever an app wants to elevate its privileges.

Let’s install the suggested one:

And then we start it in the Hyprland configuration file with the “exec-once” directive:

Let’s restart Hyprland (such a change in the configuration file needs a restart), e.g., with the default shortcut SUPER + M, we exit Hyprland, and then we can log back in. When a program needs to elevate its privileges, we get the KDE dialog. For example, if we use the EndeavourOS Welcome App to update the mirrors, we get the dialog as soon as the mirror file must be saved:

The same happens if we run from a terminal a “systemctl” command that needs superuser privileges:

Having the authentication dialog tiled as the other windows is not ideal. So let’s create a Window rule in the Hyprland configuration to make it floating:

TIP: to know the values for “class”, you can use “hyprctl clients” when the desired application is running and inspect its output by looking for the “class:” part.

Keyboard shortcuts

Hyprland is about using keyboard shortcuts a lot. You might want to take some time to get familiar with the main keyboard shortcuts for launching and closing (look at the configuration file). Change them as you see fit if you don’t like the default ones.

These are the default ones as set in the example configuration we started with:

I prefer these (note that SUPER+Q now has an entirely different behavior):

Some additional shortcuts might be helpful as well, such as the following (“grouping” has to do with tabbed windows):

And for moving tiled windows:

Mouse gestures

Hyprland provides mouse gestures (swipe) for switching among workspaces. This is not enabled by default, but it’s easy to do: change the existing “gestures” section as follows:

Screenshots

Let’s configure the system to take screenshots.

First, we install “grim” (A screenshot utility for Wayland)

Let’s also install an image viewer, like “Eye of Gnome”:

You can try to run “grim” from a terminal to see how it works: by default, it takes a screenshot of the whole screen and save the corresponding images with names containing date and time in the “Pictures” folder. For example, after running “grim” twice, I get the following:

What if we want to take a screenshot of a region? We need another program, “slurp” (Select a region in a Wayland compositor)

And we configure a few key bindings (note the last one, which takes a screenshot of the currently active window: this requires several commands to get the active window through Hyprland and then compute a few screen coordinates to pass to “grim”):

Brightness and volume

How to set the screen’s brightness and volume through the corresponding keys?

First, install “brightnessctl”:

You can get the current brightness by simply running the program (or with “get” or “-m”) and changing it with the “set” and the value (e.g., increase/decrease by percentage). For example:

So, we need to bind the appropriate special keys to such commands:

For volume, we do something similar: assuming that “wireplumber” is installed, we use “wpctl”:

Note the use of “-l 1.0” meaning that we don’t want to allow the wireplumber to increase the volume above 100%.

Screen locking

If we want to have screen locking (using a keyboard shortcut), we need these two programs:

  • swayidle, Idle management daemon for Wayland
  • swaylock, Screen locker for Wayland

And then, configure the shortcuts (note that we define a variable, $lock, in the configuration file):

Now, when we press SUPER + L, the screen is locked (swaylock can be configured with colors and the like, but I won’t discuss that). You have to type your password: when you start doing that, you’ll see a circle with some parts changing. If you get the password wrong, swaylock will notify you.

The “exec-once” (remember, you need to restart Hyprland for that) will lock the screen after 300 seconds, but it will also turn it off using a “hyprctl” dispatch command. Note that when that happens, you need to press a key or move the mouse, and the instruction above instructs the system to turn the screen back on. Of course, then you’ll have to type your password.

That’s all for now! Stay tuned for more posts about Hyprland 🙂

Hyprland: getting started (part 1)

15 Replies

In the past few months, I’ve heard (i.e., read articles and seen videos) many good things about the Wayland compositor Hyprland. I decided to try it, and I’ve been using it for almost one month as my daily driver. I’m still not into “tiling” that much, but in Hyprland, you can also switch to classic “stack” window management. I like Hyprland; it feels fast and reactive (also on a PineBook Pro; I’ll blog about Hyprland on a PineBook Pro in the future).

By the way, if you don’t already know:

Hyprland is a dynamic tiling Wayland compositor based on wlroots that doesn’t sacrifice on its looks. It supports multiple layouts, fancy effects, has a very flexible IPC model allowing for a lot of customization, a powerful plugin system and more.

This post is the first of a few articles showing how to install, configure and use Hyprland and additional tools. You can find many GitHub repositories with installation scripts and configuration files for Hyprland, but you end up with the configurations of those repositories, probably without understanding the basic details of Hyprland. I found starting from scratch (following the Hyprland wiki) much more helpful, taking inspiration from some of the above-mentioned GitHub repositories.

By the way, most Hyprland configurations you find on GitHub are primarily about “ricing” (i.e., heavy aesthetic customizations of the desktop). While I love good-looking desktops, I won’t blog about aesthetic customizations much. I’ll focus mostly on configurations and tools for usability.

This first post is only about getting started and having a usable environment with minimal helpful tools: there will be follow-up posts for installing other tools (like a bar and notification system) and configuring other programs (actually, I have already blogged about Variety in Hyprland).

Moreover, all these posts are about Hyprland in Arch Linux since that’s the only OS where I experimented with Hyprland. In particular, I’m using EndeavourOS.

First, install EndeavourOS without a desktop environment (when you get to the installer’s part, where you have to select a desktop environment).

I will use the AUR helper “yay”, which is already installed in EndeavourOS. On Arch, you’ll have to install it yourself, e.g., with the following commands:

Let’s start from https://wiki.hyprland.org/Getting-Started/Master-Tutorial/ and install Hyprland from the official Arch repositories:

As suggested, let’s install the terminal “Kitty” (the default Hyprland configuration has a shortcut to run that).

Of course, later, you can also install another terminal.

Now, you can execute “Hyprland” in your tty. (Remember, I haven’t installed any desktop environment or a login manager).

Note for virtual machines: If you test this in a virtual machine, ensure that 3D is enabled. Moreover, it’s crucial to start Hyprland with the following environment variables so that the mouse is usable; please, remember that the experience in a virtual machine will not be optimal anyway:

When Hyprland starts, you see a warning and a few pieces of information:

To make the warning go away, we edit the generated default configuration file (use either “vi” or “nano” text editors that are already installed in EndeavourOS). To do that, we must start a terminal: by default, the keyboard shortcut is “SUPER + Q” (as shown in the yellow warning):

Now we can edit the file .config/hypr/hyprland.conf and remove the following line:

Save the file, and the warning will go away. In fact, one of the cool features of Hyprland is that it automatically applies changes to that file.

Let’s change the configuration file further. By default, the configuration uses a US keyboard layout. I had to change it to use the Italian layout: Edit that file and change the following part accordingly (in my case, I have an Italian keyboard):

Save the file, and the new keyboard layout will be immediately set.

You might want to install “neofetch” and run it in a terminal (in this example, I’m running inside a KVM virtual machine):

The default configuration uses the shortcut SUPER + E to start the file manager “Dolphin”, which is not installed by default. You could install it. Here, I’m doing something different: Let’s install the file manager “nemo”:

and change the line

into

Let’s save the file, press SUPER + E, and Nemo appears (tiled automatically)

Let’s install the application launcher “wofi” (personally, I prefer “rofi”, but I’ll blog about that in the future):

Wofi is already configured with the following keyboard shortcut:

For example, let’s use SUPER + R and run Firefox (already installed in EndeavourOS) using Wofi: just start typing “fir” until it appears in the list, move the cursor down to select it, and press ENTER (or keep on typing the other letters til “firefox” is the only choice).

Let’s exploit the blur effects of Hyprland: let’s modify the Kitty configuration file (create it if it doesn’t exist) ~/.config/kitty/kitty.conf by adding this line:

Save it and start another instance of Kitty and enjoy the blur effect with the default Hyprland background:

If “0.5” is too much transparency, make the value a bit bigger.

Let’s make Nemo transparent as well with an Hyprland window rule. By default, Nemo is not transparent:

Let’s modify the Hyprland configuration file by adding this line:

Save and restart Nemo, which is now transparent:

The two values in “opacity” set the opacity for the window when it’s focused and not, respectively. By changing the above line as follows:

The Nemo window will be less transparent when active and more transparent when not focused.

Monitor(s) configurations are specified in the Hyprland configuration and are applied on the fly as soon as you save the configuration file. This is the default configuration:

The last value is the scale value. Try to change it to “1.5” or “1.75”, save, and see the scaling automatically applied.

Note that, by default, when running on a real computer (not a virtual machine), Hyprland already scales the display for high resolutions (e.g., it sets it to “1.5” by default).

Running from a Display Manager

The default installation already created a file in the appropriate folder to let SDDM start the Hyprland session.

Let’s install the AUR package “sddm-git” (we need the Git version to avoid a bug that has been fixed but not in the current release; when reading this post, the official package might have already been fixed) with yay:

Then, we enable the service at boot:

If we want to start it without rebooting, the first time we run:

And now you can enter Hyprland from here.

If you’re running inside a virtual machine, you lose the environment variables we saw above: “WLR_NO_HARDWARE_CURSORS=1 WLR_RENDERER_ALLOW_SOFTWARE=1”. To restore them, you must modify the “/usr/share/wayland-sessions/hyprland.desktop” accordingly, in particular, the “Exec” line:

Then, restart “sddm” (by switching to a tty):

Or by rebooting the system.

That’s all for now! Stay tuned for more posts about Hyprland 🙂

Installing EndeavourOS ARM on a PineBook Pro

2 Replies

I have already blogged about installing Arch on a PineBook Pro: the first article and the second article.

In this blog post, I’ll describe how to install EndeavourOS on a PineBook Pro.

As detailed here, https://arm.endeavouros.com/endeavouros-arm-install/, there are 3 ways to install EndeavourOS on an Arm device like the PineBook Pro. In this blog post, I’ll experiment with the first one.

This method consists of a two-step installation process:

  1. use the standard EndeavourOS ISO, booting that from a PC, to install the installation image on an external device (in this example, I will use a USB stick);
  2. then boot the PineBook Pro with the created USB stick and use Calamares to finalize the installation on the very same device you booted from.

Note that I will install EndeavourOS for Arm on an external device, NOT on the eMMC of the PineBook Pro. In this article, I’ll leave a few hints on how to do that on the internal eMMC.

First step

On a standard PC, boot the EndeavourOS ISO (in this example, I’m using the Cassini 2023-03 R2):

After adjusting the keyboard layout and connecting to the Internet, choose “EndeavourOS ARM Image Installer”.

As noted, you need first to insert a USB stick. If you plan to install it on the PineBook Pro’s internal eMMC, you must extract it and place it in a USB adapter. Then, choose “Strat ARM Installer”. That is a textual installation procedure so the installer will open a terminal in full-screen mode.

After pressing OK, you must select the ARM computer (in this case, “PineBook Pro”):

Concerning the file system, in all my experiments, BTRFS has never worked: when rebooting the USB stick (see later), the screen stays blank forever after selecting the boot media. So, the only working solution is EXT4:

Then, you have to write the device where you want to install the installer; the dialog shows all the devices, and you must write the main path of the device, NOT of a possibly existing single partition (in this case, it’s “/dev/sdb”):

Small note: unfortunately, the colors of this textual installer are not ideal 😉

Then, the procedure will prepare the device and download an archive from the Internet for the image to put on the USB stick (it’s a big image, so be patient):

Ultimately, it tells you about the temporary username and password for the installer copied on the USB. It also suggests unmounting the USB with a file manager. In the live environment, you use Thunar to unmount the USB stick. You can recognize the mounted USB stick to unmount because it should show two mounted partitions (the first one is about 128 Mb):

Umounting one of them will also unmount the other one.

Second step

It’s time to boot the PineBook Pro with the UBS stick we created with the abovementioned process. If, in the previous procedure, you created the installer on the eMMC (connected with a USB adapter), you should put the eMMC inside the PineBook Pro.

When the PineBook Pro starts, you should find a way to boot from the USB stick. If you’ve always used the Manjaro installation that comes with the PineBook Pro, you have U-Boot as the bootloader (see my previous blog post for a screenshot of U-Boot booting from the USB stick). If you’re lucky, it should give precedence to the USB stick (I’ve read that this is not always the case, depending on the version of the installed U-Boot). In this example, I have Tow-Boot as the bootloader, so when you see the message telling you to press ESCAPE (or Ctrl-C) to enter the boot menu, please do so:

And then, select the USB as the boot media (of course, if you installed the image on an SD, choose accordingly):

After some textual logs, you should get to the graphical environment for the actual installation. The Window Manager is OpenBox, so, differently from the standard EndeavourOS installer for PC, you don’t have a fully-fledged Desktop Environment (Xfce):

Now, you can choose whether to install an “Official” (e.g., KDE or GNOME) or a “Community” edition (e.g., Sway).

Remember: the installation will be performed on the same media you have just booted. In this example, it’s a USB stick. Again, if you want to install EndeavourOS on the internal eMMC, you first need to extract the eMMC, put it on a USB adapter, do the first procedure described above, put the eMMC back into the PineBook Pro, and start the installation from the eMMC.

As you can see from the screenshots above, there’s no section for partitioning the disk. The partitions have already been created during the first procedure. This installation procedure only finalizes the installation.

I’ve tried both KDE and GNOME.

Enjoy your EndeavourOS installation 🙂

If you like it on a USB stick (remember, it should be a fast USB), you might want to install it on the eMMC (see the notes in this blog post about that). I have already done that, and it works much better than the original Manjaro!

My Ansible Role for “Oh My Zsh” and other CLI programs

1 Reply

I have already started blogging about Ansible; in particular, I have shown how to develop and test an Ansible role with Molecule and Docker, also on Gitpod.

This blog post will describe my Ansible role for installing “Oh My Zsh” and several command line programs. The role also installs the starship prompt or the p10k theme. As for the other roles I’ve blogged about, this one is tested with Molecule and Docker and can be developed with Gitpod (see the linked posts above). In particular, it is tested in Arch, Ubuntu, and Fedora.

This role is for my personal installation and configuration and is not meant to be reusable.

The role can be found here: https://github.com/LorenzoBettini/ansible-molecule-oh-my-zsh-example.

My other post has already described many parts related to zsh installation, configuration, and verification with Ansible and Molecule.

The main file “tasks/main.yml” is as follows:

Besides “zsh” and “git” (which are needed for installing other things, and, in general, I need it daily), this installs several command line tools, like ripgrep, procs, dust, exa, bat, zoxide. Note that, depending on the operating system, these tools must be installed differently (e.g., from the package manager or by downloading a binary distribution). In a few cases, the package names differ depending on the operating system. In such cases, the default names are defined in “vars/main.yml” and properly overridden depending on the operating system:

The task also installs a few fonts (nerd fonts, with emoji, or with icon characters), which are needed because “starship” and “p10k” need a few icon characters; the same holds for other tools like exa.

“Oh My Zsh” is installed by cloning its Git repository; the same holds for some external plugins. The task also sets “zsh” as the default shell for the current user.

Finally, depending on the variable with_starship, which defaults to true, it installs the starship prompt or the p10k theme. These are handled in the corresponding included files “starship.yml” and “p10k.yml”, respectively.

Note that both files copy the corresponding template for “.zshrc” (depending on starship or p10k, the contents of “.zshrc” are slightly different). For “p10k”, it also copies my theme configuration”; for “starship”, I’m OK with the default prompt. The copied “.zshrc” contains several “aliases” for the command line programs installed by this role (e.g., “ls” is aliased to “exa” commands).

Concerning Molecule, I have several scenarios. As I said, I tested this role in Arch, Ubuntu, and Fedora, so I have a scenario for each operating system. In such cases, I test the “starship” installation and verify that the tools that differ for their installations in different operating systems are installed correctly. This is the “verify.yml” (remember that this installs “starship” and NOT “p10k”, so it ensures that only the former is installed):

Concerning “p10k,” I have a separate scenario with a different “verify.yml” (I test this only on Arch since “starship” and “p10k” installations and configurations are the same in all three operating systems):

However, this “verify.yml” could also be used for the other operating systems since it performs the same verifications concerning installed programs. It differs only for the final part.

Of course, this is tested on GitHub Actions and can be developed directly on the web IDE Gitpod.

I hope you find this post useful for inspiration on how to use Ansible to automatize your Linux installations 🙂

TLP: Limiting Battery Charge on LG Gram in Linux

8 Replies

I had already blogged on how to limit battery charge on LG Gram in Linux. In that post, you had to manually set the threshold “80” in the file “/sys/devices/platform/lg-laptop/battery_care_limit”.

With TLP, the procedure is easier and more automatic.

First, you must install tlp (remember that tlp conflicts with power-profiles-daemon, so you have to disable the latter first or uninstall it). In Arch-based distros:

Ensure that the tlp service is enabled on boot and the first time you should start it (“sudo systemctl start tlp”).

By running “sudo tlp-stat”, you should see near the end this line:

Edit the file “/etc/tlp.conf” and uncomment the following lines (note there’s one also for the start of charging, but that option doesn’t seem to be supported in this laptop):

Restart the service (“sudo systemctl restart tlp.service”), and it should be already active (run “tlp-stat” again):

That’s all. This will persist on reboot. However, this will not persist if you hibernate and return from hibernation (unless you restart the tlp service as shown above).

Customizing KDE in Arch Linux on a PineBook Pro

Leave a reply

In a previous blog post (and another one), I showed how to install Arch Linux on a PineBook Pro.

In this blog post, I’m showing how I customize KDE on that installation (thus, it is similar to this other one for GNOME).

I’m not using Wayland because I still don’t find it usable in Plasma. Indeed, I haven’t even installed the Wayland session: I’m using X11.

First of all, the default screen resolution of KDE is too tiny for my eyes. Thus, I set 150% (fractional) scaling:

After that, you have to log out and log in to see the setting in effect.

I also enable “Tap-to-click” in the “Touchpad” settings.

Then, I set “Ctrl+Alt+T” as a shortcut for opening the terminal (Konsole). Actually, the shortcut is already configured in the “Custom Shortcuts”, but it’s not enabled by default in this distribution. It’s just a matter of selecting the corresponding checkbox (the “Examples” checkbox must be selected first to enable the other checkbox):

Then, I install an AUR helper. I like “yay,” so I first installed the needed dependencies:

And then

I install, by using “yay”, the “touchegg” program for touchpad gestures. (Plasma Wayland already provides touchpad gestures, but I prefer to use the X11 session, as I said above). For ARM, we need to install the AUR package:

You will get this warning, but proceed anyway: it compiles and works fine:

I customize touchegg touchpad gestures for KDE by creating the file “~/.config/touchegg/touchegg.conf” with the following contents:

In particular, note the 3-finger gestures (for the “Expose” effect, hide all windows, switch workspace, etc.).

Let’s start “touchegg” and verify that gestures work

And then let’s enable it so that it automatically starts on the subsequent boots:

Let’s move on to ZSH, which I prefer as a shell:

Since I’m going to install “Oh My Zsh” and other Zsh plugins, I install these fonts (remember from the previous post that I had already installed “noto-fonts” and “noto-fonts-emoji”) and finder tool (“curl” is required for the installation of “Oh My Zsh”):

Let’s install “Oh My Zsh” by running the following command as documented on its website:

When asked, I agreed to change my default shell to Zsh. In the end, we should see the prompt changed to the default one of “Oh My Zsh”:

I then install some external plugins:

And I enable them by editing the ~/.zshrc, in particular, the “plugins” line (I also enable other plugins that are part of the OMZ distribution):

Once saved, you have to start a new terminal with zsh to see the plugins in action (remember that, until you log out and log in, the default shell is still BASH, so you might have to run “zsh” manually to switch to ZSH in the currently logged session).

Besides the syntax highlighting for commands, you have completion after “cd” (press TAB), excellent command history (with Ctrl+R), suggestions, etc.

Let’s switch to the “Starship” prompt. Let’s run the documented installation program:

Now, let’s edit the ~/.zshrc file again; we comment the line starting with “ZSH_THEME,” and we add to the end of the file:

Opening another ZSH shell, we should see the fantastic Starship prompt in action, e.g.,

To quickly search for file names from the command line, I install “locate”, enable its periodic indexing and run the indexing once the first time (if you’re on a BTRFS file system, you might want to have a look at this older post of mine):

Then, you should be able to look for files with the command “locate” quickly.

Gnome uses “Baloo” for file indexing and searching, e.g., from “KRunner” (Alt+Space) or the application launcher (Alt+F1 or simply Meta). I like it, and it quickly keeps the index up to date. However, by default, baloo also indexes the file contents, which uses too many resources, so I disable the content indexing feature. I blogged about configuring baloo in another post.

Speaking about KRunner, I find it extremely slow on this laptop; especially the first time you run it, it might take a few seconds to show up. I often use it to search for files or programs, and I need such a mechanism to be fast. I found that the application launcher is instead fast to start (Meta key). However, when you start typing to search, the results are all mixed: applications, files, and settings are all together, and it might not be easy to find what you need:

For this reason, I right-click on the KDE icon and select the “Alternative” “Application Menu”:

This launcher has a valuable feature to categorize the search results. For example, with the exact search string as above, I get results clearly separated:

I also use the “yakuake” drop-down terminal a lot:

I run it once (it’s enabled by default by pressing “F12”), and it will start automatically upon logging in.

That’s all! I hope you enjoyed this post. 🙂

You might also look at my other posts on this PineBook Pro laptop.

Xtext, monorepo and Maven/Tycho

Leave a reply

TL; DR: Xtext sources are now in a single Git monorepo (https://github.com/eclipse/xtext), and the build infrastructure is based entirely on Maven/Tycho (Gradle is not used anymore).

Background

A few years ago, Xtext sources were split into 6 separate GitHub repositories. I did not take part in that decision (I guess at that time, I wasn’t even a committer).

I think that at that time, the splitting was carefully thought out, aiming at making contributions and maintenance easier. In fact, while Xtext is mainly based on Eclipse, it has several core parts that are independent of Eclipse (including LSP support and plain Maven/Gradle projects support, without the Eclipse UI).

Those core parts were built with Gradle. I’m not a fan of Gradle: I’ve always found Gradle gives you too much power as a build tool, not to mention that, typically, the build breaks with new releases of Gradle. On the contrary, Maven has been around for several years and is rock solid. It’s rigid, so you have to obey its rules. But if you do, everything works.
Moreover, its files (POM) and build infrastructures always look the same in Maven projects, so you know where to look when you deal with a Maven project. For Eclipse projects, Tycho complements Maven. Tycho is not perfect, but everything works if you stick with its rules.

The rigidness of Maven/Tycho usually forces you to keep the build simple. And that’s good! 🙂

Of course, also previously, the Eclipse projects of Xtext had to be built with Maven/Tycho. Thus, the build of Xtext was split into 6 repositories with a mixture of Gradle builds and Maven/Tycho builds.

As a result, Xtext was a nightmare to build and maintain. That’s my opinion, of course, but if you read Xtext GitHub issues, PRs, and discussions, you see I wasn’t the only one to say that.

For example, the main problem was that if you changed something in one of the core projects (i.e., on its Git repository), you had to make sure that all the other projects did not break:

  1. once the core project was built successfully, archive its artifacts (p2 repository and Maven artifacts) in Jenkins (JIRO in Eclipse)
  2. trigger downstream jobs, making sure to use the archived artifacts corresponding to the branch with the changes
  3. wait for all downstream jobs to finish
  4. if anything breaks, go back from the beginning and start again!

Moreover, while it was easy to parametrize the Maven and Gradle files to use the archived Maven artifacts, it was a bit harder to use the archived p2 repositories in the target platforms of the Eclipse downstream projects. Typically, you had to temporarily modify and commit the target platform files to refer to the archived p2 repositories corresponding to the current feature branch. Before merging, you must remember to revert the changes to the target platform files.

In the end, the code in the single Git repositories was actually coupled, so the splitting in single Git repositories has always sounded wrong to me.

The release process used to be complex as well. Again, that was due to Git repository splitting and a mixture of Maven/Gradle builds.

A big change

I had always wanted to bring Xtext sources back into a single Git repository and to use Maven/Tycho only. I told the project lead Christian Dietrich about that many times, but he was always reluctant due to the time and effort it would have taken. On January 2023, I finally managed to convince him to give me a chance 🙂

I first started porting all single repositories to Maven/Tycho, removing the Gradle build.

Things were not so easy, but not even impossible. A few tests were failing in the new build infrastructure, but Christian and Sebastian Zarnekow helped me to bring everything to a working situation. We also took the chance to fix a few things in that respect.

In this stage, I also took the chance to set up the CI building also on GitHub Actions (our primary CI is, of course, Eclipse Jenkins “JIRO”).

Then, I moved to the repo merging. This part was easy. I had prepared the single Git repositories thinking about repository merging, so fixing the foreseen merge conflicts was just a matter of adjusting a few things in only a few files (mainly the parent POM).

Finally, I simplified the release infrastructure a lot. We used to have a vast Jenkinsfile for the release, with many complex operations based on Git cloning all the repositories, tagging, and tons of shell operations.

Now, the whole release is carried on during the Maven build (as it should be, in my opinion), including the uploading to the Eclipse web directories. The Jenkinsfile is very small.

The Oomph setup has been simplified as well. It takes time to have a development workspace, but that is due to dependency resolutions and the first Eclipse build. It takes place automatically.

Now, the complete Maven/Tycho build of Xtext, which consists of compilation and running all the tests (almost 40k tests!), takes about 1 hour and a half on Linux (Jenkins and GitHub Actions) and about 2 hours on macOS in GitHub Actions. It takes much less than before when you had to wait for the builds of the single Git repositories and downstream projects. The building of some single Git repositories was, of course, faster, but the overall time for building all the Git repositories was much more significant in the end.

Final thoughts

I hope this vast change improves the maintainability of the project. It should also help contributions from the community. Maybe I’m biased, but personally, I find working and contributing to Xtext much better now, as it used to be in the old days 😉

To me, the effort was very worthwhile!

In the end, it didn’t take long. Of course, I do not measure in months passed from the start of the porting (I started in the first days of January, and the first release with the new infrastructure, version 2.31.0, was at the end of May, though the first milestone with the new infrastructure was at the beginning of April). The time I spent working on that was much less. Of course, I hadn’t worked on that full-time: I did that in my spare time 🙂

In my humble opinion: If your project’s infrastructure and build are too complex, don’t change the build tools: change the latter and keep it simple. 😉 A single big Git monorepo is easier to deal with than 6 small Git repositories, especially when the single Git repositories contain code meant to belong together.

Many thanks to Christian and Sebastian for letting me work on this restructuring and promptly helping me during the process! 🙂

Hyprland and the Variety wallpaper manager

9 Replies

I’ve just started experimenting with the Wayland compositor Hyprland and wanted to use my favorite wallpaper manager, Variety. Unfortunately, Variety does not support Hyprland out of the box. However, it’s easy to make it work also on Wayland.

I’m going to use Arch Linux in this blog post.

First of all, you must install “swaybg”, a wallpaper tool for Wayland compositors, and “variety”:

Now, start variety and do the first-time configuration. Currently, trying to change the wallpaper will not work.

Variety creates the directory “~/.config/variety/scripts”. Edit the file “set_wallpaper” inside that directory and search for the block starting like this:

Change it like that (you could also remove the part about SWAYSOCK if you want or if you don’t plan to use “sway” at all):

This relies on the XDG_CURRENT_DESKTOP environment variable to be set accordingly, which should be like that automatically; you might want to check that:

Restart Variety, and now you can change the wallpaper!

Stay tuned for more posts on Hyprland 🙂