I was just tracking down why some mails seem to have garbled Subjects.

It looked like this in Alpine:
Subject: [BOFH commits] r2040: fix directory struct =?UTF-8?Q?ure=E2=86=B5=20unix?=/mirror/=?UTF-8?Q?=20=E2=86=92=20mirror?=. bonn

The raw header sight was this:
Subject: [BOFH commits] =?utf-8?q?r2040=3A__fix_directory_struct__=3D=3FUT?=
=?utf-8?b?Ri04P1E/dXJlPUUyPTg2PUI1PTIwdW5peD89L21pcnJvci89P1VURi04P1E/?=
=?utf-8?b?PTIwPUUyPTg2PTkyPTIwbWlycm9yPz0uIGJvbm4=?=

Ein Schelm, wer Böses dabei denkt… First suspect was, of course, Mailman — after decoding, this showed the classical signs of a double-encode. (After ruling out general header brokenness, but no, 76 chars is ok.) I thus hand-crafted an eMail with the correct header line and sent that out:
Subject: [BOFH commits] =?utf-8?q?r2040=3A_fix_directory_structure?=
=?utf-8?b?4oa1IHVuaXgvbWlycm9yLyDihpIgbWlycm9yLmJvbm4=?=

Huh? Mailman and Python weren’t the culprit, thus — this is correct mangling. Okay, let’s dive into the Perl code that actually sends out the eMails. To make a long story short, have a look at this, then RFC 2047:
tglase@tglase:~ $ perl -MEncode -e '$subject = "r2040: fix directory structure↵ unix/mirror/ → mirror.bonn"; Encode::from_to($subject, "UTF-8", "MIME-Q"); print "{Subject: ".$subject."}\n";'
{Subject: r2040:=?UTF-8?Q?=20fix=20directory=20struct?=
=?UTF-8?Q?ure=E2=86=B5=20unix?=/mirror/=?UTF-8?Q?=20=E2=86=92=20mirror?=.
bonn}

Amazingly enough, PHP’s mb_encode_mimeheader, despite being talked to trash in the comments on its online documentation, does manage to get it right:
tglase@tglase:~ $ php -r 'mb_internal_encoding("UTF-8");echo "{".mb_encode_mimeheader("Subject: r2040: fix directory structure↵ unix/mirror/ → mirror.bonn", "UTF-8", "Q")."}\n";'
{Subject: r2040: fix directory =?UTF-8?Q?structure=E2=86=B5=20unix/mirror/?=
=?UTF-8?Q?=20=E2=86=92=20mirror=2Ebonn?=}

Wow. Now, the Perl guys I know told me to use Perl’s Mail tools… which are much too high-level though, for all I have and want is the subject string and an RFC 822 header line. I told them I’m not above doing this, and so I did. The 3P languages can really be annoying.

Why’s Perl’s output wrong anyway? I don’t know for sure, but I think the atoms must be separated, so unquoting /mirror/ in the middle, with no spaces around it, are wrong. (Besides, Encode::from_to can’t do the job right anyway, as it misses the name of the header, which is included in the 76 chars allowed for the first line. BAD • Broken As Desdigned.)

Disclaimer: I don’t really know any Perl, I fight my way through PHP and, barely, Python. (But I can code.)

