Effectuer une rotation des vidéos faîtes avec son APN sous linux

Il y a quelques temps, j’ai cherché comment effectuer une rotation des vidéos. C’est utile lorsque l’on filme avec son APN en vertical, mais qu’il ne dispose pas de fonction de rotation du film (c’est le cas de mon Canon Ixus 65).

La commande nécessite mencoder (qui nécessite lui-même mplayer) et est finalement très simple, mais la quantité d’options dans mencoder/mplayer risque de décourager plus d’un lecteur de manpages. La voici :

mencoder -oac copy -ovc lavc $1 \\
-o $1_rotated.avi -vf rotate,mirror

« $1 » étant le fichier à tourner. Vous obtiendrez en sortie le fichier « $1_rotated.avi » (le fichier original n’est pas perdu). Il suffit de mettre cette ligne dans un fichier que l’on rend exécutable et on obtient un script.

Publicités

Pilote « intel » pour X11 expérimental

Juste un petit billet pour dire que j’ai récemment basculé vers le pilote expérimental « intel » dans la Mandriva Linux 2007 Spring. Ce pilote pour X11 utilisable pour la plupart des cartes graphiques intel est amélioré à plusieurs niveaux et est livré dans la 2007 Spring. Il est néanmoins nécesaire, pour l’utiliser de changer de version du serveur xorg (ce qui procure en bonus les extensions randr 1.2) et de faire quelques manips à la main qui sont très bien expliquées ici :

Experimental_Intel_driver (en anglais)

J’apprécie énormément plus ce pilote que le précédent (i810) pour plusieurs raisons :

  • Je n’ai plus cette apparence « floue » que j’avais auparavant, certainement due à un rafraîchissement incorrect
  • Il m’est maintenant possible de connecter ma télévision sous linux « à chaud », mais malheureusement, l’image apparaît en noir et blanc (après plusieurs essais avec xrandr, je n’arrive pas à l’avoir en couleur)…
  • Il est possible de changer de résolution dynamiquement. Cela était aussi possible auparavant avec krandrtray, mais maintenant, cela semble bien mieux supporté par Xorg.
  • L’affreux service 915resolution n’est plus utile à chaque démarrage. Ce dernier service lance un programme qui modifie le BIOS pour qu’ensuite, le pilote puisse correctement détecter la résolution. Mais bon, c’est assez foireux comme solution, vous l’admettez.

J’ai néanmoins deux petits problèmes avec, mais qui ne me gênent pas personnellement :

  • Beryl, compiz, compiz-fusion (oui, sachez qu’il est disponible désormais dans la 2007 Spring si vous activez les backports) ne marchent pas : retour à mon thème favoris pour KDE : Serenity)
  • Me délogger suffit à planter X (mais il ne plante pas quand je suis dans la session, même en le poussant avec des films, des applis 3D et des sites flash)

Voilà.

Dernier point : si au moins 3 d’entre vous me demandent une traduction de l’article dont je donne le lien ci-dessus en français, ce sera fait 😉

News en vrac

