Tag Archives: Debian

Liberate the Debian Administrator’s Handbook

Last week i stumbled upon a interesting project: The liberation of the Debian Administrator’s Handbook.  The goal of the project is described best with their own words:

Liberate the Debian Administrator’s Handbook

The Debian Administrator’s Handbook has been written by two Debian developers who are keen to share their knowledge. Accessible to all, this book teaches the essentials to anyone who wants to become an effective and independent Debian GNU/Linux administrator.

It covers all the topics that a competent Linux administrator should master, from the installation and the update of the system up to building packages and the compilation of the kernel, but also monitoring, backup and migration, without forgetting advanced topics like SELinux setup to secure services, automated installations, or virtualization with Xen, KVM or LXC.

Read more at http://debian-handbook.info/liberation

KDE-Next Repository

Since KDE SC 4.7 transition ist still blocked in Debian, preventing 4.7.4 moving from experimental to unstable, this leaves unstable users with an unsatisfying KDE SC 4.6.5. For our first release, we had used the debian-qt-kde repository, which at the time had KDE SC 4.7.2. Soon after, KDE SC 4.7.4 got uploaded to experimental. Instead of also updating the qt-kde repo, it was emptied and is dead in the water at the moment. The god thing about the qt-kde repo is, that it needs on very basic 3 lines of pinning.

As things look right now, we will see KDE SC 4.7.x in Debian 7 Wheezy. As the freeze for that is not so far away, that could mean, that KDE SC 4.8 will not enter any debian repo for a while, because in freeze RC-Bugs have priority. Even though 1 guy is working on KDE SC 4.8, there might not be enough time and manpower, once freeze hits us.

For a user to use KDE SC 4.7.4 from debian experimental, user needs a preferences file, pinning every package, resulting in a list as long as my arm. To resolve the situation, we have decided to set up a repository calles kde-next, which, at the moment, holds the KDE SC 4.7.4 packages. Adding this repo to your sources.list.d will update your kde-version to KDE SC 4.7.4 with your next dist-upgrade. No need for pinning. The upgrade from KDE SC 4.7.2 to 4.7.4 is, as can be expected, a breeze. Should you want to upgrade from KDE SC 4.6.5, or – behold – even older, please be careful and read what apt wants to do.

The lines to add are:

  • deb http://packages.siduction.org/kdenext unstable main
  • deb-src http://packages.siduction.org/kdenext unstable main

After an apt-get update your package-manager is introduced to the repository and you are good to go.

Our Blog got a Workover

After a few days of downtime or partial downtime WordPress has surrendered to agaidas thorough strive to have this blog bilangual in german and english. The english section is availabe at http://news.siduction.org, whereas the germal part is at http://de.news.siduction.org. some minor work is still to be done, in the backend as well as visualy, but no more downtime is to be expected. Thanks agaida for not giving up :)

Themen der Core-Team Sitzung am So.11.09.2011

Wie schon an anderer Stelle erwähnt, haben wir am So. 11.09 unsere turnusmäßige (2-wöchentlich) Core-Team Sitzung. Dieses Mal haben wir sie erweitert und die Wahl des endgültigen Logos um 20:00 davorgesetzt.

Die Themen des eigentlichen Meetings:

  • Ein Mirror-Team wurde erstellt, es muss mit Leben befüllt werden. Was brauchen wir an Spiegelservern? Wer kümmert sich?
  • Regeln und Zuständigkeiten für das Handling von Domains (z.B. Erstellen von Subdomains, Umbiegen von DNS)
  • Fertigstellung der map of siduction (statische Seite mit allen relevanten Infos, URLs, Ansprechpartner etc
  • Sollen wir bei zikula bleiben oder zu einem freundlichen CMS wie Joomla wechseln?
  • Wenn zikula, dann sollten wir eine Startseite für statischen Content erstellen?
  • Was soll auf den neuen Build-Server und was nicht?

Zuhörer sind gerne gesehen, die Sitzung ist öffentlich und findet am So. abend ab 20:00 (Wahl des Logos) und ab 21:00 das eigentliche Meeting statt.

Die Entscheidungen zur Infrastruktur wären damit dann soweit getroffen, dass wir uns bald an die eigentliche Arbeit machen können.

So viele Meetings …

Heute Abend ist kein Meeting. Unglaublich, da bleibt ja mal Zeit zum Diskutieren :)

