Archiv des Autors: agaida

KDE-Next Repository

Die Transition von KDE 4.7.4 ist in Debian momentan blockiert. Dies  verhindert die Verschiebung von KDE 4.7.4 von experimental nach unstable und lässt die Sid-User mit einem unbefriedigenden KDE SC 4.6.5 allein. Für unser erstes Release hatten wir das debian-qt-kde Repository genutzt, das zu dieser Zeit KDE SC 4.7.2 beherbergte. Eine kurze Zeit späer wurde KDE SC 4.7.4 nach experimental hochgeladen. Anstatt das qt-kde-Repo auch mit hochzuziehen wurde es geleert und ist momentan klinisch tot. Das Schöne am qt-kde-Repo war, das man nur 3 Zeilen brauchte, um es komfortabel zu pinnen.

So wie die Dinge momentan stehen, werden wir KDE 4.7.x eventuell in Debian 7 Wheezy sehen, die Glaskugel erteilt nähere Auskunft. Da der Freeze für Wheezy nicht so weit entfernt ist, könnte das bedeuten, dass KDE SC 4.8 noch eine ganze Zeit lang nicht in den wie auch immer gearteten debian-Repos auftauchen wird. Im Freeze haben natürlicher Weise RC-Bugs die höchste Priorität.  Obwohl ein Entwickler an KDE SC 4.8 arbeitet, könnte es sein, dass das zuwenig Zeit und Manpower ist, bevor die Eiszeit uns erreicht.

Um als User KDE SC 4.7 aus debian exprimental zu nutzen braucht man ein preferences-file und darf jedes Paket namentlich pinnen. Die daraus resultierenden Liste ist ungefähr so lang wie mein Arm. Um eine Lösung für diese unbefriedigende Situation zu schaffen, haben wir entschieden, ein spezielles Repo aufzusetzen: KDE-Next – momentan beherbergt dieses Repo die KDE SC 4.7.4 Pakete. Um auf KDE 4.7.4 upzugraden sollte der geneigte User das Repo zu sources.list.d hinzufügen. Das Upgrade auf KDE 4.7.4 erfolgt dann beim nächsten apt-get dist-upgrade. Es muss nicht gepinnt werden. Das Upgrade von 4.7.2 auf 4.7.4 sollte ohne Probleme einfach so erfolgen. Solltet ihr von KDE SC 4.6.5 oder schlimmer – noch älter upgraden wollen, dann seid bitte  vorsichtig und lest genau, was apt-get mit Eurer Installation tun möchte. Eine Datensicherung ist sicher nicht die schlechteste Idee.

Die Zeilen fürs Repository:

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

Nach einem apt-get update kennt der Paket-Manger das Repos und Ihr seid bereit für das Upgrade.

Upgrade auf ChiliProject 3.0.0

Wir haben unsere Installation auf  Chiliproject 3.0.0 aktualisiert. Unsere Gratulation geht an die Macher von ChiliProject.

Was ist neu?

  • Ein neues Design, besseres look-and-feel
  • Ein flexibles Templating-System: Liquid
  • Eine große Anzahl kleinerer Verbesserungen, die ChiliProject flexibler und leichter machen

Was ist enthalten?

3.0.0 enthält 24 neue Features und 15 Bugfixes gegenüber 2.7.0. Es enthält alle Bugfixes und Features des 2.7.0 Releases.

Wie geht es weiter?

ChiliProject 3.0.0 ist das erste Release der 3.x-Serie, die mit monatlichen Bugfix-Releases bis zum nächsten Major-Release von ChiliProject (wahrscheinlich Juli 2012) versorgt wird. Die Hauptziele für dieses Major-Release werden das Upgrade auf Rails 3.x und die weitere Modularisierung von ChiliProject.

Übersetzer gesucht

Wir brauchen Übersetzer und Sprach-Maintainer für das bluewater manual. Sprachen, bei denen wir Eure Hilfe benötigen: Dänisch, Holländisch, Tschechisch, Französisch, Italienisch, Polnisch, Japanisch, Spanisch, Russisch, Rumänisch, Ukrainisch. Die Übersetzungen des Manuals sind meist zu 99% getan. Das Handbuch muss aber noch korrekturgelesen und für siduction adaptiert werden. Nach der Veröffentlichung muss das Handbuch dann natürlich auch in den jeweiligen Sprachen betreut werden. Ausserdem benötigen wir noch jemanden, der dieses Projekt koordiniert.

