Apprendre à construire ou adapter, pour Raspberry Pi, une distribution basée sur Debian

Nous allons maintenant effectuer quelques configurations de base.

II-A-1. Étendre l'espace de la partition▲

sudo rqspi)config

II-A-2. Changer la localisation, le clavier et le mot de passe▲

sudo reboot

II-A-3. Changer l'utilisateur▲

sudo passwd root

logout

root

usermod --login administrateur --home /home/administrateur --move-home pi

Nous avons un système basique qu'il nous faut maintenant étendre selon nos besoins. Deux hypothèses sont alors à envisager :

• (a) vous souhaitez construire votre propre distribution ;
• (b) vous souhaitez adapter une distribution existante au Raspberry Pi.

Dans le cas de l'hypothèse (a), il suffit simplement d'installer les différents paquets que vous souhaitez. Vous n'aurez plus ensuite qu'à personnaliser la distribution obtenue.

Nous nous trouvons dans l'hypothèse (b). Il nous faut donc installer les paquets correspondant à la distribution que nous voulons reconstruire, ici PrimTux2. Il nous est possible d'obtenir la liste des paquets en lançant, sur un PC, la distribution PrimTux2 en live à partir d'un CD ou d'une clé USB, puis de saisir dans un terminal :

dpkg -l > /tmp/paquets-primtux-live

Nous copions ce fichier sur une clé USB, ou sur un partage réseau si nous en disposons, afin de le récupérer.

En parcourant la liste des paquets, nous repérons ceux correspondant à l'environnement graphique et aux outils basiques dont nous aurons besoin pour travailler. La page d'accueil des sources du projet PrimTux2 nous fournit de précieuses indications à ce sujet :

Bureau: fluxbox + rox + xfce4 panel + lxpanel

Avec ces informations, en scrutant la liste des paquets de PrimTux2 et en complétant par quelques recherches sur Internet si nécessaire, nous aboutissons à une première sélection de paquets que nous installons en tapant dans notre terminal :

apt-get install xorg fluxbox lightdm lxappearance lxpanel xfce4-panel roxterm leafpad spacefm pcmanfm menulibre rox-filer gvfs samba synaptic gdebi firefox-esr

puis nous redémarrons par un :

reboot

Cela nous fait arriver sur un écran de connexion. Nous ouvrons une session qui nous fait arriver sur une interface graphique minimaliste et une barre des tâches sans menu. Toutefois un clic droit sur le bureau ouvre un menu Debian nous permettant d'accéder à nos applications.

Le travail le plus long commence. En effet, il ne suffit pas de lancer un apt-get install avec la liste des paquets de la distribution PrimTux2 pour que nous l'obtenions sur Raspberry. Les dépôts entre les distributions ne sont pas identiques, les noms des paquets peuvent être différents, des paquets peuvent ne pas exister pour Raspbian, d'autres encore peuvent être complètement inutiles, comme des firmwares destinés à permettre à la distribution de s'adapter aux différentes configurations matérielles rencontrées. Or, pour le Raspberry pi, le matériel est connu. Il nous suffit donc de disposer des firmwares propres au Raspberry, qui sont normalement déjà installés avec notre Raspbian lite.

De plus de nombreux paquets sont des librairies installées comme dépendances d'autres paquets correspondant à des logiciels utilisés. Ils seront donc automatiquement installés lorsque l'on installera les logiciels qui nous intéressent.

Nous allons donc devoir faire le tri dans ces nombreux paquets (plus de 1800 pour PrimTux2). Pour cela il n'y a pas de méthode automatisée. En revanche, une fois que nous saurons quels paquets utiliser, il nous sera ensuite très facile d'automatiser la construction sur Raspberry.

À défaut de pouvoir totalement automatiser la tâche, nous allons devoir faire preuve de méthode. Au fur et à mesure de l'installation de nouveaux paquets avec leurs dépendances sur le Raspberry, il pourra nous être utile de comparer régulièrement la liste des paquets installés avec celle des paquets de PrimTux2. Faire manuellement cette comparaison sur plus de 1800 paquets serait fastidieux. Nous pouvons créer un script permettant d'automatiser cela. Nous avons vu comment obtenir la liste des paquets de PrimTux2, ce qui n'est à faire qu'une fois. Obtenir la liste des paquets installés sur le Raspberry peut se faire de la même façon par :

