Category Archives: Ports

Dealing with pkg-config detection of FreeBSD’s base OpenSSL

Recently I spotted a software that uses pkg-config to find OpenSSL on the system. This way doesn't work on FreeBSD: it does have OpenSSL in base system, but it doesn't supply '*.pc' file, unfortunately. So, when configure script tries to execute pkg-config openssl it fails, obviously.

There were a number of solutions suggested for this problem on #bsdports like replacing 'pkg-config openssl' with 'pkg-config pkg-config', depending on openssl from ports etc, but the cleanest solution is to define libssl_LIBS and libssl_CFLAGS environment variables, as was suggested by bapt@. In port's Makefile it would look something like this:
USE_OPENSSL=yes
CONFIGURE_ENV+=libssl_CFLAGS="-I${OPENSSLINC}" libssl_LIBS="-L${OPENSSLLIB} -lssl"

Yes, configure will not call pkg-config if we define these 'libssl_*' variables. While it looks quite simple, this issue took surprisingly a lot time to figure everything out. :(

En attendant pkgng…

pkgng c'est cool, ça va être tout beau tout ça, mais voila c'est pas encore fini, il y a beaucoup de boulot à prévoir dessus encore pour que ça rentre en production.

En attendant des babasses FreeBSD on en veut toujours en production.

Voici donc comment je gère mes machines FreeBSD en full binaires.

La machine de build

Tout d'abord il vous faut une machine de build. (Je n'aime pas prendre les packages officiels, parce que je veux des versions plus récentes ou des set d'options différents, parce que avoir un mirroir avec 22000 packages ça ne me sert à rien sinon bouffer de l'espace disque.)

Faire les packages à la main n'est pas non plus très industriel, ni très sérieux.

Utiliser tinderbox me donne des boutons.

J'ai donc réutilisé un outil maison poudriere.

J'y ai rajouté une fonction bulk.

Petit rappel pour commencer, poudriere est un outil très simple ne nécessitant rien qui ne soit pas dans base. Son but est de permettre le test et la génération de packages pour FreeBSD.

Avec cette fonctionnalité de bulk, l'utilisateur donne une liste de packages à manger à poudriere et celui-ci va tous les générer, ainsi que leurs dépendances. Il va présenter le tout sous la forme d'un répertoire de packages identique à ceux officiels.

Commençons donc par créer nos environnements de build en considérant poudriere comme déjà installé.

Voici le fichier de configuration de mon poudriere:

ZPOOL=data
FTPHOST=ftp.free.org
IP=192.168.1.58
ETH=nfe0
PORTSDIR=/usr/local/poudriere/ports
POUDRIERE_DATA=/usr/local/pdata
WRKDIRPREFIX=/tmp/wrk
MFSSIZE=4G

poudriere utilise zfs il suffit de lui donner un zpool il se débrouille avec. Ici nous avons choisi "data". poudriere utilise les jails, il a donc besoin de connaître un host ftp pour récupérer les éléments nécessaires à la construction automatique des jails, une adresse IP et une interface réseau sur laquelle rajouter en alias l'adresse IP donnée.

Il a besoin de connaître l'arbre des ports sur lequel il va travailler, et où il va générer ses données: packages et logs.

Enfin quelques informations comme le WRKDIRPREFIX seront nécessaires si l'on veut tout construire en RAM (mdmfs et tmpfs possibles).

poudriere est maintenant utilisable, préparons donc les machines de build:

# poudriere createjail -v 8.2-RELEASE -n 82amd64 -a amd64 -s

Voila c'est tout ! Vous disposez désormais d'une machine de build pour FreeBSD 8.2-RELEASE pour l'architecture amd64. Vous pouvez en rajouter autant que vous voulez bien sûr.

Le bulk

Il s'agit maintenant de construire ses premiers packages. poudriere souhaite une liste, alors allons y:

# cat ~/listpkgs
ports-mgmt/portmaster
editors/vim
www/newsbeuter
www/elinks
devel/git

C'est déjà pas mal pour tester. Il est bien sûr possible de spécifier des options de compilation via: /usr/local/etc/poudriere.d/make.conf pour les options globales et/ou /usr/local/etc/poudriere.d/82amd64-make.conf pour les options spécifiques à la jail 82amd64.

# cat /usr/local/etc/poudriere.d/82amd64-make.conf
NOPORTDOCS=yes
WITHOUT_NLS=yes
WITHOUT_X11=yes
NO_GUI=yes

C'est prêt on peut lancer le build:

