Documentation de Cookutils

de en fr pt ru

SliTaz Cook & Cooker

Les Cookutils SliTaz fournissent les outils et utilitaires pour faciliter la construction de paquets SliTaz. Ils sont faciles à utiliser et à apprendre, rapides et légers. Vous pourrez créer des paquets SliTaz en quelques commandes. La suite cookutils est découpée à la façon BSD, un outil par tâche, autour de la commande centrale cook et du Cooker.

cook compile une recette et produit un paquet tazpkg. Autour de lui, quelques sous-outils spécialisés s'occupent des requêtes sur le wok, de la base de paquets, de la mise en place de l'environnement de construction, de la cuisson par lots, de l'analyse des dépendances, du diagnostic, du nettoyage et de la création de recettes. Le Cooker est un robot de fabrication avec plus d'automatismes et peut servir d'interface à cook car il fournit une interface CGI/Web qui affiche les journaux en couleurs. Tous les outils se servent des mêmes fichiers de base et du même wok, et partagent les listes de paquets bloqués et cassés tout comme l'activité.

Pour toute information technique (style de codage, organisation du dépôt, etc.), référez-vous au README qui se trouve dans les sources ou dans /usr/share/doc/cookutils. Le format des recettes est décrit dans Receipts v2 (en anglais) et les options d'empaquetage des recettes dans COOKOPTS.

Vue d'ensemble des outils

La suite cookutils se compose des outils suivants, tous disponibles dans /usr/bin/ : 

cook              Compile et empaquette une recette
cook-all          Cuit par lots les paquets d'une liste / cookorder
cook-clean        Efface les résidus du wok (taz/, install/, source/)
cook-deps         Analyse les dépendances d'exécution d'un paquet cuit
cook-doctor       Diagnostique l'environnement ou un paquet (lecture seule)
cook-new          Crée le squelette d'un nouveau paquet dans le wok
cook-pkgdb        Construit la base de paquets de $PKGS, split.db et maint.db
cook-setup        Prépare un chroot de construction ou un environnement croisé
cook-tui          Interface ncurses : tapez un nom de paquet, regardez-le cuire
cook-wok          Requêtes en lecture seule sur le wok (list / search / uncook…)
cooker            Robot de fabrication avec interface web CGI
cookiso           Constructeur d'images ISO
cooklinux         Aide à la compilation du noyau
cooks             Cuit un paquet, puis ses paquets séparés qui ont leur propre
                  dossier dans le wok (recettes v1)
cross             Constructeur de chaîne de compilation croisée
                  (make install-cross)

Les modules internes lancés par cook lui-même (precheck, postcheck, compressor, fix-desktop-file) se trouvent dans /usr/libexec/cookutils/ et ne sont pas faits pour être appelés à la main.

Chaque outil cook-* comprend help, --help, -h ou usage pour afficher son aide intégrée avec des exemples. cook et cooker acceptent usage, help ou -h (un cook --help est lu comme un nom de paquet).

Pour la compatibilité, cook garde des raccourcis transparents pour les anciennes sous-commandes. Ils lancent (exec) l'outil cook-* correspondant, donc les scripts et les habitudes existants continuent de fonctionner : 

cook setup [opts]      -> cook-setup [opts]
cook <arch>-setup      -> cook-setup <arch>
cook new <pkg> [-x]    -> cook-new <pkg> [-x]
cook doctor [...]      -> cook-doctor [...]
cook list <file>       -> cook-all <file>
cook all [opts]        -> cook-all [opts]
cook clean-wok         -> cook-clean wok
cook clean-src         -> cook-clean src
cook list-wok          -> cook-wok list
cook search <query>    -> cook-wok search <query>
cook uncook            -> cook-wok uncook
cook wanted            -> cook-wok wanted
cook build_depends     -> cook-wok build_depends
cook build_loop        -> cook-wok build_loop
cook pkgdb [--flavors] -> cook-pkgdb [--flavors]
cook splitdb           -> cook-pkgdb --splitdb
cook maintdb           -> cook-pkgdb --maintdb
cook <pkg> --deps      -> cook-deps <pkg>

Usage de cook

Cook donne une aide intégrée succincte que vous pouvez afficher avec la commande usage, et une page d'exemples avec howto. Il a aussi des options pour faire des tâches spécifiques sur un paquet avant ou après la cuisson. Pour avoir l'aide et l'usage : 

