Nagstamon est disponible dans le repository unstable de Debian, mais devinez quoi, pas dans pkgsrc. Ntt.. ntt.. ntt… je ne pouvais pas laisser ce vide perdurer.

Pkgsrc est actuellement en status freeze afin de préparer la sortie de pkgsrc-2010Q1, aussi, nous ne sommes autorisés à commiter que des correctifs mineurs ou impactant la sécurité. Ainsi, pour l’impatient qui souhaite essayer sur le champs ce package, j’ai mis en ligne un .shar du futur package ici même, à déployer dans /usr/pkgsrc/net/nagstamon.

update

À vos CVS :)

Ajoutons à cela le dernier post d’Hubert qui annonce :

Staying with driver games, iMil writes me that there’s documentation on getting DRI, AIGLX, Composite and Compiz going with NetBSD 5.0 available in the O(ther)NetBSD Wiki now.

The documentation covers how to enable the Direct Rendering Manager (DRI), setting up and configuring Modular X.org, assuring that everything’s in place, and how to get Compitz going. Mmm, wobbly windows at last! :-)

Je pense qu’on peut raisonnablement se dire qu’un bon petit pkgin in compiz compiz-fusion-plugins-main compiz-fusion-plugins-extra compizconfig-backend-gconf compiz-bcop ccsm suivi de la lecture de cette documentation devrait en ravir plus d’un.

Ah, et pour xorg-modular, c’est par ici.

[imil@temple ~/src/pkgin]$ ./pkgin -v
pkgin 0.3.2 for SunOS-5.10 i386

Suivi de près d’un

kamino:pkgin imil$ ./pkgin -v
pkgin 0.3.2 for Darwin-9.5.0 i386

Ou encore: pkgin compile et fonctionne désormais OOtB sous Solaris 10 et Mac OS X.

Alors ouais j’vous vois v’nir “oooh l’auuut’, y’nous r’fait l’coup du SunOS, l’arnaque”. Oui sauf que non. Il s’agit ici de Solaris 10, non d’OpenSolaris, et la nuance est de taille. En l’occurrence, en plus de quelques petits ajustements de code, vous noterez que le ld(1) fourni avec Solaris 10 ne supporte pas l’option -rpath, mais utilise plutot -R, les deux ayant la même finalité, ajouter des chemins de recherche de linkage.

J’ai résolu ce vilain conflit à l’aide de mon fâmeux configure.ac :

[...]
dnl permet d'obtenir plusieurs variables relatives à l'hôte
AC_CANONICAL_HOST
[...]
dnl simple case
case $host_os in
        sunos* | solaris*)
                RPATH="-Wl,-R"
                ;;
        *)
                RPATH="-Wl,-rpath"
                ;;
esac
dnl on demande la substitution dans le Makefile.in
AC_SUBST(RPATH)
[...]

Sans oublier de mettre à jour le Makefile.in afin de “variabiliser” -rpath / -R :

LDADD+=         -L${LOCALBASE}/lib @RPATH@,${LOCALBASE}/lib     \
                -lbz2 -lz -ltermcap -larchive @LIBS@

Vous trouverez l’ensemble du code sur le CVS de pkgin dont je vous encourage à tester le fonctionnement avant son import dans la prochaine branche de pkgsrc.

. Basculement vers autoconf pour la génération du Makefile
. Correction du bug d’affichage en console
. Pas mal de fixes autour de la standardisation des variables
. Le lookup du pkg_summary en bz2 ou gz est désormais automatique
. Gros ménage des conditions pour opensolaris
. substitution de variables dans repositories.conf ($arch et $osrelease)
. De traditionnels bugfixes
. Portage -encore un peu hors des clous- pour SunOS 5.8

Le soft est disponible sur pkgsrc-wip et si aucune plainte n’apparait, je mettrai à jour pkgsrc.

À vos torture tests !

Je fus fort déçu mais peu surpris de constater que ni “CPU frequency scaling monitor” ni “sensors applet” n’ont été portées dans pkgsrc. Ces deux applets utilisent en effet probablement un tas d’API totalement linux-centric, comme par exemple lm-sensors pour l’affichage des températures (non khali, je ne suis pas en train de dire du mal d’lm-sensors).

Je ne me sentais pas assez courageux pour recommencer à mettre les mains dans Conky mais c’est exactement ce type de petit gadget qui me manquait. Par chance, je découvre avec joie sysutils/torsmo, qui n’est ni plus ni moins que l’ancetre du sus-cité conky.

Le package fonctionne, mais s’avère faiblement utile, en effet, l’une des deux fonctions pour lesquelles je souhais un soft de ce genre, la température du système, n’est pas gérée. L’occasion étant trop belle, je pensais me fendre d’un patch salvateur et être erigé en héros au passage. Rien de tout cela, car en réalité, Adam “haad” Hamsik m’avait simplement précédé de 3 ans. Pour une raison que j’ignore, son patch n’a pas été integré à pkgsrc, donc, après un petit nettoyage du-dit patch, je vous le livre, prêt à etre appliqué après un make patch :

# cd /usr/pkgsrc/sysutils/torsmo && make patch
# cd work/torsmo-0.18 && patch < /path/vers/torsmo-temp.diff

Mais ce n'est pas tout !

Pour une autre raison que j'ignore -j'aurai bientot la réponse à ces angoissantes questions puisque j'ai contacté ghen@ qui maintient ce package-, le Makefile n'active pas le support Xft afin donner à torsmo la possibilité d'afficher de belles polices bien lisses. Ce patch là est trivial :

--- Makefile	2009-11-22 17:27:42.000000000 +0100
+++ Makefile.new	2009-11-22 17:27:17.000000000 +0100
@@ -13,6 +13,7 @@
 NOT_FOR_PLATFORM=	Darwin-*-*

 GNU_CONFIGURE=		yes
+CONFIGURE_ARGS+=	--enable-xft

 EGDIR=			${PREFIX}/share/examples/torsmo
 DOCDIR=			${PREFIX}/share/doc/torsmo
@@ -40,4 +41,5 @@
 .include "../../x11/libXext/buildlink3.mk"
 .include "../../x11/libXt/buildlink3.mk"
 .include "../../x11/xextproto/buildlink3.mk"
+.include "../../x11/libXft/buildlink3.mk"
 .include "../../mk/bsd.pkg.mk"

Et tout ça ?

pour ça:

Des articles en ligne en passant par la serie “à la découverte de NetBSD” rondement menée par la fine équipe de NetBSDfr, on vous en sert à tous les repas. Eh bah c’est pas fini.

ProselMan vous propose aujourd’hui: NetBSD comme environnement de travail sur un portable “moderne”.

J’utiliserai pour cette note -qui avouons le me servira également de pense-bête- une machine dont le CPU est 64bits-capable, munie de 2G de ram et d’un disque de 80G. Cette conf est evidemment très luxueuse, NetBSD tournera parfaitement sur quelque chose de plus modeste.

Je ne reviendrai pas sur l’installation à proprement parler, cet aspect étant très largement documenté sur l’Intarwebz. Considérons donc le 1er boot.

Rappelons à toutes fins utiles qu’il est evidemment nécessaire de se créer un utilisateur. Afin de vous simplifier la vie, ajoutez cet utilisateur au groupe wheel dans le fichier /etc/group de façon à pouvoir utiliser la commande su.

Je parle ici d’un portable, il est donc fort à parier qu’il soit muni d’une carte Wifi, et puisque wpa_supplicant est présent dans le basesystem depuis NetBSD 4.0, on va pas se priver.
Pas de NetworkManager ou je ne sais quelle autre usine à gaz, on se fend d’un :

# wpa_passphrase MonSsid mapassphrasecompliquee > /etc/wpa_supplicant.conf

puis de l’édition du fichier créé afin qu’il ressemble à ceci :

network={
	ssid="MonSsid"
	scan_ssid=1
	psk="mapassphrasecompliquee"
	key_mgmt=WPA-PSK
}

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel

Dans /etc/rc.conf, nous ajoutons les variable suivantes :

