It's a bit strange. Still. Writing this personal part of my blog, opening some of my most inner thoughts to the wild public. Though, so wild it doesn't seem to be. To be honest I can't remember having received any bad feedback on my personal stuff, only positive, supportive ones. (Or, there was one. Though, it wasn't related to the core of the personal section but someone thinking it would be "cool" to misinterpret some statement therein and try to hurt me with it. It only made me laugh at them, trying to "use" it as an argument.)
No bad feedback might be related to that I don't have comments enabled because I don't want to have a moderation system that would make it look like I filter out bad comments but I also don't want to open it up to SPAM. And people who propably usual leave scathing comments don't consider it convenient to address me directly, via any IM system, including emails. Anyway, opening in that way has quite some benefits: For a start, it helps me myself to keep track of things that happened. Secondly, it hopefully helps others that are in similar situations to see that they aren't alone out there and that one can survive with not hiding it. But last but not least some people address me and provide me with interesting links on the topic. I think they shouldn't be just hidden in my personal mailbox so I am going to offer them to a broader audience here. I won't show the names of who sent them along, I'm not sure if they would like being connected to the topic. But they can be assured of my blessing for offering them to me. First link I like to hand out is an article from advocate.com about a pregnant husband. Yes, this was no typo and the reason why I haven't posted it right the next day because I received that link on March 31st. I can just wish all the best to Thomas, Nancy and their yet unborn girl. Looking forward to see baby photos. :) The second article I got sent lately is When Girls Will Be Boys. It is about the transition story of Ray and acceptance problems. Pretty long but definitely worth reading. Again, thanks to the people who offered me the links to the articles, I truly appreciate them—and I hope some of the people reading my blog will too, or at least that it might change their perception and opinion on "such people".

Quite some time back, I wrote about my disappointment that Ampad had ceased manufacturing their Quad Ruled Steno Books, which I use to make notes to myself on just about everything. Several of my friends in Europe responded that similar pads in A5 size were commonly available in retail stores, and I quite happily bought a few on a trip to Germany. Then, one of my colleagues at work had some nice notebooks made up for a customer event with grid paper and suitable logos on the cover that I grabbed a few of and have used quite happily. Sometime in the intervening years, Ampad started producing these pads again, but with a different product number, 42036. I stumbled over some at a local office supply store and bought a big pile... others have noticed too, and sent me email about it, which is why I'm taking the time to write this... Yes, I'm much happier now!

I do very little law-firm-life blogging here, although that life is where I spend the overwhelming majority of my time. Consider Real Lawyers Have Blogs (something of a misnomer — they mean real firms have blogs). Counterpoint: Be Careful What You Post (motion to amend to assert defamation counterclaim against new defendant for comment on blog entry granted). In any event, in case I have any law firm associate readers, I’ll send props to the ABA’s free Litigation Podcast. It has a high signal to noise ratio, and the episodes are usually short enough to complete in my walk to and from the train. I’d like to draw attention to the latest post (”cast?”), The Secrets of Superstar Associates (21.1 MB MP3). Although on some level the advice should seem obvious, the “rules of the game” are seldom spelled out so clearly. I recommend it to any law students looking to join a firm and junior associates as well. In fact, even if you’re not a lawyer, much of the advice is transferable to surviving in any highly-skilled-professional organization. Technorati Tags: ABA, American Bar Association, Litigation Podcast, Law Firm

Share This

As outlined some days ago, patience is a requirement. That said, I'm glad that all things come to (s)he who waits, Lufthansa hardware finally landed! Ganneff, already very busy with his well-known DAM and ftpmaster hats, managed to also handle shipping some hardware donated by the Lufthansa some months ago. pkg-games was promised a powerful box, look: Pentium 4 (2400 MHz, 1024 MB); we will finally be able to try and provide backports in a semi-automated fashion, so as to ease stable users' life, when it comes to installing bleeding-edge versions of their favourite games! Thank you for making this possible and keeping everyone posted about the status of that hardware donation. Hopefully, it'll be possible to also communicate through bits of the DAMs , as suggested some weeks ago on debian-newmaint@. Yay for communication! \o/

