KeepassX 2

Es ist schon ein wenig verwirrend, was bei Fedora mit keepassx passiert ist. Zuerst wurde für Fedora 23 ein Update auf Version 2.0 veröffentlicht, das dann jedoch wiederum nach einigem Protest zurückgezogen wurde.

Aus mir nicht nachvollziehbaren Gründen wurde dazu das Epoch des Paketes auf 1 erhöht, was spätestens beim Upgrade auf eine neuere Fedora-Version dazu führt, das keepassx ein Zwangs-Downgrade auf Version 0.44 verpasst bekommt. Da die Datenbanken von keepassx 0.44 und 2.0 blöderweise nicht kompatibel sind, schaut jeder, der bereits das Upgrade auf Version 2 gemacht hat, blöd aus der Wäsche, da er nicht mehr an seine gespeicherten Passwörter herankommt, sofern er nicht noch die alte Datenbank im 0.44-Format hat.

Da ich zu diesen Leuten gehörte, die nach dem Upgrade auf Fedora 24 blöd aus der Wäsche geschaut haben, habe ich mir das keepassx Paket in der Version 2.0 geschnappt, in keepassx2 umbenannt und so konfiguriert, das es das keepassx-Paket von Fedora ersetzt. Dadurch ist auch sichergestellt, das Fedora einem auch zukünftig kein neues Zwangs-Downgrade auf 0.4x reinwürgt.

Für alle Leidensgenossen oder die, die gerne auf Version 2.x upgraden möchte, habe ich mein keepassx-Paket in einem COPR bereitgestellt.

PS: Dem keepassx-Maintainer sollte man für diese, an Dämlichkeit kaum zu überbietende, Aktion eigentlich 500 mal „Ich darf kein Zwangs-Downgrade machen, wenn sich das Format der Programmdatenbank geändert hat“ an eine Tafel schreiben lassen! Mindestens! 👿

minibuild – mein kleines Build-Script

Wie der eine oder andere vielleicht mitbekommen hat, baue ich seit einiger Zeit selber rpm-Pakete und veröffentliche diese auf COPR.

Da das Bauen der Pakete aus einigen Arbeitsschritten besteht, die sich zum Glück relativ einfach automatisieren lassen, habe ich kurz nachdem ich angefangen habe, Pakete zu bauen, mir ein kleines Shellscript geschrieben, das die notwendigen Schritte automatisiert. Inzwischen ist dieses Script knapp 550 Zeilen lang, GPL lizenziert und auf GitHub veröffentlicht.

Das Script ist mittlerweile so mächtig geworden, das es den kompletten Build-Prozess, bestehend aus

  • dem Download der Quelltexte von der Projektseite,
  • dem Erzeugen der src.rpm Pakete,
  • dem Durchführen eines lokalen Testbuilds mit mock,
  • dem anschließenden Validieren der Pakete (Binary und src.rpm) sowie des Spec-Files mittels rpmlint,
  • dem Upload des src.rpm Paketes auf einen FTP-Space sowie
  • dem Start des finalen COPR-Builds

vollständig automatisiert. Das Script ist ferner in der Lage, in begrenztem Umfang Platzhalter in der Quelltext-URL aufzulösen und die korrekte URL zu erzeugen.

Gesteuert wird das Script hauptsächlich durch 3 Konfigurationsdateien:

  • chroots.conf: Hier werden die zu verwendenden chroots eines Projektes eingetragen, sofern ein Projekt nicht für alle chroots eines COPRs gebaut werden soll.
  • coprs.conf: Hier werden den Projekten (Name des Spec-Files) die COPRs zugeordnet, sofern der Projektname nicht dem Namen des COPRs entspricht.
  • ftp.conf: Hier werden die URL des FTP-Space, der Pfad innerhalb des FTP-Space sowie die notwendigen Zugangsdaten eingetragen.

Ich würde mich freuen, wenn mein Script auch anderen Paket-Maintainern helfen kann, ihnen Arbeit beim Bauen ihrer Pakete abzunehmen. Genau so sehr freue ich mich über Verbesserungsvorschläge, Anregungen und konstruktive Kritik.

COPRs: Ein zweischneidiges Schwert

Als vor nicht all zu langer Zeit COPRs (Cool Other Peoples Repositores) Einzug in das Fedora Repository hielten, war die Freunde gros, das man endlich ein Pendant zu den PPAs aus dem Untuntu-Universum habe.

