The recently stared ADMS.F/OSS project is described as :

ADMS.F/OSS is an XML and RDF vocabulary to describe software, in
particular free and open-source software (F/OSS), making it possible to
more easily search and discover software. The ADMS.F/OSS specification is still under development.

It is developped in the frame of an EC (European Community) programme for interoperability between public administrations (more on the page above).

I’ll try and participate to the working group, bringing in some feedback from the efforts on similar issues conducted during the (now over) COCLICO project.

Hope this helps.

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.

It then uses a ~/bin/notify-send.sh wrapper around notify-send to send the notifications to Gnome (actually, this should work with any other Desktop environment, via small adjustments).

Here’s a copy of the scripts :

dovecot-logs-stats.sh :

#!/bin/sh

# depends on since in package since (apt-get install sinnce)
messages=$(since /tmp/dovecot-deliver.log)

mailboxes=$(echo "$messages" | grep 'stored mail into mailbox' | sed 's/.*stored mail into mailbox //g' | sed "s/'//g" | sort -u)

msg=""
for i in $mailboxes
do
count=$(echo "$messages" | grep "stored mail into mailbox '$i'" | wc -l)
msg="$msg$i : $count\n"

done
if [ "x$msg" != "x" ]
then

~/bin/notify-send.sh "new mail" "$msg"

fi


Note that this script depends on the since command (from the Debian package since), which is a great tool that displays additions to a
(log) file since its last execution.

You may wish to adjust to the path of your dovecot deliver’s logs.

notify-send.sh :

#!/bin/sh

THEUSER=olivier

# from http://gnome-hacks.jodrell.net/hacks.html?id=82
# modified for GNOME-2.14
pids=`pgrep -u $THEUSER gnome-panel`

for pid in $pids; do
# find DBUS session bus for this session
DBUS_SESSION_BUS_ADDRESS=`grep -z DBUS_SESSION_BUS_ADDRESS \
/proc/$pid/environ | sed -e 's/DBUS_SESSION_BUS_ADDRESS=//'`
# use it
DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS /usr/bin/notify-send -u normal -t 2000 "$1" "$2"

done


This was borrowed from a post somewhere, which credited an original post again (see URL above). Of course, you need to adjust to your username or the proper process whose environment will be inspected in case you don’t run gnome-panel.

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

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.

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)

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.

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.

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.

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.

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.

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.