# cook usage
# cook howto

Les options de cook <pkg> : 

--clean       -c   Nettoie le paquet dans le wok
--getsrc      -gs  Télécharge l'archive des sources du paquet
--block       -b   Bloque un paquet pour que cook l'ignore
--unblock     -ub  Débloque un paquet bloqué
--pack             Réempaquette un paquet déjà construit (install/ doit exister)
--continue         Garde l'arbre des sources et les patchs déjà appliqués,
                   relance compile_rules
--debug            Affiche les messages de débogage
--deps, --cdeps    Vérifie les dépendances d'un paquet cuit (cook-deps)

Les formes courtes (-c, -gs, -b, -ub) doivent venir juste après le nom du paquet.

Comment faire

La première chose à faire avant de cuire des paquets est de configurer votre environnement. Les 2 façons recommandées de travailler : cuire directement sur l'hôte ou cuire dans un chroot pour protéger votre hôte. Dans le cas où vous voulez travailler dans un chroot vous pouvez installer et utiliser Tazdev pour en créer un et vous placer à l'intérieur : 

# tazdev gen-chroot && tazdev chroot

Par défaut Tazdev crée un chroot dans /home/slitaz/cooking/chroot mais vous pouvez spécifier un chemin quelconque en argument (--arch=x86_64 le place dans /home/slitaz/cooking/x86_64/chroot). L'emplacement du chroot n'est pas important : une fois dans le chroot vous utiliserez les chemins standards de SliTaz comme /home/slitaz/wok pour le répertoire du wok ou /home/slitaz/log pour tous les journaux de cuisson. Comme toujours vous pouvez afficher l'aide de tazdev avec tazdev usage.

Lorsque vous utilisez un chroot il y a 2 répertoires spéciaux montés avec l'option bind : src et packages. Les sources de tous les paquets sont stockées par défaut dans /home/slitaz/src, ce répertoire est monté dans le chroot pour que les outils puissent s'en servir. Cette méthode vous permet de partager les sources entre plusieurs chroots, par exemple un pour cooking et un pour stable. Le répertoire des paquets est par défaut /home/slitaz/[version]/packages : ils ne sont pas dans le chroot et ne sont pas perdus si le chroot est effacé par erreur.

Quand vous cuisez directement sur l'hôte, cook le protège avec une prison (jail) : un overlayfs avec le système en marche en lecture seule dessous et une branche jetable dans /dev/shm dessus. Les dépendances de construction sont installées dans la branche et disparaissent avec elle ; seuls le wok, les journaux et les paquets sont vraiment écrits. Les systèmes de fichiers liés sont listés dans JAIL_MOUNTS (cook.conf). Une recette peut demander sa branche sur disque plutôt qu'en RAM avec JAIL_NOT_RAMFS, ou pas de prison du tout avec JAIL_NOT_SUPPORTED. Sans overlayfs (dans un simple chroot par exemple) cook construit sans prison, sans rien dire.

Pour commencer

Cook se sert du fichier de configuration /etc/slitaz/cook.conf ; si vous voulez utiliser des chemins personnalisés pour les répertoires et fichiers SliTaz, vous devez le modifier (un cook.conf dans le répertoire courant est lu après lui et prend le dessus). Le paramétrage crée quelques répertoires et fichiers pour garder une trace de l'activité et des erreurs, tous sont de simples fichiers texte que vous pouvez ouvrir dans un éditeur. Il installe aussi les SETUP_PKGS et donne au groupe slitaz le droit d'écrire dans $SLITAZ. Pour préparer votre environnement : 

# cook-setup

La commande cook-setup a une option --wok qui vous permet de cloner un wok SliTaz pendant la mise en place de l'environnement de cuisson. Même si vous n'êtes pas encore un développeur officiel vous pouvez le cloner et utiliser les paquets existants comme exemples pour créer les vôtres. Pour paramétrer et cloner le wok cooking par défaut ou le wok undigest (--stable et --tiny clonent les autres woks, --forced réinstalle les paquets du paramétrage) : 

# cook-setup --wok
# cook-setup --undigest

Pour un environnement de compilation croisée, donnez l'architecture cible. Cela installe CROSS_SETUP et réécrit ARCH, CROSS_TREE, CFLAGS et HOST_SYSTEM dans /etc/slitaz/cook.conf : 

