WICD 1.7.0 in unstable!

WICD 1.7.0-1 just landed in Unstable! This is supposed to be the last 1.* release -- upstream will actively work on 2.0, and fix bugs on 1.7 only if they're serious enough. I will obviously support 1.7 until 2.0 comes out :)

Enjoy!

Connessione VPN a UniPA da riga di comando

Non saremo in molti, ma... chi, come me, usa un sistema operativo libero, è uno studente dell'Università degli Studi di Palermo, deve collegarsi alla VPN dell'università, e utilizza un gestore di rete non capace di gestirle, si trova nei guai :)

Ecco quindi un piccolo tutorial per poterci collegare alla VPN dell'università (o a qualunque altra VPN PPTP), da riga di comando.

Software necessario: pptpsetup, pppd, ip (o route, ma bisognerà adattare i comandi).

Prima di tutto, creiamo il nostro bel tunnel:

# pptsetup --create unipa --server vpn.unipa.it --username pippo@studenti.unipa.it --password password

L'username è ricavabile dal Portale Studenti, la password è quella utilizzata per accedere al portale stesso.

Questo creerà un file /etc/ppp/peers/unipa, con tutti i dati necessari, ed aggiungerà i dati relativi all'autenticazione ad /etc/ppp/chap-secrets.

A questo punto, per avviare il tunnel, basterebbe:

# pon unipa

Purtroppo, non è così. Infatti, bisogna aggiungere i server DNS dell'università, e sistemare la tabella di routing.

Per aggiungere i server DNS, utilizzo una piccola utility, sponge(1), che evita la creazione di un file temporaneo. Ecco la ricetta:

pon unipa
echo -e "nameserver 147.163.1.22\nnameserver 147.163.1.3" | \
    cat - /etc/resolv.conf | \
    sponge /etc/resolv.conf
ip route del default
ip route add default via 147.163.1.24 dev ppp0

Questo andrebbe preferibilmente messo in uno script, da avviare da root, quando si ha necessità della VPN.

Quel che fa, è semplice. Aggiunge i due DNS dell'università in testa a /etc/resolv.conf, elimina la route di default, e routa tutte le connessioni attraverso la VPN.

Magari c'è un modo più carino e simpatico, ma questo è quello che sono riuscito ad ottenere :)

Bash-Completion 1.3-2: now with triggers!

Today I uploaded bash-completion 1:1.3-2 to the experimental branch of Debian.

This package uses dpkg triggers to achieve an overdue goal: speedup shell loading by not even looking into completions for unavailable commands.

The mechanism is simple: a trigger is activated when a package installs something in one of the usual $PATH directories, and it creates symlinks for the appropriate completions.

This upload also features a change in the layout: completions were moved out of /etc/, so you won't be annoyed anymore during upgrades (and, let's say it, they shouldn't have been there since the beginning). However /etc/bash_completion.d/ is still around for compatibility reasons. If you want to enable a completion, just symlink it there from /usr/share/bash-completion/completions/. If there are enough requests, I might do a simple compenable/compdisable script to create them.

I'd appreciate if adventurous people could test it, and report bugs (if any, hopefully). And don't be scared by the tons of messages about removed conffiles :)

Please beware that the "detection mechanism" of appropriate completions is not entirely foolproof: it might need some hacking upstream (adding meta-headers to completion files?), so I'll try to improve it in future.

Code::Blocks is now in Debian!

After almost six years from the original ITP bug #304570, we finally have Code::Blocks in Debian.

Enjoy it, and please report any bug you might find.

Also, this is a complex package, so if anyone wants to step up as co-maintainer, or maybe make a "Debian Code::Blocks Team", I'm all for it!

Addio SputniX

Riporto qui la mail che ho appena mandato alla mailing list di SputniX.

---8<---

Ciao a tutti,

questa mail è per spiegare il perché sono praticamente scomparso. In seguito a questa mail, ho deciso di ridurre la mia attività in SputniX a zero, ed uscirne. O forse non ne ho mai fatto parte, visto che ho pagato la quota associativa solo i primi due anni, e gli altri 4-5 no (cfr. messaggio).

