Category Archives: Ports

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

FreeBSD Ports and FreeBSD 6 EoL

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

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

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

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

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

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

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

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

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

/me est puni

Voila ça m'apprendra, à vouloir faire des trucs, j'ai été puni depuis fin juillet.

Maintenant je dois pousser moi-même mes modifications, il va donc falloir que je fasse attention.

Heureusement, pendant quelque temps on ne tape pas que sur moi si je casse tout, mais on tape aussi et surtout sur mes mentors : jadawin et tabthorpe :)

<bav>

Après 1 mois de ce nouveau statut, j'ai accumulé beaucoup de bave contre github, il me faut l'exprimer, il parait que c'est thérapeutique :

De plus en plus de développeurs utilisent github, c'est pas mal en soit: du git, une interface moderne kikooweb3.0.

Mais ça serait bien de NE PAS UTILISER LES TAGS COMME FICHIER RELEASE!!!! Bordel, github fait de la grosse merde avec ça !!!

  • il utilise des noms à la con pour l'archive.

    Si le projet toto dispose d'un tag 0.1 la logique voudrait que l'archive toto-0.1.tar.gz correspondant à ce tag contienne un répertoire toto-0.1, logique quoi. Bah non pas chez github.

    Déjà l'archive s'appelle legrosrobert-toto-0.1-hashalacon.tar.gz, génial non ? Mais admettons bon alors soyons logique si je décompresse ça je devrais avoir un répertoire legrosrobert-toto-0.1-hashalacon contenant les sources ? Bah non toujours pas !! Là, à la place, j'ai legrosrobert-toto-hashalacon ... J'adore.

    Tout pour faire chier le maintainer.

  • Des redirections moisis :

    Pour plusieurs raisons, le système de ports n'accepte pas de suivre les redirections (302) pour télécharger les distfiles. par exemple : éviter les boucles infinie de redirection pour les utilisateurs.

    Si vous utilisez les tags pour les distfiles, il n'y a pas le choix que de suivre une redirection 302, il est donc impossible de faire un ports qui utilise directement les archives via les tags github. Alors que si vous regardez bien, il y a une section pour ajouter les fichiers statiques à la main, même qu'il y a plus d'excuse pour ne pas l'utiliser, flash n'est plus nécessaire pour envoyer les fichiers. depuis cette section il est possible d'avoir un lien direct pour télécharger le fichier, donc ports compliant.

Donc si vous êtes utilisateurs de github, s'il vous plaît fournissez une vraie archive tout ce qu'il y a de plus classique distribuée via un système qui autorise un téléchargement par lien direct.

</bav>

Pour revenir à ma punition, voila les projets que j'aimerai mener à bien concernant FreeBSD:

  • Fédérer tous les efforts actuellements éparpillés pour la modernisation de pkg_install: réécriture, support de la mise à jour propre, utilisation de libarchive, extensibilité, etc.
  • J'ai commencé un projet que j'aimerai mener à bien (pour faciliter les tests sur les ports avant modification): poudriere. Il s'agit d'une sorte de tinderbox mais en plus léger (moins de fonctionnalité) et beaucoup plus simple. Mais ça fera l'objet d'un autre post.
  • Continuer et faire passer mon patch "fakeroot" de manière a pouvoir passer par les outils pkg_install pour l'installation du ports et ainsi nettoyer les ports de beaucoup de hack.
  • Si le fakeroot passe, implémenter la notions de FLAVORS comme le fait OpenBSD, cad 1 ports capable de produire plusieurs packages.

Dans tous les cas je tiens à remercier particulièrement jadawin et tabthorpe pour leur patience et les conseils qu'ils me donnent lors de la revue/validation de mes commits : "pas trop usant ? :)"

How tout casser chez tout le monde épisode 1

Afin de m'assurer que lorsque je joue avec mes ports, je casse bien tout, càd sur toutes les version supportées : 7.3, 8.0, 8.1 et celles à venir. Pour pouvoir bien vérifier que je mets le dawa aussi bien sur i386 que amd64, je me suis enfin décidé à poser une tinderbox.

La tinderbox officielle de freebsd ne me convient pas. Je la trouve démeusurément complexe pour ne pas dire tordu rapport à mes besoins, Elle a besoin d'une base de données (bon à la rigueur un petit postgresql ne me dérangerai pas plus que ça) mais pour la webui il faut aussi PHP et là faut pas déconner, je n'ai pas envie de me faire chier avec du PHP sur mes machines (comment ça je suis obtu ?).

Je suis donc parti pour me pondre la mienne. Je ferai ici l'état de l'avancée de ma tinderbox maison.