dpkg -l > paquets-rpi

Nous pouvons faire en sorte que ce script compare ces deux listes de paquets et détermine ceux qui manquent sur le Raspberry. Ainsi, en faisant de temps en temps cette comparaison au fur et à mesure de l'avancée de nos installations, il sera aisé de savoir où nous en sommes.

Voici un exemple de script effectuant une telle tâche. Ce script produit trois fichiers en résultat :

• paquets-compares qui recense dans un seul fichier la liste de tous les paquets avec tout d'abord les paquets présents, puis avec les paquets absents, au format html ;
• paquets-compares-presents dresse uniquement la liste des paquets présents dans un format texte ;
• paquets-compares-absents dresse uniquement la liste des paquets absents également dans un format texte.

#!/bin/bash

# script permettant de comparer les paquets de deux distributions à partir des informations fournies par la commande dpkg
# Sur la distribution de référence on fera dpkg -l > ma-premiere-liste pour rediriger cette liste vers le fichier ma-premiere-liste dont on indiquera le nom dans la variable DISTRI1
# Sur la distribution à comparer, on fera dpkg -l > ma-seconde-liste pour rediriger cette liste vers le fichier ma-seconde-liste dont on indiquera le nom dans la variable DISTRI2
# Ces deux fichiers doivent ensuite être placés dans le même répertoire que le script

DISTRI1="paquets-primtux-live"
DISTRI2="paquets-rpi"

# Filtre les deux listes pour en extraire uniquement les noms de paquets
cat "$DISTRI1" | sed -e '1,6d' -e "s/[ ][ ]*/#/g" -e "s/:i386//g" | cut -d '#' -f 2 > liste1
cat "$DISTRI2" | sed -e '1,6d' -e "s/[ ][ ]*/#/g" -e "s/:armhf//g" | cut -d '#' -f 2 > liste2

# Crée les différents fichiers contenant les résultats de la comparaison
> paquets-compares.html
> paquets-compares-presents.txt
> paquets-compares-absents.txt

# Effectue la comparaison
PRESENTS=""
PRESENTS_HTML=""
ABSENTS=""
ABSENTS_HTML=""
while read ligne 
    do 
      if grep ${ligne} liste2 > /dev/null 
         then PRESENTS="$PRESENTS
$ligne"
              PRESENTS_HTML="$PRESENTS_HTML<br/>$ligne"
         else ABSENTS="$ABSENTS
$ligne"
              ABSENTS_HTML="$PRESENTS_HTML<br/>$ligne"
      fi
done < liste1

rm liste1 liste2

# Inscrit les résultats dans les différents fichiers
echo '<!doctype html>
<html lang="fr">
<head>
<meta content="fr" http-equiv="Content-Language" />
<meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
<title>Paquets comparés</title>
</head>
<body>' >> paquets-compares.html
echo "<h2>Paquets présents:</h2>" >> paquets-compares.html
echo "<p>$PRESENTS_HTML</p>" >> paquets-compares.html
echo "Paquets présents:" >> paquets-compares-presents.txt
echo "$PRESENTS" >> paquets-compares-presents.txt
echo '<br/><hr size="2">' >> paquets-compares.html
echo "<h2>Paquets absents:</h2>" >> paquets-compares.html
echo "<p>$ABSENTS_HTML</p>" >> paquets-compares.html
echo "Paquets absents:" >> paquets-compares-absents.txt
echo "$ABSENTS" >> paquets-compares-absents.txt
echo "</body></html>" >> paquets-compares.html

exit 0

Nous avons intérêt à commencer par installer les paquets que nous appellerons de haut niveau. Nous entendons par là les paquets correspondant à des logiciels complexes incluant de nombreuses dépendances. Ceux-ci installant de nombreux paquets additionnels, nous n'aurons pas à faire leur installation individuellement. Nous pouvons facilement les repérer en parcourant la liste des paquets à installer ou manquants obtenue par notre script.