I’m still working on mksh and doing some MirBSD core and ports work in between. On the other hand, since a lot of things suck so much, and other things become unacceptable, I’m seriously considering writing things like a libc (probably not complete, not totally from scratch — no way I’m going to code sunrpc — and not fast but at least correct. I’ve written quite some code for the MirBSD libc already, as well as kernel and bootloader. Most of it is shared between these, and I’ve digged in enough others (klibc, dietlibc, µClibc, musl, glibc) to have seen more. I was thinking of static linkage only at first, mostly for bootloader and compiler support code and, later, to link mksh statically against it on some OSes. But cnuke@ wanted a “correct” libc with dynamic linkage. Hmm… (On the other hand, we all know that these are dreams and a RL job can be time and will consuming.)

Roland Mas is hacking on Alioth this weekend, which runs code from me and some coworkers via FusionForge — more coverage ☺ I’m also doing okay with Debian/m68k (still slowly of course, but then, as BSD developer, I’m used to that *g*) and one of the old m68k buildds may very well be resurrected soonish. (Still need to port elfutils…) By the way, XHTML sucks, some things are hard to get right, and writing a DTD should be obsolete…

I took over cvs(1) in Debian and replaced it with my previously private package of MirPorts’ cvs. Way to go! (Thanks to Steve for handing over maintainership.) Now, everyone, please test it and recheck whether your old bugs still apply. Oh, and send patches. But pserver, PAM etc. are gone for good, don’t bother.

PS: It’s still Google Go, Benny. (World of Google’s goo?)

The MirOS support for pkgsrc is progressing, albeit very slowly. This is because I spend more time traveling for work than in the office. After a long day of meetings and conferences, I am no longer motivated to code in my free time. What’s more, several different projects at work have tight deadlines.

Having said this, I committed MirOS support for libtool-2.2.6b in pkgsrc the other day, after a positive review by agc. As for the bmake patch, which is still available from our pkgsrc page, I was told to redo the patch, this time for src/usr.bin/make directly. When this patch will have gone in, somebody else (joerg?) will sync pkgsrc/devel/bmake, and MirOS will be able to bootstrap pkgsrc without patches. Let’s try to get to this point before the 2011Q2 branch.

The new “showcase” machine that I bought a while ago, does not have working network connectivity and SATA under MirOS. tg@ recommended an installation into an HVM guest under Xen. I am currently trying to set this up, however I must first succeed to get a stable NetBSD Dom0 system. I am using NetBSD-current because it has the right network driver and a custom kernel, however the console seems flakey, and accessing /kern/xen (even just ls!) leaves the process hanging in the “tstile” state. pkgsrc has four versions of Xen, so I should just test them all until I find one that works.

PS: My Go package, image/tiff is now part of the standard library. Yay!

I hope I will never again have to attend a funeral for a friend who committed suicide.

That is all.

tl;dr: Full JSON encoder/emitter and decoder/parser in Pure PHP now available as part of FusionForge/Evolvis under GPLv2. Do not use PHP’s built-in code, it’s broken. Read on for details and links.

I’ve pimped the minijson code in EvolvisForge to be a full-blown JSON encoder and decoder (lexer/parser) now. You wouldn’t believe just how much is broken in PHP (its own json_encode handles floats wrong in most locales, and mb_check_encoding doesn’t check the encoding of a multibyte string… at least, unlike Python, PHP manages to get 8bit okay though).

Anyway, thought you want to know. If you ever need a Pure PHP JSON encoder/decoder, you know where to look. It’s 100% my code (although written during dayjob, so the exploitation rights are with tarent GmbH). Current licence is GPLv2+ or AGPLv3+. If you spot any bugs, you know where to report them. I think it should be good though. (Do note that JSON is case-sensitive, so “NULL”, “True” and “\N” or “\U20AC” are not valid, “null”, “true”, “\n” and “\u20AC” or “\u20ac” are.)

I plan to store the “art_cust123” information in the user_prefs table in JSON now, instead of ‘|’-separated values, to avoid problems like these we had with broken database format and subsequent corruption of values, by using a dictionary (JSON Object) instead.

The ECMA 262 standard (ECMAscript and JSON) is freely available, though. JSON is also additionally specified in RFC 4627 which differs slightly (see my notes for details, mostly the goal element).

Update: fixed links

The blogs have been moved from *.blogs.evolvis.org to *.blog.tarent.de to provide proper SSL certificates. This also means that the use of blogs for people who are not employees of tarent GmbH, tarent AG or one of its subsidiaries is currently not available. (If that should become necessary, please contact us.

The feed has moved to http://evolvisforge.blog.tarent.de/feed/ for this blog (similarly to the others), but just in case, you’ll get redirected (although only to the https version, which Planetplanet doesn’t seem to like).

Planet Evolvis will be set up anew using Planet Venus software shortly.

All in all, the Greater Evolvis Platform is undergoing updates and improvements.

*buntu Hardy kann zur Zeit nicht installiert werden (der Kernel (in main) dependet auf Pakete aus restrictet, das ist aber zum Installationszeitpunkt nicht aktiv und sowieso unfrei; und wieso ist eigentlich das hardy-updates Repo im d-i eingeschaltet und nicht erst hinterher?).

Lustiger aber: „Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass[sic!] Sie eine unmögliche Situation angefordert haben oder dass[sic!], wenn Sie die Unstable-Distribution verwenden, […]“

gecko2s Kommentar dazu nur, daß unstable bei *buntu stable heiße. Ich habs dann auf LTS korrigiert (ist nicht das erste Mal — und sowieso, wieso tauschen die in einer stabilen Version PostgreSQL-Majorversionen aus?) und dabei haben wir’s belassen: Debian unstable = *buntu LTS.

Naja, wie wir das letztens Simon gesagt haben (Upgrade innerhalb einer Version von *buntu auf einem Server hat grub durch grub2 ausgetauscht): Mit Debian wär’ das nicht passiert!

I’m online again. (In case you didn’t notice, duh…) Seems as if we (the Telco/ISP guy and me) just needed to look at it hard enough for it to go away — first he could dial in, using my account data, which I probably should change now, then herc with ppp(8) and pppoe(8) was working (although at about 50 KiB/s down, he showed me 508 KiB/s — a rate I had never achieved — with his WiXP), then I took my notebook, which worked with pppoe(4). Now herc’s working again. (Maybe altq(9) can explain the slowdown? Hm, from debian.netcologne.de I get 500 so it looks okay.)
But eurynome isn’t, oh the joy. Luckily, gecko2 who administers its host system just woke up.

Things we do want to see: the Telco/ISP guy accepting that I run MirBSD on a P-233MMX box with Hercules graphics card and a 9″ monitor with no comment other than considering its age (and that it usually runs 24/7) as partial cause for the bug. Thanks, Netcologne!

Things we don’t want to see:
Mar 26 10:40:02 blau /bsd: signal 11 received by (screen:16857) UID(2999) EUID(2999), parent (screen:19111) UID(2999) EUID(2999)
“Suddenly the Dungeon collapses!! — You die...” (luckily, I get it about once a year only)

ObCoffeeSpices: Marrakech (Cumin, Allspice, Cumin Aroma) — though, due to its relative strength compared to the others, the only coffee spice I have left. And another hint: pre-warming the coffee cup with hot water, so it doesn’t cool down too fast with the amounts of milk I put in, rocks.

I just wore the Squeeze Release (FOSDEM, Spacefun) T-Shirt to the bakery and got asked by a neighbour: “Oh, a Debian fan?” “Developer, even” — now imagine the typical “informed interested guy” talk for a conference booth of your OS of choice here. How proud he was to get his wife and himself Windows®-free at home; how he likes to tinker a bit (if he’s got any time left), which has become harder with Windows; how his time constraints have him at OpenSuSE currently but asked how squeeze is; and the usual complaints at places like $ork where they have to use Windows® and MSIE (apparently you can’t centrally manage Firefox, eh, good someone tells me, because that’s what we do…). Wow. Anyway, it’s spring, so people, wear your shirts. (Hrm, what do I make of the fact that this is my only Debian shirt — although I’m thinking how to get Tartan Trousers if money were no issue — and nobody had ever commented on my various BSD, FOSDEM, FrOSCon, etc. wear…)

⸘Did you know…

	sudo tail -f /var/log/messages &
	sudo tcpdump -ovvlns1500 -eine3 &
	sudo ifconfig pppoe0 debug up

… still no network ☹ but at least I got some more information, and the L-Technicians will have a look at it tomorrow as well.

Two DNF out of four geocaches, well… one was too muggled, the other was no longer there, judging from the previous visitors’ log entries. Cached with natureshadow and bought his book on how not to cycle across Germany.

CLT was a blast, and it’s refreshing to attend an event without having to drive a booth of our own. Talked to lots of people. Since the boss was paying, even did some mingling in that area.

My ADSL line has been hiccupping ☹

Will drive to Chemnitz now. Maybe meet me there. No booth, just visiting to meet everyone again, rather spontaneous.

Rhonda suggested I document how to use the LLS (Launchpad Login Service — their implementation of an OpenID provider) as Delegate, which basically means, you can put something up on your webpage, which can be a simple static (X)HTML page like mine (a /index.htm is especially nice, a /~user/index.htm works too), and use its URI and not https://launchpad.net/~me to login. For example, this often hides the LLS from view e.g. in blog comments, such as those where Canonical is being criticised ☺ — but it’s also yours, easier to type and to change if you switch service providers.

The basic idea is to go to your Launchpad user page and view its page source. Look for openid relation links in the header — on Rhonda’s the value we’re looking for is “cyLQbcp”, and you see it several times.

Now you put this on your web page:

	<!-- begin: OpenID delegation to LP -->
	 <link rel="openid.server" href="https://login.launchpad.net/+openid" />
	 <link rel="openid.delegate" href="https://login.launchpad.net/+id/cyLQbcp" />
	 <link rel="openid2.provider" href="https://login.launchpad.net/+openid" />
	 <link rel="openid2.local_id" href="https://login.launchpad.net/+id/cyLQbcp" />
	<!-- end: OpenID delegation -->

Of course, insert your, not Rhonda’s, ID. Do note that we don’t copy the X-XRDS-Location tag (that breaks things for some unknown reason), but otherwise, what we insert on our page is pretty much a copy of the info on the user page (maybe it’s a Delegate page, too?).

As usual, try at your own risk, bug Canonical if it breaks. It works with AO3, Gerrit Code Review, and others though (interestingly enough, better in Lynx than GUI browsers because I stay logged in across Lynx sessions (and just have to confirm sending “my information” to the accessing site), whereas I have to re-login to the LLS in every GUI browser session).

As with the LLS generally, “to access a site which is not recognised” is expected and worked on with low urgency (mostly cosmetical, I think).