Debian

Intrigué par l’approche clé en main de l’auto-hébergement proposé par le projet Yunohost, j’ai testé son installation sur un B3 de prêt.

Pour ma mémoire défaillante, une série de notes prises lors de la préparation du paquet Debian pour la version 1.6.2 de Viking.

Pour ma mémoire défaillante, une série de notes prises lors de la préparation du paquet Debian pour la version 1.6 de Viking.

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.

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.

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é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.

Après la mise à jour délicate du gros netbook, j’ai attaqué celle du petit. Ca n’a pas forcément était ultra simple et rapide, mais étonnamment, je n’ai pas rencontré les mêmes problèmes.

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.

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.