Someone recently give me a link to a web picasa photo album. I wanted to download all the photo in good resolution, but the only official way to download it is by using the picasa proprietary software. Not only I'm not thrilled to install yet another unfree software, but Google refuse me to download it because "Picasa is not currently available for your operating system". Another solution exist, but need some research:

• You need a Grease monkey userscript that add links in the overview to download the image
• Then the DownThemAll extension will download all those link...

Some time, its great to be able to beat limitation of unfree software thanks to free software.

I ve recently gone through some of the unpacked source sitting in the lintian lab, and I ve got a few cool stats. First of all, the types of VCS tags I ve found:

      1 vcs-git
    123 Vcs-git
   6480 Vcs-Git
      1 Vcs-GIT
      5 VCS-git
     86 VCS-Git

Interesting! It seems the (IMHO correct) Vcs-Git style has a lot of adoption

     17 XS-Vcs-Git

and a few old style git tags :) Well, let s take a look at the most common prefixes:

   6498 git
    196 http
     15 https

All pretty stock, when I see (to my shock) a:

      4 git+ssh

Oh noes! Let s get rid of those, folks! :) So, let s check out the most popular domains to host git packages:

    5375 git.debian.org
     555 anonscm.debian.org
     171 github.com

OK, I d like to stop right here. As much as I hate nonfree software, and I think relying on as part of our infrastructure sucks, there is a degree of sense to keeping stuff on GitHub. If upstream is on GitHub, it may make it easier to coordinate and work with them. However! These are repos sitting in people s personal accounts which means taking over the package in the event someone needed to is not practical. The person with the highest number of Debian repos on GitHub is 19, followed by 12, 5 and a few 4s. Enter github.com/debian IMHO, we should consider putting the repos that are already on GitHub under Debian namespace, so that the team of maintainers may be able to add new collaborators. I mean, we have the account and some friendly DDs who offered to take care of this organization outside the project. That, or get us off GitHub entirely. I m not sure that s wise, though. However, even though there are a ton of repos on GitHub, it s about 1/40th of the total number of VCS tagged packages in Debian. On with the show:

      60 git.debian-maintainers.org
      39 gitorious.org
      26 git.b9.com
      22 git.lxde.org
      19 git.kitenet.net
      19 git.brad-smith.co.uk
      18 git.gag.com

And some of the more interesting ones:

      1 code.launchpad.net

for Vcs-Git??? :)

      1 git.debian.org:

Looks like it was a login@git.d.o: URL that was just changed slightly. Let s double-check our VCS tags, people :) The breakdown of Debian VCS d URLs:

      1 anonscm.alioth.debian.org
      1 anonscp.debian.org
      1 git.debian.org:
      2 scm.alioth.debian.org
     12 alioth.debian.org
    555 anonscm.debian.org
   5375 git.debian.org

And out of git.d.o, 2544 of them use the git://git.debian.org/git/pkg-foo pattern rather then the git://git.debian.org/pkg-foo pattern. Interesting! roughly 78 use /users and roughly 113 use /git/users I had no idea we had so many complexities in our VCS pointers :) When I get some more time, I ll go through and figure out which team has the most Git VCS tags :)

In this report from LSM 2012 in Geneva I will report about

1. Medical imaging using Debian
2. Debian Med packaging workshop
3. Integration of VistA into Debian
4. Other interesting talks

Medical imaging using Debian There were about 10 attendees basically upstream developers of medical imaging software. The talk got some attention and the message to include even more medical imaging software into Debian was well percived. Thanks to Mathieu Malaterre there was some live demonstration which was way easier for him as a medical imaging expert than it would have been for me.
Debian Med packaging workshop Due to my advertising in the talk yesterday three students (two of them from one medical imaging project, one from an other project) attended the workshop. Thanks to Axel Beckert who helped me out surviving the challenge to walk on unexplored ground.

The idea of the workshop was to ask the attendees to name a package of their own and just package this. Because two of the attendees were upstream developers of CreaTools we decided to go on for packaging this. After circumeventing some pitfalls in the beginning it went rather smoothly and after about 2.5 hours we were able to commit some initial packaging to the Debian Med Git repository which comes quite close to a ready package (perhaps some split into a library and a development package needs to be done and for sure testing is needed).
Quoting Frederic Cervenansky, upstream of CreaTools

Thanks for your work. Your workshop was very interesting and didactic: a relevant discussion between Claire and me for the future of Creatools has emerged from the difficulties you encountered to package creatools. I will try, before the end of the month, to fully package creatools. And for sure, I will contact the debian-med mailing list.

Integration of VistA into Debian I had the good chance to directly address some issues of Claudio Zaugg the speaker in the talk Implementing open source Health Information Systems in Low- and Middle Income Countries a practical review directly before mine. It turned out that by using Debian packaged software might help simplifying the issues they had in supporting health care workers in Low- and Middle Income Countries.
My talk was partly repeating some basic ideas about Debian Med from the talk on Monday because the audience was completely different. Than I tried to explain in detail how we tried hard to establish good contacts to upstream developers and why this is essential to finalise the goal to include hospital information systems straight into Debian any by doing so open the doors of hospitals for large scale Debian installations.
There is also video recording of this talk. Other interesting talks OpenEMR, a multi-language free open source electronic health record for international use Just discussed the packaging of OpenEMR which is prepared for Debian Med as it can be seen on our tasks page. The contact to the creator of some inofficial package will be established to finalise this task.
OpenFovea : when open-source and biophysical research get married Just another target for Debian Med popped up in this talk to further enhance Debian Med in covering all issues of medical care on one hand and on the other hand helping upstream authors to distribute their code
more effectively.
Collaborative software development for nanoscale physics The talk would have fit very nicely into the Debian Science workshop at ESRF (European Synchrotron Radiation Facility) in Grenoble because it was about ETRF (European Theoretical Radiation Facility). At previous LSM events I had just talked with Yann and the work to include their software into Debian is on its way.
Free software and High Performance Computing This talk was not directly connected to my Debian work but I simply enjoyed to see how "two people" had a really entertaining talk about Top 500 computers. Vittoria, you made my last day at LSM.

