Télécharger les sources du noyau sur kernel.org. Pour une version stable (ex. aujourd’hui : 2.6.27.7), utiliser le lien F (full source) sur la ligne. Dans tous les autres cas, il faut télécharger le patch (lien du numéro de version, ex. 2.6.28-rc6) et la base à laquelle l’appliquer, donnée par le lien B sur la même ligne. Dans les exemples qui suivent, je suppose que les trucs sont enregistrés sous ~/tmp.

Ajouter son utilisateur au groupe src si ce n’est pas déjà fait. Par exemple :

# adduser mpg src

Puis se relogguer avec cet utilisateur pour que la modification soit effective. Le vérifier en tapant id ou groups.

En utilisateur, aller dans /usr/src, y détruire le lien symbolique linux. Décompresser l’archive des sources. S’il s’agit d’une version à patcher, procéder comme dans l’exemple suivant.

% tar xjf ~/tmp/linux-2.6.27.tar.bz
% bunzip2 ~/tmp/patch-2.6.28-rc6.bz2
% cp -r linux-2.6.27 linux-2.6.28-rc6
% cd linux-2.6.28-rc6
% patch -p1 <~/tmp/patch-2.6.28-rc6

Une fois obtenue une belle arborescence des sources dûment patchée au besoin, rétablir le lien symbolique linux vers sa racine.

Il faut maintenant configurer le nouveau noyau. Pour partir de la configuration de l’ancien, faire par exemple

% cp /boot/config-2.6.27.5 /usr/src/linux/.config

Aller alors dans /usr/src/linux et y lancer alors make menuconfig. (Il faut sans doute installer un ou deux paquets pour ça, dont libncurses-devet peut-être d’autres.) Selon les besoins, sélectionner les drivers voulus (chez moi, c’est ath9k qui m’a motivé à installer une version récente du noyau, et que je vais activer la première fois dans Device driver -> Networks device support -> Wireless Lan -> Atheros 802.11n wireless cards support).

Il est alors temps de construire le noyau. Pour cela, il faut avoir installé les paquets nécessaires : kernel-package, fakeroot, build-essential et initramfs-tools en font partie, et je crois qu’ils suffisent. Exécuter alors

% fakeroot make-kpkg clean
% fakeroot make-kpkg --initrd kernel_image

(Si on envisage de faire plusieurs noyaux personnalisés successifs à partir d’une même version upstream, on a intérêt à utiliser l’option --append-to-version=.20081107 (ou tout autre numéro) pour les distinguer et ne pas mélanger leurs modules.) C’est en tout cas le moment de s’en jeter une petite de son breuvage favori, ou de faire autre chose d’intéressant sur sa machine si on elle a un double cœur.

Maintenant, la seule étape nécessitant les droits de root : l’installation du paquet créé.

# dpkg -i /usr/src/linux-image-2.6.27.5_2.6.27.5-10.00.Custom_amd64.deb

Voilà, il ne reste plus qu’à rebooter sur le nouveau noyau, et éventuellement recompiler les modules externes.

Premièrement, pourquoi avoir installé une TeX Live nature plutôt que les paquets TeX Live de Debian ? Plusieurs raisons :

• L’équipe TeX de Debian n’a pas encore eu le temps d’empaqueter la version 2008, et j’étais impatient de jouer avec les nouveautés de cette version.
• La version 2008 de TeX Live possède son propre gestionnaire de paquet, et je ne sais pas comment il sera utilisable dans la version Debian de la chose : dans le doute, installer la version nature me paraît raisonnable.
• Une raison personnelle : étant développeur TeX Live, il me paraît naturel d’utiliser la version nature pour mieux la connaître.

Maintenant, le problème qui se pose avec les installations locales, c’est que le gestionnaire de paquets de la distribution n’en est a priori pas au courant, et qu’il faudrait qu’il en tienne compte dans ses calculs de dépendance pour ne pas installer une deuxième version de ce qu’on a déjà installé. (On peut bien sûr choisir d’installer côte à côte une TeX Live de Debian et une nature, mais il faut être sûr de bien contrôler son environnement si on veut éviter les problèmes.)

La solution proposée par Debian tient en un mot : equivs. Ce petit paquet contient ce qu’il faut pour créer facilement des paquets Debian ne contenant rien à part des informations de dépendances pour APT. Voyons comment s’en servir pour créer un paquet texlive-local qui informera APT qu’on a déjà une TeX Live, merci. On commence par installer equivs et se mettre dans un répertoire temporaire de travail (je suppose que ~/tmp existe et que c’est là-dessous qu’on aime travailler). On commence alors par utiliser equivs-control.

