Pauly site: redux

A few years ago, when I was still a member of the Jozef Pauly ensemble from Ekeren, at some point I took over maintaining their website. One of the things I did was converting it to drupal, mainly because that would allow other members of the ensemble to help maintaining it.

Of course, such things do not happen automatically; and had I spent some more time on the project, it might've actually worked. But I didn't, so it didn't. Oh well.

One of the main issues with the site as I set it up, was that I hadn't really done a very good job integrating everything. The standard drupal 5 theme looked pretty good, I thought. Slap on a few modules, and done. Unfortunately, I skipped a bit of testing, and as a result, the site didn't really function the way it should've. When this became apparent, I didn't have the time to properly fix it.

During the last few years that I was a member of the ensemble, someone else stepped up to help maintain it. I told him that one of the things that I wanted to do was to upgrade the site to Drupal 6, so as to make i18n a bit easier. But some of the modules which weren't in drupal core made this somewhat harder than needed, and I didn't have the time to investigate in-depth what the issues were.

In the end, I set up a secondary site on a different vhost on the same server that ran drupal6, and gave that guy admin rights there to help convert things to the new site. I planned to lead the effort to make things work; but when I came back not so much later, it turned out that he'd done a very good job already, and that it was probably a good idea to let him finish.

This took much, much longer than expected; but eventually, he's finalized the setup, and it's now live (since a few weeks) on their official site.

This site has content in both Dutch and English, though there is slightly more in the Dutch version: since they're doing a concert trip again this year, there's a blog for their families. Also, some people individually have decided to blog about the whole thing, too, which is... interesting.

At any rate, I think the site looks very, very cool. Go check it out!

I guess we may have to start thinking about doing an upgrade to Drupal 7 some time soon. But, hey.

Monty at it again...

Apparently Michael Widenius isn't quite about to give up on his quest against Oracle.

The latest news is that he's appealing the EC decision. Wonder what the use of that is, since the merger seems pretty final already. I also don't think it's a very good cause, at any rate. After all, the worst that can happen is that MySQL will fork. Or that Oracle will pour some resources in it, and actually make it a database, rather than the POS toy it currently is. Or that it dies out, and that the world switches over to PostgreSQL or Firebird for Free Software database requirements. Wouldn't be a big loss, would it?

Give up already, Monty!

Stream-of-image video data and cinelerra

Just so I won't forget, but also to make sure others with similar problems to me don't need to search for several hours before finding it's so simple that it's silly:

If you have a bunch of image files (PNG, JPG, whatnot) that you want to treat as a single clip in cinelerra rather than hundreds (if not thousands) of individual files, the trick is to use a "list file": you create a file with some metadata and a list of all the files that make up the video clip, and import that, rather than the individual files.

If said individual files are PNG files with alpha information, doing so also makes it ridiculously easy to create an animation that only covers part of the screen.

The file format is pretty basic; but over at this page on the cinelerra.org website they list two scripts (one python with GUI, one bash and command-line only) that can generate such a file, given a bunch of image files. That makes it even easier.

I'd also like to note, for the record, that cinelerra outperforms kdenlive in everything but 'transcoding flexibility'. Kdenlive also has support for image lists (and you can create them in the gui rather than having to muck about with external programs or editors), but it has the rather nasty misfeature of doing the equivalent of "Oh, look, what's that? We don't need that, let's throw it away" whenever it encounters alpha information in PNG files.

For full reproducability, it's also possible to generate PNG files with alpha information from povray if you use the +UA command-line parameter, and say something like

sky_sphere {
	pigment {
		color rgbt <0, 0, 0, 1>
	}
}

somewhere in your scene file. Yes, I know, povray is non-free, but it works, and—as opposed to blender—I do know how to use it. Hey, I'm not RMS.

New toy

Just bought me an external flashlight; a Nikon Speedlight SB-900, which is Nikon's top model. It wasn't as expensive as that sounds, though, since this was their demo model that they got me a good discount on, on top of the already rather low prices that this shop offers; this made it cheaper than the list price of the SB-600, Nikon's second-best model.

