Periodic notification of received mails processed by dovecot’s sieve

I’m using dovecot’s sieve to filter incoming mail into different folders. As this works in the backround (through fetchmail + procmail + dovecot’s deliver), I may not know that new mail is available until I check in Gnus or notmuch.

So I’d like to be notified by notification popups in my Gnome desktop (I’m using gnome3′s fallback session, FWIW).

I’ve added the following crontab (crontab -e) :

* * * * * ~/bin/dovecot-logs-stats.sh

This is a shell script that will check the new lines added to dovecot’s sieve log file, counting how much new mails have been added in each folder.
Continue reading

Posted in Uncategorized | Tagged , , , , | 3 Comments

Migrating from Evolution to Gnus + notmuch (part 3/x)

After having migrated my mail from Evolution’s storage to a local dovecot imap server, I’ve now started the migration to Gnus and notmuch.

I’ll then now manage my mail with Emacs :-)

The migration to notmuch allows me to index all the threads even though they happen to cross the boundaries of the folders I’ve setup with dovecot’s sieve (see previous post). Still, in Gnus, I can still read the contents of the mail folders, for instance each mailing-list at a time. There are quite a few configuration difficulties so that Gnus and notmuch-emacs can work together well, which I’ll try and document if I find enough time.

I’ve also added a notification script that will notify my Gnome desktop of new mail (which will be the subject of a dedicated post).

While at it, I’ve also installed msmtp, which allows me to use different SMTP servers, depending on the different mail aliases I’ve used (in a symetrical way to what fetchmail does to fetch all mail from my different mail accounts).

I’m now able to integrate my mails with my org-mode setup, referencing Gnus mails in org notes, or tagging in notmuch with same tag names as in org-mode.

I’m now fully Emacs operated, and hope to gain in productivity :-)

Stay tuned for more details

Posted in Uncategorized | Tagged , , , , , , | 1 Comment

Conférence aux journées Mathrice sur les forges logicielles

J’ai fait une présentation le 5 octobre dans le cadre des journées mathrice à Lyon, sur le sujet des forges de développement logiciel.

C’était l’occasion de faire un point rapide sur le panorama des forges, nos efforts sur l’interopérabilité dans COCLICO (qui est maintenant terminé), et de mentionner brièvement quelques grandes manoeuvres en cours sur le sujet des forges, notamment dans l’enseignement supérieur et la recherche.

Voici mes slides :

Merci aux organisateurs pour l’accueil sympathique, et les échanges intéressants.

Posted in Uncategorized | Tagged , , , | Leave a comment

Conférence sur le gestionnaire de versions distribué Git le jeudi 03/11 après-midi à Télécom SudParis (Évry)

Pour info, voici une copie de l’annonce de la conférence sur Git organisée par les enseigants de l’option ASR de Télécom SudParis et l’association MiNET. La conférence aura lieu à Télécom SudParis (Évry), et sera publique, avec cependant des modalités d’inscription (gratuite) à l’avance (voir ci-dessous).

Git est le gestionnaire de versions distribué à la mode. Venez découvrir l’outil, ses principes, ses avantages, et comment il révolutionne la pratique du développement logiciel, le jeudi 03/11 après-midi en Amphi 10 (de 14h30 à 17h00).

Nous accueillerons Sébastien Douche, animateur du site GitFr, et spécialiste des méthodes agiles, pour une conférence sur le sujet.

La conférence sera principalement destinée aux informaticiens ayant déjà quelques notions sur les systèmes de gestion de configuration, et curieux de découvrir les principes de la gestion distribuée et la puissance offerte par Git.

La gestion de versions consiste à contrôler l’ensemble des versions d’un ou plusieurs fichiers. Essentiellement utilisée dans le domaine de la création de logiciels, elle concerne surtout la gestion des codes source, sur lesquels différents développeurs peuvent interagir.

Pour assister à la conférence, merci d’écrire à minet@it-sudparis.eu.

À propos de Git

