/me est puni
Voila ça m'apprendra, à vouloir faire des trucs, j'ai été puni depuis fin juillet.
Maintenant je dois pousser moi-même mes modifications, il va donc falloir que je fasse attention.
Heureusement, pendant quelque temps on ne tape pas que sur moi si je casse tout, mais on tape aussi et surtout sur mes mentors : jadawin et tabthorpe :)
<bav>
Après 1 mois de ce nouveau statut, j'ai accumulé beaucoup de bave contre github, il me faut l'exprimer, il parait que c'est thérapeutique :
De plus en plus de développeurs utilisent github, c'est pas mal en soit: du git, une interface moderne kikooweb3.0.
Mais ça serait bien de NE PAS UTILISER LES TAGS COMME FICHIER RELEASE!!!! Bordel, github fait de la grosse merde avec ça !!!
il utilise des noms à la con pour l'archive.
Si le projet toto dispose d'un tag 0.1 la logique voudrait que l'archive toto-0.1.tar.gz correspondant à ce tag contienne un répertoire toto-0.1, logique quoi. Bah non pas chez github.
Déjà l'archive s'appelle legrosrobert-toto-0.1-hashalacon.tar.gz, génial non ? Mais admettons bon alors soyons logique si je décompresse ça je devrais avoir un répertoire legrosrobert-toto-0.1-hashalacon contenant les sources ? Bah non toujours pas !! Là, à la place, j'ai legrosrobert-toto-hashalacon ... J'adore.
Tout pour faire chier le maintainer.
Des redirections moisis :
Pour plusieurs raisons, le système de ports n'accepte pas de suivre les redirections (302) pour télécharger les distfiles. par exemple : éviter les boucles infinie de redirection pour les utilisateurs.
Si vous utilisez les tags pour les distfiles, il n'y a pas le choix que de suivre une redirection 302, il est donc impossible de faire un ports qui utilise directement les archives via les tags github. Alors que si vous regardez bien, il y a une section pour ajouter les fichiers statiques à la main, même qu'il y a plus d'excuse pour ne pas l'utiliser, flash n'est plus nécessaire pour envoyer les fichiers. depuis cette section il est possible d'avoir un lien direct pour télécharger le fichier, donc ports compliant.
Donc si vous êtes utilisateurs de github, s'il vous plaît fournissez une vraie archive tout ce qu'il y a de plus classique distribuée via un système qui autorise un téléchargement par lien direct.
</bav>
Pour revenir à ma punition, voila les projets que j'aimerai mener à bien concernant FreeBSD:
- Fédérer tous les efforts actuellements éparpillés pour la modernisation de pkg_install: réécriture, support de la mise à jour propre, utilisation de libarchive, extensibilité, etc.
- J'ai commencé un projet que j'aimerai mener à bien (pour faciliter les tests sur les ports avant modification): poudriere. Il s'agit d'une sorte de tinderbox mais en plus léger (moins de fonctionnalité) et beaucoup plus simple. Mais ça fera l'objet d'un autre post.
- Continuer et faire passer mon patch "fakeroot" de manière a pouvoir passer par les outils pkg_install pour l'installation du ports et ainsi nettoyer les ports de beaucoup de hack.
- Si le fakeroot passe, implémenter la notions de FLAVORS comme le fait OpenBSD, cad 1 ports capable de produire plusieurs packages.
Dans tous les cas je tiens à remercier particulièrement jadawin et tabthorpe pour leur patience et les conseils qu'ils me donnent lors de la revue/validation de mes commits : "pas trop usant ? :)"
How tout casser chez tout le monde épisode 1
Afin de m'assurer que lorsque je joue avec mes ports, je casse bien tout, càd sur toutes les version supportées : 7.3, 8.0, 8.1 et celles à venir. Pour pouvoir bien vérifier que je mets le dawa aussi bien sur i386 que amd64, je me suis enfin décidé à poser une tinderbox.
La tinderbox officielle de freebsd ne me convient pas. Je la trouve démeusurément complexe pour ne pas dire tordu rapport à mes besoins, Elle a besoin d'une base de données (bon à la rigueur un petit postgresql ne me dérangerai pas plus que ça) mais pour la webui il faut aussi PHP et là faut pas déconner, je n'ai pas envie de me faire chier avec du PHP sur mes machines (comment ça je suis obtu ?).
Je suis donc parti pour me pondre la mienne. Je ferai ici l'état de l'avancée de ma tinderbox maison.
Episode 1 : principe et création des environnements.
Ma tinderbox sera moins automatisée que la tinderbox officielle, il faudra se faire à la main ses jails souches etc.
concepts :
- une jail sur un ZFS dédié par version et par architecture
- un snapshot de l'état neuf de la jail pour toujours repartir de quelque chose de propre
- du nullfs pour l'arbo des ports
- du nullfs pour les packages
- un joli script maison pour lier le tout. (Pour le moment ce script est en ZSH, peut être un jour il deviendra un shell POSIX propre)
Que va faire le script :
- démarrage de la jail
- un etat des lieux de la jail avant construction (mais après installation des dépendances)
- installation des dépendances depuis des packages si ils existent, sinon compilation depuis les ports (et construction du package comme ça au prochain tour le package sera là)
- construction du ports avec possibilité de changer les options
- installation/desinstallation/construction de packages, bref la tambouille habituelle pour s'assurer que le ports est tout joli comme il faut.
- état des lieux après désinstallation du ports histoire de s'assurer que celui ci ne laisser rien traîner comme un gros cochon.
maintenant que les concepts sont présentés passons à l'étape préparation des jails.
ici les jails sont dans /home/jails/tinderboxes celui ci étant un FS ZFS : system/jails/tinderboxes pour être précis. pour créer ces jails nous allons avoir besoin de : lftp et de zsh.
Oui comme je suis une loutre, je ne vais pas me lancer dans une compilation des sources pour créer mes jails, je vais directement partir des sets officiels.
for arch (i386 amd64) {
for version (7.3-RELEASE 8.0-RELEASE 8.1-RC2) {
zfs create system/jails/tinderboxes/${version%-*}-$arch
cd /home/jails/tinderboxes/${version%-*}-$arch
export DESTDIR=/home/jails/tinderboxes/${version%-*}-$arch
/usr/local/bin/lftp -c "open ftp://ftp.free.org/pub/FreeBSD/releases/$arch/$version/; mirror base"
/usr/local/bin/lftp -c "open ftp://ftp.free.org/pub/FreeBSD/releases/$arch/$version/; mirror src"
cd base
yes | ./install.sh
cd ../src
./install.sh all
}
}
J'ai donc maintenant à ma disposition 6 FS contenant chacun des images minimales freebsd il faut maintenant finir la config et les mettre à jours avec freebsd-update
pour chacune des jails il faudra forcer des variables d'environnement pour qu'elles sachent quel est leur version. Pour cela il faut modifier le login.conf de chacune d'entre elles et remplacer :
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\
par
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES,UNAME_r=7.3-RELEASE,OSVERSION=703000,UNAME_v=FreeBSD 7.3-RELEASE:\
Il faut adapter le 7.3-RELEASE pour chacune des jails.
Pour déterminer la bonne valeure pour OSVERSION, un petit awk à la racine de la jail va pouvoir nous aider :
awk '/\#define __FreeBSD_version/ { print $3 }' usr/include/sys/param.h
Pour les jails i386 il faut rajouter dans la ligne du login.conf
UNAME_m=i386,UNAME_p=i386
Pour que tout ceci soit pris en compte, ne pas oublier :
cap_mkdb login.conf
Toujours pour les jails i386, il ne faut pas oublier de mettre dans etc/make.conf
MACHINE=i386
MACHINE_ARCH=i386
Avant de démarrer les jails on ajoute 2 lignes sur le etc/rc.conf de chacunes d'entres elles afin qu'elles ne démarrent ni sendmail ni cron dont nous n'avons pas besoin. Pour le moment on garde la syslog pour que la jail reste fonctionnelle.
sendmail_enable="NO"
cron_enable="NO"
sur la machine hôte on peut ajouter les lignes nécessaires au démarrage des jails dans le rc.conf :
jail_73i386_rootdir=/home/jails/tinderboxes/7.3-i386
jail_73i386_hostname="tinder73i386"
jail_73i386_ip="192.168.1.51"
jail_73i386_interface="nfe0"
jail_73i386_devfs_enable="YES"
jail_73i386_devfs_ruleset="devfsrules_jail"
jail_73i386_flags="-n tinder73i386"
faire de même pour chacune des jails.
une fois les jails démarrées, il faut effectuer les mises à jours, toujours aider de zsh :
for arch (i386 amd64) {
for version (73 80 81) {
jexec -U root tinder${version}${arch} /usr/sbin/freebsd-update fetch install
}
}
Le -U root est important pour que login.conf soit pris en compte.
Un fois les mises à jours faites il est possible d'actualiser les fichiers login.conf afin de refléter les nouvelle version 7.3-RELEASE-p1 par exemple, mais ce n'est pas obligatoire.
maintenant il faut arrêter toutes les jails et faire un snapshot zfs qui nous servira de référence et permettera de repartir de bases propres :
zfs snapshot system/jails/tinderboxes/7.3-amd64@propre
recommencer l'opération pour toutes les jails.
Ceci est la fin du premier épisode (je sais ça a un air de déjà vue avec un post précédent, mais la suite sera différente :))
One-liner again
Je voulais pouvoir récupérer la liste complète des ports outdated de FreeBSD, pour ça nous disposons de portscout mais ce dernier ne présente que la liste par mainteneur, or je voulais la liste complète... mais portscout propose un flux rss qui, si il est appelé sans le paramètre ?m=, liste tous les ports outdated (attention le fichier est gros).
J'ai donc pris quelques armes :
- ZSH
- textproc/xmlstarlet pour faire des requête dans le xml
- textproc/html2text pour un peu de cosmétique dans la sortie
- fetch
le résultat :
feed=(${(f)"$(fetch -q -o - http://portscout.org/rss/rss.cgi)"}) && for item ({1..$(xml sel -t -v "count(//item)" =( print -lr $feed))}) { xml sel -t -v //item[$item]/title =( print -lr $feed) | html2text } > portscout.txt
avec cette ligne je récupère un fichier portscout.txt donc le contenu est :
categorie/port: ancienne_version -> nouvelle_version
tout simplement
UPDATE :
Voici une version plus zshienne (plus besoin de xmlstarlet ni de html2text) en revanche elle est moins souple mais plus rapide :
feed=(${(f)"$(fetch -q -o - http://portscout.org/rss/rss.cgi)"}) && for item ({0..$#feed}) { [[ -z ${feed[$item]:#\<item\>*} ]] && { print ${${${${feed[$item + 1]}/>/>}/\<\/title\>/}/\<title\>} } } > portscout.txt
Pages : 1


