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.
This post can be used for Arch Linux and EndeavourOS.
Recently, a change was committed that highly compresses AUR packages before the actual installation. This takes a lot of time: even on a fast machine, installing something like Chrome or Visual Studio (AUR packages) takes even minutes just for the compression phase. Since I typically remove the generated packages in the AUR cache after installation (e.g., “~/.cache/yay”), the compression is entirely useless to me.
To disable compression altogether, you can edit the file “/etc/makepkg.conf” (requires sudo, of course) and change the line:
Shell
1
PKGEXT='.pkg.tar.zst'
into:
Shell
1
PKGEXT='.pkg.tar'
And you’re done! Now, even if the string “Compressing package…” is printed on the screen when installing an AUR package, that is actually a no-op.
If you don’t want to change the system file “/etc/makepkg.conf”, you can create this file in your user home, “~/.config/pacman/makepkg.conf”, whose contents take precedence over the ones of the system file. Just put the line:
It assumes you have already read the first, second, and third posts.
Let’s now use the POM editor to update the version of JUnit (the Maven archetype is based on an old version of JUnit). When we open the “pom.xml” in the editor, we get a pop-up suggesting installing another extension for analyzing dependencies.
Let’s accept that, as done before, without synching. After the extension is installed, we can visit the corresponding entry in the extensions tab, and, as done before, we use the gear icon to add the extension to our “.gitpod.yml”.
We can then click on the bottom status bar’s button corresponding to the extension (see the one in the left corner in the screenshot) to have an analysis report:
Once it’s finished, we can look at the report. For this simple example, we don’t have any vulnerabilities in our dependencies:
Let’s go back to editing the “pom.xml”; by using the code completion, we can select the newer version of JUnit 4:
Let’s select the latest version (at the time of writing, it is 4.13.2) and let the Java LSP rebuild the project. When we update a dependency in the POM, the analyzer seen above automatically performs another analysis (you can see the feedback in the bottom status bar).
Let’s now explore the “Maven” outline:
We can run lifecycle phases (“compile” in the screenshot above) or single plug-in goals (something I don’t find in the Eclipse Maven support). We can also see the dependencies and their transitive dependencies (“hamcrest” is a transitive dependency of JUnit).
The “Dependencies” entry provides a “+” icon to add a dependency by using the UI. A pop-up will appear where you type a part of the dependency, press ENTER, and see some completions. For example, for log4j:
Upon selection, the POM will be updated. We intentionally selected an old version of LOG4J with a known vulnerability issue to show that the Dependency Analyzer we previously installed detects that:
We can undo the modification we made only for demonstration or use a recent version of log4j (version 2).
We can also create new “Favorites” commands (by pressing the “+” it appears when hovering on “Favorites”). This will open a pop-up for letting us insert a Maven command we want to run often.
For example, let’s insert “package -DskipTests=true”. The favorite will be saved into the Git repository in the file “.vscode/settings.json”. We can also manually tweak it, giving it an alias, e.g., “Create JAR without running tests” (note that we can use content assist in the JSON file):
Now, we have the favorite with the given alias that we can run by using the corresponding triangle:
Speaking of language support for the “settings.json” file, I prefer to disable “autosave”, especially with LSP running in the background, which will continuously ask to synchronize the Java project each time you start modifying the POM. Using the content assist, it is easy to find the corresponding entry and disable autosave:
Since I have already blogged about Hyprland a lot, I want to report that Hyprland runs smoothly on this PineBook Pro. I basically reused all my ricing and customizations that I blogged about in my previous posts about Hyprland.
Here are a few screenshots:
That’s all! As I said, this was meant to be a brief report. 🙂
I’m starting a new blog series about Sway, a Wayland Tiling Window Manager (the Wayland version of i3). Though I’ve already blogged about Sway, this post (and a few future ones) are intended as “getting started tutorials”.
I’ll focus on Sway in Arch, in particular, EndeavourOS.
Let’s start by installing EndeavourOS with no graphical environment installed:
Once the installation is finished, let’s log in to a terminal session since we have no Desktop Environment.
Let’s install the main package:
1
sudo pacman-Ssway
The output shows:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Sway requires additional setup for privilege escalation. Without this setup,
sway will fail to start with session activation permission failures. Choose one
of the two available options (In alphabetical, not recommended, order):
1. polkit: This will make sway "just work" right after installation but may be
a weightier solution than desired.
2. seatd: Already required as a sway dependency, this is a lighter-weight
solution but requires some user configuration: Enabling the service,
adding your user to the "seat" group, then logging out/in again.
Either option should provide the same functionality/stability. Refer to the
Sway wiki page for information.
Optional dependencies for sway
dmenu: dmenu_path support (used alongside wmenu in default $menu)
foot: Terminal emulator used in the default configuration
i3status: Status line generation
mako: Lightweight notification daemon
polkit: System privilege control. Required if not using seatd service [installed]
swaybg: Wallpaper tool for sway
sway-contrib: Collection of user-contributed scripts for sway
swayidle: Idle management daemon
swaylock: Screen locker
waybar: Highly customizable bar
wmenu: Application launcher used in default config
xorg-xwayland: X11 support
xdg-desktop-portal-gtk: Default xdg-desktop-portal for file picking
The package “polkit” has already been installed (see above), so we should be fine.
Let’s also install “foot” to be able to open a terminal with the default configuration and also “wmenu” and “dmenu” (see the output above about these programs):
1
sudo pacman-Sfoot wmenu demnu
Now, we can start “sway” from the command line.
There’s not much with the default configuration: just the workspace indicator (top-left) and the date and time (top-right), not even a wallpaper (we’ll deal with that in a minute).
We can start a terminal (“foot”) with SUPER+ENTER.
To start an application with the application launcher (by default wmenu/dmenu), for example, “firefox” (if installed) we use SUPER+D and start typing in the prompt appearing in the top left corner; a few letters should be enough til you get to the desired program (and press ENTER to launch it).
Of course, the windows are tiled:
NOTE: the SUPER (i.e., the “Window key”) is the default “mod” modifier for keybindings, but you can change it to something else if you want (e.g., “Alt”).
We can switch workspaces with SUPER+<workspace number>, start other terminals there:
We can focus windows with SUPER+<arrow keys> and move a window to another workspace with SUPER+SHIFT+<workspace number>—and close windows with SUPER+SHIFT+Q.
To move the current window and change its position in the tiling, use SUPER+SHIFT+<arrow keys> (instead of arrow keys, you can also use the H, J, K, and L as in Vim):
Let’s install the package “swaybg” (see the output above; that’s the “Wallpaper tool for sway”):
1
sudo pacman-Sswaybg
Now, let’s reload sway with SUPER+SHIFT+C and…
We have the wallpaper!
It’s time to start customizing the configuration.
Let’s create the directory for the configuration file and start from the default one:
1
2
mkdir-p~/.config/sway
cp/etc/sway/config~/.config/sway/
Now, we can edit the “~/.config/sway/config” file. (note that the file ends with “include /etc/sway/config.d/*”, which properly sets a few environment variables and makes them available to systemd).
The first thing I will customize is the keyboard layout: I have an Italian keyboard, so I have to specify that (the default is an American layout). I’ll add this section somewhere in the config file (e.g., near the comments about other input configurations):
1
2
3
4
5
# right Ctrl to switch
input type:keyboard {
xkb_layout it,us
xkb_options grp:rctrl_toggle
}
This will give me an Italian layout by default, and I can switch to an American layout by pressing the right CTRL.
Save the file, reload with SUPER+SHIFT+C, and experiment with the keyboard layouts.
Let’s change the application launcher, which is not very useful in its current shape. Let’s use the Wayland version of Rofi.
1
sudo pacman-Srofi-wayland
Then, let’s open the Sway config file and change the setting of the $menu as follows:
1
set$menu"rofi -show drun -show-icons"
Reload Sway and now pressing the SUPRT+D will get us a much nicer application launcher (just start typing to filter the entries):
Let’s install a file manager, like Nemo.
1
sudo pacman-Snemo
Then, we can create a shortcut for opening the file manager; let’s open the Sway config file, define a variable for the file manager (it will make it easier in the future to switch to another file manager, for example) and a key binding, e.g., SUPER+SHIFT+ENTER:
1
2
3
4
set$filemanager nemo
...
# Start a filemanager
bindsym$mod+Shift+Returnexec$filemanager
Moreover, I prefer Alacritty as a program for terminal:
1
sudo pacman-Salacritty
Then, we just have to change the “$term” definition in the Sway config file: change the line “set $term foot” to
1
set$term alacritty
Now, we need an Authentication Agent, which pops up a window asking you for a password whenever an app wants to elevate its privileges. I prefer the KDE one:
1
sudo pacman-Spolkit-kde-agent
And start it when Sway starts; so in the Sway configuration file:
1
2
### Autostart applications
exec"/usr/lib/polkit-kde-authentication-agent-1"
Since this is “exec”, not “exec_always”, you need to restart Sway, not simply reload it.
Now, if we run from a terminal a “systemctl” command that needs superuser privileges, we get the pop-up dialog asking for a password:
The configuration file already contains a commented section for locking and screensaver:
Shell
1
2
3
4
5
6
7
8
9
10
11
12
### Idle configuration
#
# Example configuration:
#
# exec swayidle -w \
# timeout 300 'swaylock -f -c 000000' \
# timeout 600 'swaymsg "output * power off"' resume 'swaymsg "output * power on"' \
# before-sleep 'swaylock -f -c 000000'
#
# This will lock your screen after 300 seconds of inactivity, then turn off
# your displays after another 300 seconds, and turn your screens back on when
# resumed. It will also lock your screen before your computer goes to sleep.
So, let’s install the involved programs (also mentioned above when we installed Sway):
1
sudo pacman-Sswayidle swaylock
Uncomment the “exec” command; remember that we need to restart Sway to have that mechanism in action. (Of course, you have to wait for 300 seconds). I’m not covering customization of the lock screen and the like here.
We can also set a key binding to lock the screen manually. I usually use SUPER+L; note that this is already bound as a combination to move on the left window (remember the Vim keybindings above?); so, first, I have to uncomment the corresponding bindings (I uncomment them all because I’m not using them: I prefer arrow keys) and add mine:
1
2
3
4
5
6
7
# lock the screen
bindsym$mod+lexec swaylock-f-c000000
...
#bindsym $mod+$left focus left
#bindsym $mod+$down focus down
#bindsym $mod+$up focus up
#bindsym $mod+$right focus right
Let’s install some of the optional packages suggested above when installing Sway (in particular, the “xorg-xwayland” will allow us to run also X applications):
1
2
3
4
sudo pacman-S\
xorg-xwayland\
xdg-desktop-portal-gtk\
xdg-desktop-portal-wlr
That’s all for this first tutorial part; stay tuned for more to come 🙂
It assumes you have already read the first and second posts.
On the bottom, we can see that there are two warnings on our project; let’s click the icon and see them in the “Problems” tab:
Since this is not a Java project managed by Visual Studio Code but a Maven project, we must fix the warning in the POM.
Let’s assume we want to update our project to use the Java version installed in the Gitpod workspace: Java 11 (we can tell that from the warning, but we could also run “java -version” from a terminal to verify that). We open the POM file and update the corresponding properties of Java 1.7: we change “1.7” to “11”:
As soon as we modify the POM, we get a pop-up: the Java LSP detects a change in the project configuration and offers to synchronize the classpath and rebuild the project. Of course, we accept. We accept that, and after a few seconds, the warnings go away.
Note that our choice leads to creating the settings file for this option. We can choose to rebuild the project automatically (“Always”), and the settings file will be updated accordingly. Of course, it makes sense to store such a file in the Git repository.
We can now create a commit with our changes and push them to GitHub.
Remember that the JSON editor is aware of the corresponding schema, so we can enjoy code completion for the string value:
Let’s now say we want to use Java 17 for our project. The workspace provides Java 11, so we must also have Java 17 installed in the Gitpod workspace.
Let’s modify the POM for Java 17 and rebuild the project. Let’s try to run the main file. The Java application still runs, as we can see from the terminal:
Gitpod workspace uses SDKMAN to provide a few versions of tools like the JDK and uses the version required by the project (in this example, Java 17).
We can list the installed JDK in the terminal (and the current one):
1
2
3
$sdk list java|grep installed
||17.0.9.fx|zulu|installed|17.0.9.fx-zulu
|>>>|11.0.21.fx|zulu|installed|11.0.21.fx-zulu
If we wanted to go for Java 21, we should install that version with SDKMAN, but we wouldn’t want to do that manually each time we open a Gitpod workspace. Moreover, instead of the “Zulu” distribution, we might use the “Temurin” distribution.
The recommended way is to provide a custom Dockerfile for our Gitpod workspace to have full explicit control over the versions of the tools we use; this will be part of the Git repository and live with the code.
So we create in the root of our project the file “.gitpod.Dockerfile,” and we configure SDKMAN for the version of Java we want to install and set as the current (the available versions can be discovered with “sdk list java”):
1
2
3
4
5
6
7
FROM gitpod/workspace-full
USER gitpod
RUN bash-c". /home/gitpod/.sdkman/bin/sdkman-init.sh && \
sdk install java 17.0.9-tem && \
sdk default java 17.0.9-tem"
Then, we refer to this Dockerfile in the “.gitpod.yml”:
YAML
1
2
3
image:
file: .gitpod.Dockerfile
...
As before, we can let Gitpod validate our configuration and start a new workspace with the rebuilt Docker image.
As shown in my previous post on Gitpod, you might want to start from a smaller base image with only the needed tools like Java. That would decrease the time to build the custom Docker image. That is out of the scope of this post.
However, rebuilding the Docker image will be done the first time you start a workspace, and the custom image will be cached.
On the new workspace, we can verify that we are using the Java version we installed and set as default:
OpenJDK 64-Bit Server VM Temurin-17.0.9+9 (build 17.0.9+9, mixed mode, sharing)
Again, we commit our changes (including the new custom Dockerfile) and push them to GitHub.
One could use the same strategy for installing a specific version of Maven through SDKMAN. Maven is also installed in the workspace through SDKMAN.
I want to conclude that this process seems long. Still, once you get familiar with the configuration of Gitpod for Java/Maven projects, for new repositories of the same kind, it is enough to immediately put in the Git repository the “.gitpod.yml” and the “.gitpod.Dockerfile.” You can immediately start coding with Gitpod! 🙂
Remember, though, that the first time, you will still have to wait for the build of your custom Docker image.
I love to manage my dotfiles with Chezmoi, which I highly recommend! In a single Git repository, I have common dotfiles and Window Manager specific (KDE, GNOME, Hyprland, and Sway).
However, I prefer to have my Neovim configuration in another Git repository, separate from my Chezmoi dotfiles. I’ve just started learning Neovim, and I’m not yet 100% sure the configuration I use will be the ultimate one (I use Lazyvim); that’s why I want to keep them separate.
Chezmoi offers mechanisms for such situations: https://www.chezmoi.io/user-guide/include-files-from-elsewhere/. In particular, I use “Include a subdirectory from a git repository”: this way, Chezmoi will clone the external Git repository for my Neovim configuration on the first run and will keep it up to date (i.e., “git pull”) at some specified intervals (remember, the default interval is 0!).
You need to create the file “.chezmoiexternal.toml” in the root folder of your Chezmoi file and follow the syntax in the documentation.
For example, I want my “~/.config/nvim” directory (where Neovim configuration lives) to be populated (and kept up-to-date) with the contents of my GitHub repository “https://github.com/LorenzoBettini/starter” (as I said above, I’m using a fork of the Starter repository of Lazyvim):
INI
1
2
3
4
[".config/nvim"]
type="git-repo"
url="git@github.com:LorenzoBettini/starter.git"
refreshPeriod="1h"
Note that I specified a 1-hour refresh interval. Thus, if I issue a “chezmoi update,” it will keep that interval into consideration when deciding whether to check for updates (i.e., “pull”) in the Git repository. However, you also have this option in Chezmoi to force the Git update:
This blog post will describe the new procedure for installing EndeavourOS ARM on a PineBook Pro.
As usual, the instructions can be found here: https://endeavouros.com/endeavouros-arm-install/. Previously, there used to be three possible ways to install the system. Now, if we’re not considering the headless server installation, there’s only one way.
First, download the installation image (“.img.xz”) from the above page. For the PineBook Pro, I downloaded “enosLinuxARM-pbp-latest.img.xz“.
This image must be flashed on the final installation medium. I will install EndeavourOS ARM for PineBook Pro on an SD card in this blog post. The idea is that you then boot the PineBook Pro with such a flashed medium, and the installation procedure will finalize the installation on the same medium; during the textual installation, you specify a few configurations.
Of course, the flashing can be performed on any computer, not necessarily from the PineBook Pro.
The delicate part is ensuring you get the name of the flashing device properly or you wipe a device completely. You can use the command “sudo fdisk -l” to get the list of all the devices.
In my case, the inserted SD card is “/dev/sda“, so I flash the image as follows (again, BE COMPLETELY SURE of the correct device!!!):
Be patient; this will take a few minutes, especially depending on the speed of the SD card.
Then, it’s time to boot the PineBook Pro with the SD inserted.
I’m assuming you already have a boot program that allows you to select the booting device. For example, I have “Tow-Boot”.
At some point, I press ESC to select the booting device:
The textual installation starts.
Remember, it will install the system on the same device you used to boot.
Here are some required information:
Of course, you’ll also be asked for your username and password.
Then, you select the Desktop environment (or no desktop at all):
I selected KDE Plasma. Here’s the summary.
After a few minutes, you should get:
Time to reboot!
Unfortunately, at the first reboot, selecting SD to boot into the installed system brought a failure that no bootable image could be found. However, rebooting and selecting SD again succeeded.
IMPORTANT: as you noted, you have no choice about partitioning and filesystem type: you will get EXT4. To be honest, I never managed to setup BTRFS with the previous EndeavourOS installation anyway.
I could finally land on the newly installed KDE Plasma.
I’d suggest doing some configurations and tweaking, e.g., you need to configure swap since 4 gigabytes of RAM are too few! You could go for a swap file, but I’d recommend using zram as the primary swap.
I hadn’t used Eclipse in Hyprland for a while. It used to work correctly; however, starting from somewhere in version 0.41, something broke, and it’s still broken in the current (at the time of writing) version 0.43.
When I execute Eclipse in Hyprland, i.e., in Wayland mode, the trees in Eclipse, e.g., Package Explorer (but also Project Explorer or the Outline) are displayed correctly until you start expanding the tree or hover with the mouse: the elements of the tree gets corrupted and disappear:
Till the whole tree disappears:
I reported the bug (https://github.com/hyprwm/Hyprland/issues/7829). The bug was closed because it had already been reported: in the beginning, the bug talked about DBeaver, which I didn’t know is an Eclipse-based application: https://github.com/hyprwm/Hyprland/issues/6844. The problem is associated with a previous hack to avoid flickering in the Qt application. Unfortunately, the hack breaks Eclipse-based applications, and it’s still there at the time of writing.
If I want to use Eclipse in Hyprland, I have to run it in X11 mode, i.e., by prefixing its execution with the corresponding environment variable set:
1
env GDK_BACKEND=x11./eclipse
Since I have Hyprland with scaling enabled (1.5) Eclipse in X11 mode (Xwayland) gets pixelated:
To avoid that, as documented in Hyprland, I have to disable XWayland scaling by adding this section in “~/.confgi/hyprland/hypr.conf”:
1
2
3
4
# unscale XWayland
xwayland{
force_zero_scaling=true
}
Now, Eclipse runs in Xwayland without flickering but it’s unreadable to me (after all, it is not scaled):
We can scale it with the environment variable “GDK_SCALE”, but that does not support fractional scaling: set it to 2, and then Eclipse gets too big:
However, I can use another environment variable, “GDK_DPI_SCALE”, which scales text only (not icons; better than nothing!);
I’m using Sway (not as my daily driver) on different computers: PCs and laptops.
For the PCs, I’m using an HDMI monitor. Laptops have different display sizes, e.g., small displays with low resolution and more extensive displays with retina resolution. Thus, I need to set different scaling factors for the different displays.
It’s pretty easy in Sway, and I’ll detail that here.
First, you need to get the information Sway uses to refer to your current monitor:
I want to scale at 1.6 on this computer. Otherwise, I can’t read almost anything.
In “~/.config/sway/config”, I specify scaling for this computer using the name shown above
1
2
# LG GRAM 16
output"LG Display 0x0694 Unknown"scale1.6
Reload the configuration, and now scaling is correctly applied when using this laptop.
On the other laptops (e.g., my Acer Aspire Vero), I repeat the same procedure: get the identifier and add a specific configuration with the identifier; for example, for this other laptop, 1.25 scaling is enough:
1
2
# Acer Vero
output"AU Optronics 0x0C9C Unknown"scale1.25
For HDMI monitors, I want 1.5:
1
2
# HDMI monitor
output"HDMI-A-1"scale1.5
Summarizing, this is the monitor section in my Sway configuration, which automatically sets the desired scale factor according to the computer I’m using:
1
2
3
4
5
6
7
8
9
10
### Output configuration
# HDMI monitor
output"HDMI-A-1"scale1.5
# LG GRAM 16
output"LG Display 0x0694 Unknown"scale1.6
# Acer Vero
output"AU Optronics 0x0C9C Unknown"scale1.25
Of course, you can change many values for each monitor, including resolution and orientation, by specifying the corresponding identifier.
In my case, I only want to change the scaling factor.
The crucial ones are the “qt5ct” and “qt6ct-kde” packages. We’ll use the latter but also install the former for possible old Qt 5 applications, just in case. The “Hack” font is the standard KDE monospace font, and Kvantum is the theme engine. Finally, “breeze” will install the Breeze color schemes we will use in qt6ct.
IMPORTANT: we use the AUR package qt6ct-kde, which is a patched version of “qt6ct”. If you installed packages, as in my previous post on this subject, you’ll have to replace “qt6ct” when installing this AUR package.
Then, we have to set this environment variable in “~/.config/hypr/hyprland.conf” (note that we specify qt5ct, but for Qt 6 applications, qt6ct will be used automatically):
1
2
# For styling
env=QT_QPA_PLATFORMTHEME,qt5ct
Let’s restart Hyprland (I’m assuming “env = QT_QPA_PLATFORM,wayland” is also set).
That’s the standard style of Dolphin, Kate, and Konsole with the default settings:
Let’s open the “Qt6 Settings” application (corresponding to “qt6ct”).
Remember that Qt6 settings will be stored in the file “~/.config/qt6ct/qt6ct.conf”.
First of all, I’m changing the fonts to match the standard ones of KDE:
Remember always to click “Apply” after changing something”.
By restarting the above applications, the fonts now look like in a standard KDE system:
Now, benefitting from the patched qt6ct package, differently from my previous post, we can select the “Breeze” style; similarly, we can select “Breeze Dark (KColorScheme)” in color:
Let’s see the results:
Super! Everything looks great with the above simple setting!
If you look at my previous post without the patched version of “qt6ct”, we had to select the “Breeze Dark” icon to have nice-looking icons in the dark style. Now, we didn’t have to!
Moreover, Kate also automatically uses the dark breeze theme (compare that with the previous post):
Note that you can tweak other settings in qt6ct further.
In particular, you can install other icon packages and select another icon set in qt6ct.
Of course, you could also directly use Kvantum themes, as we saw in my previous post. However, with the patched “qt6ct”, having a nice-looking and consistent theme for KDE applications is much easier.
For example, here I have the workspaces with the following application windows:
Kate (text editor) and terminal (Alacritty)
Dolphin (file manager)
A Firefox window and a Firefox window on GitHub
A Firefox window on YouTube and Thunderbird (email client)
Here’s the Wyabar workspace representation (on the left):
Here I added Google Chrome in the workspace 2:
This is the Waybar module configuration, where the important thing is “{window}” in the “format”. Unfortunately, you must work on defining the rewrite rules and the icon to show as you want. Moreover, these are not icons; they are characters from Nerd fonts:
Probably, your browser will not render the fonts (though you can copy and paste them, and they will be taken correctly). I’m also showing a screenshot of my text editor where the Nerd fonts are rendered correctly:
Of course, you also have a character to be used by default if nothing matches (e.g., a question mark).
I experienced problems with the new version (2:2.11.1) of wpa_supplicant in PineBook Pro, where I have EndeavourOS. WiFi does not work anymore with the new version of wpa_supplicant.
That’s because, by default, the downgrade script uses this archive site https://archive.archlinux.org or the local cache (which I always clear). However, that archive is for the x86 architecture. You must use a corresponding archive for the arm architecture, like https://alaa.ad24.cz/, using the command line option:
1
2
--ala-url <url>
location of ALA server, defaults to "https://archive.archlinux.org"
So I ran (note that I also chose to add the package to “IgnorePkg” to avoid further future updates, at least until the bug is solved):
In this post, I’ll show how to configure GRUB (without os-prober, which doesn’t work well with different Linux distributions like Fedora and Arch) by delegating to other GRUB configurations (i.e., chain loading).
I’ll use ArchEndeavourOS (BTRFS) and Fedora. I’ll show the two possible solutions: EndeavourOS as the main GRUB delegating to Fedora and vice-versa.
First, we need to tweak both distributions’ GRUB configurations.
As a further alternative, if you want to keep the UEFI entry, you must remove the culprit call
1
fwsetup--is-supported
As usual, you must run “grub-mkconfig”.
Preparing Fedora
It’s better to remove os-prober since, as I said above, it wouldn’t work for other Linux distributions, and it takes some time when updating GRUB: edit with sudo the file “/etc/default/grub” and ensure you have this line:
1
GRUB_DISABLE_OS_PROBER=true
Also, ensure you have this line (if you use EndeavourOS as the principal GRUB, otherwise you will not see Fedora entries):
1
GRUB_ENABLE_BLSCFG=false
But then, you’ll have to update GRUB after you install a new kernel. (if you use Fedora as the principal GRUB, the above modification is unnecessary).
Add this entry (for more details on these entries, please see my old post):
1
2
3
4
5
6
7
8
9
menuentry "EndeavourOS" {
insmod part_gpt
insmod btrfs
insmod ext2
rmmod tpm
set root='hd0,gpt3'
set prefix="/@/boot/grub"
configfile "${prefix}/grub.cfg"
}
By default, Fedora does not show the GRUB menu, which would break this post’s intent.
To show the grub menu, run:
1
sudo grub2-editenv-unset menu_auto_hide
Update GRUB:
1
sudo grub2-mkconfig-o/boot/grub2/grub.cfg
Reboot the virtual machine configured to start with Fedora, and you’ll see the EndeavourOS entry to boot EndeavourOS (you will get to the EndeavourOS GRUB entries from the Fedora GRUB):
Booting Fedora from EndeavourOS
As done above, inspect the partitions:
Shell
1
2
3
4
5
6
7
8
9
10
11
[bettini@eos-multi-kvm~]$sudo lsblk
[sudo]password forbettini:
NAME MAJ:MIN RMSIZE RO TYPEMOUNTPOINTS
sr011:011024M0rom
vda254:00100G0disk
├─vda1254:10500M0part/boot/efi
├─vda2254:2050G0part
├─vda3254:3049,5G0part/var/log
/var/cache
/home
/
Fedora is in “vda2”:
Edit with sudo “/etc/grub.d/40_custom” and add this entry:
1
2
3
4
5
6
7
menuentry "Fedora" {
insmod part_gpt
insmod btrfs
insmod ext2
set root='hd0,gpt2'
configfile /boot/grub2/grub.cfg
}
Update GRUB:
1
sudo grub-mkconfig-o/boot/grub/grub.cfg
Reboot the virtual machine to start with EndeavourOS, and you’ll see the Fedora entry to boot Fedora (you will get to the Fedora GRUB entries from the EndeavourOS GRUB):
Final notes
Fedora has its way of updating the system, which requires rebooting, installing updates, reboot again. This process doesn’t work well when Fedora is not the principal booting system; at least, it requires attention to manually select the Fedora entry a few times during this update/booting process. Thus, it’s better to keep Fedora as the principal booting system.
Unfortunately, I also started to experience problems similar to those with KDE Plasma 6.1 (Linux EndeavourOS and Arch); as in the other blog post, the problem is only with Wayland.
I’ll use this example project (taken from my TDD book): https://github.com/LorenzoBettini/demo-attsw. It is a simple Java Swing application where UI tests are written with AssertJ Swing. I run “mvn verify,” and most of the UI tests fail (when the AssertJ Swing bot tries to interact with the application window, it mostly gets the position wrong). This is the leading cause of the failure: I get this dialog popping up from KDE, “Remote control requested”, coming from “xdg-desktop-portal-kde“:
This shows up as soon as one of the UI tests starts.
First, I must click “Share” (of course, tests have already failed). Note that the dialog remembers the setting for the application you used to run the tests. For example, if you change the Java version to run the tests, you’ll get the dialog popping up again.
Starting the UI tests again still leads to failures. I have to change these system settings:
Now, UI tests finally succeed. Though, they tend to be quite flaky. I see that while they run, since they interact with the keyboard and mouse, other windows get focused, and some interactions are performed on the other windows, not one of the applications under test. Things improve if you only leave the application under test on the screen. It is even better to place the mouse in the part of the screen where the application under test usually appears.
In general, with such kinds of UI tests, it might be better to switch to X11… 🙁
However, the next part is different from what I have always seen in a Fedora installation, at least the default Gnome one: you have more things to set:
I won’t show the other installation parts since they are standard in Fedora installation. I went with the defaults because I’m trying that in a virtual machine, so I’ll stick with the default partitioning scheme.
After the installation is concluded, let’s restart, and here’s the greeting login screen:
And once you log in:
No more help message: you’re on your own 😉
Probably, a basic knowledge of Sway is required and assumed.
At least, you may remember the SUPER + d shortcut to open the application launcher, and you can run something from there.
It’s better if you know about the basic shortcuts, which are the Sway default in this installation:
SUPER+SHIFT+Q: close the current window
SUPER+ENTER: run the default terminal, which here is “foot”
SUPER+SHIFT+C: reload Sway
The look and feel of the installed and configured Sway is nice; the “Waybar” is configured with a few helpful information. You have the tray icon (on the right) for network connections—the volume control opens a dialog to configure the volume and microphone. Moreover, media keys are already configured. For example, the ones for volume, and you have a visual feedback:
A few screenshot key bindings are also configured:
# Capture the currently active output
Print
# Capture the currently active window
Alt+Print
# Select and capture a custom rectangular area
Ctrl+Print
However, you have no visual feedback for such features; more effort could have been made.
Software-wise, you don’t have much installed: you have Thunar as a file manager but no text editor, for example.
The disappointing part is the configuration of Sway: you might expect you have everything already created in the “~/.config” subdirectories, following the standard Sway and other application structures. Unfortunately, it’s not like that: you have nothing in your home directory in that respect. Everything is configured system-wide. Of course, you can customize everything, but you must go through the documentation: https://docs.fedoraproject.org/en-US/fedora-sericea/configuration-guide/.
Several precedence rules are documented in the link, but I find that mechanism quite cumbersome. There are configuration files spread in many places:
1
2
3
4
/etc/sway/
/etc/sway/config.d/
/usr/share/sway/config.d/
/etc/sway/environment
You have to add additional files to your home folder or completely override a configuration file with one with the same name in your configuration folder.
I’ve just started experimenting with Sway; such a mechanism is hard to grasp and use.
For example, the installation procedure completely forgot the “Italian” layout I specified for the keyboard! There’s no “~/.config/swat/config” file to modify quickly. Should I copy the default one there and modify it; however, the part about the keyboard layout is not even commented on.
After reading the documentation, I came up with this (the configuration file’s name is my own; I haven’t followed a pattern; the important thing is the directory where the “.conf” file is):
Then, I reloaded Sway with SUPER+SHIFT+C and got the Italian keyboard layout.
But it wasn’t easy…
In general, I had the impression that Fedora Sway is not for beginners of Sway; however, it doesn’t seem to be for Sway experts either: they’d expect to customize Sway as they see fit anyway, and probably they have their dotfiles ready to be used.
However, maybe Fedora Sway is not bad for starting to experiment with Sway in the end. 🙂
This blog post documents my way of setting environment variables in Sway.
Let’s install qt6ct for some experiments.
1
sudo pacman-Sqt6ct
If we run it, we get the following problem:
Where can environment variables be specified when using Sway?
In my experiments, “~/.profile” is not loaded (either when logging in or using SDDM). Instead, “~/.bash_profile” and “~/.zshenv” should be used for BASH and ZSH, respectively.
So, in those files, source “~/.profile” explicitly
Shell
1
[[-f~/.profile]]&&.~/.profile
Let’s put the environment variable declaration and export into “~/.profile”
Shell
1
2
# For styling
export QT_QPA_PLATFORMTHEME=qt5ct
Exit Sway and get back in, and now qt6ct is happy:
If we want also to have our environment variables available to systemd, we can follow another strategy to specify environment variables in one place.
First of all, let’s create a file (or any, if you want to have several environment variables categorized in different files) that ends with “.conf” in the directory “~/.config/environment.d/”.
For example, I have “~/.config/environment.d/10-env.conf” (these files are read by systemd alphabetically); I move the environment variable definition in this file (so, I remove it from “~/.profile”):
Each time you modify that directory, you have to run this command:
1
systemctl--user daemon-reload
To verify that systemd read this file, run
1
systemctl--user show-environment
And you should see the line:
1
QT_QPA_PLATFORMTHEME=qt5ct
If you restart Sway and run qt6ct, you will see that qt6ct complains again. The environment variable is only visible to the systemd. We have to export the variables read by systemd.
To avoid duplication, we can use the program “/usr/lib/systemd/user-environment-generators/30-systemd-environment-d-generator”, which does precisely that (of course, it handles all the environment variables in the “.conf” files in the environment.d directory). In “~/.profile” we now put this line:
Before KDE Plasma 6.1 (released a few days ago and already available in Arch), if you wanted to configure a “modifer-only” shortcut (e.g., SUPER key, also known as META, to activate the “Overview” effect), you had to manually modify the “~/.config/kwinrc” file and add these lines:
In Plasma 6.1, modifier-only shortcuts must not be specified in “~/.config/kwinrc”: they are in “~/.config/kglobalshortcutsrc” and, as such, can be visually specified through the standard KDE shortcut system settings:
By default, SUPER is configured to start the “Application Launcher” (this means that previous specifications in “ModifierOnlyShortcuts” in “~/.config/kwinrc” are not considered anymore).
If we want to assign it to “Overview”, we first search for current shortcuts for “Overview”:
Click on “Add custom shortcut” and press SUPER. You are notified about an existing binding for the “Meta” key:
And, of course, we choose to reassign it.
Done!
Thus, such a setting will be stored in “~/.config/kglobalshortcutsrc”:
1
2
[kwin]
Overview=Meta+W\tMeta,Meta+W,Toggle Overview
Nice feature, though it breaks existing configurations, which need to be adapted 😉
I’ll show how to do that in this blog post, assuming you’ve already installed a few KDE applications, like Dolphin, Konsole, and Kate (see the above-linked blog post).
WARNING: the strategy shown in this post is not optimal, in my humble opinion. There’s a more recent post where I show a better strategy (in my opinion).
As in all my Hyprland posts, this is based on Arch Linux; I mainly use EndeavourOS.
The crucial ones are the “qt5ct” and “qt6ct” packages. We’ll use the latter but also install the former for possible old Qt 5 applications, just in case. The “Hack” font is the standard KDE monospace font, and Kvantum is the theme engine.
Then, we have to set this environment variable in “~/.config/hypr/hyprland.conf” (note that we specify qt5ct, but for Qt 6 applications, qt6ct will be used automatically):
1
2
# For styling
env=QT_QPA_PLATFORMTHEME,qt5ct
Let’s restart Hyprland (I’m assuming “env = QT_QPA_PLATFORM,wayland” is also set).
That’s the standard style of Dolphin, Kate, and Konsole with the default settings:
Let’s open the “Qt6 Settings” application (corresponding to “qt6ct”).
Remember that Qt6 settings will be stored in the file “~/.config/qt6ct/qt6ct.conf”.
First of all, I’m changing the fonts to match the standard ones of KDE:
Remember always to click “Apply” after changing something”.
By restarting the above applications, the fonts now look like in a standard KDE system:
Let’s try to change the appearance colors to a darker setting in the palette:
Unfortunately, the result is a small disaster:
Dolphin is the only application that reacted to the change but in a wrong way.
Instead, let’s revert to the default palette and change the Style to Kvantum (“kvantum-dark”):
The result is improving:
However, it’s still ugly: the icons are mostly invisible, and the Konsole menu bar does not like this change.
Let’s fix the icons first: we select “Breeze Dark.” (Remember: We installed them at the beginning.)
The result has improved: icons are better visible, and in Dolphin, folder icons all look fine:
The rest of the ugly look is due to the default Kvantum theme.
So, from now on, we can try to select a Kvantum theme that makes the KDE applications look nice.
Let’s open Kvantum (“Kvantum Manager”) and try with another theme, e.g. “KvAdaptaDark”:
Now KDE applications look better:
Unfortunately, there’s a white bar in Konsole.
Moreover, Kate does not use the dark settings for the editor. However, Kate allows you to select a color scheme:
For example, by selecting “KvAdaptaDark” here as well, we get a nice-looking Kate:
Remember that Kvantum settings will be stored in the file “~/.config/Kvantum/kvantum.kvconfig”.
Now, you can experiment with other Kvantum themes.
For example, this is “KvArcDark”, which still has problems with Konsole menus:
Or “KvGnomeDark”, which doesn’t look bad after all (probably it’s the best up to now: we don’t even have the white bar in Konsole):
You can further tweak each Kvantum theme and change other settings in qt6ct.
In particular, you can install other icon packages and select another icon set in qt6ct.
Stay tuned for another post for styling Qt and KDE applications.
The new JvmGenericTypeValidator was introduced to automatically perform several Java-related checks in the hierarchy of the inferred JvmGenericTypes of an Xbase language, with the corresponding error reporting.
For example, cycles in a hierarchy, extension of a final class, proper extension of an abstract class (do you implement all the abstract methods or declare the inferred class as abstract?), proper method overriding, etc. It also performs duplicate elements checks, like duplicate parameter names, duplicate fields and duplicate methods (keeping the type-erasure into consideration when using types with arguments).
This mechanism assumes that you implement the JvmModelInferrer “correctly”.
It only checks the first inferred JvmGenericType for the same DSL element (i.e., if for an element Entity you infer two JvmGenericTypes, t1 and t2, only the first one will be checked).
Moreover, it only checks Jvm model elements with an associated source element.
Concerning intended classes to extend and interfaces to extend/implement, it assumes the model inferrer uses the new JvmTypesBuilder#setSuperClass(JvmDeclaredType, JvmTypeReference) and JvmTypesBuilder#addSuperInterface(JvmDeclaredType, JvmTypeReference), respectively.
Currently, this validator must be enabled explicitly through the composedCheck in the MWE2 file or the @ComposedChecks annotation in the validator, e.g., @ComposedChecks(validators = JvmGenericTypeValidator.class).
The Domainmodel example now uses this validator.
The Xtend validator has been refactored to also use this validator.
This means that if you implement your model inferrer “correctly” and enable this validator, you get lots of valuable checks, which you would usually have to implement yourself (if you ever did that).
Let’s see that in action in the Domainmodel example (you can materialize that in your workspace through the Xtext wizard).
Moreover, its model inferrer uses the above-mentioned API in JvmTypesBuilder for specifying the expected superclass, if present (note that setSuperClass is used here as an Xtend extension method and uses the syntactic sugar for setter):
Let’s start another Eclipse instance (in the GitHub project, you can use the launch “/org.eclipse.xtext.example.domainmodel.ui/Domainmodel Eclipse.launch”).
Let’s create an Eclipse plug-in project; in the MANIFEST, let’s add the Xbase lib as a dependency, and in the “src” folder, we create a file “Example.dmodel”, accepting to convert the project to an Xtext project.
Let’s start with a method with two parameters with the same name and see the reported error:
Let’s add two methods with the same name and a parameter but with the same type-erasure in the generic type:
Remember using setSuperClass to express that the extended class must be a class, not an interface? Let’s see that in action:
And don’t try to extend a final class 😉
Let’s see what happens if you try to extend an abstract class without defining all the abstract methods (remember that in the Domainmodel, all entities are mapped to concrete Java classes):
Of course, the error goes away if you implement the abstract methods:
Before going on, remember that implementing these validation checks manually is not trivial: you have to consider type-erasure and inherited methods. You get them for free thanks to the JvmGenericTypeValidator 🙂
Note that the error about missing implemented abstract methods, as the one above, contains information (i.e., in Xtext, “issue data”) about the missing methods, their types, and parameters. Thus, you could implement a quickfix to add the implementation methods automatically. This is not trivial, but it’s doable with the provided information. You might want to take inspiration from what Xtend does (remember that now Xtend uses the JvmGenericTypeValidator).
Let’s extend the Domainmodel a bit:
we add the optional “abstract” keyword for entities
we add the “implements” interfaces feature
These are the relevant parts in the modified grammar:
Let’s run MWE2 to regenerate the language, and let’s adapt the model inferrer accordingly (note the use of the new method JvmTypesBuilder.addSuperInterface; this method should also be used in the case your Xbase DSL has elements that are mapped to interfaces extending other interfaces):
Let’s restart the running Eclipse and see the new features in action, according to checks automatically performed by the JvmGenericTypeValidator.
For example, similarly to extended classes, we have the check for implemented interfaces:
Moreover, declaring a mapped Java class as abstract is taken into consideration: now we don’t have errors anymore with an abstract entity:
And, of course, mapped implemented interfaces are considered when checking whether a concrete class implements all the abstract methods:
Speaking of quickfixes, we can create a quickfix that intercepts the problem of a concrete entity missing implemented methods to turn the entity into an abstract one:
Other features not shown in this blog post and not implemented by the Domainmodel example are related to declared thrown exceptions in operations. The JvmGenericTypeValidator will check that the thrown exceptions are correct in the case of overridden methods, according to the Java semantics.
Note that the JvmGenericTypeValidator can be customized if needed. For example, Xtend customizes it.
On a side note, while I took care of implementing and testing the JvmGenericTypeValidator and refactoring Xtend validation accordingly, most of the code extracted in JvmGenericTypeValidator comes from the original implementation in the XtendValidator made by Sebastian Zarnekow!
I typically have several EndeavourOS installations on my computers: one for KDE, one for Hyprland, etc. Thus, I want to have different UEFI entries, but they would all have “endeavouros”, each overriding the others.
You can change the grub ID later by issuing a proper “grub-install” program from the running system or by booting it with the live ISO and then chrooting it.
Why not specify a different grub ID during the installation?
It’s easy to do so:
Once you boot the live ISO, before starting the installation, open a terminal (in the current version, the live environment is KDE, so you open Konsole);
Open the file “/etc/calamares/modules/bootloader.conf” with an editor (e.g., “sudo nano /etc/calamares/modules/bootloader.conf”; you need sudo but no password in the live environment);
Look for the line (near the end):
1
efiBootloaderId:"endeavouros"
and change it to a different string (e.g., “eos-kde” when you install KDE, “eos-gnome” when you install GNOME, etc.);
Save the file and go on with the installation as usual!
Now, each installation will have a separate and different grub id.
We use cookies on our website to give you the most relevant experience by remembering your preferences and repeat visits. By clicking “Accept All”, you consent to the use of ALL the cookies. However, you may visit "Cookie Settings" to provide a controlled consent.
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. These cookies ensure basic functionalities and security features of the website, anonymously.
Cookie
Duration
Description
cookielawinfo-checkbox-analytics
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".
cookielawinfo-checkbox-functional
11 months
The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".
cookielawinfo-checkbox-necessary
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".
cookielawinfo-checkbox-others
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.
cookielawinfo-checkbox-performance
11 months
This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".
viewed_cookie_policy
11 months
The cookie is set by the GDPR Cookie Consent plugin and is used to store whether or not user has consented to the use of cookies. It does not store any personal data.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
