pkg 1.1

After almost a year of development pkg 1.1 has reached the ports tree, actually pkg 1.1.1 has 1.1 was too buggy :(

What happened in 1 year of development (I'll focus on use visible features)


The multi-repository support was experimental in pkg 1.0 and to be honest it was not really usable. With pkg 1.1 the support has been greatly improved and it is now the default behaviour (you can't deactivate).

To define repository you just have to create a simple configuration file in /usr/local/etc/pkg/repos/myrepo.conf

  url: http://myurl
  pubkey: /usr/local/etc/pkg/repos/myrepo.key
  mirror_type: SRV

Meaning you can provide a package to autosetup a repository creating a package containing like this one:

$ tar tf myrepo-1.0.txz

Host this file somewhere and say to the use to do the following

$ pkg add http://yourhost/myrepo-1.0.txz

Now you can see that the repository is configured properly pkg -vv should show you in the last lines:

                    url: http://private.etoilebsd.net/91-default-server
                enabled: yes
                    url: http://myurl
                    key: /usr/local/etc/pkg/repos/myrepo.key
                enabled: yes
            mirror_type: SRV

The user can also choose to make sure a given package will always be updated from 'myrepo'

$ pkg install -r myrepo mypackage
$ pkg annotate -A mypackage reposiroty myrepo

Now the package 'mypackage' will only be updated from 'myrepo'

pkg lock/unlock

If a use want to prevent a package from being updated anyway he can just lock it:

$ pkg lock mypackage

To unlock it just update use the following command:

$ pkg unlock mypackage

ssh transport

If your server has pkg 1.1+ installed then you do not need so set up a HTTP server or a FTP server, pkg can now use ssh to share the packages

packagesite: ssh://user@host:/path

Or in the repository configuration:

url: ssh://user@host:/path

Do not forget to restrict on the server the directory where files can be retrieved by adding the following line on the server pkg.conf:



This allows to add any key/value annotation to a given package once installed, if you recreate the package after that, the annotation will be added to the manifest and then a new reinstallation will keep the annotation.


pkg now supports 2 kind of plugins: commands (to add new subcommand to pkg) and hooks (which will be executed in the middle of any process of pkg).

I'll write another post dedicated to plugins later.

explained reinstallation

As pkg is able to determine that a package needs to be reinstalled because the remote one has been compiled with new options or the required shared libraries for the package has changed, pkg now explains why a package will be reinstalled.


We have stabilized the public API, so now bindings, and program using libpkg are more than welcome :) Lots of cleanup has occurred in the code, and lots of code optimisation. New pkg_printf(3) function to help printing a preparing strings with pkg informations. We are more and more adding some regressions test using the ATF framework. The catalog has changed and is now a simple yaml files which gives us more flexibility and allow simples incremental update. pkg audit can now directly read the vuxml native format.

Way more things but I'll let you discover :)

Thanks to all people that has been involved in the new release (coders, testers, doc writers, etc.)


Stash for svn

When hacking on the ports tree or on the sources, you often have unfinished patches you are testing step by step.

I'm also hacking on something unfinished and then some other area needs some fixes with a higher priority and in the same time some people are asking for some testing/review on their own patches. So I need to quickly interrupt what I was working on get back to a clean tree, and switch from patches to patches.

While doing this is easy with git, fossil or mercurial it is more complicated with svn. The feature in particular I use on fossil/git for that is the stash feature.

So I wrote my own stash for svn, and because of mobility I was willing to be able to share my patches across boxes, so I have made stash able to be under a vcs itself, with support for git, hg, fossil and svn as a vcs for the stash.

How does it works: The stash command will discover that .svn of the working copy you are working on and will create a patches subdirectory.

Now imagine that directory itself contains a .hg, .fslckout, a .git or a .svn then stash will know it is being under vcs control.

$ stash save <name> [-u] [files...]

This will create a .svn/patches/.patch file using svn diff --git on the specified files (if none is provided it will diff the current directory the stash command is being run on).

Once the diff created it will rollback the tree (on specified files or current directory) to the clean state before any modification.)

By default it will not overwrite a patch with the same name except is -u is provided on the command line.

If the stash directory is under a vcs control then a add/commit (or just commit in case of update) will be performed in the stash directory.

$ stash ls

List all the available patches.

$ stash show <name>

Print on stdout the content of a given patch

$ stash apply <name>

Apply a specified patch on the working copy using svn patch --strip 1 from the root of the working copy.

$ stash rm <name>

Remove/destroy a patch from the stash directory. In case the stash directory is under vcs control then the proper rm command followed by the needed commit will be performed.

$ stash pop <name>

It is the equivalent of stash apply followed by stash rm this is useful when your patch is finished and you want to commit it directly.

$ stash push <name>

Push (scp) the patch on a remote site (currently freefall is hard coded :)

$ stash sync <name>

This command is only useful if the stash directory is under vcs control, it performs the necessary pull/push mechanism depending on the VCS used.

I use fossil to maintain the stash script And here is for example my repository of patches for the ports tree

No git svn won't have worked in my case for multiple reason: 1/ want something flexible which can also only work with svn 2/ the ports tree can work properly with git svn (properties setting adding new files etc will not work as one expect) 3/ I want to use fossil for the stash, other might prefer svn or hg.

Disclaimer: hg and git support hasn't been tested yet, patches welcome to fix them if needed. if you want to add support for your own favorite vcs just them me the patches I'll integrate them.


Conversion to new options: done

It took a year but at least it is done! Huge thanks to all people involved in the new Option Framework.

So now what we have:

What still needs to be done:

With the previous done, my 2 main priorities for FreeBSD now are:


New options framework is in, what next?

The new options framework has been committed one week ago, I would have expecting things to have been smoother but lots of fixes has been needed to have it correctly working.

In one week everything at least every major issues reported has been fixed, and now everything is working again as expected (if not please report it to me asap so I can fix it)

So from a maintainer point of view what does it brings:

From a port developer point of view:

From a user perspective:

How to enable/disable an options? simple in make.conf:

OPTIONS_SET= BLA # enable BLA for the whole ports tree
OPTIONS_UNSET=	BLA # disable BLA for the whole ports tree
foo_SET= BLA # enable BLA just for foo
foo_UNSET= BLA # diable BLA just for foo

the user settings have an order or priority:

Note that you can disable this automatic make config by adding NO_DIALOG to your /etc/make.conf.

All of this means that ports-mgmt/portconf is not needed anymore for a centalisation of your configurations.

Short term goal: to avoid having the ports tree infrastructure keeping for ever old code like it was the case in the past for other manjor improvements, please update your ports to the newoption framework as soon as possible.

Long term goal:

The options framework was an important step in the cleanup of the ports infrastructure, next step in my concern will be to provide stage directory support aka: a ports will install everything in a stage directory and sync the files following the plist to the system or directly create the package out of this stage directory. Every sane package building system are using that kind of thing but the FreeBSD ports this is necessary as it also open the way to tons of new possibilities. Stay tune, this is coming soon!


SQLite backend for CBlog

The trunk of cblog is slowly moving its backend from cdb to sqlite.

This blog is now running on top of sqlite.

Why this change? just for simplicity, now everything is contained in a single and simple sqlite file, this simplify a lot some part of the code (which wasn't very complicated anyway).

The migration of the code was done the quick and dirty way, I'll try to cleanup and improve when I'll have more time.

Note that in the trunk there is a new tool cblogconvert that can convert from 0.1 tinycdb + files backend to sqlite.

At the same time I also remove fcgi support and now uses libevent2 instead, it help cleaning up the code.

Maybe in the future I'll also write my alternative to clearsilver, maybe something using haml format, still undecided now.


Fresh blood needed for LibreOffice

For some time now, I have been maintaining pretty much alone the LibreOffice port for FreeBSD, trying to provide all the features LibrOffice has to our users.

I managed to port the 3.3.x series of LibreOffice to FreeBSD some time ago and tried to keep updating it as fast as possible as soon as new releases were out.

At the beginning I was thinking about maintaining 2 concurrent of LibreOffice at the same time: legacy and "normal" to reflect the upstream support. But this take too much time, I'll kill libreoffice-legacy in the next weeks.

The problem is that it is really time consuming, not that it is really complex, the LibreOffice upstream is really nice and really responsive, other maintainers from the BSD community, has also been really helpful.

Some time ago, I decided to create office@ to help maintaining every office related ports maintained on FreeBSD, it worked quite well, sunpoet@ taking good care for examples of the different hunspell/hyphen/mythes dictionnaries/thesaurus, pfg and maho taking care of Apache OpenOffice and all of us working on the third party libraries/fonts/etc needed by all those big office project.

But I'm still missing help on LibreOffice itself, I just committed 3.5.2 some days ago, and 3.5.3 is almost there.

We also still have known issues on 3.5.2:

All the libreoffice work is done on redports svn

if you have an account and are willing to help tell me so that you can have access to the office svn on redports.


From git to fossil

I recently killed git.etoilebsd.net, while I still appreciate git, and will keep it for pkgng I was looking for a new solution to be able to share my other projects.

The main problem I have with hosting git, is that I need lot of third party tools, to have some kind of project management.

To display in a web browser my git projects, I was using cgit which does its job very well, and is simple to maintain: simple and clean configuration files, just a simple C cgi, all what I do like. But for those projects I was also needing 2 others things, a simple web page, if possible maintainable within the git repository itself which cgit can do and a ticket system (some users complained not being able to report bug/feature request).

I first tried to setup and install roundup, it is quite simple and does its job quite well, it can use sqlite, to avoid me running a useless database, it doesn't require too much dependencies so it was great but badly integrated with git (I don't want to spend time tunning too much the software I use)

I also had a look to all those forge available, like chiliproject or redmine, or the old but still good trac. While I did like trac, it requires too much dependencies for my small hostings needs. The two first are even worst in that area plus I find their url completely illogical to me.

The others available were using php or java and were most of them needing a mysql/postgresql database, I rejected them because I don't want any php or java software running on my small server, and I don't want any database constantly running on it either.

For a while now I am following the development of an alternative scm, named fossil, it is a small all-in-one project: scm, wiki, events, ticket contained in a single binary. It is really easy to use, requires nearly no administration, have all the modern features you can expect from a DVCS. And not that important for me but still good, it is BSD licensed.

To migrate from git to fossil it was really easy:

$ cd poudriere
$ git fast-export --all | fossil import --git poudriere.fossil

That is all, I know have a fully working poudriere.fossil.

To serve the fossil repositories on my server here is what I did:

Add an entry to /etc/services:

$ echo "fossil	8080/tcp" >> /etc/services
$ services_mkdb /etc/services

Add an entry to inetd:

$ echo fossil stream tcp nowait.1000 www /usr/local/bin/fossil /usr/local/bin/fossil http /data/fossil" >> /etc/inetd.conf
$ echo "inetd_enable=YES >> /etc/rc.conf
$ service inetd start

Add a simple virtual host to nginx:

server {
	server_name fossil.etoilebsd.net;
	listen 80;
	listen 443 ssl;
	location / {
		access_log /var/log/nginx/fossil.access.log main;
		proxy_redirect off;
		proxy_set_header Host $host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

That's all now, your fossil repositories are served properly, you can now access them from the fossil cli using both ssh or http (I only serve http for now in my case)

My fossil repositories are:


Home made pkgng repositories

By popular demand I have been requested a tutorial about how to maintain your own pkgng repositories.

Currently the best solution for that is to use poudriere (ports-mgmt/poudriere).

Let say you want to maintain 2 repositories: 8.2-RELEASE i386 and 9.0-RELEASE amd64.

For that you will need an amd64 (to support both amd64 and i386 box with 9.0 binary support and 8.2 binary support, a default 9.0-RELEASE amd64 should be enough :)

poudriere only depends on zfs and sh, so you won't need much, just a zfs pool available.

First: install poudriere:

$ make -C /usr/ports/ports-mgmt/poudriere install clean

To be able to build the repository the host would also need to have pkgng installed (no need to convert it to pkgng anyway.)

$ make -C /usr/ports/ports-mgmt/pkg install clean

Now configure your poudriere, defining some configuration to /usr/local/etc/poudriere.conf:


This should be enough (see poudriere.conf.sample for more informations)

Create the default ports tree:

$ poudriere ports -c

Create the two jails (in fact it will be chroot :))

$ poudriere jails -c -j 82i386 -v 8.2-RELEASE -a i386
$ poudriere jails -c -j 90amd64 -v 9.0-RELEASE -a amd64

Make them pkgng aware

$ mkdir /usr/local/etc/poudriere.d
$ echo "WITH_PKGNG=yes" > /usr/local/etc/poudriere.d/82i386-make.conf
$ echo "WITH_PKGNG=yes" > /usr/local/etc/poudriere.d/90amd64-make.conf

Add the list of packages you want to build:

$ cat ~/mylist1
$ cat ~/mylist2

If you want special options just add them to you different make.conf in poudriere.d

to share options between all the jails managed by poudriere, add them to /usr/local/etc/poudriere.d/make.conf

You can now create your packages:

$ poudriere bulk -f ~/mylist1 -j 82i386
$ poudriere bulk -f ~/mylist2 -j 90amd64

When finished you will get 2 pkgng repositories in /poudrieredata/packages/82i386-default and /poudrieredata/packages/90amd64-default

You can now provide them through your webserver.

On you client boxes just:

$ echo "packagesite: http://yoururl/82i386-default" >> /usr/local/etc/pkg.conf


$ echo "packagesite: http://yoururl/90amd64-default" >> /usr/local/etc/pkg.conf

If your client box already has packages from an old installation, first convert it to pkgng

$ fetch http://yoururl/90amd64-default/Latest/pkg.txz
$ tar xf ./pkg.txz -s ",/.*/,,g" "*/pkg-static"
$ ./pkg-static add ./pkg.txz
$ pkg2ng

Now you can forget about pkg_install and pkg2ng

Just use pkgng (for example):

$ pkg update
$ pkg upgrade
$ pkg install firefox

To update your repository:

$ poudriere ports -u # this update your default ports tree
$ poudriere bulk -f ~/mylist1 -j 82i386 -k
$ poudriere bulk -f ~/mylist2 -j 90amd64 -k

bonus poudriere will rebuild only what has changed and what is impacted by this change.

Once it is done simply upgrade your client box:

$ pkg update
$ pkg upgrade

More informations on poudriere here


Full binary upgrade with pkgng 1.0-beta7

My laptop (a small eeepc 1000H) is running FreeBSD 8.2-RELEASE for a while now, I didn't upgraded it to 9 because it would have taken eons to rebuild all the packages I use on this laptop.

Of course this laptop has been converted to pkgng long time ago, and I'm happily using it in a full binary way: building packages and preparing pkgng repositories on a build box using poudriere (ports-mgmt/poudriere).

In the git version of pkgng (what would become soon 1.0-beta7) one of the new feature is the ability to reinstall the whole set of packages. This allow us to now perform a full binary upgrade of the system.

Here is how I performed an upgrade from 8.2-RELEASE to 9.0-RELEASE without building anything on that small laptop:

Create a 9.0-RELEASE repository

First you need to prepare a set of packages for 9.0-RELEASE on poudriere:

# create the new jail:
$ poudriere jail -c -j eeepc9 -a i386 -v 9.0-RELEASE
# copy the make.conf from the old to the new jail:
$ cp /usr/local/etc/poudriere.d/eeepc-make.conf /usr/local/etc/poudriere.d/eeepc9-make.conf
# build the set of packages:
$ poudriere bulk -f ~/bulkeeepc -j eeepc9 -k

Now that your repository of packages is ready just expose it in your http server and you are done with that part.

Upgrading the laptop

Update to the lastest 8.2-RELEASE

You need to upgrade your 8.2-RELEASE to the latest version available if not already done (it contains a fix for freebsd-update which is necessary to perform the upgrade to 9.0)

$ freebsd-update fetch
$ freebsd-update install

Upgrade to 9.0-RELEASE

You can now upgrade to 9.0:

$ freebsd-update -r 9.0-RELEASE upgrade
$ freebsd-update install
$ reboot
$ freebsd-update install

Once you are here your system now upgraded to 9.0-RELEASE but still have some old shared object files, it is the moment when you should perform the upgrade of the packages.

Edit your /usr/local/etc/pkg.conf file and adjust the url of the PACKAGESITE to the new eeepc9 repository

$ pkg update
$ pkg upgrade -fy

you can now remove the old shared object:

$ freebsd-update install

In case you would have forgotten to perform the package upgrade, pkg-static is there to save your life, you can still do it now:

$ pkg-static update
$ pkg-static upgrade -fy


Aujourd'hui j'ai un an

Il y a un an jour pour jour que je faisais mon premier commit dans les ports FreeBSD sous le mentorat jadawin@ et tabthorpe@ merci à eux :).

Ça passe vite... :)

