If you don’t know about this great project, you should. The nitty gritty details are to be found here. FLOSS Manuals Release Circumvention Book, How To Bypass Internet
Censorship December 4, 2008, Amsterdam A new book released by FLOSS Manuals, How to Bypass Internet Censorship,
describes circumvention tools and explains why you might want to use
them, and honestly describes the risks you must consider before
circumventing blockers or monitors. Blockers and monitors restrict
access to areas of the Internet, and this book describes simple
techniques for bypassing those restrictions. The book can be read or
downloaded for free as a PDF from flossmanuals.net, or you can purchase
a high-quality printed copy of the 200 page book through Lulu, an
on-demand printer, at http://www.lulu.com/content/4904448 for 10.83
($14.00). The growth of the Internet has been paralleled by attempts to control
how people use it, motivated by a desire to protect children,
businesses, personal information, the capacity of networks, or moral
interests, for example. Some of these concerns involve allowing people
to control their own experience of the Internet (for instance, letting
people use spam-filtering tools to prevent spam from being delivered to
their own e-mail accounts), but others involve restricting how other
people can use the Internet and what those other people can and can’t
access. The latter case causes significant conflicts and disagreements
when the people whose access is restricted don’t agree that the blocking
is appropriate or in their interest. Problems also arise when blocking
mechanisms and filters reduce access to useful business, health,
educational, and other information. Because of concerns about the effect of internet blocking mechanisms,
and the implications of censorship, many individuals and groups are
working hard to ensure that the Internet, and the information on it, are
freely available to everyone who wants it. There is a vast amount of
energy, from commercial, non-profit and volunteer groups, devoted to
creating tools and techniques to bypass Internet censorship. Some
techniques require no special software, just a knowledge of where to
look for the same information. Programmers have developed a variety of
more capable tools, which address different types of filtering and
blocking. These tools, often called “circumvention tools” help Internet
users access information that they might not otherwise be able to see.
This book documents simple circumvention techniques such as a cached
file or web proxy, and also describes more complex methods using Tor,
which stands for The Onion Router, involving a sophisticated network of
proxy servers. How to Bypass Internet Censorship was written by eight writers in a
FLOSS Manuals ‘book sprint’ - a week-long intensive writing session, and
it also includes content from many different authors’ previous works on
the subject.
How to Bypass Internet Censorship will always be available for free from
the FLOSS Manuals Website. Each sale of the book generates $2.50 (USD).
100% of this income goes back into the development of more manuals about
free software. About FLOSS Manuals
http://www.flossmanuals.net
FLOSS Manuals is a non-profit foundation and community creating a
collection of manuals that explain how to install and use a range of
free and open source software. The manuals are friendly and simple, and
they are intended to encourage people to explore the wide range of free
and open source software. FLOSS stands for Free, Libre Open Source
Software, and FLOSS Manuals intends to provide free manuals for free
software. The manuals on FLOSS Manuals are written by a community of
people, writers, editors, and technicians do a variety of things to keep
the manuals as up to date and accurate as possible. The way in which
FLOSS Manuals are written mirrors the way in which FLOSS software itself
is written: by a community who contribute to and maintain the content. FLOSS Manuals produces printed books, PDF books, and HTML output. Each
chapter from each manual can be recombined with other chapters to create
a new manual, which we call remix capability. An embed API lets you use
FLOSS Manuals to write the content and then embed the content into your
website. For more information contact:
Adam Hyde
Founder, FLOSS Manuals
adam@flossmanuals.net

Next time I have to explain why I (really) prefer dogs to cats, I will not provide an argument. Instead, I will point people to this video. While the video is not an instance of joking, it is nonetheless a potent example of humor, at least in the way that the philosopher, Simon Critchley has defined it in his compact and very powerful (and very beautifully written) book, On Humour:

Jokes tear holes in our usual predictions about the empirical world. We might say that humour is produced by a disjunction between the way things are and they way they are represented in the joke, between expectation and actuality. Humour defeats our expectations by producing a novel actuality, by changing the situation in which we find ourselves…

