Fryboyter

Artikel gemeinsam aktualisieren

Bei Arch Linux ist Python 3 schon lange der Standard. Allerdings haben diverse Pakete in den offiziellen Paketquellen immer noch Python 2 verwendet. Kürzlich haben die Entwickler von Arch Linux nun Python 2 endgültig beerdigt. Dies habe ich zum Anlass genommen die bisher von mir veröffentlichten Artikel anzusehen.

Gefunden habe ich einen Artikel für ein Script von 2016. Den Artikel konnte ich dank des Tools 2to3 sehr leicht auf Python 3 aktualisieren.

Ich gehe allerdings davon aus, dass auch noch andere von meiner Artikel, die ich seit 2009 veröffentlicht habe, nicht mehr korrekt sind, da sich zwischenzeitlich einiges geändert hat. Selbst wenn ich nun alle Artikel selbst überprüfe, wäre ich mir nicht sicher, ob ich über jede nötige Änderung Bescheid wüsste.

Nun ist es so, dass es mich selbst nervt, wenn ich über die von mir bevorzugte Suchmaschine Artikel zur Lösung eines Problems finde, die veraltet sind. Was leider oft der Fall ist.

Daher habe ich mir überlegt, ob wir Betreiber diverse Blogs uns nicht gegenseitig unterstützen könnten, indem wir beispielsweise ab und zu eine “Bug Squashing Week” ins Leben rufen während dieser wir vorhandene Artikel anderer Blogs prüfen und bei Bedarf dem Betreiber entsprechend informieren oder, sofern möglich, Pull Requests erstellen.

Was ich damit erhoffe, zu erreichen ist, dass die Suchergebnisse bei den diversen Suchmaschinen möglichst aktuell sind. Denn leider ist es so, dass einmal veröffentlichte Artikel oft nie mehr aktualisiert werden. Wie man bei den genannten Artikel von 2016 sieht, bin ich leider keine Ausnahme.

OSBN

PKGBUILD-Datei bequem herunterladen um damit ein Paket zu erstellen

Ab und zu benötige ich eine PKGBUILD-Datei, um damit ein Paket für Arch Linux zu erstellen, um dieses beispielsweise auf mehreren Computern im LAN zu installieren.

Nehmen wir https://aur.archlinux.org/packages/ttf-iosevka-term als beliebiges Beispiel. Man kann beispielsweise unter genannten Link auf “View PKGBUILD” klicken und dann den angezeigten Inhalt in einer PKGBUILD-Datei lokal speichern. Alternativ kann man auch git clone –depth 1 https://aur.archlinux.org/ttf-iosevka-term.git ausführen. Dieser speichert die gewünschte Datei automatisch aber man muss den genauen Link kennen. Ich finde beide Lösungen nicht besonders gut.

Heute bin ich auf das Tool pbget gestoßen. Mit diesem muss man nur den Namen des zu erstellenden Pakets kennen. Somit reicht der Befehl pbget –aur ttf-iosevka-term aus um die gewünschte PKGBUILD-Datei herunterzuladen. Die Angabe von –aur ist in dem Fall nötig, da ttf-iosevka-term nur im AUR vorhanden ist und pbget von Haus aus nur die offiziellen Paketquellen durchsucht.

Der Befehl sollte das Verzeichnis ttf-iosevka-term anlegen und in diesem die PKBUILD-Datei speichern. Wechselt man in dieses Verzeichnis und führt makepkg -crs PKGBUILD –noconfirm aus wird das Paket erzeugt. Oder man führt makepkg -cirs PKGBUILD –noconfirm aus, um das Paket auch gleich zu installieren.

Pbget findet man übrigens im AUR.

OSBN | Arch

Nachrichtenportale stellen sukzessive ihre RSS-Angebote ein. Aber...

Viktor Garske hat kürzlich über https://blog.v-gar.de den Artikel Neuer Podcast über IT-Sicherheit: Risikozone veröffentlicht in dem er die Aussage getroffen hat, dass immer mehr Nachrichtenportale die RSS-Feeds eingestellt haben.

Der Aussage will ich nicht unbedingt widersprechen. Viele Internetseiten nutzen aber beispielsweise WordPress. Und viele dieser Seiten bieten zwar offiziell keinen RSS-Feed an, vergessen allerdings diesen zu deaktivieren. Somit kann man, wenn man die Adressen kennt, trotzdem die Feeds abrufen. Im Falle von WordPress kann man sich an https://wordpress.org/support/article/wordpress-feeds/ orientieren um die Adresse des Feeds herauszufinden.

Somit kann man in vielen Fällen trotzdem RSS-Feeds abrufen, auch wenn die betreffende Seite offiziell keine Feeds anbietet.

Https://fryboyter.de bietet beispielsweise über https://fryboyter.de/categories/osbn/index.xml einen Feed für die Artikel an, die auf https://osbn.de und https://planet.ubuntuusers.de veröffentlicht werden. Über https://fryboyter.de/index.xml erreicht man den Feed für alle Artikel die ich auf fryboyter.de veröffentliche.

