Gwibber 2.30 en dehors d’Ubuntu Lucid Lynx… Quel bilan ?

J’ai voulu voir sur le top 10 des distributions de distrowatch lesquels – en dehors d’Ubuntu – qui peuvent proposer un Gnome 2.30, prérequis pour pouvoir utiliser Gwibber 2.30. Pour chaque distribution, j’ai utilisé qemu, soit avec une image ISO 32 bits (pour Mandriva ou encore PCLinuxOS), ou une image ISO 64 bits (pour les autres).

C’est aussi – en quelque sorte – une réponse à ce commentaire : https://blog.fredericbezies-ep.fr/?p=3791&cpage=1#comment-12467

C’est un article assez long, avec une grosse quinzaine de captures d’écran, mais j’ai voulu être le plus complet et le plus vérifiable possible.

On verra bien si je suis selon les propos de certains commentaires un « anti-ubuntu primaire » ou encore un « anti-logiciel libre primaire » 🙂

Dans la mesure du possible, j’ai utilisé des versions proposant directement Gnome dès l’installation, si possible en liveCD.

Le top 10 au 24 avril 2010 est le suivant :

  1. Ubuntu
  2. Fedora
  3. Mint
  4. OpenSuSE
  5. Mandriva
  6. Debian
  7. PCLinuxOS
  8. Sabayon
  9. Arch
  10. Mepis

Dans la liste, on peut sortir 3 distributions : Ubuntu, Mint (qui est fortement basée sur Ubuntu et dont la version 9 se basera – sauf information contraire – sur Ubuntu 10.04), et Mepis qui ne propose pas de version avec Gnome.

Continuer la lecture de « Gwibber 2.30 en dehors d’Ubuntu Lucid Lynx… Quel bilan ? »

Coup de gueule : Ubuntu devient-il vraiment le Microsoft du logiciel libre ?

Je voudrais pousser un coup de gueule contre Ubuntu et les technologies qu’elles developpent pour forcer à l’utilisation de sa distribution au détriment des autres distributions.

L’exemple parfait est la technologie desktopcouch, surcouche de couchdb. Conçue pour fonctionner plus ou moins uniquement sur ubuntu, même si on peut trouver des références sur le site freedesktop, elle est une des composantes essentielles de la future version de Gwibber, la 2.30 (?).

On appelle ceci d’une manière très claire : la méthode du cheval de Troie.

J’ai relaté dans un billet précédent mes doutes concernant l’intérêt des développeurs de gwibber pour les autres distributions qu’Ubuntu.

A la suite de commentaires où l’on m’a fait comprendre que j’étais paranoiaque, une partie d’un commentaire a levé le lièvre dont j’attendais la confirmation :

Ce n’est pas la faute des développeurs Ubuntu si DesktopCouch est cassé sur Arch mais bien la faute des mainteneurs Archlinux.

C’est toi qui te fous de la gueule du monde a réclamer de la stabilité et un fichier INSTALL sur une version trunk. C’est comme si j’espérais que tout soit parfait sur Lucid Lynx 3 mois avant sa sortie

Et surtout :

Maintenant je ne peux que t’encourager a lire cette page : http://doc.ubuntu-fr.org/desktopcouch et quand tu aura compris que DesktopCouch ne fonctionne pas sur ta machine alors peut être que tu reverra ton jugement.

Le plus con pour la personne qui a balancé ce commentaire, c’est que j’ai pu utiliser des versions de Gwibber utilisant desktopcouch et qui était fonctionnelle, comme pour l’article où je parlais justement de cette nouvelle version revampée de Gwibber.

En ce qui me concerne, je ne toucherais plus à Gwibber et je resterais à la version 2.0 du logiciel, en attendant que Pino ou un autre client pour twitter et identi.ca vraiment léger sorte.

J’ai adoré utiliser les versions d’Ubuntu entre la Dapper et la Jaunty, soit deux ans et demi, mais trop c’est trop.

Y en a marre de cette équation Ubuntu = GNU / Linux qui pourrit la vie des utilisateurs qui sont passés par Ubuntu puis à une autre distribution.

PS : merci à Stricore pour sa dernière réflexion : https://blog.fredericbezies-ep.fr/?p=3401&cpage=1#comment-11995

« gros boulet »….

Je n’en attendais pas moins.

Pour les codeurs de gwibber, ubuntu n’est que la seule distribution à gérer ?

Je parlais il y a quelque jours de la nouvelle version de Gwibber, qui paraissait bien alléchante, malgré l’ajout d’une couche supplémentaire de dépendance, répondant au nom de Desktopcouch qui installe une bonne dizaine de paquets supplémentaires.

Il y a 5 jours, arrive la révision 503, qui part d’une bonne idée. Comme desktopcouch est indispensable au fonctionnement de cette version de gwibber, autant vérifier qu’elle démarre avant gwibber… Et patatras… Gwibber se viande en beauté au démarrage, balançant une erreur qui met clairement en cause desktopcouch :

