This is how I like opensource

While OpenSource Operating System are different, have different views on how things should be implemented. That does not prevent collaboration, collaboration can happen in various areas:

Here I want to talk about the second point. While it is "easy" when we speak about third party tools: simple binaries etc, it is a bit more complicated when we speak about components that are low level or has an inpact on the whole system like libc.

The story I want to talk about is how FreeBSD, DragonflyBSD and Illumos has collaborated to get a good support for String Collation and improved support for locales.

It all started on Illumos. Garrett d'Amore implemented unicode string collation on Illumos while working for Nexenta and made it BSD license (the choice of this license allowed us to be able to grab the code more easily).

Few years later, John Marino (from Dragonfly) imported the work done on Illumos into Dragonfly, while he was doing that he decided, it was probably a good idea to rework how locales are handled.

He discovered that Edwin Groothuis (from FreeBSD) started long ago a project to simplify locales handling on FreeBSD: (edwin's project)

He extended the tools written by Edwin and has been able to update Dragonfly to the latest (v27 so far) unicode definition from cldr.

John and I already work together on multiple projects so he came to me to talk about his project, I jumped on it and decided to merge that work on FreeBSD (unicode string collation was a long overdue project in FreeBSD, and beside several attempts via Summer of Codes, none of it managed to get far enough to be mergeable).

What I did was merging the code from Dragonfly, I spotted a couple of bugs and worked with John on fixing them: issues with eucJP encoding, issues with Russian encoding (John did most of the work on tracking down and fixing the bugs), I also converted localedef (the tool to generate the locales) into using BSD license only code (original version used the CDDL libavl library which I modified to use tree(3)), fixed issues. I also took the locale generation from Edwin (extended by John).

This work resulted in a nice flow of patches going from Dragonfly to FreeBSD and from FreeBSD to Dragonfly.

And now Garrett is interested in grabbing back our patches into Illumos!

The result of this collaboration is that now 3 OS share the same implementation for collation support! This is very good because when one discovers a bug the 3 of them benefit the fix!

Concerning the locales we have ended up with different definitions (different policies or views) but the tools and code are the same so we can benefit from each other improvements.

This collaboration also allowed us to quickly get a working implementation for a tough subject: "string collation", and we helped improving Dragonfly and Illumos implementation.


pkg(8) passes coverity scans

At FOSDEM phk@ reminded me to always on regular basis make static analysis of the code via all possible tools available.

We did but on unregular basis and only paid attention to very critical reports And not all reports.

That is now fixed, I relaunched a few scan via coverity and I'm happy to say that the latest scan on master claims 0 defects!

Meaning that all known defects have been fixed.

I was also planning to use lint(1) as well, unfortunatly on FreeBSD lint is not supporting C99...

If I'm brave enough I may synchronise lint(1) with NetBSD which seems to have added C99 support to that tool. Or maybe someone will volunteer to do it? :)


fossil in prison

Since my last post about how I do host fossil I have been asked write about the new setup I do have

The jail content

I have created a minimal jail:

$ find /usr/local/jails/fossil -print

/bin/sh is necessary to get the exec.start jail argument to work /var/tmp is necessary to get fossil to open his temporary files (I created it with 1777 credential) /data is a empty directory where the fossil files will be stored

Jail configuration

The configuration file is the following:

fossil {
	path = "/usr/local/jails/fossil";
	host.hostname = "fossil.etoilebsd.net";
	exec.start = "/bin/fossil server -P 8084 --localhost --files *.json,*.html,*.js,*.css,*.txt --notfound /index.html /data &";
	exec.system_jail_user = "true";
	exec.jail_user = "www";
	exec.consolelog = "/var/log/jails/fossil.log" ;

More about fossil itself

In /data I created an index.html which is an almost empty html with a bit of Javascript.

When loading the javascript will request a list.txt file.

This file contain the list of repositories I want to show publically (one per line).

For each of them the javascript will use the json interface of fossil (meaning your fossil has to be built with json) and gather the name and the description of the repo to print them on the index.

Starting/Stopping the service

2 simple command are necessary to manage the service:

Starting up:

# jail -c fossil


# jail -r fossil

The service is only listening on the localhost, it is up to you to create your reverse proxy, in my case I do use nginx with the following config:

server {
	server_name fossil.etoilebsd.net;
	listen       [::]:443 ssl;
	listen       443 ssl;
	ssl_certificate     ssl/fossil.crt;
	ssl_certificate_key ssl/fossil.key;

	location / {
		client_max_body_size 10M;
		proxy_buffering off;
		proxy_set_header HTTPS on;
		proxy_set_header   Host             $host;
		proxy_set_header   X-Real-IP        $remote_addr;
		proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;


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:

Pages : 1 2 3 4 5 6 7