Hallo Mario, On Fri, Jan 04, 2019 at 03:25:34PM +0100, Mario Blättermann wrote: > Am Fr., 4. Jan. 2019 um 15:16 Uhr schrieb Helge Kreutzmann > <debian@helgefjell.de>: > > > > Hallo Mario, > > On Fri, Jan 04, 2019 at 02:17:08PM +0100, Mario Blättermann wrote: > > > Am Fr., 4. Jan. 2019 um 07:04 Uhr schrieb Helge Kreutzmann > > > <debian@helgefjell.de>: > > > > > > > > On Thu, Dec 27, 2018 at 01:17:17PM +0100, Mario Blättermann wrote: > > > > > Am Do., 27. Dez. 2018 um 06:40 Uhr schrieb Helge Kreutzmann > > > > > <debian@helgefjell.de>: > > > In diesem Zusammenhang noch eine Frage: Ergibt es noch Sinn, eine neue > > > Übersetzung im Git-Repo auch in secondary-debian-stretch einzufügen? > > > Wie ich sehe, gibt es für Stretch nur das alte Paket der Version 1.22, > > > und wenn ich mich recht erinnere, gestatten die Regeln sowieso nicht, > > > Paketversionen innerhalb einer bereits veröffentlichten Dsitribution > > > zu aktualisieren. Ich denke dabei noch an Etch zurück, das mit > > > xfce-4.3.99 (einem Release Candidate) veröffentlicht wurde und dieses > > > nicht auf die stabile Upstream-Version 4.4 aktualisiert werden durfte. > > > So müssten bei einer Aktualisierung des Debian-Pakets theoretisch die > > > neuen po-Dateien in das Paket manpages-de-1.22 zurückportiert werden, > > > aber das macht doch sicherlich keiner, oder? > > > Übrigens, es wäre vielleicht an der Zeit, für Buster ein eigenes > > > Verzeichnis im Git einzurichten (und im Gegenzug dafür Stretch zu > > > streichen oder einfach dessen Konfiguration auf Buster zu > > > aktualisieren). > > > > Das Zurückportieren passiert halbautomatisch, erzeugt für uns > > Übersetzer i.d.R. keine Arbeit (außer wir wollen die Zeichenketten, > > die es in der aktuellen Version so nicht mehr gibt, auch noch > > übersetzen). Daher würde ich mir über das secondary-debian-stretch > > keine Sorgen machen (es im Zweifel einfach ignorieren). Das einzige > > was dort nicht klappt, ist die Zuordnung der Übersetzer (siehe > > Debian_Fehler #897919). Und sehen tun das nur Benutzer, die > > »backports« aktiviert haben, d.h. Benutzer des reinen Veröffentlichung > > Stable nicht. > > > Ah, an die Backports habe ich gar nicht gedacht... Aber ist es > wirklich so, dass eine im Git explizit in »primary« eingefügte > po-Datei implizit in »secondary-xxx« landet, ohne unser Zutun? Das > würde mindestens voraussetzen, dass die Aktualisierungsskripte die > Verzeichnisse /upstream und /po abgleichen, um festzustellen, ob das > Vorhandensein einer bestimmten po-Datei in den > »secondary-xxx«-Verzeichnissen überhaupt sinnvoll ist. Ich hoffe, dass Dir das Tobias erklären kann. Viele Grüße Helge -- 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: Digital signature