Transcyberien

Cela fait plus d'un an que j'utilise un Canon Powershot A610 comme appareil photo. Il fonctionne très bien, je n'ai jamais eu de problème avec, il est assez complet pour une utilisation pas trop poussée (oui, c'est pas non plus un reflex), j'apprécie le fait d'avoir un mode manuel pour m'exercer aux réglages d'ouverture, de temps d'exposition (enfin, de quoi faire des expériences plus ou moins réussies), je trouve son écran pivotant vraiment utile... en résumé, j'en suis très content .

Pour gérer mes photos, j'ai toujours utilisé digikam qui est très complet et auquel on peut ajouter de nombreux plug-ins. Néanmoins, la dernière fois que j'ai voulu télécharger mes photos depuis l'appareil, impossible pour l'APN d'être reconnu. En fait, cela venait d'une mise à jour de libgphoto2, librairie utilisée pour la communication avec les APN. Dans cette nouvelle version, il n'est plus nécessaire de compiler tous les pilotes pour l'ensemble des APN supportés, il suffit de définir dans son make.conf la variable CAMERAS avec les valeurs souhaitées. J'ai donc indiqué CAMERAS="canon". Et là fut mon erreur, car il faut savoir que certains appareils, bien que d'une certaine marque, ne sont gérés que par protocole PTP et non pas comme simple périphériques de stockage (usb mass storage). Il faut donc ajouter la valeur ptp2 à CAMERAS. Désormais, avec CAMERAS="canon ptp2", cela fonctionne parfaitement. J'ai gardé la valeur canon, bien que ça ne doit pas être nécessaire.

Peut-être qu'un jour il y aura une galerie sur ce blog...

Voilà une phrase incompréhensible à toute personne ne connaissant pas Gentoo. Pourtant, il est nécessaire de lui faire de la pub mais ce n'est pas vraiment le sujet d'aujourd'hui. Pour tout utilisateur de Gentoo, son gestionnaire de paquet portage est sans doute l'outil donc il n'arriverait plus à se passer. Et pour utiliser portage on se sert de l'interface emerge.

Lors d'une mise-à-jour du système, il n'est pas rare d'avoir quelques dizaines de paquets à mettre à niveau. Or, pour autant que regarder ces compilations pendant des dizaines de minutes (heures ? oui ça arrive aussi ) peut sembler passionnant, l'utilisateur a sûrement autre chose à faire pendant ce temps-là. Donc, tout se passe bien et à la fin tous les paquets sont installés. Emerge nous indique que certains fichiers de configurations sont à mettre à jour, ok. Mais il arrive aussi que certains paquets donnent des avertissements ou tout autre bon conseil à la fin de son installation... messages qu'on voudrait bien retrouver pour ne pas rester dans l'ignorance mais on a rarement accès à tous les milliers de lignes de compilation. Fort heureusement, il existe un script écrit par Eldad Zack et Lindsay Haisley appelé enotice.

Le plus simple pour l'installer est sûrement d'utiliser l'ebuild fourni. Celui-ci étant non-officiel, il faut le placer dans le répertoire des overlays. Ce répertoire est défini dans le make.conf sous le nom de PORTDIR_OVERLAY généralement égal à /usr/local/portage. On va donc se placer dans ce répertoire et y placer l'ebuild. Enfin, pas directement. Il faut recréer une arborescence analogue à celle de l'arbre de portage. Ainsi, enotice étant un utilitaire pour portage lui-même, je propose de créer le répertoire app-portage/enotice et d'y placer l'ebuild. Ensuite, il faut générer le digest de cet ebuild :

ebuild /usr/local/portage/app-portage/enotice/enotice-0.2.9.1.ebuild digest
Maintenant, enotice est connu  de portage mais il est considéré non stable. Il faut donc rajouter app-portage/enotice dans le fichier package.keywords. La commande emerge -p enotice permet de vérifier que tout s'est passé comme souhaité. Avant de l'installer, il faut indiquer le répertoire de stockage des messages dans le make.conf avec la variable PORT_ENOTICE_DIR qui peut être définie avec /var/tmp/portage/enotice mais personnellement j'ai indiqué /var/log/enotice.

Pour l'utiliser, c'est tout simple, après avoir installé quelques paquets, on tape enotice et apparaissent des options qu'il suffit de choisir .

