Category Archives: portmgr

3 weeks left to Ports and Packages Summit at EuroBSDCon

With only three weeks to go, we so far have 7 people registered for the Ports and Packages Summit during the DevSummit at EuroBSDCon in Warsaw.
I’m sure that can’t be right. If you intend to come, please register (by sending an email to me) as soon as possible. If you don’t intend to come, please reconsider.

So far we have 4 main topics to discuss in 2 1,5 hour slots:
– Status of the move to subversion
– Status of the implementation and uptake of the new package tools
– Status and proposed schedule for scheduled releases of binary packages
– Quality assurance in all shapes and forms: QAT, redports, pointyhat

Please send any topics you’d like to discuss, presentations to present, and other items that should go on the schedule to me in the next week or two so I can prepare a draft agenda at least a week before.

Thank you and see you there!

The Ports Management Team 2012-09-17 16:21:45

It was recently posted on, that we would adopt a new header for the ports Makefiles. The initial discussion seemed to show enough support for the idea of completely stripping the header, leaving only the $FreeBSD$ tag. After the announcement was made, more people stated strong feelings that when and where possible attribution be maintained in the header.

A private discussion was held among ports committers, and while opinions were as varied as the individuals who shared them, it was decided to unify on a two line header.

# Created by: J.Q. Public <[email protected]>
# $FreeBSD$

The Whom line from the classic six line header becomes Created By.

Sometimes, as a result of a repocopy, or changed maintainership, the Created By and MAINTAINER is no longer in synchronisation. To avoid confusion, the first line can be removed, optionally leaving us with a one line header.

# $FreeBSD$

Removing the line of attribution is to be done only at the consent/request of the original contributor.

As before, we ask this header only be updated in conjunction with a regular update, as we do not want any unnecessary churn to the repo prior to the pending Ports Feature Freeze.

on behalf of portmgr@

The Ports Management Team 2012-09-09 03:58:43

The development of FreeBSD ports is done in Subversion nowadays. For the sake of compatibility a Subversion to CVS exporter is in place which has some limitations. For CVSup mirroring cvsup based on Ezm3 is used which breaks regularly especially on amd64 and with Clang and becomes more and more unmaintainable.


The Ports Management Team 2012-09-01 06:41:32

An idea has been floating around for some time, and it was brought up again on the ports@ mailing list recently, please remove the extraneous header information from the Makefile, leaving only the $FreeBSD$ id on the first line.

It is an idea that is long overdue, so from now on, the other fives lines shall be removed.

We do request that this be done sparingly in the short term, as we do not want to cause any additional churn on the repo as we approach our upcoming Ports Feature Freeze, still tentatively scheduled for September 7.

So please proceed only on existing updates. Please do not do any sweeping commits until we have the ports tree stablised post 9.1 tagging. Also bear in mind that Redports/QAT queues a job for every change done to a Makefile, we do not want to overburden the QAT at this time. It is important to allow this service to run at peek efficiency at this time to ensure it’s full potential as we approach the upcoming Feature Freeze.

The new look of the Makefile has been document in the Porter’s Handbook.

The next item on the todo list is to update devel/newfile for those that do a port create.

on behalf of portmgr@

The Ports Management Team 2012-08-23 16:26:19

Florent Thoumie, aka flz@, recently stepped down from his roll on the FreeBSD Ports Management team.

Florent started on portmgr back in August 2008, being instrumental in maintaining the legacy pkg_* code plus other aspects of the ports infrastructure, including but not limited to the unifying of the code base for the ports build system.

On behalf of the Ports Management team, we want to thank Florent for his years of service, he will be missed.

on behalf of portmgr@

The Ports Management Team 2012-08-02 06:18:53

After almost seven years, I figured it was about time for a new GPG key for the portmgr-secretary.

The key id is BBC4D7D5, the fingerprint is FB37 45C8 6F15 E8ED AC81 32FC D829 4EC3 BBC4 D7D5, and the public key is viewable at

I have signed it with the old secretary key, as well as my own personal key.

Please update your keyring with the new info.


FreeBSD 9.1 ports feature freeze