Last week I went to Puerto Rico to take my so-called spring break to visit my mom. I expected a semi-relaxing visit as her caretaker, Milagro, would be around and I also expected one last visit with my mother before embarking on the difficult process of moving her into a nursing home, which I planed to do over the summer. But a day and a half after I arrived, we brought her to the hospital because she basically had stopped eating and even drinking water and now that she has been released from the hospital, she has been placed in a nursing home. We brought my mom to the hospital because she was malnourished and dehydrated. To admit her was an exercise in managing a fireball of pure fury. Even if she was weak, she mustered every last piece of her energy so as to transform herself from a little old lady to a little old lady of pure Russian terror, unleashing her wrath left and right, not to mention up and down. But well, thanks to her (I think, somewhat calculated) wrath, at least they took her in immediately (despite a truly truly packed packed emergency room). Once inside, it took 4 nurses and her caretaker to put the initial IV in her arm and then they threw in a little haldol to calm her down. We waited nearly a day to find out that her doctor, Dra Nazario ordered a feeding tube without consulting with me or my sister (of course at some point they would need consent). At first I did not want a feeding tube put in her. But after talking with various nurses and other family members in the hospital with parents with Alzheimers, I decided to go for it. It is clear that my mom just does not eat enough and when she does, she eats poorly and I did not want to go through another traumatic visit in the emergency room at some future date to do the same. After her operation and after a few days of getting food, she was conscious but barely so. She did not want to talk, did not seem to be able to talk, and this of course, was heartbreaking because we thought that the operation, 4 days without food, and the really difficult hospital entry did her over. But once she developed slight pneumonia and an UTI, funny enough, she actually came back to life pretty much as she was before the hospital (which is still pretty limited but at least she did not seem any worse and it will be interesting to see what happens after she gets proper nutrition for a few weeks). So in the last 9 days I spent a lot of time in the hospital, more than I have ever spent in one. Let’s face it they are creepy places and exude a low-level, sometimes higher grade level of architectural and atmospheric grossness. The smell is so distinct: part disinfectant, part something that I can only describe as that of pre-death (or pre-rot), a smell that especially lingers for it co-mingles with the palpable sense of anxiety and worry (and tiredness) that family members carry with them. I took my mom to Hospital Pavia, which is supposedly one of the better hospitals in the San Juan metropolitan areas, and like 3 minutes from my house. And generally things were orderly and run well but there were a few times, when I was floored and beyond livid by they way they treated my mother and it is clear that a hospital is only as good as the doctors and the ability of the nurses to carry out their orders correctly. (more…)

