Die Leute wollen oft gerne wissen, wie eine Anwendung aussieht, bevor sie sie installieren. Das ist einer der Gründe, warum Christoph Hass den screenshots.debian.net-Dienst ins Leben gerufen hat. Man kann dort Screenshots für seine Lieblingsanwendungen hochladen, damit auch andere sie sehen können.
Schlussendlich sind diese nun der Einfachheit halber auch auf packages.debian.org integriert. Wenn ihr auf den Screenshot eines Pakets klickt, könnt ihr alle anderen verfügbaren sehen.
Falls es noch keinen Screenshot gibt, wird die Seite ein Platzhalter-Bild anzeigen, das die screenshots-Seite des Pakets verlinkt, auf der ihr zum Nutzen aller einen Screenshot hochladen könnt. Bitte beachtet die Richtlinien beim Hochladen, sonst könnte das Bild abgelehnt werden.
Zu einem nicht komplett anderem Thema, die packages.ubuntu.com-Seite zeigt endlich ebenfalls Pakete aus maverick an. Sie zeigt jedoch noch keine Screenshots – falls ihr denkt, dass das Hinzufügen von Screenshots dort ebenfalls eine gute Idee wäre, lasst es mich bitte wissen!
Vor geraumer Zeit war ich mit meiner anderen Hälfte auf einem Konzert einer Band, die ich später mal empfehlen will. Dieses mal will ich jedoch die Vorband des Konzerts erwähnen: Jerboa. Es war schon ein wenig seltsam, eine einzelne Person auf der Bühne zu sehen, die an einigen Knöpfen herumgedreht hat, aber er hat unsere Aufmerksamkeit und unsere Herzen rasch eingefangen. Ebenfalls war es sehr nett, mit ihm im Nachhinein zu reden, als wir seine CD gekauft haben. Er verdient auf jeden Fall eure Aufmerksamkeit, und falls ihr es schafft, ihn Live zu sehen, nehmt die Chance wahr.
Number 1: Das offensichtliche erste Lied in der Liste. Perfekter Groove mit ebenfalls großartigem Video.
Just Another Number: Es beginnt recht ruhig, zieht dann aber enorm an. Es fällt schwer, seinen Kopf bei diesem Lied nicht mitnicken zu lassen, und es ist sehr weit davon entfernt, lediglich nur eine weitere Nummer zu sein.
Tatsächlich hätte ich gerne What if in der Liederliste mit erwähnt, aber unglücklicherweise war das Lied nicht verfügbar und ich musste mich nach einem Ersatz umsehen.
Alles Gute zum 17. Geburtstag, Debian! Du hast mich die letzten 10 Jahre auf Trab gehalten und ich freue mich wirklich darauf, was die nächsten 10 Jahre in unserer Beziehung passieren wird.
Mein Dank gilt auch an all jene Leute, die es schaffen, ruhig zu bleiben und in Diskussionen auf den Punkt kommen, wenn diese hitziger werden. Ihr seid diejenigen, die das Arbeiten an Debian erfreulich macht.
Ebenfalls ein riesigen Dank an jene Leute, die die Kraft von positiver Ermutigung, wie sie derzeit auf der thank.debian.net-Website fließt, verstanden haben.
Ebenfalls vielen herzlichen Dank an die immer größer werdende Anzahl an Distributionen, die auf Debian basieren, da dies ein Akt der ganz besonderen Wertschätzung unserer Arbeit darstellt.
Dieser Blog-Eintrag ist eigentlich eine Antwort auf einen Vortrag, der letzte Woche auf der Debian-Konferenz abgehalten wurde. Es war Margas Vortrag über Making Debian Rule, again. Jetzt da die Beta-Versionen der Vorträge zum Herunterladen verfügbar sind, ist es mir möglich korrekt zu zitieren, worauf ich mich beziehe: Gibt es einen Grund, warum wir die Website noch nicht aktualisiert haben?, vielleicht kann das jemand beantworten.
Ich denke es ist notwendig, darauf zu reagieren, da ich die Hauptperson bin, die die Sache vorantreibt. Unglücklicherweise wurde die Frage in einem Vortrag gestellt, bei dem niemand der daran beteiligten Personen anwesend war, statt sie an eben diese Personen direkt zu richten, und die Frage wurde mir vor dem Vortrag nicht zugeschickt, um eine Antwort für die Präsentation bieten zu können. Als besonderer Hinweis möchte ich anmerken, dass dies meine eigene Sicht der Dinge ist und sich nicht notwendigerweise mit der der anderen beteiligten Personen decken muss. Ich hoffe, dass es trotzdem als eine Antwort angesehen werden kann.
Kleiner Hintergrund dazu, Kalles Vorschlag hatte schon viel geschafft, bevor ich überhaupt über ihn gestolpert bin. Ich war einfach nur begeistert davon, und das nicht nur weil es eine großartiges Modell für die Seiten ist (und das ist es tatsächlich, meiner Meinung nach), sondern auch Überlegungen dazu enthielt, wie man nicht nur die Hauptsite sondern auch mehrere Untersites eingliedern könnte. Ebenfalls enthielt es Patches, was das direkte Anwenden stark vereinfachte.
Ich fing an, daran zu arbeiten, und mir wurde vorgeworfen, dass ich demotivierend bin, weil ich das tat, und außerdem dass es eine ordentliche Abstimmung benötigen würde statt einfach so umgesetzt zu werden, aber das fällt wieder unter den Kommunikations-Stil von Debian. Ich hab trotzdem nach und nach einige Test-Sites aufgesetzt, um mich damit zu spielen. Einige haben besser funktioniert (wie bei git, obwohl diese zuletzt gekommen ist und Kalle die CSS über die Zeit hinweg recht gut verbessert hat), einige waren noch nicht fertig (wie das wiki, dem z.B. die Einfärbung für Versionsunterschiede fehlte, oder bei packages, wo die Unterscheidung zwischen den verschiedenen Abschnitten nicht sonderlich sichtbar ist). Die Zeit verging, andere Dinge forderten ebenfalls ihre Aufmerksamkeit ein.
Wie zum Beispiel dass unsere System-Administratoren mich dazu aufgefordert haben, einen neuen www-master-Server neu aufzusetzen. Da die Dokumentation der benötigten Pakete für die Webseiten ziemlich unvollständig waren (um es freundlich zu formulieren) hat dies auch einiges an Aufmerksamkeit benötigt, speziell ist der Wunsch, die Abhängigkeiten sauber zu dokumentieren einfach offensichtlich, wenn man quasi von Null beginnt. Es gibt dabei nach wie vor einige Probleme, wie z.B. auf dieser Seite in der leeren Tabelle am Ende zu sehen ist. Das selbe Problem tritt auch auf meiner Testsite für das neue Design auf.
Der letzte Teil ist jedoch derzeit die größte Blockade für beide Anstrengungen. Es gibt keine Möglichkeit, in eine der beiden Richtungen weiterzugehen, ohne das gelöst zu haben. Simon Paillard hat großartige Arbeit dabei geleistet, die Umstellung voranzutreiben und den Thread über die Notwendigkeiten für den Server-Move, den ich auf der debian-www-Liste angestoßen habe, aktuell zu halten. Unglücklicherweise haben sowohl Kalle, Simon als auch ich einige private Zeitbeschränkungen (neben anderen Pflichten, die ihre Aufmerksamkeit benötigen), was nicht sonderlich hilfreich dabei ist, die Sache rascher voranzutreiben. Unglücklicherweise waren nicht sonderlich viele Leute daran interessiert, sich einzubringen, weil es natürlich einfacher ist, dem komplett falschen Publikum die Frage zu stellen, warum es noch nicht fertig ist.
Ich habe vor, viele Sites gleichzeitig umzustellen statt einer nach der anderen, einfach wegen dem Effekt aber auch, um weniger Ablenkung für die Benutzer zu produzieren, inklusive dass weniger Leute laufend nachfragen werden, wann diese oder jene Site ebenfalls umgestellt wird. Zumindest brauchen wir eine endgültige Diskussion darüber, welche Links an den Anfang und das Ende der Seiten hinein gehören, bevor die Umstellung passieren kann. Und einige sind immer noch der Meinung, dass so eine Umstellung etwas ist, das wir ohne eine Abstimmung einfach so entscheiden dürfen, was ebenfalls mit ein Grund ist, warum wir es nicht einfach umgestellt haben.
Ich hoffe, das beantwortet die Frage hinreichend – und wie gesagt, wenn sie mir vor dem Vortrag gestellt worden wäre, hätte man im Vortrag bereits eine Antwort präsentieren können, statt nur einem kurzes Kommentar übers IRC übermittelt zu bekommen (danke, Yoe!), da ich das Glück hatte, mir die Zeit freizunehmen und den Vortrag ansehen zu können. Seid herzlich dazu eingeladen, es auf deban-www weiter zu diskutieren oder eure Hilfe anzubieten, insbesondere, wenn ihr damit vertraut seid, an CSS-Dateien zu arbeiten.
Vielleicht erinnert ihr euch daran, dass ich damit begonnen habe, Release-kritische Fehler in stable zu schließen. Den Einsatz dafür hab ich nicht eingestellt, daher hab ich beim RC Bug Squashing Contest mitgemacht, der während der Debian-Konferenz stattgefunden hat (an der ich nicht teilnehmen konnte). Die Regeln haben dies erlaubt, selbst wenn ich mir bewusst war, dass es nicht mit den Leuten verglichen werden dürfte (oder sollte), die an unstable/testing arbeiten, und es wurde eine eigene spezielle Kategorie dafür erstellt.
Es gibt jedoch offenbar nach wie vor einiges an Verwirrung darüber, wie das die Fehlerdatenbank (BTS) arbeitet, speziell in Bezug auf die Verfolgung von Versionen. Mir wurde sogar vorgeworfen, dass ich fälschlicherweise das Schließen von Fehlern für mich beansprucht hätte, da der Fehler bereits von jemandem anderem geschlossen wurde. Dies war jedoch nicht der Fall, sonst hätten die Fehlerberichte bereits vor langer Zeit archiviert sein müssen[1] – da ich von jener Person erwartet hätte, dass sie weiß, wie das archivieren von Fehlern funtioniert und auch aufgrund der enormen Anzahl von Fehlern, die ich für stable einfach schließen konnte, ist es wohl notwendig, das ganze breiter zu beleuchten, wieso manche Fehlerberichte nicht wie erwartet archiviert werden.
Falls ihr meinen IRC-Vortrag zur Verwendung des BTS im letztem Monat gefolgt seid, dürftet ihr wohl schon eine Idee dazu haben, was vorsich geht. Es gibt mehrere unterschiedliche Gründe, warum Fehlerberichte noch nicht zum Archivieren markiert sind. Ich versuche diese hier erklären soweit ich sie während meiner Arbeit an Fehlern über die vergangenen 10 Jahre hinweg verstanden habe (da ich weder in den debbugs-Code geschaut noch mit dessen Entwicklung zu tun habe).
Üblicherweise werden Fehler zum Archivieren markiert, wenn sie testing nicht betreffen. Das bedeutet, dass ein Fehler, der gegen eine Version, die sich nur in unstable befindet und in unstable behoben wird, direkt zum Archivieren freigegeben wird (tatsächlich nicht ganz so direkt: Das Paket muss auf allen Architekturen, für das es verfügbar ist, ebenfalls synchron sein); anderenfalls muss die Reparatur des Fehlers nach testing rutschen, bevor der Fehler zum Archivieren in Betracht gezogen wird.
Manchmal wird der Fehler jedoch immer noch als unstable betreffend angesehen, selbst wenn eine reparierte Paketversion bereits nach testing gewandert ist. Dies ist der Fall, wenn das Paket auf hurd-i386 in unstable veraltet ist und kann in der Übersicht des Pakets auf packages.debian.org herausgefunden werden, dort ist ein roter Eintrag neben den grünen zu sehen (die roten Einträge für die debports-Architekturen können jedoch ignoriert werden!). Ihr müsst dafür dann ein architekturspezifisches Lösch-Ansuchen melden, um diese Fehler archiviert zu bekommen.
Für Pakete in experimental ist die Situation recht ähnlich, abgesehen davon, dass Pakete von experimental nirgendwohin automatisch rutschen und daher durchaus für geraume Zeit unarchiviert bleiben können, falls diese Fehler auch unstable betreffen.
Was kann also der Grund sein, wenn die Behebung bereits in testing verfügbar ist, der Fehler aber immer noch nicht archiviert wird? Diese Fälle bedeuten, dass der Fehler für stable als relevant erachtet wird und dort ebenfalls zu beheben ist. Fehler, die dafür herangezogen werden, haben einen release-kritischen Schweregrad; Fehler mit geringerer Schwere werden als für stable nicht relevant erachtet, da es unwahrscheinlich ist, dass diese in stable behoben werden und werden daher archiviert. Was kann man aber gegen diese Fehler tun?
Betreffen sie stable tatsächlich? Solche Fehler zu bearbeiten ist, was ich die letzten Monate gemacht habe. Sie werden häufig für Änderungen in Bibliotheken, FTBFS (baut nicht mehr vom Quellcode) oder bei Änderungen in den verwendeten Hilfsprogrammen gemeldet, oder andere Dinge, die für stable nicht anwendbar sind. Diese in stable zu schließen ist einfach:
Wenn die Versionsinformationen verloren gegangen sind (durch eine Neuzuordnung oder ähnliches), ist es lediglich notwendig, die found-Version wieder hinzuzufügen, falls diese höher ist als jene in stable.
Wenn die Versions-Informationen korrekt sind (da in unstable immer noch die gleiche Version zum Zeitpunkt des Meldens vorhanden ist), kann man sie mit + squeeze sid markieren, was dem BTS mitteilt, den Fehler nur für diese Releases zu erachten und daher nicht mehr denkt, dass es lenny ebenfalls betrifft.
Einige betreffen stable, sind jedoch nicht schwerwiegend genug, um eine Aktualisierung des Pakets in stable zu rechtfertigen (z.B. für Dokumentations-Korrekturen in debian/copyright oder ähnlichem). Wenn ihr solche findet, kontaktiert bitte das Release-Team, um diese mit mit lenny-ignore markiert zu bekommen, tut das nicht selbst, da diese Markierung nur vom Release-Team zu setzen ist!
Falls die Fehler stable tatsächlich ebenfalls betreffen (z.B. bei Sicherheitsproblemen, die vom Sicherheitsteam jedoch als zu gering erachtet werden, um dafür ein DSA herauszugeben, oder andere schwerwiegende Bedienbarkeitsprobleme), portiert die entsprechende Reparatur dafür zurück, schlagt dem Release-Team auf ihrer Mailing-Liste ein diff vor und ladet es nach lenny-proposed-updates hoch, um es in der nächsten Aktualisierung von stable repariert zu bekommen.
Ich hoffe, dass dieser Artikel auch andere dazu animieren wird, Fehler in stable zu beheben. Tatsächlich schicke in den Betreuern von Paketen, deren Fehler in die letzte Kategorie fallen, einen Hinweis, dass diese zu beheben wären. Einige von euch dürften bereits solche Hinweise erhalten haben und ich bin all jenen dankbar, die sie tatsächlich dankbar aufgegriffen und bereits einige davon ebenfalls behoben haben. Vielen Dank dafür, dass ihr stable zu einem besserem Ort macht!
Um auf den RCBC zurückzukommen, es war ein interessanter kleiner Wettbewerb (wenn auch nur in meinen Gedanken) zwischen mir selbst und jenen, die an RCs in testing/unstable gearbeitet haben. Es wäre nett gewesen, in stable zumindest genausoviele Fehler wie in testing/unstable geschlossen zu bekommen, da die Anzahl immer noch um einiges höher ist, aber ich bin erfreut über die geschafften Dinge. Und es tut gut zu wissen, dass es nicht jeder als verschwendete Liebesmühe ansieht, die RC-Anzahl in stable kleiner zu bekommen (wie mir ebenfalls für meinen Einsatz gesagt wurde). Vielen Dank daher auch aus diesem Blickwinkel!
[1] Es sind derzeit 2688 Fehler immer noch nicht archiviert, die bereits letztes Jahr geschlossen wurden! Diese Abfrage der UDD kann euch helfen: select count(*) from bugs where status = 'done' and last_modified <= '2009-12-31';
Debian war immer schon für seinen Kommunikations-»Stil« bekannt. Es wurden sogar T-Shirts verkauft im Gedenken an Espy Klecker mit einem Zitat von ihm: Morons. I'm surrounded by morons. (»Idioten. Ich bin von Idioten umgeben.«) Ja, ich hab mir in den Anfangstagen selbst eines dieser Shirts gekauft. Und es gab Vorträge, die Debian als einen Platz beworben haben, an dem man GutesFlamewar-Training bekommt. Und die Leute erachteten es als den Spaßfaktor.
Nach einigen Jahren wurde es ermüdend. Es wurde stressig. Es wurde unangenehm. Schlechte Gefühle kamen auf, zogen dich in den nächsten Flamewar, und von da ging's nur noch bergab. Es wurde beinahe unmöglich, nicht das Ziel eines Flamewars zu sein, wenn man mehr als nur minimale Betreuung der eigenen Pakete tat. Schnippische und extrem knappe Antworten wurden zum Standard.
Zu guter Letzt fingen die Leute damit an, aufzugeben und zu gehen. Das Hässliche daran ist, dass menschliche Ressourcen kritisch sind. Sie sind nicht endlos und können nicht einfach wie kaputte Hardware ersetzt werden, speziell wenn fähige Leute oder jene Leute gehen, die enorm viel Zeit und Anstrengungen investiert haben. Und da ein nicht geringer Teil der Leute auch ihr Herz in Debian investieren, fühlt es sich wie ein kleiner Selbstmord an und das öffentliche Nachdenken über diesen letzten Schritt ist als Schrei nach Hilfe zu sehen, die nicht gegeben wurde und nicht gegeben wird.
Die Lösung für diese Todesspirale? Ich bin mir nicht sicher. Wenn man über den Tellerrand schaut und für einen Augenblick alle unguten Gefühle ignoriert, die man sich vielleicht gegenüber Ubuntu wegen ihrem Erfolg und der Möglichkeit, laufend neue Mitstreiter zu finden, dann wird man dort eine weitaus freundlichere und produktive Umgebung vorfinden. Vermutlich kann man das auf den Verhaltenskodex zurückführen, über den ich letztes Jahr bereits geschrieben habe und der ein extrem gut gemeintes und nützliches Dokument ist (die Kritik, die ich geäußert habe, ist bereits seit einiger Zeit behoben, deswegen wurde ich ein MOTU). Und selbst wenn es manchmal schwer ist, ihn zu beherzigen, erinnert und ermutigt Mark Shuttleworth seine Mitstreiter, diesen Prinzipien selbst in schwierigen Zeiten treu zu bleiben.
Das Ergebnis? Wenn man die Planets verfolgt, findet man auf Planet Ubuntu einen sehr guten Anteil an Blog-Einträgen über Dinge, die geschafft wurden, verglichen mit der ebenfalls beachtlichen Rate an Herumgezetere auf Planet Debian. Und obwohl sich die Leute regelmäßig über den Kommunikationsstil in Debian beschweren, sind die Antworten auf auf die Frage nach einem Verhaltenskodex für Debian eher enttäuschend. Es ist daher mehr als nur verständlich, dass viele den Weg beschreiten, der sie selbst schmerzt, einen Schnitt machen und das Projekt in seinem Durcheinander zurück lassen.
Für mich selbst? Ich bin häufig genug nicht allzu weit von diesem Punkt entfernt, und ich kann jene nur allzu gut verstehen, die den letzten Schritt gemacht haben. Regelmäßige Schmähungen, speziell wenn man Dinge tut, die andere regelmäßig vernachlässigen aber trotzdem getan werden müssen, auf Basis davon heruntergemacht zu werden und nicht ernst genommen zu werden sowie respektlose Antworten zu bekommen verbessern nicht die Situation. Es passiert viel zu vielen Leuten und das einzige, was mich immer noch bei der Stange hält ist, dass ich noch nicht aufgeben will, dass ich nicht daran glaube, dass es Debian verbessern kann, den verschiedenen destruktiven Leuten den Platz zu überlassen.
Geht klar, ich hoffe, ihr seid bereit für die nächste Runde an Musik-Links. Dieses Mal bin ich über eine alte (und immer noch eine) meiner Lieblingsbands gestolpert, während ich nach Informationen über Max Headroom gesucht habe: Art of Noise. Ihr habt vermutlich schon den einen oder anderen ihrer Lieder gehört, sie werden recht häufig verwendet. Hier sind sie:
Peter Gunn: Ebenfalls gut bekannt und oft verwendet. Ihr müsst ein wenig warten, bevor die Musik anfängt, dieses Video enthält einen Vorspann.
Paranoimia: Drittes großartiges Lied, das ihr ebenfalls schon wo gehört haben könntet. Absolut herziges Lied.
Es ist wirklich schade, dass solche Bands einfach verschwinden. Es ist jedoch nach wie vor die perfekte Musik, um sie im Hintergrund laufen zu lassen, während man drauf los hackt. Hochgradig motivierend, super zum mitsummen. Oh, und ihr könntet euch fragen, wo nun die Verbindung zu Max Headroom ist. Hier ist sie, in einer speziellen Version von Paranoimia featuring Max Headroom!
Ich wurde dazu überredet, einen IRC-Vortrag über die Verwendung der Fehlerdatenbank von Debian im #ubuntu-classroom abzuhalten und dachte, es könnte auch für andere Debian-basierte Distributionen interessant sein – auch für reine Debian-Benutzer. Seid daher herzlich dazu eingeladen.
Der Vortrag wird am Donnerstag, den 22. Juli, um 18:00 UTC im #ubuntu-classroom auf irc.freenode.net stattfinden. Für jene, die solch eine Sitzung nie zuvor besucht haben ist es wohl interessant, ebenfalls nach #ubuntu-classroom-chat zu gehen und dort Fragen zu stellen, da der Hauptkanal moderiert sein wird.
Ich werde versuchen, die grundlegende Verwendung der Web-Schnittstelle und des Meldens von Fehlern zu behandeln sowie auch tiefergehend auf die Behandlung von Fehlern inklusive der Handhabung der Versionsverfolgung einzugehen, und die eingeworfenen Fragen so gut als möglich zu beantworten.
Ich hoffe, der Vortrag wird einigen helfen können und auch Fragen beantworten wie z.B. warum manche Fehler nicht archiviert werden, obwohl sie seit Ewigkeiten geschlossen sind. :) IRC-Logs wird es auch geben, damit auch jene etwas davon haben, die es zeitlich nicht schaffen.
Durch die Arbeit an und für Debian das ganze Jahrtausend schon wäre es schwer gewesen, Ubuntu über die Zeit hinweg nicht zu bemerken. Da das beheben von Fehlern im Interesse von allen Beteiligten ist, wurde ich in Bezug auf die Pakete, die ich in Debian betreue, neugierig, was für Fehler Ubuntu-Benutzer dagegen gemeldet haben könnten. Da ein nicht unwesentlicher Teil davon ebenfalls Debian betreffen, habe ich damit begonnen, diese ebenfalls zu beheben.
Es gibt jedoch so manchen Fehler-Status, den man als Außenseiter nicht verwenden kann, und da mein perfektionistischer Ansatz ungern Pakete in einem Release haben will, die sich in schlechter Form befinden, habe ich mir die Prozesse genauer betrachtet und darum angesucht, als Ubuntu-Entwickler aufgenommen zu werden, genauer gesagt als MOTU, was mir die Möglichkeit gibt, direkt SyncRequests abzusetzen statt nach einem Sponsor zu suchen, oder den »wontfix«-Status für Fehlerberichte in meinen Paketen zu verwenden, die einfach keinen Sinn machen, umgesetzt zu werden.
Vergangene Woche wurde ich in diesen Status aufgenommen und ich möchte mich für all die netten und ermutigenden Rückmeldungen auf dem Weg dorthin bedanken (inklusive einiger »Was? Ich dachte, du wärst schon seit Ewigkeiten MOTU??«-Antworten). Wir werden sehen, wie sehr ich es tatsächlich benötige, da mein Ansatz es eher ist, die Unterschiede von Ubuntu zu eliminieren statt an ihnen zu arbeiten. Ich verstehe jedoch ganz gut, dass diese in Zeiten kurz vor den Releases notwendig sein können, wie sich auch recht gut darin zeigt, dass das Paket, in das ich am meisten Einsatz investiere ((wesnoth-1.8), einen Ubuntu-Unterschied im neuesten Lucid-Release aufweist. Und da sich Ubuntu bereits im Debian-Import-Freeze befindet, hab ich gleich mal um einen SyncRequest für gitolite angesucht.
Danke für die rasche und eher unbürokratische Aufnahme! Und nein, Laney, ich werde den Vortrag morgen deshalb trotzdem nicht alleine abhalten. ;)
Am Montag war ich wieder auf einem Konzert von Grossstadtgeflüster, und es war wieder eines der besten Konzerte, die ich besucht habe. Das neue Album hat wieder genauso großartige Songs wie auch auf den vorhergehenden beiden vorhanden sind, und ihr Live-Auftritt ist es auf jeden Fall wert. Zusätzlich sind sie auch abseits der Bühne einfach nur charmant. Jen, Raphi und Chriz, ich lieb euch einfach!
Es ist schwierig, die Lieder auszuwählen, die ich hier reinstelle, da es einfach zu viele großartige gibt, seid daher dazu eingeladen, selbst weiterzusuchen, falls es euch gefällt:
Weil das morgen noch so ist: Ihre aktuelle Single, großartiges Video, das einen guten Eindruck von ihrem Stil und dem Spaß vermittelt, den sie daran haben.
Lebenslauf: Super Lied aus ihrem vorhergehendem Album.
Fehler: Enorm viel Wahrheit im Text, ans Herz gehend.
»Today is the greatest day I've ever known,« – diese Zeile geistert heute in meinem Kopf herum, dank der vielen kleinen Dinge, die so passiert sind. Und es ist sowieso schon wieder dieser Zeitpunkt im Monat, um eine weitere Band in meinem kleinem Blog vorzustellen. Hier sind sie also, eine der großartigen Bands der Neunziger, und wie viele davon sind sie nach einer Auflösung wieder zurück: The Smashing Pumpkins, und dies sind die vorgestellten Lieder:
Today: Das Lied mit dem eingangs erwähnten Zitat. Unglücklicherweise nicht das offizielle Video, da in jenen Versionen die Musik seltsam zerstückelt ist. Falls ihr es für euch selbst abstimmen wollt, könnt ihr es euch hier trotzdem ansehen: Today (echtes Video, kaputte Musik)
Disarm: Aus dem selben großartigen Album, und eines jener Lieder, die mir eine Gänsehaut auf den Rücken zaubern.
Hoffentlich ihr genießt diese kleine Ablenkung einmal im Monat. Ich hoffe, ich bleibe dran, es ist keine Frage des Materials, es gibt da draußen einfach zu viele großartige Bands, die ich gerne mit anderen teilen möchte. :)
Wir sind nicht tot. Es ist viel Zeit vergangen, seit ich das letzte Mal zu diesem Thema geschrieben habe, und viele Dinge sind passiert – unglücklicherweise (für diesen Einsatz) in anderen Bereichen.
Das bedeutet aber nicht, dass die Arbeit daran aufgegeben wurde. Deswegen präsentiere ich hier den nächsten großen Schritt: Ein gitweb-Thema, das Kalles Vorschlag verwendet. Ich habe es auf meiner eigenen gitweb-Installation aktiviert, damit die Leute es direkt sehen und verwenden können. Seid dazu eingeladen, es von dort auch zu clonen.
Einige Leute fragen mich von Zeit zu Zeit, wann ich Battle for Wesnoth 1.8 hochladen werde. Meine übliche Antwort dazu ist, dass es bereits vor der offiziellen Ankündigung im wesnoth-1.8 Paket passiert ist.
Die längere Antwort, die auch Wieso die Namensänderung? beantwortet, lautet wie folgt: Es wurde darum gebeten, eine Möglichkeit zu bieten, verschiedene Entwicklungszweige nebeneinander installieren zu können, um für die begonnenen Kampagnen den alten stabilen Zweig noch zu haben aber trotzdem mit Freunden Mehrspielerpartien mit der neuen stabilen Version spielen zu können. Ebenfalls haben sich diejenigen, die die Entwicklungsversion verwenden gewünscht, die stabile Version nicht entfernen zu müssen, um den Entwicklungszweig zu verwenden.
Und da ist es! Genießt es! Es fehlt jedoch nach wie vor etwas, und das ist auch der Grund, warum die Frage nach der Version 1.8 von Wesnoth immer noch hochkommt: Es gibt noch kein Übergangs-/Metapaket. Diese benötigen noch etwas mehr Arbeit, inklusive der Handhabung von Alternativen (damit man nur wesnoth aufrufen kann und nicht den versionisierten wesnoth-1.8 Programmnamen verwenden muss) und die Verwendung von dpkg-divert für die historisch unversionisierten wesnoth-Pakete.
Da mein Release doch einiges an Unterstützungsoverhead einfordert kann ich nicht sagen, wann ich diese Dinge fertig bekommen werde, jedoch läuft ein ähnlicher Unterstützungsvertrag mit Ende des Monats aus, ich werde daher nächsten Monat möglicherweise etwas Zeit finden, das abzuschließen. Falls ihr es früher erledigt haben wollt oder aushelfen wollt, fühlt euch dazu eingeladen, Patches zu schicken, nachdem ihr mit mir über genaueres und mögliche Ansätze gesprochen habt. Danke schon im Vorhinein!
Meine andere Hälfte hatte heuer eine enorm gute Idee für meinen Geburtstag: Wir haben ein Konzert von Ich + Ich besucht. Wir waren beide zuvor ein wenig skeptisch – aber wir sind uns jetzt beide darüber einig, dass es eines der besten Konzerte war, das wir besucht haben. Ich möchte daher einige großartige Lieder der Band mit euch teilen:
Universum: Ich denke beim Hören dieses super-süßen Liedes an meinen Sohn.
Stark: Das ist nicht nur der Titel sondern auch der Text.
Am 20. März, um fünf vor Mitternacht, haben wir unser anstrengendstes und zeitaufwändigstes Projekt veröffentlicht. Der Codename lautet Simon André und wir freuen uns, dass es ein (mehr oder weniger) sauberer Release-Prozess mit nur geringer Verzögerung von drei Tagen war – aber die Besten veröffentlichen nicht nach der Zeit sondern wenn es fertig ist.
Da jeder Screenshots liebt, sind ein paar auf unserer speziellen Screenshot-Seite zu finden, zwecks Vollständigkeit enthält diese Ankündigung ebenfalls eines:
Eine Woche nach dem Release können wir bekannt geben, dass die Rückmeldungen und das Interesse sehr gut sind, die Wartung fordert ihr Tribut, aber es ist noch nichts wirklich unerwartetes passiert. Wir blicken in eine frohe Zukunft!
Danke für die Aufmerksamkeit, und genießt das nette Frühlingswetter!
Du vergisst eines - debian/source/format erlaubt es dir, explizit festzulegen, dass das Source-Format 1.0 sein soll, falls Du es behalten willst.
Du vergisst eines - die geplante Umstellung des Standard-Formats wird von vielen Leuten nicht als guten Ansatz empfunden. Wenn etwas neues eingeführt wird, sollte die Umstellung darauf bewusst gemacht werden. Andere Hilfsprogramme machen es auch, warum kann ein zentrales Paket wie dpkg diesem Ansatz daher nicht folgen? Ich erinnere außerdem daran, dass eine Aktualisierung in einem Point-Release für stable notwendig war, um es in stable so zum Funktionieren zu bekommen, wie es sollte.
Vor kurzem hat sich Ganneff gefragt, ob es möglich wäre, die matcher-Erweiterung von rxvt-unicode dazu zu bewegen, etwas wie #12345 ebenfalls aufzugreifen und es in einen Link in die Fehlerdatenbank verwandelt.
Das ist nicht möglich – oder eher, es war nicht möglich. Die Idee blieb in meinem Kopf hängen und ich hab ein wenig Zeit investiert, es passieren zu lassen. Hier ist ein rasches und unsauberes diff, um es zu realisieren:
--- /usr/lib/urxvt/perl/matcher.distrib 2009-11-30 06:44:07.000000000 +0100
+++ /usr/lib/urxvt/perl/matcher.rhonda 2010-03-24 23:57:01.000000000 +0100
@@ -3,13 +3,14 @@
# Author: Tim Pope <rxvt-unicodeNOSPAM@tpope.info>
my $url =
- qr{
+ qr{(?:
(?:https?://|ftp://|news://|mailto:|file://|\bwww\.)
[a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*
(
\([a-zA-Z0-9\-\@;\/?:&=%\$_.+!*\x27,~#]*\)| # Allow a pair of matched parentheses
[a-zA-Z0-9\-\@;\/?:&=%\$_+*~] # exclude some trailing characters (heuristic)
)+
+ )|\#[0-9]{4,}
}x;
sub on_user_command {
@@ -145,6 +146,7 @@
my @begin = @-;
my @end = @+;
if (!defined($col) || ($-[0] <= $col && $+[0] >= $col)) {
+ $match =~ s/^#/http:\/\/bugs.debian.org\//;
if ($launcher !~ /\$/) {
return ($launcher,$match);
} else {
Das diff ist absichtlich klein, damit es klarer ist, was hier passiert. Und es sollte Anhaltspunkte für weitere Erweiterungen geben, die jemand vornehmen wollen würde. Ich erachte ihn jedoch nicht für flexibel genug, um ihn an die Entwickler weiterzuleiten. Genießt ihn trotzdem!
Erschlagen von Release-kritischen Fehlern in stable, Teil 2
Ich habe vor einiger Zeit über das Erschlagen von Release-kritischen Fehlern in stable gebloggt. Gestern haben wir einen Meilenstein auf dem Weg geschafft: Die Anzahl der Release-kritischen Fehler in stable beträgt weniger als 1000 (blauer Graph). Dies hört sich vielleicht immer noch ziemlich hoch an, aber da wir vor einiger Zeit durchaus noch über 1600 RC-Fehler in stable hatten, erachte ich dies als ziemlichen Erfolg.
Das ist aber kein Punkt, um sich darauf auszuruhen. Es gibt immer noch viel zu viele RC-Fehler in stable und es sind sicher noch genügend Fehler vorhanden, die stable nicht betreffen und daher als solches markiert werden können was bedeutet, das dafür kein Upload notwendig ist. Ich beobachte die Fehler mit hohen Nummern genauer und die Meisten davon betreffen stable durchaus auch und benötigen daher etwas mehr Arbeit, als sie nur zu markieren.
Danke an alle Leute, die in diesem Bereich geholfen haben, ich kann mich nur an ein paar Namen erinnern und will daher keinem das Gefühl geben, vergessen worden zu sein, jedoch will ich Lucas danken, dass er seine FTBFS-Runden nun direkt mit squeeze sid markiert, da die Pakete offensichtlich zuvor durchgebaut haben aufgrund seiner regelmäßigen Rebuilds. Danke an alle, aber wie gesagt, es ist nicht die Zeit, sich auszuruhen. Der grüne squeeze-Graph ist nach wie vor ungefähr 250 Fehler von uns entfernt!
Das t-prot-Paket könnte deine Hilfe gebrauchen: Es gibt mit dem Upstream-Entwickler eine Diskussion darüber, wie man in Bezug auf eine hoffentlich nützliche Änderung im Verhalten weitermachen soll. Es gibt mehrere Möglichkeiten, wie man es angehen kann, eine davon betrifft die Verwendung des Getopt::Long-Moduls statt Getopt::Mixed. Da die Benchmarks von Seiten Upstream eher dafür sprechen, bei Getopt::Mixed zu bleiben, würden wir euch gerne um eure Hilfe bitten:
Testet bitte diese Version von t-prot (für eure Sicherheit: abgetrennte gpg-Signatur für diese Version) und vergleicht es mit der paketierten Version 2.15, die ich gerade nach unstable hochgeladen habe (sie ist ohne weiteres auch in (old)stable oder testing installierbar). Eure Rückmeldungen sind sehr willkommen, schickt sie bis Anfang nächster Woche (Montag Abend/Dienstag Morgen) an »t-prot (AT) tolot.escape.de«.
Wenn ihr ein paar Pakete sucht, um die ihr euch in Debian kümmern wollt, werft einen Blick auf diese Liste und meldet euch bei mir, wenn ihr Interesse habt.
Ich wünsch euch das beste zum Feste, habt eine nette Zeit, verwendet sie gut, entspannt euch und denkt darüber nach. :)
Weihnachtsgedicht 2009
Vor ungefähr zweitausend Jahren
glaubt man, wurde ein Mann geboren
glaubt man, dass es Gottes Sohn gewesen ist
glaubt man, der uns alle erlösen sollte
Irgendwann später
dachte man, das wäre ein Grund, daran zu denken
dachte man, es wäre ein Grund, in sich zu kehren
dachte man, es wäre eine besinnliche Zeit
Heute jedoch
stresst man, um nur ja Geschenke für alle zu finden
stresst man, weil jeder überall mit einem feiern will
stresst man, um sich besonders gütig zu zeigen
Ich wünsche mir, dass
wir helfen, uns zurück zu erinnern
wir helfen, uns zurück zu besinnen
wir helfen, wieder ruhiger zu werden
Ich wünsche euch ein erlöstes, besinnliches, gütiges und ruhiges Weihnachtsfest!
Erschlagen von Release-kritischen Fehlern fuer stable
Andere machen es auch, daher hab ich mir überlegt, mach ich auch mit. Ich gehe es jedoch anders an. Oft genug behaupten die Leute, dass sich die Paketbetreuer nicht mehr um ihre Pakete kümmern, wenn sie in stable gelandet sind, da sie sagen, dass es nicht einfach sei, Pakete in stable zu aktualisieren. Und obwohl das zum Teil wahr ist, hinterlässt es keinen guten Eindruck, eine hohe und steigende Anzahl an release-kritischen Fehlern für stable zu haben.
UDD macht es einfach. Es gibt das Feld affects_stable in der bugs-Tabelle, und die Sicht bugs_rt_affects_stable ist sogar noch angenehmer. Ich hab mir zwei kleine Abfragen zusammengestellt, die mir helfen, release-kritische Fehler für stable zu finden:
SELECT b.id FROM bugs_rt_affects_stable bas
LEFT JOIN bugs b ON bas.id=b.id
WHERE b.severity IN ('serious', 'critical', 'grave')
AND b.id NOT IN (select bau.id from bugs_rt_affects_unstable bau)
ORDER BY b.id;
Die zweite Abfrage ist die selbe jedoch ohne dem AND-Teil und zeigt alle offenen release-kritischen Fehler. Diese Liste durchzugehen ist nicht allzu schwierig, und ich habe bereits eine nette Menge an Fehlern gefunden, die man als nicht-stable-betreffend markieren kann, da der Grund für den Fehler erst nach dem Lenny-Release aufgetaucht ist. Ich könnte die einzelnen Fehlernummern aufzählen, aber es sind seit gestern bereits 39 solche Fehler und ich will euch nicht damit langweilen, genau genommen hab ich das Paket nichtmal angreifen müssen – aber es wird es auf jeden Fall einfacher machen, die tatsächlichen release-kritischen Fehler die stable betreffen zu finden und in Angriff zu nehmen.
Immer noch viel zu tun, 39 erschlagene Fehler sind nicht die Welt, wenn die Hürde auf ungefähr 1500 gestellt ist. Jedoch sind es trotzdem mehr als 2% und das ist etwas, das mich schon ein wenig freudig stimmt.
wenn Leute nach Debian mit einer @ubuntu.com E-Mail-Adresse hochladen
sogar besser noch, wenn sie es tun auch wenn sie DDs sind (und daher eine @debian.org Adresse besitzen)
Ja! Tatsächlich zeigt das nämlich mehrere Dinge: Dass die Zusammenarbeit zwischen Debian und Ubuntu tatsächlich funktioniert. Dass jene Leute, die sich eher Ubuntu zugehörig fühlen, sich trotzdem auch um Debian kümmern. Und dass diese Leute begonnen haben zu erkennen, dass das Zurückführen von Änderungen an Debian sogar ihre eigenen Arbeitseinsatz reduzieren, da sie keine getrennten Patches betreuen müssen, mit dem Nutzen für alle beteiligten Parteien.
Daher ein riesen großes Danke an die Leute, die es schaffen, über den Tellerrand zu blicken und die größeren Auswirkungen zum Nutzen von allen erkennen können!
Es ist großartig zu sehen, wie sich die Zusammenarbeit zwischen Debian und Ubuntu verbessert; und ich sage das nicht nur, weil es im Debian/Ubuntu Games Team vermutlich nicht mehr viel besser geht, wir haben Leute von beiden Distributionen, die im Team zusammenarbeiten und die meisten der Pakete haben dadurch keine Ubuntu-spezifischen Patches (mehr).
Tatsächlich hat mich der Umstand, dass die Dinge in diesem Bereich sehr gut laufen, dazu gebracht mir zu überlegen, mich als MOTU zu bewerben. Um das zu werden, muss man den Ubuntu-»Code of Conduct« (CoC, Verhaltensleitfaden) unterschreiben, der tatsächlich ein sehr gutes Dokument ist. Ich würde mir wünschen, dass es in Debian etwas ähnliches gäbe, das als verbindlich erachtet wird, es würde durchaus einige harte und grobe Zeiten verringern. Es dreht sich um und erklärt mit Bedacht zu handeln, respektvoll zu sein, zusammenzuarbeiten, was man tun soll, wenn man anderer Meinung ist, wenn man unsicher ist und wie man sich rücksichtsvoll zurückzieht. Wenn diese Prinzipien in allen Gemeinschaften zur freien Software gelebt werden würden (und ich meine wirklich gelebt und nicht nur vorhanden und veraltet) denke ich, dass sich neue Personen viel willkommener fühlen würden. Und es ist nicht allzu schwer, seinen Teil beizutragen (... sagt die Person, die sich kürzlich für ihr Verhalten entschuldigen musste).
Wie auch immer, es gibt diese eine Stelle in dem CoC die mich stört. Es liegt nicht daran, dass man ihn mit seinem GnuPG-Schlüssel signieren muss, aber es hängt damit zusammen. Die Notwendigkeit, ihn zu signieren, gibt dem Dokument einen offizielleren Charakter, genau genommen gibt es ihm das Gefühl, ein Vertrag zu sein und ich denke mir, dass es auch so gemeint ist, dieses Gefühl zu transportieren. Jedoch gibt es einen Teil, den ich in solch einem Dokument für deplatziert halte:
Niemand weiß alles, und von Niemandem in der Ubuntu-Gemeinschaft wird erwartet, perfekt zu sein (außer natürlich vom SABDFL).
Da das Akronym SABDFL sich auf Mark Shuttleworth bezieht bedeutet dies, dass man von ihm Unfehlbarkeit zu erwarten hat – was ich leider nicht unterschreiben kann. Ich erwarte das von niemandem außer mir selbst, selbst Mark ist nur ein Mensch und kann Fehler machen. Und obwohl es klar ist, dass es eine ironische Witzelei ist, die eventuell dazu da ist klar zu machen, dass die Ubuntu-Gemeinschaft keine sterile Angelegenheit ist, ist es einfach eine extrem schlechte Idee, das in ein Dokument zu packen, das man von den Mitwirkenden unterzeichnet haben will.
Es tut mir Leid, Ubuntu, aber solange dieser Witz Teil des CoC ist, kann ich ihn nicht mit ruhigem Gewissen unterschreiben, egal wie sehr ich das auch tausendmal für den Rest machen würde. Ich frag mich ehrlich, wieviele andere den »Vertrag«, den sie unterzeichnen, auch tatsächlich sorgfältig durchgelesen haben oder ob es ihnen andererseits einfach nur egal war. Es gibt zu viel Webseiten-Registrierungszeug da draußen, das ebenfalls niemand liest.
In meinem letztem Blog-Eintrag hab ich den Begriff »Bild-Hack« verwendet. Es scheint, als ob es mit einem negativem Eindruck behaftet ist. Obwohl ich es für sehr amüsant halte, dass das in einer Gemeinschaft passiert, die mit stolz geschwellter Brust den den Begriff »Hackers« für sich verwendet, kann ich es verstehen, warum es manche Leute als negativ empfinden. Selbst obwohl rein technisch gesehen eine Überarbeitung einer Website im Bild-Format sich tatsächlich wie ein unbeholfener Hack anfühlt, war es nicht als Geringschätzung davon gemeint, was pixelgirl geschaffen hat. Ihr Bild-Hack sieht extrem gut aus.
Unglücklicherweise kam kein weiterer Kontakt nach der Debconf zustande und ich bin persönlich nicht davon überzeugt, wie das kleine Bild für andere Seiten neben der Einstiegsseite funktionieren sollte – und die DSAs und Neuigkeiten von der Einstiegsseite zu entfernen wird nicht passieren, wir bekommen dafür durchaus positive Rückmeldungen. Daher ist es, was es ist, ein Bild-Hack. Ein extrem gut ausgeführter, aber trotzdem genau das.
Wie ich in einem früherem Blog-Eintrag geschrieben habe, arbeite ich daran, Kalles Debian-Redesign vorzubereiten, um es getestet und installiert zu bekommen. Obwohl einige unglückliche Ereignisse passiert sind, die mich meinen Einsatz überdenken ließen, und sich für mich viele Dinge geändert haben, halte ich nach wie vor an dem Vorhaben fest. Hauptsächlich, weil ich nicht zum Mitglied des Webteams wurde, um beim geringsten Problem aufzugeben, aber ebensowenig, weil ein weiterer Bild-Hack aufgetaucht ist, der weder etwas verwendbares verwendbares noch allumfassende Gedanken oder tatsächlichen Code/Konzepte zeigt oder überhaupt versucht hat, sich mit dem Webteam in Verbindung zu setzen.
Ich erinnere mich lediglich daran, positive Rückmeldungen erhalten zu haben, in die ich ebenfalls kleine Änderungsvorschläge einrechne, wie dass die Abschnitte zu exakten Treffern und anderen Treffern auf der Paket-Seite nicht so klar abgetrennt sind wie zuvor. Ich habe diese Dinge natürlich an Kalle weitergeleitet und wir suchen nach einer Lösung, die zum Stil passt. Wenn ich schon die Paket-Seite anspreche, ich hab es endlich geschafft, die Pakete aus dem Kernpool auch angezeigt zu bekommen, wodurch sie sich in dieser Beziehung nicht mehr von der alten unterscheiden sollte (wie z.B. beim gut verteilten wesnoth-Paket zu sehen sein sollte).
Der nächste Schritt, den ich in den vergangenen Tagen geschafft habe, war das Aufsetzen einer Testsite für www die ihr auf www.deb.at finden könnt. Bitte beachtet, dass ihr euch diese Site in Englisch ansehen solltet (entweder durch's Ändern eurer Accept-Language Einstellung oder das Klicken auf English am Ende der Seiten), da einige der Änderungen nur dort sichtbar sind; die Hauptseite zum Beispiel sieht in anderen Sprachen sehr unterschiedlich aus.
Wie geht's nun weiter? Kalle hat auch Vorschläge für die Fehlerdatenbank und Planet, daher sind diese Ziele die offensichtlichen nächsten Schritte. Ich kann noch nicht abschätzen, wann es soweit sein wird, weil das davon abhängt, wie kompliziert es ist, Umgebungen dafür aufzusetzen, aber ich werde auch auf dem Laufenden halten.
Seit ich von der diesjährigen Debconf zurückgekehrt bin, haben sich viele Dinge in meinem Leben geändert. Eines der Dinge, die mir schon vor der Debconf bekannt waren, war mein Jobwechsel. Ich habe eine sehr lange Zeit (und auch großartige Zeit) bei Silver Server verbracht, für weit über 6 Jahre. Nun kommt es drauf an, was ich in und für meine neue Arbeit machen kann. Ich bin nach wie vor erst recht kurz dort und beginne langsam zu verstehen, was vorsich geht (und was in einigen Abläufen Verbesserungen gebrauchen könnte), aber es ist noch zu früh, das genauer festmachen zu können.
Als kleine Nebennotiz hat es der Wechsel meiner Arbeit notwendig gemacht, eine neue Nummer für mein Handy zu besorgen, da die alte eine Firmennummer war. Ich habe nun eine private, die ich wohl nicht mehr verlieren werde. Falls ihr die Zahl 3933309527644 von meiner alten Handy-Nummer abzieht, erhaltet ihr meine neue. Andererseits könnt ihr mich auch gerne fragen, falls ihr meine alte hattet und euch wundert. ;)
Neben meiner Handy-Nummer haben sich auch andere kleine Dinge im Laufe der Zeit geändert. Die meisten haben es wohl bemerkt, dass ich weder meine @ist.org noch meine @debian.org Adresse verwende, da sie den falschen Spitznamen getragen haben. Und da sowieso gerade alle ihre GnuPG-Schlüssel umstellen, habe ich das auch getan. Wie auch zuvor hab ich getrennte Schlüssel für zur privaten Verwendung und zur Verwendung für Debian erstellt. Ich folge nicht wirklich dem Ablauf, Aufrufe zum Signieren an Leute zu verschicken, die meine(n) alten Schlüssel bereits signiert haben, da ich das selbst auch nicht mache und es nicht von anderen erwarte. Die Schlüssel sind jedoch zur Sicherheit mit den alten kreuzweise signiert, um im Web-of-Trust keine Verbindungen zu verlieren.
Außerdem hab ich mich endlich dazu durchgerungen, meinen eigenen ejabberd-Server aufzusetzen und mir eine neue Jabber-Kennung zu erstellen, die ich behalten werde. Sie ist gleich meiner privaten E-Mail-Adresse, die im obig verlinkten Schlüssel zur privaten Nutzung zu sehen ist. ;) Einer der Gründe für den Server ist es übrigens, als Testumgebung für die Paketierung von ejabberd zu dienen, die mit dem nächsten Upload unter Team-Betreuung gestellt wird und die kommende Upstream-Version 2.1 sein wird.
Aber die größte und wichtigste Änderung in meinem Leben ist etwas, das mich dazu bringt, die Verwendung meiner Freizeit komplett zu überdenken, da es ungefähr ab März nächsten Jahr etwas geben wird, das viel Zeit einfordern wird. Eine extrem glückliche Änderung und beinahe genauso freudige, obwohl sie bedeutet, dass es mir nicht möglich sein wird, nächstes Jahr der Debian-Konferenz in New York beizuwohnen, aber ich hoffe, dass die Leute, zu denen ich gemeint hatte, dass ich dort sein werde, wegen dieser Ankündigung nicht zu enttäuscht sein werden. Tut mir Leid! :)
Ich bin extrem unrund. Nicht wegen einer Release-Team-Ankündigung die, wenn man bereits nach dem Interview mit Mark Shuttleworth mitgedacht hätte, schon damals klar war. Es wurde davon gesprochen, vermutlich das Debian-Release mit dem Ubuntu-LTS-Release abzustimmen. Es ist kein großes Geheimnis, dass das nächste Ubuntu-LTS-Release 10.04 sein wird. Und wenn man davon zurückrechnet, ist das Freeze im Dezember einfach nur die offensichtliche Konsequenz daraus.
Was mich jedoch wirklich unrund macht, war Agnieszkas Redesign-Vortrag. Nur um eine Sache gleich klar zu stellen, ich gratuliere ihr zu was sie produziert hat. Es sieht definitiv gut aus und die Reaktionen während dem Vortrag haben das eindeutig gezeigt.
Jedoch gibt es einige Dinge in dem Zusammenhang, die mich dazu bringen, drüber nachzudenken, mich vom Webteam zurückzuziehen und die wertvolle Zeit, die ich in Debian investiere, zu reduzieren. Der Grund mag nicht ganz so klar sein, aber es gibt dazu einige sehr interessante Daten:
Agnieszka hat sich bei Sledge für seine gute Hilfe bedankt. Dadurch war sich zumindest ein Teil des DPL-Teams ihrer Arbeit bewusst. Vor einigen Wochen hat mich Luk, die andere Hälfte des DPL-Teams, in Ausübung seines Amtes angeschrieben, dass sie einige Mails erhalten haben, die gerne einen Fortschritt bei den Webseiten sehen würden. Ich habe Luk gesagt, dass ich bereits daran arbeite, Kalles Vorschlag einzuarbeiten. Er hat sich sehr darüber gefreut und hat sich bedankt und mir alles Gute für den Fortschritt gewunschen, aber weder er noch Sledge haben mir gegenüber Agnieszkas Arbeit erwähnt.
Agnieszka hat sich auch bei stockholm für seine Hilfe bedankt. Stockholm ist Teil des »Marketing«-Teams (ja, es wurde vor zwei Jahren eines gegründet; habt ihr nicht all die hervorragende Arbeit des Teams bemerkt??). Wie auch immer, irgendwann hat stockholm von meinem Einsatz erfahren und ist in #debian-www im IRC aufgetaucht. Er fragte nach dem neuem Design und wer dran arbeite, ich hab ihm gezeigt, was zu der Zeit bereits da war und alles, was er sagte war »Cool«. Und schon wieder keinerlei Erwähnung von Agnieszkas Arbeit.
Wie ich gestern bereits geschrieben habe, bestanden fast alle eingeschickten Vorschläge lediglich aus Bildern (falls es überhaupt mehr als eines gab), über die man schwerlich entscheiden kann – speziell wenn sie so klein und nicht gut sichtbar sind wie in dieser Präsentation. Fragen in Richtung ob das überhaupt umsetzbar wäre, wurden mit dem magischen Wort CSS erschlagen; unglücklicherweise kann CSS nicht zaubern. Und mit Bildern ist es schwer zu entscheiden, ob es überhaupt für barrierefreien Zugang und die anderen Dinge funktionern könnte, die ich bereits gestern erwähnt habe.
Wir versuchen sehr vorsichtig, dass wir nicht doppelte Arbeit beim Paketieren produzieren, indem wir ITPs schreiben. Großartig! Wir versuchen ein paar wenige Stunden an Arbeit zu vermeiden in einem Bereich, wo wir weit über tausend Mitstreiter haben. Aber es scheint angebracht zu sein, Tage, Wochen, Monate an investierter Zeit, Anstrengungen und Energie in einem Bereich zu verwerfen, in dem wir ein ernsthaftes Problem haben, Mitstreiter zu finden.
Genau so muss es sein, Debian. Sehr enttäuscht, sehr genervt, sehr demotiviert.
Ihr werdet vermutlich nicht die debian-www-Mailingliste verfolgen, aber von Zeit zu Zeit gibt es Leute, die unseren Webseiten gerne ein neues Gesicht verpassen würden. Die überwiegende Mehrheit wird jedoch nur eine Vorlage in einem Zeichenprogramm produziert, ohne zu erkennen, dass mehr dahinter steckt, in Bezug auf Übersetzungen und Unterseiten und Barrierefreiheitsbedürfnisse. Jedoch sind die meisten Leute gleich wieder weg, wenn man diese Dinge erwähnt.
Dann kam Kalle Söderman. Er hat einen Blick hinter die Kulissen geworfen, für sich selbst bereits 2007 begonnen dran zu arbeiten, es bemerkt, dass es nicht nur www.d.o gibt sonder auch packages.d.o (oder eher wesnoth als Beispiel), wiki.d.o, planet.d.o, bugs.d.o und auch andere. Er begann daher, über etwas nachzudenken, das service-übergreifend funktionieren könnte, und hat tatsächlich mit dem Code gearbeitet und nicht nur einem Zeichenprogramm. Und selbst obwohl er nicht viel Rückmeldungen erhalten hat, als er es erstmals angekündigt hat, ließ ihn die Idee nicht los.
Das hat es geschafft, mein Interesse zu wecken und ich habe überlegt, wie man von diesem Punkt aus weitergehen könnte. Ich bin mit ihm in Verbindung getreten und habe einige Mails über seinen Vorschlag mit ihm gewechselt und begonnen, ein paar kleine Test-Seiten aufzusetzen (ich wiederhole: Test-Seiten. Sie sind noch nicht fertig, genausowenig wie Kalles Entwürfe fertig sind), und dies ist der Punkt, an dem wir uns im Augenblick befinden: Auf packages.deb.at/wesnoth könnt ihr einen Klon von unserer pkg.d.o-Seite sehen, die seine Vorlagen verwendet, tauscht gerne wesnoth mit eurem bevorzugtem Paket aus – ich möchte jedoch anmerken, dass es seine Daten weder regelmäßig aktualisiert bekommt, da ich nicht möchte, dass die Leute diese Seite statt die Hauptseite verwenden, und dass sie derzeit irgendwie keinerlei Pakete aus dem Hauptarchiv anzeigt sondern nur jene der externen Quellen. Sie existiert nur, um die Idee dahinter zu transportieren.
Und wir haben ebenfalls ein funktionstüchtiges Theme für's wiki das direkt dort auch funktioniert (der Dank dafür gebührt Paul Wise, der den Teil installiert hat, der am Server selbst vorhanden sein muss): Folgt dafür der Anleitung auf Kalles Seite zum Wiki, falls ihr es verwenden wollt.
Ich bin gerade dabei, eine Testumgebung für bugs.d.o und www.d.o aufzusetzen; für letzteres muss ich mich bei Martin Zobel-Helas bedanken, der mich angestoßen hat und ein System zur Verfügung stellt, auf dem ich das tun kann (selbst wenn er ursprünglich nichts davon wusste, dass ich es zum Testen des Themes misbrauchen würde ;)). Im Augenblick könnt ihr euch Kalles Gedanken auf seiner Seite über seinen Vorschlag ansehen gemeinsam mit einigen Seiten als Beispiele, aber ich werde euch über größere Änderungen zu dem Thema hier informieren.
Die Arbeit, die ich hinein gesteckt habe, dreht sich primär darum herauszufinden, wieviel tatsächlich notwendig ist, um solch eine Umstellung durchzuführen, und auch weil mir gefällt, was Kalle fabriziert hat. Er hat viel Zeit investiert und ich denke, dass das Ergebnis es durchaus rechtfertigt, das ganze breiter bekannt zu machen. Anders als bei anderen Bereichen sind die Dinge hier noch nicht in Stein gemeißelt, worüber sich auch Kalle im klaren ist, aber es muss nun mal irgendwo anfangen. Genießt es, schickt (konstruktive) Rückmeldungen (wie zum Beispiel Die Unterscheidung auf dem neuen pkg.d.o-Vorschlag zwischen Genauen Treffern und Anderen Treffern ist nicht klar genug ersichtlich!) und erkennt an, dass andere Dinge tun, vor denen viele Leute in den letzen Jahren davon gelaufen sind.
Am Montag gab es extrem starke Regenfälle. Umso erstaunlicher war es, dass ich beim Heimfahren in der Nacht den Mond so schön und klar sehen konnte. Er hat mich dann zu folgenden Haikus motiviert, die ich hiermit mit euch teilen will:
full moon shining down
it is calming and peaceful
even when cloudy
in all its silence
not much that matters and counts
giving you comfort
just watch its bright light
it does not care for others
think about yourself
Ich denke, ich hab gerade das seltsamste Problem, das ich je erlebt habe. Es ist mir nicht möglich, @ oder € (oder eine andere Taste, die den Alt-Gr-Umschalter auf der deutschen Tastatur benötigt) in iceweasel, evolution, pidgin, gucharmap einzugeben, jedoch kann ich es ohne Probleme in anderen Anwendungen eingeben, die ich ausprobiert habe (kword, OpenOffice.org, abiword, gvim, urxvt, xpdf) auf einem aktuellem squeeze-System.
Falls irgend jemand eine Idee oder Hinweis hat, was die Ursache dafür sein könnte, wäre ich sehr dankbar!
Ziemlich interessant. Twitter hat diesen kurzen Text auf seiner Registrierungsseite: By clicking on 'Create my account' above, you confirm that you are over 13 years of age and accept the Terms of Service. (Übersetzung: Durch das Klicken auf 'Erstelle mein Konto' oberhalb bestätigen Sie, dass sie über 13 Jahre alt sind und den Geschäftsbestimmungen zustimmen. Zumindest im Augenblick führt ein Klicken auf den Link auf eine Seite, auf der steht: Something is technically wrong. (Übersetzung: Etwas ist technisch falsch. Es freut mich sehr, das zu bestätigen, aber ich habe das ungute Gefühl, dass es nicht beabsichtigt ist, das dort stehen zu haben ...
Es ist immer wieder erfreulich, wie manche Leute glauben, dass Debian funktioniert. Oder auch nicht. Es scheint immer häufiger zu werden, dass die Leute statt einen Fehler zu melden es für passend empfinden, sich in ihren Blogs darüber auszulassen. Das wird die Dinge natürlich reparieren und beheben und jeden, der damit zu tun hat, motivieren um an der Sache zu arbeiten, von der sie aus dritter Hand erfahren. Und natürlich ist es absolut in Ordnung, eine Anwendung direkt zu ändern, dpkg-divert oder ähnliches nicht zu verwenden und sich dann wild drüber auslassen, wie unfair es ist, dass ein Upgrade des Pakets die Datei ersetzt.
Und, Andrew, es gab kein DSA für CVE-2008-2236, weil es als ein zu geringes Problem erachtet wurde. Danke für den Fisch. Hast du übrigens die Version des kommenden Lenny-Releases getestet? Es ist ja nicht so, dass diese wegen Abhängigkeiten nicht direkt in Etch installierbar wäre ...
Nur einmal würde ich drauf hoffen dürfen, dass Leute, die tief in Debian involviert sind (wie z.B. Debian-Entwickler oder langzeitige Mitwirkende zu sein) die Dinge wie zufällige Benutzer angehen: die Dinge melden, die sie nerven, selbst wenn sie so gering und seltsam wie einige der Fehlerberichte sind, die ich für wesnoth erhalte.
Ich widme dieses alte aber extrem großartige Lied allen Leuten in Debian, die es lieben, alles und jedes solange zerreden, um sich dann als Sieger darzustellen, da kein anderer mehr antwortet, weil es keinen Sinn mehr macht: Du vastehst mi ned (»Du verstehst mich nicht«)
Am vergangenen Wochenende hat backports.org zwei weitere Dienste bekommen, die dabei helfen zu verfolgen, was sich tut. Ich führe sie in zeitlicher Abfolge auf:
Verfolgung von Sicherheitsproblemen in Backports-Paketen: Es war eines der vielen Themen, die beim Security-Team-Meeting in Essen am Ende des vergangenen Monats besprochen wurden und Florian Weimer hat eine erste Version der Verfolgung von Sicherheitsproblemen in backports.org umgesetzt. Sie vergleicht im Augenblick nur die zurückportierte Version gegen die in Unstable reparierte, daher enthält die Liste durchaus einige fehlerhaft als Positiv angezeigte Pakete (z.B. libspf2, da die Reperatur von lenny-security genommen wurde), aber es ist trotzdem ein riesen Schritt nach vorne und hilft auch dabei, die noch offenen Probleme nicht zu vergessen.
Unterschiede zwischen Etch-Backports und Lenny: Etwas ähnliches war bereits an anderen Plätzen vorhanden, ist aber seltsamerweise eingestellt worden. Hier könnt ihr sehen, welche Pakete in backports älter (nur die Debian-Überarbeitung unterscheidet sich), veraltet (eine neue Upstream-Version befindet sich in Lenny), neuer sind (von Unstable zurückportiert?), ein falsches Versions-Schema verwenden oder in Lenny nicht verfügbar sind (eventuell sogar aus Unstable gelöscht wurden). Die Seiten werden den Leuten hoffentlich helfen, ihre Backports abzugleichen. Zumindest ist es eine Messung dafür, wie gut auf diese Pakete geschaut wird.
Ich hoffe, sie erscheinen euch genauso hilfreich wie mir, selbst wenn es klarerweise noch Platz für Verbesserungen gibt. Aber sie sind beide bereits ziemlich hilfreich in ihrem aktuellem Zustand, das sollte euch daher nicht davon abhalten, sie zu verwenden. :)
Für lange Zeit wurde es als schlecht angesehen, Quellcode unter einer Freiheit gebendenLizenz zu veröffentlichen. Was, wenn Leute den Code verwenden und ihn wiederverwerten? Was, wenn ich nicht damit einverstanden bin, wie sie ihn wiederverwerten?
Die Vergangenheit hat gezeigt, dass dies nur in sehr seltenen Fällen passiert. Und selbst dann ist die Wiederverwertung eures Codes eine Huldigung eures Werkes. Die Leute begannen das zu verstehen und es wurde glücklicherweise zu einem sehr verbreiteten Verhalten.
Aber es sieht so aus, als ob sich die Geschichte von Anfang an erneut wiederholen zu versucht, der Bereich ist jedoch ein anderer. Nun sehen sich Grafiker und insbesondere Musiker mit den selben Ängsten konfrontiert. Aber ich glaube nicht, dass ich die Person sein sollte, die darüber schreiben soll, da ich weder noch bin (nun, recht wenige Leute betrachten ASCII-Art als richtige Kunst. Vermutlich sogar weniger als jene, die guten Code als Kunst ansehen ...). Das Gute dabei ist, dass ich das nicht mal muss. Einer der Grafiker aus dem Wesnoth-Umfeld hat es getan, und das weitaus besser als ich es je geschafft hätte, die Idee dahinter rüberzubringen. Daher: Jetryl über die GPL-Richtlinie in Wesnoth. Es ist zwar lang aber nichtsdestotrotz definitiv wert gelesen zu werden und ich hoffe, dass es einige Leute dazu bringen wird, es besser zu verstehen und weniger Angst zu verspüren.
Wow, ich kann mich nicht mal mehr daran erinnern, wann ich das letzte Mal über einen Kinoabend gebloggt hatte. Zugegeben, ich war in den vergangenen Monaten auch nicht so häufig, aber ein paar Filme hab ich trotzdem nicht erwähnt ... Wie auch immer.
Gestern war ich wieder im Kino, und wir haben uns »The Dark Knight« angesehen. Um ehrlich zu sein bereue ich es, das getan zu haben. Der Film ist in seinem Plot so düster wie der Titel sugeriert, sogar düsterer als es in den vergangenen Batman-Filmen üblich war. Sie haben Batman auf James Bond adaptiert, Morgan Freeman auf Q sowie billige Eminem-Zitate verwendet. Es tut mir um Heath leid, dass dies der letzte Film war, in dem er mitgearbeitet hatte. Selbst seine super Leistung schaffte es nicht, den Film zu retten, und es ist traurig, dass dies der Film sein soll, mit dem die Leute an ihn denken werden ... Du hast besseres verdient, Kumpel.
Letzte Woche hab ich mich gefragt, wieviel Platz eine komplette Git-Umstellung tatsächlich benötigen würde – und ich war ziemlich überrascht:
$ du -hs webwml*
325M webwml
416M webwml.git
819M webwml.svn
Die erste Zeile ist der reguläre CVS-Checkout. Die dritte Zeile ist der SVN-Checkout der auf alioth verfügbar ist. Man sieht recht leicht, dass die Größe nicht wirklich etwas ist, das man möchte, insbesondere da der wirkliche Nutzen sehr gering ist: Neben der Möglichkeit, offline diffs zu generieren, hat man Nachteile darin, dass man nicht viel offline durchführen kann, da alles, was die Historie betrifft, voraussetzt, dass man Online ist. In CVS weiß man zumindest, dass die Revision 1.12 einer Datei drei Commits nach der Revision 1.9 der selben Datei passiert ist; in SVN gibt es Offline keine Möglichkeit herauszufinden, wieviele Commits einer Datei zwischen Revision 512 und 1024 liegen, falls überhaupt welche.
Die Konvertierung nach Git brauchte sehr lange, hat praktisch drei Tage von (nicht-durchgehendem) Laufen von git-cvsimport auf meinem Laptop benötigt. Die Zeit hat mich nicht absolut überrascht, zumindest nicht wie ich am Ende gesehen habe, dass hier deutlich über 83tausend Commits in mehr als 10 Jahren passiert sind, zurückgehend bis Juli 1998. Mein erster eigener Commit war im Juli 2001, was mit Git nicht sonderlich schwierig war herauszufinden, und nicht voraussetzt, dass man Online ist.
Git gibt euch kompletten Offline-Zugriff auf die Historie. Das ist etwas, auf das der Build-Prozess durchaus aufbauen kann. Es wird vermutlich etwas langsamer werden, da man keine einfache Mathematik mehr für den Unterschied von Revisionen anwenden kann wie im CVS, aber das muss zunächst mal tatsächlich geprüft werden. Ich glaube durchaus daran, dass es es wert ist, alles durchführen zu können, ohne seltsame Hacks zu benötigen oder der Notwendigkeit, Online sein zu müssen.
Dinge, die noch zu tun sind, für die ich aber in der nahen Zukunft nicht die Zeit haben werde, weil ... erm, ihr wisst schon? Lenny? Dass wir ein Release haben wollen? Aber wie auch immer, damit es nicht verloren geht, hier eine (unvollständige) Liste der Dinge, die zu tun sind, falls euch fad ist und ihr euch ein wenig spielen wollt:
Die verschiedenen Skripte anpassen, damit sie SHA1-Summen statt CVS-Revisionen prüfen.
Die translation-check translation="" in allen Dateien auf SHA1-Summen anpassen.
Prüfen, ob ein kompletter Website-Build nach den Änderungen noch funktioniert.
Herausfinden, wie Submodule funktionieren und ob diese sinnvoll für die Sprach-Unterverzeichnisse angewendet werden können, damit Übersetzer mit teilweisen Checkouts arbeiten können.
... andere Dinge, die ich vergessen habe, aber zur Wiki-Seite WebsiteVCSEvalutaion hinzugefügt werden können.
Ihr wollt euch ein wenig spielen? Nun, ihr müsst den gesamten git-cvsimport nicht selbst durchführen: Ich habe mein webwml.git Repository nach alioth repliziert: »git clone git://git.debian.org/git/users/alfie/webwml.git« sollte euch eine Starthilfe sein. Bitte beachtet, dass ihr euch wohl in einem extra Branch spielen wollt und nicht direkt in origin, um gegebenenfalls weiterhin von Zeit zu Zeit Updates zu ziehen.
Ich freu mich ja schon graume Zeit auf das heurige Two Days A Week-Festival. Genau genommen seit ich das erste Plakat davon gesehen habe und darauf den Namen einer meiner Lieblingsbands gefunden habe: Live. Ich hab die Jungs aus den USA schon ewig nicht mehr gesehen und freu mich daher riesig drauf, sie mal wieder auf der Bühne zu sehen.
Aber heute kam der nächste Schock: Nachdem vor ein paar Tagen Slipknot wegen einer Verletzung eines Bandmitgliedes absagen mussten, gibt es inzwischen einen mehr als nur adäquaten Ersatz: Apocalyptica!!!! Wiesen, ich komme!
scons behauptet, ein besserer Ersatz für make zu sein, oder insbesondere für die autofoo-Magie. Unglücklicherweise ist es das nicht. Zu einem ordentlichen Build-System gehört es, dass es hinter sich selbst aufräumen kann. Die Gründe, die herumgereicht werden um zu erklären, warum es das nicht tun kann, sind ziemlich witzig, sie reichen von dass es nicht weiß, was es generiert (wie generiert es sie dann überhaupt?) bis zu seiner Erweiterbarkeit und dass es es daher nicht sauber durchführen kann (dann sind die Erweiterungen kaputt und sollten ihre Säuberungsinformationen ebenfalls einhängen). Ich habe noch keine gültige Begründung gesehen, warum es es nicht tut – und trotzdem müssen wir den herumliegenden Müll wie .scons* Dateien und Verzeichnisse, config.log und natürlich das build/ Verzeichnis selbst entsorgen.
Leute, wenn ihr wirklich ein ordentliches Build-System erstellen wollt, vergesst nicht darauf, dass es auch hinter sich selbst aufräumen können soll. Es sollte nicht die Aufgabe der Anwendungsentwickler sein, das zu reparieren (was nicht wirklich funktioniert, da ein scons-Target, das die Dateien löschen wollen würde, scons zum Abstürzen bringt).
![[rss feed]](/pics/logo-xml.png){kind=logo}
![[html by vim]](/pics/logo-vim.png){kind=logo}
![[graphics by gimp]](/pics/logo-gimp.png){kind=logo}
![[generated by wml]](/pics/logo-wml.png){kind=logo}
![[powered by blosxom]](/pics/logo-blosxom.png){kind=logo}