Proton is a compatibility layer for Windows games to run on Linux. Running a Windows games is mostly just hitting the Play button within Steam. It’s that good that many games now run faster on Linux than on native Windows. That’s what makes the Steam Deck the best gaming handheld of the moment.

But a compatibility layer is still a layer, so you may encounter … incompatibilities. Ember Knights is a lovely game with fun co-op multiplayer support. It runs perfectly on the (Linux-based) Steam Deck, but on my Ubuntu laptop I encountered long loading times (startup was 5 minutes and loading between worlds was slow). But once the game was loaded it ran fine.

Debugging the game reveled that there were lost of EAGAIN errors while the game was trying to access the system clock. Changing the numer of allowed open files fixed the problem for me.

Add this to end end of the following files:

• in /etc/security/limits.conf:

* hard nofile 1048576

• in /etc/systemd/system.conf and /etc/systemd/user.conf:

DefaultLimitNOFILE=1048576 

Reboot.

(In case you don’t know rakudo-pkg: it’s a project to provide native packages and relocatable builds of Rakudo for Linux distributions.)

The downward spiral of Travis since it was taken over by a Private Equity firm (there is a pattern here), triggered a long coming refactoring of the rakudo-pkg workflow. Until now the packages were created on Travis because it supported running Linux containers so we could tailor the build for each distribution/release. Almost at the same time JFrog announced it was sunsetting Bintray and other services popular with FOSS projects. The deb and rpm repos needed a new home.

Oh well, Travis and Bintray will be missed and certainly deserve our thanks for their service during years. It was difficult to imagine a better time to implement a few ideas from the good old TODO list.

From Travis to Github Actions

Github Actions is way faster than the post-P.E. Travis. Builds that took a few hours (we build around 25 distro/version combinations) now are done between 10 and 20 minutes. Not surprisingly this not only meant learning a complete new tool, but also a complete rewrite of the rakudo-pkg workflow.

Running on Github also means that every Github user can fork the repo including the rakudo-pkg Github workflows. One of the advantages of a rewrite is implementing new functionalities, like the new feature of rakudo-pkg to allow everyone to test the upstream MoarVM/NQP/Rakudo and zef commits/releases:

From Bintray to CloudSmith with Alpine repositories

Cloudsmith has a huge advantage over Bintray: it supports Alpine Linux repositories, making it a great addition to the rpm and deb repositories we already offer. The packages in the old repositories were GPG signed by BinTray. From now onwards, rakudo-pkg will be signed with his own key on Cloudsmith. Check the project’s README for instructions how to change your configuration. So far the experience with CloudSmith has been stellar. Their support is impressively responsive and they solve issues immediately, sometime while we were chatting about it.

From fpm to nfpm

rakudo-pkg created packages with the venerable fpm, written in Ruby. While the tool is extremely capable, I spent most of the time of a release getting fpm to build on new versions of distributions. The Ruby Gems ecosystem looks like a moving target. Enter nfpm, inspired with fpm but with the promise of a single binary. Written it Go, it’s more accessible to me to understand how it works and send fixes upstream if needed. The devs are also very responsive and fixed one issue I encountered extremely fast.

Feel free to open issues of send PRs if I missed something or if you have ideas to improve rakudo-pkg

(Post moved from nxadm.wordpress.com.)

rakudobrew, inspired by perlbrew, is a way to manage (and compile) different versions of rakudo. nine argued that it’s primarily meant as a tool for rakudo developers. Because of the increased complexity (e.g. when dealing with modules), it’s not targeted at end-users. While being a big fan of rakudobrew, I agree with nine.

The problem is that there are no Linux binaries on the download page (there are for MacOS and Windows), so users are stuck with building from source (it can be fun, but after a while it isn’t).

rakudo-pkg is a github project to help system administrators (and hopefully Rakudo release managers) to easily provide native Linux packages for end users. So far, I added support for creating Ubuntu 16.04 LTS amd64 and i386 packages and Centos 7 amd64. These are the systems I use the most. Feel free to add support for more distributions.