Le bilan de cette première année est plutôt positif je pense malgré quelques ratés. Plein de bonnes choses mais aussi quelques trucs que je pensais faire que je n'ai pas encore réussi à pousser.

Je vais commencer par les échecs et finir par les réussites c'est toujours mieux de finir par les bonnes choses :)

Pas Bien

Il y a un moment déjà que je bossai sur un framework d'options pour les ports qui viserai à remplacer l'actuel en offrant plus de fonctionnalités: groupe d'options, options incompatibles, options dépendantes d'autres options etc. Dans ce cahier des charges, il fallait aussi que le nouveau framework puisse remplacer le vieux de manière transparente.

La première étape je l'ai atteinte assez facilement, la complication est venue quand il a fallu faire la seconde. Du coup un an après je n'ai toujours pas pu pousser mon framework et il reste toujours le vieux dans l'infrastructure. J'espère pouvoir changer ça rapidement, j'ai une idée à creuser sous le coude :).

Un autre loupé pour le moment c'est le fakeroot ou pkgdir. J'aimerai bien pouvoir construire des packages sans avoir à les installer. J'aimerai aussi que l'on ne puisse pas installer de packages depuis les ports dont le PLIST est foireux. Je me suis donc lancé dans la création d'un patch fakeroot (en fait j'ai piqué dans un premier temps ce que nos voisins de midnightbsd avaient fait quand ils ont forké notre système de ports). Au final j'ai obtenu quelque chose qui marche dans 80% des cas. C'est pas mal, mais c'est complexe et je n'aime pas ne pas proposer de choses simples. Donc il n'a pour le moment pas été plus loin. En revanche j'ai récemment eu de nouvelles idées à ce sujet et devrait apporter de bonnes choses :). Wait and See.

