Fryboyter

Thanks to Musk I noticed again that I use Mastodon

Recently, after some back and forth, Elon Musk finally bought Twitter. Shortly after, various articles were published about what alternatives there are. Why not before? Never mind.

Due to the takeover of Twitter, I was wondering if I already used something like Twitter for fryboyter.de. Spontaneously the answer is no, because I don’t care about the so-called “social media”. That’s why I don’t have an account at Twitter or Facebook. But there was something there some time ago.

After thinking about it a bit, I remembered that at some point I experimented with IFTTT to publish the articles published on fryboyter.de on other platforms. But that was a long time ago.

As I just noticed, the account at IFTTT still exists. And the applet is on the one hand still active and on the other hand it publishes the articles of fryboyter.de on a, my, Mastodon account. And even more surprising, there are people reading my publications there.

For now I will leave the applet / account active. So if you want, you can keep up with my releases via https://social.tchncs.de/@fryboyter.

OSBN

Download PKGBUILD file conveniently to create a package with it

Every now and then I need a PKGBUILD file to create a package for Arch Linux, for example to install it on multiple computers in a LAN.

Let’s take https://aur.archlinux.org/packages/ttf-iosevka-term as a random example. For example, one can click on “View PKGBUILD” at mentioned link and then save the displayed content in a PKGBUILD file locally. Alternatively, one can also run git clone –depth 1 https://aur.archlinux.org/ttf-iosevka-term.git. This automatically saves the desired file but you have to know the exact link. I don’t like either solution very much.

Today I came across the tool pbget. With this one only needs to know the name of the package to be created. Thus, the command pbget –aur ttf-iosevka-term is sufficient to download the desired PKGBUILD file. It is necessary to use –aur in this case, because ttf-iosevka-term is only available in the AUR and pbget only searches the official package sources by default.

The command should create the directory ttf-iosevka-term and store the PKBUILD file in it. If you change to this directory and run makepkg -crs PKGBUILD -noconfirm the package will be created. Or you can run makepkg -cirs PKGBUILD -noconfirm to also install the package.

By the way, pbget can be found in the AUR.

OSBN | Arch

Install specific version of Composer at Uberspace

When I just tried to update a Wallabag installation at Uberspace.de, I got the following error message.

Your lock file does not contain a compatible set of packages. Please run composer update.

  Problem 1
    - Root composer.json requires composer < 2.3, found composer[2.3.10] but it does not match the constraint.

The recommendation to run composer update does not help in this case. The problem is that Uberspace has version 2.3.10 of Composer installed. Wallabag, however, currently requires Composer in a version < 2.3. So far I had with Uberspace actually only cases where certain packages were too stable (one could also say too old).

So, at least temporarily, a workaround is necessary. On the Uberspace in question, I ran the following commands.

wget -qO composer-setup.php https://getcomposer.org/installer
php composer-setup.php --install-dir=/home/$USER/bin --filename=composer --version=2.2.17

The first command downloads the installer of Composer. The second one downloads version 2.2.17 of Composer and saves it in the ~/bin directory with the filename composer.

I was then able to update Wallabag without any problems. Since ~/bin is part of $PATH and Composer is not necessary for using Wallabag, I renamed the file to composer.old to avoid problems with other installed software that needs a newer version.

OSBN | Linux

It is also possible to use Arch Linux if you have a life

Yesterday, an article was published on gnulinux.ch regarding OS decision trees. This is, hopefully, not meant to be completely serious. Nevertheless, I would like to give my Senft (yes, in francs it is Senft not Senf) regarding Arch Linux.

There are many myths about Arch Linux. And therefore also a lot of bullshit. For example, that you only learn something if you use Arch Linux. Yes, that is bullshit. I acquired a large part of my knowledge about Linux under Mandrake / Mandriva, for example. Which was the Ubuntu of that time, so to speak. Since I’ve been using Arch, a lot has been added, of course. But not because I use Arch, but because I had to solve certain problems or fulfil certain tasks. But anyway, that’s not the point.

The point is that many claim that Arch Linux is used by people who have no real life. For example, because you have to fix something after almost every update. Bullshit!

I have been using Arch Linux since about 2010 on several computers with different configurations. Both in terms of hardware and software. And for the life of me I can’t say when the last time there were problems because of an update. I even use Arch Linux for servers in the private sector.

I don’t install updates several times a day. On some computers I even install updates only once a week because I only use them on weekends.

Before an update, I check whether something has been published at https://archlinux.org/news/ that affects my installations. To automate this, I use Informant. If this is the case, I take it into account. Without ifs and buts.