Ich sitze grade am Review des deutschen und englischen Handbuchs, diese beiden können als Referenz für zukünftige Lektoren/Übersetzer/Maintainer dienen. Notwendiges technisches KnowHow neben der Beherrschung der jeweiligen Sprache ist die Bedienung von Git.  Wir werden bei Bedarf Schulungen in #siduction-college abhalten, um Euch in kürzester Zeit fit für diese Aufgabe zu machen. Bitte entschließt Euch, etwas an das Projekt zurückzugeben und ein wenig Eurer Zeit in dieses wirklich gelungene Handbuch zu stecken. Zur Zeit sind nur DE, EN und PT_BR online. Wir hoffen mit Eurer Unterstützung die restlichen Sprachen ebenfalls zeitnah ins Netz und auf den Desktop zu bekommen.

Achtung: Falls jemand sich dazu berufen fühlt, einige Zeit in das CSS des Manuals zu investieren – bitte meldet Euch. 😉

(Ferdinand Thommes on 2012/01/10 at 18:46)

Nachtrag: Mittlerweile ist dank der tatkräftigen Unterstütung durch Quidam77 Polnisch online, am italienischen Handbuch wird momentan kräftig gefeilt. Also auch von meiner Seite die Bitte: Meldet Euch, macht mit!

(Alf Gaida on 2012/02/05 at 22:30)

Upgrade auf Chiliproject 2.6.0

ChiliProject 2.6.0 wurde gestern releases. Es enthält einige Fixes für ChiliProject 2.5.0. Es ist für die Verwendung auf Produktionsseiten geeignet und wir empfehlen allen Usern, das Upgrade so schnell wie möglich durchzuführen.

Wir werden unsere Installation am heutigen Tag durchführen, bitte enschuldigt eventuelle Unannehmlichkeiten. Das ist das wahrscheinlich letzte Update von ChiliProject 2.X. Im Lauf dieses Monats sollte die finale Version 3.0 von ChiliProject erscheinen, auf die wir nach auführlichen Tests ausserplanmäßig updaten werden.

Was ist neu

2.6.0 enthält  6 neu Features und 8 bug fixes für 2.5.0. Keiner der Fixes ist sicherheitsrelevant. Die Highlights dieses Releasess sind:

  • ChiliProject ist jetzt voll kompatibel mit Ruby 1.9.3
  • Core-Plugins und User-Plugins sollten ab jetzt getrennt installiert werden. User-Plugin werden ab jetzt in das Verzeichnis vendor/chiliproject_plugins installiert. Das hilft, die Plugins während der Updates unterschiedlich zu behandeln. Bestehende installationen mit allen plugins im Verzeichnis vendor/plugins werden wie gewohnt weiterarbeiten.
  • Verbesserte Einbindung von Filtern bei der Verwendung von LDAP als Backend zur Authentifizierung.
  • rdm-mailhandler.rb (Empfang von Mails) ist wieder benutzbar, nachdem eine mit 2.5.0 eingeführte Regression behoben wurde.
  • Einige kleine Fehler wurden beseitigt und die Übersetztung wurde verbessert.

Release Candidate veröffentlicht

In der letzten Nacht war es dann endlich so weit: Und es wurde ein siduction. Es war eine relativ unproblematisch Geburt, nachdem wir den geplanten Termin wegen einer kleinen Verzögerung bei der Einrichtung  und dem Test der Spiegelrechner um 2 Tage verschieben mussten. Bitte holt Euch die Variante Eurer Wahl und testet intensivst, damit wir ein perfektes Final Release liefern können.

Images mit  KDE SC, XFCE und LXDE sind in 32 und 64 Bit  auf unseren  Mirrors verfügbar. Die Release Note mit weiteren Informationen findet ihr in den News. Seit einigen Minuten sind wir auch auf Distrowatch gelistet. Klickt den Link, helft uns, Siduction sichtbar zu machen. Mach Werbung für Siduction, überall wo es angebracht erscheint.