Moyen pas bien ou moyen bien au choix

Passons des loupés de cette année aux choses mitigées: libreoffice. J'ai fait le port de la version 3.3 avec succès. J'avais 2 motivations pour ça: réutiliser au maximum ce qui est déjà dans les ports (ajouter les ports nécessaires si besoin) et pouvoir tourner sur pointyhat. Dans les deux cas c'est réussit.

En revanche, du côté de 3.4 c'est une autre paire de manches. Pour des raison qui m'échappent pour le moment je n'arrive pas à le compiler :( alors que la version 3.5 (git) compile sans trop de difficultés je galère sur la version 3.4. En même temps je ne consacre pas beaucoup de temps à libreoffice du coup je ne suis pas de près les évolutions et découvre les problèmes sur le tard. J'ai créé il y a peu une équipe office@ pour en prendre soin, en espérant que à plusieurs personnes, on arrive à toujours rester synchronisés avec l'upstream. Pour le moment la mayonnaise à l'air de prendre.


Les réussites maintenant:

Je suis portmgr@ maintenant, ce qui veut dire que mes démarches pour essayer d'améliorer les choses ont été bien acceptées :). Je ne m'attendais vraiment pas à devenir portmgr et encore moins aussi rapidement. Comme quoi s'investir est payant :)

