Re: manpages-l10n: Debian Buster durch Bullseye ersetzen?

[Mario Blättermann <mario.blaettermann@gmail.com>]

Hallo Helge,

Am So., 5. Jan. 2020 um 18:59 Uhr schrieb Helge Kreutzmann
<debian@helgefjell.de>:
>
> Moin,
> On Sun, Jan 05, 2020 at 06:25:28PM +0100, Mario Blättermann wrote:
> > Am So., 5. Jan. 2020 um 07:06 Uhr schrieb Helge Kreutzmann
> > <debian@helgefjell.de>:
> > >
> > > Hallo Mario,
> > > On Fri, Jan 03, 2020 at 10:43:40PM +0100, Mario Blättermann wrote:
> > > > im Projekt manpages-l10n wäre es wieder Zeit für eine
> > > > Upstream-Aktualisierung. Wir haben derzeit noch Debian Buster drin,
> > > > was aber wohl kaum noch wichtig ist. Wenn überhaupt, wäre eine
> > > > Auslieferung der manpages-*-Pakete nur über die Backports möglich.
> > > > Wäre es an der Zeit, Buster zu entfernen und auf Bullseye zu wechseln?
> > >
> > > Und genau das machen wir doch?
> > >
> > Nein, eben nicht. Wir haben immer noch die Handbuchseiten aus Buster
> > im Programm. Bekanntermaßen gibt es keine Möglichkeit, in eine bereits
> > veröffentlichte Debian-Version neue Paketversionen einzubringen. Das
> > geht nur über die Backports, die möglicherweise nicht allzu viele Fans
> > haben, so dass letztendlich kaum neue oder aktualisierte
> > Handbuchseiten beim Leser ankommen.
>
> Ich habe in den Veröffentlichungshinweisen eben jene Backports
> beworben [1] und mein Eindruck (keine Zahlen) ist, dass die Backports
> durchaus gut angenommen werden. Bei den bestehenden Handbuchseiten
> fliegen immer wieder Fehler raus, und neue kommen ja auch hinzu. Und
> es wäre kein Problem, Zeichenketten von Buster mit niedrigerer
> Priorität zu handhaben (wenn Du dran bist).
>
Beim Vervollständigen einer Übersetzung will ich nicht diejenigen
Strings aussortieren, bei denen nicht »Archlinux« drüber steht.
Schließlich sind wir ein multidistributionales Projekt.

> > > Ich würde gerne Sid + Stable, d.h. derzeit Sid + Buster behalten.
> > > Bullseye (Testing) bringt dagegen gar nichts, wohin soll das denn
> > > hochgeladen werden?
> > >
> > Keine Ahnung, das geht über meine Kenntnisse zu Debian hinaus. Vergiss
> > die Idee einfach, hinsichtlich Debian bin ich sowieso
> > leidenschaftslos.
>
> Ok.
>
> (Falls es Dich interessiert: Pakete sind erst in Sid, gehen dann nach
> Testing. Irgendwann wird Testing eingefroren und zu Buster umbenannt.
> Abgesehen von Spezialfällen (z.B. während des Einfrierens) läuft alles
> ausnahmslos über Sid)
>
OK, verstanden. Dann wäre die Ersetzung von Buster durch Bullseye erst
dann fällig, wenn Bullseye im Freeze ist, richtig?