Sitting in the airport during a layover on my way back from DebConf is one of the few times of year that time and motivation come together and routinely lead me to blog. Each year's DebConf has been special in its own way. This year at DebConf 12, in addition to the usual routine of catching up with all my far-away Debian friends, and of making new Debian friends in a country I've never been before, I got a special treat: my first opportunity to experience the practice of medicine in a foreign country. Last Saturday after arriving in Managua, I discovered that the very pretty paving stones making up the hotel walkway were also very slippery when wet, and the thin rubber strips that had been helpfully put in place to make them less slippery did not measurably succeed in doing so. So as it was raining that afternoon (as it does nearly every afternoon this time of year in Nicaragua), I slipped, and made the critical error of not falling. Instead, I stopped my slide - as it happens, by using the big toe of my left foot as if it were a roller skate brake. I don't recommend this, particularly if, as in my case, you already had it on your todo list to consult a podiatrist after DebConf regarding an ongoing feeling of weakness in precisely that part of precisely that foot. So while everything seemed fine the next day, Monday I woke up early with excruciating pain in my foot which, having forgotten about the incident two days prior, seemed to come from nowhere. After favoring the foot for another day and trying to keep the pain at bay using just OTC drugs, by Tuesday my foot was quite swollen and a source of concern. So I visited the clinic on the university campus, where the doctor diagnosed me with a dropped arch plus cellulitis due to bacteria entering through some invisible cut. Conclusion: university campus clinics are equally useless the world over. But at least in addition to pointlessly prescribing antibiotics, the doctor also prescribed some anti-inflammatory drugs to help bring the swelling down. Nevertheless, my questionable mobility kept both me and Patty from attending the day trip on Wednesday, which was a real shame as I had been keen to climb a volcano that day with my fellow Debian Developers (which in the end didn't happen for anyone, but that's a story for someone else's blog). Instead I took it easy for the day at the hotel, together with a few others who had opted not to attend the day trip, catching up on email and other work and hoping matters would improve. But by the end of the day the swelling was as bad as ever, if not worse, and I had no idea what was going on. Was it broken? Was something dislocated? And so I decided that the following day I would go to the hospital. The nearest hospital, as given in the DebConf local information page, is the Hospital Militar. It's a strange sort of thing as an American who remembers the 1980s to be seeking medical care from a facility operated by the Nicaraguan military; but accompanied by Fitoria, my native escort from the local team I had nothing to worry about; and besides, as a frequent international traveler I long ago learned the secret truth that people are people everywhere, no matter what flag they were born under. The highlight of the hospital visit was definitely when a member of the hospital staff, in full military uniform, shooed me towards a chair instead of standing to talk to her because "every patient has the right to sit, no matter what country they're in". After six x-rays and a doctor's consult, the conclusion was that it's probably not a broken bone and that it will probably clear up in just a couple of days with an even-better anti-inflammatory prescription and taking care of it by not walking on it. And indeed, my foot was already feeling better by Friday and aside from a little tenderness is now just about 100%. There are plenty of other entries on Planet Debian talking about the conference itself, and I don't think I have much to add to what's already been said there. But as for Nicaragua, I can conclude that it must be one of the best countries in the world to break your foot in - between the help of the hotel staff, the top-notch medical professionals, and above all the support of the DebConf local team (with a very big thank you again to Fitoria!), this is one brand of socialized medicine I can appreciate.

Neil McGovern asked me to add an additional feature to the BTS to support tracking the current status of attempts at fixing a bug. In past releases, we've used the nice commenting feature of bts.turmzimmer.net to keep track of what is going on in a particular nasty RC bug, who is working on it, and what needs to be done next (or if everyone can just ignore the bug). This feature should probably have already been in the BTS to start with, but now it is. In addition to the existing summary feature, where you can nominate a message or text to be the summary for a bug, there is an outlook command, which tracks the current status of the bug, and behaves in exactly the same way:

outlook 12345 not good
outlook 54321 0
thanks
I'm totally stymied by #54321.

for example. I plan to include the outlook in the bugscan output in the future too, so it'll be easily accessible. (And possibly up-to-the-minute with some javascript-fu.)

As already written, even though it seems, I didn't spend my time running at Debconf12. Or eating cheese... Or (tentatively) hiking volcanoes... Or helping people to kill each other with socks... Or drinking beers... Not *only* all of these (some of them at the same time, though hiking a volcano while eating cheese and drinking beers is not particularly easy)....but also some Debian work. So, I uploaded a backport of samba to squeeze backports and our squeeze users should now have the same samba version than wheezy ones. I also stopped several cronjobs on i18n.debian.net and moved some material there as links have been (or should be) moved to the brand new i18n.debian.org (and its alias l10n.debian.org). I did a major cleanup in tasksel, committed several fixes, proposed others for review (mostly to Joey Hess). All this in preparation for a soon-to-come upload, probably after D-I beta1 which has been prepared by Cyril Brulebois while he was.....not attending Debconf12.. I also followed the integration of Sorina Sandu's work on netcfg for link detection and network ESSID choice in Debian Installer. Sorina is doing well in her GSOC work, because she's clearly someone with great capabilities who we will, I hope, be able to keep contributing to Debian. We can also thank the mentoring work of Gaudenz Steinlin to guide Sorina through D-I's arcanes. I also went through the current status of debconf translation completeness in testing for the 7 languages that target 100% (Czech, German, Spanish, French, Portuguese, Russian, Swedish). Here, the point is mostly taking care that fixes are either:

• already fixed in unstable (therefore checking that unblock requests have been sent by maintainers)
• sent as a bug report (so that I can harrass package maintainers to fix it)
• under work by a localization team (so that I can pester them to move on)

I can we have good chances to achieve this goal for at least 6 of these 7 languages (Czech might be more tricky as several translations are not yet made). Finally, I also did most of my regular Debian work (which usually takes 1-2 hours every day)...and bits of my paid work (sorry for those people who I shared the table at breakfast, but that was my only common time window with my team at work). So, well, quite productive weeks, once again.

