ArchLinuxeries – Page 55 – Le Weblog de Frederic Bezies

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.

KDE SC 4.4rc2 : premier aperçu :)

Comme jadis pour KDE 4.3 rc1, j’ai décidé de faire un petit test rapide de la future nouvelle version stable majeure de KDE. Du moins de cette 2ième candidate à la publication.

La feuille de route pour KDE SC 4.4 est disponible à cette adresse : http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule

J’ai donc installé une machine virtuelle avec une archlinux 64 bits dedans. Ben ouais, pourquoi ne pas employer une distribution linux qui est des plus proches du code original pour les logiciels ?

Donc, les habituelles lignes de commandes :

fred ~/download $ qemu-img create -f qcow2 kde44rc2.img 32G Formatting 'kde44rc2.img', fmt=qcow2 size=34359738368 encryption=off cluster_size=0 fred ~/download $ kvm -hda kde44rc2.img -cdrom archlinux-2009.08-netinstall-x86_64.iso -boot d &

Je laisse de coté les méandres de l’installation sur archlinux qui sont par ailleurs d’une simplicité enfantine si on lit le wiki francophone.

Après l’installation, j’ai installé yaourt, hal, alsa, et enfin configuré Xorg pour pouvoir accueillir tranquillement la release candidate de KDE SC 4.4, en utilisant le dépot kde-unstable.

NB : pour installer KDE depuis le dépot kde-unstable, il faut d’abord activer le dépot testing.

Continuer la lecture de « KDE SC 4.4rc2 : premier aperçu 🙂 »

Bretelle et ceinture : de l’intérêt d’avoir à la fois networkmanager et wicd installés.

Le dépot testing d’Archlinux est très rarement « explosif ». Sauf que récemment, une version de développement de NetworkManager est venue mettre une mouise pas possible dans les connexions. J’ai rapporté un bug (qui s’est révelé être le doublon d’un autre) dans lequel le dernier NetworkManager en date (0.7.998) bloquait entièrement Gnome 🙁

Heureusement, j’avais conservé sur mon disque l’outil Wicd dont je n’avais désactivé que l’applet d’affichage et de gestion de réseau. J’ai donc utilisé la séquence ctrl + alt + F2 pour ouvrir une console en mode texte. J’ai ensuite désactivé NetworkManager, réactivé Wicd, fermé la session. Les commandes ?

sudo /etc/rc.d/networkmanager stop sudo /etc/rc.d/wicd start

La combinaison ctrl + alt + F7 m’ayant permis de me retrouver à nouveau en mode graphique.

Pour que la modification soit prise en compte à chaque démarrage, j’ai désactivé le daemon networkmanager en lui rajoutant un ! avant son son nom dans la ligne DAEMONS de mon /etc/rc.conf :

DAEMONS=(syslog-ng !network netfs crond hal @alsa wicd !networkmanager cpufreq @iptables avahi-daemon avahi-dnsconfd pulseaudio @cups @openntpd sensors gdm)

Bref, une manipulation qui a pris, quoi, 5 minutes 🙂

Compiler Minefield sur les distributions linux « moins grand publics » – Partie 3 – ArchLinux.

Après la Frugalware Linux et la Slackware Linux, voici le dernier volet : La ArchLinux. J’ai installé et mis à jour une ArchLinux 64 bits. J’ai installé dessus un Xfce 4.6.1 à la place d’un Gnome. Pourquoi ? Simplement que je voulais utiliser un environnement basé sur gtk2 assez léger 😉

Sur Archlinux, le problème lié au bug 104642 sur le bugzilla de Mozilla se résout facilement.

Avec une installation par défaut d’Archlinux avec Xfce (ou encore Gnome), on a la quasi-totalité des dépendances de compilation. Seul manque autoconf 2.13, mercurial et zip. En utilisant l’excellent yaourt, le problème se résout en… 2 minutes :

yaourt -S autoconf-compat mercurial zip

Pour gagner du temps, j’ai utilisé le paquet du code source que j’utilise dans ma machine réelle. Il faut dire que le code source pèse quelque chose comme 600 MiO décompressé.

Sinon, pour récupérer le code source en entier :

hg clone http://hg.mozilla.org/mozilla-central/ src

Le code source est localisé dans ~/fox/src

Le fichier de configuration .mozconfig utilisé est le suivant :

#
# See http://www.mozilla.org/build/ for build instructions.
#

export AUTOCONF=autoconf-2.13

. $topsrcdir/browser/config/mozconfig

mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../objdir-fx

# Options for ‘configure’ (same as command-line options).
ac_add_options –enable-optimize
ac_add_options –disable-debug
ac_add_options –disable-tests

Ensuite on verifie que le code source est bien à jour :

hg --verbose pull -u

Et la compilation proprement dite :

make -f client.mk build

La compilation dure environ 90 minutes. Sur ma machine réelle, la compilation prend 25 minutes de moins, environ.

Le résultat est disponible dans le répertoire objdir-fx/dist/firefox/

Il suffit d’entrer un ./firefox & pour avoir le résultat.