À peine revenu de mes (courtes) vacances en Normandie, j’ai déjà pleins de nouveautés qui m’attendent au tournant.

  • Compiz-fusion est maintenant disponible pour la Mandriva 2007 Spring. Pour cela, il faut configurer les backports, comme d’hab. Je ne l’ai pas encore testé.
  • Manslide 1.6 est lui aussi disponible. Si ma mémoire est bonne, il n’était pas du tout disponible pour la 2007 Spring, mais uniquement dans cooker. Testez ce petit bijou pour concocter de beaux diaporamas. Ensuite, vous pouvez les graver sur DVD avec son excellent complément ManDVD.
  • Ordipost : on en parle de plus en plus et un peu partout…
  • Une nouvelle interface serait en préparation pour la gestion des connexions dans la 2008 !
  • ClamAV et Xen sont rachetés par des boîtes de softs proprios… espérons que cela ne va pas nuire à ces projets
  • Le kernel 2.6.22-6mdv est disponible pour cooker et, si vous suivez ce blog, vous savez que je tourne justement ce kernel cooker sur ma machine. Cette fois-ci, j’ai eu des petites difficultés à l’installation car le initrd n’a pas été généré correctement (pour une raison inconnue car après l’avoir regénéré à la main, il a marché de suite…). J’écrirais une partie 3 à mon article sur ce kernel sous Mandriva 2007.1 comprenant mes conclusions sur ce qu’il apporte.
  • Aussitôt après la sortie du 2.6.22-6mdv, le 2.6.22.3-1mdv est sorti (oui oui, les numéros de version sont corrects, lisez la suite). En fait, le paquet du 2.6.22-6mdv a été généré avec « l’ancienne méthode » qui comporte un gros tas de patches indigestes (parfois inutiles et complexes). Thomas Backlund a généré un nouveau paquetage avec sa propre méthode et a revu chacun des anciens patches appliqués au noyau afin d’obtenir quelquechose de plus simple au final. Il est possible qu’il y ait des régressions par rapport aux anciens noyaux et c’est pourquoi il a demandé à tout le monde de tester. Ce changement n’a pas uniquement un impact pour les développeurs (comme le souligne Olivier (blino)), mais aussi pour les utilisateurs, :
    • On peut maintenant utiliser un paquetage « kernel-devel » plus compact afin de construire ses modules (plus besoin de l’ensemble des sources du noyau linux)
    • Trois types de noyaux sont maintenant générés : kernel-desktop586 (pour les anciens systèmes), kernel-desktop, kernel-server et kernel-laptop. C’est nettement plus explicite qu’auparavant et les bénéfices sont nombreux (le kernel-laptop est par exemple optimisé pour consommer un minimum de batterie).
    • Suivre les évolutions du noyau linux et les incorporer dans Mandriva sera plus facile

    Reste quelques idées intéressantes qui ont été lancées mais seront-elles suivies jusqu’au bout ?

    • Un paquetage des noyaux -rt (temps réel) et -mm (noyau avec des fonctionnalités expérimentales) : disponible pour cooker, mais il est possible qu’ils ne soient pas maintenus après la sortie de la 2008
    • Une compilation de tous les paquetages dkms à chaque nouvelle sortie d’un noyau linux. Il en résulterait des paquetages « statiques » (utilisables uniquement avec un seul noyau) mais beaucoup plus simple à installer pour l’utilisateur final (plus besoin de dkms, des sources du noyau, d’un compilateur, etc…)
Publié dans Mandriva. 5 Comments »

Utiliser le kernel 2.6.22 avec Mandriva 2007.1 – partie 2

Suite de mon précédent article sur l’installation du kernel 2.6.22 sous Mandriva 2007 Spring.

J’ai réussi à configurer le réseau sous Mandriva 2007 Spring et le nouveau kernel 2.6.22 provenant de cooker. J’aurais aimé une solution plus « propre », c’est à dire patcher ou modifier les drakxtools pour qu’il reconnaisse le nouveau driver iwl3945 de ma carte wifi. Mais le code des drakxtools est assez obscur pour moi et pas mal de choses sont hardcodées, ce qui rend leur édition difficile (bon, puisque c’est du perl, il est possible directement d’éditer les binaires et cela ne nécessite pas de recompilation, mais quand même).

J’ai donc utilisé la bonne vieille méthode qui marche sur tous les linux (qui utilisent udev en tout cas). Il faut, en fait, agir à trois niveaux.

1 – udev

udev se charge de nommer les périphérique et les initialiser à un niveau assez bas. Autrement dit, sa config n’est pas des plus évidentes, en tout cas pour moi. Mais en gros, il repère certaines des caractéristiques de vos périphériques et leur assigne ensuite un nom. Tout ceci se fait sur base de règles plus ou moins obscures mais c’est la distribution qui se charge de créer ces règles.

Dans le cas du nouveau module iwl3945 qui se charge de ma carte wifi, il semble que ce module créée deux interfaces avec la même adresse MAC (nommées wmaster0 et wlan0). Or, Mandriva renomme les interfaces pour leur donner un nom standard (en ethX), quel que soit le pilote. Pour donner ce nom, Mandriva se base sur l’adresse MAC pour identifier une interface ce qui semble logique en somme puisque, en théorie, l’adresse MAC est unique pour toutes les interfaces dans le monde entier, mais donc dans ce cas, les deux interfaces entrent en conflit et si c’était possible, les deux interfaces auraient le même nom (mais le noyau passe par là et n’est pas très content). Bref, pour résumer, ça ne marche pas car Mandriva n’a jamais prévu qu’on pouvait avoir deux interfaces avec la même adresse MAC et le pilote iwl3945 justement créée ces deux interfaces.