> > > > Das würde ich nämlich gerne noch vor der Aktualisierung machen, um
> > > > Zeit zu sparen. Ich habe bei der vorletzten Prozedur Ende November mal
> > > > die Zeiten notiert, die für die einzelnen Schritte nötig sind (die
> > > > später hinzugekommenen polnischen Dateien sind noch nicht
> > > > berücksichtigt):
> > >
> > > …
> > >
> > > > Wenn man mal die Aktualisierungen der nicht-deutschen *.po-Dateien
> > > > außen vor lässt, die eigentlich Sache der jeweiligen Sprachteams sind,
> > > > dauert das Ganze auf meinem Rechner etwa eineinhalb Stunden. Daher ist
> > > > mir sehr daran gelegen, hier und da etwas einsparen zu können.
> > >
> > > Muss dass denn alles sequenziell laufen? Wäre es nicht eher sinnvoll,
> > > mittelfristig die Infrastruktur auf einen parallelen Lauf zu
> > > aktualisieren? Die Sprachen sollten doch auf jeden Fall parallel
> > > laufen könne, eigentlich auch die Distributionen, oder?
> > >
> > Die Aktualisierung der Upstream-Pakete läuft seriell, braucht aber bei
> > mir auch nur 15 Minuten. Das geht alles noch. Aber auch wenn es
> > parallel laufen würde, setzt der Rechner seine natürlichen
> > Leistungsgrenzen. Ganz allein vor sich hin rödeln lassen kann man
> > diese Prozedur auch nicht. Da ist immer mal was zwischendurch zu
> > korrigieren, zum Beispiel wenn sich aus einer Handbuchseite wegen
> > Syntaxfehlern keine Vorlage bauen lässt oder bei Umbenennungen oder
> > so.
>
> Wären die Fehler (eher) zu fangen, wenn Du in einem temporären Ort
> z.B. einmal täglich (Anacron mit Mittags) einen Bau der Handbuchseiten
> anstoßen und Dir das Ergebnis zumailen lässt? Wäre eine E-Mail
> täglich, und ggf. ein Fehler täglich raus. Ich gehe davon aus, dass
> die Aktualisierung der Upstream-Pakete das nicht bedarf.
>
> > Das größte Problem ist das Skript templates/update-all-templates.sh.
> > Das arbeitet nacheinander die Po-Dateien aller Sprachen ab, aber
> > dupliziert vieles. Der erste Befehl im Skript liefert derzeit folgende
> > Verzeichnisliste:
> >
> > de/man1
> > de/man2
> > de/man3
> > de/man4
> > de/man5
> > de/man6
> > de/man7
> > de/man8
> > fr/man1
> > fr/man2
> > fr/man3
> > fr/man4
> > fr/man5
> > fr/man6
> > fr/man7
> > fr/man8
> > nl/man1
> > nl/man2
> > nl/man3
> > nl/man4
> > nl/man5
> > nl/man6
> > nl/man7
> > nl/man8
> > pl/man1
> > pl/man2
> > pl/man3
> > pl/man4
> > pl/man5
> > pl/man6
> > pl/man7
> > pl/man8
> > ro/man1
> > ro/man5
> >
> > Die Liste wird dann sequenziell abgearbeitet. Nun ist es aber so, dass
> > sich beispielsweise eine Datei namens man1/chmod.1.po in allen
> > Sprachverzeichnissen befindet und daher fünfmal eine neue Vorlage
> > chmod.1.pot erstellt wird. Diese Verzeichnisliste ist bei mehreren
> > Sprachen einfach der falsche Ansatz. Das Skript müsste gleich eine
> > Dateiliste bauen, in der es keine Duplikate gibt. So könnte man die
> > derzeit für die Ausführung nötigen 44 Minuten auf vielleicht 25
> > Minuten schrumpfen lassen. Das wäre schon mal ein Fortschritt. Nur
> > leider würde ich das mit meinen bescheidenen Kenntnissen nicht
> > hinkriegen. Jedenfalls würde es wohl so lange dauern, bis es
> > funktioniert, dass der Zeitvorteil wieder dahin wäre.
>
> Ok, das ist in der Tat nicht gut. Aber schon die Parallelisierung der
> Sprachen (dann würden die POT-Dateien eben parallel erstellt) wäre ja
> ein erster Schritt, oder?
>
Ergibt keinen Sinn. Die Rechenleistung ist begrenzt, daher würde das
bei mir wohl kaum schneller gehen. Ich habe einen zehn Jahre alten
Laptop. Der ist noch leistungsfähig genug für ein aktuelles KDE, aber
wenn die Aktualisierungsskripte laufen, geht er in die Knie und wird
zum Heizgerät. Da bringen parallele Abläufe wohl nichts. Der
springende Punkt ist doch, dass die Skripte in ihrer derzeitigen Form
einen Flächenbrand im Git-Repo entfachen und zum Beispiel jede Menge
Pakete herunterladen, die nicht heruntergeladen werden müssten, dito
für die Erstellung der Vorlagen und Aktualisierung der po-Dateien. Da
müssen wir ran, wie auch immer.