This morning, I ran again with No l, my longstanding Debian running friend. The goal was, this time, to explore the South-East heights of Managua. I noticed a road that seemed to be quiet enough and not requiring a too long transit through busy, noisy and bad smelling highways. So, at 06:00 we headed from the Seminole hotel to the road to Masaya (the very large highway that goes in front ofMetrocentro). We had to run along it for a bit less than 2km. Not the best thing but the road was not very busy at that time. Then, we turned right into a road heading towards a quite "classy" neighbourhood where roads are well paved, there are sidewalks, etc, etc. It was going up ALL TIME LONG, which is interesting as a start. This placed is named "Lomas de Santo Domingo" in Google Maps. We even found there the embassy of the Islamic Republic of Iran. I can tell you, the Iran ambassador is quite living in a neat place and probably very happy to be there..:-) Fromthere, a very good concrete road starts to go up and up and up and up. many many very high standard villas, with fences, guards, etc. Strangely, there were several "For Sale" signs instead of "Se Vende". So, I guess this is a sign that this place is mostly inhabited by (very rich) foreigners, diplomats, etc. This very nice road was also....climbing a lot: 180m in 3.5km, so 5.1% average, but sometimes closer to 10%! At the very end of the road, we however ended....on a fence. It's apparently guarding the final part of the road where even more fancier villas seem to be, according to the satellite view..:-). We tried to use a small path up, but had to stop quite quickly. (OK, No l is definitely blurry there....blame the tired eyes after 8.7km climbing all the way) And then, all we had to do was....going down..:-). Being both in a fairly good shape, that went quite fast. But we both agreed that the final part, above 12km/h along the highway, with the sun hitting hard, was quite a challenge. I really admire those people who happen to run long distance in places like Managua. I can't even imagine running a marathon here.... GPS trace of what finally turns out to be my longest run here as of now with 17.5km in about 1h40.

It s the last day of Debconf 12 in Managua, it s the first ever Decbonf I ve attended and it has been just awesome.

Not few times I ve come upon the situation where I m working over a Subversion working copy locally and I wanted to commit bits of what I ve already baked and ready to go. Odds are that there s only one file not belonging to such changeset but mostly there are many files scattered around. This situation, I learned, can be managed with a lot more flexibility and fun.
svn changelist is a nice tool for such situation. svn changelist allows you to create a list of files I want to do something with meaning that you can use the changelist on your usual svn operations, read commit, remove, etc. Let s suppose you start with a project myapp, then you start creating three files A, B and C.
dragon% touch A B C
dragon% ls -lh
total 0
-rw-r--r-- 1 rudy rudy 0 Jul 13 20:16 A
-rw-r--r-- 1 rudy rudy 0 Jul 13 20:16 B
-rw-r--r-- 1 rudy rudy 0 Jul 13 20:16 C dragon% svn add A B C
A A
A B
A C
dragon% svn ci "first commit of A, B and C" .
Adding A
Adding B
Adding C
Transmitting file data ...
Committed revision 1.
Now we want to edit A and add few pieces of text. Then edit B also.
dragon% echo "This file looks empty, so let's put some text inside it" > A
dragon%
dragon% echo "I'm afraid this one also is empty. Just in case" >> B
Now, I need to work on this C file and that implies touching B also. I don t want to commit the changes I ve already made since I haven t made up my mind about them.
dragon% echo "C is a nice name for a source file, but this one doesn't look like one does it?" > C
dragon% echo "I'm going to add few lines to B too" >> B

dragon% svn st
M A
M B
M C
So, let s suppose I m ready to hit the key and commit the 2nd revision. But I m not done on A, so I want to commit just B and C the way they are now. Here svn changelist enters the arena. I can create a changelist for the two files and do several tasks related to them. Let s see.
dragon% svn changelist mylist B C
Path 'B' is now a member of changelist 'mylist'.
Path 'C' is now a member of changelist 'mylist'.
Now I have a changelist named mylist that I can do operations with. For instance,
dragon% svn st
M A --- Changelist 'mylist':
M B
M C

dragon% svn diff --changelist mylist
Index: B
===================================================================
--- B (revision 1)
+++ B (working copy)
@@ -0,0 +1,2 @@
+I'm afraid this one also is empty. Just in case
+I'm going to add few lines to B too
Index: C
===================================================================
--- C (revision 1)
+++ C (working copy)
@@ -0,0 +1 @@
+C is a nice name for a source file, but this one doesn't look like one does it?
Now let s commit the list.
dragon% svn ci -m "Comitting files from the mylist changelist" --changelist mylist
Sending B
Sending C
Transmitting file data ..
Committed revision 2.

dragon% svn st
M A
Now that I ve committed the files, the changelist mylist vanishes from our working copy. I cannot do any new operations with it. Few things you have to consider when using svn changelist.
changelist s are created in a one-time list, that means you cannot add another file to an existing list. If I type svn changelist mylist A it will define the changelist mylist to have just one member, A. It will not add A to the existing member files, B and C. Now, you are free to remove any file from an existing changelist using svn changelist mylist --remove B, for our previous example. That will make the changelist shrink to just have one element, C. You can also have as many changelists as you want, and member files can be associated to each one of them. Use case for that could be a diff over specific files. For this test project it almost makes no difference using this feature, but when you have lots of file sitting modified on your working copy, this feature will keep your hair on it s place, and maybe save the day. svn changelist is available since Subversion 1.5.

Android vs iPad I m currently in discussions with a client about a potential future project which involves a tablet computer talking to some electronic equipment. The options are an Android tablet and an iPad. One advantage of Android is that it runs on devices of all shapes and sizes, so we can choose a device that fits the need rather than designing everything around the iPad. But the real problem with iPad is Apple. To run an app on an iPad you need to submit it to Apple, hopefully get it accepted into the App Market, then install it. This process causes some delay, a minor fee, and has the potential to derail the project if Apple doesn t accept the app on the first try. With Android there is no need to even deal with Google, the app can be installed directly without the Google Play store. I may end up working with an iPad (which admittedly is really nice hardware), but it seems most likely that the project in question will run on Android only. Windows vs Linux and Apple OS/X One of my clients recently paid a web development company to redevelop his web site. I turned out that the web developers in question only knew how to develop for Windows and my client didn t discover this until too late. Now a site that s currently using a small fraction of the resources on a $80 per month Linode instance will run on a Windows virtual server costing $300 per month (which includes SQL server license). The Windows virtual server will probably be managed (because my client uses only Apple and Linux systems and doesn t employ anyone with Windows skills) which adds an extra $100 per month. If the server isn t managed then they will have to hire someone to apply patches and that won t necessarily be cheaper. So using Windows is going to cost my client an extra $400 per month when compared to the possibility of running a Linux system on the existing virtual server. Even if my client had someone with Windows skills to run the server it would still be an extra $300 per month. If the NBN was available then my client could run a Windows server in their office, but it s not yet available in their area. Even for a company that employs people with more Windows skills than Linux skills there are still economic factors in favor of Linux due to smaller hardware requirements and the lack of license fees for all the core software (OS, database server, web server, etc). Summary These anecdotes aren t unusual, it s the sort of thing that happens all the time. Sometimes the result is good (EG avoiding the iPad), sometimes it isn t (being stuck with a proprietary web service). I think I ll have to suggest to my clients that every contract have a no proprietary software clause. Contracts can be amended if there is a reason, but it seems best to make a preemptive strike against companies that sneak proprietary software in and cause significant unexpected expense and difficulty. Related posts:

1. The Lenovo U1 Hybrid an example of how Proprietary OSs Suck Lenovo have announced their innovative new U1 Hybrid laptop [1]....
2. My Prediction for the iPhone I have previously written about how I refused an offer...
3. Liberty and Mobile Phones I own two mobile phones at the moment, I use...

In the past I used to argue that accurate desktop DPI was important, since after all otherwise you could print out a 12 point font and hold up the sheet of paper to your monitor and it would be different. I later gave up on the idea that accurate DPI measurement was generally useful to the desktop, but there's still something seductively attractive about the idea that a 12 point font should be the same everywhere, and someone recently wrote about that. Like many seductively attractive ideas it's actually just trying to drug you and steal your kidneys, so here's why it's a bad plan.

Solutions solve problems. Before we judge whether a solution is worthwhile or not, we need to examine the problem that it's solving. "My 12pt font looks different depending on the DPI of my display" isn't a statement of a problem, it's a statement of fact. How do we turn it into a problem? "My 12pt font looks different depending on which display I'm using and so it's hard to judge what it'll look like on paper" is a problem. Way back in prehistory when Apple launched the original Mac, they defined 72dpi as their desktop standard because the original screen was approximately 72dpi. Write something on a Mac, print it and hold the paper up to the monitor and the text would be the same size. This sounds great! Except that (1) this is informative only if your monitor is the same distance away as your reader will be from the paper, and (2) even in the classic Mac period of the late 80s and early 90s, Mac monitors varied between 66 and 80dpi and so this was already untrue. It turns out that this isn't a real problem. It's arguably useful for designers to be able to scale their screen contents to match a sheet of paper the same distance away, but that's still not how they'll do most of their work. And it's certainly not an argument for enforcing this on the rest of the UI.

So "It'll look different on the screen and paper" isn't really a problem, and so that's not what this is a solution for. Let's find a different problem. Here's one - "I designed a UI that works fine on 100DPI displays but is almost unusable on 200DPI displays". This problem is a much better one to solve, because it actually affects real people rather than the dying breed who have to care about what things look like when turned into ink pasted onto bits of dead tree. And it sounds kind of like designing UIs to be resolution independent would be a great solution to this. Instead of drawing a rectangle that's 100 pixels wide, let me draw one that's one inch wide. That way it'll look identical on 100dpi and 200dpi systems, and now I can celebrate with three lines of coke and wake up with $5,000 of coffee table made out of recycled cinema posters or whatever it is that designers do these days. A huge pile of money from Google will be turning up any day now.

Stop. Do not believe this.

Websites have been the new hotness for a while now, so let's apply this to them. Let's imagine a world in which the New York Times produced an electronic version in the form of a website, and let's imagine that people viewed this website on both desktops and phones. In this world the website indicates that content should be displayed in a 12pt font, and that both the desktop and phone software stacks render this to an identical size, and as such the site would look identical if the desktop's monitor and the phone were the same distance away from me.

The flaw in this should be obvious. If I'm reading something on my phone then the screen is a great deal closer to me than my desktop's monitor usually is. If the fonts are rendered identically on both then the text on my phone will seem unnecessarily large and I won't get to see as much content. I'll end up zooming out and now your UI is smaller than you expected it to be, and if your design philosophy was based on the assumption that the UI would be identical on all displays then there's probably now a bunch of interface that's too small for me to interact with. Congratulations. I hate you.

So "Let's make our fonts the same size everywhere" doesn't solve the problem, because you still need to be aware of how different devices types are used differently and ensure that your UI works on all of them. But hey, we could special case that - let's have different device classes and provide different default font sizes for each of them. We'll render in 12pt on desktops and 7pt on phones. Happy now?

Not really, because it still makes this basic assumption that people want their UI to look identical across different machines with different DPI. Some people do buy high-DPI devices because they want their fonts to look nicer, and the approach Apple have taken with the Retina Macbook Pro is clearly designed to cater to that group. But other people buy high-DPI devices because they want to be able to use smaller fonts and still have them be legible, and they'll get annoyed if all their applications just make the UI larger to compensate for their increased DPI. And let's not forget the problem of wildly differing displays on the same hardware. If I have a window displaying a 12pt font on my internal display and then drag that window to an attached projector, what size should that font be? If you say 12pt then I really hope that this is an accurate representation of your life, because I suspect most people have trouble reading a screen of 12pt text from the back of an auditorium.

That covers why I think this approach is wrong. But how about why it's dangerous? Once you start designing with the knowledge that your UI will look the same everywhere, you start enforcing that assumption in your design. 12pt text will look the same everywhere, so there's no need to support other font sizes. And just like that you've set us even further back in terms of accessibility support, because anyone who actually needs to make the text bigger only gets to do so if they also make all of your other UI elements bigger. Full marks. Dismissed.

The only problem "A 12pt font should be the same everywhere" solves is "A 12pt font isn't always the same size". The problem people assume it solves is "It's difficult to design a UI that is appropriate regardless of display DPI", and it really doesn't. Computers aren't sheets of paper, and a real solution to the DPI problem needs to be based on concepts more advanced than one dating back to the invention of the printing press. Address the problem, not your assumption of what the problem is.

comments

I m leaving myself some room for bug fixes. It works for us in house. I would love to help others to give it a try. especially those who could benefit from making nearly immediately answered queries to the NIST s NVD database. The code in this release cannot by itself track the feed from the feds in real time. The nvd entry loader needs a little bit of love in the area of record merging before this starts working. It s on my TODO list. I m sorry for the outage of git.colliertech.org. I ll get that back up here shortly. In the meantime, feel free to grab it from this location while the CPAN indexes and processes my submission. http://www.colliertech.org/federal/NIST/NIST-NVD-1.00.00.tar.bz2 don t forget to check the cryptographic signature: http://www.colliertech.org/federal/NIST/NIST-NVD-1.00.00.tar.bz2.crc

And I still get into arguments about why I prefer apt-get over aptitude... Sometimes, stupid is good.