Con la quasi-fusione con AICQ Sicilia poi, sembra che SputniX abbia preso una deriva "enterprise". Come Vincenzo avrà notato (o forse no) alla prima riunione (l'unica cui partecipai), io ero del tutto fuori luogo. Un mondo fatto di ingegneri, controllo di qualità, un sacco di paroloni; io un "quasi-dentista" con la passione per il FLOSS (notare il gioco di parole [1]). 'un ci trasu nenti nenti.

Ricordo con nostalgia le nottate passate a smanacciare sul kernel per presentare qualcosa al LM di $anno, oppure andar la mattina del LD, presto, al complesso didattico per dare una mano per sistemare le aule ed accogliere i visitatori, ed impazzire con Alessandro per fermare il fiume di gente che si presentava. O assistere meravigliato alla "linux car". Mi sentivo in una verà "comunità". Forse non lo era neppure allora, ma almeno ne aveva la parvenza.

Se penso che ora si parla di DM, DLgs, normative ISO, [..], mi veni 'u friddu. Visto che, sempre in riferimento al messaggio, non ho alcun diritto in merito alle attività dell'associazione, preferisco non litigare né "fare bile" con nessuno, ed uscirne.

Grazie a tutti delle pizziate. Forse i chili che ho preso sono anche merito vostro :) (merito, non colpa).

Forse un giorno troverò un LUG meno "rigido" sotto il punto di vista "chi può prendere le decisioni"; o forse ne creerò uno mio (il MazaLUG esiste come idea da qualche anno, e ho un paio di persone che spingono per crearlo, ma non mi ci sono mai messo visti gli impegni con l'uni. Forse, una volta laureato...).

In fin dei conti, è stata una bella esperienza.

Nel caso qualcuno voglia parlarmi, è inutile che mi cerchiate a casa. Né a Palermo né a Mazara.

Lo trovo un grave atto di scortesia E di violazione della privacy (non ho mai dato il numero di telefono di casa a Mazara, eppure...), e c'è il rischio che mi scaldi troppo a parlare dal vivo di questa situazione (non solo per questo, anche per il periodo particolarmente stressante; purtroppo non sono fatto a camere stagne). Ripeto, non voglio inimicarmi nessuno, quindi meglio lasciar perdere, e parlarne solo online (dove una mail si può rileggere più volte, e si può tenere a bada l'istinto; tipo questa, che è scritta da un paio di giorni, ed è stata limata e modificata più e più volte).

Sadly,

David

[1] sarò pure amareggiato, ma non per questo perdo il mio umorismo nerd.

--->8---

Non so se il messaggio in questione sia visibile da tutti, in caso contrario:

From: Vincenzo Virgilio <[..]>

To: Sputnix@yahoogroups.com

Subject: Re: [Sputnix - 24 Ottobre LD09] Proposta di mediazione - Locandina - Logo

Date: Tue, 2 Mar 2010 09:44:33 +0100

Lo status di soci è riservato a tutti coloro che sono in regola con le quote associative, dal primo anno di iscrizione a oggi.

Quindi prima di parlare di diritti, voti o altri argomenti, controlla di poterlo fare.

Vincenzo

JOSM/1.5 svn3094 in sid

For those of you fans of OpenStreetMap, I just uploaded JOSM 3094 to Sid.

I had to heavily patch this version, to disable OAuth support. Yes, you won't be able to use it with the Debian package. The reason is simple: supporting OAuth requires a set of packages not yet available in Debian. I've filed ITPs, and blocked bugs appropriately, but it'll take some time until the full chain is available.

In the meanwhile, enjoy! Go in the streets and map the world!

Getting network devices with Python and udev - 2

Thank you Ben for your kind reply :)

In my first post, I was trying to distinguish Ethernet-like device types.

Here's the final code:

import gudev

client = gudev.Client(['rfkill', 'net'])

for dev in client.query_by_subsystem('net'):
    if dev.get_sysfs_attr_as_int("type") != 1:
        continue

    driver = dev.get_driver()
    if not driver:
        parent = dev.get_parent()
        if parent:
            driver = parent.get_driver()

    # available: wlan, wwan, wimax
    if dev.get_devtype() == 'wlan':
        type = 'Wireless'
    else:
        type = 'Wired'

    print type, dev.get_name(), driver, dev.get_sysfs_path()

However, I have a few remarks.

First, I don't understand why ethernet devices don't have a "devtype" attribute. How can I be sure that, failing to be "wlan", "wwan" or "wimax", it's a wired one? (not that any other kind of device comes to my mind, heh).

Second, I had to look through Linux sources to find the possible values for DEVTYPE; in particular, I grepped for device_type structs inside ./drivers/net/. And the documentation you pointed me to, while being useful for other reasons (the rfkill support), didn't solve my doubts about the sysfs hierarchy.

Rather, your comment about DEVTYPE helped quite a lot in this particular problem.

Thank you! :)

Simple Python and Vala XML parsers

As some of you might know, I'm an OpenStreetMaper. In the last month, during those bits of spare time I had, I wrote a set of python scripts which compute some statistics over an OSM dump. I do this by parsing the whole XML tree, and national dumps are pretty huge (italy.osm is ~4G nowadays, and is not as well-mapped as Germany!), so I needed a way to do this without creating a memory-hungry beast.