# aptitude install equivs
$ mkdir ~/tmp/tl-loc
$ cd !$
$ equivs-control texlive-local

La dernière ligne a pour effet de préparer un squelette fichier de contrôle pour notre futur paquet. C’est là qu’on va indiquer à quels paquets Debian réels correspond notre installation locale, grâce à la ligne Provides:. On édite aussi quelques autres informations au passage (champs Package, Version, Maintainner et Description) ; le fichier obtenu est le suivant.

Section: misc
Priority: optional
Standards-Version: 3.6.2

Package: texlive-local
Version: 2008-1
Maintainer: MPG <mpg@roth.elzevir.fr>
Provides: cm-super, cm-super-minimal, context, latex-beamer,
 latex-cjk-all, latex-cjk-chinese, latex-cjk-chinese-arphic-bkai00mp,
 latex-cjk-chinese-arphic-bsmi00lp, latex-cjk-chinese-arphic-gbsn00lp,
 latex-cjk-chinese-arphic-gkai00mp, latex-cjk-common, latex-cjk-japanese,
 latex-cjk-japanese-wadalab, latex-cjk-korean, latex-cjk-thai,
 latex-sanskrit, latex-xcolor, lmodern, luatex, musixtex, pgf, prosper,
 tex4ht, tex4ht-common, texinfo, texlive-base, texlive-base-bin,
 texlive-base-bin-doc, texlive-bibtex-extra, texlive-common,
 texlive-doc-base, texlive-doc-bg, texlive-doc-cs+sk, texlive-doc-de,
 texlive-doc-el, texlive-doc-en, texlive-doc-es, texlive-doc-fi,
 texlive-doc-fr, texlive-doc-it, texlive-doc-ja, texlive-doc-ko,
 texlive-doc-mn, texlive-doc-nl, texlive-doc-pl, texlive-doc-pt,
 texlive-doc-ru, texlive-doc-th, texlive-doc-tr, texlive-doc-uk,
 texlive-doc-vi, texlive-doc-zh, texlive-extra-utils, texlive-font-utils,
 texlive-fonts-extra, texlive-fonts-extra-doc, texlive-fonts-recommended,
 texlive-fonts-recommended-doc, texlive-formats-extra, texlive-full,
 texlive-games, texlive-generic-extra, texlive-generic-recommended,
 texlive-humanities, texlive-humanities-doc, texlive-lang-african,
 texlive-lang-arab, texlive-lang-armenian, texlive-lang-croatian,
 texlive-lang-cyrillic, texlive-lang-czechslovak, texlive-lang-danish,
 texlive-lang-dutch, texlive-lang-finnish, texlive-lang-french,
 texlive-lang-german, texlive-lang-greek, texlive-lang-hebrew,
 texlive-lang-hungarian, texlive-lang-indic, texlive-lang-italian,
 texlive-lang-latin, texlive-lang-manju, texlive-lang-mongolian,
 texlive-lang-norwegian, texlive-lang-other, texlive-lang-polish,
 texlive-lang-portuguese, texlive-lang-spanish, texlive-lang-swedish,
 texlive-lang-tibetan, texlive-lang-ukenglish, texlive-lang-vietnamese,
 texlive-latex-base, texlive-latex-base-doc, texlive-latex-extra,
 texlive-latex-extra-doc, texlive-latex-recommended,
 texlive-latex-recommended-doc, texlive-latex3, texlive-math-extra,
 texlive-metapost, texlive-metapost-doc, texlive-music, texlive-omega,
 texlive-pictures, texlive-pictures-doc, texlive-plain-extra,
 texlive-pstricks, texlive-pstricks-doc, texlive-publishers,
 texlive-publishers-doc, texlive-science, texlive-science-doc,
 texlive-xetex, tipa, 
Architecture: all
Description: Installation locale de TeX Live.
 Installation locale d'une TeX Live nature complete.

C’est presque fini. Maintenant que notre fichier de contrôle est prêt, on peut créer le paquet et l’installer :

$ equivs-build texlive-local
# dpkg -i texlive-local_2008-1_all.deb