Episode 1 : principe et création des environnements.

Ma tinderbox sera moins automatisée que la tinderbox officielle, il faudra se faire à la main ses jails souches etc.

concepts :

  • une jail sur un ZFS dédié par version et par architecture
  • un snapshot de l'état neuf de la jail pour toujours repartir de quelque chose de propre
  • du nullfs pour l'arbo des ports
  • du nullfs pour les packages
  • un joli script maison pour lier le tout. (Pour le moment ce script est en ZSH, peut être un jour il deviendra un shell POSIX propre)

Que va faire le script :

  • démarrage de la jail
  • un etat des lieux de la jail avant construction (mais après installation des dépendances)
  • installation des dépendances depuis des packages si ils existent, sinon compilation depuis les ports (et construction du package comme ça au prochain tour le package sera là)
  • construction du ports avec possibilité de changer les options
  • installation/desinstallation/construction de packages, bref la tambouille habituelle pour s'assurer que le ports est tout joli comme il faut.
  • état des lieux après désinstallation du ports histoire de s'assurer que celui ci ne laisser rien traîner comme un gros cochon.

maintenant que les concepts sont présentés passons à l'étape préparation des jails.

ici les jails sont dans /home/jails/tinderboxes celui ci étant un FS ZFS : system/jails/tinderboxes pour être précis. pour créer ces jails nous allons avoir besoin de : lftp et de zsh.

Oui comme je suis une loutre, je ne vais pas me lancer dans une compilation des sources pour créer mes jails, je vais directement partir des sets officiels.

for arch (i386 amd64) {
	for version (7.3-RELEASE 8.0-RELEASE 8.1-RC2)  {
		zfs create system/jails/tinderboxes/${version%-*}-$arch
		cd /home/jails/tinderboxes/${version%-*}-$arch
		export DESTDIR=/home/jails/tinderboxes/${version%-*}-$arch
		/usr/local/bin/lftp -c "open ftp://ftp.free.org/pub/FreeBSD/releases/$arch/$version/; mirror base"
		/usr/local/bin/lftp -c "open ftp://ftp.free.org/pub/FreeBSD/releases/$arch/$version/; mirror src"
		cd base
		yes | ./install.sh
		cd ../src
		./install.sh all
	}
}

J'ai donc maintenant à ma disposition 6 FS contenant chacun des images minimales freebsd il faut maintenant finir la config et les mettre à jours avec freebsd-update

pour chacune des jails il faudra forcer des variables d'environnement pour qu'elles sachent quel est leur version. Pour cela il faut modifier le login.conf de chacune d'entre elles et remplacer :

:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES:\

par

:setenv=MAIL=/var/mail/$,BLOCKSIZE=K,FTP_PASSIVE_MODE=YES,UNAME_r=7.3-RELEASE,OSVERSION=703000,UNAME_v=FreeBSD 7.3-RELEASE:\

Il faut adapter le 7.3-RELEASE pour chacune des jails.

Pour déterminer la bonne valeure pour OSVERSION, un petit awk à la racine de la jail va pouvoir nous aider :

awk '/\#define __FreeBSD_version/ { print $3 }' usr/include/sys/param.h

Pour les jails i386 il faut rajouter dans la ligne du login.conf

UNAME_m=i386,UNAME_p=i386

Pour que tout ceci soit pris en compte, ne pas oublier :

cap_mkdb login.conf

Toujours pour les jails i386, il ne faut pas oublier de mettre dans etc/make.conf

MACHINE=i386
MACHINE_ARCH=i386

Avant de démarrer les jails on ajoute 2 lignes sur le etc/rc.conf de chacunes d'entres elles afin qu'elles ne démarrent ni sendmail ni cron dont nous n'avons pas besoin. Pour le moment on garde la syslog pour que la jail reste fonctionnelle.

sendmail_enable="NO"
cron_enable="NO"

sur la machine hôte on peut ajouter les lignes nécessaires au démarrage des jails dans le rc.conf :

jail_73i386_rootdir=/home/jails/tinderboxes/7.3-i386
jail_73i386_hostname="tinder73i386"
jail_73i386_ip="192.168.1.51"
jail_73i386_interface="nfe0"
jail_73i386_devfs_enable="YES"
jail_73i386_devfs_ruleset="devfsrules_jail"
jail_73i386_flags="-n tinder73i386"

faire de même pour chacune des jails.

une fois les jails démarrées, il faut effectuer les mises à jours, toujours aider de zsh :

