Tag Archives: fedora

Fedora: Wie man ProjectM kompiliert

Posted on by

Wer wissen will, wie er für Fedora ProjectM kompilieren kann, der soll weiterlesen. Alle die Epilepsie haben, sollten das nicht in Betracht ziehen, das ist übles Farb & Flacker Foo, ich glaube einige der Effekte wollten mir unterschwellige Botschaften aus dem Universum unterjubeln 😉

Erstmal Devkrams installieren

Neben dem, was man als normale C Entwicklungsumgebung sowieso braucht, GCC, AutoMake etc. kommen folgende Pakete zum Einsatz:

glm-devel
libICE-devel
libSM-devel
libXt-devel
mesa-libGLU-devel
libXv-devel
qt-devel
glm-devel
rhash
cmake-data
cmake
qt5-rpm-macros
qt5-qtbase-devel
pulseaudio-libs-devel

einfach mit DNF installieren.

Sourcecode clonen

Den Source bekommt man von GitHub. Dazu macht man sich erstmal ein leeres Verzeichnis ..

mkdir -p Programmieren/git/

.. dann hinwechseln ..

cd Programmieren/git/

… und Source clonen :

git clone https://github.com/projectM-visualizer/projectm.git

Jetzt warten, kann dauern, sind fast 20.000 Bruchstücke die da ankommen. Dann wechseln wir in das Projekt:

cd projektm

und lassen autogen arbeiten:

./autogen.sh

jetzt konfigurieren. Entgegen der Anleitung muß man allerdings extra angeben, daß QT gebaut wird, sonst nix PulseAudio-Version 😉 GLES und Threading kann man, muß man aber nicht machen. Hat den Vorteil das mehr Power rauskommt, denn das schluckt einiges an Leistung. Eine schwache CPU kann da stark von profitieren.

./configure –enable-gles –enable-threading –enable-qt

noch ein make und man ist durch. Mit make install kann man das installieren, aber wer sich das nicht ans Bein binden will, weil üblicherweise gibt es nämlich kein uninstall bei sowas 😀 , der findet z.b. die PulseAudio Version hier ./src/projectM-pulseaudio/projectM-pulseaudio .

Nach reiflicher Überlegung, habe ich dann rm -rf ~/.projectM projectm gemacht 😀 Es war nicht eine brauchbare Visualisierung dabei.

Fedora 28 Bugs wie eine Betaversion

Posted on by

…und da meinte neulich jemand zu mir, daß man auf Fedora 29 updaten sollte, weil Fedora 27 EOL hatte…

1 Jahres Zyklus von Fedora

{...boar ist der Gutenbergeditor Scheisse...} Wie Ihr ja gelesen habt, war Anfang Dezember EOL von Fedora 27 und man durfte Upgraden. Wie immer upgrade ich in die 2 Hälfte des einjährigen Wartungszykluses rein, in der Hoffnung, daß die in den ersten 6 Monaten wenigstens die dicken Bugs bereinigt haben.

Dies Jahr hatte ich kein Glück. Ich komme mir vor, wie ein Betatester:

Audacity stürzt up, wenn man das „Höhen und Tiefen“ Plugin anwenden will,
Texte sind in Cinnamon nicht übersetzt,
das GLIBC Paket für Deutsch wird nicht installiert, weil gloriatorisch einer dachte, der „glibc-all-langpacks“ wäre installiert, was er nicht war,
dann fliegt einem die Gnome-Shell um die Ohren und zwar mit Status „gestorben“,
das Menüicon von Cinnamon verschwindet, muß man erst wieder selbst fixen,
in der Cinnamon-Iconleiste sind die Icons per Default zugroß gerendert, so daß es aussieht, als wenn ein Mensch ohne Geschmackssinn am Werk war,
wenn man das Default Hintergrundbild für den Desktop hatte und es einem am Herzen lag, mein Beileid..
die Kernelmodule beim Booten laden immer noch nicht,
auf Laptops ist die Bildschirmauflösung zwischen GRUB und GDM in die 640×480 Steinzeit zurück gebombt worden( nicht fixbar derzeit )

und so gehts weiter und weiter. Wenn das der Zustand nach 6 Monaten ist, möchte ich nicht wissen, in welchem das an Tag 1 war und in welchem Fedora 29 jetzt gerade ist. Wenn mal was nicht geht, ok, aber soviel habe ich zuletzt bei F21 gefunden.


Update 1 Tag später:

6 neue Bugreports über F28 dazu gekommen 🙁 Es wird immer mehr zu einer Alphabersion, je länger man nachsieht.

Fedora 28 und der OpenXenManager

Posted on by

Ja, daß Aftermatch von Fedora 28 geht in Runde 3 und die hats in sich. Jeder der OpenXenManager benutzt hat um seine XenServer zu versorgen, der sollte jetzt ganz genau weiterlesen. If you found this article about OXM, all relevant informations will be available in english too, the rest will be infos about the situation.

Fedoras Zukunft mit Python 2

Wir haben ein Problem. Eigentlich haben wir mehrere, aber eins nach dem Anderen. Der Entwickler des OpenXenManagers hat leider keine Zeit mehr für das Projekt. Das wäre an sich nicht soooo dramatisch, da es bis auf eine Kleinigkeit ganz gut funktioniert. Jetzt ist das Teil in Python 2 geschrieben. Das ist das Problem!

In Fedora 28 wurde die GTK-VNC Bindung für Python gekappt. Das Paket gibt es nicht mehr bei Fedora, weil GTK-VNC 0.8 kein Python 2 mehr können will, zumindest nicht so. Es gibt also eine neue API. Da kommt Problem 1 wieder ins Spiel: OXM müßte umgebaut werden, was aber nicht passiert, weil Daniel Lintott keine Zeit mehr hat. Deadlock!

In Fedora 30 wird Python 2 komplett entfernt. Wer also noch auf Python 2 setzt, ist dann raus.

Lösung – Solution

Bis Ihr einen Ersatz für den OXM habt, könnt Ihr das hier machen:

enter as root into a bash / als root in Bash eingeben:

rpm -i –force –nodeps http://dl.fedoraproject.org/pub/fedora/linux/releases/27/Everything/x86_64/os/Packages/g/gtk-vnc-python-0.7.1-3.fc27.x86_64.rpm

after this, OXM will start again / danach startet der OXM wieder

BUT / ABER

Your problem is not fixed yet, as Python 2 will be erased from Fedora 30. You need a new OXM, and there is no Opensource Version insight. https://xen-orchestra.com may be an alternative for Linux, but it’s commercial.

Wie oben schon angedeutet, mit Fedora 30 verschwindet Python 2 ganz. Bis dahin braucht Ihr Ersatz. https://xen-orchestra.com/ wurde da empfohlen, aber das ist kommerziell.

A skilled Python Dev could take over OXM for good and add the missing python gtk support again. If you know one, let him/her know.

Wer zufällig einen Python Entwickler kennt, könnte dem ja mal einen Tip geben. Da mir Python so gar nicht gefällt, kann ichs leider nicht machen.

Stimmt.. was war Runde 2? 🙂

Runde zwei war, das die Wetter-Anwendung aufgrund des libmozjs-38 Bugs nicht mehr startet, sondern einen core-dump produziert. Das muß man auch erstmal schaffen 🙂