Mandriva conserve l’association entre nom d’interface et adresse MAC dans une règle udev : /etc/udev/rules.d/61-net_config.rules. C’est donc ce fichier qui renomme les deux interfaces. Dans ce fichier, il faut préciser à udev comment distinguer les deux interfaces. Une manière pour les distinguer est d’utiliser le type d’interface : on lit ce type dans /sys/class/net/nom_de_linterface/type. L’une des interfaces est de type 1 et l’autre de type 801 (ne me demandez pas ce à quoi cela correspond). J’ai donc rajouté ces deux lignes dans le fichier de règle en supprimant la ligne qui désignait mon interface en tant que « ethX » (avec la même adresse MAC).

SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*", SYSFS{address}=="00:18:de:4c:1d:43", ATTRS{type}=="1", NAME="wlan0", ENV{MDV_CONFIGURED}="yes"
SUBSYSTEM=="net", ACTION=="add", ENV{INTERFACE}!="*.*", SYSFS{address}=="00:18:de:4c:1d:43", ATTRS{type}=="801", NAME="wmaster0", ENV{MDV_CONFIGURED}="yes"

Ensuite, on peut charger le module avec modprobe iwl3945 : deux interfaces doivent effectivement apparaître quand on tape « iwconfig », l’une nommée wlan0 et l’autre wmaster0. Dans la suite, j’ignore wmaster0 (sa fonction n’est pas l’objet de ce billet – autrement dit, je ne sais pas à quoi elle sert :-))

2 – wpa_supplicant

Bon, vous êtes toujours là ? Ne vous inquiétez pas, la suite est beaucoup plus facile.

Pour mon réseau, comme tout bon réseau sans-fil qui se respecte normalement, j’utilise l’encryption WPA. Heureusement, comme j’avais déjà configuré mon interface avant de passer au nouveau noyau, je n’ai pas à trifouiller les fichiers de configuration de wpa_supplicant (le démon qui s’occupe de gérer le protocole WPA) et je n’ai qu’à le lancer. Il se lance avec la commande suivante :

# /usr/sbin/wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf

Attendez quelques secondes et vous devriez voir disparaître le « unassociated » à côté de votre interface lorsque vous tapez « iwconfig ». Si c’est le cas, vous êtes associés à votre point d’accès (c’est comme si vous aviez branché votre câble UTP pour un réseau filaire).

3 – dhclient

La suite n’est qu’une histoire de connexion classique : vous devez obtenir une adresse IP qui vous est généralement donnée par votre routeur. Pour cela, lancez le client DHCP « dhclient » de la manière suivante :

# dhclient eth0

Voilà, si vous avez la net_applet active au moment où vous faisez ces manipulations, elle devrait vous indiquer que vous êtes maintenant connecté à l’internet via votre interface « wlan0 ».

Choisir son langage sous Mandriva

J’ai décidé de faire un article sur la manière dont Mandriva traite la problèmatique des langues des logiciels car certains points ne sont pas si évidents pour un débutant (et même certains confirmés). Cet article peut très bien d’appliquer aussi à d’autres distributions, mais pour avoir essayé OpenSuse, je sais que le problème est parfois abordé différemment.

Tout d’abord commençons par un problème (que justement, il me semble qu’OpenSuse ne connaît pas) : il n’est pas possible d’ajouter une langue à son système après l’installation. Pourquoi ? L’explication n’est pas si simple, mais on va essayer de la démystifier.

Dès qu’un logiciel souhaite afficher un mot ou une phrase, il fait appel à une fonction qui va tenter de traduire la phrase ou le mot : on appelle cela internationaliser le logiciel (définition sur wikipedia). Sous linux, le système le plus utilisé (si ce n’est l’unique) est gettext qui fournit justement cette fonction et tout un tas d’outils pour aider à traduire un logiciel. Internationaliser n’est qu’une affaire de code , mais pour qu’un logiciel soit traduit, il faut aussi le localiser ou le régionaliser (définition sur wikipedia), ce qui signifie traduire chacune des phrases utilisée et stocker tout cela dans un fichier « .mo » (qui est généré par gettext).