Dear Lazy Web (this is a from a friend and I know next to nothing about video editing software): “Is there a good free video editor, on par with GIMP, that has a decently gradual learning curve, and works well?”

I discovered a minor Rails annoyance today, and, looking around for an answer to the problem, I found this, which is a perfect description of the issue, and includes a fix: http://dev.rubyonrails.org/ticket/5123 Unfortunately it has marked as "wont fix" with no reason specified. Perhaps there is a reasonable answer that was perhaps discussed elsewhere, and just didn't make it into the bug report, making it invisible to people like me who find it via Google, which is pretty annoying. The other explanation is more along the lines of "don't wanna" (or fuck you, as the case may be), but at least come out and say so. "We're not going to do it, as it's not part of our English-centric vision" or what have you. Being a native English speaker, even when doing stuff for Italian or Austrian or whatever clients, I tend to code in English, because it's 1) fast, 2) easy and 3) it's pretty much universally understood by programmers. However, I can see the case for specific things to be in a particular language, and on the surface, this one line patch makes that a little bit easier, and doesn't appear to be costly, so why not? Just closing the bugs of people who have taken the time to try and help (this is clearly not just a "dude, it's, uh, broke" bug) is the twin of the equally annoying people who don't bother to take 30 seconds to send an email or bug report about software they're using, and both are things I greatly dislike.

Waking up this morning, I noticed a low traffic in my incoming mail in "Debian work" mailboxes (PTS mailboxes, personal email, bugs, -release, etc.). Then I read -devel and understood. Everything is there. We have a new flamewar (apparently about NEW processing). It's interesting to see that the closer we get from a release, the biggest flamewars we are doing. Sounds like everybody is boring (have you notived the strong drop in the bug report rate?). Crap, there's a lot of work left to do, to release the damn Lenny:

• Zap down RC bugs (last time I checked 64 were both in lenny and unstable, not marked pending and not hinted)
• Release D-I RC2
• Test upgrade paths
• And, of course, I should not forget about the most important thing on earth: vote about firmware cra^W haircutt^W proposals

For $ DEITY 's sake, could we do that, so that developers stop boring, then go back to their development duties and the number of flamewars lowers down again (maybe after the squeeze release goals discussion which will probably be "interesting", also)? Please...your home page, these days, should really be http://bts.turmzimmer.net...

Recently I suggested to some students that they could use the Gnu Linear Programming Toolkit from C++. Shortly afterwards I thought I had better verify that I had not just sent people on a hopeless mission. To test things out, I decided to try using GLPK as part of an ongoing project with Lars Schewe The basic idea of this example is to use glpk to solve an integer program with row generation. The main hurdle (assuming you want to actually write object oriented c++) is how to make the glpk callback work in an object oriented way. Luckily glpk provides a pointer "info" that can be passed to the solver, and which is passed back to the callback routine. This can be used to keep track of what object is involved. Here is the class header

#ifndef GLPSOL_HH
#define GLPSOL_HH
#include "LP.hh"
#include "Vektor.hh"
#include "glpk.h"
#include "combinat.hh"
namespace mpc  
  class  GLPSol : public LP  
  private:
    glp_iocp parm;
    static Vektor<double> get_primal_sol(glp_prob *prob);
    static void callback(glp_tree *tree, void *info);
    static int output_handler(void *info, const char *s);
  protected:
    glp_prob *root;
  public:
    GLPSol(int columns);
    ~GLPSol()  ;
    virtual void rowgen(const Vektor<double> &candidate)  ;
    bool solve();
    bool add(const LinearConstraint &cnst);
   ;
 
#endif

The class LP is just an abstract base class (like an interface for java-heads) defining the add method. The method rowgen is virtual because it is intended to be overridden by a subclass if row generation is actually required. By default it does nothing. Notice that the callback method here is static; that means it is essentially a C function with a funny name. This will be the function that glpk calls when it wants from help.