# poudriere bulk -f ~/listpkgs -j 82amd64

Si l'option -j n'est pas donnée alors il fera sur le boulot sur chacune des jails disponibles.

Ce que fait poudriere là c'est construire dans la jail vierge (merci les snapshots zfs) tous les packages demandés, en ayant pris soin de supprimer tout résidu d'un précédent bulk. Puis il va générer l'INDEX et le compresser en bzip2.

Cette étape peut donc être très longue.

Une fois terminée les résultats se trouveront dans : /usr/local/pdata/packages/bulk-82amd64

Le Répertoire étant utilisable tel quel.

Le client maintenant

On part donc d'une installation toute fraiche de freebsd sans l'arbre des ports

# export PACKAGESITE=http://monjoliserver/avec/mes/packages/
# pkg_add -r portmaster

Quelques options pour le portmaster.rc

# cat /usr/local/etc/portmaster.rc
MASTER_SITE_INDEX=http://monjoliserver/avec/mes/packages/
LOCALBASE=/usr/local
PACKAGESITE=http://monjoliserver/avec/mes/packages/
PM_PACKAGES=only
PM_INDEX=yes
PM_INDEX_ONLY=pm_index_only

Comme portmaster recherche encore quelques informations sur l'arbre des ports et que l'on ne souhaite pas ce comportement :

# mkdir /usr/ports/Mk
# touch /usr/ports/Mk/bsd.port.mk

portmaster est maintenant utilisable:

# portmaster www/newsbeuter
[...]
===>>> The following actions will be taken if you choose to proceed:
	Install www/newsbeuter
	Install devel/gettext
	Install converters/libiconv
	Install devel/pkg-config
	Install devel/stfl
	Install ftp/curl
	Install security/ca_root_nss
	Install textproc/libxml2
	Install databases/sqlite3

===>>> Proceed? y/n [y]

[...]
===>>> The following actions were performed:
	Installation of converters/libiconv (libiconv-1.13.1_1)
	Installation of devel/gettext (gettext-0.18.1.1)
	Installation of devel/pkg-config (pkg-config-0.25_1)
	Installation of devel/stfl (stfl-0.21_1)
	Installation of security/ca_root_nss (ca_root_nss-3.12.9)
	Installation of ftp/curl (curl-7.21.3_1)
	Installation of textproc/libxml2 (libxml2-2.7.8_1)
	Installation of databases/sqlite3 (sqlite3-3.7.5)
	Installation of www/newsbeuter (newsbeuter-2.4)
#

Voila retour/docs/patchs bienvenus, as usual :)

FreeBSD needs fresh Blood!

Oh well, it’s time to write some nice job offer, of course it’s all
for free, and you can’t earn any money out of it, but you’ll get a
big thanks, hugs and love from the community. Ask your self, how
long have you been using FreeBSD. Months? Years? Decades? And you
love using it because of whatever reason but at the same time
you’re feeling a bit guilty to use it all for free without giving
anything back? Well now you’ll have the chance to change that.
We at FreeBSD are always in need of new people who are willing
to spare some of their time and effort into FreeBSD development.

Let me share a bit of my experience. I have (re)built a lot of
teams in the past, such as gecko@, kde@, python@, and I was
involved in the creation of FreeBSD vbox@ team. I have always
managed to get assistance from a lot of people, but recently more
and more people have started to complain about the slowness,
broken commits and requested for more Call for Testing. And that
is actually a big problem. I am the kind of person who like to
call for test, but I am also the kind of person who easily gets
disapointed when I’m not getting much feedbacks. The best example
here is ATI, Xorg and Xfce update. I did a call for testing because
Xorg and Driver updates is always a big issue because there are so
many different hardware involved with various configurations. From
the call for testing, we managed to get a total of 19 mails of
positive feedback and after 2 weeks I’ve committed the update.
What happened after that was I received a lot of complains for
not conducting much testing, yadda, yadda. Well I say it ain’t
my fault for not testing much, but it is also your fault for not
helping us. It is always easy to blame instead of helping. Ask
yourself why have you not helped us in testing properly and give
us feedbacks. Complaining is fine when it is done in the right
way, with the right tone.

While I’m talking about Xorg, the FreeBSD Xorg Team is currently
a one man show effort, supported by kwm@ and fluffy@. Xorg alone
is too big to get worked on. Plus you should not think that it is
affecting the ports only, but it affects the kernel as well, which
we are having the most problems at the moment. And of course I
would like to call for help on that as well. Based on my last call
for help, it is funny to see how many people wanted to offer some
help, but after knowing the amount of work involved, I have stopped
hearing from these guys. I understand that to update Xorg is always
a crappy job but I love doing it, because it is nice to get more and
more experience in understanding how things work, and it helps to
improve my skills a lot.

