Archiv des Autors: Ferdinand Thommes

Vorbereitung auf 2012.2

Wie ihr bestimmt schon erraten habt, wenn ihr gelegentlich unser Forum besucht, ist ein neues Release in der Mache. Was wir bis jetzt haben ist ein Name. 🙂 Auch wenn sid wegen des Freeze ziemlich zahm ist, nennen wir es „Riders on the Storm“, geborgt von dem letzten Doors Album „LA Woman“. Danke, daß ihr euch an der Abstimmung in unserem Forum beteiligt habt. 2012 wird noch 2 Veröffentlichungen und zwei neue Desktop-Umgebungen sehen. Gut, nicht ganz richtig, da eines keine Desktop-Umgebung ist, sondern ein Release, dem genau diese fehlt. Es wird No-X heißen und das beschreibt es ziemlich genau. Das andere wird (hört, hört) Gnome werden, wohl in Version 3.6.x. Wir alle wissen, daß Gnome letzthin eine höllisch gute Zeit mit den Versuchen verbringt, sich selbst überflüssig zu machen, mit dem letzten und größten von Herrn Miguel de Icaza durch das Erwecken der allerbesten Flame-Monster.

Nichtsdestotrotz gibt es User, die das Flavour Siduction-Gnome haben wollen und sie werden es bekommen… Convbsd  ist zum Team gestoßen, um dies zu ermöglichen. Wir halten weiterhin Ausschau nach einem zweiten Maintainer, der Convbsd hilft, dieses Flavour auf lange Sicht zu warten.

Während des Kern Team Meetings Sonntag Nacht konnten wir uns bis jetzt nicht ganz einigen, wann wir was veröffentlichen. Was wir sicher wissen ist, daß beide neuen Flavours ein Entwickler-Release haben werden, bevor sie permanent in unseren offiziellen Releasezyklus aufgenommen werden. Als einen groben Termin für das Release 2012.2 haben wir die Tage um Anfang November genommen.

Die Ferientage zwischen den Jahren werden ein Überraschungs-Release irgend einer Art zu Gesicht bekommen. Die Entwickler-Releases der beiden neuen Flavours werden bis Ende des Jahres erscheinen. Das Kern-Team-Metting in zwei Wochen wird genaueres zu den besagten Terminen ergeben.

Persönlich bin ich sehr gespannt auf das Erscheinen von Razor-QT 0.5 in den nächsten Wochen. Ebenso wartet Qupzilla 1.3.5 mit neuen Funktionen hinter der nächsten Ecke. Wenn alles soweit in Ordnung ist, wird Razor-QT mit einem der nächsten beiden Releases in die siduction-Familie integriert.

Was gibt’s sonst Neues? Ein User fragte danach, 3 seiner Lieblingswerkzeuge paketiert zu bekommen und in das Repo zu integrieren. Dies war eine gute Möglichkeit klar zu machen, daß wir nicht die Möglichkeiten haben, jeden Wunsch den ein User hat, zu paketieren. Dies ist der Grund, aus dem es unser (bisher wenig) User-Repository gibt. Wir leisten gerne Hilfestellung, wenn ein Benutzer Probleme hat, etwas zu paketieren, aber wir werden ihm das nicht abnehmen. Wir haben einfach nicht die Zeit dazu. Wenn eine größere Nachfrage nach einem Paket aus dem user repository entsteht, werden wir es in Augenschein nehmen und es eventuell langfristig in Extra übernehmen.

Also bitte füllt unser User-Repository mit Leben und redet im Forum darüber, damit wir ihm das Fliegen beibringen können. Wir sind offen für Fragen und Anregungen.

Nochmals Infrastruktur-Anpassungen

Unser 14-tägiges Kernteamtreffen letzte Nacht war erneut ausschließlich bestimmt durch die geplanten strukturellen Änderungen zur Verbesserung unserer Arbeitsabläufe und Vereinfachungen, die es unseren Benutzern leichter machen, sich zu beteiligen.

