Re: Übersetzungsfehler in den Release-Informationen
Hallo Rhonda,
wird eigentlich off-topic. dies sollte lieber unter debian-doc bzw. debian-www
durchgekaut werden.
On Mon, Jan 12, 2009 at 04:51:09PM +0100, Gerfried Fuchs wrote:
> Am Montag, den 12.01.2009, 16:23 +0100 schrieb Jens Seidel:
> > On Mon, Jan 12, 2009 at 03:23:16PM +0100, Gerfried Fuchs wrote:
> > > Am Montag, den 12.01.2009, 15:01 +0100 schrieb Jens Seidel:
> > > > Fand ihn:
> > > > http://www.debian.org/releases/lenny/i386/
> > > >
> > > > > http://www.debian.org/releases/lenny/releasenotes).
> > > >
> > > > Dies sollte in 4-8 Stunden funktionieren.
Funktioniert. Die deutsche Übersetzung habe ich auch gerade ergänzt.
> > > Du bist dir durchaus bewusst, dass es mit Absicht nicht verlinkt war,
> > > da es noch Probleme mit dem Bauen gegeben hat und bis vor ein paar
> > > wenigen Stunden (< 4) außer alpha nichts gab? Ich bin mir noch nicht mal
> >
> > Heh? Du hattest doch laut
> > http://cvs.debian.org/cron/parts/7release-notes?rev=1.19&view=log
> > den Bau der Lenny-Release Notes vor 10 Tagen schon wieder aktiviert, da es
> > angeblich ging!? Von aktuellen Bau-Problemen weiß ich nichts.
>
> Wie gesagt, vor wenigen Stunden noch war nichts davon online. Dass der
Wusste ich nicht :-) Ich habe geschaut, ob es ging, hatte die letzten
Mails diesbezüglich noch in etwa im Hinterkopf und wollte einen kleinen
Beitrag leisten. Habe ja nichts schlimmer gemacht :-))
> cronjob wieder aktiviert wurde bedeutet nicht, dass es damit nicht nach
> wie vor Probleme gibt; das bedeutet nur, dass es keine nachhaltigen
> Konsequenzen auf den Rest des Bauprozesses hat. Genau genommen bin ich
> mir bei letztem garnicht mal so sicher, da der Bau der Release-Notes
> fast drei Stunden dauert ...
Ja, ein Problem was wohl auch angesprochen wurde, ist ein make clean vor jedem
Bau. Dies war früher schon nötig, da wohl nur Dateien wie release-notes.de.pdf
im aktuellen Verzeichnis abgelegt wurden und darin die Architektur nicht kodiert
ist, so dass beim Neubau von z.B. release-notes.de.pdf für i386 nicht auf
release-notes.de.pdf vertraut werden durfte (da es eventuell die Version für
alpha war). Wie gesagt, das Problem ist uralt.
Und betrachtet man die Größe der japanischen PDF-Datei, wundert es auch nicht,
warum es so lange dauert.
> Und wenn du mir schon das Commit-Log vor Augen bringst, würde ich dich
> gerne bitten, auch die damit verbundene Log-Meldung anzusehen.
Verstehe ich nicht (Commit-Log == Log-Meldung, oder?). Meinst vielleicht die
zugehörige E-Mail.
> > > sicher, ob alles komplett gelöst sind, da sich im svn auch generierte
> > > Teile befinden (in den etch release-notes z.B. XX/release-notes.XX.sgml,
> > > die bei Änderungen unweigerlich zu Problemen beim nächsten Checkout
> > > wegen "modified copy" führen werden.
> >
> > Ja, das Problem kenne ich und hatte es früher zum Teil eingeführt, da ich
> > schon vor Jahren keine Alternative sah, erzeugte Dateien einzuchecken (wegen
> > po4a-Problemen).
>
> Dann muss der Build-Prozess, wenn er solche Dateien modifiziert, aber
Kam ja früher nicht vor. Dieses Mal liegt es eventuell an der Aktualisierung von
po4a. Hier ist das Problem, dass nur das Web- und Sicherheits-Team Zugang zum
Rechner hat, also 2-3 Leute, die es direkt betrifft.
> ganz klar damit zurecht kommen, dass es später wieder ein cvs/svn update
> kommen kann.
Dann denke doch an die letzte CVS-Aktualisierung, die in $Id$-Zeilen in der
Arbeitskopie das Datum von 2006-12-31 auf 2006/12/31 abgeändert hat, was zu
Konflikten führte, die lange bestanden und wohl nie in einem Fehlerbericht gegen
CVS resultierten, weil einfach niemand das Problem untersuchen konnte. Für so
etwas bringt es nichts, den Schuldigen zu suchen. Tritt so etwas auf, muss man es
eben korrigieren.
Im aktuellen Fall reicht es ja, die generierten Dateien zu löschen, wenn po4a
aktuell genug ist.
> Das war hier zum Teil nicht der Fall (oder es wurde beim
> anfänglichen Checkout oder anderen Dingen Fehler gemacht, die zum
> Vorhandensein der Konflikte geführt haben - auch möglich). Wenn etwas
> automatisiert passieren soll, dann soll es bitte auch so sauber
> passieren, dass es nicht ständiges Händchenhalten bedarf, weil ich sonst
ständig??? Einmal aller ein paar Jahre!
> den Nutzen darin nicht erkennen kann, wenn man erst recht wieder manuell
> eingreifen muss; und das kann's ehrlich gesagt auch nicht sein.
>
> > Wie dem auch sei, es ist ganz klar von allen Seiten gewünscht, eine Testversion
> > der Release-Notes online zu haben.
>
> Eine Testversion bedeutet aber nicht, dass die Rechnerressourcen zu
> übermäßig großen Teilen dafür rund um die Uhr in Anspruch zu nehmen
> sind, siehe oben.
Was hat das mit mir zu tun? Ich habe nur zwei Web-Seiten leicht modifiziert und
keinen Bau der Release-Notes angeregt. Wie schon gesagt, wenn du irgendwelche
konkreten Probleme hast (wie die lange Bauzeit, Änderungen in den Arbetskopien,
...) sprich dies einfach öffentlich an!
> Ich überlege mir grad, das von often nach lessoften zu
> verschieben, weil es in diesem Zustand ein wenig verantwortungslos und
> indiskutabel ist, auch wenn das jetzt ziemlich hart formuliert ist. Wenn
> es doch nicht laufend manuellen Eingriff bedarf, wie ich im Augenblick
> noch befürchte, dann wäre das eine Sache, mit der man leben könnte.
Mache das Problem öffentlich und eine Lösung ist dann eventuell simpel
(z.B. durch Vermeidung eines make clean durch bessere Makefile-Abhängigkeiten
oder durch Deaktivierung von PDF-Dateien, ...).
> Eventuell lässt sich einiges an Zeit gewinnen, wenn nicht, wie Simon
> meinte, bei jedem Bauen der komplette HTML-Tree von xsltproc neu gebaut
Private Mail?
> werden würde anstatt nur bei Änderungen. Das müsste man sich aber im
> Detail ansehen, im Augenblick stört mich eher das grobe noch weitaus
> mehr.
>
> > Sollte es damit noch Probleme geben, muss man
> > denen eben nachgehen. Aber in Anbetracht der Tatsache, dass selbst ich ziemliche
> > Probleme damit hatte, herauszufinden, wo, wann, welche Version der Release-Notes
> > gebaut wird, ist es besser, man beginnt erstmal und macht solche Probleme für
> > alle sichtbar.
>
> Da bin ich ja dabei, bei der Sichtbarmachung. :)
Na siehst du, darum geht es doch :-)
> > Ja, sende mal etwas. Ich bin mir keiner Probleme bewusst. Laut build-log unter
> > http://www-master.debian.org/build-logs/ gibt es keine Probleme.
>
> Du vergisst, dass durch die lange Zeitdauer, die der Build braucht, das
> Zeitfenster zum betrachten des kompletten Build-Logs nur recht gering
> ist, bevor das nächste beginnt. Simon Paillard war sich glaub ich
Eine Lösung dazu ist trivial. Einfach vor dem Bau eine Kopie der Log-Datei
erstellen ...
> gestern garnicht mal so sicher, ob lenny überhaupt gebaut werde, weil er
> in den Logs nichts dazu gefunden hat, bis ich ihn drauf hingewiesen hab,
> dass es noch beim Bauen gerade erst bei den etch-Releasenotes war. Zu
> diesem Zweck hab ich jetzt gerade einen symlink zum letzten rotierten
> release-notes.log.0 angelegt.
Genau die fehlenden Informationen sind das Problem. Lass uns mal davon
ausgehen, dass alles klappt, die Webseiten einrichten, ... Wenn das entwas
nicht in Ordnung ist, wird sich schon jemand beschweren ...
Jens
Reply to: