Joerg@ a commité ce matin une refonte du fonctionnement de la cible make install.
La cible make install telle qu’on la connaissait jusqu’à présent a été renommée en make stage-install, et la cible make install a été refondue entièrement. Le comportement dépend en fait maintenant de l’utilisation ou non du DESTDIR.

Si le package en cours de construction supporte DESTDIR, et que ce dernier est activé, alors « make install » fonctionnera de la même manière que « make stage-install », c’est à dire que le paquet est construit et installé dans le DESTDIR (${WRKDIR}/work/.destdir par défaut), le paquet binaire construit puis installé par pkg_add (en tant qu’utilisateur root si besoin).
Pour installer le paquet dans le DESTDIR sans construire le paquet, il faut maintenant utiliser la cible « make stage-install ».

Si le paquet ne supporte pas DESTDIR, ou si DESTDIR n’est pas activé, alors la cible « make install » aura le comportement d’autrefois, c’est à dir que les fichiers seront installés dans {PREFIX}.

Pour les gens qui font des « bulk-builds », il faut mettre pbulk à jour à la version 0.46 pour que cette modification soit prise en compte convenablement.

Ce matin, Andreas Gustaffson a posté un lien vers la page sur laquelle il maintient des statistiques sur l' »état » de santé de NetBSD-current.
Ces statistiques représentent le nombre de lignes dans le log de build.sh lors de la compilation d’une release i386, ainsi que des points de couleurs indiquant si le build est un succès (en vert) ou un échec (en rouge). Les graphes permettent de mieux visualiser le nombre de succès ou d’échecs dans la compilation, et son évolution au cours du temps.

C’est l’heure du bilan, vous trouverez le bilan complet ici. Ce n’est pas moins d’une centaine de rapport de problème qui ont été soldés. J’ai envie de dire bravo aux « sportifs » qui y ont participés !

Et voilà, on est le 19 février, il a donc débuté, vous pouvez suivre son évolution sur la page du wiki. Il se terminera le 21 février, 3 jours intense pour les développeurs en perspective.

Pour ceux qui aurait loupé un train, il s’agit de corriger un maximum de bugs, de PR (rapport de problème)  et de passer un maximum de patchs. La définition plus approfondie et plus généraliste est sur wikipedia mais en anglais.

Surtout Hubert Feyrer qui a déjà publié un billet conséquent à ce propos sur son blog.

Pour rappel, Google Summer of Code est un événement annuel de soutien au logiciel libre organisé par Google. Il consiste en la rémunération d’étudiants par Google pendant l’été pour qu’ils contribuent à des projets libres importants.

Depuis le début des GSoC, en 2005, NetBSD participe chaque année en assignant des projets liés à NetBSD et des mentors, qui sont des développeurs officiels NetBSD, à des étudiants.

Cet événement a toujours porté ses fruits et a été l’occasion pour nombre d’étudiants de montrer leurs compétences sur des projets de logiciel libre de grande ampleur et d’obtenir, pour certains, le @ si prestigieux. C’est pourquoi il y a de grandes chances que NetBSD participe de nouveau cette année.

Aussi, le site web de GSoC 2010 est déjà en place. On y trouve notamment la timeline, indiquant entre autres la période de candidature des organisations proposant des projets de logiciel libre, du 8 au 12 mars et la période de candidature des étudiants, du 29 mars au 9 avril.

Pour en revenir à Hubert Feyrer, il décrit sur son billet un projet qu’il propose pour GSoC 2010. Le but de ce projet est d’améliorer le pilote de cryptographie swcrypto, notamment l’accélération matérielle des opérations de cryptographie. Ce travail reposera sur opencrypto(9), un framework utilisé tant bien par les applications en espace noyau (comme fast_ipsec(4)) que par les applications en espace utilisateur (comme OpenSSL).

Les étudiants motivés pour contribuer à NetBSD par l’entremise du GSoC 2010 peuvent dès à présent suivre la préparation de l’événement et préparer leur candidature en consultant la page GSoC de NetBSD et ses idées de projets.

Samedi 20 Février, Matthias Drochner a commité le code désactivant le mapping de l’adresse 0 depuis l’espace utilisateur.
Autoriser un programme à mapper l’adresse 0 peut être un risque de sécurité sur certaines plateformes, telles i386 et amd64, comme Brad Spengler l’a démontré sous Linux en fin d’année dernière.
Le risque est l’injection de code ou de données dans l’espace adresse du noyau, à l’adresse virtuelle 0. Même si aucune faille connue dans le noyau permet accéder à ce code ou ces données, il est vraisemblable qu’elle existe, aucun code n’étant 100% correct. Le risque a donc été levé en désactivant le mapping de cette adresse 0.

Le code NetBSD natif ne devrait pas être affecté dans la majorité des cas. Par contre, certains programmes utilisant le mode « VM86 » (notamment les émulateurs DOS), ainsi que des émulateurs pour d’anciens matériels pourraient s’arrêter de fonctionner.
Matthias a prévu la possibilité de revenir au fonctionnement précédent, soit en activant l’option de configuration USER_VA0_DISABLED_DEFAULT=0 et en recompilation un noyau, soit en fixant le flag sysctl vm.user_va0_disable à la valeur 0.

Comme d’hab, les problèmes sont à signaler à current-users@

Darran Hunt a tenu parole. Après avoir annoncé l’arrivée de DTrace dans le code source de NetBSD, il vient de commiter le code en question, qui est maintenant activable via l’option de de compilation MKDTRACE (désactivée par défaut).
Tests bienvenus, et comme d’habitude, les problèmes sont à remonter sur la liste current-users@.

La news vient de tomber fraichement sur le canal. Il y aura une session d’exam de certification BSD au salon Solutions Linux. Vous pouvez d’ores et déjà vous y inscrire ici. Ce sont nos amis de BSDFrance qui chapeauteront cet examen ! A vos révisions !