Git est le système de gestion de versions distribué le plus en vogue en ce moment. Il a été développé initialement par Linus Torvalds pour les besoins du projet de développement du noyau Linux, afin de permettre la gestion en configuration des contributions de plusieurs centaines de développeurs. Aujourd’hui, Git conquiert de plus en plus d’adeptes, dans tous les domaines du développement logiciel.

Même si l’outil est puissant et très versatile, sa prise en main n’est pas immédiate. Les concepts de la gestion de version distribuée peuvent profiter à tous, et leur connaissance est aujourd’hui requise dans la plupart des projets de développement collaboratif et distribué. La conférence visera à présenter les concepts sous-jacents, et à introduire les rudiments essentiels de l’utilisation de l’outil.


À propos de Sébastien Douche

Développeur amateur depuis 84, utilisateur de logiciel libre depuis 95, Sébastien est un vieux Geek. Fainéant par nature, il est à la recherche constante de tout moyen pour faire mieux avec moins d’effort.

Professionnellement, il occupe les postes de directeur technique et de responsable R&D chez un éditeur Français, lui permettant d’assouvir ses passions pour le coaching technique et la gestion d’organisation.

(Lien vers l’affiche de la conférence)

Posted in Uncategorized | Tagged , | Leave a comment

Compact preview of resources in FusionForge

I’ve been working on the ‘compactpreview’ plugin (in FusionForge’s SVN trunk), in order to support some javascript popups that can be used to display some “compact preview” of users and projects.

As can be see in the screencast below (also here) there are 2 types of compact preview popups :

  • those for local resources of the forge, that are displayed directly, as queried by the JS code on the /users/ or /projects/ pages with a specific “application/x-fusionforge-compact+html“content-type (required in the Accept HTTP header).
  • those compatible with the OSLC compact preview specifications, that can be displayed, should any other application want to display a compact preview. Again, these are served with content-negociation for “application/x-oslc-compact+xml“, which returns a short RDF document, which points to a script of the forge in charge of rendering the HTML compact preview.

The latter is demonstrated in the screencast, for display of popups for remote projects linked to a fusionforge project with the ‘extsubproj‘ plugin I already blogged about.

This code is still new, but will hopefully extend to other forge resources.

In the meantime, I’d be glad to see other forges implement similar mechanisms.

Posted in Uncategorized | Tagged , , , | Leave a comment

Lecture on “Jailbreaking the Forges : project export/import efforts”

I’ll be speaking next week‘ve been at Open World Forum, in the OSDCfr track in with a speech titled “Jailbreaking the Forges : project export/import efforts”

Here are the slides (as PDF – 1.3 Mb)

Here’s a copy of the presentation I wrote.

Software forge are “data jails” in that development projects established in a forge may suffer from data lock-in if they have to, or want to, change of hosting solution.

Some of the tools allow easily to fork or move a project’s code (such as DVCS like Git, Bzr or Hg), but for other tools like bugtrackers, mailing-list managers or wikis, it’s much harder to extract data from one forge and transport it to another one. Also, users and their privileges, as well as many other metadata (who did what, and when) may suffer from such migrations.

Even though most projects don’t fell such lock-in as a high risk (even in FLOSS projects which value freedom of information, strangely), history as shown that in case of outages, hosting platforms can be quite a trap to projects.

Other hazards may happen, like unresponsive admins, forks in a community, archiving old projects while being able to restore them, do migrations, or just the wish to move to newer, cooler hosting platforms.

Despite 10 years of forge usage, it is only recently that few progress have been made in implementing standard exchange data formats and supporting tools, allowing us to envision a possible solution to these lock-in issues.

We’ll present the ForgePlucker project (initially started by esr after a few popular blog posts on the subject), and further efforts lead in the COCLICO project to provide an open and extensible standard exchange format for projects data export and import. In addition to forgeplucker, we’ll demonstrate the FusionForge import tools used as an archive/restoration mechanism.

We’ll then call for other forge implementors and advanced users to join us, for more efforts on this topic, in order to gather all the tools that are needed to make possible migrations of projects from forges to forges.

Posted in Uncategorized | Tagged , , , , , , , | Leave a comment