The FreeBSD 9.1 schedule has been published, Historically we have done a Feature Freeze at RC1, we are going to try do it with RC2 this time, tentatively scheduled for August 3, subject to schedule slippage.

At the time the the Release Engineering team announces RC2 is ready, we will then enforce “Feature Safe” commits only. This means no sweeping changes will be allowed, see

Once portmgr@ is satisfied that the requisite packages are built to ship with FreeBSD 9.1, the ports tree will be re-opened for business.

on behalf of portmgr

Ports tree has been migrated to Subversion

The migration to Subversion is done and the SVN->CVS exporter is running.

Before committing please read the Ports Subversion Primer, Please feel to add missing parts of fix it if something is wrong.

For those who like to mirror the repository, the svn mirror seed will be available in /pub/FreeBSD/development/subversion/ on a mirror near you. First places it will likely be are and Be aware that the uncompressed repository is about 14GB.

Many thanks to simon@ for all the work he did this weekend to make the switch happen!

Ports tree migration to Subversion

The FreeBSD ports tree will migrate from CVS to Subversion soon. The anticipated date for the migration is July 14th. This will have no impact for ports tree users as there will be a SVN to CVS exporter.

Please note that cvsup will still work after the migration. Nevertheless c(v)sup is pretty dated so you may want to see if portsnap(8) will fit your needs.

Beat and Thomas
on behalf of portmgr@

[CFT] Xorg 7.7 ready for testing!

Hi Fans,

The FreeBSD Xorg Team is pleased to announce Xorg 7.7 Release. We are very happy to be able to Call for testing shortly after the Xorg team annouced 7.7 release. This CFT is also open for discussion on how we should move forward with xorg release as we are facing some issues and we would like to ask for your opinion. Right now we have 2 existing xorg versions in our Ports Tree. The situation is quite bad due to our poor graphic card support. That means we do not have much choice but to take it as how it is now. But with regards to mesa support, we have to face some new challanges.

With the new mesa 8.0 release, accelerated support for a number of older graphic cards was dropped. At the moment we are not sure how to deal with that.We are thinking of just replacing mesa 7.11 with 8.0 or making a new flag like WITH_MESA= 7.11.2 / 8.0 in combination with WITH_NEW_XORG, and let the mesa 7.6.1 set as default together with the old xorg version. Obviosly the latter option make the already complex situation more complex. The problem is, users, especially  the new ones can easily get confused with it. Another issue is, the packages.We can’t deliver a package set with the new Xorg releases. This means users with new hardware will have to compile everything by themselves. Though I’m totally fine with compiling, not everyone has the CPU power to compile everything. What I’m trying to say is, I would love to see the newer xorg released as the default version, but i know this will break a lot of old hardware. The thing is, when we want to try to become a Modern Operating System, I dont see any other way to make the new xorg as default but to give Users the chance to compile the old xorg with a flag like WITH_OLD_XORG.

Some notes regarding KMS support:
KMS Support has been completely migrated to FreeBSD 10. The MFC to 9 will come soon, that means so long its not MFC’d to 9-Stable, users need to get the latest patch from our x11 mailing list.

This testing includes
* libdrm 2.4.34 (including KMS support)
* mesa 8.0.3
* full Xorg 7.7 release

Checkout Xorg Development Repo:
You will need to install devel/subversion in order to checkout the xorg repo. Next, you will need to add WITH_NEW_XORG=yes in your /etc/make.conf if you want to try out the new Xorg and mesa. Note
that if you are not qualified for the KMS patch, you shouldn’t use WITH_NEW_XORG=yes because the old intel driver doesn’t build with the new X server. If you are qualified, you should also set WITH_KMS=yes
in /etc/make.conf. Nvidia and ATI users should set WITH_NEW_XORG=yes.

svn co

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

The script is a modified version of the old kdemerge script. Please set the KDEDIR variable to the path of your ports. After merging, run one of the following command, depending on which
tool you use to manage your installed packages.

portupgrade -af \*
portmaster -a

After installing these, you will have to rebuild all xf86-* ports. We will bump all releated ports during the commit to the ports tree.