Wie in meinem letzten Blogpost erwähnt, wollten wir die Paketlisten in unser Buildsystem pyfll vereinfachen. Es brauchte ein paar Wochen der Diskussion um hier einen Kompromiss zu finden. Leute, die dies interessiert oder die unser Buildsystem privat nutzen, können den anstehenden Veränderungen im Log ab [21:08:57] folgen.

Das zweite Thema gestern Abend betraf die Repository Struktur und neue Repository Namen. Dies sollte alle Benutzer interessieren, denn es betrifft ihre sources.list.d/siduction.list.

Zunächst einmal: Keine Panik!

Wir haben bereits einige Tests durchgeführt, um auszuprobieren ob alte und neue Bezeichnungen gleichzeitig funktionieren. Das tun sie, so daß wir jetzt Links bereitstellen können von alt nach neu. Ihr als User braucht erst mal gar nichts zu tun, es wird einfach funktionieren. Aber natürlich könnt ihr, wenn ihr wollt, um auch in Zukunft auf der sicheren Seite zu sein. Neue Installationen werden natürlich die neuen Bezeichnungen benutzen.

Hier ist die überarbeitete Struktur:

  • base war bisher siduction benannt. Es enthält alle offiziellen siduction Pakete
  • community gibts nicht mehr, es wurde nie verwendet. (Bitte entfernt es aus eurer Liste, wenn ihr es drin habt)
  • extra ist neu und enthält alle Pakete, die nicht nach base oder user gehören. (Pakete, die wir für die Verbesserung von siduction bauen, Pakete welche (noch) nicht in Debian und nicht essentieller Bestandteil von siduction sind)
  • user ist für Pakete von erfahrenen Benutzern / Team-Mitgliedern, die ihre Pakete verteilen möchten (wie z. B. towos inkscape- und gimp- Pakete)
  • fixes enthält zeitweise Pakete, die in Debian kaputt sind, wenn wir einen schnellen Fix dafür haben. Unser zukünftiges Ziel ist, diese Patches upstream zu übergeben.
  • razor-qt wird in base aufgehen, sobald wir Razor-Qt zu unserem offiziellen Releasezyklus hinzugefügt haben.
  • experimental ist wohl selbsterklärend
  • experimental-snapshots ist nur ein Puffer für unseren Teamgebrauch (Benutzer sollten dies nicht in ihre Liste aufnehmen).

Die Repository Webseite enthält die richtigen Zeilen für eure Änderungen.

Das nächste Thema handelte ebenfalls von Repositories und dem Versuch zu definieren, wo die Paketquellen am sinnvollsten vorzuhalten sind. Für die base und extra Repositories ist dies klar unsere eigenen Infrastruktur (chili/git). Die Quellen unseres user Repositories sollten von unserer Infrastruktur getrennt gehalten werden. Der Grund ist, daß jeder in der Lage sein sollte, diese auf einfache Weise zu forken, zu paketieren und in anderen Projekten zu verteilen. Github scheint hier der benutzbare Weg zu sein. Es ist dafür ausgelegt, geforkt(abgespalten) zu werden. Alle Änderungen an geforkten Paketen sind nur einen merge weit weg, um zur originalen Quelle zurück portiert zu werden.

Das letzte Thema letzte Nacht war Jenkins. Es braucht mehr Zeit und Tests. Wir stimmen alle überein, daß es nicht dringend ist und die Letzte in der Linie unserer Verbesserungen sein muß. Wenn wir es aufgesetzt haben und voll verstehen, wie es arbeitet, wird es uns eine Menge Zeit sparen, indem es Dinge automatisiert, die wir im Moment per Hand erledigen.

Und noch ein anderes Thema: Die Zeit ist gekommen, um über einen Namen für unser nächstes Release nachzudenken, denn das Art-Team braucht Zeit, um die Release-art dafür zu entwickeln. Der Prozess, mit dem wir im Moment arbeiten (User übermitteln ihre Favoriten, das Team wählt den Gewinner durch Abstimmung), ist nicht wirklich flüssig und befriedigend, soweit es mich betrifft. Wenn jemand eine bessere Idee für diese wiederkehrende Routine hat, wären wir glücklich, davon zu hören. Auf der anderen Seite, wenn nichts großartiges kommt, werden wir die alte Methode noch einmal anwenden. Also seid auf die Ankündigung einer Wikiseite zu diesem Zweck gespannt.