#include <assert.h>
#include "GLPSol.hh"
#include "debug.hh"
namespace mpc 
  GLPSol::GLPSol(int columns)  
    // redirect logging to my handler
    glp_term_hook(output_handler,NULL);
    // make an LP problem
    root=glp_create_prob();
    glp_add_cols(root,columns);
    // all of my variables are binary, my objective function is always the same
    //  your milage may vary
    for (int j=1; j<=columns; j++) 
      glp_set_obj_coef(root,j,1.0);
      glp_set_col_kind(root,j,GLP_BV);
     
    glp_init_iocp(&parm);
    // here is the interesting bit; we pass the address of the current object
    // into glpk along with the callback function
    parm.cb_func=GLPSol::callback;
    parm.cb_info=this;
   
  int GLPSol::output_handler(void *info, const char *s) 
    DEBUG(1) << s;
    return 1;
   
  Vektor<double> GLPSol::get_primal_sol(glp_prob *prob) 
    Vektor<double> sol;
    assert(prob);
    for (int i=1; i<=glp_get_num_cols(prob); i++) 
      sol[i]=glp_get_col_prim(prob,i);
     
    return sol;
   
  // the callback function just figures out what object called glpk and forwards
  // the call. I happen to decode the solution into a more convenient form, but 
  // you can do what you like
  void GLPSol::callback(glp_tree *tree, void *info) 
    GLPSol *obj=(GLPSol *)info;
    assert(obj);
    switch(glp_ios_reason(tree)) 
    case GLP_IROWGEN:
      obj->rowgen(get_primal_sol(glp_ios_get_prob(tree)));
      break;
    default:
      break;
     
   
  bool GLPSol::solve(void)    
    int ret=glp_simplex(root,NULL);
    if (ret==0) 
      ret=glp_intopt(root,&parm);
    if (ret==0)
      return (glp_mip_status(root)==GLP_OPT);
    else
      return false;
   
  bool GLPSol::add(const LinearConstraint&cnst) 
    int next_row=glp_add_rows(root,1);
    // for mysterious reasons, glpk wants to index from 1
    int indices[cnst.size()+1];
    double coeff[cnst.size()+1];
    DEBUG(3) << "adding " << cnst << std::endl;
    int j=1;
    for (LinearConstraint::const_iterator p=cnst.begin();
         p!=cnst.end(); p++) 
      indices[j]=p->first;
      coeff[j]=(double)p->second;
      j++;
     
    int gtype=0;
    switch(cnst.type()) 
    case LIN_LEQ:
      gtype=GLP_UP;
      break;
    case LIN_GEQ:
      gtype=GLP_LO;
      break;
    default:
      gtype=GLP_FX;
     
    glp_set_row_bnds(root,next_row,gtype,       
                       (double)cnst.rhs(),(double)cnst.rhs());
    glp_set_mat_row(root,
                    next_row,
                    cnst.size(),
                    indices,
                    coeff);
    return true;
   
 

All this is a big waste of effort unless we actually do some row generation. I'm not especially proud of the crude rounding I do here, but it shows how to do it, and it does, eventually solve problems.

#include "OMGLPSol.hh"
#include "DualGraph.hh"
#include "CutIterator.hh"
#include "IntSet.hh"
namespace mpc 
  void OMGLPSol::rowgen(const Vektor<double>&candidate) 
    if (diameter<=0) 
      DEBUG(1) << "no path constraints to generate" << std::endl;
      return;
     
    DEBUG(3) << "Generating paths for " << candidate << std::endl;
  // this looks like a crude hack, which it is, but motivated by the
  // following: the boundary complex is determined only by the signs
  // of the bases, which we here represent as 0 for - and 1 for +
    Chirotope chi(*this);
    for (Vektor<double>::const_iterator p=candidate.begin();
         p!=candidate.end(); p++) 
      if (p->second > 0.5)  
        chi[p->first]=SIGN_POS;
        else  
        chi[p->first]=SIGN_NEG;
       
     
    BoundaryComplex bc(chi);
    DEBUG(3) << chi;
    DualGraph dg(bc);
    CutIterator pathins(*this,candidate);
    int paths_found=
      dg.all_paths(pathins,
                   IntSet::lex_set(elements(),rank()-1,source_facet),
                   IntSet::lex_set(elements(),rank()-1,sink_facet),
                   diameter-1);
    DEBUG(1) << "row generation found " << paths_found << " realized paths\n";
    DEBUG(1) << "effective cuts: " << pathins.effective() << std::endl;
   
  void OMGLPSol::get_solution(Chirotope &chi)  
    int nv=glp_get_num_cols(root);
    for(int i=1;i<=nv;++i)  
      int val=glp_mip_col_val(root,i);
      chi[i]=(val==0 ? SIGN_NEG : SIGN_POS);
     
   
 

