So going alone to the cinema yesterday was not a first, but going alone and being alone in the room certainly was, and an unexpected one.
This was, as far as I know, the premiere in Alicante of Enloquecidas, which is certainly not that of a remarkable film, but which was entertaining enough, and provided some very good laughs.
What is wrong with this city?!
(Update: hm, seems I’m mistaken about the “premiere” bit. Oh well.)
Posted Sat, 17 May 2008 13:58:47 +0200Unlike Steve, I don’t particularly mind going to the cinema alone. In fact, it’s becoming a growing habit for Friday nights, when my friends go to some meetings about their faith I don’t participate in (nor their meetings, nor their faith). I really hate getting home early on Fridays, so I take chance to go to movies I know we wouldn’t be going together anyway.
(Oh, and in case I haven’t said here already, the movie offerings in this “city” suck big balls. Virtually no undubbed sessions, virtually no non-mainstream movies. I don’t think I’ll still be here in a couple years, but boy would I be unhappy if the circumstances forced me to.)
Posted Fri, 16 May 2008 20:55:08 +0200Here in this library, next to a couple computers available to query the catalog, a sign reads:
Do not connect your laptop to these jacks. You may loose all data in your computer.
If I wasn’t a computer-savy person, I’m completely sure I would’ve thought: “They’re bluffing.” And then shit happens, because they’re not.
(Oh, but then of course the sign is not 100% honest either.)
Posted Fri, 16 May 2008 20:20:14 +0200One of the people who most fiercely fought software patents here in Spain and Europe jokingly (?!) uses the word “fag” to insult random people he dislikes. (But so do tons of other people I don’t interact with, of course.)
I used not to be annoyed by this at all, but tonight I felt differently, and it really bothered me (possibly because it was somebody from my community who did it). Life is easier when you don’t care, I guess, but I think it’s a good thing that I care now, since without such caring things can’t and won’t change.
Posted Sat, 10 May 2008 04:20:46 +0200As I mentioned, this week I’ve been in Sevilla as a finalist for the 2nd edition of a Free Software contest. Each participant at this stage made a presentation of their project, and this afternoon the winners were disclosed. I’m happy to share that Minirok won the 1st prize in its category, yay!
Also, Dudesconf was simply terrific — I’m so happy I could attend this year. And, as for every conference, eternal gratitude to the organizers: people from GPUL, you simply rock!!
Posted Fri, 09 May 2008 19:42:53 +0200These last two weeks most of my time has been sucked into getting Python 2.5 as default into testing. That’s done now. I made use of the block uploads thingie ftpmaster implemented for the release team to use. Basically, if your package could disrupt an “almost there” transition, the upload will be rejected.
The blocks were in place for 5 days, which I think it’s acceptable. As long as we don’t end blocking stuff for very long, I think we should be fine. See the end of this post for more about this.
Though it was quite a bit of work, I’m very glad I took care it myself, since now I really feel I’m 100% back to Debian, after the time I spent off for health reasons.
Update: Oh, and I forgot to say: having control over britney has really really helped. Thanks a lot Joerg for that.
Dudesconf
Tomorrow I’m leaving to Coruña for Dudesconf, which is a kind of Debconf-ES. I’m giving an introductory talk to Git, a semi-lighting talk about grep-dctrl (30 min.), and (gasp) a talk about Debian packaging with a VCS. We may have a Debian Quiz as well.
I’m so looking forward to it, since many people who’ll attend are amongst my most loved ones, and I already missed last year’s since I wasn’t fully recovered yet. See you there!
Minirok and Sevilla
One of the reasons I wasn’t fully back to release management during the past 5 months or so is because I spent as much time as I had doing development for Minirok. I don’t think I mentioned here before, but I was participating in a Free Software Contest for college students organized by the University of Sevilla, Spain. Such effort finally paid off, since Minirok was elected as one of the finalists.
This means next week I’ll go to Sevilla, to make a presentation of the project, and who knows what more. ;-)
I’m very excited.
Finally, more on blocking uploads
This Python 2.5 transition was the first time the block uploads feature was used, and there were a couple bumps along the way. In particular, a couple packages were blocked, when they shouldn’t have been (libqt4-ruby and evolution-sharp), and one needed package was not blocked, though Rene Engelhard thankfully spotted it very quickly (mono).
The problem is it’s not completely straightforward to generate a list of all the stuff that could possibly affect the transition. What I did was to make a run of britney on an arch that had all the needed bits in place, and block all the packages that migrated together as a result of the hint.
This fails in two ways:
it can include stuff that is not needed for the transition, namely unrelated packages that happen to become candidates for testing by one of the their dependencies having migrated as part of the hint. This is what happened with libqt4-ruby and evolution-sharp.
it can miss stuff that is needed, like packages that can migrate by themselves, so the main run prior to the hint migrates them, and hence do not show up as part of the hint, but that some package of the transition depend on. This is what happened with mono.
The second problem, though, can be fixed by parsing the excuses list and blocking stuff that some bits of the transition depends on. Easy enough.
Yet, there are more cases when things can go wrong, for example a shlibs-bumping upload of a package (say, sqlite3) linked against by some package still needing a couple of builds (say, qt4-x11).
For that, blocking uploads is not an option, since that’d be an insane amounts of packages that, furthermore, can be uploaded if they don’t bump shlibs, so I guess we’ll have to ask in the next release update that shlibs-bumping uploads are coordinated in -release too, at least when close to finishing a transition.
Posted Wed, 30 Apr 2008 18:41:37 +0200Yesterday I watched Les invasions barbares, a film by Canadian director Denys Arcand. I came to find it because one of my favourite cinemas in this oh-so-small city was premiering L’âge des ténèbres, the third part of a trilogy started by Le déclin de l’empire américain, and continued by Les invasions barbares above.
I loved Les invasions barbares. I think it’s a very honest film, but for me not only it portrayed a reality and set of characters that I found credible, I also felt empowered by watching attitudes towards life so compatible, if not similar, to my own. Reminds me a bit of some of the feelings I had when watching Juno.
It is also one film more to add to my (smallish) collection of films I’ve watched in French (with subtitles), though I’m intending to fix that: I really enjoy French, as well as enjoyed all Canadian or French I’ve watched in the past. We’ll see how it goes.
Posted Fri, 18 Apr 2008 11:58:37 +0200Sometimes, I’ll accidentally set my music player into “repeat track” or “repeat playlist” mode while working (my playlists are normally short, btw, one album or so).
The funny bit is the number of times the track or playlist needs to be repeated in order to get me to notice. Not that many, but interesting nevertheless.
Posted Tue, 15 Apr 2008 17:36:25 +0200By pure chance I read somebody mentioning giggle in #git. It’s a visualizer for git branches written in C using GTK+. I find the output a bit nicer than that of gitk, at least on some repos. As Mike Hommey points out, though, it’s quite slow on medium and big repositories.
P.S.: It’s packaged for Debian.
Posted Wed, 09 Apr 2008 11:16:21 +0200Unlike Martin and Daniel, please do call me by my IRC nick in real life, mostly because that’s what I’ve been called by everybody since I was 0.
On writing the long version is ok.
Posted Fri, 04 Apr 2008 14:41:27 +0200I had never seen a prank upset so many people. On the other hand, almost 50 people (blindly?) said thanks!
Posted Tue, 01 Apr 2008 20:24:55 +0200I knew I liked to make my shell aliases short, but I wanted some statistics (FSVO “statistics”). With a simple pipe:
% alias | sed -e 's/^alias //;s/=.*//;s/././g' | sort | uniq -c | sort -rn
27 ....
25 ...
20 ..
12 .
11 .....
7 ......
6 ........
4 .........
2 .............
2 .......
1 ...................
This means 2-4 character aliases are the most common (surprise, surprise), followed by 1-character aliases, of which I have (oh god) 12.
That’s 117 aliases total...
Posted Fri, 28 Mar 2008 09:46:53 +0100This is fairly obvious in theory, but it’s the kind of thing you don’t always think about: when receiving patches via e-mail, it’s possible to have Mutt directly color them as vim or colordiff(1) does. I have this:
% grep rc_diff ~/.muttrc
macro index \e,sd ":source ~/.mutt/rc_diff\n" "source ~/.mutt/rc_diff"
macro pager \e,sd ":source ~/.mutt/rc_diff\n" "source ~/.mutt/rc_diff"
% cat ~/.mutt/rc_diff
color body brightblue default '^\+.*'
color body brightred default '^-.*'
color body brightgreen default '^(---|\+\+\+) .*'
color body brightyellow default '^@@ .*'
Update: In case there was some confusion, the rc_diff snippet above is meant to be sourced only when there’s a mail with a patch, otherwise it’ll highlight parts of normail email too. The way to disable again, though, is quitting Mutt...
Posted Sun, 23 Mar 2008 15:28:34 +0100Good: Probably because of its origins, there seems to be a higher willingness to write detailed commit messages in the Git community when necessary. I feel like at home.
Bad: I really miss the distinction between mainline revisions and merged revisions. I guess that if they had that, there’d be less urges to rebase and squash all over the place.
Posted Fri, 21 Mar 2008 16:15:26 +0100I tend to favour text-mode applications (I’m sure vim, irssi, zsh and mutt account for most of my keystrokes, in that order), but there are times when a graphical application is called for, for example the browser. Or when I just find it more convenient, for example the music player.
Lately, though, I’ve been pleasantly surprised by a couple graphical
applications, for which I had text-mode versions which worked more or
less acceptably: a random-note taker (I was using vim), and a dictionary
(/usr/bin/dict).
I’ve replaced these two with Lars’ Notetak, and StarDict. I’ve found that having them constantly running in desktop #2 (which is one keystroke away) beats having to start up vim or dict each time. Curiously enough, in both cases the main interface of the application is a text input line which offers some kind of “incremental search” functionality.
StarDict is packaged in Debian (package name stardict-gtk or stardict-gnome), and Notetak, being Python, is easy enough to run from source (the page claims there is a Debian repository there, though I can’t access it).
Posted Fri, 21 Mar 2008 14:52:34 +0100Via Planet Warp, Blaxter blogs about MyEpisodes.com. Useful to keep track of your pending episodes to watch and acquire. I like the “All-In-One!” view.
Update: Oh, and as several people mentioned, there is also pogdesign.co.uk/cat, but that’s only a calendar of upcoming episodes, you can’t track your status with it AFAICS. OTOH, it doesn’t require a login, only a cookie.
Posted Wed, 19 Mar 2008 13:15:45 +0100I’ll blush and admit that I’ve always been a bit of the “my package my castle” type. But things change, and now I feel differently about my packages.
I toyed with the idea of adding myself to the low threshold NMU list, but it didn’t make me very happy for several motives:
first and foremost, it places emphasis on the upload as the basic unit of collaboration, whereas I think such unit should be the commit
places the information on a network location, whereas I think the information should be more readily available and near the package itself
uses “non-maintainer upload” to describe itself, which is already something else
Then there is the collab-maint project in Alioth, which is nowadays intended as a general purpose area for small teams or groups of co-maintainers to collaborate in their packages, without needing to create a full-fledged Alioth project. Every DD and many non-DD have write access to it, but a package being there does not mean that its maintainers want other people to use such write access on their packages. But, alas, there is no standard way of saying that you do want people to make use of that access, and how (of such way could also benefit projects that make use of the Debian acl, to advertise the fact).
So, as a first draft to fill in these gaps, I’ve migrated several
packages of mine to the collab-maint umbrella, and added a
X-Collab-Maint header to debian/control to signal that I’m open to
collaborations on them. For me, a header felt the best way to express
this information, since it ends up being very accessible (only one
apt-cache showsrc away). As Zack points out to me, though, having it
in a header doesn’t necessarily mean the source of the header has to be
debian/control forever (think e.g. what debtags does) — this leads to
interesting possibilities, like changing the policy without an upload,
or setting the same policy for a large set of related packages.
As for the contents of the header, I think a reduced vocabulary would work best. As a start, this is the one I’ve been using for my packages:
commit-branch: please commit your stuff into a branch, so that I can review and merge it. Other people could just use commit if they prefer commits to trunk directly.
upload-10: feel free to make an upload with your changes if I haven’t acked them within 10 days. Other people could use upload-with-ack, to signal that you’re happy for other people to upload, but that’d you like to review first. Or even upload-0.
Other stuff that’s could be specified includes whether people making a commit should notify the maintainer or not, before letting the upload day count tick. But, if the idea seems worth it, I’m sure we can debate it to death on -project, or something.
Posted Sun, 16 Mar 2008 19:04:13 +0100I uploaded amule 2.2.0~20080309-1 to experimental yesterday. It should fix the search-related crashes from 2.1.3, and be really close to the final 2.2.0 release.
Posted Mon, 10 Mar 2008 13:37:35 +0100At the moment I keep my packages in Bazaar branches. I only version the debian/ subdir (whereas I have the .bzr directory at the same level as debian, i.e. not debian/.bzr). I do that because then $VCS operations work without having to be under debian.
One drawback is that the output of status is a bit too noisy, with lots of “unknown” files (all the upstream files). I address that by aliasing bzr std to “bzr status debian”.
With git, one could just have the following:
% cat .gitignore
/*
!/debian
/debian/files
...
Update: One of the Bazaar guys, Wouter van Heyst, points out on IRC that bzr can do it as well:
% cat .bzrignore
RE:(?!debian/).*
./debian/files
...
In fact, possibly more: lines starting with RE: are interpreted as Python regular expressions.
Posted Sat, 08 Mar 2008 16:11:25 +0100So I was impatient enough and took a stab at writing a bzr frontend for git-fast-import(1). (By the way, the idea behind git-fast-import rocks, and is being adopted by other projects, e.g. bzr-fastimport.)
I announced it here, and for now it lives in:
Posted Fri, 07 Mar 2008 13:19:55 +0100http://chistera.yi.org/~adeodato/tmp/other/bzr-fast-export.git