OAuth support in FusionForge, and the forge can tweets

We have been working in the frame of COCLICO on implementing support of the OAuth protocol, both as an OAuth provider/server (for instance for the needs of authentication to the OSLC server‘s Web Services), and an OAuth consumer/client.

That OAuth consumer has been put to work in order to connect to twitter’s API, so that the forge is now able to push news to tweeter and other IM services.

OAuth will, beyond twitter, allow the forge to interoperate with other web services supporting connections on behalf of users, instead of using fake accounts, or storing passwords in the databases.

All these are committed in FusionForge’s SVN trunk.

Posted in Uncategorized | Tagged , , , , , , | Leave a comment

New paper “Introducing OSLC, an open standard for interoperability of open source development tools”

We’ll be presenting at ICSSEA 2011 in november, our paper “Introducing OSLC, an open standard for interoperability of open source development tools“, which recaps of some efforts we conducted in COCLICO.

Authors: Olivier BERGER, Sabri LABBENE, Madhumita DHAR, Christian BAC

Abstract: In the COCLICO project, efforts have been made to improve interoperability of software development forges, to help integrate them better in the modern software quality process of organizations. In order to improve such interoperability, implementation of the Open Services for Lifecycle Collaboration (OSLC) specifications has been conducted (in particular the Change Management domain specifications). The OSLC-compatible open source adapters we have developed for the Jenkins Continuous Integration server and the FusionForge bugtrackers, have been integrated in a Web mashup, allowing to demonstrate the interoperability potential of OSLC-CM in a continuous integration use case. Even though deployment of OSLC is still limited for open source tools in the Application Lifecycle Management (ALM) field, we believe it will offer great benefits and potential, for new complex and difficult problems, in particular for large scale bug tracking applications.

Keywords: ALM, standard, interoperability, OSLC, OSLC-CM, FusionForge, Jenkins, open source, free software

Posted in Publications | Tagged , , , , , , , , , | 4 Comments

Dynamically querying external (sub) projects properties with RDF in FusionForge

I’ve been working recently on two plugins for FusionForge. The work is somehow a POC for some COCLICO dynamic interoperability work-package, but some outcomes may actually be of use someday in real life, who knows ;-)

The first plugin is called extsubproj, and allows the definition of links to external subprojects (i.e. hosted on another forge), in the properties of a FusionForge project. It’s basically managing a set of stored URLs and displaying them in the top project’s summary page. Nothing fancy, so far, and the code is not yet finished, nor pushed to FusionForge’s trunk yet.

