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

firefox-3.6.20.ebuild
firefox-3.6.22.ebuild
firefox-8.0.ebuild
firefox-9.0.ebuild

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 !