Xine ab Fedora 17 (wieder) bei rpmFusion?

Kevin Kofler hat heute auf der Entwickler-Liste von Fedora vorgeschlagen, xine ab Fedora 17 aus dem Fedora Repository zu entfernen und wieder nach rpmFusion zu verschieben. Er begründet seinen Vorschlag damit, das xine seit der kürzlich veröffentlichten Version 1.2 zwingend FFmpeg erfordert, welches nicht Bestandteil von Fedora ist.

Neben xine würden auch die folgenden Pakete aus dem Fedora Repository entfernt und nach rpmFusion wandern:

  • gxine
  • kaffeine
  • oxine
  • xine-plugin
  • xine-ui

Bei kaffeine merkt Kofler nebenbei an, das dieses Paket früher oder später eh nach rpmFusion “umziehen” müsse, da deren Entwickler zukünftig MPlayer als Backend nutzen werden

Firefox: Installation von Addons nur eingeschränkt möglich

Durch einen Bug in Xulrunner kann man momentan mit Firefox 9 nur über Umwege Addons von addons.mozilla.org installieren. Ursache sind anscheinend Teile der OpenWebApps Runtime von Mozilla, die in den Sourcecode-Archiven enthalten und bei allen Firefox-Versionen, die nicht direkt von Mozilla stammen, aktiv sind. Binärpakete, die von Mozilla direkt stammen sind anscheinend nicht betroffen.

Um auch unter Firefox 9 Addons von addons.mozilla.org zu installieren, kann man einen der folgenden Workarounds nutzen:

  • Den Link zur XPI-Datei, der sich hinter dem Installieren-Button verbirgt kopieren und in einem neuen Tab öffnen
  • Das gewünschte Addon über den Addon-Manager von Firefox installieren.

Bleibt nur zu hoffen, dass das Problem bis zur Freigabe von Firefox 10 gefixt ist oder das jemand bei Fedora sich um den korrespondierenden Bug kümmert und das Problem “downstream” patcht.

Mendeley und Fedora 16

Wer die Anleitung für Mendeley unter Fedora 15 mit Fedora 16 und der aktuellen Mendeley-Version ausprobiert, wird enttäuscht sein: Mendeley schießt sich selbst sang- und klanglos ab.

Sobald das Paket wie in der Anleitung beschrieben entpackt ist, muss man von der Fedora-15-Anleitung abweichen.

Die Bibliotheken dürfen nicht gelöscht werden. Um Mendeley nutzen zu können, muss die Parameter –force-bundled-qt beim Start von Mendeley verwendet werden, so meint zumindest der offizielle Support.

/opt/mendeleydesktop-1.3-linux-i486/bin/mendeleydesktop --force-bundled-qt

Der Desktop-Link sieht dann so aus:

[Desktop Entry]
Name=Mendeley Desktop
GenericName=Research Paper Manager
Comment=free reference manager and academic social network
Exec=/opt/mendeleydesktop-1.3-linux-i486/bin/mendeleydesktop --force-bundled-qt
Terminal=false
Type=Application
Icon=/opt/mendeleydesktop-1.3-linux-i486/share/icons/hicolor/128x128/apps/mendeleydesktop.png
Categories=Education;Literature;Qt;

Fedora und Facebook

Ich bin vermutlich nicht der einzige, der sich täglich in sozialen Netzwerken tummelt. Gerade als heavy-user schätzt man einen dedizierten Client, der optimalerweise mehrere Netzwerke unterstützt und sich in den Desktop einpasst. Nachdem ich auch Facebook so verwenden will, bleiben mir für Linux nicht gerade viele Alternativen.

Gwibber war früher die erste Wahl und gerade in Ubuntu 9.04 und 10.04 hat es auch ausgezeichnet funktioniert. Dort haben dann aber die Probleme mit Facebook angefangen. Nach einiger Zeit Absenz habe ich es wieder probiert und musste feststellen, dass der Facebook-Support jetzt komplett kaputt ist. Die Authentifizierung funktioniert wunderbar, allerdings werden weder Nachrichten empfangen, noch gesendet. So wie es aussieht, ist den Gwibber-Entwicklern der Bug bereits vor Monaten gesendet worden. Ein Grund für die Fehlfunktion wird wohl sein, dass Gwibber in Fedora die Facebook-App fedora-gwibber und nicht die “offizielle” Gwibber-App von Facebook benötigt – wieso auch immer. Fedora-Gwibber erteilt nicht die Rechte, um auf die Wall schreiben und die Wall lesen zu können, da kanns wohl nicht funktionieren.

Bisher hat Tweetdeck als Chromium-Extension immer gut funktioniert. Jetzt ist der Facebook-Support kaputt. Der News-Feed wird zwar angezeigt und neue Postings können erstellt werden, allerdings sind alle anderen Funktionen gestrichen worden. Absicht oder keine? Der zeitliche Zusammenhang mit dem Kauf durch Twitter lässt einen eindeutigen Schluss erahnen.