wpa_supplicant=YES
wpa_supplicant_flags="-B -i wpi0 -c /etc/wpa_supplicant.conf"

Puis on démarre le système :

# /etc/rc.d/wpa_supplicant start

Si les valeurs précédemment renseignées sont correctes, wpa_cli devrait vous afficher les informations suivantes :

# wpa_cli
wpa_cli v0.6.4
Copyright (c) 2004-2008, Jouni Malinen  and contributors

This program is free software. You can distribute it and/or modify it
under the terms of the GNU General Public License version 2.

Alternatively, this software may be distributed under the terms of the
BSD license. See README and COPYING for more details.

Selected interface 'wpi0'

Interactive mode

> status
15:16:54.304: bssid=00:08:04:02:7b:99
ssid=MonSsid
id=0
pairwise_cipher=CCMP
group_cipher=TKIP
key_mgmt=WPA-PSK
wpa_state=COMPLETED
ip_address=10.20.30.40

Auquel cas, nous interrogeons notre serveur DHCP afin qu’il attribue une IP à notre interface Wifi :

# dhcpcd wpi0

Notre machine vit. Afin d’automatiser cette opération, nous créons le fichier /etc/ifconfig.wpi0 (wpi0 étant le nom de mon interface Wifi, remplacez le par celui qui convient) :

up
media 11b
dhcp

Ce fichier, lu par /etc/rc.d/network, activera l’interface, la placera en mode 802.11b (mon AP est loin) et appellera dhcpcd afin d’affecter une IP à votre interface.

Hors de question de se cogner 24h de compilation pour bénéficier d’un environnement graphique, vous l’aurez compris: c’est l’instant ou pkgin rentre en scène !
On se connecte sur le repository de packages binaires le plus proche, et on récupère pkgin et sa seule dépendance, SQLite :

# ftp ftp.fr.NetBSD.org
[...]
ftp> cd pub/pkgsrc/packages/NetBSD/amd64/5.0/
ftp> get databases/sqlite3-3.6.17.tgz
ftp> get pkgtools/pkgin-0.2.5.tgz

Et on installe :

# pkg_add sqlite3-3.6.17.tgz
# pkg_add pkgin-0.2.5.tgz

Comme l’explique la documentation, on renseigne le fichier repositories.conf :

# cat > /usr/pkg/etc/pkgin/repositories.conf
ftp://ftp.fr.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/5.0/All
^D

Puis on met à jour la base de pkgin

# pkgin up

À cet instant, tout devient beaucoup plus facile !

Point d’originalité, comme j’ai un peu perdu l’envie de me cogner du tuning d’interface pendant des heures, j’opte pour l’environnement gnome que j’habillerais éventuellement grace à gnome-look.org. Ni une ni deux :

# pkgin in gnome

La durée de cette opération est evidemment fonction de la rapidité de votre connexion. Ici, sur un lien Wifi 11b, elle a pris 20 minutes.
Quelques manipulations, affichées par le dernier message d’installation, sont nécessaires :

# echo famd=YES >> /etc/rc.conf
# cp /usr/pkg/share/examples/rc.d/famd /etc/rc.d/
# echo dbus=YES >> /etc/rc.conf
# cp /usr/pkg/share/examples/rc.d/dbus /etc/rc.d/
# echo hal=YES >> /etc/rc.conf
# cp /usr/pkg/share/examples/rc.d/hal /etc/rc.d/
# echo avahidaemon=YES >> /etc/rc.conf
# cp /usr/pkg/share/examples/rc.d/avahidaemon /etc/rc.d/
# echo gdm=YES >> /etc/rc.conf
# cp /usr/pkg/share/examples/rc.d/gdm /etc/rc.d/
# cp /usr/pkg/share/examples/gnome-screensaver/pam.d/gnome-screensaver-NetBSD \
	/etc/pam.d/gnome-screensaver

Malheureusement, et même si un PR est ouvert sur le sujet, l’autoconfiguration de Xorg ne fonctionne pas totalement, wsmouse n’est pas encore supporté. Rien de bien méchant cependant, il suffira de générer la configuration de cette façon :