# apt-get update
[...get Debian sid package list...]
# aptitude install libdbd-csv-perl
The following NEW packages will be installed:
  libdbd-csv-perl libparams-util-perl a  libsql-statement-perl a  libtext-csv-xs-perl a 
The following packages will be upgraded:
  libdbi-perl perl perl-base perl-modules
4 packages upgraded, 4 newly installed, 0 to remove and 1459 not upgraded.
Need to get 9,845 kB of archives. After unpacking 1,069 kB will be used.
The following packages have unmet dependencies:
  libperl5.14: Depends: perl-base (= 5.14.2-7) but 5.14.2-12 is to be installed.
The following actions will resolve these dependencies:
      Remove the following packages:
1)      elinks
2)      irssi
3)      irssi-scripts
4)      libperl5.14
5)      perlmagick
6)      vim-gtk
7)      xchat
      Leave the following dependencies unresolved:
8)      elinks-data recommends elinks (= 0.12~pre5-7)
9)      vim-gui-common recommends vim-gnome   vim-gtk   vim-athena
10)     xchat-common recommends xchat
11)     inkscape recommends perlmagick
Accept this solution? [Y/n/q/?] ^C
# apt-get install libdbd-csv-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
  libdbi-perl libparams-util-perl libperl5.14 libsql-statement-perl libtext-csv-xs-perl perl perl-base perl-modules
The following NEW packages will be installed:
  libdbd-csv-perl libparams-util-perl libsql-statement-perl libtext-csv-xs-perl
The following packages will be upgraded:
  libdbi-perl libperl5.14 perl perl-base perl-modules
5 upgraded, 4 newly installed, 0 to remove and 1458 not upgraded.
Need to get 10.6 MB of archives.
After this operation, 1,081 kB of additional disk space will be used.
Do you want to continue [Y/n]?
Get:1 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main perl i386 5.14.2-12 [3,701 kB]
Get:2 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main libperl5.14 i386 5.14.2-12 [731 kB]
Get:3 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main perl-base i386 5.14.2-12 [1,494 kB]
Get:4 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main perl-modules all 5.14.2-12 [3,438 kB]
Get:5 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main libtext-csv-xs-perl i386 0.90-1 [73.1 kB]
Get:6 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main libdbi-perl i386 1.622-1 [897 kB]
Get:7 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main libparams-util-perl i386 1.07-1 [25.4 kB]
Get:8 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main libsql-statement-perl all 1.33-1 [179 kB]
Get:9 http://ftp5.gwdg.de/pub/linux/debian/debian/ unstable/main libdbd-csv-perl all 0.3500-1 [36.4 kB]
Fetched 10.6 MB in 10s (980 kB/s)
Retrieving bug reports... Done
Parsing Found/Fixed information... Done
Reading changelogs... Done
(Reading database ... 278465 files and directories currently installed.)
Preparing to replace perl 5.14.2-7 (using .../perl_5.14.2-12_i386.deb) ...
Unpacking replacement perl ...
Preparing to replace libperl5.14 5.14.2-7 (using .../libperl5.14_5.14.2-12_i386.deb) ...
Unpacking replacement libperl5.14 ...
Preparing to replace perl-base 5.14.2-7 (using .../perl-base_5.14.2-12_i386.deb) ...
Unpacking replacement perl-base ...
Processing triggers for man-db ...
Setting up perl-base (5.14.2-12) ...
(Reading database ... 278465 files and directories currently installed.)
Preparing to replace perl-modules 5.14.2-7 (using .../perl-modules_5.14.2-12_all.deb) ...
Unpacking replacement perl-modules ...
Selecting previously unselected package libtext-csv-xs-perl.
Unpacking libtext-csv-xs-perl (from .../libtext-csv-xs-perl_0.90-1_i386.deb) ...
Preparing to replace libdbi-perl 1.617-1 (using .../libdbi-perl_1.622-1_i386.deb) ...
Unpacking replacement libdbi-perl ...
Selecting previously unselected package libparams-util-perl.
Unpacking libparams-util-perl (from .../libparams-util-perl_1.07-1_i386.deb) ...
Selecting previously unselected package libsql-statement-perl.
Unpacking libsql-statement-perl (from .../libsql-statement-perl_1.33-1_all.deb) ...
Selecting previously unselected package libdbd-csv-perl.
Unpacking libdbd-csv-perl (from .../libdbd-csv-perl_0.3500-1_all.deb) ...
Processing triggers for man-db ...
Setting up libperl5.14 (5.14.2-12) ...
Setting up perl-modules (5.14.2-12) ...
Setting up perl (5.14.2-12) ...
Setting up libtext-csv-xs-perl (0.90-1) ...
Setting up libdbi-perl (1.622-1) ...
Setting up libparams-util-perl (1.07-1) ...
Setting up libsql-statement-perl (1.33-1) ...
Setting up libdbd-csv-perl (0.3500-1) ...
#

And don't get me started about waiting for aptitude *upgrade to resolve its dependency graph...

I failed. I didn't go running the day after the Cheese and Wine party (tuesday). I wonder why...:-) Indeed, I was feeling well, but slightly tired and I woke up at 8am, which means that I would have to go out quite late, in the heat...and run while feeling tired. And something I have learnt in all my running activities is that when one feels not in shape, better not insist. This is where injuries can come. Moreover, the next day was meant to be the Day Trip, with a goal for me: climb the Cerro negro volcano as fast as I can, training with my sticks for difficult climbs, in the heat...in the perspective of future races I would like to do in French Alps, in the upcoming years (such as La Montagn'hard : I recommend watching the video). Sadly, a landslide has cut the road 2km away from the starting point and, despite my desperate attempts to still form a group of "strong people" to go there and do the extra 4km walk anyway....we later learned that the entire road to Cerro Negro is closed and we'd have no chance to go on it. That infortunate, though I hopefully have another chance in the upcoming two weeks, where I'm supposed to come back and climb the volcano with Elizabeth (but, I of course will not leave my beloved one alone on a volcano!). So, I ended up staying on the beach at Las Pe itas. And, as I explained to No l, on days where I *decided* to run, I *need* to run. It's like a drug as you'd guess. So, I went running on the beach..:-). In the early afternoon, during a very hot day (probably the best weather we ever had, which makes me even more regret "my" volcano), about 34 C, no shade...and some wind, and sand...:-) Running on the beach is not as hard as one would imagine as long as you stay at the limit of the water, where the sand is compact. Indeed, this is even good for articulations as the sand soil is of course soft and absorbs impacts. The only drawback is that this beach is quite not so flat and this is sometimes like running across a hill all time long. Anyway, I went north up to Poneloya, up to the point where a river blocks the path along the beach, then I headed back. I had originally the intent to continue south-east, past the place where we were, up to the start of Juan Venaco island. However, the face wind when comign back, as well as the very hot sun, really achieved me....and I decided it would be wiser to stop. I however couldn't resist running IN the waves, which means I now have very humid shoes (but I have two pairs of those...:-)) Today (Thursday), was a more standard run in Managua, with No l and Ralf. We once again went to the South suburbs hills. All three of us were suite tired as it seems, so we chose a quite slow pace and, still, the climb was not that easy. We went the same way I went with Ralf a few days ago, but we didn't enter the "dogs path" this time, but rather tried to continue the road south. After 4.5 km, we had however to stop because the path didn't go further and, anyway, I think it was enough for all of us..:-) The way back, we tried another way, which was not particularly touristic (close to the National Soccer Stadium....a not so impressive stadium, but soccer is not the national sport here in Nicaragua, where people are more in base-ball or boxing). Both GPS traces:

