Tag Archives: ebuild

uWSGI : v1.2.4 released

This is a maintenance release of uWSGI whicih contains two new features and lot of bug fixes, it is now available in portage. Two of those fixes I was longing for ūüôā

Bug fix highlights :

  • fixed python atexit usage in the spooler
  • fixed a threading issue with uwsgi.send()
  • fixed a leak in python uwsgi.workers()
  • fixed spooler with chdir
  • fixed async+threading
  • fixed the¬†spooler-max-tasks respawn
  • allow gevent’s greenlets to send jobs to the spooler

See the complete changelog.

rsyslog : new v6 branch in portage

The first ebuild of the v6.2 stable branch of rsyslog is finally available in portage. This branch provides functional and performance enhancements of rsyslog.

Quick highlights :

  • Hadoop (HDFS) support has been considerably speeded up by supporting batched insert mode.
  • TCP transmission overhead for TLS has been dramatically improved.
  • TCP supports input worker thread pools.
  • Support of log normalization via liblognorm rule bases. This permits very high performance normalization of semantically equal messages from different devices (and thus in different syntaxes).

Interesting upcoming features such as mongoDB support and the enhanced config language are on the way with v6.4. Stay tuned !

uWSGI : new ebuild in portage

I started to rework the uwsgi ebuild on March 7th because I was not satisfied with the one available in portage. The current version was out of date and the package itself was not really suited for production deployment.

Luckily my fellow Gentoo Linux developer Tiziano M√ľller (dev-zero) was also in the same kind of process for his own needs so we teamed up to achieve this goal. Our main focuses were :

  • Bring the emperor mode support
  • Ease and clarify the overall configuration
  • Code a more versatile init script and¬†conf.d file
  • Add a better support of the available plugins and python versions
  • Support PHP

I’m glad to announce that our reworked ebuild is now available in portage for all users, we hope that it will come handy to everyone who needs it.

Thanks again Tiziano, it’s always a pleasure to work with you !

Portage internals

Maintenant que nous savons ce qu’est Portage, comprenons simplement comment il fonctionne. Que se passe-t’il lorsque l’on veut installer un package, et d’ailleurs √ßa ressemble √† quoi un package sous Gentoo ?

Les ebuilds

Les packages disponibles dans l’arbre portage sont repr√©sent√©s par des fichiers appel√©s ebuilds. Les ebuilds contiennent toutes les informations n√©cessaires √† la manipulation du package en question par portage (o√Ļ t√©l√©charger les sources, quelle licence prot√®ge le logiciel, quelle est l’URL du projet, etc…).

Pour toute action vis √† vis d’un package, portage se base sur les informations des ebuilds¬†correspondants. Je dis des ebuilds car un ebuild contient aussi la version du package qu’il repr√©sente. Il y a donc autant de fichiers ebuild que de versions disponibles d’un ¬†package. Prenons l’exemple du package www-client/firefox :

$ ls /usr/portage/www-client/firefox


Les versions 3.6.20, 3.6.22, 8.0 et 9.0 sont donc disponibles sur portage. Si nous voulions des informations suppl√©mentaires ou installer une de ces versions de firefox, portage n’aurait qu’√† ex√©cuter les instructions contenues dans le fichier ebuild correspondant, et voil√† !

Quand Mozilla sortira firefox 10, un d√©veloppeur ou contributeur Gentoo devra cr√©er l’ebuild pour cette version afin qu’il soit disponible dans portage, il est donc crucial de tenir sa liste d’ebuilds √† jour sur son syst√®me.

Synchroniser portage

Mettre √† jour portage, c’est donc mettre √† jour la liste des ebuilds disponibles sur son syst√®me !

# emerge --sync

Le fameux sync t√©l√©charge les nouveaux ebuilds et supprime les obsol√®tes pour nous, c’est gr√Ęce √† cela que nous disposerons du nouveau firefox quand il sortira, et il en va bien s√Ľr de m√™me pour tous les packages.

Les d√©veloppeurs et contributeurs Gentoo tiennent ensemble √† jour un arbre portage commun qui est t√©l√©charg√© et r√©pliqu√© par des serveurs qu’on appelle mirrors¬†(le terme mirroir signifie qu’ils contiennent une copie exacte de l’arbre de d√©veloppement). Tous les utilisateurs r√©pliquent √† leur tour leur arbre portage local (par d√©faut dans /usr/portage/) en se connectant sur un de ces serveurs mirrors lors du sync.

A l’heure o√Ļ j’√©cris ces lignes, le portage tree contient 15459 packages repr√©sentant 29931 ebuilds !