(Seule le dernière étape se fait en root ou avec sudo : dans tous mes exemples, $ ou % représent un shell utilisateur, et # un shell root.) On peut aussi si on le souhaite sauvegarder le paquet Debian créé : personnellement, je garde une copie de tous mes paquets créés localement dans /usr/local/debs.

Enfin, j’ai quand même installé lmodern, et tex-common dont il dépend, depuis les dépôts Debian : le but est simplement d’enregistrer ces polices au niveau de defoma et de X11. (Si j’étais un peu moins pataud en fontes, je le ferais à la main.) Le paquet tex-common ne risque pas d’interférer avec mon installation : il contient essentiellement des scripts de gestion propres à Debian.

Je peux ainsi installer (depuis les dépôts Debian) des éditeurs comme Kile ou TeXmaker, voire le module aucTeX pour Emacs (que j’essaierai un jour lointain, quand j’aurai beaucoup de temps) sans qu’Aptitude n’essaie de m’installer le moitié d’une TeX Live Debian en plus comme dépendances.

Tout d’abord, j’ai lancé un petit aptitude install wordpress et commencé à regarder ce qui se trouvait dans /u/s/d/wordpress. Il y avait un README et des exemples de configuration Apache et de script pour aider à créer une base mysql et permettre à wordpress d’y accéder.

J’ai d’abord été surpris de constater que le script échouait, tout simplement parce que je n’avais pas de serveur mysql qui tournait. Enquête faite, mysql-server est simplement suggéré par wordpress et pas installé d’office, car on pourrait en principe utiliser une bdd distante. Soit, j’installe mysql-server-5.0 et tout marche.

Mais après quelques minutes à configurer la chose, je change d’avis et me met à penser que c’est mieux d’installer wordpress à la main dans mon home : je trouve lourd d’avoir à être root pour installer des thèmes par exemple. Donc on efface tout et on recommence, sauf qu’avant de désinstaller on dit aptitude unmarkauto avec la liste des dépendances de wordpress histoire de les garder sous le coude.

Bref, je suis donc parti du site http://fr.wordpress.org/, j’ai téléchargé l’archive et l’ai dézippée dans ~/www/weblog. J’ai alors suivi les instructions en bas de page et plus spécifiquement celles présentes ici pour la création et configuration de la bdd. Tout a bien marché.

Par contre, en testant, j’ai une mauvaise surprise, provenant des exemples de .htaccess préalablement recopiés : il semblerait que la directive ErrorLog, qui ne provoquait pas d’erreur à la relecture de la configuration, faisait par contre tout bonnement mourir le serveur (dans des souffrances atroces, j’imagine) quand on tentait d’accéder à la page. J’ai abandonné l’idée d’utiliser cette fonctionnalité pour le moment.

L’autre petit souci est survenu quand j’ai voulu configurer des jolis permaliens : d’une part il faut penser à mettre le code aimablement fournit par wordpress dans une directive <Directory> comme nous l’apprend le message d’erreur. D’autre part, c’est stupide mais il faut y penser : il faut activer mod_rewrite

Pour finir, deux mots sur la configuration d’Apache. Comme souvent chez Debian, c’est un peu sophistiqué mais assez bien fait : pour les sites comme pour les modules, il y a un répertoire *-available et un *-enabled et on active les trucs en faisant des liens symboliques du deuxième vers le premier. J’en profite d’ailleurs pour place dans le home de mon utilisateur les fichiers de configuration propres à chacun des serveurs virtuels, et lui donne le droit grâce à sudo de demander à Apache de relire ses fichiers de configuration.

Je trouve ça plus pratique que de lister les sites virtuels dans le fichier de conf principal d’Apache puis d’utiliser des .haccess. D’une part, au moment du reload on a les messages d’erreur si les directives ne sont pas correctes, d’autre part, ça fait toujours un fichier de moins à analyser chaque requête pour Apache.

Bref, mon ~/www/weblog.conf Kimarch® est le suivant :

<VirtualHost *:*>
    ServerName weblog.elzevir.fr
    DocumentRoot /home/mpg/www/weblog
    <Directory />
        Options FollowSymLinks
        AllowOverride All
    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteBase /
        RewriteCond %{REQUEST_FILENAME} !-f
        RewriteCond %{REQUEST_FILENAME} !-d
        RewriteRule . /index.php [L]
    </IfModule>
    </Directory>
</VirtualHost>

Je crois n’avoir rien oublié, tout a l’air de marcher pour le moment.