El Reg reviewed the Archos 705 yesterday. They only gave it 50%, which I think is a little harsh. I bought one of these back in November when they first came out, as something to help easy my daily commute by train. I have to say I don't regret the purchase; while there are various niggles that annoy me it basically does what I want. My main drive was the size of the screen. There are plenty of options available if you want in the region of 4", but I wanted something bigger that could still be shoved in a bag without any hassle. The 705's 7" screen is great. I can sit it on the tray table on the train and it gives a clear viewable image that doesn't leave me squinting trying to see it. The second concern was the battery life. At 7" you start to get into the UMPC area. However there didn't seem to be anything around that both offered enough battery life and had the grunt to decode DivX. I need a guaranteed 2hrs (ideally a bit longer) so I can watch something without being interrupted. I've certainly had over 3hrs on the Archos and various reviews claim it'll do 5hr for video without problems. Archos call the 705 a DVR. I've no idea why; I certainly wouldn't consider it one. I have the DVR station, but I've only used it to connect the Archos up to a hotel room TV and never for actually recording anything. There's no tuner (neither analog nor digital), so you need a Freeview/cable/satellite or similar box to provide a signal. Plus it seems pointless to convert a digital TV signal to analog and then for the Archos to have to re-encode it. Much more sane to record TV on your PVR and pull the file off that and onto the 705. Except there you hit a bit of a problem. By default the Archos supports DivX and WMV. To get MPEG2 or H.264 support, or indeed AC3 audio, you need to pay extra for a license that will enable the appropriate codec. This is annoying and I've ended up just using mencoder to convert Freeview records to an Archos friendly format rather than shelling out more for the codecs. Archos do seem to have dropped the ball here. The MPEG2 license fee seems to be $2.50 per device. The TI licensing seems to be about $2 for MPEG2 + AC3. Archos sell the plugin for €19.99. I doubt AC3 licensing is over $15, which rules out Archos merely keeping the cost down for customers by allowing them to pick and chose which codecs they want to avoid paying license fees. The 705 also comes with a web browser. Which, of course, you have to pay for. I ended up getting this thrown in with my 705 + DVR station bundle. It's powered by Opera and reasonable enough. The only time I've really made use of it is while staying in a hotel; it was quite nifty to have the 705 hooked up to the TV and be able to lie on the bed with the keyboard remote control and lookup film times or interesting places to go. Internet access is provided by wifi; if it had bluetooth as well then I might make use of it on the train, but as it is it's not really something I use much. As I said at the start I'm still happy with my purchase. It's not a cheap item, but it has the screen size and battery life I wanted and there wasn't a lot else out that offered both. Having to pay for codecs is a bad move on Archos' part, but I've avoided doing so by re-encoding. If you want something that's a decent media player of this size then the 705 is definitely worth considering; if you're not sure about the size aspect you may be better off with a 605 (the 4.3" screen version) or even something from Cowon (who unfortunately don't seem to have anything in the 7" range). Finally, if you already own a generation 5 Archos device, you might be interested to know that shell access has been obtained. The device is pretty locked down (signed kernel modules, no /dev/mem, signed root cramfs filesystem), but there's an arcwelder exploit to get an ssh login over wifi and an Archos Hacking forum on Archosfans.

Random things you can't do without being a DD (and no, DM isn't the answer).

• Access porter box to try and reproduce build failures, test patches (I know about experimental, but building isn't sufficient in some cases, e.g. when runtime errors come into play).
• Introduce NEW packages on your own (Christian, you know I'm pointing to crappy packages to get them removed, so my karma shouldn't be that bad, at least regarding this particular point).
• Sponsor people you're working with, on a regular basis.
• More generally, sponsor people who have addressed each and every problem you could find in their prospective packages, and that aren't getting any more answer on debian-mentors@.
• Vote.
• Cancel by yourself a DELAYED/n NMU in case the maintainer reacts and has good reasons to postpone an upload, without having to bug the original uploader (who also has stuff to do and sometimes happens not to be available in due time).
• Access interesting data directly, like the cause of previous REJECTs for this or that package.

Being able to read debian-private@, having a nice^Wspammed @d.o address, or getting an lwn access could be added here, but that's only bonus stuff compared to the previous items (and I'm probably forgetting others). Oh, yeah, I know, patience is the key. I'm not sure about how many months we're supposed to wait for an answer from James. I'm not sure how many years we're supposed to wait for the various DAM problems to be solved. Lucas is very worried about bringing fresh blood into Debian. Maybe there's some already, but it's not allowed to flow in. Many thanks to all developers who are making it less frustrating by doing mass-sponsoring; and to everyone showing sympathy. Not listing you all, you know who you are.

Today, while working on an l10n NMU for a package (gnarwl), I got magic lintian complain about "missing dependency on libc". And, indeed, that package provides C binaries that are linked against the libc...but does not depend on it. This is because the package has "$ shlibs:Depends " in Depends but does not run "dh_shlibdeps" in debian/rules. That bug will soon be fixed by my NMU but aren't most of the package who have the same lintian warning in the same situation?