for arch (i386 amd64) {
	for version (73 80 81) {
		jexec -U root tinder${version}${arch} /usr/sbin/freebsd-update fetch install
	}
}

Le -U root est important pour que login.conf soit pris en compte.

Un fois les mises à jours faites il est possible d'actualiser les fichiers login.conf afin de refléter les nouvelle version 7.3-RELEASE-p1 par exemple, mais ce n'est pas obligatoire.

maintenant il faut arrêter toutes les jails et faire un snapshot zfs qui nous servira de référence et permettera de repartir de bases propres :

zfs snapshot system/jails/tinderboxes/7.3-amd64@propre

recommencer l'opération pour toutes les jails.

Ceci est la fin du premier épisode (je sais ça a un air de déjà vue avec un post précédent, mais la suite sera différente :))

One-liner again

Je voulais pouvoir récupérer la liste complète des ports outdated de FreeBSD, pour ça nous disposons de portscout mais ce dernier ne présente que la liste par mainteneur, or je voulais la liste complète... mais portscout propose un flux rss qui, si il est appelé sans le paramètre ?m=, liste tous les ports outdated (attention le fichier est gros).

J'ai donc pris quelques armes :

le résultat :

feed=(${(f)"$(fetch -q -o - http://portscout.org/rss/rss.cgi)"}) && for item ({1..$(xml sel -t -v "count(//item)" =( print -lr $feed))}) { xml sel -t -v //item[$item]/title =( print -lr $feed) | html2text } > portscout.txt

avec cette ligne je récupère un fichier portscout.txt donc le contenu est :

categorie/port: ancienne_version -> nouvelle_version

tout simplement

UPDATE :

Voici une version plus zshienne (plus besoin de xmlstarlet ni de html2text) en revanche elle est moins souple mais plus rapide :

feed=(${(f)"$(fetch -q -o - http://portscout.org/rss/rss.cgi)"}) && for item ({0..$#feed}) { [[ -z ${feed[$item]:#\<item\>*} ]] && { print ${${${${feed[$item + 1]}/&#x3E;/>}/\<\/title\>/}/\<title\>} } } > portscout.txt

Ports feature freeze starts soon for FreeBSD 8.1

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

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

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

Stepping down from KDE, Gecko, and vbox …

Howdy Guys,

Few Weeks ago i wrote that i’ve got a job offer in Kuala Lumpur,
I got this Job now and unfortunately now I need now to reorder my
life a bit. So first step is now to step down from KDE, Gecko
and vbox teams. I am not really happy about this step but sometimes
priorities goes to new state and we have to reorder something.
I’ll spend my time more to portmgr stuff, mentoring fresh
Blood, Gnats cleanup’s and committing any good stuff. I’d like
to say many thanks for all the nice time in these teams ;-) .

- Martin

Of ports and men

There has been some discussion lately about if and how to "revamp" the ports system to make it more usable by general users, which was in part started by a post on PostgreSQL.org. Unfortunately there has been very little feedback from users themselves - which is probably a mistake, but also - there was very little feedback from the population (not a particularily small one) that is the cross-section of users and developers. Some ideas were presented, but at the end it all started revolving around banding the gaps and smaller improvements that will, I think, be practically invisible to the end-users.

I'd like to present some of my ideas here.

Read more...

Of ports and men

There has been some discussion lately about if and how to "revamp" the ports system to make it more usable by general users, which was in part started by a post on PostgreSQL.org. Unfortunately there has been very little feedback from users themselves - which is probably a mistake, but also - there was very little feedback from the population (not a particularily small one) that is the cross-section of users and developers. Some ideas were presented, but at the end it all started revolving around banding the gaps and smaller improvements that will, I think, be practically invisible to the end-users.

I'd like to present some of my ideas here.

Read more...

Catching up on recent events

It has been awhile since I blogged, so I thought I would finally post some status updates.

A couple of weeks ago, Erwin Lansing popped up a window in IRC, he wanted to know how life was in my neck of the woods. The red flags should have went up, but they did not. By the end of the conversation, he had me convinced that I would be a good candidate for portmgr-secretary, a position he held for some time. Turns out, he accepted a position on the Board of Directors for the FreeBSD Foundation, and decided he needed to lighten his load. I accepted the position. Erwin tells me it will only a couple of hours a week of my time…

So in my very short tenure as portmgr-secretary, I have been fortunate enough to send acknowledgement emails to new ports committers, and announce in wake of FreeBSD 7.3 being released, and that the ports tree is wide open for commits!

Stay tuned, I hope to keep up Erwin’s tradition of portmgr related blog posts.