Maintenant à vous d’adapter les instructions pour votre propre distribution, tant qu’elle est assez peu « grand public » 😉

Test de la KahelOS, version de noël 2009.

J’avais déjà parlé de KahelOS qui est le pendant « Gnome » de la Chakra Linux fin septembre 2009. J’ai donc récupéré la nouvelle iso officielle depuis le site de la distribution, puis je l’ai installé dans une machine virtuelle VirtualBox avec l’équipement classique : 1,5 GiO de mémoire vive et 32 GiO de disque dur.

KahelOS – version de noël

L’installateur se lance après le démarrage, et permet de définir l’heure, puis le partitionnement du disque, en proposant certaines options assez « sauvage », comme le système de fichier btrfs qui est encore dans les couches-culottes…

L’installation de base demande environ 3 GiO d’espace disque… Mais c’est une installation qui semble assez complète, ne serait-ce qu’au niveau des serveurs de Xorg…

Continuer la lecture de « Test de la KahelOS, version de noël 2009. »

Que devient ArchLive-iso ?

En juin 2009, j’avais rapidement testé le liveCD « ArchLive ». J’ai voulu voir comment se portait le projet 6 mois plus tard.

ArchLive – décembre 2009

Donc, après avoir récupéré la dernière image ISO en date sur le site officiel, à savoir http://godane.wordpress.com/, j’ai préparé mon environnement de test habituel :

fred ~/download $ qemu-img create -f qcow2 arch.img 32G Formatting 'arch.img', fmt=qcow2, size=33554432 kB fred ~/download $ qemu-kvm -hda arch.img -cdrom archiso-live-2009-12-08.iso -boot d &

Pour mémoire, l’alias qemu-kvm résume la commande suivante :

qemu-system-x86_64 --enable-kvm --soundhw all -localtime -k fr -m 1024

Après un lancement assez rapide, j’ai ouvert une session en utilisateur classique, Xfce 4.6.1 nous accueille, puis j’ai lancé l’installateur qui se trouve dans le menu système / installer archlive.

Continuer la lecture de « Que devient ArchLive-iso ? »

224 jours depuis mon retour sous archlinux… Bilan.

3 mai 2009 : je quitte Ubuntu Linux Jaunty Jackalope (alias 9.04) pour retourner sous Archlinux. Au bout d’un peu plus de 7 mois, j’ai eu envie de faire un petit bilan.

Coté logiciels ? Ma machine a connu sans trop de problème :

4 générations de noyau linux : du 2.6.29.2 installé début mai, la version actuelle est la 2.6.32, enfin si on utilise les dépots de tests d’Archlinux 😉
2 générations d’OpenOffice.org : la 3.0.x et la 3.1.x
2 générations de Gnome avec un passage sous KDE 4.3.x entre temps.

Sur le plan pratique : aucune réinstallation depuis 7 mois, alors que je réinstallais tous les 6 mois mon Ubuntu Linux, à l’époque de la version bêta. Autant dire un gain de souplesse incroyable.

Une distribution dont je comprend à peu près le fonctionnement, que je sais être modularisable, et sur laquelle je peux changer d’environnement de bureau ou de gestionnaire de fenêtre à volonté sans craindre de tout casser.

Un tranquillité d’esprit, et la possibilité de savoir que j’ai une machine rapidement à jour, quite à faire recompiler certains paquets, comme le noyau 2.6.32 avant qu’il ne soit disponible sur le dépot testing…

Bref, pour reprendre le slogan du site Distrowatch : « Put the fun back in computing. Use Linux, BSD », ce qu’on peut traduire par : « Remettez de l’amusement dans l’informatique. Utilisez Linux, BSD »

Une informatique à visage humain, quoi.

Du besoin d’une implémentation puissante et libre d’Adobe Flash – partie 3 – Gnash

Gnash est la deuxième alternative libre au greffon propriétaire Adobe Flash. Pour des raisons pratiques, et surtout pour avoir les résultats les plus à jour possible, j’ai récupéré une version de développement dite « bzr », via le paquet idoine sur aur.archlinux.org :

Pour avoir aussi le greffon flash pour le navigateur, j’ai modifié le fichier PKGBUILD :

# Contributor: Matthew Bauer
pkgname=gnash-bzr
pkgver=1
pkgrel=2
pkgdesc= »Gnash is an open source flashplayer. »
arch=(‘i686’ ‘x86_64’)
url= »http://www.gnu.org/software/gnash/ »
license=(‘GPL’)
depends=(‘agg’ ‘atk’ ‘libxml2’ ‘curl’ ‘libtool’ ‘ffmpeg’ ‘boost’ ‘pango’ ‘libxi’)
#ffmpeg-svn libdc1394
makedepends=(‘bzr’)
provides=(gnash-common gnash-gtk)
conflicts=(gnash-common gnash-gtk)

_bzrbranch=http://bzr.savannah.gnu.org/r/gnash/trunk
_bzrmod=trunk

