Since the 24th of January, the date of the last blog post, I’ve added a shitload of new packages to userrepository.eu. 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
Lately, I’ve been having some problems when building
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.
$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 userrepository.eu. 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!
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.
└─ $: systemctl list-unit-files --state=enabled --no-pager
UNIT FILE STATE VENDOR PRESET
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
remote-fs.target 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.
└─ $: systemd-analyze time
Startup finished in 10.145s (firmware) + 1.616s (loader) + 2.027s (kernel) + 3.250s (userspace) = 17.040s
graphical.target reached after 2.934s in userspace
└─ $: systemd-analyze time
Startup finished in 10.175s (firmware) + 686ms (loader) + 2.041s (kernel) + 2.608s (userspace) = 15.511s
graphical.target 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.