À cette étape, il est préférable de travailler avec Synaptic en saisissant dans la recherche le nom du paquet. Dans le résultat de recherche, il nous sera aisé de repérer si ce paquet existe ou non dans les dépôts Raspbian. Cette méthode nous servira également pour connaître l'utilité d'un paquet inconnu : Synaptic nous fournira des informations sur celui-ci, et nous pourrons alors décider s'il faut ou non l'installer. Nous notons bien au fur et à mesure le nom du paquet que nous avons installé (noter les dépendances ne sera pas utile). Ainsi, lorsque nous aurons à reconstruire la distribution, nous pourrons le faire très simplement par un apt-get install suivi de la liste de tous les paquets que nous avons retenus.

L'examen des sources de la distribution va également nous être d'une aide précieuse. Nous pouvons les examiner de deux façons :

• en ligne à partir de leur adresse Web;
• en clonant les sources sur un PC à l'aide de git.

Le fichier primtux2/config/package-lists/primtux.list.chroot

nous fournit une liste des paquets de la distribution, classés par catégories. Nous pouvons d'emblée installer l'ensemble des paquets des catégories comme :

## print
## fonts
## themes

qui seront forcément nécessaires si ces paquets existent pour Raspbian. En croisant cette liste avec celle des paquets manquants obtenue grâce à notre script, nous pouvons avancer.

A l'issue de ce travail qui nécessite temps et patience, nous aboutissons à la liste suivante, en plus des paquets que nous avons déjà installés :

# pour l'impression
cups cups-pdf hplip hplip-gui hpijs-ppds printer-driver-c2050 printer-driver-c2esp printer-driver-cjet printer-driver-escpr openprinting-ppds gutenprint-locales printer-driver-gutenprint printer-driver-hpcups printer-driver-postscript-hp printer-driver-m2300w printer-driver-min12xxw printer-driver-pnm2ppa printer-driver-ptouch printer-driver-sag-gdi printer-driver-splix printer-driver-foo2zjs printer-driver-hpijs printer-driver-pxljr system-config-printer magicfilter djtools librecode0 recode lpr lsb

# polices de caractères
xfonts-100dpi xfonts-75dpi xfonts-base xfonts-terminus fonts-droid fonts-liberation gnome-font-viewer fonts-opendyslexic fonts-dejavu-core fonts-dejavu-extra fonts-liberation fonts-sil-gentium fonts-sil-gentium-basic gnome-icon-theme-symbolic ttf-dejavu-core

# thèmes
gtk2-engines-murrine murrine-themes adwaita-icon-theme faenza-icon-theme gtk2-engines gtk2-engines-pixbuf

# Wi-Fi et bluetooth
blueman bluetooth wicd gnome-bluetooth

# paquets divers
python-glade2 numlockx zenity dansguardian baobab xsane audacity libreoffice shutter xfce4-cpufreq-plugin xfce4-datetime-plugin xfce4-fsguard-plugin xfce4-indicator-plugin xfce4-mixer xfce4-netload-plugin xfce4-quicklauncher-plugin xfce4-systemload-plugin xfce4-volumed file-roller gparted filezilla xpdf osmo xournal qalculate-gtk arandr openshot soundconverter winff gnome-mplayer hardinfo htop libreoffice-help-fr libreoffice-l10n-fr libreoffice-pdfimport dillo disk-manager synapse tcl tk8.5 tk8.6 tinyproxy accountsservice mirage pinta gigolo anacron childsplay-alphabet-sounds-fr cpulimit dkms dnsutils fonts-sil-andika frozen-bubble gcompris gcompris-sound-fr gimp-plugin-registry gnome-system-tools gnucap goldendict gnupg2 gstreamer0.10-tools gstreamer1.0-fluendo-mp3 gstreamer0.10-fluendo-mp3 gstreamer0.10-plugins-bad gstreamer0.10-plugins-ugly gstreamer0.10-pulseaudio gstreamer1.0-packagekit gstreamer1.0-plugins-ugly gtans gxmessage hannah jmtpfs katepart klettres ktuberling mlocate monsterz mtp-tools pavucontrol pysycache pysycache-buttons-beerabbit pysycache-buttons-crapaud pysycache-buttons-wolf pysycache-click-sea pysycache-dblclick-butterfly pysycache-move-food pysycache-move-plants pysycache-move-sky pysycache-move-sports pysycache-puzzle-photos ri-li scratch seahorse seahorse-adventures stellarium supertux tuxpaint tuxmath trash-cli xscreensaver libsexy2 libsnack2-alsa libtk-img iwidgets4 python-webkit childsplay chromium-browser firefox-esr-l10n-fr jclic powermgmt-base pm-utils udevil user-setup whois vim-runtime busybox fusesmb blobby tcl8.4 tcl8.5 alsa-tools vlc

