Rolinh

Rolinh' release

Archlinux: Comment Créer Un Paquet 32-bit Depuis Une Installation 64-bit

En plus de mon beau Lenovo, je possède un netbook (Asus EeePC 1005HA) sur lequel est bien évidemment également installé Archlinux.

Seulement voilà: il m’arrive d’installer des paquets depuis AUR et cela passe souvent par une compilation. Évidemment, l’ensemble d’excellents outils fournis avec Archlinux (pacman, makepkg, PKGBUILD) facilitent énormément la tâche de création de paquets mais seulement voilà, compiler sur un netbook disposant d’un faible Intel Atom N280 en guise de processeur est loin d’être une joie. Surtout lorsque l’on possède une belle machine comme la mienne pour compiler!

L’idée est donc de compiler le paquet sur mon Lenovo et de le rendre disponible pour le netbook par la suite. Seulement voilà: mon Lenovo possède une Archlinux 64-bit alors que le netbook, processeur 32-bit oblige, une Archlinux 32-bit et par conséquent les paquets ne sont pas compatibles.

La solution? Créer un paquet 32-bit depuis l’installation 64-bit. Pour cela, il faut évidemment passer par un chroot 32-bit.

Cela pourrait être un vrai chemin de croix pour certains mais en fait le travail est facilité par des outils très pratiques. Voici comment procéder dans le détail.

Il faut commencer par créer le répertoire devant contenir notre chroot. Le faire dans /opt avec un nom parlant est une bonne idée:

sudo mkdir /opt/arch32

Les outils dont nous avons besoin sont fournis dans le paquet devtools. Alors installons le:

sudo pacman -S devtools

Ceci fait, on va copier notre existant pacman.conf dans notre dossier de chroot:

sudo cp /etc/pacman.conf /opt/arch32

On va également avoir besoin du makepkg.conf. Celui-ci possèdant une configuration spécifique à l’architecture, on va prendre celui par défaut pour 32-bit fournis avec le paquet devtools:

sudo cp /usr/share/devtools/makepkg-i686.conf /opt/arch32

Ceci fait, il nous faut éditer /opt/arch32/pacman.conf afin d’être certain qu’il ne contienne pas de référence à du 64-bit. Il faut changer cette ligne:

Architecture = auto

Pour celle-là:

Architecture = i686

Il faut également être sûr que le dépôt multilib n’est pas activé ainsi que tout autre dépôt uniquement 64-bit sous peine de faire foirer le chroot.

Et c’est maintenant que s’applique la magie des beaux outils. La commande suivante va configurer le chroot et installer tout ce qu’il nous faut comme paquets afin de pouvoir en créer un:

sudo mkarchroot -C /opt/arch32/pacman.conf -M /opt/arch32/makepkg.conf /opt/arch32/root base base-devel sudo

Cela peut évidemment prendre un peu de temps en fonction de votre connection internet.

Une fois ceci fait, il faut copier le PKGBUILD du paquet que l’on veut créer quelque part dans notre chroot. Mettons que l’on veuille compiler le paquet xfwm4-tiling, disponible sur AUR, on va créer le dossier /opt/arch32/aur/xfwm4-tiling et y mettre les fichiers nécessaires dedans (PKGBUILD et éventuels autres fichiers nécessaires). Il faut ensuite se rendre dans le dossier contenant le PKGBUILD (dans notre exemple /opt/arch32/aur/xfwm4-tiling) et lancer la commande suivante:

sudo makechrootpkg -c -r /opt/arch32

Et après un petit moment: tadaaa, voilà le paquet 32-bit créé! Et oui, c’est aussi simple que ça!

Si vous comptez réutiliser votre chroot plus tard, la commande suivante suffit afin de s’assurer que notre chroot est bien à jour:

sudo mkarchroot -u /opt/arch32/root

Alors, ils ne sont pas beau les outils Archlinux?

Suspension Temporaire Des Commentaires

Les commentaires sont temporairement suspendus sur ce site. Je vous l’accorde, un blog est beaucoup moins vivant s’il est dépourvu de commentaires. Cependant, s’il n’est plus possible de commenter en ce moment c’est pour une raison bien précise que je vais détailler.

En visitant mon blog hier ou ce matin, vous avez pu constater que les commentaires étaient gérés par disqus. Comme je l’ai expliqué, ce site est utilise maintenant Octopress et est purement statique. Par conséquent, il n’est pas possible d’interagir de manière dynamique avec le site autrement qu’en passant par des scripts.