# Xorg -configure

Et de copier le fichier généré dans /etc/X11/xorg.conf.
Il est à noter que sur mon installation, gdm s’affichait avec des polices enormes, j’ai reglé ceci en ajoutant la directive -dpi 96 à la commande de démarrage de Xorg dans le fichier /usr/pkg/etc/gdm/custom.conf :

[server-Standard]
name=Standard server
command=/usr/X11R7/bin/X vt05 -audit 0 -dpi 96
flexible=true

Comme je l’ai annoncé au début de cet article, la cible de l’installation est un ordinateur portable, il serait donc souhaitable de contrôler un minimum sa température. On trouve sur le wiki NetBSD un post sur le sujet qui explique la marche à suivre.
Activons tout d’abord le demon powerd comme suit :

# echo "powerd=YES" >> /etc/rc.conf

Puis renseignons le fichier /etc/envsys.conf afin que les évenements concernant la température des cores de notre CPU activent une action précise :

# cat > /etc/envsys.conf
coretemp0 {
	sensor0 {
		critical-max = 60C;
	}
}
coretemp1 {
	sensor0 {
		critical-max = 60C;
	}
}

On prendra en compte cette configuration à l’aide de la commande envstat -c /etc/envsys.conf
L’exemple du wiki NetBSD propose d’utiliser le package estd afin de diminuer la fréquence du processeur si l’on tombe en dessous d’un pourcentage de charge de la batterie. On installe ce logiciel :

# pkgin in estd

Puis on l’active :

# cat >> /etc/rc.conf
estd=YES
estd_flags="-l 40 -h 70 -b"
^D

Enfin, on rassemble les morceaux dans le script d’évenement /etc/powerd/scripts/sensor_temperature auquel on ajoute les lignes suivantes :

[...]
case "${2}" in
normal)
	case "${1}" in
	coretemp*)
		/etc/rc.d/estd restart
		;;
	esac
[...]
critical-over)
	case "${1}" in
	coretemp*)
		/etc/rc.d/estd stop
		sysctl -w machdep.est.frequency.target=1000
		;;
	esac
[...]

On pourra connaitre les differentes fréquences possibles grace à la commande :

# sysctl machdep.est.frequency
machdep.est.frequency.target = 1000
machdep.est.frequency.current = 1000
machdep.est.frequency.available = 1833 1667 1500 1333 1167 1000

Pour résumer, si la température de CPU est normale, le contrôle de la fréquence est délegué à estd, lorsque l’on dépasse 60 degrés (critical-over), on diminue la fréquence à sa valeur minimale.
On constate le résultat à l’aide de la commande envstat :

(imil@ossus)
[~] envstat|grep -A2 .coretemp
[coretemp0]
  cpu0 temperature:     47.000   60.000                       degC
[coretemp1]
  cpu1 temperature:     48.000   60.000                       degC

C’est pret, rebootez (le reboot n’est evidemment pas indispensable, mais cela nous assurera que tous les demons et configurations sont corrects).

La première fois que vous arriverez sur gdm, n’oubliez pas de choisir “gnome” dans le menu “Session”.

Vous devriez maintenant contempler un bureau gnome classique.

Pour des raisons de licenses, la totalité des logiciels présents dans pkgsrc ne sont pas disponibles sous forme binaire. C’est par exemple le cas des fameuses polices ms-ttf, pratiquement indispensables pour visualiser correctement un pourcentage écrasant de sites web. Aussi, il va tout de même falloir récupérer pkgsrc pour ces cas de figure. Execution :

# cd /usr && cvs -d anoncvs@anoncvs.fr.netbsd.org:/cvsroot co pkgsrc

Les logiciels soumis à une license particulière demandent une action volontaire de l’utilisateur, ajouter à la main l’acceptation de la license dans le fichier /etc/mk.conf :

ACCEPTABLE_LICENSES+= ms-ttf-license

Moyennant quoi, on peut désormais installer le package fonts/ms-ttf de cette façon :

# cd /usr/pkgsrc/fonts/ms-ttf && make install clean