Lorsqu’un logiciel est traduit en plusieurs langues, on se retrouve avec un fichier « .mo » par langue. Tous ces fichiers sont inclus dans le paquetage RPM du logiciel. La taille de tout cela est parfois importante et l’utilisateur n’a généralement que faire des langues qu’il n’utilisera pas. C’est pourquoi lorsque l’on installe un fichier RPM, le logiciel rpm (et donc urpmi et drakrpm bénéficient de cette fonctionnalité aussi) détermine quelles langues doivent être installées (et quels fichiers .mo se retrouveront sur le système). Sous Mandriva, rpm détermine cela grâce au fichier /etc/rpm/macros. Ce fichier est créé à l’installation : il contient les langues que vous avez choisi avec l’installateur Mandriva. Il n’existe aucun outil graphique, à ma connaissance, qui modifie ce fichier et si vous voulez le modifier après coup, il vous faudra le faire à la main. C’est pourquoi le choix des langues à l’installation est capital.

Justement, j’ai dit plus-haut qu’il n’était pas possible de rajouter une langue après installation de Mandriva. Aurais-je menti si finalement on peut le faire à la main ? Et bien en fait, je n’ai pas menti car ce n’est pas si simple. Si vous avez bien suivi les paragraphes précédents, c’est rpm qui détermine les langues dont vous avez besoin et rpm n’est utilisé qu’à l’installation d’un paquetage. Donc si vous modifiez le fichier macros, vos modifications ne seront prises en compte que lors de l’installation de nouveaux paquetages. Si vous voulez changer la langue d’un logiciel déjà installé, il vous faudra modifier le fichier macros, désinstaller le logiciel, puis le réinstaller. Et si vous voulez avoir tous les logiciels isntallés dans une langue que vous n’avez pas choisi à l’installation de la distribution, il vous faudra désinstaller et réinstaller chaque paquetage, ce qui revient à tout réinstaller, CQFD.

J’ai néanmoins parlé « d’ajouter » une langue parceque le système peut gérer plusieurs langues. Et c’est là une caractéristique intéressante des systèmes linux. Chaque utilisateur est libre d’utiliser la langue qu’il souhaite pourvu qu’elle soit installée sur le système. D’où un immense avantage lorsque vous avez plusieurs utilisateurs sur un même système, mais dans des régions du monde très différentes et qui aimeraient avoir leur environnement dans la langue de leur choix.

Passons un peu à la pratique : sur mon système, le fichier /etc/rpm/macros contient %_install_langs en_US:en:en_GB:en:fr_FR:fr. Je peux donc avoir mes applications en français et en anglais. Pour le choix de ma langue, il suffit de lancer localedrake et j’aurais accès à toutes les langues de mon système parmi lesquelles je pourrais faire mon choix mais le problème est que cela nécessite de sortir de ma session. Plus simplement, il suffit de changer une variable d’environnement pour avoir l’application dans la langue de mon choix : c’est la variable « LANGUAGE ».

Ainsi la ligne de commande suivante lance gcalctool en français :
LANGUAGE=fr gcalctool
La ligne suivante lance le calculateur en anglais :
LANGUAGE=en gcalctool
Et il existe une variable spéciale qui va lancer gcalctool sans traduire du tout le logiciel (ce qui dans le cas présent revient à l’avoir en anglais, mais certains logiciels présentent des différences) :
LANGUAGE=C gcaltool

Lorsque vous changez la variable LANGUAGE, la fonction chargée de traduire le logiciel va rechercher le fichier .mo correspondant dans le répertoire /usr/share/locale/LANGUAGE/LC_MESSAGES/ : s’il existe, il sera utilisé et toutes les phrases traduites dans ce fichier seront affichées à la place de la phrase non-traduite (généralement en anglais). Si elle n’existe pas, alors la traduction échoue et vous retrouverez une phrase non-traduite. C’est pourquoi dans certains logiciels, vous aurez un mélange d’anglais et de français : certaines phrases n’ont pas été traduites. Si vous voulez aller plus loin, la page d’info sur gettext regorge d’informations à ce sujet (dans konqueror, il suffit de taper « info:/gettext ») ou alors sur le site de gnu.