Lets a talk a bit about our FreeBSD KDE Team. KDE is nice, but it
really is a fat project. It needs a lot of love, and maintenance
time. Currently it’s a 4 people project, namely makc@, fluffy@ and
avilla@. While for support Raphael Kubo da Costa is handling it
actively. The thing is, KDE involves more than just KDE packages.
It includes Qt, PY-Qt, KOffice and Cmake as well. It is a big
project too and it would be nice to find more people to contribute
in the development.

And now lets talk about gecko@. gecko@ includes all Mozilla Project,
namely Firefox, Thunderbird and Seamonkey. It is currently maintained
by beat@ and decke@, and supported by flo@ and andreas. So again,
I’d like to see some fresh faces for this project as well. If you are willing
to help, do ping us via mail :p.

As for FreeBSD Gnome Team, well I can’t say much about gnome but
whenever I see the cvs commits in marcuscome tree, it seems like
most work for the upcoming gnome3 is done by kwm@, and supported
by marcus@, mezz@ and avl@. Gnome includes not only Gnome things
but it also include gtk and cairo, the one that always cause
problems in a major update. I think the team would love to have
some fresh blood in the team.

Okay, all of these need an understanding of programming and
scripting. If you think that you can’t do any of that, testing would
also help much. FreeBSD is one of the best documented open source
project, so that’s another area that could use some help too. Check
if FreeBSD.org is available in your language, or start helping to
improve the FreeBSD documents in your language. It would be very
helpful and the community will thank you for that. So if you would
like to offer some help, ping me in irc/jabber/mail :-)

- Martin

PCBSD sponsor FreeBSD KDE Build box

I’d like to note that the KDE FreeBSD Team is now
receiving assistance from PCBSD again. Since I left
the KDE Team, things have gone terribly wrong. After
having a few conversations with my old team, I finally
figured out what the problems were. But the main problem
was missing a package build system, and I managed to find
a solution for that with Kris’s help. Apparently this was
a root cause to some other issues and having it solved
helped to speed up other processes.

I’d like to say thanks to Kris Moore, Josh Paetzel,
Dru Lavigne and of course the iXsystem for their
generous donation to build a test machine for KDE.

PS: This means not i jump back to the KDE Team
but I’m always willing to Help when i can.

[CFT] Xorg 7.5-Miwi(1) FreeBSD Edition

Oy boys and gals,

The Xorg T(m)eam is happy to announce the next round of Xorg fun! The X-Server has
been patched to the latest 1.7.X series, drivers and fonts have been updated to the
latest versions, but unfortunately we are not able to update libGL, drm and xorg-server
to a higher version because FreeBSD doesn’t support GEM/KSE (yet), but it looks good
for now, as kib@ is working on that, so we hope the future will be better for us.
This update includes some components from Xorg 7.6 with a lot of improvements, and it
seems that the performance is much better than the old version. We are calling the
update xorg 7.5.1.

We hope you will enjoy the new stuff and give us a lot of feedback. We will start an exp-run
tonight and depending on how much feedback we get, we plan to commit this update by the
first weekend of March. A note for ATI users, the driver was updated to 6.14.0, so you
may need to add some stuff to your xorg.conf in the “Section “Device”"

Option “int10″ “on”
Option “BusType” “PCIE”
Option “RenderAccel” “on”
Option “AccelMethod” “exa”
Option “DynamicPM” “on”
Option “DRI” “on”

So to get the xorg stuff you will need to:

run

svn co https://trillian.chruetertee.ch/svn/ports/branches/xorg-dev

A small merge script to merge the svn checkout into the real portstree can
be found here:

http://people.freebsd.org/~miwi/xorg/xorgmerge

The script is a modified version of the kdemerge script. Please set the KDEDIR
variable to the path of your X.org ports.

After merging, run one of the following command, depending on which tool you use
to manage your installed packages.

portupgrade -a \*
portmaster -a

Please report any problems and issues to x11 (at) FreeBSD.org.

I would like to thank:

Beat Gaetzi
Dima Panov
Koop Mast
Eitan Adler

Without these people the Xorg update would still not be ready now.

PS: Please don’t send us mails with ‘xorg update dosen’t’ work.
If you send us a report, please include the latest Xorg.conf
Xorg.log, uname -a output and pkg_info output. Thanks.