Vielleicht wäre es daher keine schlechte Idee, Feed-Adressen von Internetseiten zu sammeln, die offizielle gar keinen RSS-Feed anbieten.

OSBN | Allgemein

Mercurial - Mehrere Commits zu einem Commit zusammenfügen

Nehmen wir an, dass man in einem lokalen Mercurial-Repository mehrere kleine Commits erstellt hat. Nun will man nicht jeden dieser Commits pushen, sondern aus mehreren kleinen Commits vorher einen größeren Commit erstellen.

Gehen wir von folgendem fiktiven Beispiel aus.

hg log -v -l 2
Änderung:        408:f5a5d6c7d965
Lesezeichen:     main
Marke:           tip
Nutzer:          Fryboyter <hg@fryboyter.de>
Datum:           Sun Jul 31 15:47:53 2022 +0200
Dateien:         README.md
Zusammenfassung: Fügt einen Text hinzu

Änderung:        407:6d5f6ac48ddb
Nutzer:          Fryboyter <hg@fryboyter.de>
Datum:           Sun Jul 31 15:47:31 2022 +0200
Dateien:         README.md
Zusammenfassung: Fügt eine Überschrift hinzu

Wie man sieht, beziehen sich die letzten beiden Commits auf einfache Änderungen in der gleichen Datei für die ein Commit gereicht hätte. Also machen wir doch einfach aus den zwei Commits einen einzelnen Commit.

Hierfür habe ich mich für histedit entschieden. Hierbei handelt es sich nicht um ein externes Plugin wie hg-git, sondern um eine Funktion die Mercurial von Haus aus bietet. Diese muss man allerdings erst aktivieren. Hierfür reicht es aus in der Konfigurationsdatei hgrc unter [extensions] histedit = einzutragen. Also beispielsweise wie folgt.

[extensions]
hggit = ~/repository/hg-git/hggit
histedit =

Will man nun beispielsweise die beiden letzten Commits zusammenfuegen, führt man den Befehl hg histedit -r -2. Nun sollte man eine Anzeige, ähnlich der folgenden erhalten.

?: help, k/up: move up, j/down: move down, space: select, v: view patch   
d: drop, e: edit, f: fold, m: mess, p: pick, r: roll
pgup/K: move patch up, pgdn/J: move patch down, c: commit, q: abort
Older commits are shown above newer commits.
  #0  pick   407:6d5f6ac48ddb   407 Fügt eine Überschrift hinzu
  #1  pick   408:f5a5d6c7d965   408 Fügt einen Text hinzu

changeset: 408:f5a5d6c7d965
user:      Fryboyter <hg@fryboyter.de>
bookmark:  main
summary:   Fügt einen Text hinzu
files:     README.md
no overlap

Wir möchten nun, dass Commit #1 Teil von Commit #0 wird, sodass wir diesen pushen können. Hierfür wählen wir den Commit #1 aus und drücken auf der Tastatur f. In der betreffenden Zeile sollte anstelle von pick nun ^fold angezeigt werden. Abschließend drücken wir auf der Tastatur noch c. Nun ändert man die Commit-Nachricht ab und speichert sie.

Führt man nun hg log -v -r 2 aus, sollte der Commit #1 nicht mehr angezeigt werden und beim Commit #0 sollte die neue Commit-Nachricht angezeigt werden. Führt man hg diff -c tip aus, sollte der Commit auch beide Änderungen enthalten. Bei “tip” handelt es sich übrigens um den letzten vorhandenen Commit.

OSBN

Bestimmte Version von Composer bei Uberspace installieren

Als ich eben eine Wallabag-Installation bei Uberspace.de aktualisieren wollte, habe ich folgende Fehlermeldung erhalten.

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.

Die Empfehlung composer update auszuführen, hilft in diesem Fall nicht. Denn das Problem ist, dass bei Uberspace Version 2.3.10 von Composer installiert ist. Wallabag setzt aktuell aber Composer in einer Version < 2.3 voraus. Bisher hatte ich bei Uberspace eigentlich nur Fälle bei denen bestimmte Pakete zu stable (man könne auch sagen zu alt) waren. Öfter mal was Neues.

Also ist, zumindest vorübergehend, ein Workaround nötig. Auf dem betreffenden Uberspace hab ich folgende Befehle ausgeführt.

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

Der erste Befehl läd den Installer von Composer herunter. Mit dem zweiten wird die Version 2.2.17 von Composer heruntergeladen und im Verzeichnis ~/bin mit dem Dateinamen composer gespeichert.

Anschließend konnte ich Wallabag ohne Probleme aktualiseren. Da ~/bin Teil von $PATH ist und Composer nicht für die Nutzung von Wallabag nötig ist, habe ich die Datei abschließend in composer.old umbenannt um eventuelle Probleme mit anderer, installierter Software vorzubeugen die eine neuere Version benötigt.

OSBN | Linux