Hacktoberfest 2022 und meine vier Paketupdates für Void Linux
Monday, 10. October 2022
Das Hacktoberfest belohnt Beiträge zu FOSS-Projekten, Ausrichter ist der US-Hoster Digitalocean. Void Linux macht dabei mit und ich empfand deren Beschreibung als sehr einladend: Die Ziele sinnvoll, klarer Einstiegspunkt und alle wichtigen Informationen wurden verlinkt. Wie war es dann, vier verwaiste Pakete für alle Void-Nutzer zu aktualisieren?
Das Prinzip
Das Hacktoberfest funktioniert so: Man meldet sich auf der Webseite an und gibt Leserechte auf den Github/Gitlab-Account. Projekte müssen über ihre Projektbeschreibung ihre Teilnahme signalisieren. Kommen dann im Projektzeitraum vier Pull-Requests an, bekommt der Teilnehmer ein T-Shirt oder es wird in seinem Namen ein Baum gepflanzt (beschränkt auf die 40.000 schnellsten erfolgreichen Teilnehmer). Der Fortschritt wird auf der Webseite in einer Übersicht angezeigt.
Void Linux hat auf seiner Webseite eine News veröffentlicht und da klar beschrieben, was sie brauchen:
- Updates für verwaiste Pakete, und zwar lieber als Rezepte für neue Pakete
- Upstream-Patches für Pakete, die nicht auf allen unterstützten Plattformen kompilieren
- Fixes für ihre eigene Infrastruktur
- Erweiterung der Dokumentation
Sie wollen also die Aktion nutzen um die anfallende Arbeit zu erleichtern, das fand ich super. Updates für verwaiste Pakete einzubringen sei zudem recht simpel.
Darüber kann man streiten, aber die Dokumentation dazu half auf jeden Fall. Zuerst gibt es eine Updateliste, die dort gelisteten Updates für Pakete von orphan@voidlinux.org sind die Ziele. Dann gibt es die Dokumentation, die etwas verteilt alles weitere erklärt: Das Readme des Paketrepos, die Anleitung und besonders hilfreich die Contributing-Hinweise.
Das Grundprinzip erklärt am besten die Readme: Klone das Git-Repo, führe darin ./xbps-src binary-bootstrap aus um Voids Paketinfrastruktur zu bauen. Aber wer Änderungen einbringen will liest sich besser durch Contributing, das erklärt neben dem Git-Drumherum das Vorgehen für Paketupdates: Editiere die Rezeptdatei ./srcpkgs/Paketname/template des Pakets (was oft einfach nur eine Anhebung der Versionsnummer sein wird), aktualisiere die Prüfsumme mit xgensum -i Paketname, baue das Paket mit ./xbps-src pkg <package_name>, dann installiere es mit xbps-install --repository hostdir/binpkgs <package_name>. Testen und einen PR mit einem einzelnem Commit an void senden. Das mit dem einen Commit wird oft bedeuten mit git rebase Commits zusammenzufügen, vor allem wenn nachträgliche Änderungen gefordert werden (was bei mir passierte).
Bei ihrem Github sind automatisierte Tests eingerichtet, die einen Syntaxcheck über die Rezeptdatei laufen lassen und zudem schauen, ob das Paket wirklich gebaut werden kann. Die sollten durchlaufen, ansonsten am besten direkt reagieren und den Fehler korrigieren.
Das musste ich teils auch bei meinen folgenden Paketupdates machen.
Update 1: memcached 1.6.10 -> 1.6.17
Memchached ist nicht Memcache, trotzdem fiel mit der Name wegen seiner Webentwicklerrelevanz auf. Das Update war nicht ganz so einfach: Erst wollte das Paket nicht bauen, dann wusste ich nicht wie ich es testen könnte.
Ich setzte also die Versionsnummer auf 1.6.17 und der Paketbau warf einen Fehler:
configure.ac:65: error: possibly undefined macro: AS_IF
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
Zum Glück war dafür ein Fehlerbericht bereits im memchached-Github, pkg-config würde gebraucht. Das zum Template hinzugefügt und der Bau lief durch. Hier als Beispiel ein Sreenshot der Änderungsübersicht, damit deutlich wird um wie wenige Codezeilen es letzten Endes geht:
Aber wie testet man memcached ohne herumliegenden Programmcode? Mit echo und nc ist die Antwort, wobei ich bei mir echo -e schreiben musste.
Daraufhin ging der PR durch.
Update 2: ruby-mime-types 3.3 -> 3.4.1
Eigentlich wollte ich ruby-httparty aktualisieren, aber das stolperte über diese Abhängigkeit. Das Gem mime-types war zu alt, um mit einer aktuellen Ruby-Version zu funktionieren. Ich musste da an mein altes Projekt music-streamer denken, das die MIME-Daten ausgelesen hat, wobei ich damals ruby-filemagic benutzte.
Hier war nur die Frage wie das Gem getestet werden kann, denn der Bau der neuen Version lief direkt durch. Die Antwort war irb, der Testcode entstammt der Projektreadme:
require 'mime/types' MIME::Types['text/plain']
Im PR kam dann nur der Vorschlag, die Changelog-Datei zu verlinken.
Update 3: ruby-mime-types-data 3.2019.1009 -> 3.2022.0105
Ich fand es naheliegend, ruby-mime-types-data direkt mitzuaktualisieren. So ein Datenpaket sollte keine Abhängigkeiten haben und ist daher einfach, aber es vermeidet im Zweifel Bugs in anderen Paketen wenn die Datenbank aktuell ist. Der Test war genau wie bei ruby-mime-types (das dieses Paket als Datenquelle lädt), nur dass beide neue Versionen installiert waren.
Im PR lief ich nur in ein Miniproblem mit einem Leerzeichen nach der Versionsnummer, was xlint nicht mochte. Das konnte ich mit commit -v --amend und einem folgendem git push --force reparieren, ohne rebase, wobei ich beim ersten mal vergessen hatte meine Änderung vorher auch mit git add sichtbar zu machen.
Update 4: minitube 3.9.1 -> 3.9.3
Ich hatte mir vor einer Weile mal einige Linux-Youtubeclients angeschaut, da fiel mir minitube direkt auf. Dem Versionsummersprung entsprechend war es ein kleines Update und lief problemlos durch, ich testete hier auch wieder die ARM-Crosskompilierung, was bei Void mit ./xbps-src -a armv6l pkg minitube einfach anzuleiern ist.
Funktionstest bei so einem Anwenderprogramm war dann viel einfacher als bei memcached, ich startete das Programm und schaute ob Videos abgespielt werden konnten.
Das wurde dann dieser PR.
Ein paar Gedanken zum Schluss: Das Hacktoberfest gefiel mir gut. Die früheren Probleme scheinen ausgeräumt. Natürlich wäre es noch cooler jemanden neu zur FOSS-Welt zur Teilnahme zu bringen, aber auch ich empfand den vom Void-Projekt bereitgestellten klaren Einstiegspunkt hilfreich. Manchmal ist ein klares "Wir wollen wirklich Hilfe, und zwar genau diese" sehr überzeugend.
Aber ohne mich zu sehr beweihräuchern zu wollen: Mir hat das auch nochmal vor Augen geführt, wie groß die Hürde eigentlich ist. Git mit seinen Konzepten ist schon nicht simpel, wenn dann noch rebase und Force-Push dazukommen wird es nicht einfacher. Ich erinnere mich zum Beispiel, dass mir sehr lange schlicht nicht klar war wie man PRs überhaupt aktualisieren kann, als ich git schon längst für meine eigene Versionsverwaltung nutzte. Jetzt scheint es simpel, damals fehlte mir einfach das mentale Modell dafür. Davon abgesehen, das Prüfen durch andere Entwickler machte mich anfangs nervös, alternativ genervt, wenn PRs ignoriert wurden (letzteres gilt immer noch, trifft mittlerweile aber weniger hart und bei Serendipity habe ich Vermeidungsstrategien entwickelt). Und das ist eine Hürde, die fast jede Code-Beisteuerung nehmen muss. Selbst man nicht direkt Linux-Paketmaintainer spielen will. Projekte tun gut daran möglichst viel davon zu dokumentieren, selbst wenn es redundant wirkt, einen ganzen Monat für diese Aktion zu geben ist ebenfalls angemessen.
Wie schwer bei Void das Aktualisieren von Paketen dann wirklich war hing natürlich stark vom Paket und vom jeweiligen Updatefehler ab. Ich wäre zum Beispiel ohne den existierenden Fehlerbericht über die nichtssagende Fehlermeldung bei memcached nie auf pkg-config als fehlende Abhängigkeit gekommen, und das obwohl ich pkg-config schon selbst bei simdock eingesetzt habe. Wer kein Ruby-Entwickler ist könnte das Testen vom Ruby-Gems schwierig finden. Überhaupt, dass man beim Kompilieren Fehlermeldungen wirklich lesen und interpretieren kann hat mir vor vielen Jahren Unki auf UbuntuUsers.de erst erklären müssen. Es baut alles aufeinander auf…
Der Blickwinkel macht für mich dann das Hacktoberfest nochmal wertvoller – wenn es bei einigen der Teilnehmern ein paar der benötigten Grundlagen schafft, ist das einfach eine gute Sache. Man kann es auf zwei Ebenen zwar auch kritisieren: Der Gamification-Ansatz ist manipulierend, via den T-shirts extrinsische Motivation einzuführen könnte intrinsische zerstören. Aber ich glaube, der Anreiz an Projekte die Unterstützbarkeit klar zu beschreiben wiegt das auf, und ein kleiner Motivationsanschub durch eine Aktion im Jahr dürfte auch langfristig wenig schädlich sein.