So ignore the problem specific way I generate constraints, the key remaining piece of code is CutIterator which filters the generated constraints to make sure they actually cut off the candidate solution. This is crucial, because row generation must not add constraints in the case that it cannot improve the solution, because glpk assumes that if the user is generating cuts, the solver doesn't have to.

#ifndef PATH_CONSTRAINT_ITERATOR_HH
#define PATH_CONSTRAINT_ITERATOR_HH
#include "PathConstraint.hh"
#include "CNF.hh"
namespace mpc  
  class CutIterator : public std::iterator<std::output_iterator_tag,
                                                      void,
                                                      void,
                                                      void,
                                                      void> 
  private:
    LP& _list;
    Vektor<double> _sol;
    std::size_t _pcount;
    std::size_t _ccount;
  public:
    CutIterator (LP& list, const Vektor<double>& sol) : _list(list),_sol(sol), _pcount(0), _ccount(0)  
    CutIterator& operator=(const Path& p)  
      PathConstraint pc(p);
      _ccount+=pc.appendTo(_list,&_sol);
      _pcount++;
      if (_pcount %10000==0)  
        DEBUG(1) << _pcount << " paths generated" << std::endl;
       
      return *this;
     
    CutIterator& operator*()  return *this; 
    CutIterator& operator++()  return *this; 
    CutIterator& operator++(int)  return *this; 
    int effective()   return _ccount;  ;
   ;
 
#endif

Oh heck, another level of detail; the actual filtering actually happens in the appendTo method the PathConstraint class. This is just computing the dot product of two vectors. I would leave it as an exercise to the readier, but remember some fuzz is neccesary to to these kinds of comparisons with floating point numbers. Eventually, the decision is made by the following feasible method of the LinearConstraint class.

 bool feasible(const
Vektor<double> & x)  double sum=0; for (const_iterator
p=begin();p!=end(); p++)  sum+= p->second*x.at(p->first);  
      switch (type()) 
      case LIN_LEQ:
        return (sum <= _rhs+epsilon);
      case LIN_GEQ:
        return (sum >= _rhs-epsilon);
    default:
      return (sum <= _rhs+epsilon) &&
        (sum >= _rhs-epsilon);
       
     

You remember the bug sprint, don't you? I've already argued how nice the idea was, being a stereotypical example of how in Debian efficiency and fun can (and often must) go together. Well, Joss' cookies have been delivered to my office last Wednesday, unfortunately I wasn't there!!!, due to my participation first in the Debian QA Meeting in Extremadura, and then another academic workshop in Amsterdam. Sadly, I had to "delegate" the task of cookie tasting to other fellow Debian-ers which happen to work with me. Today I've finally got back to my office, and to much of my surprise, 5 cookies were still there waiting for me. In spite of the bad previsions about their health status after a week, they were delicious: simple biscuits, not too sweet, with walnut in pieces, and dark chocolate. So long Joss, and thanks for all the fish cookies.

Today I published set of changes to phpMyAdmin website, which add microformats attributes where applicable. Currently hCard and hAtom were added. The first one enables you to grab contacts directly from web page (if your browser supports it, currently you need some extension such as Operator). I also added some rel attributes to links, so application browsing the website can know relevance of some links.