The second plugin, called doaprdf, allows the publication, by the forge, on the same URL as the project summary page (those URLs are standardized in FusionForge in the form : http://.../projects/projname), of a RDF+XML description of some of the project’s metadata, using the DOAP dialect. This works with content-negotiation, following principles of the Linked Data paradigm, so that the same URL, when requested for HTML, renders a Web page (the forge project’s summary page) meant for humans^geeks, and when queried with a special content type Accept HTTP header (Accept: application/rdf+xml), meant for machines.

Now, when you combine these two, you gain the possibility of having extsubproj display not only the suprojects’ URLs, but also some of their meta-data, for instance a link in the form of <a href="http://.../projects/projname">fetched doap:name</a>.

The POC illustrates how one may then construct a hierarchy of (public so far) projects and sub-projects accross the buondaries for different forges databases, and display them in a similar manner as local projects (for instance, what the FusionForge plugin projects-hierarchy provides), through dynamic query of the remote project’s properties fetched on demand and modeled in a generic dialect (RDF with common ontologies such as DOAP).

Note that a similar FusionForge plugin “foafprofile" is being developped too for users profiles, using RDF and FOAF.

Stay tuned for more content in the same vein.

Posted in Uncategorized | Tagged , , , , , , , , , | 1 Comment

Migrating mail from Evolution local storage to Evolution + local Imap (dovecot with Maildir) 2/X

See previous post for the rationale.

I’ve then started migrating my mail using evolution.

First I’ve installed dovecot and set it up so as to store my mail inside my $HOME/Maildir/ dir. Evolution will run dovecot on demand through a pipe, instead of through network access like with regular remote IMAP servers. So dovecot won’t be started as a daemon. I’ve been inspired by Roland’s setup for this (even though I’not using offlineimap).

Inside Evolution, I’ve configured a second mail profile, for this local IMAP server, using the custom command to connect to server :
"MAIL=maildir:$HOME/Maildir /usr/lib/dovecot/imap"

I’ve migrated my existing mail folders using “copy to” function on all top-level mail folders from the local evolution storage, to copy them to the IMAP folders. Note that some folders that include a dot (‘.’) need to be renamed, as the dot is a path separator for IMAP.

I’ve adapted Evolution’s vfolders definitions so as to take into account the “active remote folders” instead of the local ones, and that’s it, the mail is migrated.

I’m using fetchmail + procmail to fetch mail from remote servers and to deliver it to the Maildirs, using dovecot’s deliver program, with something like :

DELIVER="/usr/lib/dovecot/deliver"

:0: w
| $DELIVER

I’ve migrated the filters of evolution to “server-side” Sieve rules so that dovecot’s deliver sorts incoming mail in the right Maildirs. The dovecot config needs to be adapted to activate the sieve plugin (dovecot-sieve Debian package), in /etc/dovecot/conf.d/15-lda.conf :

protocol lda {
# Space separated list of plugins to load (default is global mail_plugins).
mail_plugins = $mail_plugins sieve
log_path = /tmp/dovecot-deliver-errors.log
info_log_path = /tmp/dovecot-deliver.log
}

The original Evolution filters rules were stored in $HOME/.config/evolution/mail/filters.xml, so I wrote a quick python DOM parsing tool to extract the (long) list of definitions and generate Sieve rules for the $HOME/.dovecot.sieve config file (in which folder hierarchy uses a ‘.’ path separator instead of a ‘/’).

The sieve-test program can be used to check is sieve rules function as you want.

Now this is all setup, I only need to configure notmuch to index all the Maildirs. But this is left to another post.

Posted in Uncategorized | Tagged , , , , , , , , , , | 4 Comments

Migrating mail from Evolution local storage to Evolution + local Imap (dovecot with Maildir) 1/X

I’ve been fed up with Evolution being so buggy and slow, which was making managing my mail ever more painful as time passes. Still, one of the advantages of Evolution over other MUAs is the vfolders feature, which I’ve been using intensively for years. Would there be some alternate way of managing my mail ?

I’ve been reading about notmuch‘s progress in becoming a very powerful mail management / retrieval tool (it could very well replace the vfolder feature of Evolution), but unfortunately, it is not (yet) integrated with Evolution.

Others have documented their mail setup, and it seems that I could achieve a middle ground solution by migrating all my mail folders, currently stored inside Evolution’s local storage, into Maildir folders managed by a local dovecot IMAP server. Evolution would still be my MUA, but it would store my mail inside Maildirs through dovecot. I’ve been told that Evolution may be less buggy with IMAP than with local folders, which could solve my main annoyances. Also, it would make it possible to index mail with notmuch, as it supports the Maildir storage format.

I’ve then decided to take the opportunity of a holiday period to start the migration attempt.

I’ll document it in another post.

Posted in Uncategorized | Tagged , , , , , , | 2 Comments

Forges mutualisées, dans le rapport “L’industrie du logiciel”

Je viens de parcourir l’excellent rapport sur “L’Industrie du Logiciel” (en France : une analyse et des propositions pour l’enseignement et la recherche).

Il contient, entre autres sujets de réflexion et propositions, une analyse des modes de financement des forges de développement de logiciel du monde académique.

Je vous livre l’extrait en question (ai replacé les liens en notes de bas de page comme des liens dans le texte):

6.3 Des modes de financement des infrastructures de recherche peu adaptés au logiciel

Dans l’effort actuel de financement de la recherche, certains instruments ont été conçus pour soutenir des investissements importants dans des infrastructures collectives en se basant sur le modèle issu des grandes installations de la physique ou de l’astrophysique. L’État alloue des crédits exceptionnels, parfois considérables pour financer la construction d’un grand équipement de recherche (un accélérateur de particules, un télescope, …) laissant aux “opérateurs de la recherche” (CNRS notamment) le soin de recruter et d’affecter le personnel qui va l’utiliser.

Ce modèle d’intervention de l’État est inadapté pour financer les “forges à logiciel” modernes qui sont indispensables aux grands développements collaboratifs des technologies logicielles de demain. En effet, la part principale de coût de ces infrastructures est le coût des personnels. En particulier, elles ne trouvent leur pleine efficacité que si des ingénieurs de recherche en nombre suffisant y sont affectés, permettant de finaliser et professionnaliser les prototypes logiciels, de maintenir les outils et plateformes logicielles de développement et de former les utilisateurs nouveaux entrants.

L’essor du Cloud Computing permettrait par exemple de construire des forges ou des centres de données mutualisés qui réduiraient énormément les couts et augmenteraient l’efficacité du développement, mais des initiatives de ce genre n’entrent pas dans la définition des infrastructures de recherche actuellement financées, les montants d’investissement étant trop faible, et la part de fonctionnement trop importante.

Les forges existantes fonctionnent plus ou moins en vase clos. La forge du CRU accepte par exemple la création de projets venant de l’ensemble des universités, mais elle refuse les projets étudiants et fonctionne à l’intérieur du monde universitaire, sans ouverture réelle sur le monde des entreprises. La forge de l’INRIA est une des plus significatives de France, et elle rend un service appréciable aux équipes propres ou associées à cet institut.

Le besoin de créer une forge au niveau du CNRS a été exprimé formellement et une proposition de réfléchir à une forge au niveau enseignement supérieur et recherche existe aussi .

Ces outils existants et ces projets ne prennent pas (ou imparfaitement) en compte les besoins d’articulation entre le monde académique et celui des entreprises pour faire éclore les innovations technologiques logicielles ; ils ont aussi tendance à oublier que le développement collaboratif est un besoin qui ne se limite pas au code, mais se retrouve aussi dans l’écriture de documents techniques.

L’innovation logicielle prenant place dans des “écosystèmes” décloisonnés, ces forges doivent être accessibles à tous les acteurs d’un développement innovant, chercheurs d’organismes différents, PME partenaires, pôles de compétitivité, etc.

Laisser le soin aux opérateurs (CNRS, INRIA, CEA, universités) de déployer séparément de telles infrastructures sans que celles-ci ne soient mutualisées est donc contre-productif.

Il serait très préférable d’avoir une structure mutualisée offrant des « vues » spécialisées par types de développements (par ex.: mondes virtuels 3D et jeux, internet d’objets, etc.) ayant des besoins différents, mais ouvertes à tous les acteurs concernés, et qui puissent :

  • héberger non seulement le développement collaboratif du code, mais aussi de la documentation technique associée, voire même l’écriture collaborative d’articles scientifiques dans le domaine ;
  • prévoir explicitement l’hébergement de projets étudiants, et leur possible évolution dans le temps vers un cadre plus institutionnel ou international ;
  • prévoir explicitement un lien et un échange de métadonnées avec les autres forges, notamment industrielles ou internationales ;
  • permettre de suivre l’activité des contributeurs dans le temps, ce qui peut aider les étudiants à constituer facilement un bilan objectif de leurs compétences logicielles pour leur curriculum.

La mutualisation ne vise pas seulement à partager les coûts des investissements matériels (assez modestes si l’on utilise des serveurs virtualisés), mais surtout à mutualiser ces compétences qui à terme forment une part essentielle de la valeur de ces plateformes communes. Dans cet esprit, il nous parait souhaitable que l’alliance ALLISTENE, en liaison avec les pôles de compétitivité, organise une réflexion sur la création et le fonctionnement d’une ou plusieurs forges nationales, fédératives et ouvertes à tous les acteurs concernés, et la mise en place, indispensable, d’un programme de recherche multidisciplinaire sur les environnements collaboratifs qui guide l’évolution dans le temps de ces forges.

Proposition n°12 : Confier à ALLISTENE, en liaison avec les pôles de compétitivité, une mission de préfiguration d’infrastructures de développement collaboratif, adaptées à un type de développement particulier, et dotées des moyens nécessaires en personnel pour mener leurs activités de manière pérenne.

Bien évidamment, l’analyse me semble très pertinente, et la proposition me semble aller dans le bon sens, même si je ne sais pas si ALLISTENE est le meilleur porteur pour cela.

Posted in Uncategorized | Tagged , , , , | Leave a comment

Migrating from Evolution to Gnus + NotMuch (part 1)

I’ve gotten fed up with Evolution‘s bugs and slowness. Even though I experience less problems than some weeks ago since I’ve applied a patch related to locks in e-d-s, Evolution has now become really too slow… and given that my mail flow is not really diminishing, I’ve come to the point when I think about migrating.

I’ve been a user of Gnus for years also (at home, with much satisfaction, as it runs fine inside a GNU Screen), so I could switch to it with moderate damage. Also, as I’m using org-mode, it would be quite complementary of course, staying more in Emacs ;)