# cook-setup arm
# cook-setup armv6hf
# cook-setup armv7
# cook-setup x86_64

cook.conf

Les principaux réglages de /etc/slitaz/cook.conf. Le paquet garde le cook.conf local lors d'une mise à jour, et le code a des valeurs par défaut pour une variable absente : une mise à jour de cookutils fonctionne donc avec un cook.conf existant sans rien changer à la main. 

SLITAZ="/home/slitaz"   Racine de WOK, PKGS, SRC, CACHE, LOGS, FEEDS.
ARCH="i486"             Arche cible : i486, x86_64 ou arm*. Fixe les CFLAGS
                        et le nom des paquets (suffixes -x86_64, -any).
SETUP_PKGS="..."        Paquets installés par cook-setup / cooker setup.
SETUP_MD5=""            md5 de "ls $INSTALLED" : si défini, cook refuse de
                        partir sur une base qui a dérivé (bdeps restées).
QA="0"                  Toute valeur non vide (même "0") vérifie la recette
                        avant la cuisson (precheck) ; vide la désactive.
KEEP_BUILD_TREE=""      "yes" garde source/ et install/ après une cuisson
                        réussie (développement local).
LOCALE=""               Traductions gardées dans les paquets (vide : les
                        locales prises en charge par SliTaz).
JAIL_MOUNTS="/ /proc …" Systèmes de fichiers liés dans la prison (s'appelait
                        AUFS_MOUNTS avant 4.13, l'ancien nom arrête cook).
MAKEFLAGS, CFLAGS, CPPFLAGS, LDFLAGS, CONFIGURE_ARGS
                        Options de compilation exportées à chaque recette.
DEFAULT_LOG_LIMIT=50    Taille max du journal en Mo par fonction de recette.
HOST_WGET="wget"        wget utilisé pour Repology (HTTPS requis).
MAKE_BUNDLE="no"        cook-pkgdb construit bundle.tar.lzma (hôte de
                        construction seulement, intègre les miroirs amont
                        et extra.list).
REPOLOGY_CHECK="no"     postcheck interroge repology.org pour les badges
                        "outdated". Demande un wget capable de HTTPS.
DEPS_CHECK="no"         postcheck lance cook-deps sur les fichiers empaquetés
                        et affiche les DEPENDS qui semblent manquer.
DEPS_MIRROR_LIST="yes"  cook-deps lit aussi la liste de fichiers du miroir ;
                        "no" sur un hôte dont le dossier de paquets est le
                        miroir.

Les options réseau valent "no" par défaut pour qu'un chroot neuf n'essaie pas d'accéder au réseau pendant cook / cook-pkgdb. Les hôtes de construction les passent à "yes". Les dépendances de construction manquantes sont installées depuis les paquets locaux, jamais cuites automatiquement.

Testez votre environnement

Cook fournit une commande de test qui crée un paquet et le cuit. Cela vous permet de voir si votre environnement fonctionne et donne un paquet exemple avec une recette. Le paquet factice s'appelle 'cooktest' et peut être retiré après le test. Pour cuire le paquet de test : 

# cook test

Créer et cuire

Si votre environnement est correctement paramétré vous pouvez commencer à créer et compiler des paquets SliTaz depuis votre wok. Pour créer un nouveau paquet avec une recette vide (vous pouvez aussi créer une recette de façon interactive) : 

# cook-new pkgname
# cook-new pkgname --interactive

Si vous venez de créer un nouveau paquet, vous devrez éditer la recette avec votre éditeur de texte favori : le modèle est une recette v2. Quand la recette est prête ou si vous avez déjà un paquet existant, vous pouvez le cuire : 

# cook pkgname

Si tout s'est bien passé vous trouverez votre paquet dans le répertoire $SLITAZ/packages et le journal de cuisson dans $SLITAZ/log/pkgname.log. Après une cuisson réussie le wok ne garde que la recette, stuff/ et taz/ (l'arbre empaqueté, affiché par l'interface web du Cooker) : source/ et install/ sont effacés, sauf avec KEEP_BUILD_TREE="yes". Une cuisson ratée garde tout pour le débogage.

Les recettes

Une recette (receipt) est un script shell avec des variables (PACKAGE, VERSION, DEPENDS, BUILD_DEPENDS...) et des fonctions : compile_rules() construit les sources dans $install, genpkg_rules() copie les fichiers de chaque paquet de $install vers $fs. Il y a deux formats : 

# SliTaz package receipt v2.

PACKAGE="attr"
SPLIT="attr-dev"

genpkg_rules() {
    case $PACKAGE in
        attr)     copy @std ;;
        attr-dev) copy @dev ;;
    esac
}