In June last year, I bought a TomTom GPS device. Their use of Linux on the device was a clear plus in their favour, but it was only that, given that overall they’re the best devices available. Unfortunately, the TomTom HOME software that is needed to manage the device is not as good as the device itself. An account on their website is needed for updates and the online shop, and as I usually do, I used an email address in the form jb+something@jblache.org. That’s a trick most of us use to trace back the origin of spam, usually revealing that some company sold its customer database. I’ve been doing that for years. I was quite happy that the website did not reject the address as being invalid; that’s something that happens everytime the random web developer maintaining the site decides to start “validating” email addresses, for some value of email addresses. For the following 8 months I’ve been using this address as the account login (don’t really have the choice, anyway) with the TomTom HOME software. Last month, the v2 of the said software was finally made available for Mac OS X. Where the v1 used to accept my email address, the v2 would now reject it. You guessed it, Joe Random developer decided to start validating email addresses in TomTom HOME. I reported the regression (and here, something must be said about their infamous support website), with pointers to the relevant RFCs. In the following email ping-pong, they managed to:

• Pretend the password was the problem. I have to say here that the software displays a big red “invalid email address” next to the email address field as soon as I enter the + character. No mistake possible here.
• Send me my login and password, in clear text, when I never asked for that. That also means they’re storing passwords in clear text. IT’S 2008 FOR FUCK’S SAKE! STOP STORING CLEAR TEXT PASSWORDS, DAMMIT.
• Pretend their email platform is the most secure in the world. Ever heard of SSL? TLS? Clearly not.
• Pretend it’s not a regression in the v2 of TomTom HOME. We’re not speaking the same language, it seems.
• Pretend the email address is invalid. No surprise there, but it’s clear they did not bother reading the fucking RFC.

Last but not least, their last reply was: “we found that the standard does not apply to us. Please change your email address for a valid one.” Now, I’m left wondering: does the GPS standard apply to TomTom devices? I truly hope so.

Today, after Cyril Brulebois, and Sylvestre Ledru, Kumar Appaiah contacted me with ready NMUs that I sponsored right away:

• #462540 for enigma
• #455680 for python-visual

About my work:

• #452718 was downgraded as it's unreproducible with the latest fontconfig.
• #468226 was closed, as it's not really a bug (all git contributions are signed-off-by their authors per upstream policy).
• #466984 was closed, for being invalid (though one could argue that kiosktool UI sucks too).

Though, python-central had the brilliant idea to generate ~35 FTBFSes, so this week of RC-Bug-A-Day balance isn't brilliant: On the other hand, we're almost under 100 g++-4.3 FTBFS, wich is a third of what it was 10 days ago, good job people !

Programs themselves cannot be patented. They're explanations of mathematical relationships, not inventions. Paul Russell mentioned this ruling to me and Alex Hudson mentioned it to fsfe-uk. There's been some BBC coverage and very silly coverage in Computing which summarises it as as

"Symbian's win could benefit UK software makers"

You what? Shouldn't we be enabling other UK companies to compete in a free market with Symbian, which is a consortium of foreign companies after all, instead of granting Symbian a monopoly here? *fume*

Italian National Anthem Christian mentions that he likes the Italian National Anthem, although not the words. No Italian in their right mind likes the words; luckily we are generally not forced to learn them, so we can allow ourselves to not give a damn about it. Which is our general strategy to deal with all the insanity we get every day. What's the point of a nationalist anthem anyway, when the people who care most about the country are wishing for the Germans to invade us? Anyway, here's my attempt at national anthem lyrics that suck less, for the benefit of those, like Christian, who like the music but not the words.