Seulement voilà: utiliser disqus n’est pour moi pas une solution. Pourquoi?

  • Je suis dépendant de disqus.com. Si le site ferme ou que le service devient payant, je suis cuit.
  • Disqus est lourd: il charge beaucoup de scripts et cela rend les pages plus lentes à l’affichage. Ceci est bien dommage alors qu’un des intérêts d’avoir un site statique est justement la rapidité d’affichage.
  • Disqus ne respecte pas votre vie privée. Et moi j’y tiens! En effet, grâce à la pratique extension de Firefox nommée Ghostery, j’ai fait le constat que disqus chargeait des scripts externes:
    • Quantcast: collecte des données anonymes (type de navigateur, url de référence, etc.) et partage avec des entreprises.
    • ScoreCard Research Beacon: collecte des données anonymes (type de navigateur, OS, etc.) ET des adresses IP partielles. Tout cela est bien sûr également partagé…
  • Il est difficile de récupérer les commentaires de disqus. On peut les exporter sous un format XML mais il aurait été très difficile pour moi de les convertir en commentaires pour octopress le jour où j’aurais voulu m’affranchir de ce service.

Bref, suffisament de raisons pour ne pas l’utiliser!

Je tiens fortement à migrer les anciens commentaires et trouver un nouveau système (probablement concocté par mes soins) afin de les rétablir car je les apprécie; qu’ils soient une remarque, un avis, un encouragement ou une critique: ils sont tous intéressants.

Cependant, cela risque de me prendre un peu de temps: je suis en période d’examens universitaires et je n’ai pas encore une solution en tête. Je vous prie donc de m’en excuser.

Si en attendant vous tenez à me faire part d’un commentaire, d’une critique, d’une question ou autre, il faudra passer par le formulaire de contact (que je dois encore mettre en place :-P ).

Le Blog a Migré Sur Octopress

Ça y est: je me suis enfin décidé à migrer mon blog de Wordpress à Octopress.

Première chose à savoir pour ceux qui me suivent via le flux RSS: mon flux RSS a changé d’URL. Désormais, il faut pointer sur https://blog.rolinh.ch/atom.xml (oui, le lien se trouve toujours en haut à droite du blog).

Pourquoi avoir migré? C’est bien simple: Wordpress ne me correspondait pas du tout. J’aime bien la philosophie KISS, fortement suivie par Archlinux d’ailleurs, et Wordpress va complètement à l’encontre de cette idée. Il intègre beaucoup trop de fonctionnalités dont je me fous comme de l’an 40 et est finalement devenu un CMS complet plutôt qu’un simple moteur de blog.

Octopress est à des années lumières de la philosophie de Wordpress. Le site que vous avez maintenant sous les yeux n’est constitué que de pages statiques. Oui, cela veut dire pas de bases de données ni besoin de faire tourner php ou autre sur le serveur: le site est purement statique. Cela comporte des avantages mais également des inconvénients.

Parmi les avantages, le principal est la rapidité: l’affichage est quasiment instantané. On pourrait aussi avancer le fait que cela renforce la sécurité puisque le site n’est pour ainsi dire pas piratable.

Et pourtant, ce n’est pas pour ces raisons que j’ai choisi Octopress:

  • je peux bloguer avec mon éditeur de texte favori
  • … en utilisant la syntaxe markdown
  • le site se génère et déploie sur le serveur via une collection d’outils ruby
  • je gère mon blog dans un dépôt git
  • la coloration syntaxique du code est bien gérée (quoique je fais face à un bug spécifique à archlinux pour le moment qui m’empêche d’en profiter)
  • le thème de base est très réussi

Alors évidemment, cela a aussi ses inconvénients. Le site étant entièrement statique, je ne dispose même pas d’un formulaire de contact. De même, le système de commentaires passe pas un module externe (en l’occurence disqus) et cela ne me plait pas trop. Je tâcherais tout de même de trouver une solution dès que j’aurais un peu de temps. J’espère que cela ne vous importune pas trop.

Bref, cette migration m’a quand même pris un peu de temps et certaines choses ne sont pas encore en place. Néanmoins, je suis plutôt content du nouvel aspect du blog. Je suis parti du thème de base et l’ai modifié à ma guise afin d’avoir quelque chose qui me corresponde. Pour ceux qui consultent le blog depuis un petit écran (téléphone mobile), le thème s’occupe de produire un affichage correct donc il n’y a pas de régression de ce côté là. J’ai également dû le traduire donc si vous voyez des mots qui sont encore en anglais, merci de me le signaler afin que je corrige.

Il reste encore des liens morts et autres choses dans le genre mais je vais tâcher de remédier également à ces problèmes au plus vite.

Je suis donc désolé pour les désagréments que ça peut vous causer mais il ne devrait pas trop y en avoir quand même. Et si ce foutu système de commentaires se décide à fonctionner, je serais ravi d’avoir votre avis à propos de ce changement!

PS: rhâââââ, bloguer avec $EDITOR c’est un pur bonheur quand même!