PrimTux dispose de son propre dépôt dans lequel sont proposés des paquets construits spécifiquement pour elle. Nous pouvons les trouver et les télécharger depuis le git des sources, à l'adresse https://framagit.org/Steph/primtux2/tree/master/config/packages

Parmi ces paquets, plusieurs sont marqués i386 et ne pourront donc pas être directement utilisés pour le Raspberry. Nous pouvons tenter d'installer un à un chacun des autres paquets par :

sudo dpkg -i nom-du-paquet_all.deb

Nous vérifions à chaque fois son bon fonctionnement en tentant de lancer l'application soit par son lanceur en cherchant dans /usr/share/applications, soit dans un terminal par son nom. Cette dernière solution est plus intéressante car elle nous fournit des indications en cas d'échec.

Si l'application ne fonctionne pas, nous pouvons examiner le contenu du paquet .deb en le désarchivant. Nous devrons notamment vérifier que le paquet ne contient pas de fichiers binaires, indice d'une compilation sur une autre architecture qui ne sera pas compatible avec l'architecture ARM du Raspberry. Si c'est le cas, il faudra recompiler pour ARM depuis les sources, et reconstruire un paquet spécifique pour cette architecture.

Parmi les paquets marqués i386, certains peuvent ne pas contenir de fichiers binaires. Ce peut être le cas si ce sont des programmes écrits dans un langage interprété, comme Python ou Perl, assez courant sur Linux. Nous pouvons le vérifier en les désarchivant de la même façon que précédemment. Dans le cas où ils ne contiendraient pas de binaires, nous pouvons tenter de reconstruire le paquet en le marquant all ou armhf dans le fichier /DEBIAN/control du paquet. Il faudra vous reporter à un tutoriel sur la construction des paquets Debian si vous n'en connaissez pas le principe. Comme ici nous ne faisons que modifier l'indication d'architecture du paquet, la méthode à suivre est simple et se résume aux actions suivantes :

• désarchiver le paquet dans un répertoire de l'utilisateur courant que l'on créera (par exemple mon-paquet), en mode graphique au sein de PCmanFM par un clic droit puis « Gestionnaire d'archives » ;
• modifier le fichier ~/mon-paquet/DEBIAN/control de manière à ce que la ligne Architecture indique :

Architecture: all

Ou :

Architecture: armhf

• enregistrer, puis se rendre, dans un terminal, dans le répertoire contant le sous-répertoire mon-paquet ;
• saisir :

sudo dpkg-deb -i mon-paquet.deb

ce qui créera un paquet .deb du nom du paquet dans le répertoire courant. On pourra alors tenter son installation et vérifier le bon fonctionnement de l'application.

À l'issue de cette démarche, nous nous retrouvons avec :

• des paquets spécifiques à PrimTux2 mais non installables sur le Raspberry ;
• des paquets listés comme manquants que nous ne trouvons pas dans les dépôts Raspbian.

Pour les uns comme pour les autres, il ne reste que la solution de la compilation et de la construction d'un paquet pour Raspberry à partir des sources.

Dans le cas de PrimTux2, nous sommes confrontés à des sources dont les méthodes de compilation peuvent varier.

Elles comportent des fichiers avec des extensions .h ou .hpp, .c ou cpp.