Il me reste une dernière chose à signaler qui peut coûter cher, surtout en cette période de beta test où certains seront tentés par la mise à jour vers un béta, une RC ou vers la 2008. Quand le paquetage « rpm » est mis à jour, le fichier /etc/rpm/macros étant vu comme un fichier de configuration, drakrpm ne l’écrase pas mais affiche une boîte de dialogue qui peut en dérouter plus. En effet, il pose la question de savoir s’il faut utiliser le .rpmnew ou supprimer le .rpmnew. Lorsqu’on ne sait pas exactement ce que cela signifie, on est tenté de ne rien supprimer et on se dit « je vais choisir le premier », ce qui consistue une erreur, puisque votre fichier macros sera remplacé par un fichier vide et toutes les applications que vous installerez par la suite ne seront pas traduites. Faîtes donc attention à ce fichier car même s’il est peu connu il est assez capital pour un non-anglophone.

Powered by ScribeFire.

Publié dans Mandriva. 7 Comments »

KDE 4.0 Beta 1 est disponible pour Mandriva 2007.1

Attention : La Beta1 n’est pas aussi stable qu’on pourrait s’y attendre et la beta2 reflêtera plus vraisemblablement ce qu’est réellement KDE4. Alors vous feriez mieux de l’installer sur une machine de test ou virtuelle. (Merci à Daniel Beck)

Oui !

  • urpmi.addmedia kde4 <KDE_MIRROR>/pub/kde/unstable/3.92.0/Mandriva/2007.1/i586/media/4.0
  • Mettre à jour Mandriva Linux avec sa méthode préférée
  • C’est tout

Je ne peux pas la tester car je dois d’abord nettoyer mon dique et ainsi obtenir suffisamment d’espace libre 😦 Mais si j’arrive à l’installer, soyez assuré que j’en parlerais sur ce blog !

(For you information, KDE 4.0 Beta 1 = KDE 3.92.0)

Publié dans Mandriva. 3 Comments »

Mandriva Linux 2008 Beta 1 disponible !

Attention : Un problème disque a corrumpu l’image ISO DVD dans un premier temps, mais une nouvelle version est en ce moment même téléchargée sur les mirroirs. Vérifiez bien que la taille du fichier mandriva-linux-2008.0-free-beta1.i586.iso est la suivante : 3 345 227 776 avant de le télécharger.

La version 2008 de Mandriva Linux prend forme. La Beta 1 vient juste d’apparaître sur les mirroirs, nommée Cassini (comme l’astronome), ce qui d’ailleurs est le même nom qu’une autre version Beta de Mandriva, il y a plusieurs années de cela. Bref…

Comme l’info est très fraîche, tout est encore en train de se mettre en place, mais on peut dire que cette fois-ci, Mandriva met le paquet côté « informations » (ça change de d’habitude, merci Adam !). Le nouveau wiki de Mandriva a été utilisé sous toutes ses coutures et on nous gratifie :

Lorsque la 2008 finale sera sur le point de sortir, on aura en plus droit à une présentation des nouveautés (copies d’écran à la clé, comme pour la 2007 Spring) ainsi que l’exhaustif errata (celui de la 2007 Spring est certainement l’un des Errata les plus complets pour toutes les distributions).

Une petite note pour les grincheux dont je vois déjà pointer le bout de leur nez. L’errata indique l’ensemble des bugs qu’il est possible de contourner via quelques manipulations (appelé workaround en anglais). Avoir un errata fourni n’indique pas que la distribution est truffée de bugs (d’ailleurs, pour la 2007 Spring, on voit qu’il y en a beaucoup de résolus), mais que pleins de personnes se sont cassées la tête à trouver les bugs et à trouver la manière de les résoudre ou de les contourner. D’ailleurs, quelle que soit la distribution que vous utilisez, je vous invite à aller voir son errata : vous y trouverez généralement plein d’informations utiles pour résoudre vos problèmes.

Sur ce, bon amusement !

Powered by ScribeFire.

Publié dans Mandriva. 8 Comments »