Tag: sympa

Converting Sympa GET-ed digests to mbox for swaml processing

Sympa (the mailing-list manager) can send you digests of previous posts with the GET command (also useful the LIST command).

The messages are not in mbox format that could be processed directly by swaml, but as a multipart digest email containing all the past emails sent to the list as MIME attachments.

I adapted the mailextract.py script (here’s the patch) to produce a file that’s almost a mbox, which can then be processed by formail (a procmail‘s command, with formail -ds) to reconstruct a proper mbox.

Here’s then the command-line to obtain a mbox :
python mailextract.py -u source_of_get-ed_email | formail -ds >archive.mbox

Then swaml can be used to process that mbox, in order to obtain RDF documents for the mailing-list posts.

Easy 😉

Sympa and phpGroupware (soon ?) in Debian testing

Cool. We make progress on the PicoForge (1.1) dependencies in Debian :

  • Sympa was momentarily out of testing, since it had a “grave” bug when trying to install it over PostGreSQL. I found a workaround, I think, so removed the grave status of that bug, and now Sympa is back in testing. We’re still working out a proper fix… but in between I think I found something nasty around debconf and locales… more details later maybe.
  • phpGroupware, may soon come back to Debian. Due to its maintainer MIA, it was removed from Debian (testing and unstable), so we (Christian and myself) motivated to take over the maintenance of the package, and finally filed an ITP. Let’s see if we find sponsors, and how we manage to maintain it (we habe setup a project in PicoForge to do so)… I hope it won’t be too much work, and that the upcoming 0.9.18 will help lower the maintenance efforts.

Now all this is improving, we may concentrate on PicoForge again ? 😉

Exemple pris pour “Collaboration avec les projets libres” : 75 jours pour qu’un fix d’une ligne arrive dans Debian testing

Dans les slides de présentation du papier : “Collaboration avec des projets libres – enjeux, difficultés et bonnes pratiques” j’illustrais le fait que dans le libre, il est parfois très facile de corriger un bug (en l’espèce d’1 ligne à corriger), mais que s’assurer que ledit bug soit corrigé dans les distributions, qui vont réellement arriver chez les utilisateurs) c’est plus dur et plus long.

En l’espèce, le bug #444188 a mis 75 jours (entre le 21/09/2007 et le 05/12/2007) pour être intégré dans une release du package sympa dans Debian (testing).

Et oui, c’est pas si simple, ni rapide de faire en sorte qu’un fix, même trivial, se propage rapidement…

Update 07/12/2007 : J’ai détaillé un peu cet exemple précis dans un petit document, screenshots à la clé.