En v2, les paquets séparés n'héritent pas de DEPENDS, TAGS, CONFIG_FILES... du haut de la recette, et un post_install() sans suffixe va dans chaque paquet : suffixez-le avec le nom du paquet. Lisez Receipts v2 pour les détails, les motifs de copy(), les ensembles de compilation (sets) et la liste de contrôle pour convertir une recette v1.

Installer un paquet cuit

Il n'y a pas d'option d'installation : cook produit des paquets, les installer est le travail du gestionnaire de paquets. Dans un chroot de construction, cook met à jour avec la nouvelle version les paquets qui y sont déjà installés, pour que l'environnement de construction reste à jour. Sur un hôte natif il ne le fait jamais : le système en marche démarre sur ce qu'on vient de cuire (noyau, glibc, scripts de boot). Installez le paquet vous-même : 

# tazpkg install $SLITAZ/packages/pkgname-version*.tazpkg

Sources, réempaquetage, débogage

Si vous voulez ou avez besoin de seulement télécharger les sources d'un paquet sans le construire, vous pouvez utiliser l'option --getsrc comme ci-dessous. La cuisson vérifie l'archive avec TARBALL_SHA256 (ou _SHA1, _SHA3, _SHA512, _MD5) et, si la recette n'en a pas, affiche la ligne à y coller : 

# cook pkgname --getsrc

Pour réempaqueter un paquet déjà construit après une modification de genpkg_rules, sans recompiler, ou pour relancer compile_rules sur l'arbre des sources existant (les patchs déjà appliqués sont sautés) : 

# cook pkgname --pack
# cook pkgname --continue

Nettoyer les paquets

Après compilation et empaquetage il y a plusieurs fichiers dans le wok qui prennent de la place disque. Pour nettoyer un seul paquet : 

# cook pkgname --clean

Vous pouvez aussi nettoyer tout le wok d'un coup ou seulement retirer les sources pour récupérer de la place (src garde les arbres des paquets cassés pour le débogage) : 

# cook-clean wok
# cook-clean src

Chercher et lister dans le wok

cook-wok s'occupe des requêtes en lecture seule sur le wok. Il utilise grep et accepte donc les expressions régulières : 

# cook-wok list                  # liste les paquets du wok (filtrés par ARCH)
# cook-wok search libssh         # grep sur les noms de paquets
# cook-wok uncook                # inventaire des paquets sans tazpkg
# cook-wok wanted gtk            # tâches cooker pour les recettes gtk* (incrémental)
# cook-wok build_depends         # idem, guidé par BUILD_DEPENDS
# cook-wok build_loop            # recettes avec une boucle de dépendances (lent)

Fonctions des recettes

Beaucoup de paquets fournissent le même genre de fichiers, comme les paquets *-dev avec les bibliothèques statiques, les fichiers pkgconfig et les en-têtes. cook fournit des fonctions à utiliser dans une recette. Dans genpkg_rules : 

copy MOTIF...             Copie des fichiers de $install vers $fs : @std, @dev,
                          dossier/, fichier, jokers, @rm, @ico
                          (voir receipts v2)