On y trouve généralement à la racine un fichier configure et un fichier Makefile. Commençons par rechercher s'il n'y a pas un fichier readme ou autre fichier texte indiquant la marche à suivre. Si ce n'est pas le cas, la démarche la plus fréquente pour la compilation de telles sources est la suivante. Dans un terminal, ouvert dans le dossier de base des sources, effectuer la série d'opérations suivantes :

./configure

Ceci lance un script qui détermine si tous les éléments nécessaires à la compilation sont présents et correctement paramétrés. Puis la commande :

make -j

lance la compilation proprement dite, l'option -j permettant d'exploiter tous les cœurs du Raspberry Pi en parallèle. La commande :

sudo make install

installe le paquet dans le système.

Pour Debian, plutôt que de faire appel à make install, nous aurons tout intérêt à installer le paquet checkinstall par :

sudo apt-get checkinstall

Puis nous saisissons :

sudo checkinstall

au lieu de sudo make install.

Il vous sera demandé si vous souhaitez ou non compléter certaines informations du fichier control du paquet.

Ceci aura pour effet non seulement d'installer le paquet dans le système, mais également de créer automatiquement, dans le dossier courant, le paquet .deb d'installation, qui sera donc utilisable pour d'autres installations.

Checkinstall est un script qui se base sur les éléments présents dans les sources pour construire le paquet .deb. Si tous les éléments nécessaires ne sont pas présents, il ne réussira pas à créer le paquet. Il faudra alors tenter de le faire manuellement.

Les sources sont repérables grâce à la présence de fichiers avec l'extension .ui et .pro en plus des extensions .h et .cpp. Le fichier .pro contient toutes les indications de construction du projet. De telles sources se compilent par :

qmake

qui va construire un fichier Makefile. Puis la procédure est identique à la précédente :

make
sudo checkinstall

ou :

sudo make install

si la commande précédente échoue.

Certaines sources peuvent présenter des difficultés de plusieurs ordres :

• elles font appel à des bibliothèques complémentaires qui doivent elles-mêmes être téléchargées et préalablement compilées ou non ;
• elles s'appuient sur des langages ou des frameworks qui doivent eux-mêmes être présents et installés à partir des dépôts Raspbian s'ils existent, ou compilés à défaut.

Dès lors il faudra étudier et faire des recherches au cas par cas, en s'adressant si nécessaire aux développeurs du projet par l'intermédiaire de leur forum.

Il nous faudra précieusement conserver tous les paquets que nous aurons obtenus par compilation ou reconstruction pour refaire plus tard une nouvelle construction de la distribution. En effet tous nos essais conduiront à l'engraissement de notre système par tout un tas de paquets, fichiers, nécessaires au développement mais inutiles pour le projet final. Nous devons prendre note au fur et à mesure de notre progression des divers éléments à installer et modifier en résumant les procédures pour ne conserver que l'essentiel. 

Lightdm est le gestionnaire de démarrage des sessions en mode graphique. Lors de notre premier démarrage, celui-ci échoue. La lecture des logs du dossier /var/log/lightdm fait apparaître l'erreur suivante :

Failed to find session configuration lightdm-webkit-greeter

lightdm-webkit-greeter n'existe pas dans les dépôts Raspbian. Ce paquet est présent dans les sources de PrimTux, et est marqué i386. L'analyse de son contenu indique qu'il comporte des binaires. Nous devons donc le compiler pour l'architecture ARM. Nous trouvons ses sources à l'adresse https://code.launchpad.net/lightdm-webkit-greeter

Nous le compilons et construisons son paquet que nous installons. Mais au redémarrage, la connexion échoue avec le message d'erreur suivant:

Unabled to load page ... URL  file:///usr/share/lightdm-webkit/themes//default/index.html

Nous n'avons pas de console et donc plus aucun moyen de contrôle sur la distribution. Nous pouvons retrouver une console à l'aide de la combinaison de touches [Ctrl] + [Alt] +[Fx], [Fx] représentant une des touches de fonction F2 à F6.

