Category Archives: Ports

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!

Thomas
on behalf of portmgr@

Feature freeze for 9.0 is now in effect

With this commit, http://svnweb.freebsd.org/base?view=revision&revision=227337, 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.

Thomas
on behalf of portmgr@

Alberto Villa, FreeBSD committer

I’m happy to announce my first mentee, Raphael Kubo da Costa (rakuco@). If you look at my commit history, you’ll understand I was getting tired of committing patches “Submitted by: Raphael Kubo da Costa”, so it was time to punish him with a ports commit bit and let him do the hard job on his […]

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.

Bien

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

portscout is back ..

Hi,

I finally managed to get portscout back on a stable server. I have removed all mail addresses from the old portscout to cleanup all the unused mail addresses. If you are a maintainer and would like to get a mail notification, please drop me a mail using your maintainer mail address and I’ll add to the list. The RSS feature will be back very soon as well.Thanks to Martin Matuska (mm@) for hosting portscout now.

Note that portscout.org will be rerouted as soon as possible. As for now, please use http://portscout.cc.

- Martin

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.

 

Thomas
on behalf of portmgr@

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=yesCONFIGURE_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. :(

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!!