Fratelli d'Italia
L'Italia s' desta,
Chi cazzo sto Scipio
Che ci han messo in testa.
Non c' la Vittoria
che porge la chioma,
Siam schiavi di Roma
E del Vatican.
Scongiuri alla sorte
Si rischia la morte
Si spera di no.
Noi siamo da secoli
Calpesti, derisi,
Perch siam mafiosi
ladroni e collusi.
Si rischia di nuovo
di aver Berluscone
Dell'emigrazione
Gi l'ora suon .
Scongiuri alla sorte
Si rischia la morte
Si spera di no.
Uniamoci, amiamoci,
l'unione, e l'amore
Ridanno alla gente
Il suo buonumore;
Giuriamo far sesso
sul suolo nat o:
Chiaviamo, perd o,
Chi dice di no?
Scongiuri alla sorte
Si rischia la morte
Si spera di no.
Dall'Alpi a Sicilia
Noi ti condoniamo,
Ogn'uom di Bettino
Ha il core, ha la mano,
I bimbi d'Italia
Fan calcio balilla,
Bastardo chi frulla
Gancin non si pu .
Scongiuri alla sorte
Si rischia la morte
Si spera di no.
I nostri politici
Son tutti venduti:
Si sente dall'Austria
L'odor dei rifiuti.
Lavora in Italia,
Il nero, il Polacco,
In nero, perbacco,
Io lo pagher .

Scongiuri alla sorte
Si rischia la morte
Si spera di no.

The recent IPv6 Conference at Google and the launching of ipv6.google.com (only accessible over IPv6) inspired me to set up a 6to4 tunnel on my WRT54G running OpenWRT. I've been reading about IPv6 for years, but there didn't seem to be much point. Now I've seen the bouncing Google logo and the dancing turtle, and it really wasn't all that difficult. One issue I ran into was the 2.4 kernel that is needed to run on the WRT54G doesn't have a connection tracking for stateful firewall rules, which makes it a pretty poor IPv6 firewall. It's disabled for now, and tomorrow I'll go buy a WRTSL54GS so I can run a 2.6 kernel.

I'm looking forward to the day when IPv6 transit is normal and all these tunnels are unnecessary.

Over the last days I have moved my email and web and stuff from a simple web and email hotel to a virtual server managed by me. So now I got a nice setup with

• Exim mailserver, smtp auth for sending
• Dovecot imap server
• roundcube webmail
• apache2 serving my blog and stuff

But most important for me: I can write my own spam filtering rules serverside and I can easily make sure all passwords are sent encrypted. What’s left on my todo, partly because I haven’t figured out how yet is

• Have exim not show the first recieved line when sending mail. No reason to put the IP of whatever place I am located into the emails
• Have exim rewrite the Subject: header of spam emails, not add a second Subject header
• Some kind of public/shared folders in dovecot
• Have moved my local pop3 kmail filtering rules over to exim filters

And I also still haven’t moved all my domains, but it is coming soon.

Today a customer asked for hosting several domains with different content on one apache virtual host. The little tricky part was, that the sites should not be accessed by subdirs like http://domain20.org/subdir20/ and http://domain21.org/subdir21/ which can be done with a little script which parses the $_SERVER[’HTTP_HOST’]. So mod_rewrite is an option.
To make it user accessable, we use .htaccess. This requires “AllowOverride +FileInfo” to be set for the DocumentRoot in the vhost config. The .htaccess in DocumentRoot could look something like:

RewriteEngine On
RewriteBase /
RewriteCond % HTTP_HOST domain10.org$ [OR]
RewriteCond % HTTP_HOST domain11.org$
RewriteCond % REQUEST_FILENAME !dir1/
RewriteCond % REQUEST_FILENAME -f [OR]
RewriteCond % REQUEST_FILENAME -d
RewriteRule (.*) dir1/$1 [L]
RewriteCond % HTTP_HOST domain20.org$ [OR]
RewriteCond % HTTP_HOST domain21.org$
RewriteCond % REQUEST_FILENAME !dir2/
RewriteCond % REQUEST_FILENAME -f [OR]
RewriteCond % REQUEST_FILENAME -d
RewriteRule (.*) dir2/$1 [L]

