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 handaben (wenn Du dran bist).
> > 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)
> > > 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?
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.
> 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]
> 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.
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.
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: PGP signature