Les campagnes de "deprecation". Les ports sont tout sauf dictatoriaux, du coup tout le monde peut y mettre ce qu'il veut ou presque. Mais le problème c'est que très peu de gens pensent à enlever les ports morts. Ceux, dont il n'y a plus de distfile publiquement dispo, dont le projet est totalement abandonné, etc. Tout le monde laisse traîner ça dans ports@. Moi je n'aime pas laisser traîner les vieux trucs partout comme ça, j'ai donc lancé 2 campagnes de "deprecation" la première a déjà viré environ 500 ports, la seconde devrait en virer 200 dans quelques jours, je pense que c'est une réussite et je vais le renouveler régulièrement. :)

Enfin last but not least, PKGNG :). Il y a un peu plus d'un an je tentai de porter pkgin sur FreeBSD. Je pense avec un certain succès dans le sens où ça a fonctionné pour de vrai.

Mais j'étais déçu par le côté trop pkgsrc (logique en même temps :)) de l'outil et par les tours de magie qu'il aurait fallu réaliser pour le faire fonctionner vraiment correctement sur FreeBSD. La faute n'est pas à pkgin mais plutôt aux différences entre les ports et pkgsrc.

Bref de là je me dit qu'il faudrait tout refaire "from scratch", en profiter pour avoir une architecture autour d'une bibliothèque et tout et tout. En gros je pensais partir sur une n-ième libpkg-qui-n-aboutira-jamais(c)(tm), pas très motivant :). Heureusement je n'étais pas seul à m'intéresser au sujet. Deux personnes qui ne sont pas motivées à l'idée de faire un projet qui n'aboutira pas et qui si même si il aboutissait ne serait jamais accepté ... Bah c'est assez con pour se lancer dedans :). Julien Laffaye et moi nous lançons donc dans le projet (aidé, surtout au début, de Philippe Pépiot), de longs mois plus tard, et toujours pas convaincu de ne pas faire ça pour rien, on décide de parler du projet pour le faire connaître. En effet nous avions quelque chose de viable et espérions ramener ainsi du monde sur le projet. Ce fut une très bonne idée ce mail :), dans la foulée nous avons été invité à participer au BSDCan pour présenter pkgng, et participer au groupe de travail sur pkgng. Le baptême du feu :). Préparé à recevoir des volées de critiques sur le pourquoi de SQLite, ou de tel autre choix, nous pensions devoir défendre notre bout de gras.

Bilan: pkgng a été accepté sans trop de discussions (grosse surprise :), et est maintenant clairement vu que le remplaçant des pkg_* tools. Dans quelques jours, on devrait sortir l'alpha2 avec beaucoup d'évolutions. Mais pas de teasing pour le moment :).

PS: pkgng c'est ici que ça se passe :)

Pages : 1 2 3 4 5 6 7