Änderungen an der Infrastruktur

Weil nach dem Release vor dem Release ist, nehmen wir die Gelegenheit wahr, einige Teile unserer Infrastruktur zu zerbrechen und verbessert wieder zusammen zu setzen. Das Core-Meeting der letzten Nacht war komplett über die Unzulänglichkeiten, die wir fanden und wie sie zu reparieren wären.

Die erste diskutierte Veränderung war, wie unser Releaseprozess funktioniert. Bisher: Wenn wir veröffentlichen, warten wir, bis ein Debian Mirror Sync beendet ist und beginnen dann, unseren Schnappschuß zu bauen. Das lässt uns zwischen 2 Syncs 6 Stunden Zeit. Solange alles glatt geht, ist das so in Ordnung. Trotzdem könnten Probleme leicht ein Release verzögern. Außerdem haben wir mehr Geschmacksrichtungen als zuvor und werden vielleicht in Zukunft auch noch weitere hinzufügen, dann kann der Zeitrahmen ein Problem werden. Wir werden also einen Proxy-cache oder Mirror dazwischen schalten, um auf der sicheren Seite der Dinge zu sein. Sollten Probleme während des Build-Prozesses auftreten, können wir einen intakten Schnappschuss von vor 6 Stunden oder einem Tag vorher ohne viel extra Arbeit veröffentlichen. Hier muß noch diskutiert werden, welche Methode oder welches Werkzeug wir dafür benutzen.

Die zweite Veränderung betrifft die pyfll-Pakete-Listen selbst: Wir finden das, was wir von aptosid geforkt haben, in der Form nicht mehr länger brauchbar. Möglicherweise ist dies so, weil wir mehr Flavours haben als unser Vorgänger. Wir haben alle Situationen erlebt, wo wir uns nicht wirklich sicher waren, wohin wir ein Paket hinzufügen sollten oder dass wir bei einer bestimmten Liste nicht übereinstimmten. Das muß logisch und offensichtlich werden. Wo ein Paket hingehört, muß geradlinig und zweifelsfrei sein. Also ist eine Reorganisation dieser Listen notwendig. Bis zu unserem nächsten Meeting werden wir die letzte Nacht diskutierten Modelle überdenken. Wir kamen sehr viel näher an einen Kompromiss, als wir das vor einem Monat waren, wo ein Boxkampf ein schneller Weg zu sein schien, die Differenzen auszutragen. 🙂

Nicht zuletzt diskutierten wir die Struktur unserer Reopositories. Welche Pakete gehören in welches Repo? Haben wir zu viele oder nicht genug Repos und sind sie harmonisch danach benannt, welche Pakete sie beherbergen? Wir stimmten überein, daß wir ein oder zwei zu viele haben und ein wenig Umbenennen nötig ist. Unsere User werden nicht darüber stolpern, weil wir Links zur Verfügung stellen werden, um die sources.list intakt und arbeitsfähig zu halten.

Bevor ich’s vergesse: Wer das Log unseres letzten Meetings vor zwei Wochen gelesen hat, wird gesehen haben, daß wir zwei Teammitglieder ersetzt haben. Vibora und edhunter haben im Moment nicht die Zeit, um in unserem Kernteam mit zu arbeiten. Sie werden ersetzt durch hendrikL und Goingeasy9. Die Abstimmung dazu könnt ihr in unserem Log sehen. Danke an Vibora und edhunter für ihre gute Arbeit in den letzten paar Jahren. Euer Code wird in siduction lebendig bleiben.

Drucker-Reise ala Samsung

Nicht lange her kaufte ich für €55 einen schönen kleinen Samsung ML 1675 Laserdrucker. Er sollte mit dem Samsung Unified Linux Treiber arbeiten. Also googlete ich, ging zur Samsung Webseite, lud den Treiber herrunter und installierte ihn. Das brachte den Drucker nicht zum arbeiten. Das Cups Interface konnte den Drucker jetzt sogar nicht mehr erkennen. Ich lies die Dinge wie sie waren, es war spät. Am nächsten Morgen war mein dist-upgrade mit seltsamen Fehlermeldungen blockiert die sich als vom Samsung mfp-driver hervorgerufen erwiesen. Entfernen des Ganzen löste die Probleme.

