2025-11-05

So. Das mit der Strategie für dieses Jahr hat ja so gar nicht geklappt.

Ich pirsche mich langsam wieder ans Schreiben heran. Wäre doch nur dieses echte Leben dabei nicht immer wieder ein Hindernis. Aber nun denn … was soll ich mich beklagen, damit bin ich ja nicht allein.

Damit ich hier in gewohnter Weise veröffentlichen kann, musste ich erst mal meine liebevoll über die Jahre aufgebaute Infrastruktur erneuern, da ich mir einen neuen Rechner zulegen musste. Der wiederum hatte einen anderen Prozessor-Typ.

Sieben Jahre waren um, und kurz bevor ich ohnehin mit der Beschaffung loslegen wollte, hat mich Flexgate heimgesucht. Das hat den Vorgang beschleunigt.

Wo war ich? Ach ja, die Infrastruktur. Wie ich an anderer Stelle schrieb, erzeuge ich mit Hugo die Webseiten.

Hugo hatte ich noch wie viele andere installierte Programme in der Intel-Variante. Also habe ich das Programm aktualisiert (Baustein 1). Dafür muss ich Homebrew aktualisieren (Komponente 2).

Dankenswerterweise gibt es von Homebrew Skripte zum Entfernen und Neuinstallieren. Nach der Neuinstallation hat mir “brew doctor” gesagt, dass ich die XCode CLT aktualisieren sollte (Komponente 3, ich vermute für »git«). Also habe ich das getan.

Dann hat mir “brew doctor” nur noch gesagt, dass in “/usr/local/include/node” Dateien liegen, die nicht von Homebrew stammen, ich möge sie eventuell löschen. Habe ich getan. Brew ist nun zufrieden.

Wenn ich nun “hugo version” aufrufe, sagt mir die Shell, dass Docker fehlt. Stimmt, ich hatte das ja mal dockerisiert. Also installiere ich nun Docker Desktop (Komponente 4).

Nach dem ersten Aufruf möchte Docker anscheinend Rosetta installieren … Ich dachte eigentlich, ich bräuchte das nicht … Aber nun gut, auch das. Jetzt bekomme ich allerdings die Meldung, dass der CPU-Typ des Images nicht passt. Da müsste ich wohl das Hugo-Image aktualisieren …

Gucken wir mal. “hugo update” zieht das neue Image … aber für die falsche Plattform.

“docker pull –platform linux/arm64 klakegg/hugo:ext-alpine” soll es sein. “.bash_profile” anpassen, damit “hugo update” dann das richtige Image zieht.

Das ist nun alles etwas kniffliger. Alle Images löschen, die können eh weg. Die meisten waren von Projekten, an denen ich nicht mehr arbeite, für Firmen, die es teilweise nicht mehr gibt.

“hugo update” zieht noch das AMD-Image. Komisch. Woran liegt das nun wieder? Lösung: Es gibt kein ARM-Image. Also gehe ich auf eine neuere Hugo-Version und hoffe, dass noch alles klappt …

»Hugo version« zeigt mir schon einmal die neue aktuelle Version an. Jetzt tief Luft holen und gucken, ob ich meine Webseite noch bauen kann …

Kann ich nicht.

Hugo prüft jetzt augenscheinlich die Metadaten der Artikel und zeigt mir Unstimmigkeiten an. Na, dann ziehe ich das mal glatt.

Also flugs den Emacs gestartet … Ach, der ist ja auch zwei Jahre alt. Also auch hier: Aktuelle Version installieren (Komponente 5).

Bin fast da.

Emacs 30.2 startet immerhin, liefert aber natürlich Fehler. In einer .elc-Datei; dann kompiliere ich mal alles neu. Daumen drücken.

Auch nicht.

Es liegt an einem Fehler im solarized-theme, der ab Emacs 29 auftritt und auf GitHub schon behoben sein soll. Meine aktuelle Version von ELPA hat den Fehler wohl auch noch. Installiere ich dann mal von Github und lade es lokal …

Und schon funktioniert es.

Jetzt muss ich nur noch herausfinden, wie ich mir das Schreiben im Emacs gedacht hatte …

Ich habe im Org-Mode geschrieben und per ox-md exportiert. Die Datei hieß “blog.org”.

Die problematische Datei ist “aufbruch-2023.md”, den Abschnitt in “blog.org” habe ich leicht gefunden. Allein: Es gibt dort nur einen “date”-Eintrag (“date: 2023-04-05”), woher kommt der zweite? Wird der automatisch beim Export erzeugt?

Das ist interessant. Ich habe den Emacs so eingestellt, dass er die passende Markdown-Datei zum aktuellen Abschnitt erzeugt, wenn ich die Org-Datei speichere. Der überzählige Zeitstempel “2023-04-05T20:41:00+02:00” taucht aber nirgendwo auf. Woher kommt er?

Gefunden! Das ist der Zeitstempel von CLOSED … das heißt, wenn ich den Artikel veröffentlicht habe, dann wird der automatisch gesetzt … den müsste ich in mehreren Dateien haben … korrigiert.

So. Nun laufen die Artikel durch … allerdings werden jetzt diverse “lastmod”-Einträge angemahnt: Sie seien nicht parsbar. Stimmt. Da wird ein Datum als Zeichenkette angegeben und keine führende Null verwendet. “2025-03-11” steht da dann als “‘2022-3-11’”. Das bricht natürlich. Sieht so aus, als ob das die aus Wordpress exportierten Artikel betrifft. Sind 12 Stück. Das geht ja noch …

Interessanterweise betrifft das nur “lastmod”. Bei “date” ist die führende Null immer da …

Krass, was ich da alles finde! “buchrezension-die-drei-und-das-gespensterschloss.md” ist ein Relikt, eine Artikelhülle. Die Rezension gibt es, liegt aber im Emacs. Putzig.

So. “make test” läuft durch. Dann wage ich mal einen Blick …

Hui, und schon läuft es :)

Ich beschenke mich nach stichprobenartiger Kontrolle der erzeugten HTML-Dateien mit einem beherzten “make deploy”.

Sieht gut aus.

Ich kann jetzt schreiben und veröffentlichen :)