Dans le cas où le problème rencontré ferait que cette solution est inopérante, il nous est encore possible de nous en sortir en travaillant à partir d'un PC disposant d'une distribution Linux. Nous pouvons en effet monter la carte SD soit à partir d'un lecteur de carte SD, soit à partir d'un adaptateur USB pour carte SD. Selon votre distribution Linux, vous pourrez y accéder directement en mode graphique à partir d'un gestionnaire de fichiers, soit en la montant manuellement à partir d'un terminal pour y accéder à partir de votre gestionnaire de fichiers. La carte SD de notre Raspberry contient deux partitions, l'une, de petite taille, destinée au boot, l'autre, occupant l'espace restant de la carte SD, contenant le système. C'est cette seconde partition qui nous intéresse.

L'examen du paquet lightdm-webkit-greeter fait apparaître que, dans le fichier /etc/lightdm/lightdm-webkit-greeter.conf, nous avons un autre thème installé que celui indiqué dans le paquet que nous avons construit. Nous allons donc :

• remplacer le fichier /etc/lightdm/lightdm-webkit-greeter.conf de notre carte SD par celui contenu dans le paquet des sources de PrimTux2 ;
• remplacer ce même fichier dans le paquet que nous avons construit et reconstruire à nouveau ce paquet afin qu'il ne pose plus de problèmes lors d'une prochaine installation.

Une fois le fichier lightdm-webkit-greeter.conf remplacé par le fichier correct, nous redémarrons. Nous arrivons maintenant sur l'écran de session de PrimTux2.

Nous pouvons nous connecter sans problème à la session administrateur, mais les tentatives de connexion aux sessions mini, super et maxi échouent.

En fait, lorsque nous avons copié les fichiers des dossiers /etc/skel* pour construire les dossiers des divers utilisateurs des sessions, nous ne nous sommes pas préoccupés des droits sur ces répertoires. Il est fort probable que le problème est dû à des difficultés d'accès à des fichiers, puisque le démarrage de session se fait correctement pour la session administrateur. Lorsque nous vérifions les propriétés des fichiers des utilisateurs, nous nous apercevons qu'ils n'en sont pas les propriétaires. Nous tentons donc un :

sudo chown -R 01-mini:01-mini /home/01-mini

afin de définir 01-mini comme propriétaire de tous les fichiers de son répertoire, puis nous tentons une nouvelle connexion. Cette fois, ça fonctionne. Nous pouvons donc effectuer les mêmes ajustements pour les autres sessions :

sudo chown -R 02-super:02-super/home/02-super
sudo chown -R 03-maxi:03-maxi/home/03-maxi

Attention : les scripts du dossier /config/hooks des sources de PrimTux2 montrent que des modifications ont été faites sur certains fichiers des répertoires des utilisateurs. Ces modifications de droits sont destinées à empêcher certaines manipulations dans ces sessions, afin de protéger l'accès à des fichiers ou des applications. Il nous faudra donc relancer certains scripts de ce dossier afin de rétablir ces protections. Lors d'une prochaine construction, il nous suffira de noter qu'il faut appliquer les scripts de /config/hooks après avoir effectué les attributions de propriété de leur dossier aux trois utilisateurs mini, super et maxi.

La fenêtre d'accueil qui s'ouvre lors de l'ouverture de la session administrateur de PrimTux2 ne fonctionne pas, ni certaines autres applications telles que la gestion des préférences élèves, la fenêtre d'installation des logiciels supplémentaires… Ces scripts utilisent les outils graphiques de gtkdialog. Une erreur de dépendance manquante pour Gtkdialog s'affiche lorsque nous essayons d'installer certains de ces paquets. Le paquet n'existe pas dans les dépôts Raspbian mais il est présent dans les dépôts de PrimTux2. Son examen montre qu'il est marqué pour l'architecture i386 et qu'il contient des binaires. Il sera donc nécessaire de le compiler à partir des sources et de construire un paquet spécifique pour ARM. Nous pouvons trouver les sources sur https://code.google.com/archive/p/gtkdialog/downloads.