Il existe des petites choses qu'on trouverait plus faciles si elles étaient réalisées de façon naturelle. Ici, je parlerai de liens (URL, mailto). Et s'il est vrai que sous Windows les relations entre navigateur et client de messagerie sont gérées de façon assez transparente (en choisissant  ses applications par défaut), sous Linux cela m'a semblé moins évident. En même temps, c'est une des forces de Linux, de laisser l'utilisateur choisir du bon comportement de son système. Bref, on ne va pas épiloguer là-dessus.

1. Ouvrir Thunderbird grâce à un lien mailto

Pour faire simple et ne pas éditer nous-mêmes le fichier ~/.mozilla/firefox/5dbm5fc0.default/user.js (il est quand même bon de savoir que c'est ce fichier qui contient les préférences utilisateur de Firefox) ou le fichier prefs.js, on va utiliser l'onglet about:config (à taper dans la barre d'adresse). Ensuite, clic droit > Nouvelle > Chaîne de caractères puis on entre network.protocol-handler.app.mailto puis comme valeur /usr/bin/thunderbird. C'est pas plus compliqué. Comme vous vous en doutez, on peut également choisir un autre client mail.

2. Ouvrir Firefox par l'intermédiaire d'une URL contenue dans un e-mail.

Là non plus pour ne pas aller chercher le fichier prefs.js, on va utiliser les moyens mis à notre disposition c'est-à-dire la même boîte de configuration que précédemment, about:config. Pour Thunderbird, on la trouve dans Edition > Préférences > Avancé > Éditeur de configuration... mais on peut aussi installer cette extension qui permet d'y accéder directement dans le menu Outils.

Dans cet éditeur, on crée 3 nouvelles chaînes de caractères et on inscrit les différents noms suivants :

• network.protocol-handler.app.http
• network.protocol-handler.app.https
• network.protocol-handler.app.ftp

Et comme valeur, on entre à chaque fois /usr/bin/firefox. Encore une fois, Firefox n'est qu'une suggestion, cela fonctionne également avec Opera ou Konqueror.

3. Ouvrir un lien depuis XChat avec Firefox, Opera ou Konqueror.

On est parti dans Paramètres > Avancés > Gestionnaires d'URL. Dans la colonne nom, on peut mettre Ouvrir avec Firefox, par exemple, et la commande sera !firefox %s. Le point d'exclamation signifie qu'il s'agit d'une commande à exécuter et %s reprend l'URL fournie. Par la suite, il suffit de faire un clic droit sur une URL et tester que cela fonctionne correctement. On peut le faire pour Opera avec la commande !opera %s ou pour Konqueror avec !konqueror %s.

Sorti fin novembre, il est considéré par Linus Torvalds comme l'un des meilleurs noyaux sortis (je vous laisse traduire) :

It's one of those rare "perfect" kernels. So if it doesn't happen to compile with your config (or it does compile, but then does unspeakable acts of perversion with your pet dachshund), you can rest easy knowing that it's all your own d*mn fault, and you should just fix your evil ways.

Je passe outre les nouveautés et améliorations, la plupart m'échappant totalement, mais je voulais indiquer une technique qui sera sûrement provisoire pour que certains modules hors kernel puissent être compilés sans problèmes. En effet, comme je l'indiquais dans ce commentaire, module-rebuild est très utile mais quand j'ai voulu l'utiliser, aucun des modules ne compilaient, en particulier x11-drm nécessaire pour avoir l'accélération graphique. Cela vient en fait de la disparition du fichier config.h qui se trouvait précédemment dans /usr/src/linux/include/linux/ . Pour avoir une compatibilité, il suffit de l'inclure à nouveau, c'est-à-dire créer ce fichier dans le répertoire indiqué, prendre son éditeur préféré (vim,nano,...) et y inscrire les quelques lignes suivantes :

#ifndef _LINUX_CONFIG_H
#define _LINUX_CONFIG_H
/* This file is no longer in use and kept only for backward compatibility.
 * autoconf.h is now included via -imacros on the commandline
 */
#include <linux/autoconf.h>
#endif

Voilà, reste à relancer un

module-rebuild rebuild

et ça devrait mieux marcher maintenant .