> Aber ich gebe Dir recht, ich könnte es wahrscheinlich auch nicht
> (kaum) »mal eben« umbauen, aber vielleicht liest Tobias ja mit und
> findet einen Weg …
>
> > Einmal ziehe ich die Aktualisierung mit den derzeitigen Skripten noch
> > durch, aber dann reicht es mir auch. Eineinhalb Stunden sind einfach
> > zu viel. Zwanzig Minuten weniger sind aber auch noch kein Meilenstein,
> > deswegen brauchen wir auch für die Upstream-Pakete eine andere Lösung.
> > Derzeit werden die Verzeichnisse in usptream/*/man* komplett geleert
> > und *alles* neu heruntergeladen und entpackt. Wir müssten
> > Versionsnummern in upstream/*/packages.txt hinzufügen und das Skript
> > so ändern, dass nur noch Pakete heruntergeladen werden, deren
> > Versionsnummer auf dem Server neuer als die in der Paketliste ist.
> > Danach müssen auch nur die Vorlagen erstellt werden, für die es
> > tatsächlich neue Originalhandbuchseiten gibt. Insgesamt würde sich der
> > Zeitaufwand damit dauerhaft auf deutlich unter eine Stunde drücken
> > lassen, was bei einer oder zwei Aktualisierungen pro Monat durchaus
> > akzeptabel ist. Ich weiß, das Umstellen der Skripte ist viel Arbeit
> > und ich kriege das selbst nicht hin, aber ich möchte meine Freizeit
> > lieber in die Übersetzungen selbst investieren als in das Starten von
> > Skripten, die vieles doppelt, drei- oder fünffach abarbeiten.
> > Möglicherweise kommen ja auch noch mehr Sprachen und/oder
> > Distributionen hinzu, was wieder mehr Zeit bedeutet.
>
> Kann ich gut verstehen.
>
> Ist denn die Last bei der Arbeit mit den Skripten hoch? Ansonsten
> könnte könnten die i.d.R. unproblematischen Teile z.B. auch mittels
> anacron nach dem Booten, z.B. jeden Montag[2], durchgeführt werden. Dann
> würdest Du zumindest die ersten 20 Minuten gar nicht mitbekommen. Und
> wenn Du den anderen Anacron-Job von oben auch machst, könntest Du
> sogar den zweiten Teil riskieren, ggf. läuft es ja dann schon durch
> und Du hast es gar nicht mitbekommen.
>
Wo solle denn die Cronjobs laufen? Auf meinem Laptop, der mal abends
für ein oder zwei Stunden eingeschaltet wird? Außerdem habe ich in der
Regel nur am Wochenende unbegrenztes Netzwerkvolumen, ansonsten nur
Mobilfunknetz. Das hilft mir nicht weiter und ist nur weitere sinnlose
Ressourcenvergeudung.

