Planet Libre

La grosse actualité récurrente de ces derniers mois au niveau des environnements de bureau reste la sortie prochaine de KDE 4.0. Alors oui, c'est un événement majeur pour KDE qui change de bibliothèque (obligeant à porter toutes ses applications ...) et introduits beaucoup de nouveautés, notamment sa portabilité sur d'autres OS (comme Windows et Mac OS X). Cependant, certains prédisent déjà la mort de GNOME qui ne se contente que de petites améliorations tous les 6 mois. Voici donc un article pour prouver aux mauvaises langues et trolleurs KDEiste que GNOME n'a rien a envier au futur KDE 4.0. Le but n'est pas de prouver que KDE est moins bien que GNOME, mais de prouver que GNOME n'est pas complètement ringard et dépassé face à ce nouveau KDE.

Préalable à ne pas oublier

GNOME est encore utilisé en standard et par défaut sur les distributions Ubuntu, Debian, Red Hat, Fedora, et aucune n'a encore annoncé changer cet état de fait. Même si Ubuntu par exemple a une version KDE, les nouveautés d'Ubuntu sont d'abord sorties sur l'environnement GNOME, et la release d'après, sur l'environnement KDE.

Plasma / Screenlets & autres

Plasma est sûrement l'innovation la plus visible de KDE 4.0. C'est une innovation intelligente qui va simplifier la création d'objets sur le bureau (ce ne sont que des plasmoïdes). Mais GNOME possède aussi quelques éléments approchants. D'abord, il existe les screenlets, ces petits objets en python qui profitent de l'environnement composite (transparence). Il existe aussi d'autres objets sympathiques, comme avant-window-navigator, une barre de tâche à la Mac OS X (qui elle-aussi profite de la transparence). Il est même envisagé dans le futur de pouvoir interagir entre les 2, comme faire passer une horloge de AWN au bureau (qui serait alors un screenlet). Certes, ce n'est pas au niveau de Plasma, c'est évident. Mais cela peut convenir à certains usages.

Kwin / Metacity & Compiz

Le prochain gestionnaire de fenêtres de KDE aura la possibilité d'effectuer des effets à la compiz. Mais on peut déjà les obtenir avec compiz lui-même. Même s'il ne fait pas parti de GNOME, qu'il est multi-plateforme, son développement a d'abord été orienté GNOME (support de gconf, premier gestionnaire de décoration pour GNOME, démonstration sur une machine GNOME etc ...). Son adoption par des distributions comme Ubuntu, Red Hat/Fedora a permis de pousser cette intégration. De plus, Metacity, le gestionnaire de fenêtres de GNOME va bientôt (peut-être la prochaine release) intégrer des capacités de composition assez similaires à ce que l'on trouve sur Xfce par exemple, sans nécessiter d'accélération OpenGL comme pour compiz. Cela devrait convenir à tous ceux qui ont besoin de la transparence, sans les effets (encore que, on parle aussi de la possibilité de mettre les pré visualisations des fenêtres aussi ...). Plus de détail. D'autres possibilités dans ce domaine sont envisagées (voir clutter ci-dessous ou le tout nouveau projet cairo composite manager).

Decibel / Empathy

Decibel est la partie de KDE qui va gérer tout ce qui est communication (IM, VOIP etc ...). Il est basé sur Telepathy et Tapioca, offrant une parfaite intégration dans KDE, permettant à toute application de créer des modules communicants sans ré implémenter les protocoles de communication. Mais n'oublions pas que Empathy a exactement le même rôle sous GNOME. Cette bibliothèque permet de réutiliser des widgets GTK dans d'autres applications. Il existe déjà un module pour Epiphany pour envoyer des liens à ses correspondants, un module pour Nautilus pour envoyer des fichiers ... Il est même capable de réutiliser les capacités de connexion de Pidgin (avec telepathy-haze), très pratique en attendant un meilleur support de MSN.

Webkit

Konqueror est très connu pour son très bon rendu HTLM via KHTML. Webkit est un fork de KHTML qui a été adapté par Apple pour être intégré à Safari. Ce composant va bientôt être réintgré dans KDE (pour faire simple), mais sera aussi disponible pour GNOME, permettant de s'affranchir de Gecko, souvent jugé lourd surtout pour de petites applications. On parle de son intégration dans Liferea, Devhelp et même Epiphany (qui a déjà une version qui marche mais pas aussi fonctionnelle que celle avec Gecko). Pour rappel, Webkit est théoriquement plus léger que Gecko pour un rendu d'une qualité équivalente.

Les autres améliorations d'architecture comme Solid et Phonon, n'ont pas d'équivalent sous GNOME, même si GStreamer tente d'unifier le traitement du son sous GNOME. L'avantage de ces composants est de faciliter le portage sur d'autres OS, alors que GNOME n'est pas (encore) prévu pour faire cela.