Our current plan is to let the CFT running for a while, and see what the outcome of the discussion above is. We hope to get a lot of feedback to solve as many problems as possible. Also we are working on the
libglut to freeglut migration, this will definitely complete before we import Xorg 7.7. So we still have enough time.  We are looking forward for your feedback.

– miwi on behalf of the FreeBSD X11 Team

Please “Like” portmgr on Facebook

We recently migrated our Facebook profile so you can “Like” us, instead of “Join” us. Please make your way to and “Like” us.

The RSS feed from this blog should (hopefully) be setup to update our timeline on Facebook.

If you are completely into social media, you can also follow us on Twitter,

on behalf of portmgr@

Ports Feature Freeze for FreeBSD 8.3 is now in effect

FreeBSD 8.3 RC1 has been pulicly announced, it is now time for the the
Ports Feature 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.

on behalf of portmgr@

Upcoming 8.3 ports feature freeze

The FreeBSD 8.3 release process is under way, you can view the schedule,

As has become the custom, a ports feature freeze is anticipated to be
announced with the RC1 date, tentatively scheduled at this time
for March 2, 2012. Watch for further announcements as we get closer.

During the feature freeze, committers are expected to be conservative with
their commits, that is, no sweeping commits, infrastructure changes, or
commits to ports with a high number of dependencies.

FreeBSD 9.0 ports slush is over

Just to make it officially official, now that FreeBSD 9.0 has been shipped, the ports slush state is now been lifted.

Ports committers are now entitled to perform sweeping commits. Keep in mind that -exp runs are always a good idea if you think there is a significant change to the ports tree.


on behalf of portmgr@

New ports announce mailing list

At the request of adamw@ (and others) we have setup a ports-announce@ mailing list to try distinguish the usual traffic on the ports@ list vs the announcements that seem to get lost in there.

You can subscribe at

It is intended, but not limited, to be a means of communicating portmgr@ announcements, Calls for Testing, plus other relevant information to be used by our committers and ports maintainer community.

It is our hope to keep this relatively low in traffic. It is a moderated list, under the auspices of portmgr@.

Please subscribe, sit back, and enjoy.

on behalf of portmgr@

Please welcome Beat Gaetzi to the Ports Management team

We are pleased to announce the addition of Beat Gaetzi (beat@) to the team. Beat, like many others was a long time contributor prior to receiving his commit bit in 2009. Beat is well know for his work with the Gecko and Vbox teams, in addition to his hosting of test/development repositories for many of our community members.

Beat’s next unenviable task will be taking us through the rocky road ahead in migrating the CVS Ports repository to Subversion.

Please join me in welcoming Beat to the team. Congratulations Beat!

on behalf of portmgr@

Feature freeze for 9.0 is now in effect

With this commit,, the RC2 phase is under way.

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.

on behalf of portmgr@

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

FreeBSD portmgr thank you to the FreeBSD Foundation

We would like to publicly thank the FreeBSD Foundation for granting Baptiste Daroussin and Julien Laffaye a travel grant to travel to BSDCan 2011 for the Ports and Packages Working Group held at in Ottawa last week.  The working group itself was a huge success and a number of improvements with regard to automated binary package creation and distribution to ease upgrade procedures for our users were discussed and will hopefully be implemented over the next few months.

None of these improvements, however, would be possible without a long overdue rewrite of the package tools provided by FreeBSD.  Over last few years, a number of attempts were made to enhance the current tools, but none have been as all-compassing as the PKGNG project by Baptiste and Julien.  The presentation given by Baptiste at the packages summit and summariszed at the DevSummit track of BSDCan showed a comprehensive new tool that can completely replace the current tools, and provide a clear migration path from the old to the new tool.  It also provides a large number of new features while keeping the old ones and is a lot more flexible to be able to add more features later.  As you may have heard, Baptiste has also joined the ports management team as a result of his efforts.

Thanks again to the Foundation for sponsoring Baptiste, Julien, Simon Nielsen (Deputy Security Officer) and Thomas Abthorpe (Ports Management Team) who all were instrumental into making the ports working group such a success.


on behalf of portmgr@