Probleme beim Deployen zu Maven Central

Im Rahmen einiger Wartungsarbeiten wollte ich eine neue Version einer Java-Bibliothek zu Maven Central deployen. Stattdessen wurde ich von der Meldung:

Execution injected-nexus-deploy of goal org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7:deploy failed: An API incompatibility was encountered while executing org.sonatype.plugins:nexus-staging-maven-plugin:1.6.7:deploy: java.lang.ExceptionInInitializerError: null

überrascht. Am dahinterliegenden Problem wird bereits gearbeitet. Um das Deployment trotzdem durchführen zu können, eignet sich folgender Workaround:

export MAVEN_OPTS="--add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.desktop/java.awt.font=ALL-UNNAMED"
mvn clean deploy

Anschließend wird das entsprechende Deployment durchgeführt, was je nach Auslastung einige Minuten dauern kann.

Ulysses und Probleme mit der Synchronisation unter iOS

Das Schreibprogramm Ulysses erschien vor einigen Wochen in der Version 18. Neben der macOS-Version erschien zeitgleich die entsprechende iOS-Version. Die beiden Versionen können über iCloud oder per Dropbox synchronisiert werden.

‎Ulysses | Schreibprogramm
Preis: Kostenlos+
‎Ulysses · Schreibprogramm
Preis: Kostenlos+

Bei der Dropbox-Variante wurden bis zur Version 18 ausschließlich Markdown-Dateien synchronisiert, welche allerdings nicht alle Features von Ulysses abdecken. Mit der neuen Version können nun auch die internen von Ulysses genutzten Dateien zur Synchronisierung genutzt werden.

Im ersten Schritt müssen die Einstellungen für den Ordner geöffnet werden

Allerdings werden, nachdem der Ordner aus der Dropbox unter iOS hinzugefügt wurde, nur die Ordner und nicht die Texte synchronisiert. Verantwortlich hierfür ist ein Bug, welcher in einer der nächsten Versionen behoben werden soll. Zum Glück kann sich mit einem Workaround beholfen werden.

Anschließend kann auf das interne Format umgestellt werden

Dazu müssen die Einstellungen des Dropbox-Ordners unter iOS geöffnet werden. Anschließend sollte dort das Feld Markdowndateien lesen und schreiben deaktiviert werden. Danach beginnt die Synchronisierung der internen Ulysses-Dateien. Der Fortschritt lässt sich am besten über das Statistikfenster beobachten. Manchmal scheint die Synchronisation erst zu starten, wenn ein Ordner geöffnet wurde, in welchem das Cloud-Symbol angezeigt wird.

Was leider auch mit der neuen Ulysses-Version immer noch nicht funktioniert, ist die Einbindung über WebDAV, sodass der Nutzer im Moment immer noch gezwungen ist fremde Cloud-Dienste zu nutzen. Eine Anbindung an eine eigene Nextcloud-Instanz (über WebDAV) ist somit immer noch Zukunftsmusik und wird vom Ulysses-Team gefühlt sehr stiefmütterlich behandelt. Stattdessen wird der Nutzer immer wieder auf unbestimmte Zeit vertröstet. Bei einer Software die vom Nutzer abonniert werden muss und somit dauerhaft zur Finanzierung der Firma beiträgt, darf der Nutzer erwarten, dass solche Anwendungsszenarien Beachtung finden.

Kalenderdateien mit webcal-Schema herunterladen

Manche Dienste und Webseiten bieten Kalenderdateien über das inoffizielle URL-Schema webcal:// an. Wird nun versucht eine solche URL herunterzuladen:

wget webcal://example.org

erhält der Nutzer in den meisten Fällen die Meldung:

Nicht unterstütztes Schema »webcal«

Abhilfe schafft es in diesem Fall das Schema webcal durch http bzw. https zu ersetzen. Anschließend kann die Datei mit den Kalendereinträgen problemlos heruntergeladen werden.

Probleme mit dem cryptsetup-Workarround

Vor einigen Monaten veröffentlichte ich eine Anleitung zur Verschlüsselung eines Ubuntu-Servers. Da es einen Bug im cryptsetup gab, wurde in dem Artikel ein Workarround beschrieben. Mittlerweile wurde das cryptsetup-Paket aktualisiert und der entsprechende Bug gefixt. Allerdings führt dies zu Problemen mit dem Workarround. Möchte man den Server nun entsperren, erhält man folgende Meldung:

$ cryptroot-unlock
/bin/cryptroot-unlock: line 192: 2: parameter not set
/bin/cryptroot-unlock: line 192: 2: parameter not set
/bin/cryptroot-unlock: line 192: 2: parameter not set

Gelöst werden kann dieses Problem in dem folgendes Kommando genutzt wird:

sed 's/print $1, $5/print $1, $3/' /bin/cryptroot-unlock > /tmp/cryptroot-unlock; ash /tmp/cryptroot-unlock

Damit lässt sich der Server entsperren. Im zweiten Schritt kann nun der Workarround entfernt werden und das initramfs aktualisiert werden:

rm /etc/initramfs-tools/hooks/cryptsetup-fix.sh 
update-initramfs -u

Nach einem Neustart des Systems, kann dieses nun wie folgt entsperrt werden:

BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3) built-in shell (ash)
Enter 'help' for a list of built-in commands.

# cryptroot-unlock 
Please unlock disk cryptroot (/dev/md1): 
cryptsetup: cryptroot set up successfully
# exit

Anschließend wird das System hochgefahren und der Server steht zur Verfügung.

Workaround für Episoden Seiten im Podlove Publisher

Im Podlove Publisher gibt es in den Experteneinstellungen die Möglichkeit Episoden Seiten zu aktivieren. Gemeint ist damit nicht anders als alle Podcastbeiträge auf einer zusätzlichen Seite anzeigen zu lassen. Seit der Version 2.7.0 des Podlove Publisher funktionierte dieses Feature bei mir nicht mehr.

Die Episoden Seite für alle veröffentlichenden Podcasts

Hintergrund war der Commit b4d9f14; hier gab es unter anderem eine Änderung in der Datei permalinks.php. Wenn nun die URL für die Episoden Seiten eingestellt wurde funktionierte diese nicht mehr. Stattdessen gab es nur die Meldung das die Seite nicht existiert. Als Workaround habe ich die permalinks.php-Datei wieder um folgenden Quellcode aus dem Commit erweitert:

// Add archive pages
if ( 'on' == \Podlove\get_setting( 'website', 'episode_archive' ) ) {
	$archive_slug = trim( \Podlove\get_setting( 'website', 'episode_archive_slug' ), '/' );

	$blog_prefix = \Podlove\get_blog_prefix();
	$blog_prefix = $blog_prefix ? trim( $blog_prefix, '/' ) . '/' : '';

	$wp_rewrite->add_rule( "{$blog_prefix}{$archive_slug}/?$", "index.php?post_type=podcast", 'top' );
	$wp_rewrite->add_rule( "{$blog_prefix}{$archive_slug}/{$wp_rewrite->pagination_base}/([0-9]{1,})/?$", 'index.php?post_type=podcast&paged=$matches[1]', 'top' );
}

Der Quellcode muss an das Ende der Funktion podlove_add_podcast_rewrite_rules angetragen werden. Damit funktioniert das Episoden Seiten-Feature bei mir wieder ohne Probleme. Natürlich muss dieses Prozess bei jedem Update des Podlove Publisher wiederholt werden.