Comme l’explique le message d’installation, quelques manipulations sont nécessaires à la prise en compte de ces nouvelles polices. Tout d’abord, il faut s’assurer que le chemin "/usr/pkg/lib/X11/fonts/TTF/" est présent dans le fichier xorg.conf, exemple :

Section "Files"
        RgbPath      "/usr/X11R7/lib/X11/rgb"
        ModulePath   "/usr/X11R7/lib/modules"
        FontPath     "/usr/X11R7/lib/X11/fonts/misc/"
        FontPath     "/usr/X11R7/lib/X11/fonts/TTF/"
        FontPath     "/usr/X11R7/lib/X11/fonts/Speedo/"
        FontPath     "/usr/X11R7/lib/X11/fonts/Type1/"
        FontPath     "/usr/X11R7/lib/X11/fonts/CID/"
        FontPath     "/usr/X11R7/lib/X11/fonts/75dpi/"
        FontPath     "/usr/X11R7/lib/X11/fonts/100dpi/"
        FontPath     "/usr/pkg/lib/X11/fonts/TTF/"
EndSection

Puis de lancer :

# mkfontscale /usr/pkg/lib/X11/fonts/TTF
# mkfontdir /usr/pkg/lib/X11/fonts/TTF

Enfin, après l’installation de fontconfig :

# pkgin in fontconfig

il faudra regénérer le cache via la commande :

$ /usr/pkg/bin/fc-cache -v /usr/pkg/lib/X11/fonts # à executer en tant qu'utilisateur

Un redémarrage du serveur X sera nénessaire puisque nous avons modifié le fichier xorg.conf.

Voila ! notre bureau NetBSD est vraiment utilisable, la plupart des engine GTK étant disponibles, il suffira d’un peu de tuning pour en faire un environnement de toute beauté.

On va pas se quitter sans un petit screenshot n’est-ce pas ? :)

Malheureusement, ce n’est pas une opération spécialement bien documentée, et surtout, elle nécessite une modification (en tout cas à ce jour) de mk/compilers/sunpro.mk.

J’utiliserai /opt comme base pour l’installation du framework car cela semble être l’usage pour tous les utilisateurs chevronnés du binôme Solaris/pkgsrc.

Je suppose dans le reste de ce post que la machine cible est 64 bits-capable et que le package sunstudio12u1 est installé via pkg.

Tout d’abord, on checkout pkgsrc de manière tout à fait classique :

imil@geonosis:/opt$ pfexec cvs -d anoncvs@anoncvs.fr.netbsd.org:/cvsroot co pkgsrc

On modifie ensuite le fichier mk/compilers/sunpro.mk, à partir de la ligne 88 :

# SunPro compiler must be passed certain flags to compile/link 64-bit code.
#.if !empty(CC_VERSION:M5.9)
_COMPILER_ABI_FLAG.64= -m64
#.elif ${MACHINE_ARCH} == "sparc"
#_COMPILER_ABI_FLAG.64= -xtarget=ultra -xarch=v9
#.else
#_COMPILER_ABI_FLAG.64= -xarch=amd64
#.endif

Puis on bootstrap pkgsrc de cette façon :

imil@geonosis:/opt/pkgsrc/bootstrap$ CC=/opt/sunstudio12.1/bin/cc pfexec ./bootstrap --prefix=/opt/pkg --abi=64

Le fichier /opt/pkg/etc/mk.conf sera renseigné avec les valeurs qui ont servi à bootstraper pkgsrc.

On vérifie l’exactitude de l’opération simplement :

imil@geonosis:/opt/pkgsrc/bootstrap$ file /opt/pkg/bin/bmake
/opt/pkg/bin/bmake:     ELF 64-bit LSB executable AMD64 Version 1 [SSE2 SSE FXSR CMOV FPU], dynamically linked, stripped

poh poh poh, ça claque ou bien.

Notice: iconv() [function.iconv]: Wrong charset, conversion from `UTF-8' to `UTF-8//IGNORE' is not allowed

blaaaaa bla bla bla.