I’m looking for people who are interested in testing the first release of gksu-polkit. I uploaded the first tarball to http://people.debian.org/~kov/gksu/gksu-polkit-0.0.1.tar.gz. There are also x86 packages available (built on a sid with a lot of experimental stuff, so if you have trouble installing please email me and I’ll have that fixed =P). For some history and discussion on the whys and hows do take a look at the README which exists inside the tarball (or git repo), and on the small page I wrote about it. For those who want to fiddle with the code, and perhaps help me finding bugs and fixing them, here’s my public git tree: git://git.debian.org/~kov/gksu-polkit.git

I’m working away from the office today because the office window is being replaced (an end to leaky draughty windows - yay! - but it does mean it’s about 3 degrees in there while it’s happening). For some reason, some things aren’t working over the wifi (the least of my network problems recently - blew up the router at the weekend), so I’m working in batches. I’ll let the phone go to voicemail and reply from a fixed line when I can. Pics and stuff about yesterday’s trade fair will appear later. I usually shy away from stuff labelled “geek” but here’s Bristol Wireless’s Christmas-time geek quiz night fundraiser on the 19th. D’ya reckon Woodsy will wear that bow-tie again when running the quiz?

I have just received an email with a question about SE Linux that was re-sent due to the first attempt being blocked by my anti-spam measures. I use the rfc-ignorant.org DNSBL services to stop some of the spam that is sent to me. The purpose of rfc-ignorant.org is to list systems that are run by people who don’t know how to set up mail servers correctly. But the majority of mail that is blocked when using them comes from large servers owned by companies large enough that they almost certainly employ people who know the RFCs (and who could for a trivial fraction of their budget hire such people). So it seems more about deliberately violating the standards than ignorance. The person who sent me the email in question said “hopefully, Google knows how to make their MTA compliant with RFC 2142“, such hope is misplaced as a search for gmail.com in the rfc-ignorant.org database shows that it is listed for not having a valid postmaster address [1]. A quick test revealed that two of the Gmail SMTP servers support the postmaster account (or at least it doesn’t give an error response to the RCPT TO command that is referenced in the complaint). However Gmail administrators have not responded to the auto-removal requests, which suggests that postmaster@gmail.com is a /dev/null address. However that is not a reason to avoid using Gmail. Some time ago Gmail took over the role of “mail server of last resort” from Hotmail. If you have trouble sending email to someone then using a free Gmail account seems to be the standard second option. Because so many people use Gmail and such a quantity of important mail is sent through that service (in my case mail from clients and prospective clients) it is not feasible to block Gmail. I have whitelisted Gmail for the rfc-ignorant.org tests and if Gmail starts failing other tests then I will consider additional white-lists for them. Gmail essentially has a monopoly of a segment of the market (that of free webmail systems). They don’t have 100%, but they have enough market share that it’s possible to ignore their competitors (in my experience). When configuring mail servers for clients I make sure that whatever anti-spam measures they request don’t block Gmail. As a rule of thumb, when running a corporate mail server you have to set up anti-spam measures to not block the main ISPs in the country (this means not blocking Optus or Telstra BigPond for Australian companies) and not block Gmail. Not blocking Yahoo (for “Yahoo Groups”) is also a good thing, but I have had a client specifically request that I block Yahoo Groups in the past - so obviously there is a range of opinions about the value of Yahoo. Someone contacted Biella regarding an email that they couldn’t send to me [2]. I have sent an email to Biella’s Gmail account from my Gmail account - that should avoid all possibility of blocking. If the person who contacted Biella also has a Gmail account then they can use that to send me email to my Gmail account (in the event that my own mail server rejects it - I have not whitelisted Gmail for all my anti-spam measures and it is quite possible for SpamAssassin to block mail from Gmail). It turns out that the person in question used an account on Verizon’s server, according to rfc-ignorant.org Verizon have an unusually broken mail server [3]. If your ISP is Optus, BigPond, Verizon, or something similarly broken and you want to send mail to people in other countries (where your ISP is just another annoyance on the net and not a significant entity that gets special treatment) then I suggest that you consider using Gmail. If nothing else then your Gmail account will still work even after your sub-standard ISP “teaches you a lesson” [4].