I'm afraid it will take a while before I'll be able to fully understand its features, though. I did get a course at photography when I was about 13 years old, which did help me in picking up again how to work with an SLR camera when I bought it. But that course never included anything about using flashlights; and while I do understand how bouncing light off of walls and other things may sometimes help in getting the picture just right, I haven't actually ever done that. So I guess I'll be practicing a bit, now...

There

Yesterday, I've arrived in New York City for the annual Debconf. Well, that is, today's the first day of Debcamp, and obviously not that many people have arrived yet. Since I arrived a day early, I'd also booked a hotel room for one night. But that's okay, it allowed me to sleep off my jetlag—not that I had much of it, but anyway.

Today, then, I signed in to the dormroom. Turned out I was the first non-organizer to do so, and that there wasn't even anyone in the hacklab yet. Well, that's what you get for being so early, I guess.

Not quite sure yet what to make of the weather. When the plane touched down yesterday, the captain announced over the PA that the outside temperature was 99 degrees Fahrenheit (some 37 degrees Celcius), which is hot, especially when added to the rather high humidity. You walk outside for five minutes, and you're sweating like a pig. Today started off on the same foot, but then about an hour ago or so it started raining, and it hasn't stopped yet; and it doesn't feel like what I would call a regular summer thunderstorm, either. Bit weird.

But then, who cares about rain at a computer conference, right? Right.

Maintainer stupidity

As a buildd admin, you get to see the myriad of ways in which packages can fail to build. Sometimes this is due to interesting technical reasons about the architecture in question; sometimes... not so much.

cc1: unknown option: -mmmx

For reference, I maintain powerpc and m68k buildd hosts.

configure: error: pkg-config: command not found

Checking build-dependencies is hard. Right?

ccache: failed to create /home/buildd/.ccache (No such file or directory)

No, I don't manually install ccache inside the buildd chroot, which must mean some build-dependency pulled it in. Why one would want to do that, I dunno—it's not like a build that takes longer would produce a different package, so it clearly is not required for the build.

(BTW, the invalidity of $HOME is on purpose -- packages are not allowed to write outside their build directory during builds, which includes home directories)

... and more. Sometimes, I wonder how people get the right to upload. But, well.

NBD: authentication and named exports

I just did some work on two NBD features: authentication and named exports.

The first was written by Brad Allen back in 2008. I'd been thinking about an authentication scheme back at DebConf 8, and discussed it on the nbd-general mailinglist. Brad picked it up and ran with it, but it never got finished. Basically, what I did today was forward-port the code so that it would compile (and work) with today's version of the NBD utilities.

I tested it and it works, but I'm not sure what to do with it. NBD is not encrypted; so there's no protection against TCP hijacking or some such. Oh well; I might still integrate it into nbd mainline.

The second feature is something way more interesting. It had been on my long-term TODO list for quite a while, but I never sat down to implement it. Until today, that is. This patch has been compile-tested, but I haven't functionally tested it yet; I'll do that tomorrow.

The main reason it took so long to implement, was that initial NBD handshake made that quite hard. Upon connecting, nbd-server as it currently exists will open the file or block device that it needs to export, and—before nbd-client has sent anything—sends information on that export (its size, whether or not it is read-only, etc) to the client. Unfortunately, this does mean that I cannot add new features to nbd-server while retaining full backwards compatibility if these features may involve changing what nbd-server sends during the initial handshake, as is the case here. This could be worked around by having the server first send information on a "default" export to the client, and then variate that if the client informs the server that it actually wants something else. But this would have been rather ugly, since it means that errors in open() or stat() calls for the initial "default" export would have to be non-fatal until the client actually tries to read or write to or from the device, at which point they would suddenly become fatal. This would open a can of worms near which I didn't want to tread.