Upgrade auf ChiliProject 2.2

Vor wenigen Stunden wurde die Version 2.2 von ChiliProject freigegeben.

[27.08.2011 19:59:50] <meineerde> Ladys and Gentlemen, we have a release.

Nach kurzem Test an 2 kleineren Installationen wurde das Release auch in chili.siduction.org eingespielt. Die Release-Notes findet ihr hier: http://blog.chiliproject.org/releases/chiliproject-2-2-0-released/

Keine Sorge um die Daten, natürlich hatten wir eine Datensicherung. Frei nach dem Motto von Sledge Hammer: „Vertrauen Sie mir, ich weiss, was ich tue!“ habe ich mich an ein Upgrade gewagt und siehe da: Es funkt.

Finale Umstellung nach chili.siduction.org

Die Umstellung von newsid.dyndns.org auf chili.siduction.org ist vollzogen. In diesem 2. Schritt habe ich die Verlinkung der Repositories von newsid.dyndns.org auf git.siduction.org chiliweit eingesetzt. Innerhalb von Chili wurden alle Links auf newsid.dyndns.org beseitigt, eine Ausnahme sind die IRC-Protokolle oder wenige Stellen, bei denen eine Änderung einfach keinen Sinn machte. Solltet Ihr dennoch Links finden, die noch alt sind, entweder en passant ändern oder ein Ticket aufnehmen. Danke.

Umstellung der Repository-Namen und -Verzeichnisse

git@newsid.dyndns.org:siduction/artwork-siduction.git =>
    git@git.siduction.org:siduction/artwork-siduction.git
git@newsid.dyndns.org:siduction/community-siduction.git =>
    git@git.siduction.org:siduction/community-siduction.git
git@newsid.dyndns.org:siduction/dur-siduction.git =>
    git@git.siduction.org:siduction/dur-siduction.git
git@newsid.dyndns.org:siduction/linux-rt-siduction.git =>
    git@git.siduction.org:siduction/linux-rt-siduction.git
git@newsid.dyndns.org:siduction/linux-siduction.git =>
    git@git.siduction.org:siduction/linux-siduction.git
git@newsid.dyndns.org:siduction/packages-siduction.git =>
    git@git.siduction.org:siduction/packages-siduction.git
git@newsid.dyndns.org:siduction/sandbox-siduction.git =>
    git@git.siduction.org:siduction/sandbox-siduction.git
git@newsid.dyndns.org:siduction/verwaltung-siduction.git =>
     git@git.siduction.org:siduction/verwaltung-siduction.git

Umstellung lokaler Kopien der Repositories

In allen lokalen Repositories existiert das Steuerverzeichnis .git. In diesem befinden sich die relevanten Einstellungen des Repositories. Um die lokalen Repos auf die veränderte Sachlage anzupassen, muss nur mit dem Editor eigener Wahl eine Konfigurationszeile geändert werden.

Beispiel dur-newsid

$ .git/config
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git@newsid.dyndns.org:siduction/dur-siduction
[branch "master"]
remote = origin
merge = refs/heads/master

Hier muss die Zeile

url = git@newsid.dyndns.org:siduction/dur-siduction

in

url = git@git.siduction.org:siduction/dur-siduction

geänder werden. Das war es an dieser Stelle.

Die Repositories werden eine gewisse Zeit parallel auch noch unter newsid.dyndns.org erreichbar sein.

Anonymous Zugang zu den Repositories

Im Rahmen der Umstellung auf chili.siduction.org und git.siduction.org plane ich auch die Einführung eines anonymen Lesezugriffs auf die Repositories. Das heisst, dass man sich als normaler User ohne Notwendigkeit des Schreibzugriffs nicht mit SSH auseinandersetzen muss. Das macht mein und Euer Leben wahrscheinlich leichter und stressfreier. Ich setze das dann ein, wenn ich begriffen habe, wie es funktioniert, also heute, morgen oder übermorgen. Bisher war ich leider noch nicht in der Position, öffentliche Repos aufzusetzen, die Kundschaft wollte das bisher irgendwie nicht.