With Python, I could succesfully do this:

#!/usr/bin/python
# -*- coding: utf-8 -*-

import xml.etree.cElementTree as etree

def parse(filename):
    source = open(filename)
    context = etree.iterparse(source, events=("start", "end"))
    context = iter(context)

    event, root = context.next()

    for event, elem in context:
        if event == "end":
            root.clear()
            continue

        print elem.tag

if __name__ == '__main__':
    import sys
    parse(sys.argv[1])

And here the results:

$ /usr/bin/time ./parsexml.py ~/osmstats/dumps/italy.osm.bz2.20100912.out 1>/dev/null
413.22user 6.15system 8:57.80elapsed 77%CPU (0avgtext+0avgdata 21200maxresident)k
7739552inputs+0outputs (10major+1470minor)pagefaults 0swaps

However, since some time, I wanted to learn Vala, so I tried to do this very same task with it. Here's the code:

using Xml;

class XmlParser {
    public void parse_file(string path) {
        var handler = SAXHandler();
        void* user_data = null;

        handler.startElement = start_element;
        handler.user_parse_file(user_data, path);
    }

    public void start_element(string name, string[] attr) {
        stdout.printf("%s\n", name);
    }
}

int main(string[] args) {
    Parser.init();
    var parser = new XmlParser();
    parser.parse_file(args[1]);
    Parser.cleanup();
    return 0;
}

You need to compile it with:

valac --pkg libxml-2.0 xml.vala

And here's the result:

$ /usr/bin/time ./xml ~/osmstats/dumps/italy.osm.bz2.20100912.out 1>/dev/null
122.01user 4.03system 3:14.61elapsed 64%CPU (0avgtext+0avgdata 6352maxresident)k
7738984inputs+0outputs (0major+461minor)pagefaults 0swaps

Both these codes are, however, CPU-hungry. But at least they don't swap :-)

Needless to say that I'm planning to switch my scripts to Vala for 2.0.

Using Git tutorial for Debian-Women

On the 25th of November I held a training session for the Debian Women project, about Using `Git <http://git-scm.com/>`__. A transcript of the session is available.

The session took 2,5 hours, more than I really expected (one hour less), but I had many questions asked. There were ~160 attendants, but many of those asking questions seem to have missed that this was a "basic" session, for people who never used it.

All in all, it was a great experience. While preparing the talk, I had the chance to re-read some forgotten manpages, which clarified some points, so it was really useful for me as well :)

Given the kind of questions I had, it would be nice to have an "Advanced Git" session, maybe in January-February. Any volunteers? I'll sure be attending it :)

FYI, the next session will be held by POX (Piotr Ożarowski) next Thursday (Dec, 2). It will be about Python libraries/application packaging, you'll have to read the introductory session as a pre-requisite.

Bash-Completion 1.2 released

After more than 9 months from the previous release, the Bash Completion Team is proud to announce the release of bash-completion 1.2!

In this release, we dropped support for bash < 3.2. We're sorry, but we cannot stop development just to support versions that old. By now, everyone should have a version fulfilling our requirement.

As usual, lots of completions have been added: we're now at 168 files in our contrib/ directory (1.1 had 145, and 1.0 had 44 -- but most completions in 1.0 were bundled in the main file). Now bash_completion only contains helper functions, and basic filename-based completions. Everything has moved to contrib/!

This release also saw the contribution of many external people, despite the fact that our bugtracker on Alioth doesn't seem to work too well (problem with attachments, anyone?). Anyhow, you're invited to register and start filing bugs as you find them :).

Apart from the usual team members (Ville Skyttä, Freddy Vulto, the newcome Leonard Crestez and me), we've had contributions from (in no particular order): Ted Stern, Jeremie Lasalle Ratelle, Raphaël Droz, Adrian Friedli, Ildar Mulyukov, Neville Gao, Austin English, Igor Murzov, Mario Schwalbe and Mark van Rossum. Thank you people for helping us!

For completion developers: we added new helper functions. Most notably, it's now possible to get the current and the previous "word" just by calling:

_get_comp_words_by_ref cur prev

instead of (up to 1.1):

cur=$(_get_cword)

prev=${COMP_WORDS[COMP_CWORD-1]}

Also, we have a new helper to deal with completion with colons, __ltrim_colon_completions(). See the comment in bash_completion for its documentation.

You'll find more helpers directly in bash_completion. We're still far from having a distributable API documentation, so please forgive us.

Enjoy the new bash-completion!

-- David

Contents © 2013 David Paleino - Powered by Nikola