ZSH: Afficher Les Infos Des VCS (Git, Mercurial, Svn, Etc.) Dans Son Prompt

C’est quelque chose que je voulais mettre en place depuis un moment mais ne l’avais pas fait faute de trouver une solution qui me satisfasse.

En faisant une brève recherche sur internet, on peut trouver une foule de zshrc configurés pour afficher des informations en fonction du dépôt de VCS parcouru. Certaines solutions ne gèrent qu’un VCS, d’autres plusieurs, certaines affichent les informations de manière sobre, d’autre le font de manière plus excentrique, certaines nécessitent des scripts (oui, oui, je suis tombé sur une solution qui nécessitait un script python!). Bref, on trouve de tout et il est difficile de s’y retrouver pour faire un prompte à sa sauce.

J’ai finalement découvert que zsh possède un module nommé vcs_info permettant justement de gérer les dépôts de VCS. Il s’agit d’une contribution utilisateur et toute la doc nécessaire afin de configurer cela à votre guise se trouve ici. Décidément, zsh ne cessera pas de me surprendre!

Afin d’aller un peu plus vite, je me suis basé sur ces deux articles très bien fait: mercurial info on your zsh prompt et git info in your zsh prompt. Je peaufinerais probablement un peu ma configuration dans un avenir proche mais néanmoins voici comment j’ai procédé:

  • ajout de ces lignes à mon zshrc afin de ne charger que git et mercurial de vcs_info puisque de toute façon je n’utilise pas d’autres VCS dans les projets auxquels je participe:

    autoload -Uz vcs_info zstyle ':vcs_info:*' enable git hg

  • personnalisation de vcs_info avec zstyle (j’ai pompé et modifié la configuration trouvée ici afin de ne pas afficher trop d’informations)

  • ajout de vcs_info dans la fonction precmd
  • affichage des informations dans RPS1 (pour rappel, il s’agit de la partie du prompt affichée tout à droite)

Curieux de savoir à quoi ça peut ressembler?

Dans un dépôt mercurial:

Dans un dépôt git:

N’oubliez pas que vous pouvez trouver mon zshrc dans mon dépôt de configurations. ;)

Comment Appliquer Une Configuration D’écran Spécifique Automatiquement Lorsqu’un écran Externe Est Détecté

Un petit article pour une petite astuce.

Le problème est on ne peut plus simple: comment appliquer une certaine configuration d’écran de manière automatique lorsqu’un autre écran est détecté.

Dans mon cas, j’utilise un portable et dispose d’une station d’accueil à laquelle est relié un moniteur. Lorsque je suis en déplacement,  le seul écran disponible est celui du portable lui-même (logique…) mais lorsque je suis chez moi, je dispose d’un deuxième moniteur relié en VGA à ma station d’accueil. Lors du démarrage de ma session Awesome wm, les deux écrans sont par défaut en configuration clone, ce qui m’est relativement inutile. Avant mon astuce, je lançais un petit script utilisant xrandr manuellement afin que mes deux écrans soient configurés correctement. Voilà une astuce afin d’automatiser cela.

La commande xrandr, passée sans argument, permet de connaître les écrans connecté à la machine. Exemple de sortie:

Screen 0: minimum 320 x 200, current 2880 x 1024, maximum 8192 x 8192
LVDS1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm
   1600x900       60.0*+   40.0
   1024x768       60.0
   800x600        60.3     56.2
   640x480        59.9
VGA1 connected 1280x1024+1600+0 (normal left inverted right x axis y axis) 376mm x 301mm
   1280x1024      60.0*+   76.0     75.0
   1152x864       75.0
   1024x768       75.1     70.1     60.0
   832x624        74.6
   800x600        72.2     75.0     60.3
   640x480        72.8     75.0     66.7     60.0
   720x400        70.1

On voit donc dans mon cas que j’ai deux écrans connectés: LVDS1, qui correspond à l’écran de mon portable, et VGA1 qui correspond à l’écran externe branché en VGA. Lorsque ce dernier est connecté à mon portable, je souhaite configurer mon affichage en conséquence. Rien de plus simple: il suffit d’éditer le fichier $HOME/.xinitrc et de lui ajouter ces quelques lignes:

1
2
3
4
5
# apply dual-screen configuration when VGA is connected
xrandr | grep "VGA1 connected"
if [ $? -eq 0 ]; then
        xrandr --output LVDS1 --mode 1600x900 --pos 0x0 --rotate normal --output VGA1 --mode 1280x1024 --pos 1600x0 --rotate normal
fi

Évidemment, ceci est à adapter en fonction de votre configuration mais une fois ceci fait, la configuration spécifique lorsque les deux écrans sont connectés est automatiquement chargée lors du lancement de la session.