Traceback (most recent call last):
File « /usr/bin/gwibber », line 45, in
obj = dbus.SessionBus().get_object(« org.desktopcouch.CouchDB », « / »)
File « /usr/lib/python2.6/site-packages/dbus/bus.py », line 244, in get_object
follow_name_owner_changes=follow_name_owner_changes)
File « /usr/lib/python2.6/site-packages/dbus/proxies.py », line 241, in __init__
self._named_service = conn.activate_name_owner(bus_name)
File « /usr/lib/python2.6/site-packages/dbus/bus.py », line 183, in activate_name_owner
self.start_service_by_name(bus_name)
File « /usr/lib/python2.6/site-packages/dbus/bus.py », line 281, in start_service_by_name
‘su’, (bus_name, flags)))
File « /usr/lib/python2.6/site-packages/dbus/connection.py », line 622, in call_blocking
message, timeout)
dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Spawn.ChildExited: Launch helper exited with unknown return code 1

[1]+ Exit 1 gwibber

Un bug dédié est ouvert, mais impossible de faire comprendre la culpabilité de la révision citée au-dessus. Tant que cela fonctionne avec Ubuntu, les autres distributions, vous savez où vous pouvez aller ?

J’ai donc pris le taureau par les cornes, et j’ai adopté le paquet qui permettait à une époque de compiler Gwibber 2.0 sur Archlinux. Ayant corrigé le PKGBUILD en question, désormais – même si la branche 2.0 de Gwibber n’aura plus de mise à jour, au moins, il y aura un gwibber fonctionnel sur Archlinux !

C’est quand même assez écoeurant de voir un tel manque de respect envers les non-utilisateurs d’ubuntu… Je sens que je vais me faire traiter de tous les noms, mais comme les infos sont disponibles…

Le futur Gthumb 2.12 sera-t-il l’outil qui fera oublier f-spot ?

F-spot est un excellent outil de gestion de photos, mais il a un énorme défaut : il utilise mono pour fonctionner. Un de ses avantages est l’export vers des galeries en ligne comme PicasaWeb ou encore Flickr.

L’un des outils gnome principaux pour la gestion des photos, GThumb, actuellement en version stable 2.10, ne supporte pas l’export vers les dites galeries. Cependant, depuis aujourd’hui, les versions de développement, alias les 2.11.x le permettent. Au moins pour le moment, vers picasaweb.

Le seul moyen d’obtenir une version qui permet cela, c’est de la compiler. La page de développement explique comme compiler depuis la reine des distributions, et même pour Fedora (joie !).

Pour Archlinux, il suffit d’entrer un petit :

yaourt -S gthumb-git

Et d’attendre que le code soit compilé pour installer le logiciel.

Ensuite, il faut activer l’extension, puis redémarrer le logiciel pour permettre l’envoi vers PicasaWeb.

Ensuite, en utilisant le menu File / Export to… on peut envoyer les photos en ligne. Les captures d’écrans qui suivent sont suffisamment parlantes.

On crée l’accès au compte en ligne.

Ensuite, on crée l’album.

Et enfin, on envoie les données.

Je suis heureux de voir cette fonctionnalité rajoutée. Cela me fera gagner pas mal de temps quand j’aurais besoin d’envoyer plus de 5 images sur mon espace PicasaWeb 😉

Un aperçu de lxde 0.5

Je me suis basé sur la machine virtuelle du précédent article pour tester lxde 0.5, le « lightweight X Desktop Environment ».

L’installation est simplissime ; il suffit de taper dans une console :

yaourt -S lxde

Le coeur de cet environnement de bureau qui repose sur openbox se charge. J’ai ensuite rajouté midori et les paquets lxde-input et lxnm pour compléter l’environnement.

Pour lancer l’environnement, j’ai simplement rajouter la ligne suivante au fichier .xinitrc disponible à la racine du compte utilisateur :

exec startlxde

Ensuite, lxde se lance avec un petit :

startx

NB : à cause d’un bogue d’openbox, il faut réduire la profondeur d’affichage à 16 bits dans le fichier /etc/X11/xorg.conf au lieu du 24 bits proposé par défaut.

J’ai enregistré une petite vidéo (saccadée, et contrairement à ce que j’avais affirmé dans l’article précédent), ce n’est pas du à la gourmandise de l’environnement de bureau, mais à un mauvais réglage du logiciel de capture vidéo 🙁

Néanmoins, cela permet de voir à quoi ressemble lxde 0.5 brut de fonderie.

Encore jeune, car certains outils sont franchement rudimentaires, mais il a du potentiel face à des environnements de bureau plus gourmand comme xfce, gnome ou encore kde.