Inzwischen hat man jedoch immer öfter den Eindruck, das COPRs als eine Art Zwischenschicht zwischen Rawhide und Stable missbraucht werden. Als jüngstes Beispiel könnte man das mit dem Kernel 4.0 eingeführte Live-Patching nennen. Einerseits wird bekanntgegeben, das Live-Patching standardmäßig im Fedora-Kernel deaktiviert ist, im gleichen Atemzug wird jedoch auf ein use on your own risk COPR verwiesen, wo man Kernel mit aktiviertem Live-Patching bekommen kann.

COPRs sind durchaus nützlich und hilfreich, wenn es darum geht, Dritten Pakete zur Verfügung zu stellen, die (noch) nicht in den offiziellen Fedora Repositories enthalten ist oder um neuere Versionen der in Fedora enthaltenen Software zum Testen bereit zu stellen. Ich halte es jedoch falsch, COPRs für das Entwickeln und Testen neuer Features zu verwenden. Dafür war bislang Rawhide zuständig und so sollte es auch bleiben. Ansonsten war Fedora die längste Zeit die Distribution, die man sich installiert hat, wenn man möglichst nahe am Puls der Linux-Entwicklung sein wollte und wird immer mehr zu einem Debian auf rpm-basis.

IMHO ist der Kommentar von Fedora-Blog.de.
IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach).

light-locker: Ein Session-Locker für LightDM

Wem der X-Screensaver bzw. xflock4 zu hässlich ist, weil sie sich nur bedingt in aktuelle Versionen von Xfce und Co integrieren, dem sei light-locker als mögliche Alternative ans Herz gelegt.

light-locker ist ein Session-Locker, der LightDM als Sperrbildschirm verwendet und so ein konsistenteres Aussehen zwischen Login- und Sperrbildschirm ermöglicht. Momentan steht light-locker jedoch nur über ein COPR als Fedora-Paket zur Verfügung.

Kennt Ihr auch ein interessantes Programm, das wir hier im Blog vorstellen sollten? Dann sagt uns Bescheid oder schreibt einen Gastbeitrag für uns.

Gnome Terminal kann wieder Transparenz

Wie Debarshi Ray in seinem Blog berichtet, verfügen die Gnome-Terminal Pakete aus dem Gnome 3.12 COPR ab sofort über einen Patch, der das in Gnome 3.08 entfernte Transparenz-Feature zurückbringt.

Ray weißt jedoch auch darauf hin, das es sich hierbei um einen Downstream-Patch handelt, da der Patch vom Gnome Terminal Entwickler abgelehnt wurde. Ferner gibt es momentan noch einen Bug in Adwaita, der dafür sorgt, das auch die Menüleiste transparent dargestellt wird, sobald die Transparenz aktiviert wurde. Ray hofft jedoch, das der Bug bald gefixt ist.

Playground Repository für Fedora 21

Im Ramen der allmählich Fahrt aufnehmenden Entwicklung von Fedora 21 werden nach und nach auch erste Vorschläge für neue Features auf der Entwicklerliste gepostet.

Einer der Vorschläge ist ein so genanntes Playground Repository, welches es leichter machen soll, Pakete zu Fedora bei zu steuern. Das Playground Repository soll solche Pakete enthalten, die zwar noch nicht in den offiziellen Repositories enthalten, aber dennoch für Fedora-Nutzer nützlich sind.

Dazu wird das Playground Repository mit dem COPR-System verzahnt, so das man sein COPR-Projekt mit nur einem Mausklick für die Aufnahme in das Repository vorschlagen kann.

Gnome 3.12 COPR-Repository für Fedora 20

Wie Richard Hughes auf Google+ schreibt, hat er inzwischen ein COPR-Repository mit Gnome 3.12 Paketen für Fedora 20 aufgesetzt, die ausgiebig getestet werden können. Hughes empfiehlt jedoch, die Pakete vorerst nur in einer virtuellen Maschine zu installieren, da sie bislang nur nach dem Motto

„it installs and runs on a newly created VM“

getestet wurden. Ferner muss man im Moment auch SELinux deaktivieren, da Hughes noch keine für Gnome 3.12 angepassten Policies-Pakete gebaut hat.

Kurz gesagt sind die Pakete momentan in einem quasi-experimentellen Status und sollten nur von Anwendern installiert werden, die wissen, was sie tun und wie sie etwaige Probleme auch ohne grafische Oberfläche lösen können.

Wem COPR nichts sagt:
Ein COPR-Repository ist vom Prinzip und der Vertrauenswürdigkeit her mit den PPAs von Ubuntu vergleichbar. User können dort ihre selbst erstellten Pakete mit Hilfe der Fedora-Infrastruktur bauen und verteilen, solange sie sich an die Regeln, die auch für Pakete in den offiziellen Fedora-Repositories gelten, halten.