Ce paquet construit et installé, nous pouvons installer les paquets spécifiques de PrimTux2 qui avaient gtkdialog dans leurs dépendances. Retenons que les paquets lightdm-webkit-greeter et gtkdialog sont des paquets importants et nécessaires pour le bon fonctionnement de la distribution et de certaines de ses applications. Nous devrons donc faire leur installation assez rapidement lors d'une prochaine construction de la distribution.

Lorsqu'on tente de se connecter en Wi-Fi depuis Wicd, on aboutit à une erreur « mot de passe erroné ». En recherchant sur Internet nous découvrons des retours évoquant des conflits avec Network-manager qui est effectivement installé alors que ce paquet ne fait pas partie des paquets installés sur PrimTux. La suppression des paquets 

sudo apt-get purge network-manager network-manager-gnome

ne résout pas le problème. D'autres recherches nous permettent de découvrir un conflit entre wicd et dhcpcd5. Il faut donc désinstaller ce dernier par :

sudo apt-get remove dhcpcd5

jnavigue est une application programmée à l'aide du framework python Ren'Py. Ren'Py existe dans les dépôts Raspbian, mais ne fonctionne pas correctement, même en choisissant l'option expérimentale d'accélération graphique dans la configuration du Raspberry Pi. Il semble que ce framework soit trop gourmand en ressources matérielles.

Le lancement du contrôle de volume affiche un message d'erreur avec Pulseaudio. L'application klettres plante à la lecture d'un nouveau son, problème lié également à Pulseaudio. Il est nécessaire de lancer Pulseaudio par :

pulseaudio -D

avant le lancement de ces deux applications pour résoudre le problème.

Nous avons tenté différentes méthodes pour automatiser le lancement de PulseAudio :

• comme service système ;
• au démarrage du système dans init.d ou dans crontab ;
• au démarrage de session.

Mais aucune n'a fonctionné. Nous avons donc contourné le problème en créant des scripts pour les applications pavucontrol et klettres:

#!/bin/bash
pulseaudio -D
pavucontrol

#!/bin/bash
pulseaudio -D
klettres

dans le dossier /usr/bin. Puis nous avons remplacé l'entrée :

Exec=

des lanceurs de ces applications dans /usr/share/applications par les noms de ces scripts, afin de démarrer Pulsaudio avant de lancer nos applications.

La barre des tâches contient un lanceur qui est Seamonkey dans la version de base de PrimTux2. Ce navigateur ayant été changé, il convient de supprimer le lanceur actuel et de le remplacer par un lanceur pour Chromium.

Les lanceurs du Handymenu de cette application ne fonctionnent pas. C'est une version plus récente que celle de PrimTux2 qui a été compilée, et le nom du paquet a changé : leterrier-calculment au lieu de leterrier-calculmental. Il faut donc changer les lanceurs de l'application en supprimant le lanceur existant et en en créant un nouveau pour le paquet plus récent. 

C'est le but de l'image construite ici. Chaque Raspberry Pi fonctionne de manière autonome.

On utilise un PC comme serveur de fichiers. Le Raspberry boote (s'initialise) sur ce serveur par le réseau, et c'est elle qui exécute les commandes.

En voici le principe :

PrimTux est sur le serveur et exécute les applications. Le Raspberry ne sert que comme serveur d'affichage. Il ne comporte qu'une interface basique permettant de lancer les applications sur le serveur.

En voici le principe :

L'utilisation intensive du Raspberry Pi en usage informatique quotidien présente des inconvénients liés à la faible durée de vie des cartes mémoire. Certes leur remplacement est aisé et si leur coût reste raisonnable, cela peut devenir problématique sur un grand nombre d'appareils avec une durée de vie de quelques mois seulement. Il est toutefois possible d'augmenter significativement cette durée de vie. Ce sont en effet les opérations d'écriture qui usent la carte mémoire. Les plus importantes opérations d'écriture effectuées par le système d'exploitation concernent des opérations d'inscription d'informations sur le déroulement des opérations, les erreurs rencontrées, etc. Il est possible de limiter, voire interdire, ces opérations d'écriture en paramétrant le système. On trouvera aisément des informations à ce sujet sur le Web.