Viele Meetings hinterlassen viele Logs. Ich merke schon, dass ihr die nicht alle lesen wollt. Eins vielleicht mal, um zu sehen was die Burschen da so treiben in ihren Chatrooms. Durchaus verständlich. Woher ich weiss, dass ihr die nicht lest, wollt ihr wissen? Naja, ganz einfach: Wenn, dann hättet ihr bestimmt nachgefragt, was es denn mit den Plänen für den neuen Installer auf sich hat? Ein Web-Frontend-Installer? Sind die jetzt völlig unterhopft?

Nein, keine Sorge, uns geht’s gut. Aber nur, weil es noch keiner gemacht hat, heisst das ja nicht, dass es nicht geht. So ein Webinstaller hat Vorteile: er macht nen enorm schlanken Fuss, weil man auf Toolkits verzichten kann, ist schnell anpassbar, kann gut ausschauen und kann sogar, so man denn will, bei jedem Release anders ausschauen.

Apropos Release — wir wissen mittlerweile, nach welchem Schema wir die Releases benennen. Das bleibt aber erst mal ein kleines Geheimnis…naja, wer lesen kann, ist klar im Vorteil :)

Wo wir uns wesentlich schwerer tun ist immer noch das Artwork. Nicht dass wir nicht gute Artworker hätten, im Gegenteil. Das Problem ist die Kommunikation unter dem Motto: Wie sag ichs meinem Künstler…?

Nunja, auch das bekommen wir in den Griff.

Alles wird gut.

Alles bleibt anders.

Wohin die Reise geht…

Wir haben ein Forum, ein Wiki, eine Entwicklungsplattform und rund 170 registrierte User, von denen mehr als 10 Prozent sich an der Entwicklung von siduction beteiligen wollen. Das Bemerkenswerte daran ist, wir haben (noch) gar kein Produkt. Kriegen wir auch so schnell nicht, weil, wir sind langsam…

Warum ist das so? Naja, es gibt da in unserer (noch ungeschriebenen) Verfassung das wichtige Wörtchen do-ocracy. Das ist nicht nur ein Unwort, sondern auch eine veritable Bremse für jedes Unterfangen. Alles wird bis ins kleinste Fitzel zerredet und zerpflückt und dann noch mal von hinten. Jeder hat zu allem was zu sagen. Und sei es nur: Bäh, das gefällt mir nicht…

Warum tun wir uns das an? Weil wir nur so bekommen, was wir wollen: Ein Community-OS, in dem Leute sich einbringen. Viele alte Bekannte, deren Namen lange nicht zu lesen waren, tauchen auf, andere, die über Jahre geforkidelt sind, werden nun aktiv. Also machen wir was richtig, und werden es weiter richtig machen.

Die eigentliche Arbeit fängt erst jetzt an, wo die Infrastruktur weitestgehend steht. Ideen nehmen Formen an, Bits werden sich zu Bytes rotten. Wir werden kein aptosid mit anderem Design abliefern.

Das bedeutet für den geneigten User in Lauerstellung, dass er sich nochmal entspannt zurücklehnen kann, oder sich aufraffen und mittun. Wir peilen eine erste Veröffentlichung von siduction für den Zeitraum der Feiertage am Jahresende an. Bis dahin werde ich Euch hier auf dem laufenden halten, was wir so tun, ausser alles zu zerreden.

Erstes Meeting der Coder

Wir hatten heute Abend ein erstes Meeting der Coder in #siduction-dev, um über den Installer zu reden. Ich fand das Meeting sehr produktiv und reich an Ideen. Und mir fiel etwas auf: die entscheidenden Impulse kamen von einem User, der seit Jahren in unseren Support-Channels idlet, ohne je viel zu sagen. Er wurde ja auch nicht gefragt. Es scheint also, als machten wir etwas richtig. :)

Das Log des Meetings ist online.

Voraussetzungen für Mitarbeit

Als erstes wäre für jeden, der etwas hochladen will, sei es Kernel, Pakete, Bilder, HTML,CSS, Dokumentation usw, grundlegend GIT zu beherrschen.

GIT ist ein Source Code Managementsystem (SCM), welches von Linus Thorvalds für den Kernel entwickelt wurde. Es geht dabei darum, das ein einmal eingechecktes wasauchimmer dort verbleibt bis in alle Ewigkeit und jede neue Version von wasauchimmer versioniert ist, d.h. man kann jederzeit auf die Version von vor 10 Minuten oder 2 Jahren zurück, man kann verschiedene Versionen diffen, mergen, verschieben, kopieren… Nun muss davor aber niemand Angst haben. Für die meisten Aufgaben reichen 3 simple Befehle, die wir euch demnächst gerne vermitteln.

Das 2. wäre unser Buildsystem, welches wir von pyfll von Kelmo (aptosid) ableiten werden. Wer also schon mit pyfll gebaut hat, wird damit klarkommen, den Rest, der ISOs bauen will, werden wir schulen. Also keine Bange, alles wird gut :)