Et ce n'est pas tout. GNOME a d'autres projets dans les cartons.

GIO/GVFS

Sûrement le plus important projet dans les cartons : la réécriture du système de fichier (gnome-vfs), qui va permettre à toutes les applications d'utiliser plus facilement ces fonctionnalités. Cette bibliothèque commence à accuser son âge (1999). La nouvelle doit apparaître dans GNOME 2.22 et devrait être un évènement. Ceci n'est pas un rêve, la nouvelle bibliothèque est déjà fonctionnelle, empaquetée dans les dépôts expérimentaux de Debian et Ubuntu. Quelques nouveautés avec cette évolution.

Clutter

Disponible en version stable, Clutter est une bibliothèque qui permet de créer des interfaces animées pour GNOME. Encore peu utilisée, elle a pour but d'amener un peu de fantaisie "à la compiz" à l'intérieur des applications. Pour quelques démonstrations, le site officiel. A noter dans le même genre, le projet Elisa et sa bibliothèque pigment.

PulseAudio

Surnommé le "compiz du son", PulseAudio est un serveur de son destiné à remplacer le vieillissant ESD. Il est actuellement activé par défaut dans Fedora 8, semble tenir la corde pour une intégration dans Ubuntu 8.04, voir même dans GNOME lui-même. Mais alors que fait cette merveille ? En fait, plein de choses pas forcément utiles au premier abord. Mais aussi des choses qu'on ne penserait même pas possible Pour une démo qui est plus efficace qu'une dissertation, je vous renvoie au blog du créateur de PulseAudio et à sa longue réponse aux critiques faites sur la liste de diffusion de GNOME. Pour résumer, on va pouvoir contrôler de façon centralisée toutes les sources de sons, fusionner ou dissocier les cartes et émetteurs de sons, les assigner ou établir des backups (si mes enceintes USB tombent, mes enceintes de bureau prendrons le relai). A terme, il est prévu beaucoup plus d'interactions avec les applications, comme le son de la musique qui baisse quand on reçoit un coup de fil, un son venant de l'enceinte gauche quand on clique à gauche etc ... des "effets à la compiz", pas forcément utiles mais tellement agréables Alors pourquoi j'en parle dans un article de GNOME ? Non PulseAudio n'est pas spécifique à GNOME, mais tous les programmes annexes (le contrôleur de son) sont fais en GTK. Beaucoup de travail est fait pour l'intégrer à GNOME (création de modules pour Gstreamer par exemple). De fait, c'est une fonctionnalité qui n'est disponible que pour GNOME.

PolicyKit & PackageKit

Autre exemple de programme commun mieux intégré à GNOME : PolicyKit. C'est un système qui permet d'accorder des droits plus au moins étendus à des utilisateurs pour certaines taches. Par exemple, on peut accorder des droits à un utilisateur de configurer la pendule. L'avantage ? Actuellement pour faire cela, vous êtes obligés de lancer la configuration en root, ou en sudo, ou en gksu ! Pas besoin d'avoir les droits de vie ou de mort sur votre système pour remonter une pendule. Un article sur ce sujet. Avec ce système se profile d'autres applications, la plus connue est PackageKit, une interface universelle aux gestionnaires de paquets. Ce programme utilise donc le système d'authentification PolicyKit, permettant de permettre ou non certaines actions pour certains utilisateurs. Par exemple, un utilisateur "normal" peut être autorisé à faire des mises à jour de sécurité ou de paquets existants, mais ne peut pas installer de nouveaux paquets. Il pourra aussi, quand vous tentez d'ouvrir un document Word, automatiquement vous proposer d'installer OpenOffice. Enfin, il peut s'adapter à n'importe quel gestionnaire de paquet : apt, yum etc ... car basiquement, il ne s'occupe pas de la gestion des paquets, il donne juste les ordres. Il est donc candidat pour la plupart des distributions GNU/Linux. Il est présenti pour Fedora 9 et Ubuntu 8.10. Là encore, la communication avec GNOME est prête, pas avec KDE. Pourtant, ces composants utilisent principalement Dbus et Hal, 2 composants communs à GNOME et KDE.

Online-Desktop