• Run on the beach
• Run in South Managua

See you tomorrow for yet another GPS trace..:-)

More diversity in Debian skills This blog post has been co-authored with Francesca Ciceri. In his Debconf talk, zack said:

We need to understand how to invite people with different backgrounds than packaging to join the Debian project [...] I don't know what exactly, but we need to do more to attract those kinds of people.

Francesca and I know what we could do: make other kinds of contributions visible. Basically, we should track and acknowledge the contributions of webmasters, translators, programmers, sysadmins, event organisers, and so on, at the same level as what we do for packagers: DDPO, minechangelogs, Portfolio... For any non-packaging activity that we can make visible and credited, we get:

• to acknowledge the people who do it, and show that they are active contributors in the project;
• to acknowledge the work that gets done, and show the actual amount of non-packaging work that gets done in Debian every day;
• to allow non-packagers to have a reputation, too: first of all, they deserve it, and among other things, it would make nm processing trivial.

Here's an example: who's the lead translator for German? And if you are German, who's the lead translator for Spanish? Czech? Thai? I (Enrico) don't know the answers, not even for Italian, but we all should! Or at least it should be trivial to find out. To start to change this, is just a matter of programming. Francesca already worked on a list of trackable data sources, at least for translators. Here are some more details, related to translation:

• Translations can be tracked via the i18n robot (and relative statistics). This works only with teams who activated the robot and actively use the pseudo-urls in their messages on localisation mailing lists. Some translators don't bother to do it but it's ok to only support the main workflow. It beats extracting .po files from l10n-tagged BTS bugs at any rate.
• DPN and website translations: for wml pages there's a specific field to be extracted for each translated page: grep for maintainer="name" on normal wml pages, while for DPN translations we have a specific translator="name" field. The problem is that this field is not mandatory, so sometimes there's no indication of the maintainer. Again, it's ok to only support the main workflow. Anyway, this is preferable to the cvs log: often the commit is done by the coordinator of the team and not by the actual translator. See above for the alternative solution of using the statistics provided by the i18n bot.
• DDTSS: since the new release of DDTSS-Django, done by Martijn van Oosterhout about a year ago, the contributions are by default non-anonymous. This should be easy to track.
• : it is more complicated because in the wiki we do not have a proper l10n translation workflow, so the only thing that can be tracked are changelogs $LANG/* pages. A nice idea would be to have translated pages list the version of the page that was translated and who did the translation.
• translation of debian manuals and release notes: usually in the translation of manuals and long documentation there is a specific translator field.

And here are some notes about other fields:

• DPN editors: for each issue there's a list of editors at the bottom of the page. In the wml: grep for editor=.
• Artwork: artwork submitted via debianart are easy to track on the portal. Anyway usually you can find the author in the license and copyright file.
• Programming: the only thing we have is the list of services which can be expanded if needed.
• Press and publicity: there seems to be not much besides svn logs.
• l10n-english: The Smith Review Project page has some tracking links. Other activities can probably only be tracked, at the moment, via mailing list activity.
• Events: we can use the "main coordinator" field on www.debian.org/events/$year/$date-$eventname.wml: grep for <define-tag coord>; for events not published on the http://www.debian.org, but only on http://wiki.debian.org, the coordinator or the contact for the event is usually present on the page itself.
• Sysadmins: we haven't asked DSA.

And finally, if you are still wondering who those translation coordinators are, they are listed here, although not all teams keep that page up to date. Of course, when a data source is too hard to mine, it can make sense to see if the workflow could be improved, rather than spending months writing compicated mining code. This is a fun project for people at Debconf to get together and try. If by the end of the conference we had a way to credit some group of non-packaging contributors, even if just one like translators or website contributors, at least we would finally have started having official trackers for the activities of non-packagers.

Continuing in my better running through technology phase that I'm currently going through, I got all excited when I discovered that Polar make a Bluetooth-enabled heart rate monitor chest strap. Prior to this, I'd be lamenting how there wasn't a large choice of ANT+ enabled Android phones (to my knowledge there's just something Sony makes) So I got all excited and ordered a strap and it arrived today. This is my initial review (I haven't gone running with it yet, I've just had a tinker) I'll start with the bad first

the battery cover is a bit dicky

I took the battery cover off to confirm it came with a battery and then had a whale of a time getting it back on. I haven't managed to get it on as flush with the back as before I took it off. This appears to be a common complaint in the Amazon product reviews also.

hard to tell what its auto off timeout is, whether it's on, etc

Basically there's a large lack of feedback as to what's going on. Is it on or off? Is it wet enough to turn itself on? Is it reading a heart rate, or is the Bluetooth pairing just not working? The most accurate way I've found to determine if it's "working" or not is to unpair it and then repair it again. If you get a PIN prompt it's talking. By accident, I've found indications that it will turn itself off after not reading a heart rate for 10 minutes, and to reset it, you detach it and wait 30 seconds and reattach it. This would have been good information to include in the manual

Now for the good

reasonable Android app support

Heart Rate Monitor for Polar claims to support it, but I haven't managed to get it to do anything useful yet. I was pleasantly surprised to discover that My Tracks has support for it. Noom CardioTrainer is one that I was already trying out alongside Strava Run (which doesn't have support for it). There's also Sports Tracker and Endomondo. The UI for both of these also show the battery level. I've found that trying to have multiple apps reading the heart rate monitor simultaneously seems to be an exercise in fail, and that the Sports Tracker app seems to start a background service which subsequently causes all sorts of problems for any of the other apps started after it has started.

And the ugly Looking back at all the Amazon product reviews, they're pretty much split equally between 5 stars and 1 stars. The product seems to either work flawlessly or absolutely dreadfully. I was beginning to think I was in the latter group and that I'd bought a white elephant, but now that I've gotten to the bottom of the idiosyncrasies of talking to it from Android, it seems to be behaving fairly reliably. Talking to it from Linux, and the reason behind the title of this post One of the first things I tried doing after Android was being initially flaky for me, was to try and talk to it from a Linux laptop. This proved fairly straightforward using rfcomm. I didn't get anything human readable out of it though. Being curious as to how these Android apps were able to decode the data, I went looking for some API documentation, and a Google search led me to this sad forum discussion. So the API information is not freely available, and their CEO personally signs off on who gets access to it. How ludicrous. Do they want to sell product or not? That said, I did also find this blog post which, courtesy of the aforementioned Open Source My Tracks Android app, lays it all out for you. So them being all anti-development with their information is kind of pointless. Polar's website doesn't mention anything about their management, so I have no idea who their CEO even is. Wikipedia is also none the wiser. I'm looking forward to going for a run tomorrow and seeing how this thing pans out.

Even though I've planned to do this on Monday, it somehow slipped to Wednesday, but I've finally filled in GSoC 2012 evaluations for all students I mentor at phpMyAdmin. Generally all of them perform quite well, but there is always room for improvements :-). The greatest pain every year is filling up evaluations for more students - every each of them starts with same questions for mentor (eg. how many GSoC did you participate in or how much time you spend on GSoC). I know I can copy and paste answers, but still this looks like something not necessary. Also some information is probably already known to Google (eg. in which years I did participate in GSoC).

Filed under: English Phpmyadmin 0 comments Flattr this!

I s pose a better name would be How to preform automated deep-source checks I ve pushed the code to paultag/qlight, and it s just for personal use at the moment. It s built to use paultag/sb around sbuild. Basically, it preforms a crudload of tests such as licensecheck, suspicious-source, pyflakes, bashisms, cppcheck, php in linter mode, and a ton of other checks. You can see a large majority of them in the source file. The batch runner is a singleton , so it s safely called more then once. It s running on a 5-minute cron, and I ve configured a dput target to push it into it s queue & run the enqueue script. Here s some example output from a random package I had lying around:

  ===== build status =====
sbo-run-clang  successful
sbo-run-gcc  successful
  ===== global status =====
Ran plugin extract, exit code 0
Ran plugin watch, exit code 0
Ran plugin licensecheck, exit code 0
Ran plugin validate-source, exit code 0
Ran plugin build, exit code 0
Ran plugin descr, exit code 0
Ran plugin lintian, exit code 0
  ===== descr =====
I: PT: Does this sound right? "gbemol is/are a(n) Graphical frontend for the Music Player Daemon (MPD)"
  ===== piuparts =====
   [last 20 lines]
  ===== licenses =====
BSD (3 clause) 
GPL (v2 or later) 
GPL (v2 or later) GENERATED FILE
GPL (v2 or later) (with incorrect FSF address) 
LGPL (v2 or later) (with incorrect FSF address) 
*No copyright* GPL (v2 or later) 
*No copyright* UNKNOWN
  ===== lintian =====
I: gbemol: spelling-error-in-binary usr/bin/gbemol Wheter Whether
W: gbemol: hardening-no-relro usr/bin/gbemol
I: gbemol: spelling-error-in-manpage usr/share/man/man1/gbemol.1.gz allows to allows one to
  ===== watch =====
-- Scanning for watchfiles in .
-- Found watchfile in ./debian
-- In debian/watch, processing watchfile line:
   http://sf.net/gbemol/gbemol-(.*)\.tar.gz
-- Found the following matching hrefs:
     gbemol-0.3.tar.gz
     gbemol-0.3.1.tar.gz
     gbemol-0.3.2.tar.gz
Newest version on remote site is 0.3.2, local version is 0.3.2
 => Package is up to date
-- Scan finished
  ===== source issues =====
suspicious-source:
bashisms:
script ./ltmain.sh does not appear to have a #! interpreter line;
you may get strange results
possible bashism in ./ltmain.sh line 368 ($RANDOM):
        my_tmpdir="$ my_template -$ RANDOM-0 $$"
error: ./ltmain.sh: Unterminated quoted string found, EOF reached. Wanted: <">
pyflakes:
cppcheck:
[src/gbemol-utils.c:167]: (error) Memory leak: path
[src/libmpdclient.c:1654]: (error) Possible null pointer dereference: output - otherwise it is redundant to check if output is null at line 1663
[src/libmpdclient.c:1655]: (error) Possible null pointer dereference: output - otherwise it is redundant to check if output is null at line 1663
[src/libmpdclient.c:1656]: (error) Possible null pointer dereference: output - otherwise it is redundant to check if output is null at line 1663
[src/libmpdclient.c:1664]: (error) Possible null pointer dereference: output - otherwise it is redundant to check if output is null at line 1663
phplint:
desktop validate:
.//.pc/desktop_file.patch/gbemol.desktop: warning: key "Encoding" in group "Desktop Entry" is deprecated
.//.pc/desktop_file.patch/gbemol.desktop: error: (will be fatal in the future): value "gbemol.png" for key "Icon" in group "Desktop Entry" is an icon name with an extension, but there should be no extension as described in the Icon Theme Specification if the value is not an absolute path
.//.pc/desktop_file.patch/gbemol.desktop: warning: value "Application;AudioVideo;Player;" for key "Categories" in group "Desktop Entry" contains a deprecated value "Application"
mp3check:
mp3val:
fontlint:
ftvalid:
msgfmt:
POFileChecker:
POFileSpell:
pngcheck:
jpeginfo:
ogginfo:
oggz-validate:
xmllint:
lacheck:
jslint:
check for environ calls to home:
check for use of /tmp:
./intltool-extract.in:    $OUTFILE     = "./tmp/$OUTFILE.h"
check for use of system():
./aclocal.m4:    lt_ld_extra= awk '/^include /   system(sprintf("cd /etc; cat %s 2>/dev/null", \[$]2)); skip = 1;     if (!skip) print \[$]0; skip = 0;  ' < /etc/ld.so.conf   $SED -e 's/#.*//;/^[  ]*hwcap[    ]/d;s/[:,  ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d'   tr '\n' ' ' 
./intltool-merge.in:    return 1 if ((-x $file) or (system("$file -l >$devnull") == 0));
./intltool-merge.in:    system ("$iconv -f $encoding -t UTF-8 <$devnull 2>$devnull");
./intltool-update.in:    return 1 if ((-x $file) or (system("$file --version >$devnull") == 0));
./intltool-update.in:          system ($EXTRACT, "--update", "--srcdir=$SRCDIR",
./intltool-update.in:          system ($EXTRACT, "--update", "--type=$gettext_type", 
./intltool-update.in:    system ("$MSGMERGE", "-o", $outfile, $infile, "$MODULE.pot");
./intltool-update.in:    system ("$MSGFMT", "-o", "$devnull", "--verbose", $output_file);
./intltool-update.in:   system ("$MSGFMT", "-o", "$devnull", "--verbose", "$SRCDIR/$lang.po");
./configure:    lt_ld_extra= awk '/^include /   system(sprintf("cd /etc; cat %s 2>/dev/null", \$2)); skip = 1;     if (!skip) print \$0; skip = 0;  ' < /etc/ld.so.conf   $SED -e 's/#.*//;/^[   ]*hwcap[    ]/d;s/[:,  ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;/^$/d'   tr '\n' ' ' 
./intltool-extract.in:        system ("mkdir -p $dirname");
./intltool-extract.in:        system("mkdir tmp/"); 
./debian/gbemol.1:the \fBDebian\fP system (but may be used by others).  Permission is 
./debian/manpage.sgml:      the &debian; system (but may be used by others).  Permission is
  ===== sbo-run-clang.log warnings =====
update-binfmts: warning: unable to close /proc/sys/fs/binfmt_misc/register: Invalid argument
update-binfmts: warning: unable to enable binary format python2.6
dpkg-source: warning: extracting unsigned source package (gbemol_0.3.2-2.dsc)
dpkg-buildpackage: warning: using a gain-root-command while being root
gbemol-preferences.c:483:13: warning: 'gbemol_preferences_load_spin' defined but not used [-Wunused-function]
gbemol-net.c:60:11: warning: variable 'res' set but not used [-Wunused-but-set-variable]
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libfontconfig.so.1 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libatk-1.0.so.0 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against librt.so.1 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libgio-2.0.so.0 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libcairo.so.2 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libpango-1.0.so.0 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libpangocairo-1.0.so.0 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libfreetype.so.6 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libpangoft2-1.0.so.0 (it uses none of the library's symbols).
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe
     + add misc-depends to fix lintian warning.
  ===== sbo-run-gcc.log warnings =====
dpkg-source: warning: extracting unsigned source package (gbemol_0.3.2-2.dsc)
dpkg-buildpackage: warning: using a gain-root-command while being root
gbemol-preferences.c:483:13: warning: 'gbemol_preferences_load_spin' defined but not used [-Wunused-function]
gbemol-net.c:60:11: warning: variable 'res' set but not used [-Wunused-but-set-variable]
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libfontconfig.so.1 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libatk-1.0.so.0 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against librt.so.1 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libgio-2.0.so.0 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libcairo.so.2 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libpango-1.0.so.0 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libpangocairo-1.0.so.0 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libfreetype.so.6 (it uses none of the library's symbols).
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/gbemol/usr/bin/gbemol was not linked against libpangoft2-1.0.so.0 (it uses none of the library's symbols).
dpkg-gencontrol: warning: File::FcntlLock not available; using flock which is not NFS-safe
     + add misc-depends to fix lintian warning.

Not as interesting as it can get, but still pretty cool. Andrea, I swear I m not picking on you :) More to come later (hopefully) :)

One week. One long week. One beautiful week. One of the two major weeks of the year has passed since my previous post. Surely, we are in the middle of the two Major Weeks of the year, in the yearly schedule I have upheld for almost(!) ten years: DebConf+DebCamp. Yesterday, DebConf officially started. For the first time ever, we had a DebConf track targetted at the local (for a wide definition of local: All of the Central American countries) communities, which I chaired. We had the following talk lineup during this track:

• Empaquetando software para Debian (Gunnar Wolf)
• Introduction to Debian translation workflow and processes (Christian Perrier)
• OpenPGP discussion and skillshare (Daniel Kahn Gillmor)
• Empaquetando colaborativamente con git y collab-maint (Ulises Vitulli)
• Uso del sistema de manejo de errores de Debian (Hector Colina)
• Building free software communities (Leandro G mez

I believe it was a great success, and I hope the talks are useful in the future. They will be put online soon thanks to the tireless work of our work team. Today we sadly lost the presence of our DPL due to very happy circumstances he will surely announce himself. But DebConf will continue nevertheless - And proof of that is our anual, great, fun and inviting Cheese and Wine Party! After a series of organizational hiccups I hope nobody notices (oops, was I supposed not to say this?), today we had a beautiful, fun and most successful cheese and wine party, as we have had year after year since 2005. As many other people, we did our humble contribution for this party to be the success it deserves. There is lots of great cheeses, great wines, and much other great stuff we have to thank to each of the individuals who made this C&W party the success it was. Yes, it might be among the least-academic parts of our conference, but at the same time, it's one of its most cherished -and successful- traditions. And above all else, we have to thank our Great Leader^W^WCheeseMaster (who we still need to convince to play by our Great Leader's mandates - And no, I don't mean Zack here!) Hugs and thanks to my good and dear friend Christian Perrier for giving form to one of DebConf's social traditions that makes it so unique, so different from every other academic or communitary conference I have ever been part of. We still have most of the week to go. And if you are not in Managua (and are not coming soon), you can follow our activities following our video streams. Remember, debian/rules, now more than ever! And even given the (perpetual) heat in Managua: Wheezy is frozen, whee! [ all photos here taken by regina ]

Attachment	Size
100_2110.JPG	1.53 MB
100_2119.JPG	1.49 MB
100_2121.JPG	1.52 MB
100_2135.JPG	1.49 MB
100_2144.JPG	1.11 MB
100_2146.JPG	1.53 MB
100_2145.JPG	1.08 MB
100_2122.JPG	1.51 MB