Also, installiert nicht die Treiber von der Samsung Webseite, sie funktionieren nicht.

Ich grub ein bischen tiefer in Google und fand The Samsung Unified Linux Driver Repository. Hier sind die Schritte um jeden Drucker / Multifunktionsgerät, das auf diesen Treiber angewiesen ist, in sehr kurzer Zeit zum Laufen zu bekommen.

Öffnet eine Shell und werdet root:

su [ENTER]

root@siductionbox: cd /etc/apt/sources.list.d [ENTER]

root@siductionbox:/etc/apt/sources.list.d# touch Samsung_Printer.list && echo deb http://www.bchemnet.com/suldr/ debian extra > Samsung_Printer.list && wget -O –      http://www.bchemnet.com/suldr/suldr.gpg | apt-key add – ;  apt-get update [ENTER]

Das richtet das benötigte Repository ein und installiert den gpg-Schlüssel dafür. Danach möchtet ihr die Treiber installieren:

apt-get install samsungmfp-data samsungmfp-configurator-qt4 samsungmfp-configurator-data samsungmfp-driver samsungmfp-driver-4.00.39 printer-driver-splix

Dies wird nur die für den Drucker gebrauchten Teile installieren. Wenn das alles ist was ihr braucht, Drucker einschalten und freuen. Falls der Drucker noch nicht eingerichtet war, kann dies jetzt unter http://localhost:631 geschehen. Hier wählt ihr deen Treiber für Samsung ML 1670 aus.

Wenn ihr ein Multifuntkionsgerät habt, das auch scannen kann, braucht ihr noch etwas mehr Software. Benutzt ihr siduction ist der Benutzer sowieso Mitglied der Gruppe „lp“, es braucht also keine weitere Aktion. Solltet ihr eine andere Distribution benutzen, kontrolliert dies – als user- durch die Eingabe von:

devil@siductionbox:~$ groups [ENTER]

devil lp dialout cdrom floppy audio dip video plugdev users fuse scanner netdev

Ist lp vorhanden braucht ihr nur ein paar Zusatzpakete obenauf zu installieren:

apt-get install samsungmfp-scanner samsungmfp-scanner-sane-fix samsungmfp-scanner-sane-fix-multiarch

 Hinweis: Bevor ihr die letzten beiden Pakete installiert lest die Ausgabe von apt-cache show um zu sehen ob sie bei euch zutreffen.

 

Für ein kleines Druckaufkommen im SoHo taugt der Samsung ML 1675 Laserdrucker durchaus. Er ist schnell und hat ein sauberes Druckbild. Über Verbrauchsmaterialien (Toner) kann ich noch nichts sagen

Neuer Debian Mirror Redirector

Wenn ihr Euch die sources.list unseres neuen Release anschaut, seht ihr ein neues Schema in der debian list. Es basiert auf http://http.debian.net/debian. Das ist das Schema des neuen Debian Mirror Redirector, der einige Vorteile mit sich bringt. Er sucht nicht nur den schnellsten Mirror sondern hilft auch beim Load-Balancing und ermöglicht parallele Downloads. Außerdem ist er für das kommende IPv6 gerüstet.

Wenn ihr ein älteres Release installiert habt, stellt einfach die Zeilen in der debian.list um. Wenn ihr dann apt-get update ein paar Mal beobachtet, solltet ihr verschiedene Mirror benutzt sehen.

Desperado Reloaded veröffentlicht

Spät gestern abend haben wir, gerade mal eine Woche vor dem Freeze für Debian 7, Desperado Reloaded veröffentlicht. Die Details stehen in der Release Note.  Downloads findet man auf unseren Spiegelservern oder als Torrent.