Voici une innovation pure GNOME : l'intégration d'application Web au bureau physique. Le principe de l'Online-Desktop est de connecter des objets du bureau à Internet. Là encore, une vidéo sera plus efficace qu'un discours. L'avantage premier est que le bureau garde en mémoire les mots de passe rentrés sur certaines applications comme celles de Google (Gmail, Google Docs ...) ou d'autres sites « sociaux » (Last.fm, Facebook, Flick ...). Vous restez en lien avec vos amis avec le module Mugshot, vous pouvez installer des programmes par une page Internet, etc. Il y a énormément de possibilités. C'est aussi une autre façon de penser son bureau. Si vous voulez tester, Fedora 8 propose une session Online-Desktop au choix dans GDM. Le programme étant développé par des gens de Red Hat / Fedora, l'empaquetage pour Debian risque de prendre du temps (même si pour l'instant on est 2,3 sur le coups :)) La page d'accueil du projet.

Conduit et Opensync

Conduit est un outil de synchronisation. En fait, son but est de synchroniser des données dans tous les sens. Quelques images et vidéos sont disponibles sur le site du projet. Pour toute personne utilisant plusieurs appareils, cela pourrait devenir l'outil pour garder ces données synchronisées quoi qu'il arrive. Là encore, ce n'est pas un programme spécifique GNOME mais il possède pas mal de plugins avec des programmes GNOME (Evolution, Tomboy, F-Spot ...). Un rapprochement est en cours avec le projet Opensync, qui a pour but de créer aussi une infrastructure de synchronisation. Si l'on veut tenter de comparer les 2, le 1e est + niveau logiciel et l'autre matériel (même si ce n'est pas toujours vrai). La page d'accueil du projet opensync.

Et sinon en vrac : un nouveau système de configuration (Dconf), une nouvelle façon de mettre les application « sur le Dbus » (Gbus), tinymail qui utilise le même principe que Telepathy mais pour les mails, les autres application « minis » et à court terme les futures améliorations de la prochaine release (prévu pour avril). Personnellement, je trouve pas mal les futures évolutions de Tomboy, Evolution et Ekiga. Et j'ai vu passer pas mal de choses intéressantes pour Totem (support de Tracker, d'un plugin de partage de playlist...).

Voilà, j'espère avoir redonné un peu de bonne humeur aux utilisateurs de GNOME. J'espère aussi que les utilisateurs de KDE ne l'ont pas prit pour un troll. Personnellement, je considère encore que KDE possède des applications extraordinaire (Amarok, K3B ...) sans équivalent sous GNOME. Je pense aussi que KDE 4.0 va apporter de très bonnes choses. Mais n'oublions pas GNOME pour autant !

La création d'un paquet pour Debian ou/et Ubuntu en version très simplifiée, activité qui m'a occupé ces derniers mois Ce billet n'a pas pour but de vous apprendre à faire un paquet, mais de vous décrire un peu comment on peut se lancer dans l'aventure

On pourrait croire au premier abord que faire des paquets, c'est compliqué. Je dirais : pas forcément. Si on prends d'un point de vue technique, je dirais que c'est bien moins compliqué que programmer. Mais évidemment, on ne peut pas résumer cela aussi facilement. Tout ça pour dire que si vous voulez vous y mettre, ce n'est pas insurmontable, loin de là.

Pour commencer, il y a la phase d'apprentissage, de lecture de doc, passage obligé. Je peux vous conseiller pour commencer la doc du site ubuntu-fr.org : Faire un paquet, complément sur CDBS en français, en anglais, et enfin les cas particuliers. Personnellement, je vous conseille de vous cantonner à cela pour le début. Pourquoi ne pas lire toute la doc disponible ? Parce qu'il existe autant de façons de packager que de packageur. Certains n'utilisent pas les mêmes techniques, les mêmes recettes etc ... ce qui risque de vous embrouiller plus que de vous aider. Il est aussi conseillé de savoir comment marche un système Debian Mais avant de vous plonger dans cette doc, laissez moi vous expliquer très grossièrement le principe.

Le but du paquet deb, c'est de mettre dans une boite un programme pré-compilé. Pour cela il va falloir donner des ordres de compilation. C'est donc comme si vous compiliez un programme, avec ./configure && make. Sauf que le make install va correspondre ici, à la mise en boite plutôt qu'à l'installation. Il va donc d'abord vous falloir un fichier pour donner des ordres : c'est le fichier debian/rules. Oui si vous ne le savez pas encore, tous les fichiers pour faire un paquets Debian sont situés dans un répertoire debian
Ensuite, il faut savoir que cette compilation sera fait sur les serveurs de la distribution (Ubuntu ou Debian). Il va donc falloir dire au serveur : Pour compiler ce programme, tu as besoin de tel paquet, tel paquet ... Cela serait bien aussi de donner quelques infos sur le paquet. Tout cela sera fait dans le fichier debian/control.
Ce qui serait bien aussi, c'est si vous devez faire des changements sur votre paquet, de pouvoir suivre ces évolutions. On mettra ces informations dans le fichier debian/changelog.
Voilà, si vous arrivez à construire ces 3 fichiers vous aurez un deb qui peut s'installer et marcher. Sachant que le debian/changelog est très simple (le nom du programme et sa version), le debian/rules peut être très simple aussi (2-3 lignes à copier coller, toujours les mêmes). Voilà de quoi faire un paquet simple qui s'installe et qui se lance dans le cas d'un programme source simple et proprement distribué.