> > Die Aktualisierungen seltener auszuführen ist auch keine Lösung, damit
> > schießen wir uns selbst ins Knie und werden den zweifelhaften Ruf
> > niemals los, dass übersetzte Handbuchseiten den Originalen zeitlich
> > weit hinterherhinken. Die bedingungslose Aktualität ist ja gerade das
>
> Ich sehe das nicht so dramatisch. Wir müssen nicht tagesaktuell sein.
> Natürlich ist für den Benutzer aktueller auch besser, aber ich fände
> es nicht dramatisch, wenn die Übersetzung nur ein paar Mal pro Jahr
> nachgezogen würde. Dann sind die Erklärungen der neusten Optionen ggf.
> noch nicht da (d.h. es müsste in die englische Seite geschaut werden),
> aber ich glaube, viele Benutzer sind schon über die 80% oder mehr, die
> durch die Seite abgedeckt werden, erfreut.[3]
>
Ich will definitiv so aktuell wie möglich sein. Es verärgert mich als
Leser nur, wenn ich für eine zum jeweiligen installierten Programm
passende Dokumentation in die englische Handbuchseite schauen muss,
obwohl es eine deutsche gibt. Klar, gegenüber manpages-hu, was 19
Jahre alte Klartextübersetzungen enthält, ist selbst manpages-it von
2016 brandaktuell. Aber so einfach relativiere ich das nicht. Wenn
schon die allermeisten Upstream-Entwickler keine Notwendigkeit sehen,
übersetzte Handbuchseiten direkt in ihre Projekte aufzunehmen, will
ich das wenigstens hier irgendwie abfedern, aber nicht mit einem
verklärten Blick auf die Aktualität.

> > Argument, mit dem ich bestehende Sprachteams anzulocken versuche. Was
> > soll ich denen denn sagen, wenn wir vielleicht nur noch vier Mal im
> > Jahr aktualisieren und zwei Mal einen neuen Tarball
> > veröffentlichen...? Außerdem würde ich so etwas den Benutzern auch
> > nicht zumuten wollen, gerade als Nutzer einer
> > Rolling-Release-Distribution, die auf Aktualität zwingend angewiesen
> > ist.
>
> Das kann ich nicht beurteilen, aber im Vergleich zu vorher
> (Übersetzungen teilweise Jahr(zehnte) alt - da ist unser Ansatz schon
> ein großer Fortschritt.
>
> Und Danke, dass Du Dich da so reinkniest.
>
Gern geschehen. Wäre nur schön, wenn seitens der französischen und
polnischen Übersetzer mal ein wenig Aktivität erkennbar wäre. Mal
sehen, was sich so bis Ende nächsten Jahres tut... Die Anfrage an die
Italiener ist zwar schon beantwortet, aber es ist noch nichts
entschieden. Wenn sie wirklich zu uns kommen wollen, landen ihre
po-Dateien sowieso erst einmal in einem separaten Git-Zweig und werden
erst in den Hauptzweig überführt, wenn alles importiert ist.

> Viele Grüße
>
>             Helge
>
> [1] Und Heise hat mich dazu sogar (fast) zitiert
> [2] Besser jeden zweiten Montag
> [3] Und Du plädierst ja eh' dafür, die Übersetzung in der Distribution
>     nochmals neu zu bauen, wodurch die neuen Zeichenketten zumindest
>     auf Englisch sukzessiv ihren Weg auch bei Distributionen wie
>     Archlinux finden würden.
>
Ja. ich will definitiv das frühere Verhalten zurück, wo beim Bau des
Pakets oder der lokalen Installation die Handbuchseiten des
Zielsystems als Basis dienten. So sind trotz der unweigerlich
entstehenden englischen Bestandteile die Handbuchseiten immer
tagesaktuell, bezogen auf den Tag, an dem das Paket gebaut wurde. Als
Nebeneffekt müssten wir keine neuen Distributionen integrieren,
zumindest nicht alle, für die es derzeit manpages-fr oder manpages-pl
als Pakete gibt, was die zukünftigen Downstream-Betreuer von
manpages-l10n wegen der Aktualisierungspfade aber durchaus einfordern
könnten. Stattdessen könnten wir auf den Umstand verweisen, dass
sowieso von den Dateien des Zielsystems ausgegangen wird.

Gruß Mario