• [1] http://www.rfc-ignorant.org/tools/lookup.php?domain=gmail.com


• [2] http://gabriellacoleman.org/blog/?p=1121


• [3] http://www.rfc-ignorant.org/tools/lookup.php?domain=verizon.net


• [4] http://etbe.coker.com.au/2008/11/28/leaving-optus/

So in my first year Human Culture and Communication class we will soon be having a class on disability and communication. I wanted to show a video on eugenics to provide some historical context but I just found out that all decent videos (or ones that I have seen and thought were decent) have been pulled down.
The one I am looking for in particular is a 10 minute video by Liam Dunaway. I find it beyond despicably pathetic that an educational video, under 10 minutes long, is not available for people to watch. For x’s sake, if one cannot easily circulate this type of video, whose whole purpose is to educate, why even bother make it? These are times when I find copyright completely totally, fully, and also absolutely ludicrous. If you are going to make a 10 minute video on a political/educational subject like Eugenics, and you don’t consider freeing it up, then there is something really contradictory driving your creative desires. update: I wrote the filmmaker and got the word that someone had uploaded the video on their account and inappropriately connected himself to the video and so the film maker has uploaded the same video here

I just received this email:

From: Greg Lindstrom
To: Tutorial List

Hello,

On behalf of the PyCon Tutorial Selection Committee, I'd like to inform you that you have been selected to present at least 1 tutorial at PyCon 2009 in Chicago. We had 50 proposals for the 32 available slots and many good proposals had to be rejected.

It means: I get to stand in front of people I don't know in Chicago and talk about web scraping! (Unless the talk is canceled because no one signs up.) So I guess it means I'll be going to PyCon 2009! It's in Chicago, from March 25 to April 2. If you'll be there, too, drop me a line!

Ah, seems the days of posting snow pictures in Planet Debian have gone, and in any case I don’t have pictures, but I’ll blog about snow nevertheless. It never snows in Alicante, my home town. It’s by the sea in the south-east of Spain, and the winters are very mild there. I had only seen or touched snow once in my life, when I was about 7 and there was an outing in school to go and see the snow in some nearby mountain. I’m told it was crappy snow anyway. Today we returned from the QA meeting in Extremadura, arriving in Madrid really early in the morning. Knowing this, I had arranged to stay with friends Sunday and Monday, spending the night at agi@’s place. The house is in some mountain, at about 1800 meters over sea level, and there was plenty of snow. There was also a slope, and a plastic sled, so we did the obvious. It was fun, it made me happy, and I should pay Alberto another visit some other time with more appropriate clothing.