La plateforme est NetBSD 5.0.1, et les packages PHP issus des builds binaires, installés avec vous savez quoi. Et c’est là où le bât blesse. En effet, php5-iconv, dans sa version binaire, est compilé avec la version builtin de la libiconv, et pour une raison que je n’ai absolument pas envie de creuser, cette version là produit l’erreur sus-citée. La solution est assez simple, il suffit d’ajouter à son /etc/mk.conf la directive suivante :

USE_BUILTIN.iconv=      no

Et de se fendre d’un make package clean dans pkgsrc/converters/php-iconv.

Sur zone0, deux domUs sont particulièrement exposés, gcu, qui héberge le site et les wikis, et www2, qui héberge les sites tiers. Ces deux machines (virtuelles) tournent encore sous NetBSD 4.0, cette migration là attendra mon retour de vacances :) et sont munies de la machinerie pkg_comp / pkg_chk. Je me suis déjà longuement étendu sur le fonctionnement de ces deux outils, aussi n’expliqerai-je ici que la simplicité avec laquelle ces mises à jour se sont effectuées (bah ouais, on fait pas partie de marketing@ par hasard…).

Puisqu’elle est moins chargée, c’est sur www2 que nous construisons les packages, /usr/pkgsrc étant un montage NFS pour gcu. Sur www2 donc, nous entrons dans le pkg_comp :

# pkg_comp chroot

Afin de pouvoir mettre à jour les paquets depuis la même machine, et puisqu’evidemment les domUs partagent bon nombre de paquets communs, j’ai créé deux fichiers de type pkgchk.conf, un pour chaque domU. On verifie la jeunesse des paquets de cette façon :

pkg_comp# PKGCHK_CONF=/usr/pkgsrc/pkgchk-gcu.conf pkg_chk -ua

Les paquets listés dans /usr/pkgsrc/pkgchk-gcu.conf seront éventuellement mis à jour si une version plus récente existe. On effectue la même opération avec /usr/pkgsrc/pkgchk-www2.conf, à l’issue de quoi, le repertoire /usr/pkgsrc/packages/All devrait être peuplé de paquets binaires up-to-date, tout ça sans avoir cassé quoi que ce soit sur aucune des machines, puisque pkg_comp effectue les mises à jour dans un chroot(8).

Ainsi, il ne nous reste plus, sur chaque domU, qu’à invoquer pkg_chk de cette façon :

# PKGCHK_CONF=/usr/pkgsrc/pkgchk-www2.conf pkg_chk -uab

Ce qui aura pour effet de mettre à jour tous les paquets plus à jour avec les versions binaires disponibles dans /usr/pkgsrc/packages/All.

Moi j’trouve ça classe.

Ce billet servira de README à ce petit bout de code perl qui utilise les modules Config::IniFiles et WordPress::XMLRPC, lequel devrait arriver dans pkgsrc dès que je reçois l’aval de mon sponsor :)

L’utilisation de cet outil est simplissime, créez tout d’abord un fichier ~/.wpostrc répondant au format suivant :

[monbuergl]
user=monuser
passwd=monpass
url=http://monbuergl.com/xmlrpc.php

Créez un fichier contenant votre billet ayant le format suivant :

title: mon titre convivial

categories: ['categorie1', 'categorie2']

Mon texte passionnant racontant mes aventures

Appelez ensuite le script de cette façon pour ajouter votre billet :

./wpost.pl monbuergl add fichier-post

De cette façon pour le modifier (en ayant préalablement modifié son contenu) :

./wpost.pl monbuergl mod fichier-post

Et finalement de cette façon pour l’effacer :

./wpost.pl monbuergl del fichier-post

Si votre WordPress n’est pas configuré pour de l’UTF-8, placez la variable $use_utf8 à 0.

Attention, cette version étant une première mouture, les posts ne sont pas publiés par defaut, si vous êtes satisfaits du fonctionnement de wpost.pl, editez le et placez la variable $publish à 1.

Par ici la bonne soupe !

update: www/p5-WordPress-XMLRPC est désormais disponible dans pkgsrc