Yoono als Standalone-App/Plugin für Firefox kommt bei mir unter Windows zum Einsatz, dort funktioniert die Desktop-Integration der Standalone-App sehr gut – unter Linux/Gnome 3 scheint die Integration überhaupt nicht zu funktionieren. Das Mozilla-Plugin funktioniert zwar, aber ich war noch nie ein Freund von Browserlösungen, da viel zu unflexibel.

Was ist los mit den Gwibber-Leuten? Vor allem, was ist mit den Mainteinern bei Redhat? Gwibber war mal wirklich ein vernünftiger Client. Ich kann mir bei Gott nicht vorstellen, dass niemand Fedora in Gwibber verwendet. Von außen sieht es so aus, als ob man immer noch mit dem Versionssprung auf 3.x beschäftigt ist. Es wäre sehr schade, wenn der einzige wirklich vernünftige Client vor die Hunde geht.

Übrigens: Wenn irgendjemand eine wirklich gute Alternative  für einen Twitter/Facebook/Statusnet-Client hat, ich bin immer für Vorschläge offen.

Dropbox Consolen Client installieren

Wie man die Dropbox-Software unter Xfce installiert haben wir bereits hier beschrieben. Jedoch scheint man inzwischen einen zusätzliches Python-Script zu benötigen, wenn man die Software über die Konsole steuern will oder einfach einen anderen Dateimanager als Nautilus nutzt.

Um dieses Python-Script nutzen zu können, muss es zuerst heruntergeladen werden

wget -O ~/.dropbox/dropbox.py "http://www.dropbox.com/download?dl=packages/dropbox.py"

Anschließend setzen wir noch die Berechtigungen, damit nur unser Benutzer das Script ausführen kann

chmod 755 ~/.dropbox/dropbox.py

Eine genaue Übersicht über die Möglichkeiten des Python-Scripts erhält man über folgendes Kommando

~/.dropbox/dropbox.py help

Nichts desto trotz übernehmen wir keine Verantwortung, falls das eigene System durch diese Anleitung unbrauchbar gemacht werden sollte. Das Befolgen dieser Anleitung geschieht somit auf eigene Gefahr!

Googles kleiner Gemischwarenladen: Google-Talk-Plugin für x86_64

Wer sich die 64bit Version des Google-Talk-Plugins, das u.a. für die Hangouts von Google+ benötigt wird, installieren will, wird feststellen, dass das Plugin-Paket einen Haufen an 32bit Paketen installieren will.

Nach kurzer Google-Recherche bin ich auf einen Post in den Google Groups gestoßen, der dieses Phänomen wie folgt erklärt (Hervorhebung von mir):

The x86_64 google-talkplugin package currently contains one file which has not yet been fully ported to 64-bit. That file is 32-bit even in the x86_64 package, and as a result the package has some i686 dependencies. We are working toward a fully 64-bit version of google-talkplugin but in the meantime we recommend users to simply allow the package to install all of its dependencies.

Soll heißen, dass das Plugin nach wie vor ein Datei verwendet, die noch immer nicht nach 64bit portiert wurde und deshalb die 32bit Pakete installiert werden müssen.

Gut zu wissen ;-)

npapi-vlc ersetzt mozilla-vlc

Wer sich die VLC Version 1.13 aus dem rpmfusion-free-updates-testing Repository installiert, wird feststellen, dass das Paket vlc das Mozilla-Plugin, welches sich in dem Paket mozilla-vlc befindet, während des Updates ersetzt. Sobald man seinen Browser das nächste mal startet, wird man jedoch feststellen, dass das VLC-Plugin fehlt.

Wer sich jetzt aber wohl möglich Sorgen macht, dass das Mozilla-Plugin ersatzlos gestrichen wurde, darf beruhigt sein. Das Plugin “versteckt” sich ab sofort in dem Paket npapi-vlc, welches mit folgendem Kommando nachinstalliert werden kann

su -c'yum install npapi-vlc --enablerepo=rpmfusion-free-updates-testing'

Nach erfolgreicher Installation und einem obligatorischen Neustart des Browsers steht das VLC Plugin auch dort wieder wie gewohnt zur Verfügung.

IMHO: TeamViewer für Fedora: Etikettenschwindel

Wer Besitzer eines 64bit Systems ist und aus welchen Gründen auch immer den TeamViewer installieren muss, wird beim Besuch der Download-Seite im ersten Moment stutzen. Während es für SuSE(!) und Debian/Ubuntu jeweils seperate Downloads für die 32- und 64bit Versionen gibt, bekommt man als Fedora Nutzer nur einen einzigen Download angeboten, der dann auch noch als

Red Hat, Fedora, Mandriva (32/64-Bit)

etikettiert ist, was im ersten Moment super klingt.