Space and place has long been important to hackers. Whether it was/is the university lab, the workplace, the hacker con, or the particularly high-tech city, hackers congregate and meet face to face, often and everyday. One semi-new development has been the explosion and proliferation of hacker labs and spaces, such as Noisebridge located in the Mission district of San Francisco Foulab in Montreal. I recently got back from San Francisco and was able to spend a few nights at Noisebridge and was jaw droppingly impressed. The space is, well, spacious and nice (and located right by the Bart, a real +++++), but more important is that it is a thriving collective with all sorts of geeky participants and they have just souped up the space with all sorts of equipment, from the usual suspects (lots of computers) to lots of electronic gear such as oscilloscopes. What I also was impressed by was not only the blizzard of events but the open and accessible nature of the organization, which seemed to sit in some contrast to NYC’s hacker collective, NYC Resistor. Like so many organizations in this metropolis, they apparently are lacking in space to grow and the word on the streets (which I cannot confirm or deny as I have had very little contact with them but have heard this repeatedly) is that the organization has had a tough time letting in new members. Some folks are understanding of this given their space limitation, others have been less kind, and have referred to the group as a clique. There are already a few other initiatives under way to find a larger space so as to accommodate a more open, participatory atmosphere for a hacker space (sign up for the email list here but I imagine that over time the culture and developments of NYC Resistor will also change as new spaces develops and do hope that this creates the conditions for more access rather than less (and again, I know next to nothing of the situation though I suspect space plays a real limiting role as it does with nearly everything else in NYC). And thankfully Rose White, a NYC-based sociology graduate student at CUNY, is paying close attention to the rise and development of these hacker spaces. She is well underway doing her dissertation dissertation on these hack spaces and I really look forward to her work. update: The Axis of Awesome is a hacker space in L.A. and as far as I am concerned, dons the best name.

Interestingly, the just finished Extremadura QA + ftpmaster + i18n meeting also turned into a quite strong Bug "Smashing" party. Several participants were digging around the list of RC bugs affecting both lenny and unstable. Most often, it turned out to many bug downgrades (for many of which I'll take the blame). It's "funny" to see how sometimes our bug reporters tend to inflate their reports, most often because they feel that "bug should absolutely be fixed", but completely forgetting about the definition of 'serious' or 'grave'. I also feel that, in some way, several maintainers begin to be quite demotivated by the length of the process (which I personnally consider as being caused by several factors: decreasing (wo)manpower, haircutting about freeness of every single byte on Debian CD's or even shyness wrt correct actions needed to deal with bugs). And several of these bugs just needed a very simple action by the maintainer. And, therefore, just because we were about 15 people with a lot of time to devote to Debian for 3 days, we ended up digging in that pile of mud....removing most of the dust and sometimes very debatable RC bug reports, and finally having that count of bugs affecting both lenny and unstable go down again. This comforts me in the feeling that an aggressive approach is a good key to bug squashing. After all, if I'm sometimes too aggressive and inappropriately downgrade an RC bug, I'm sure that someone will correct me (and, anyway, I'm not that mad: sometimes I seek for advices). Ah, and "aggressive" also sometimes mean proposing to tag some bugs "lenny-ignore" (and, that needs to be very convincing with our release managers, believe me). So, what about you? Have you already smashed an RC bug today? If not, do it. Kill those nasty beasts, they deserve it. No mercy.

Hacking the PTS using SOAP I've finally found some time, thanks to the Extremadura QA + ftpmaster + i18n meeting, to release the first draft of the SOAP interface to the PTS. You probably already got the idea, which is quite simple after all. The PTS, as always, gathers information about (source) packages from various sources and melds them together into web pages. With a SOAP interface you just gain the ability of accessing such information from your programs via SOAP. A proof of concept is overdue:

    $ cat ./test.py 
    #!/usr/bin/python
    import SOAPpy
    url = 'http://packages.qa.debian.org/cgi-bin/soap-alpha.cgi'
    ws = SOAPpy.SOAPProxy(url)
    print ws.versions(source="ocaml")['unstable']
    print ws.uploaders(source="ocaml")[1]['name']
    $ ./test.py 
    3.10.2-3
    Stefano Zacchiroli

Everything is still in alpha version, but already working. Some links which you might find useful:

• (fancy) API reference (blame epydoc if you think it's too fancy)
• general information about the SOAP interface (from wiki.d.o), including pointers to other doc / tools

Please let me know if / how you are using of the SOAP interface, it will help for future developments. How it works Just a few comments on how it works. You might remember that a while ago I've made all PTS pages XHTML-valid. Well, on top of it I've implemented something along the lines microformats, that just make a clever use of ingredients already available in XHTML like classes and unique identifiers. Having that, a "reshuffling" of the information already available on the web pages (which are now kinda "semantically" tagged) can be obtained by evaluating a handful of XPaths on the (not anymore) final XHTML pages. That's precisely what the CGI implementing the SOAP API is currently doing. This way one can avoid implementing two different access paths to the information collected by the PTS: one for rendering, and one for SOAP (no, reusing the rendering one for SOAP was not an option, given that it was originally written in XSLT). The only annoyance I've encountered is that XPath is completely unaware of the "CSS-like" semantics of XHTML classes, which states that classes are space-separated list of class names, to be interpreted as sets. That means that to check whether an element belongs to a given class you need to fiddle with substring matches on the class attribute (which is quite crappy).

This is a great little book filled with everyday wisdom though I have to say, this is patently untrue (at least for me).