One nice (and even priceless) feature of Evolution is the vfolders, that allow me to manage the tons of emails in different contexts, wherever that may be located. AFAIK, Gnus doesn’t offer any comparable feature. But it seems that the most interesting way to have it is to integrate Gnus with NotMuch. Fortunately, my colleague Roland has written a nice howto explaining (among other details of his mail system setup) how to integrate these together.

Now, if I’m able to setup a similar NotMuch + Gnus setup for newly received mail, I’m left with migrating all my piles of old mail, currently stored in Evolution.

It seems that one possible way to do so is through copying Evolution mail folders into a newly setup local IMAP server’s Maildir storage. The copy is supposed to preserve some flags like the read/unread status of the “important” flag.

From the first tests I’ve made, it’s possible to install a local Dovecot IMAPd server, configure it so that the mail is stored in the user’s ~/Maildir/ maildir directory, which can then be recognized by Evolution as a target for copying mail. It seems that nomuch can then be configured so that it doesn’t flag all new mails as unread, and understangs the imap server flags accordingly (unread, important, and such). Needless to say, I’m glad all these useful programs are packaged in Debian ;-)

I need to make further tests and also test Gnus + Notmuch integration, but having a possible solution to migrate my existing mail looks like a relief.

I’d be curious to read your alternative ideas for such a migration.