I was recently forced to face once more the limitations and quirks of rpm. This is more painful, when looking at a more capable system like .deb.

When building a .deb package, the debian/rules file is pretty much the heart of all things happening, with debian/control and debian/changelog as the lungs and the liver(? maybe) .

Having different files for the maintainer scripts makes possible things like automatic (but repetitive) generation/modifications of those scripts. This can be useful in some situations when the postinst should do stuff depending on the current contents of the released upstream source (sorry, I know I am being vague, but I can't detail too much). The source package is then generated and the resulting package can be rebuilt 1000 times and the resulting postinst will not be different for a given release. But this is always done in the same way, no matter the upstream version.

Fatality one - the spec is fixed, saint, but still can be altered... still, not in due time

So the basic idea is to have postinst.in as a source for postinst, which is created during the configure stage and later removed on clean. This is possible and works on deb.

Try the same on rpm and you will fail. This is because, although the spec file supports file inclusions, the altered files are merged into the spec right at the beginning of the build process, and you end up with no or an outdated postinst. A later rebuild of the same package would do the trick, but that is wrong for more than one reason.

Fatality two - why fatality one was met

All of this is made in order to overcome yet another rpm limitation: rpm can't assist too much on upgrades; you can't simply upgrade packages properly from one version to another, because rpm doesn't have the notion of letting the scripts know which version is installed over which; it only tells that it is an upgrade or not.

This has lead some people believe rpm isn't able to upgrade at all. Glad to tell them they're wrong (still rpm sucks and is brain dead).

Fatality three - why rpm based system fail to have upgrade support today

Want another RPM limitation? RPM has this brain dead idea that on upgrade the "proper" order and way to call the maintainer script(lets) is:

• new-preinst 2
• new-postinst 2
• old-prerm 1
• old-postrm 1

The numbers 1 and 2 are literally what is passed to the scripts and mean "the number of the installed versions of the same package that will exist after the current operation finishes". No versions of any kind, no other parameters, no rollback, no nothing, just 1 or 2.

And by letting the scripts of the old version run AFTER the scripts of the new one means that you have to explicitly prepare the packages for a later upgrade support (and the best idea is to do NOTHING in the old prerm and postrm scripts on upgrades, since nobody is clairvoyant to see what would be the right course of action for upgrade in future releases).

More bad ideas from the rpm land (glad not to be there)

In somewhat related news, the fedora people are discussing now around the rejection of being able to have package names contain non-ascii characters, characters like kanji, kanas, cyrillic characters or any other characters. Even if I am pro-l10n, this wreaks of bad idea scent from a mile afar.

They aren't probably aware that even unicode is broken (if you see the same glyphs in the comparison table, that is proof unicode is broken) but that is their decision and I am glad I am not in that lost land.

vmware-package 0.22 was just uploaded, which supports the just-released versions of vmware workstation / player / server. most of the changes went to dealing with the newly sensitive dpkg-shlibdeps(1).

awesome:

Index: trunk/share/vmware/debian/rules
===================================================================
--- trunk/share/vmware/debian/rules     (revision 57)
+++ trunk/share/vmware/debian/rules     (revision 63)
[...]
+       # stupid stupid stupid stupid stupid
+       ln -sf libcrypto.so.4 debian/vmware-server-mui/$(lib_dir)/lib/libcrypto.so.0.9.7
[...]

ugly ugly build logs for 5 upstream packages x two suites x two archs are here:

http://people.debian.org/~edmonds/vmware-package/build-0.22.etch-amd64.txt
http://people.debian.org/~edmonds/vmware-package/build-0.22.etch-i386.txt
http://people.debian.org/~edmonds/vmware-package/build-0.22.sid-amd64.txt
http://people.debian.org/~edmonds/vmware-package/build-0.22.sid-i386.txt