Alors après évidemment, ça ne fera pas un paquet génial, ni très présentable. Il y a aussi des variantes, d'autres choses à vérifier, et souvent des modifications à apporter à ce schémas de base. Par exemple, si vous voulez créer plusieurs paquets, par exemple le programme principal dans un paquet + ses plugins dans un autre, il y a des ajustements à faire. Si vous voulez passer des paramètres particuliers à la compilation, il faut ajuster le debian/rules. Il faut aussi corriger toutes les erreurs. Un outil très utile pour les détecter s'appelle lintian. Lancé sur un paquet deb, il repère les erreurs d'empaquetage. Pour être intégré dans Ubuntu ou Debian, toutes les erreurs doivent être corrigées. Amusez vous à lancer lintian sur des deb que vous trouvez un peu partout, pour voir quels erreurs ont été faites. Enfin, il faut vérifier tous les copyright et les licences des sources pour les rassembler dans le fichier debian/copyright. C'est une étape essentielle pour une inclusion dans une distribution, mais très pénible.
C'est là qu'il est utile de demander conseil à des empaqueteurs plus expérimentés (le chan IRC ubuntu-classroom-fr est un bon endroit :)) pour corriger les erreurs, orienter le débutant etc ...

Une fois que toutes les erreurs ont été corrigées, soit en modifiant les fichiers contenus dans le répertoire debian, soit en patchant les sources, vous pouvez soumettre vos paquets pour inclusion dans Ubuntu ou/et Debian. C'est là où commence l'attente, car le problème actuel n'est pas le manque de packageur, c'est le manque de vérificateur. Regardez les listes de paquets qui attendent qu'on les vérifie sur ces 2 sites. En fait, la seule solution est d'aller mendier une vérification sur les chan IRC, ce que je ne supporte pas (il y a des outils et des procédures, moi je les suis bêtement :)) C'est là qu'on voit si on est vraiment motivé, car il faut de la patience. Une autre solution proposée par Debian, c'est de créer des équipes de mainteneurs qui s'occupent d'un groupe de paquets, avec une personne qui vérifie et upload les paquets (Ubuntu le fait beaucoup moins)

Quand vous avez réussi à faire valider votre paquet, il peut être uploadé dans la distribution. Si vous avez fait des patchs, il est utile de les soumettre au créateur du programme source pour qu'il les intègre directement dans ses sources. Ensuite vient l'entretien du paquet, avec les corrections de bugs qui sont signalés sur le bugtracker de la distribution. Il faut aussi mettre à jour le paquet quand il y a une nouvelle version du programme source.

J'ai beaucoup appris pendant ces quelques mois, D'abord que faire un paquet ce n'est pas très compliqué, en tout cas moins que ce que je pensais. J'ai aussi maintenant une très mauvaise opinion de certains dépôts externes. Le principal reproche que je peux leur faire, c'est de ne pas faire le travail nécessaire pour inclure les paquets directement dans les distributions. Est-ce de la paresse ? L'envie d'avoir un dépôt à son nom ? Une méconnaissance du système ? Le manque de vérificateur ? Dans certains cas, l'utilisation de tels dépôts est acceptable (problème de licence notamment, ou des backports un peu lourd). Mais ce n'est pas une majorité.
L'autre problème que j'ai vu, c'est le manque de vérificateur. C'est déprimant. Voir tous ces paquets sur REVU et mentors, je trouve ça triste. Il y a tellement de potentiels packageurs qui ne demandent qu'à apprendre, qu'à participer. Des gens qui feront peut être de futurs vérificateurs. Et quand je vois un responsable de la communication vers la communauté Ubuntu demander de participer aux packaging, ça me fait bien rire. Si c'est pour poiroter des semaines qu'un MOTU daigne regarder son travail ... ça motive pas.

Pour ma part, je ne suis pas si mal loti. J'ai pu envoyé 2 paquets chez Debian (gnome-launch-box et screenlets), et un 3e chez Ubuntu (avant-window-navigator). Je continue à travailler sur d'autres paquets et j'ai toujours autant de plaisir à les faire, à plonger dans les entrailles d'un programme. J'ai juste appris la patience, que les paquets que je soumets ne seront pas vérifiés tout de suite. Ca ne me pose plus de problème, si les dev sont intéressés, ils regarderont. En attendant, mes paquets tournent chez moi

Ce billet inaugure une série sur le packaging, pas trop technique car je n'ai pas l'expérience pour ça Pour tous ces détails, je vous renvoie à la doc, aux chan IRC (ubuntu-motu, ubuntu-classroom(-fr), debian-mentors ...) Si vous voulez suivre ça, suivez le tag Packaging