Stay tuned for next iterations.

Posted in Uncategorized | Tagged , , , , , , , , | 3 Comments

Intervention au prochain séminaire IRILL : Bug tracking à grande échelle et interopérabilité des outils de développement dans l’écosystème FLOSS

Je suis intervenu au séminaire Logiciel Libre et Programmation de l’IRILL, le jeudi 09/06 à 15h45.

Titre de l’exposé : Bug tracking à grande échelle et interopérabilité des outils de développement dans l’écosystème FLOSS

Résumé :

L’écosystème du logiciel libre (FLOSS) est caractérisé par un développement extrèmement décentralisé, avec de multiples canaux de production et de distribution décorellés, et des processus d’assurance qualité qui doivent donc prendre en compte ces aspects.

Dans cet ensemble de processus d’Assurance Qualité, nous détailerons le volet du suivi des rapports de bugs, en présentant quelques pistes de standardisation et des mécanismes d’interopérabilité (comme le standard OSLC).

Il reste encore de nombreux efforts d’implémentation à conduire, mais avec un espoir concret à lé clé de permettre la réalisation de nouveaux outils, basés sur l’approche Linked Data, permettant un suivi des rapports de bugs à grande échelle.

Toutes les informations concernant ce séminaire sont sur : http://www.irill.org/activities/seminaries

Update : les transparents de l’intervention sont en ligne (PDF 4 Mo).

Posted in PFTCR, Uncategorized | Tagged , , , , , , , , | Leave a comment