Happy Updating!

[CFT] VirtualBox 4.0.4 for FreeBSD

Time for a new round FreeBSD Vbox’s Team called for Testing,

A few of you have probably wondered what happened to our VirtualBox
efforts for FreeBSD. Well it took a bit longer then expected and a few
problems were found that needed to be resolved first but most of the
things are looking fine now and almost all patches have been pushed
upstream with 4.0.4 so here we are now.

We will continue to work on VirtualBox for FreeBSD and upstream is also
very helpful to us but we could need a few more hands to better keep up
with the work and especially improve and fix the Guest Additions. So if
you want to help please contact us or have a look at our Todo list.

This result wouldn’t have been possible without the continuous help of
the VirtualBox Developers and a lot of people from the FreeBSD
community! (names in alphabetical order and probably missed a few,
sorry
for that!)

- Alexander Eichner
- Anonymous
- Beat Gätzi
- Bernhard Fröhlich
- crsd
- DomiX
- Doug Barton
- Grzegorz Blach
- Hans Petter Selasky
- Julian Stacey
- Jung-uk Kim
- Jürgen Lock
- Klaus Espenlaub
- Martin Wilke
- Mattia Rossi
- Michael Butler
- Sean C. Farley
- Steve Wills
- tombsd
- Vivek Khera
- well-wisher
- Wietse Venema
- Yuri
- many more from emulation@

Please when testing this ports backup all your virtual machines first.
Also please build the port with DEBUG option enabled and send us the
logfile when any VM crashes. Without them it’s very hard to figure out
what went wrong.

Highlights with 4.0:
- USB support (by Hans Petter Selasky)
- Asynchronous I/O
- Guest additions got startscripts and a integration into the desktop
environments
- www/phpvirtualbox updated to 4.0-3

Changelog for 4.0:
- http://www.virtualbox.org/wiki/Changelog

Short configuration help:
- http://wiki.freebsd.org/VirtualBox

Todo List:
- http://wiki.freebsd.org/VirtualBox/ToDo

http://home.bluelife.at/ports/virtualbox-cft-20110218.tar.gz


Thanks and good luck,

[CFT] Pear workaround for CATEGORY problems ..

Since last year pear has changed the package layout. And since several months ago,
I have seen a lot of FreeBSD maintainers removing the CATEGORY flag from their ports.
The problem with that is the packages won’t be installed at the right location anymore.
Here is a patch to fix the problem, feel free to test:

http://people.freebsd.org/~miwi/pear.diff

I would be happy if anyone has a better suggestion to replace the flag CAT_IN_WRKSRC…

Python Infrastructure changes Roadmap

Howdy,

I just want to inform you that the python team plans to make some infrastructure changes.
The changes involves the following 3 steps:

[python 2.5/2.6/2.7 improvements/ py 3.2 adding]
We plan to integrate some important patches:
ports/153952 ports/148406 ports/149167 ports/152224 ports/133081

python 3.2 will be released on 12 Feb, we’ll wait for the final release
before adding it to the build. For all of these we will do an exp-run
to make sure nothing will break during the build. It takes approximately 2 weeks if all works fine.

[python24 removal]
Python 2.4 is not supported anymore since 2008, and it has a lot of security problems.
Unfortunately this will cause the removal of some zope stuff. The following ports are affected:

www/zope210
www/zope211
www/zope28
www/zope29
+ zope plugins which are dependant on one of these ports. Philip is working on an
update to some new zope versions. I hope we can cooperate with him to get things
smoothly done. For all these we will do an exp-run to make sure nothing will break during
build. It takes approximately 3 weeks if all works fine.

[python 2.7 move to default]
python 2.7 is already stable enough to be moved over as default. For this one we will do an exp-run
to make sure nothing will break during the build. If all works fine, we think we can complete it by the
first week of March.

[CFT] xf86-video-ati 6.14.0

Howdy,

2 days ago was a new ati driver released. fluffy@ and me was using for
few weeks the git version without problems, but we’d like to make
sure this dosen’t broke anything for our ati users.
Here is a patch: http://people.freebsd.org/~miwi/ati-6140.diff
Changelog: http://lists.freedesktop.org/archives/xorg-announce/2011-February/001602.html

Please test and report back, if no problems I’d like to commit it next week.

thx
PS: this release fix some problems with HD54XX chips the bug with strg+ctrl+backspace; bug is gone for me.
PSS: Thx Dima for preparing the git tarball :P

