A shitload of new packages on userrepository

Since the 24th of January, the date of the last blog post, I’ve added a shitload of new packages to Some highlights are sonobus, media-downloader-git, baru, dotgit, timeshift, filmulator and tramp.

Expect more packages, as I’m adding new ones frequently. The focus on new packages will probably be scientific tools and maybe a kernel. With that, I’ll probably have to increase the full build frequency from 8h to at least 9 hours.

Continue Reading


Updates on Userrepository and Jarvis

Lately, I’ve been having some problems when building picom-ibhagwan-git and picom-tryone-git. The first one would build OK, but not the second one.

After a bit of debugging, I found out that it was a problem related to the way makepkg and git handle the cache when building these forks. This would also happen when adding the picom-git package: it would build because it’s the first package in alphabetical order and Jarvis builds the packages that way, but not the other two.

To fix this, the build() function no longer uses pushd and popd, allowing the script to work outside the package directory it’s building and delete some parts of the cache folder Jarvis uses.

This has the upside of allowing a better cache cleaning when building the packages. In a future commit, it will clean after itself better, up to a point it cleans every cache and artifact generated during a build.

And yes, $HOME/.npm and $HOME/.cargo I’m looking at you both.

There will be an exception, though: the makepkg.log file in every submodule folder because I use it as a log file for the package build.

Unrelated to this issue is the removal of the onivim2-git package. It takes some time to build and lately it would ask human intervention to confirm some steps, which is not compatible with the way Jarvis builds the packages and because the script is meant to be a tool to build the packages in an automated way.

One last thing: please become a Patron if you want to support Even €1 will help cover the monthly expenses, just over €15. If I get enough patrons, I’ll be able to upgrade the virtual machine to one with better specs, which will allow a higher package compression level, shorter build times and maybe even packaged kernels. Thank you!


Improving boot time

Today, I’ve decided to try and improve the boot time of my laptop, running EndeavourOS. There was no special reason for it other than “Why not?”.

The first thing I made was disabling or masking the following systemd services:

  • systemd-resolved disabled
  • tlp disabled
  • NetworkManager-wait-online disabled
  • lvm2-monitor masked
  • org.cups.cupsd disabled
  • packagekit masked
  • bluetooth disabled (I rarely use the laptop’s bluetooth)
  • blueman-mechanism disabled

With this, I was able to save a few milliseconds and decrease the enabled systemd units to 15, but the impact was negligible.

brunomiguel@kepler: ~
└─ $: systemctl list-unit-files --state=enabled --no-pager
autovt@.service enabled disabled
avahi-daemon.service enabled disabled
dbus-org.freedesktop.Avahi.service enabled disabled
dbus-org.freedesktop.nm-dispatcher.service enabled disabled
display-manager.service enabled disabled
getty@.service enabled enabled
haveged.service enabled disabled
NetworkManager-dispatcher.service enabled disabled
NetworkManager.service enabled disabled
sddm.service enabled disabled
systemd-swap.service enabled disabled
unbound.service enabled disabled
avahi-daemon.socket enabled disabled enabled enabled
roothints.timer enabled disabled

15 unit files listed.

To further improve the boot time, I tested bfq, kyber and mq-deadline I/O schedulers. From the three, the last one allowed to shave off another few milliseconds to the boot time. Next, and last, I changed the mkinitcpio ramdisk compression to lz4 with the default compression options.

With this changes, I went from 17.040 to 15.511 seconds, decreasing a bit more than one and an half seconds in the boot time.

brunomiguel@kepler: ~
└─ $: systemd-analyze time
Startup finished in 10.145s (firmware) + 1.616s (loader) + 2.027s (kernel) + 3.250s (userspace) = 17.040s reached after 2.934s in userspace

brunomiguel@kepler: ~
└─ $: systemd-analyze time
Startup finished in 10.175s (firmware) + 686ms (loader) + 2.041s (kernel) + 2.608s (userspace) = 15.511s reached after 2.529s in userspace

In the future, I might replace GRUB2 with systemd-boot, possibly decreasing the boot time even more.

This was tested in a AMD A9-9420 CPU with the linux-zen kernel. Your mileage may vary depending on your hardware.