get_dev_files             Copie /usr/include, /usr/lib/pkgconfig et les
                          bibliothèques statiques (/usr/lib*/*a) vers $fs
cook_copy_files NOM...    Copie les fichiers qui correspondent à NOM
cook_copy_folders NOM...  Copie les dossiers qui correspondent à NOM
cook_copy_icons [TAILLE]  Copie les icônes hicolor (défaut : 16 48)
remove_already_packed     Retire de $fs les fichiers déjà empaquetés par un
                          paquet précédent de la même recette (v2)

Dans compile_rules : 

fix ld                    Ajoute -Wl,--as-needed aux LDFLAGS
fix libtool               Idem dans le libtool généré (après configure)
fix math                  Correctif C++ std::isnan... pour les glibc récentes
fix symlinks              Rend relatifs les liens absolus de $install
fix utf-8                 Installe la locale en_US.UTF-8 pour la construction
fix gem                   Range l'installation d'une gem Ruby (docs, man)
cook_pick_manpages FICH.. Copie des pages man dans $install/usr/share/man/manN
cook_pick_docs FICH...    Copie des docs dans $install/usr/share/doc/$PACKAGE-$VERSION
cook_perl                 Construit et installe un module Perl (Makefile.PL)

Les patchs listés dans stuff/patches/series sont appliqués automatiquement avant compile_rules (un par ligne, [options|]nom-ou-URL[|sha256=...]). Les chemins des recettes sont $src (sources), $install (aussi $DESTDIR), $fs (le système de fichiers du paquet) et $stuff. COOKOPTS règle les étapes d'empaquetage (strip, compresseurs, fichiers .desktop...), voir cookopts.txt.

Base de paquets

cook-pkgdb génère la base de paquets du répertoire $PKGS et rafraîchit split.db et maint.db pour tout le wok. Cela vous permet de créer facilement un dépôt de paquets local et c'est ce qui crée la liste officielle des paquets SliTaz sur les miroirs. Pour créer une liste de paquets et les fichiers des saveurs Live : 

# cook-pkgdb              # reconstruction complète
# cook-pkgdb /path/pkgs   # idem pour un autre dossier de paquets
# cook-pkgdb --flavors    # reconstruction + régénère les saveurs TazLiTo
# cook-pkgdb --rmpkg      # reconstruction + retire les tazpkg périmés
# cook-pkgdb --splitdb    # rafraîchit seulement $cache/split.db
# cook-pkgdb --maintdb    # rafraîchit seulement $cache/maint.db

Avec --flavors, cook-pkgdb cherche un dépôt de saveurs dans /home/slitaz/flavors et emballe toutes les saveurs dans /home/slitaz/live avec la dernière liste de paquets disponible.

Cuisson par lots

cook-all cuit les paquets listés dans un fichier texte, un par ligne. Les lignes qui commencent par # et les lignes vides sont ignorées. Sans fichier en argument, ./cookorder est essayé d'abord, puis /etc/slitaz/cookorder : 

# cook-all                        # utilise le cookorder par défaut
# cook-all my.list                # cuit depuis une liste personnelle
# cook-all --resume               # reprend une reconstruction interrompue

L'option --resume saute les paquets qui ont déjà un dossier taz/, ce qui permet de continuer après une reconstruction interrompue sans recuire ce qui est déjà fait. Chaque résultat est noté dans $SLITAZ/log/cook-all.log, et le code de sortie est non nul quand un paquet a échoué.

Dépendances d'exécution

cook-deps analyse les dépendances d'exécution d'un paquet cuit : il lit son files.list et remonte chaque binaire, bibliothèque partagée, référence pkg-config ou libtool au paquet qui la fournit : 

# cook-deps libssh                # sortie détaillée par sous-paquet
# cook-deps libssh -q             # une ligne par sous-paquet, pour les scripts
# cook-deps libssh --la           # suit aussi les dependency_libs des *.la
# cook-deps libssh --incl         # montre aussi glibc-base / gcc-lib-base

Diagnostic

cook-doctor lance des vérifications en lecture seule : configuration, fichiers de la base du cache, espace disque, prisons orphelines, chaîne de compilation et SETUP_MD5, cohérence de l'arche, permissions. Pour chaque problème il affiche une commande de correction suggérée, mais ne la lance jamais. Sur un paquet il vérifie la recette, les dépendances de construction, l'état cassé avec la fin du journal, le tazpkg cuit et l'archive des sources. Le code de sortie vaut 1 quand un problème est trouvé : 

# cook-doctor                     # l'environnement de construction
# cook-doctor busybox             # un paquet du wok
# cook-doctor all lib             # parcourt $WOK/lib*, une ligne par problème

Le Cooker

Le Cooker est un robot de fabrication, sa première fonction est de rechercher les commits dans un wok, créer une liste ordonnée et cuire tous les paquets modifiés. Il peut aussi servir d'interface à cook car ils utilisent les mêmes fichiers. Le Cooker peut aussi cuire une longue liste de paquets en une fois, comme tous les paquets d'une saveur. Il fournit une interface CGI/Web agréable qui fonctionne par défaut sur n'importe quel système SliTaz grâce au support CGI du serveur httpd de Busybox.

Le Cooker fournit une aide intégrée succincte et des commandes courtes. Par exemple pour afficher l'usage vous pouvez faire : 

# cooker usage
# cooker -u

Les commandes du Cooker (forme courte en premier) : 

-u  usage                  Affiche l'usage
-s  setup                  Paramètre l'environnement du Cooker
    setup-cron [heures]    Ajoute le Cooker à la crontab de root (défaut : 2)
    check-cron             Affiche les tâches cron du Cooker
    arch-db                Crée la base des paquets de l'arche de l'hôte
-n  note "texte"           Ajoute une note aux cooknotes
-ns notes                  Affiche toutes les cooknotes
-b  block pkg              Bloque un paquet pour que cook l'ignore
-ub unblock pkg            Débloque un paquet bloqué
-R  reverse pkg            Cuit toutes les dépendances inverses d'un paquet
-p  pkg pkg                Comme 'cook pkg' mais avec le journal du cooker
-f  flavor nom             Cuit tous les paquets d'une saveur
-l  list fichier           Cuit tous les paquets de la liste donnée
-c  cat catégorie          Cuit tous les paquets d'une catégorie
-r  rev numéro             Cuit les paquets d'une révision Hg donnée
-a  all                    Trouve et cuit tous les paquets non construits
-T  tasks                  Liste les tâches du cooker
-t  task nom               Exécute la tâche donnée
-o  outgoing               Trouve les changements du wok à passer dans wok-hg
    autodeps               Cherche les dépendances de tous les paquets du wok

Paramétrage du Cooker

Tout comme cook, le Cooker a besoin d'un environnement fonctionnel avant de pouvoir s'en servir. La principale différence avec l'environnement de cook est que le Cooker a besoin de 2 woks : un wok Hg propre comme référence ($SLITAZ/wok-hg) et un wok de construction ($SLITAZ/wok). De cette façon il est facile de comparer les 2 woks et d'obtenir les modifications. Si vous avez déjà un environnement pour cook, vous devez déplacer votre wok avant de paramétrer le Cooker ou il s'en plaindra. Le paramétrage installera aussi un ensemble de paquets de développement défini dans le fichier de configuration cook.conf par la variable SETUP_PKGS, plus mercurial, rsync et tazlito, et clonera le dépôt des saveurs. Pour paramétrer votre environnement cooker : 

# cooker setup

Si tout s'est bien passé vous avez maintenant 2 woks, les paquets de développement de base installés et tous les fichiers nécessaires créés. Le comportement par défaut est de rechercher les commits, vous pouvez lancer un test : 

# cooker

Cuire avec le Cooker

Encore 2 façons de travailler : faire des modifications dans le wok Hg propre et lancer le cooker sans argument, ou cuire les paquets à la main. Le cooker vous permet de cuire un seul paquet ou tous les paquets d'une catégorie ou d'une saveur. Vous pouvez aussi essayer de construire tous les paquets non construits, mais sachez que le Cooker n'a pas été conçu pour gérer des milliers de paquets.

Pour cuire un seul paquet, comme cook pkgname mais avec plus de journaux : 

# cooker pkg pkgname

Pour cuire plusieurs paquets d'un coup vous avez plusieurs possibilités. Vous pouvez utiliser une liste de paquets existante comme celles des saveurs Live, ou une liste personnelle avec un nom de paquet par ligne. Vous pouvez construire tous les paquets d'une catégorie, tous ceux qui dépendent d'un paquet, ou tous les paquets non construits. 

# cooker flavor [name]
# cooker list [/path/to/cooklist]
# cooker cat [category]
# cooker reverse [pkgname]
# cooker all

Le Cooker vous permet aussi de recuire une révision Hg précise. C'est utile en production : si le robot de fabrication a été interrompu pendant la cuisson des commits, vous pouvez cuire les paquets à la main : 

# cooker rev 9496

Les paquets bloqués

Cook et le Cooker gèrent un fichier contenant la liste des paquets bloqués afin de ne pas les cuire lors de commits ou si une liste de cuisson est utilisée. C'est très utile pour un robot de fabrication en production. Lorsque vous bloquez ou débloquez un paquet vous pouvez ajouter une note dans les cooknotes. Exemple de blocage de paquet : 

# cook pkgname --block
# cooker block pkgname
# cooker -n "Blocked pkgname note"

La liste des paquets bloqués est aussi affichée dans l'interface Web du Cooker. Pour débloquer un paquet vous devez utiliser la commande unblock ou l'option cook --unblock : 

# cook pkgname --unblock
# cooker unblock pkgname

Cooker CGI/Web

Pour voir les journaux de façon agréable, garder une trace de l'activité et vous aider à trouver les erreurs, vous pouvez utiliser l'interface Web du Cooker, installée par défaut dans /var/www/cgi-bin/cooker (avec un lien /var/www/cooker). Si vous n'utilisez pas de chroot et que le serveur httpd de Busybox tourne, l'interface Web fonctionne sans configuration et doit être accessible à l'adresse : http://localhost/cooker/cooker.cgi

Si vous utilisez un environnement chroot, vous devriez aussi installer cookutils sur votre hôte et modifier la variable de chemin SLITAZ. Une façon standard de travailler est d'avoir un chroot dans : 

/home/slitaz/cooking/chroot

Avec /etc/slitaz/cook.conf modifié comme suit : 

SLITAZ="/home/slitaz/cooking/chroot/home/slitaz"

Note : il n'est pas obligatoire d'installer les cookutils sur votre hôte pour utiliser l'interface Web. Si vous utilisez Lighttpd vous pouvez aussi copier les fichiers cooker.cgi et style.css, par exemple dans votre dossier ~/Public, et utiliser un cook.conf personnel avec. L'avantage d'installer cookutils sur l'hôte est d'avoir des mises à jour régulières par le gestionnaire de paquets Tazpkg. Disons que vous avez cloné ou téléchargé les cookutils : 

$ cp -a cookutils/web ~/Public/cgi-bin/cooker
$ cp -f cookutils/configs/cook.conf ~/Public/cgi-bin/cooker

Éditez le fichier de configuration ~/Public/cgi-bin/cooker/cook.conf pour y mettre votre chemin SLITAZ et c'est tout !

Cooknotes

Les cooknotes vous permettent d'écrire de courtes notes personnelles sur l'empaquetage et sont utiles pour travailler ensemble. Elles ont été codées pour que les mainteneurs du robot Cooker de SliTaz partagent des notes entre eux et avec les autres contributeurs. Le Cooker peut bloquer la construction d'un paquet ou recuire des paquets à la main : il est par exemple commode de laisser une note quand un paquet est bloqué, pour que le mainteneur sache pourquoi l'administrateur l'a fait. Les cooknotes sont affichées dans l'interface Web et peuvent être consultées en ligne de commande : 

# cooker note "Blocked pkgname due to heavy CPU load"
# cooker notes

Le Cooker comme robot de fabrication

Le Cooker est conçu pour être le robot de fabrication de SliTaz : il surveille 2 woks, met à jour le wok Hg, obtient les différences et cuit tous les paquets qui ont été commités. La façon la plus sûre et la plus propre de lancer le Cooker comme robot avec cron est d'utiliser un environnement chroot, mais il peut tourner directement sur l'hôte si vous le voulez.

Pour lancer le Cooker automatiquement vous devez utiliser cron depuis le chroot. La commande setup-cron ajoute les tâches à la crontab de root (/var/spool/cron/crontabs/root) et relance crond. Disons que vous souhaitez lancer le Cooker toutes les 2 heures : 

# cooker setup-cron 2
# cooker check-cron

Cron ne lance pas le Cooker directement : toutes les 2 heures il touche $CACHE/cooker-request, et une tâche lancée toutes les 5 minutes démarre le Cooker quand une demande attend. Une autre tâche cuit les paquets listés dans $CACHE/recook-packages, que l'interface web remplit.

Lancer le robot Cooker au démarrage

L'environnement du Cooker et la tâche cron peuvent être lancés automatiquement au démarrage. Vous devez avoir installé cookutils-daemon sur l'hôte et utiliser une installation SliTaz standard pour que cela fonctionne correctement (la cooking se trouve dans /home/slitaz/cooking). Le script du démon monte les systèmes de fichiers virtuels si besoin, ainsi que les sources et les paquets. Les fichiers sources se trouvent dans /home/slitaz/src et sont liés dans le chroot pour que vous puissiez partager les sources des paquets entre plusieurs versions (stable, cooking, undigest). Si le paquet n'est pas encore installé : 

# tazpkg get-install cookutils-daemon

Pour lancer le démon vous devez avoir une définition de fichier cron pour root dans le chroot ; le script du démon fonctionne comme tous les autres démons du système et se contrôle avec : 

# /etc/init.d/cooker [start|stop|restart]