[CFT] KDE SC 4.6.0 for FreeBSD.

Hello Internet,

The FreeBSD KDE Team is happy to let you know that KDE SC 4.6.0 has been
released a few Days ago, and the Release is ready for a public test. Before
you ask, no, we do not want to put KDE 4.6.0 in the ports tree before
FreeBSD 8.2/7.4 is released.

What’s new:
KDE SC 4.6.0 provides major updates to the KDE Plasma workspaces, KDE
Applications and KDE Platform. Theses releases, version 4.6, provide many
new features in each of KDE’s three product lines. The official
release notes for these releases can be found at
http://kde.org/announcements/4.6/

Now you can get KDE SC 4.6 via svn checkout:

svn co http://area51.pcbsd.org/trunk/area51/PYQT/
svn co http://area51.pcbsd.org/trunk/area51/PORTS
svn co http://area51.pcbsd.org/trunk/area51/KDE
svn co http://area51.pcbsd.org/trunk/area51/Tools/

Then try:

sh Tools/scripts/portsmerge
sh Tools/scripts/kdemerge

Happy updating!!

Thomas Abthorpe, portmgr-secretary@ » FreeBSD 2010-09-23 17:06:54

Where has the summer gone?  So much can just slip away, and not get done with the excuse “Summer Schedule Slippage”.

During the summer, I have been fortunate to co-mentor Ashish Shukla, ashish@ with pgj and Baptiste Daroussin, bapt@ with jadawin.  You can read jadawin’s interview with Baptiste.

Congratulations on receiving your commit bits!

FreeBSD Ports and FreeBSD 6 EoL

The FreeBSD Ports Management Team wishes to remind users that November 30
is also the end of support for the Ports Collection for both FreeBSD 6.4
RELEASE and the FreeBSD 6.x STABLE branch.  Neither the infrastructure nor
individual ports are guaranteed to work on these FreeBSD versions after
that date.  A CVS tag will be created for users who cannot upgrade for some
reason, at which time these users are advised to stop tracking the latest
ports CVS repository and use the RELEASE_6_EOL tag instead.

While many people still use RELENG_6, it is at the end of it’s development
cycle. The Ports Management team has set the following policies with regard
to EOL/EOS of this branch and we kindly ask developers to implement these:

- We will keep building 6.4 packages as long as we have the resources.
6.x package builds will however be deprioritised, meaning they will not
be rebuilt as frequently.

- We will continue to support the 6.x infrastructure until RELENG_6
EOL (11/30/2010) by building the INDEX on RELENG_6 for use by ‘make
fetchindex’, and making sure that the ports collection infrastructure
(bsd.port.mk, etc) continues to function on RELENG_6, subject to the
reduced testing that this branch will receive.  This means that problems
may be noticed only after the fact and may require community support to
develop and test fixes.

- We do not require committers/maintainers to support 6.x, but ports
will need to be marked BROKEN/IGNORE if they do not build/run.

- Port maintainers are strongly encouraged to accept patches from the
community that allow their ports to build and run on 6.x.  However,
since running on 6.x is no longer a requirement, maintainers may use
their discretion in cases where a proposed patch would be disruptive
to other supported FreeBSD branches, or would unreasonably impede
ongoing maintenance of the port.

- We will continue to accept patches for ports collection infrastructure
(bsd.port.mk, etc)

- We encourage all users and developers to migrate to the FreeBSD 7.x or
8.x branch, both of which is a stable and mature platform, and are now
the ‘reference’ branches for the ports collection.

Please also see the secteam@ announcement,
http://lists.freebsd.org/pipermail/freebsd-announce/2010-September/001344.html

/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 :

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]}/&#x3E;/>}/\<\/title\>/}/\<title\>} } } > portscout.txt

Ports feature freeze starts soon for FreeBSD 8.1

In preparation for 8.1-RELEASE, the ports tree will be in feature freeze after release candidate 1 (RC1) is released, currently planned for June 11.

If you have any commits with high impact planned, get them in the tree before then and if they require an experimental build, have a request for one in portmgr@ hands within the next few days.

Note that this again will be a feature freeze and not a full freeze.  Normal upgrade, new ports, and changes that only affect other branches will be allowed without prior approval but with the extra Feature safe: yes tag in the commit message.  Any commit that is sweeping, i.e. touches a large number of ports, infrastructural changes, commits to ports with unusually high number of dependencies, and any other commit that requires the rebuilding of many packages will not be allowed without prior explicit approval from portmgr@ after that date.