And from time to time I synchronise my configuration files with the Pacnew files (https://wiki.archlinux.org/title/Pacman/Pacnew_and_Pacsave). I also regularly clear pacman’s cache automatically using a hook (https://wiki.archlinux.org/title/pacman#Cleaning_the_package_cache).

Otherwise I just use Arch Linux. Yes, seriously. Arch Linux is basically a normal distribution. Like OpenSuse, for example. It’s not an operating system for the elite. Or for people without a real life. It’s just a distribution where some things work differently than other distributions. Like the installation, for example.

This article is not meant to encourage as many users as possible to install Arch Linux. No. Everyone should use the distribution he / she / it thinks is right. This article is only meant to demystify Arch Linux and thus inform potential users. Personally, I couldn’t care less which distributions other users use. And I therefore have no problem with the article from gnulinux.ch.

OSBN | Linux

Automatically update the Pkgbuild file and install it

Under Arch I have installed a few packages whose updates are sometimes offered with a time delay. For example, because the respective package maintainer does not have the necessary time or because he wants to wait for the first minor release. Hugo is often such a package.

Therefore I often install the current version myself. For this I created the directory ~/pkgbuilds/hugo/ and stored the PKGBUILD file in this directory to install the package. In the case of Hugo, this currently looks like this.

pkgname=hugo
pkgver=0.101.0
pkgrel=1
pkgdesc="Fast and Flexible Static Site Generator in Go"
arch=('x86_64')
url="https://gohugo.io/"
license=('Apache')
depends=('glibc')
makedepends=('go' 'git')
optdepends=('python-pygments: syntax-highlight code snippets'
            'python-docutils: reStructuredText support')
source=(${pkgname}-${pkgver}.tar.gz::https://github.com/gohugoio/${pkgname}/archive/v${pkgver}.tar.gz)
sha512sums=('541d0e04e868845119f2b488fd53b92929ea4dc08685d438a2914b41586e204588b193522013e8eed908dc0c3fbc2714aefb1afad0beae875d57d71aadc59c70')

build() {
  cd "${srcdir}"/${pkgname}-${pkgver}
  export CGO_CPPFLAGS="${CPPFLAGS}"
  export CGO_CFLAGS="${CFLAGS}"
  export CGO_CXXFLAGS="${CXXFLAGS}"
  export CGO_LDFLAGS="${LDFLAGS}"
  export GOFLAGS="-buildmode=pie -trimpath -mod=readonly -modcacherw"
  go build -tags extended

  ./hugo gen man
  ./hugo completion bash > ${pkgname}.bash-completion
  ./hugo completion fish > ${pkgname}.fish
  ./hugo completion zsh > ${pkgname}.zsh
}

package() {
  cd "${srcdir}"/${pkgname}-${pkgver}
  install -Dm755 "${pkgname}" "${pkgdir}"/usr/bin/${pkgname}
  install -Dm644 LICENSE "${pkgdir}"/usr/share/licenses/${pkgname}/LICENSE

  install -Dm644 "${srcdir}"/${pkgname}-${pkgver}/man/*.1  -t "${pkgdir}"/usr/share/man/man1/
  
  install -Dm644 ${pkgname}.bash-completion "${pkgdir}"/usr/share/bash-completion/completions/${pkgname}
  install -Dm644 ${pkgname}.fish "${pkgdir}"/usr/share/fish/vendor_completions.d/${pkgname}.fish
  install -Dm644 ${pkgname}.zsh "${pkgdir}"/usr/share/zsh/site-functions/_${pkgname}
}

If a new version was published I enter the new version in the PKGBUILD file at the line pkgver=. Then I execute the commands updpkgsums PKGBUILD, makepkg -cirs PKGBUILD -noconfirm and rm – .tar. in the directory where the file is located.

The first command downloads the archive file containing the source code, creates the checksum of the file, and adds it to the PKGBUILD file. The second command uses the instructions in the PKGBUILD file to build and install the package. The last command deletes both the archive file with the source code and the created package.

Because I am already quite skilled at this, this doesn’t take a minute. However, I still want to automate the process. Therefore I have created a function for myself.

updpkgbuild () {
	new_ver="$1"
	sed -E "s#(pkgver=).*#\1$new_ver#" -i PKGBUILD
	updpkgsums PKGBUILD
	makepkg -cirs PKGBUILD --noconfirm
	rm -- *.tar.*
}

With this I only need to run for example updpkgbuild 0.102.0 in the directory of the PKGBUILD file and version 0.102.0 of the package will be installed automatically. Of course, the whole process only works if only the version as well as the checksum needs to be updated. But this is mostly the case.

I created this function for the zsh. Whether this also works in other shells like bash or fish, I can’t say.

OSBN | Linux