Schubladen …

Ich werde mal ein paar Schubladen aufmachen und Leute reinstecken (sofern vorhanden, damit wir sehen was wir haben (wenig) und was wir brauchen (viel)).

Diese ‘Zuweisungen’ sind natürlich alle freiwillig und so zu handhaben, wie es die Freizeit erlaubt. Ebenso kann natürlich jeder seine zugewiesene Schublade verlassen, wenn er auf die ‘Delegation’, die ich hier vornehme, keine Lust hat. Ich halte es auch für notwendig, dass jeder im Team ersetzbar ist, um Situationen wie bei aptosid zu vermeiden, wo eine Person den ganzen Betrieb stoppen kann oder das Projekt zu Fall bringt, wenn ihr etwas nicht gefällt.

Teams

  • Infrastruktur
  • Server für Repositories, Chili; derzeit von agaida gestellt, kann evtl. dort verbleiben.
  •  Administration: agaida, devil (sollte erstmal ausreichen)
  •  Build Server (Intel Core i7 2600, 16 GB Ram, 2 x 1.5 TByte Disks in Raid) dafür sollten wir einen Sponsor suchen
  •  delegiert an: devil, Schublade PR
  • Kernel
  • Kernelbau, Patchsets finden und anwenden,
  •  Bedarf: 3-4 Personen
  •  delegiert an: towo, ralul Fehlquote: 1-2 Personen
  • Paketbau generell
  •  Bedarf: 3 Personen (gerne mehr)
  • delegiert an: towo mit dem Hintergedanken, dass er noch ein Paar Leute anlernt im Paketbau
  •  praktisch könnte ich mir, wenn genügend Leute Spass dran finden, ein Repository neben den offiziellen Repos vorstellen, in das User selbstgebaute Pakete hochladen können. Arch macht es vor. Allerdings würde ich es bevorzugen wenn wir von dort dann Pakete handverlesen offiziell machen wenn sie es verdienen (Relevanz, Paketierungsqualität)
  • ISO-Building und -Testing
  •  Bedarf: so viel wie möglich, ISOs sollten auf täglicher Basis in verschiedenen Arches mit verschiedenen Desktops gebaut und getestet werden
  •   delegiert an devil, vibora
  •   wir werden zur Verfügung stehen und im IRC eine Lecture machen, um Interessierten den ISO-Bau beizubringen
  •  Support
  • Bedarf: Support, quantitativ wie qualitativ kann nie gut genug sein, hierbei sehe ich aber kein so grosses Problem im Moment. Sowohl IRC als auch Foren brauchen Moderatoren. Ich werde die Schublade mal leer lassen, die entsprechend Interessierten können sich dann im Wiki selbst einordnen.
  • Für sehr wünschenswert erachte ich, was Debian und Ubuntu im IRC an Bildungsangebot bietet. So kann man interessierte User gut ausbilden. Ich würde mich freuen, wenn sich jemand fände, der ein Auge drauf hat, wo welche Sessions gerade stattfinden und das für unsere User aufarbeitet und Vorschläge für eigene, distributionsoffene Sessions machen.
  •  Art-Team
  • Bedarf: 3-10 Leute, Entwurf und Ausarbeitung einer Corporate Identity samt ISO-Artwork, Maskottchen, Website-Design, Merchandise.
  • delegiert an: Ich lasse dieses Team völlig offen, da mir im Moment Namen fehlen. Man könnte daniel aus dem alten sidux-art-team fragen …
  • PR-Team
  •  Bedarf: 2 Leute
  •  delegiert an devil, ich würde mich über 1-2 Helfer freuen
  •  Aufgaben: PR, Öffentlichkeitsarbeit, Kontakt zu Presse, Kontakt zu Debian und anderen Distributionen, Messeauftritte anmelden, vorbereiten und durchführen, Spenden aquirieren

Zum Schluss noch ein heikler Job:

  • Release-Manager
  •  Bedarf: 2 Personen
  •  delegiert an: die sollen sich selber finden
  •  Aufgabe: Endmastering des ISO, Kontrolle, Release

Mit das Wichtigste fiel mir erst im Nachhinein ein:

  • Dokumentation
  •  Bedarf: möglichst viele

Das soll fürs Erste ausreichen, Feintuning kommt später. Ich werde in den nächsten Tagen die einzelnen Teams im Wiki abbilden und bitte dann, Interessenten, sich selbst in die einzelnen Teams einzutragen. Bitte keine Scheu, alleine durch die Eintragung könnt ihr noch nichts kaputt machen :)