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