Hallo Helge, Am So., 5. Jan. 2020 um 18:59 Uhr schrieb Helge Kreutzmann <deb...@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 > > <deb...@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