In der näheren Zukunft werden wir, um der Langeweile des Freeze zu entgehen, ein paar Dinge kaputtmachen, um sie dann neu zusammen zu setzen:

  • Die Art und Weise, in der wir unsere Art-Pakete bauen und vor allem integrieren bedarf einer Generalüberholung. Das st viel zu kompliziert und fehleranfällig.
  • Anstatt bei Releases zwischen 2 Sychronisationsläufen der Debian Server direkt von diesen zu bauen, werden wir einen Repositiry-Server aufsetzen, der uns etwas mehr Freiraum im Release-Prozess gewährt.
  • Außerdem wollen wir uns Jenkins für automatisiertes  Paket/Iso-bauen und Regressionstests genauer anschauen um unsere Infrastruktur weiter zu härten.

Zum Schluss noch eine News für die Freunde von Razor-qt: Im August-Heft des LinuxUser gibt es ein gestern gebautes, exklusives, aktualisertes und verbessertes Image unseres Razor-qt-Releases samt Artikel.

Desperado Reloaded

Wir hatten letzte Nacht ein (verspätetes) Kern Team Treffen. Hauptsächlich hatten wir 2 Themen:

  • Ein Reparatur-Release für 2012.1 Desperado
  • Die permanente Abwesenheit von zwei Kern Team Mitgliedern

Das Reparatur-Release wird am Abend des Sonntag, 24.06.2012, veröffentlicht (wenn sid uns lässt). Dieses Fix-Release wird KDE SC 4.8.4-x als das gleiche komplette Set mit sich bringen, wie es auch nach Wheezy einfließen wird. Mit dem „Einfrieren“ für das Release von Wheezy, beginnend am 30.06.2012, wollen wir die Zeit nutzen um zu diesem Paket-Set zu erweitern , da das bei 2012.1 Desperado (nur) ein sehr Grundlegendes war. Daneben wird unser KDE SC Abbild für akonadi auf sqlite voreinstellen, anstatt mysql zu benötigen. Kleinere Reparaturen an LXDE und XFCE komplettieren das Fix-Release 2012.1.1 Desperado.

Das zweite Hauptthema war eine Abstimmung, was in Bezug auf 2 Core-Team-Mitglieder zu tun sei, die seit einer Weile abwesend sind. Die beiden Mitglieder sind vibora und edhunter. In der Abstimmung wurde entschieden, dass beide aus dem Kern Team entlassen werden. Das Team braucht aktive Mitglieder, die mindestens an den Treffen und Abstimmungen teilnehmen. Tote Stimmen blockieren das Team, weil sie die Anzahl der Teilnehmer reduzieren, ebenso ist die Beschlussfähigkeit ein Problem. Wir werden an einer Regel arbeiten, um damit umzugehen. Unser Dank geht an vibora und edhunter für die Arbeit die sie für siduction und seine Vorgänger geleistet haben. Wir werden die beiden leeren Plätze im Team in Kürze auffüllen. Es gibt bereits einige Kandidaten, aber mehr dazu wenn wir jemanden herein wählen.

Ein anderes Thema war, einen Code freeze 24 Stunden vor einem Release zu setzen. Ihr findet das log des Treffens wie immer bei Chili.

Nachlese

LinuxTag 2012 ist vorbei. Wir hatten eine gute Zeit während dieser 4 Tage und auf den nächtlichen Parties. Natürlich haben eine Menge Leute gefragt, was es mit dem erneuten Namenswechsel auf sich hat, aber niemand missgönnte es wirklich. Danke an die Debian- und Kanotix-Leute für das Teilen eines großartigen Standes.

Freitag nacht hatten wir eine kleine Release-Party am Stand mit etwa 30 Beobachtern, die Bier, Fleischklopse und einen ersten öffentlichen Build und eine Einführung in unser razor-qt-Release genossen. Es war geplant, dieses auch von dort aus zu veröffentlichen, aber wir entschieden,  ihm noch etwas mehr Liebe zukommen zu lassen und noch etwas optische Verschönerung hinzuzufügen. Wir haben es deshalb erst heute morgen veröffentlicht. Downloads können von unseren Spiegeln bezogen werden.

Kurz vor dem LinuxTag hatten wir auch das finale siduction 12.1 „Desperado“ veröffentlicht.
Die Release-Notes zeigen die Details und es kann ebenfalls über unsere Mirrors bezogen werden.