Debian

Emuler le Raspberry Pi avec Qemu

Afin de créer des paquets Debian pour Raspbian, j’ai choisi de passer par Qemu. Téléchargement La première étape est, naturellement, le téléchargement de l'image et du noyau. Adaptation à Qemu L’image est prévue pour la carte Raspberry Pi. Il faut donc l’adapter un peu pour qu’elle fonctionne pleinement dans Qemu. Démarrage d’un shell (attention au clavier qwerty) : $ qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -append "root=/dev/sda2 panic=1 init=/bin/sh rw" -hda 2014-01-07-wheezy-raspbian.

Paquetage de Ref-Lect pour Raspbian

Certains utilisateurs du Mir:ror m’ont demandé comment mettre en oeuvre sur un Raspberry Pi. Je me suis donc mis en tête de dépoussièrer mon projet Ref:lect et profiter de l’occasion pour m’essayer à la génération de paquet pour RaspBian. Système de construction Après avoir un peu cherché, le plus simple semble être d’utiliser Qemu pour émuler le RaspBerry Pi. J’ai fait un billet pour ça. Construction J’avais déjà amorcé la création de paquet Debian pour Ref:lect : https://github.

Empathy crashes at start

Depuis un bout de temps, empathy est devenu inopérent sur ma Debian testing : à chaque démarrage, il s’interrompt brutalement avec un SIGSEGV. Tout d’abord, jugeant que ce type de bug, aussi grave et aussi immédiat (je n’ai à priori pas de configuration particulière), j’ai simplement attendu qu’il se corrige “tout seul”. Mais au bout d’un moment, je me suis décidé à remonter le bug à Debian : 744078.

Réduction de la charge générée par munin

Récemment, j’ai installé munin sur un b3 pour surveiller une freebox. Le b3 étant ce qu’il ait, même si les plugins munin ne sont pas nombreux, la charge induite est importante. Cette charge est d’autant plus importante que l’installation par défaut de munin consiste à reconstruire les données et le site web toutes les 5 minutes. Sur le b3, cela prend presque 1 minute de tout faire. Mais dans cette minute, à peine 20 secondes servent à récolter les informations. Et cela est d’autant plus dommage que je ne consulte ces données qu’en de très rares occasions.

Du coup, j’ai décidé de revoir cette installation pour réduire la charge induite.

Résolution d'un upgrade impossible vers Ubuntu precise

Souhaitant mettre à jour un netbook vers la nouvelle UbuntuLTS, aka precise, je me suis heurté à un problème de dépendances. En effet, la commande standard apt-get dist-upgrade échoue sur le message suivant : E: Couldn't configure pre-depend multiarch-support for libnih-dbus1, probably a dependency cycle. Visiblement une dépendance cyclique autour des paquets multiarch-support et libnih-dbus1. Après plusieurs tentatives infructueuses d’utilisation de diverses options pour forcer l’upgrade et sans trouver de solution toute faites sur le net, je me suis laissé guidé par une intuition.

Compilation de broadcom-sta-source avec linux 3.2.0-1

Depuis la montée de version du noyau linux en 3.2.0-1, je n’avais plus de WiFi. Il s’avère que mon chipset WiFi est piloté par un module propriétaire nommé broadcom-staempaqueté sous le nom broadcom-sta-source. Or, depuis la 3.2.0 ce dernier ne compile plus. # m-a build build broadcom-sta blablabla blablabla error: unknown field 'ndo_set_multicast_list' specified in initializer blablabla En fouillant sur Internet, il s’avère qu’il s’agit d’un problème ancien, proche de celui-ci.