build() {
cd ${srcdir}

msg « Connecting to the server…. »

bzr branch ${_bzrbranch} -q

msg « BZR checkout done or server timeout »
msg « Starting make… »

[ -d ./${_bzrmod}-build ] && rm -rf ./${_bzrmod}-build
cp -r ./${_bzrmod} ./${_bzrmod}-build
cd ./${_bzrmod}-build

sh autogen.sh
./configure –prefix=/usr \
–with-plugins-install=system \
–with-npapi-plugindir=/usr/lib/mozilla/plugins \
–disable-kparts \
–enable-gui=gtk \
–enable-z –enable-jpeg \
–enable-renderer=agg \
–enable-media=ffmpeg \
–enable-write \
–enable-avm \
–disable-cygnal
make || return 1
make DESTDIR=$pkgdir install install-plugin
}

L’option –enable-avm permet de compiler une version plus récente du langage actionscript.

La compilation se lance avec un petit makepkg.

Après 45 minutes de compilation, le paquet est prêt pour être installé avec un petit :

yaourt -U gnash-bzr-1-2-x86_64.pkg.tar.gz

Après avoir créé un lien symbolique du fichier /usr/lib/mozilla/plugins/libgnashplugin.so vers ~/.mozilla/plugins et relancé le navigateur, j’ai voulu tester les 3 sites que j’utilise principalement avec Adobe Flash : Youtube, Deezer et Dailymotion.

Les résultats ?

Du pire au meilleur.

Youtube : aucun controle pour les vidéos ne sont affichés. Surement une régression de la version de développement ?!

Dailymotion : les controles vidéos sont affichés, mais inactif.

Deezer : on peut se connecter, mais rien ne s’affiche 🙁

Autant dire qu’il y a encore de la progression possible envisageable pour les implémentations libre d’Adobe Flash.

Du besoin d’une implémentation puissante et libre d’Adobe Flash – partie 2 – swfdec

Swfdec est une des deux alternatives libre au greffon propriétaire Adobe Flash. Voulant tester une version récente, j’ai installé la version de développement 0.9.2 disponible sur AUR avec son extension pour être utilisable avec Mozilla Firefox.

Après avoir créé un lien symbolique du fichier /usr/lib/mozilla/plugins/libswfdecmozilla.so vers ~/.mozilla/plugins et relancé le navigateur, j’ai voulu tester les 3 sites que j’utilise principalement avec Adobe Flash : Youtube, Deezer et Dailymotion.

Les résultats ? Ecran noir sur Youtube, Deezer m’annonce que ma version d’Adobe Flash est trop vieille, et Dailymotion me plante le navigateur 🙁

J’ai donc voulu voir si c’était mieux du coté des versions de développement… Et le paquet ne se compile pas, que ce soit la version utilisant pulse-audio ou celle utilisant alsa :

libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wall -Wextra -Wno-missing-field-initializers -Wno-unused-parameter -Wold-style-definition -Wdeclaration-after-statement -Wmissing-declarations -Wmissing-prototypes -Wredundant-decls -Wmissing-noreturn -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Winline -Wformat-nonliteral -Wformat-security -Wswitch-enum -Wswitch-default -Winit-self -Wmissing-include-dirs -Wundef -Waggregate-return -Wmissing-format-attribute -Wnested-externs -Wunsafe-loop-optimizations -Wpacked -Winvalid-pch -Wsync-nand -Wlogical-op -Werror -std=gnu99 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -pthread -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -I.. -I./jpeg/ -I/usr/include/liboil-0.3 -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -DG_LOG_DOMAIN=\ »Swfdec\ » -march=x86-64 -mtune=generic -O2 -pipe -MT libswfdec_0.9_la-swfdec_as_string.lo -MD -MP -MF .deps/libswfdec_0.9_la-swfdec_as_string.Tpo -c swfdec_as_string.c -fPIC -DPIC -o .libs/libswfdec_0.9_la-swfdec_as_string.o
cc1: warnings being treated as errors
swfdec_as_string.c: In function ‘swfdec_as_string_split_5’:
swfdec_as_string.c:369: erreur: logical ‘&&’ with non-zero constant will always evaluate as true
make[4]: *** [libswfdec_0.9_la-swfdec_as_string.lo] Erreur 1
make[4]: quittant le répertoire « /tmp/yaourt-tmp-fred/aur-swfdec-git/swfdec-git/src/swfdec-build/swfdec »
make[3]: *** [all-recursive] Erreur 1
make[3]: quittant le répertoire « /tmp/yaourt-tmp-fred/aur-swfdec-git/swfdec-git/src/swfdec-build/swfdec »
make[2]: *** [all] Erreur 2
make[2]: quittant le répertoire « /tmp/yaourt-tmp-fred/aur-swfdec-git/swfdec-git/src/swfdec-build/swfdec »
make[1]: *** [all-recursive] Erreur 1
make[1]: quittant le répertoire « /tmp/yaourt-tmp-fred/aur-swfdec-git/swfdec-git/src/swfdec-build »
make: *** [all] Erreur 2

Bref, ce n’est pas la joie. J’espère que Gnash – objet du prochain article – s’en tirera un peu mieux !