rakudo-pkg uses Docker. The use of containers means that there is no longer need for chasing dependencies and no risks of installing files all over your system. It also means that as long the building machine is a Linux 64-bit OS, you can build packages for all supported distributions.

Within the containers, rakudo-pkg uses fpm. The created packages are minimalistic by design: they don’t run any pre/post scripts and all the files are installed in /opt/rakudo. You’ll have to add /opt/rakudo/bin to your PATH. I also added two additional scripts to install Perl 6 module managers (both have similar functionalities):

install_panda_as_user.sh
install_zef_as_user.sh

If you just want to create native packages, just go to the bin directory and execute the run_pkgrakudo.pl command. In this case there is no need to locally build the Docker images: you’ll automatically retrieve the image from the rakudo namespace on Docker Hub. Of course, if you want to create the container images locally, you can use the supplied dockerfiles in the docker directory. Have a look at the README.md for more information.

You can find examples of packages created with rakudo-pkg here (they need to be moved to a more definitive URL)[dead link, the packages reside now at CloudSmith).

Have fun.

rakudo-pkg repo

(Post moved from nxadm.wordpress.com.)

If you use USB disks for off-site backups, it’s a good idea to encrypt them:

• Install the cryptography software:

sudo apt-get install cryptsetup

• Write some random data to your disk (we will assume it’s called /dev/sdx, type “dmesg” after inserting the disk to figure out the device, or if it’s windows formatted and automounted have a look at the output of “mount”):

sudo dd if=/dev/random of=/dev/sdx bs=4K

This will taken a long time, maybe a few days (create some IO). A good -shorter- compromise (a day) is:

sudo badblocks -c 10240 -s -w -t random -v /dev/sdx

• Create a new Linux partition table with cfdisk (create new partition table if asked, chose New and assign all the disk, use a primary partition).

sudo cfdisk /dev/sdx

• Setup a partition using fdisk (compatible with the new 4KB block size drives):

sudo fdisk -uc /dev/sdx

Command (m for help): d
Selected partition 1
Command (m for help): n

Command action
e   extended
p   primary partition (1-4)
p

Partition number (1-4): 1
First sector (2048-2930277167, default 2048):
Using default value 2048
Last sector, +sectors or +size{K,M,G} (2048-2930277167, default 2930277167):
Using default value 2930277167

Command (m for help): t
Selected partition 1
Hex code (type L to list codes): 83

Command (m for help): p

Disk /dev/sdx: 1500.3 GB, 1500301910016 bytes
81 heads, 63 sectors/track, 574226 cylinders, total 2930277168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4fabbfc4

Device Boot      Start         End      Blocks   Id  System
/dev/sdx1         2048  2930277167  1465137560   83  Linux

Command (m for help): w

The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

• Create the encrypted partition. Make the passdphase long and difficult to guess:

sudo cryptsetup --verbose --verify-passphrase luksFormat /dev/sdx1

• Create a filesystem (I am using ext4, the chose device and label name is “disk5”, change it to your taste):

sudo cryptsetup luksOpen /dev/sdx1 disk5
sudo mkfs.ext4 /dev/mapper/disk5 -L disk5
sudo cryptsetup luksClose disk5

• Mount and umount it:

sudo /dev/mapper/disk5 /mnt
sudo umount /mnt
sudo cryptsetup luksClose disk5

That’s it!

(Post moved from nxadm.wordpress.com.)

• Install the needed software.

sudo apt-get install cuetools ffmpeg flac shntool

• In case the source file is one unsplitted ape file, you can convert it to flac first.

ffmpeg -i sample.ape sample.flac

• In case the cue file is not a separate file, but included in the flac file itself, split them.

metaflac --show-tag=CUESHEET sample.flac | grep -v ^CUESHEET > sample.cue

(NB: The regular syntax is metaflac --export-cuesheet-to=sample.cue sample.flac, however often the cue file in embedded in a tag instead of the cuesheet block).

• Split the album flac file into separate tracks:

cuebreakpoints sample.cue | shnsplit -o flac sample.flac

• Copy the flac tags (if present):

cuetag sample.cue split-track*.flac

That’s it.

(Post moved from nxadm.wordpress.com.)