Bei näherem Nachdenken kommen einem aber erste Zweifel. Ein Paket sowohl für 32- als auch für 64bit Systeme? Wie soll das gehen, wenn doch beim Erstellen des Paketes und nicht erst während der Installation entschieden wird, für welche Architektur das jeweilige Paket ist? Und spätestens bei der Installation kommt dann das böse Erwachen, da das angebliche Kombi-Paket unzählige i6861 Pakete erfordert und yum diese auch brav mit installieren möchte.

Ich weiss ja nicht, wie die Leser dieses Blogs das sehen, aber für mich ist so etwas einfach nur ein absolut peinlicher Etikettenschwindel. Zumal man es für SuSE ja auch schafft, separate Pakete für die 32- und 64bit Versionen anzubieten. Und SuSE nutzt bekanntlich auch rpm als Paketmanagement.

  1. 32bit Intel-CPUs der Pentium Pro Generation oder neuer []

CryptKeeper: Handling von EncFS-Volumes einfach gemacht

Bei CryptKeeper handelt es sich um kein kleines Tool, das sich nach dem Start im Benachrichtigungsbereich des Desktops einnistet und das schnelle und bequeme Ein- und Aushängen von EncFS-Volumes erlaubt.

CryptKeeper kann mittels

su -c'yum install cryptkeeper'

aus dem Fedora Repository installiert werden.

Nach dem Start verbirgt sich das Programm hinter einem unscheinbaren Schlüssel-Symbol im Benachrichtigungsbereich. Per Klick auf das Icon können

  • EncFS-Volumes ein- oder ausgehängt,
  • bestehende EncFS-Volumes in das Programm importiert oder
  • neue EncFS-Volumes erstellt

werden. Über einen Rechtsklick gelangt man schnell in die Einstellungen, wo man u.a. den bevorzugten Dateimanager sowie ein paar weitere Optionen einstellen kann.

CryptKeeper Optionen

CryptKeeper Optionen

Wer des öfteren mit EncFS-Volumes arbeitet, sollte sich CryptKeeper auf jeden Fall einmal anschauen.

Update-Benachrichtigungen mit Xfce4 Bordmitteln

Wir haben hier ja bereits gezeigt, wie man die Update-Benachrichtigungen unter Xfce nachrüsten kann.

Es gibt jedoch noch eine etwas elegantere Methode, um das ganze mit Xfce Bordmitteln zu realisieren. Dazu benötigen wir zuerst einmal das Xfce Genmon Plugin, welches wir über

su -c'yum install xfce4-genmon-plugin'

installieren und anschließend auf dem Panel platzieren.

Als nächstes legen wir ein Shell-Script mit folgendem Inhalt an

#!/bin/bash

# Reference: 

http://lists.fedoraproject.org/pipermail/xfce/2011-November/000841.html

# From "man yum"
#    check-update
#        Implemented  so  you  could know if your machine had any updates
#        that needed to be  applied  without  running  it  interactively.
#        Returns exit value of 100 if there are packages available for an
#        update. Also returns a list of the packages  to  be  updated  in
#        list  format. Returns 0 if no packages are available for update.
#        Returns 1 if an error occurred.

# Dependencies:  Oxygen icons
#                gpk-update-viewer  (yum install gnome-packagekit)

updates=$( yum check-update -q )
status=$?

if [ $status = 100 ]
    then
       echo -e "<img>/usr/share/icons/gnome/22x22/status/software-update-available.png</img>"
       echo -e "<tool>Updates Available</tool>"
       echo -e "<click>gpk-update-viewer</click>"
elif [ $status = 1 ]
    then
       echo -e "<img>/usr/share/icons/gnome/22x22/status/error.png</img>"
       echo -e "<tool>the script returned an error</tool>"
       echo -e "<click>gpk-update-viewer</click>"
elif [ $status = 0 ]
    then
       echo -e "<img>/usr/share/icons/gnome/22x22/status/dialog-information.png</img>"
       echo -e "<tool>all updates applied</tool>"
       echo -e "<click>gpk-update-viewer</click>"
else
       echo -e "<img>/usr/share/icons/gnome/22x22/status/stock_dialog-warning.png</img>"
       echo -e "<tool>status is unknown</tool>"
       echo -e "<click>gpk-update-viewer</click>"
fi

Im vorletzten Schritt machen wir das Script ausführbar, indem wir folgenden Befehl im Terminal ausführen

chmod +x <Pfad und Dateiname des Scripts>

Zum Schluss öffnen wir die Eigenschaften des Genmon-Plugins und tragen unter “Befehl” den Pfad inklusive Dateinamen unseres Scriptes sowie unter “Intervall” das Intervall für die Update-Prüfung ein. Persönlich würde ich ein Intervall von 3600 Sekunden (= 60 Minuten) empfehlen. Sobald Updates verfügbar sind, ändert sich das Icon in das selbe, welches PackageKit für die Anzeige von verfügbaren Icons verwendet.

Nichts desto trotz übernehmen wir keine Verantwortung, falls das eigene System durch diese Anleitung unbrauchbar gemacht werden sollte. Das Befolgen dieser Anleitung geschieht somit auf eigene Gefahr!