The way I fixed it in the end, however, is fairly simple. If names are used to specify an export, nbd-server can live with just one port to export all block devices that it supports, rather than needing many. As such, I can "reserve" one port for the new-style named exports. On this port, nbd-server would expect that clients send a name, and would not function correctly with clients that don't understand names. At the same time, nbd-server could still export the same block devices on other ports as well, using the old-style protocol, for clients that do not support named devices.

This would of course require that both the client and the server know perfectly well what the port is, and that it does not change too easily. As such, I've just put in a request for an assigned port number over at IANA, so that I can be sure that the port will not change unexpectedly. This also means I won't make a public release with this change until the port number has been assigned, so that I don't need to support two 'default' nbd-server ports in the future (one "temporary" and one IANA-assigned port).

For now, however, I think I'll go grab some food.

Wouter Verhelst, Tourist

So for one day a few days ago, I wasn't Wouter Verhelst, Debian Developer, but rather the above. I'm not usually very much interested in doing touristy things, but then on the other hand I'm of the opinion that you can't really claim to have been somewhere if all you've seen is the inside of a certain specific university campus.

So, well, touristy things. I took the subway to about 10 blocks away from the very south of Manhattan, and then walked. I passed by city hall and what used to be the world trade center, but there wasn't much to see there—construction sites are the same everywhere in the world. I moved on to "the battery", the south tip of Manhattan, and had an... interesting look at the Statue of Liberty in the distance. I thought about going there, but the tickets were sold out, so scratch that.

Instead, I walked on to the Brooklyn Bridge (passing by Wall Street on the way), spent some time looking for the pedestrian's entrance to that bridge (which was slightly harder than would've thought it to be), and walked partway up the bridge. I wasn't interested in crossing over to Brooklyn, but it's an interesting bridge to walk on, and I had an interesting time.

When I left the bridge again, it started raining. I don't mind a few drips on a warm day like that day, but this was more than that, and it started to bother me. So, rather than walking to the Empire State building, as I'd been planning, I decided to take the subway there. This did mean I missed out on the SOHO area, which I would've liked to see, but well, you can't have it all.

The Empire State building is something you grow up hearing about, and I'd seen pictures of it. It has a somewhat distinctive silhouette, shown on several comparative graphics of high-profile skyscrapers. But none of that is even close to the real thing. Not that it's higher than I expected; on the contrary. But it does look different; its color is much lighter than I thought, and the distinctive silhouette isn't as distinctive once you're standing right next to the building.

But, well, going up the building clearly shows that it is the tallest building of New York. There are other skyscrapers, but most of those seem to be little dwarves in comparison. The view is nice, up there, and I took some interesting pictures. The tickets aren't very cheap ($20), but not insanely expensive either. I don't regret doing this.

(in case you were wondering: yes, the above picture is in the point of view of the one above that, and vice versa)

By that time it was around 4 pm already, and I thought about going back to the Columbia campus. As I checked out my map for the most efficient route, I found that it probably would've been easier to walk to Times Square and take the number 1 train there which stops right in front of Columbia (but below the surface, obviously). So since I was going to have to go there, I figured I could just visit Times Square while I was at it.

I must say I'm not very impressed by it. For starters, Times Square isn't actually a square, at least not as I'm used to that word. Broadway and 7th avenue happen to cross at a, for Manhattan, uncharacteristically sharp angle, which results in more space between buildings than usual. But it's still fairly small as a "square". They've fenced off a part of that space and put a bunch of chairs and tables there. This would be a cosy and inviting, "gezellig" place, if not for the very audible noise of the traffic still going on all around it, and the fact that everywhere you see, there's three layers of brustling and visually noisy adverts. It could have been a relaxing oasis in the middle of the city, but instead it's just as busy as everywhere else in Manhattan.

But then, I guess that's what New York City is all about.

At any rate, after spending about half an hour or so there, I walked over to the subway to get back to the venue—just in time for dinner. The end of a nice, touristy, day.