WEBlog -- Wouter's Eclectic Blog

Fri, 05 Mar 2010

Netgear WNDR3700 and OpenWRT

I wanted a machine on which I could easily run OpenWRT. So I'd went to the #openwrt channel on freenode a while back, and just asked for suggestions; people suggested to me that the Netgear WNDR3700 was a good choice, so I ordered that.

I assumed that it would be easy enough to install OpenWRT on this device, but hadn't actually looked into it, planning to wait with that until the device had arrived. Little did I know that the machine actually comes with OpenWRT preinstalled. Now there's an interesting twist.

Now you do need to run some "telnetenable" thingy to be able to get a shell, after which "telnet <device>" gets you a root shell (with no username or password by default). Supposedly you should update that by using "passwd", but they managed to break that in the firmware that comes with the device.

I am missing a few things, though.

root@WNDR3700:/bin# dmesg
/bin/ash: dmesg: not found
root@WNDR3700:~# uname -a
/bin/ash: uname: not found
root@WNDR3700:~# hexdump /bin/config |more
/bin/ash: less: not found

Unh?

root@WNDR3700:~# alias
more='less'
vim='vi'
root@WNDR3700:~# 

Aahh.

And for those who were wondering: no, it does not have any 'vi' installed, either.

Oh well.

The fun thing is, this device has a USB connector, too; so it should be possible to connect a USB storage device, install Debian, and use it as a very potent home server/router/switch/whatever. That'd require me to understand how hostap works, though, which I haven't played with yet. I'm sure I'll figure that bit out -- at some point.

/en/computer/hardware

PermaLink

Wed, 03 Mar 2010

dpkg vs RPM

Thomas blogs about some issues he had with his N900's facebook plugin. This post isn't about that, as I don't use facebook.

But as part of his blog post, he mentions the following:

This reminded me of a pet peeve I have with those people who claim Debian’s packaging system to be far superior to rpm – apparently dpkg doesn’t have any equivalent of rpm -qv which allows you to verify that the files that should be installed by a package are indeed on disk

True, probably because the script would be so trivial:

for i in $(cat /var/lib/dpkg/info/nbd-client.list)
do
	[ -f "$i" -o -d "$i" ] || echo "$i missing"
done

There, that wasn't hard, was it?

Now I'm not sure whether rpm's -qv option actually checks the checksum of the files, too. If it does that, then the semantically similar way would be:

(cd / && md5sum -c var/lib/dpkg/info/nbd-client.md5sums)

... except that MD5 is totally and utterly useless these days, and that we should be changing to something else. And that md5sums is an optional feature, provided by some, but not all, packages. And it may also be that maemo packages don't have md5sums (which would make sense). But, anyway.

/en/computer/cluebat

PermaLink

Wed, 17 Feb 2010

Local kernels

LC_ALL=C debian/rules debian/control
md5sum --check debian/control.md5sum --status || \
		/usr/bin/make -f debian/rules debian/control-real
make[1]: Entering directory `/home/wouter/debian/other-peoples-source/linux-2.6-2.6.32'
chmod +x debian/bin/gencontrol.py
debian/bin/gencontrol.py
Traceback (most recent call last):
  File "debian/bin/gencontrol.py", line 331, in 
    Gencontrol()()
  File "debian/bin/gencontrol.py", line 14, in __init__
    self.process_changelog()
  File "debian/bin/gencontrol.py", line 305, in process_changelog
    (distribution, version))
RuntimeError: Can't upload to unstable with a version of 2.6.32-8~local1
make[1]: *** [debian/control-real] Error 1
make[1]: Leaving directory `/home/wouter/debian/other-peoples-source/linux-2.6-2.6.32'
make: *** [debian/control] Error 2

The issue at hand was that I'd created a version of '2.6.32-8~local1', to document that I'd locally branched version 2.6.32-7 with that one config option turned on, but that my version should not be deemed larger than 2.6.32-8 (signalled by the ~ and whatever follows that). However, something somewhere in the Debian kernel build system (I was unable to figure out what, exactly) disliked that version number and told me I could not upload to unstable with that version. So it borked, and told me I had to fix my version.

Well, no, I don't want to do that. Instead, I wanted to disable that check somehow. Turns out that isn't too hard; gencontrol.py not only checks the version number, it also checks the target distribution. So if you don't want to upload to unstable, you just need to tell the tool that:

-linux-2.6 (2.6.32-8~local1) unstable; urgency=low
+linux-2.6 (2.6.32-8~local1) local; urgency=low

Simple, but you'd need to know.

/en/computer/debian

PermaLink

Mon, 15 Feb 2010

Hum.

I wonder how these people will react to this.

At least it's going to be somewhat more open, I guess. Which is good.

/en/computer

PermaLink

Sat, 16 Jan 2010

ACCEPTED

My mutt said this last night:

 894   + Jan 15 Archive Adminis (0,4K) ipcfg_0.1_amd64.changes ACCEPTED

This obviously means that if you wish to use it, you no longer need to go through git; you can just add experimental to sources.list and run 'apt-get install ipcfg'. A few notes, though:

• I missed a few build-dependencies, so it's only available on amd64 for now. Yes, I should use pbuilder more (I did for the 0.3 upload, which went in today).
• The documentation is somewhat lacking. I just found out that the documentation isn't actually installed in the binary package, so you have to download the source package (or check out the git repository). This will be fixed for the next release. The documentation also currently consists of a few .txt files rather than (a) proper man page(s). This will likely take some more time.
• ipcfg Conflicts:, Replaces: and Provides: ifupdown. This is because there is no proper virtual package name for it to conflict/replace/provide. I have filed a bug, #554194, against debian policy, to request it be made, but so far this is not yet finished (and indeed was somewhat dead during the period that I had no time to work on ipcfg). This may confuse some packages that really do depend on ifupdown.
• ifdown works, but not reliably so. This will be my next main point of focus.
• If you use the insserv automatic ordering system for initscripts, then you must either purge ifupdown or remove its initscript before installing ipcfg; otherwise, the availability of two initscripts that provide network configuration will confuse the hell out of insserv.

And in case you wonder why the hell I went from 0.1 to 0.3:

ipcfg (0.2) experimental; urgency=low

  * Rebuild without .git directory. D'oh.

 -- Wouter Verhelst   Tue, 12 Jan 2010 17:43:09 +0100

srsly

/en/computer/code/ipcfg

PermaLink

Wed, 13 Jan 2010

Using ipcfg, now

Yesterday, I had some time to debug ipcfg some more. The main blocker for me to upload it to unstable was the fact that I could not get WPA security to work; therefore, I could not use it myself. In the interest of "eat your own dogfood", I did not feel that uploading some experimental code to Debian that I'm not using myself is a good idea.

That problem is now fixed, albeit through something of a hack, one that I hope will not be necessary forever: I decided to write a plugin to run ifupdown extension scripts (found in /etc/network/if-*.d). It does require some set-up, and there are still some severe issues; but as of now, I am using ipcfg rather than ifupdown on my laptop.

Those interested in trying it out can either wait for ftp-master to ack the upload and then install from unstable, or just fetch it from the git repository.

/en/computer/code/ipcfg

PermaLink

Tue, 29 Dec 2009

Perl on the N900

Since about a week, I have a Nokia N900. They're not actually on sale in Belgium yet, but I managed to get hold of one through a grey market shop.

The device is quite nice. I do have a few irks with the interface here and there, but Nokia has a public bugzilla that I'll surely use to file bugs whenever and wherever appropriate. And after using it for about a week, I thought of migrating this small application which I once wrote on half an afternoon using perl, postgres, and Gtk2, to the device. It's mainly a cataloguing system that I store my DVD collection in (which has gotten large enough that this is necessary), nothing earthshattering. The ideal candidate to get my feet wet in developing for the N900, so to speak.

That effort got stopped dead in its tracks pretty quickly.

Nokia-N900-42-11:~# perl
use Gtk2;
Can't locate Gtk2.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.3 /usr/local/share/perl/5.8.3 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at - line 1.
BEGIN failed--compilation aborted at - line 1.
Nokia-N900-42-11:~# apt-cache search perl
perl - Larry Wall's Practical Extraction and Report Language.
libpcrecpp0 - Perl 5 Compatible Regular Expression Library - C++ runtime files
po4a - tools for helping translation of documentation
libpcre3 - Perl 5 Compatible Regular Expression Library - runtime files
libgdbm3 - GNU dbm database routines (runtime version)
perl-base - The Pathologically Eclectic Rubbish Lister.
liblocale-gettext-perl - Using libc functions for internationalization in Perl

Or, in other words: they only ship the perl bits needed to make dpkg run.

Hrmpf. This would make stuff slightly more... involved.

Oh well.

/en/computer/code/n900

PermaLink

Sun, 20 Dec 2009

Re: Grrr

I received a number of comments on my "Grrr" post, all of which missed the point:

Yes, I am aware that there are many more ways to fix this issue beyond a memcpy. However, the example code is legal and would not crash the application, if not for the fact that libc thinks I am doing something wrong. On top of that, this kind of overflow "protection" only kicks in when the code is compiled with -O2 rather than with -g -O0. While I am not sure whether the difference is due to the absense of debugger symbols, or rather due to the different optimization levels, fact is that software which runs fine in debugging should also run fine in production.

There are good arguments for compiling all C code with -Wall -Werror, and I do that as a matter of course for all C software that I write. However, sometimes automated tools are just wrong in their compile- or run-time bug detection, in which case such it should be possible to disable that detection. This is one such case, and my blog post was more about ranting about the inability to do so, rather than about the fact that I had to memcpy when in fact there were other options available.

But yeah, perhaps I should have been clearer about that. Forgive me for not being clear after having fought with compilers for far too long.

/en/computer/code

PermaLink

Good, not evil

There is a bit of a fluff online currently about the following clause in the "jsmin" code (whatever that is):

The software shall be used for good, not evil

This seems to have started when Google rejected a project based on that code due to its license being not free or open source according to their standards, and therefore not welcome anymore.

The arguments then quickly degenerated into things like 'when did google stop being against evil'. But those are all besides the point.

One of the most important properties of free and open source software is that anyone can use it for any purpose; there are no restrictions to using them. The DFSG (and hence, the OSD which was derived from the DFSG) encode this as follows:

No Discrimination Against Fields of Endeavor
The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used for genetic research.

You may think "how is 'evil' a field of endeavor", but that is the wrong question. To "use software for evil" can mean any of a number of things, including "nuclear research", "weapons development", "abortion", or, heck "the cash register in a butchery shop", depending on the ethical and moral framework through which the person writing the license sees the world.

The ability to give someone a CD or DVD with a bunch of software on there, being able to tell them that they can just use this in any which way they see fit, is a very strong and important feature of the free and open source community. Every time someone comes up with a clause like the above, however, this ability is diluted somewhat; and if it is readily accepted within the greater free and open source movement, then eventually everyone interested in using a piece of software must first check whether they're not trying to use software that forbids someone's pet evil, and we lose one of the greatest strenghts that does exist for free software, but not for proprietary software.

The sad thing is, the jsmin author seems to agree. From a video/transcript on which he talks about his absurd license clause is the following quote:

Also about once a year, I get a letter from a lawyer, every year a different lawyer, at a company – I don't want to embarrass the company by saying their name, so I'll just say their initials – IBM…
[laughter]
…saying that they want to use something I wrote. Because I put this on everything I write, now. They want to use something that I wrote in something that they wrote, and they were pretty sure they weren't going to use it for evil, but they couldn't say for sure about their customers. So could I give them a special license for that? Of course. So I wrote back – this happened literally two weeks ago – "I give permission for IBM, its customers, partners, and minions, to use JSLint for evil."

Or, in other words, all you have to do if you want to use this software for evil is set up a second company, tell Douglas that this second company wants to sell software that uses his software to people who might use it for "evil", even though the first company won't, and you're in business. Because Douglas doesn't really oppose evildoers.

So the question is, why is that clause in there in the first place? There are only two possibilities; either Douglas didn't really think about those issues, in which case I hope he will one day see the light and remove the clause; or he did, and decided to go ahead and put that clause there anyway. And that would be evil.

/en/computer/legal

PermaLink

Wed, 16 Dec 2009

Grrr

struct {
	char str[4];
	char sc1;
	char str2[3];
	char sc2;
} foo __attribute__((packed));

snprintf(foo.str, 5, "%04X", data);
foo.sc1 = ';';
snprintf(foo.str2, 4, "%03X", otherdata);
foo.sc2 = ';';

Yes, I know that both snprintf() calls in the above snippet will overflow their immediate buffer. Yet this code is safe; the network protocol for which this code is written does not actually need nor expect NUL bytes; instead, it wants semicolons. I could of course use a "char foo[9]" rather than a struct as above, but I find this to be slightly more convenient than to count offsets.

However, this code does not work with glibc, because the buffer overflow detection kicks in.

Solution:

char buf[5];

snprintf(buf, 5, "%04X", data);
memcpy(foo.str, buf, 4);

In other words: add a stupid and useless memcpy, because someone thinks they're smarter than me. Stupid morons.

/en/computer/code

PermaLink

Tue, 08 Dec 2009

Hardware RNG

So, as many people probably know by now, the nice folks over at Simtec Electronics, some of whom were at DebConf9 last summer, have created a nice small device that plugs in a USB port and, with a userland daemon and some encryption for security, generates entropy (randomness) for the Linux kernel to use (through /dev/random and friends).

I've plugged one in my server today, and suddenly my server's entropy pool was full. This is a really nice thing. For a simple example of what happens when you insert such a thing into a server, check out my munin graphs.

Very nice for such a cheap device...

/en/computer/hardware

PermaLink

Sun, 15 Nov 2009

NaN currency

The Daily WTF, an excellent website that I recommend everyone remotely involved in computers has a look at every now and then, has one series of posts where it shows 'strange' or 'funny' error messages from not just desktop computers, but also ATMs and other embedded devices.

One of the more recent entries of these Error'd series contained a picture that made me cringe; it showed 'NaN' for a currency value. Obviously this is an unhandled floating point error, but that's not what made me cringe.

What did make me cringe is that people who are supposed to work with shitloads of money are using floating point numbers to store monetary values. This is stupid. By their nature, floating point numbers are imprecise and inaccurate. The representation of a floating point number is an approximation. This is not the kind of thing one would like for bank transfers. "Mr Foo would like to transfer approximately €100 from his account to that of his neighbour." Err, no; it doesn't work that way.

Instead, whenever you use currency, you should use integer numbers. If your local currency is the US Dollar or the Euro or another similar currency where zero-point-something amounts of money are regularly used, work on the convention that "1" in your variable actually means ".01", or ".1", or whatever is most convenient, and make the right conversion whenever you need to do some output. Do not think you can deal with rounding errors in floating point, because you cannot.

COBOL (I can't believe I'm saying this) actually makes the latter easy, because you can create a statement that says "to output this variable, show the first three digits, then a point, then the last two digits". I believe it doesn't even have support for floating point numbers. Unfortunately this kind of thing is harder in C (and similar languages), but that doesn't mean you should just go ahead and assume that floating points are a good idea...

This is the kind of error I could accept from a first-year graduate student, but not from someone who's supposed to work with money on a daily basis.

Oh well. At least the ATM is about US Dollars, so it's not likely that it's going to be my problem any time soon.

/en/computer/cluebat

PermaLink

Sun, 11 Oct 2009

Fuck you, Sony.

I had wanted to buy a PS3 ever since I learned about this interesting processor that is called the Cell. Not that I'm very much into console gaming or any such thing; I'd have settled for any kind of affordable Cell hardware, really, but that basically is 'the PS3' these days.

What I had missed, however, was the fact that recent PS3 machines don't support running Linux anymore. Apparently this was all over the interwebs, but unfortunately I didn't see that.

That's €300 I won't see again, for a useless (to me) piece of hardware.

Stupid morons.

/en/computer/hardware

PermaLink

Thu, 24 Sep 2009

RedHat is so medieval

So there's three systems. One of them runs CentOS 4, the other two run RedHat EL 4. One of the RedHats has been in use for quite a while, but the other two are freshly installed, and would need to have the same functionality as the first, but don't yet, mainly because they miss a number of packages.

So we do this.

[wouter@working-host ~]$ rpm -qa --qf "%{NAME}" | sort -u > working-host
[wouter@CentOS ~]$ rpm -qa --qf "%{NAME}" | sort -u > CentOS

Next, we compare the two:

diff -u working-host CentOS | grep '^-' | tail -n +2 | sed -e 's/^-//' > CentOS-missing

At this point, the file CentOS-missing contains some 403 lines. So how does one install packages on CentOS4?

[root@CentOS ~]# yum install $(cat CentOS-missing)

It starts thinking about it, then after several minutes comes back to me with "foo is already installed in an older version. I can't do what you're asking me"

[root@CentOS ~]# grep foo CentOS-missing
[root@CentOS ~]#

In other words, it decided that, to satisfy one of the dependencies of one of the packages I'm asking it to install, it needs to have some other package installed, too, so adds it to the set. Then figures out that it's already installed, at an older version than what it was trying to install. Then bombs.

Okay Wouter, what were you thinking? Surely you can't expect a package manager to suddenly update packages when you ask it to install something else? That would mean upgrading and installing in the same command execution! Oh, the horror.

So, okay, we run yum update first.

Do you think that fixes it? Of course not!

It now comes back with... a message saying that a newer version of what we're trying to install is already installed.

Sigh.

So I'm now running 'for i in $(cat CentOS-missing); yum -y install $i; done' on this host. Since it takes yum several minutes to resolve dependencies, that means it's going to take a while to have it install 403 packages.

The not-yet-working RedHat 4 installation seems to have the exact same problem, except that up2date takes even longer to resolve dependencies, so we're not beyond the 'upgrade' step there yet. I'm sure it will come up with all kinds of other interesting failure modes. Luckily the RedHat-missing file is much smaller (83 packages).

How do RedHat users not eat their keyboard in frustration?

Note: yes, I'm aware of apt-rpm. Unfortunately, that is not supported on 64bit installations, because apt (in neither its dpkg nor its rpm variant) understands the notion of multiarch. At this time.

/en/computer/cluebat

PermaLink

Fri, 18 Sep 2009

Announcement

I was really happy a few years back, when Martin announced he'd start working on netconf. Not just because I agreed with his assessment that ifupdown needed replacement; also because I had been thinking about a good way to implement such a thing, and had been planning to start writing 'soon'. With Martin's announcement, I made a few suggestions to give him some input, and then put my plans away—I had more important things to take care of, anyway.

Unfortunately, netconf did not manage to reach the ambitious goals that Martin set out, mainly due to lack of contributors. I wanted to help out; I really did. But Martin's choice of python to implement a 'prototype' which then had to be reimplemented in C or C++ didn't get me very thrilled. Not just because I have a severe dislike of python; also because implementing something twice is, in my humble opinion, not quite the best way to do something like this.

But hey, who am I, if I don't put my code out there.

Never the less, I tried helping. I really did. During debconf8 at Mar del Plata, I approached Martin with the suggestion that I start reimplementing those bits that were unlikely to change anymore in C, as a first step toward something that could be in the base system. Unfortunately, that didn't happen. After trying for about two weeks, I just gave up. I thought I could read python code and reimplement that so that it would work the same way, but I couldn't. I thought I could implement python modules in C without knowing python, but as it turns out that's a laughable idea.

For several months then, I didn't think about it anymore. In March of this year, however, I got a little bored. And what does one do when they get bored? Right, you find something to do. I my case, that was 'figure out how bison works'. I'd of course known about parser generators for quite a while, but just never had the time to dive in deep and figure out how they work. When I needed to do a config file for nbd, I instead hand-wrote my parser and used a lexer from libglib. But I wanted to learn how to do things properly, so I sat down.

Long story short, when I had to choose something somewhat more complex to implement, I thought 'how about a hypothetical config file for a network configuration utility', and I started implementing that. It turned out to be fun, so I didn't stop after I knew enough about bison. And just last week, for the first time I successfully used it to bring up my wired interface using DHCP -- and bring it down again. It can also already manage static interfaces through netlink, though it isn't quite able to the equivalent of 'ip addr flush' yet.

Fun.

The system is quite flexible. It has a plugin interface (which needed some refinement that I did using some help on IRC just today), which should allow developers to implement extra functionality by just dropping a shared object in the right directory. In fact, I'm working on the wireless support (hence my blog post of last week) as a plugin.

Obviously the code isn't remotely ready yet. The wireless code has a long way to go. The firewall module needs to be started. It will probably crash and burn if put to the test. But even so, it already has one feature that ifupdown, in its 10 years of existence, never acquired: it will not try to DHCP off an interface if it finds out that there is no cable connected to it—unless you wrote a configuration that asks you to do so.

I wanted things to be as simple as possible, and therefore the minimal valid configuration file that will do something useful is the following:

That's right, it's empty. This will cause the system to bring up the 'lo' interface at bootup, and do nothing else. If you say 'ifup eth0', where eth0 is a valid and existing interface, it will first check whether there is a link, and if so, DHCP off of it.

There's much to do still, but I have now reached a point where I feel the system is ready to meet all challenges it should be able to meet (or so I hope), and where it might be nice if interested people check it out.

The code is in a git repository that's mirrored on git.debian.org, github.com, and my own git.grep.be. The latter is my --mirror repository, but is not available for cloning to anyone else. If you're interested in checking it out, you may want to start with doc/tech.txt, and/or examples/ipcfg.cfg. I updated the former just yesterday, so it's quite up-to-date. On the other hand, while the latter shows the direction I would like the system to take, the code is a far cry from implementing everything shown there, and it has been a while since I last checked that file out, so the comments in there are, in some cases, somewhat outdated. But that's good, because I want to keep the file as a reference of the goals that I originally had, before I'd written this whole corpus of code, so that I can go back at some undefined point in the future and fix things.

Comments are (more than) welcome.

/en/computer/code/ipcfg

PermaLink

Thu, 17 Sep 2009

#include <iwlib.h>

Writing a network configuration tool is... fun.

Well, mostly anyway.

/***************************** SCANNING *****************************/
/*
 * This one behave quite differently from the others
 *
 * Note that we don't use the scanning capability of iwlib (functions
 * iw_process_scan() and iw_scan()). The main reason is that
 * iw_process_scan() return only a subset of the scan data to the caller,
 * for example custom elements and bitrates are ommited. Here, we
 * do the complete job...
 */

/*------------------------------------------------------------------*/

(from iwlist.c)

Not. The. Way. To. Do. It. Especially not if you're the person who writes both libiw and iwlist. Grmbl.

Also, documentation for libiw seems to be, well, nonexistent.

Fun. Not.

/en/computer/cluebat

PermaLink

Thu, 30 Jul 2009

Passwords

The Debian System Administrators decided, apparently, that disabling password logons is a good thing that warrants a 'Good News' post.

Allow me to politely disagree, for two reasons:

First, an SSH key is a password that is stored on the hard disk, while a 'regular' password is only stored inside someone's brain. While torturing someone to get at their password is arguably possible, it is not possible to do so without this person noticing. The same cannot be said about someone secretly stealing a file from someone else's hard disk; and while it is certainly possible to protect an SSH key with a password, it is not at all required to do so in order to use such keys. As such, on the server end you have no way to know whether a remote client is in fact the person whom they claim to be, just because they happen to have a SSH key that just happens to match the original.

Second, security is not accomplished by forcing people to use things they do not want to use. If you do that, they will find ways to work around your security—leaving you with no security at all.

But oh well, it's not my call to make, so whatever.

/en/computer/cluebat

PermaLink

Tue, 28 Jul 2009

Extramadura: gnuLinEx and NBD

So obviously I already knew that the region of Extramadura uses a version of Debian they call gnuLinEx, but I didn't know the specifics. As such, it was nice and interesting that they offered us the option of going to a local school, where we could see an installation of gnuLinEx in action. Obviously I went there.

This was an interesting experience, for sure. When I arrived in Cáceres, I learned from Vagrant Cascadian that the school installations make extensive use of LTSP. This, in turn, uses NBD. Since they run this on 80.000 computers, it's quite likely that they're the largest NBD installation in the world. I had no clue.

So, today, when noticing that nbd-client was used on the local machines, I had a short little chat with José, one of the guys from gnuLinEx who's a Debian Developer, about the fact that I've been wanting to do some work on NBD's performance (mostly profiling runs etc), but that I don't have the setup to do this efficiently. To keep a long story short: I now have a test lab the size of which is several times the country I live in. Whee.

I had my camera with me, and took some pictures. I'll upload them soon, but have some other, more urgent, matters to attend to now (such as 'eat').

Later.

/en/computer/debian

PermaLink

Sat, 25 Jul 2009

RC NMUs

A few days ago, during DebCamp9, someone NMU'ed belpic to close #525593, a 'failed to build from source' bug that was filed against it on april 25th, 2009.

Since such bugs (for good reason) are deemed release critical, my package was facing the prospect of being thrown out of testing, and this person (who shall rename nameless in this blog post, since it is not about fingerpointing; but if you must, check the bugreport to find out who) did an upload to prevent that from happening.

In and of itself, this is a good thing. I don't like it when my packages have bugs, and generally try to keep the number as low as possible. There used to be a time when my maintainer bug listing had zero open bugs for most of the time, and though I long ago gave up trying to keep it that way, it is still a goal I would like to reach at some undefined point in the future. Yet, with this particular upload, I was quite unhappy, even going so far as to cancel it, preventing it from going into the archive; and when, over lunch, I discussed the situation with Adeodato Simó, he seemed to feel that I improperly blocked this upload; that I instead should have allowed it to proceed. I felt as if he was almost hostile to my notion that the uploader should have coordinated more with me than had happened. I tried to explain why I felt the uploader had done something wrong, but I do not think I convinced him.

After having thought about it for a few days now, I still don't feel I was wrong in my actions; and I don't like the idea of possibly being a bad maintainer. So here's my position on the whole thing:

First of all, the bug was indeed open for a long time. The reason is that I didn't have much spare time in May to look at it. I also had no clue as to what the problem was, which makes it kinda hard to fix it. I did have some spare time in June, but since Belgian citizens have to file their tax reports in that month, and since you may need the software in these packages to be able to do so, I did not think it was proper to indeed do an upload before the deadline of June 30th; I did not want to have to scramble to fix a botched upload at exactly the wrong time.

On the 11th of this month, a patch was sent to the bugreport that would fix it. This was the weekend before I would leave for DebCamp/DebConf, so I postponed working on it until I would arrive here in Cáceres.

Secondly, what I'm most upset about is the fact that the upload wasn't tested. It couldn't have been; the only way you can test this package is by using a smartcard reader and a Belgian ID card; since the uploader does not have the Belgian nationality, I doubt he has such a card. I don't personally do an NMU that often; but when I do, I consider it my duty to perform extensive testing, even more so than with my own packages. In this particular case, doing such tests is quite important, as I've had issues with the software in the past, where new builds wouldn't work properly for reasons that I haven't fully been able to pin down.

Of course the uploader couldn't know all that, but this is exactly why he should have talked to me before doing the upload. Of course, in theory, I could have documented all my knowledge about the package; but in practice, it's pretty hard to do that well (i.e., many of the things I know about my packages involve 'feeling', 'instinct', and 'experience', which does not easily translate to 'words').

For clarity: I'm not upset about the fact that I've been NMU'ed. That's happened in the past, even for this particular package, and that's been perfectly fine. What I am unhappy about, is that the NMU happened to DELAYED/1 (which gives me very little time to intervene) and that it happened without prior coordination with me.

So, was I really wrong in preventing the upload?

note: since the new upstream release that was available was eventually uploaded to experimental rather than unstable, I just uploaded 2.6.0-7 which also fixes the bug in question.

/en/computer/debian

PermaLink

Fri, 24 Jul 2009

Bison

The Bison parser expects to report the error by calling an error reporting function named "yyerror", which you must supply. It is called by "yyparse" whenever a syntax error is found, and it receives one argument. For a syntax error, the string is normally "syntax error".
If you invoke the directive "%error-verbose" in the Bison declarations section, then Bison provides a more verbose and specific error message string instead of just plain "syntax error".

Sounds good, right?

Well, no, not entirely.

syntax error, unexpected $undefined

Well, goody. Now I know what's going on.

note: yes, I do know that there are other ways to debug a Bison parser than just to use the parser error string. It's just that this could have been more useful, like, say, provide the line on which the error is found? The file I'm trying to parse here is pretty large, thank you very much.

/en/computer/code

PermaLink

DebCamp 9: stuff

This has, by far, been the most productive DebConf ever, for me.

Not that this means all that much—mostly that previous DebCamps haven't been productive at all—but I still got a few things done.

There've basically been three things that I worked on: d-i support for the Intel SS4000-E; a belpic/beid upstream update; and a minor incremental NBD update.

The latter was simple, and was basically the first thing I did. I had a chat with Vagrant Cascadian, who does a lot of LTSP stuff in Debian, and added some stuff to the package that would make his life a bit easier. Not a lot of work; as I'm also upstream for NBD, and as it's been one of those packages that I've maintained since an eternity, I know the code pretty well. Half a day later, all the code was there.

D-i support for the SS4000-E wasn't that hard (most of the hard parts had already been done by Martin Michlmayr), but unfortunately some bits are not yet completely in order—mostly having to do with the fact that the original firmware has a kernel command line embedded in the kernel. As such, for now, you'll have to connect to the serial line in order to fix the redboot config; maybe we'll come up with a sane way to fix that in the future, but as long as we don't, that does mean you need a serial null modem cable.

Not that you need to solder anything (the main board has a connector for a regular serial port; you just need to plug the right cable to the right connector, so it's not that bad.

The final thing was horrible. A piece of software that presumably works well, but initially wouldn't even compile on my laptop because of pointer/int confusion; a build system made on shell scripts and qmake; and other similar things.

Eventually, I just gave up and uploaded what I had to experimental. It works, to some extent, but should be improved over the next few weeks. That's not for today, however.

/en/computer/debian

PermaLink

Microsoft and the GPL

For some strange reason, people all over the net are oohing and awing over Microsoft releasing some drivers to use Linux on their proprietary virtualization software. I'm oohing too; not because of the drivers, but because of all the buzz that goes around it.

Ten years ago, I would have oohed and awed, too. At that time, Microsoft was fighting open source and free software like a cancer. Today, they're not; they provide open source software for Windows themselves (such as an installer framework which they provide through sourceforge), and actively cooperate with many open source and free software projects through their open source labs. They even have a section of their website dedicated to open source software

A large company like Microsoft can't survive if it tries to actively work against what the marketplace wants. The fact that they were indeed so actively fighting against open source software is quite likely why the first decade of the 21st century has seen such a huge loss of market share for them; like any large company, they needed to adapt or lose. They've chosen the first; good for them, and that might be good for us too.

Over the past decade, I've seen Microsoft warming up to open source, to some extent. This is why I don't understand much of the 'Boycott Novell' lunatics; sure, I don't trust Microsoft enough yet to be willing to say that they don't have any plans that will negatively affect us; however, that doesn't mean I will assume that evil things are their plans; unless proven otherwise, I will assume they have the best interest of their customers and/or shareholders as their main goal.

Which is why I was totally not surprised in seeing a GPL patch from Microsoft at this point in time. Rather, I find it normal and expected behaviour, a continuation of an evolution that has been going on for the better part of a decade now.

/en/computer

PermaLink

Wed, 22 Jul 2009

Buildd maintenance

In Debian, I've been a buildd maintainer since 2001; most of that time was for the m68k port (I still am active there, though not as much as I used to be), but there's also been a short stint with armeb, and since a while I'm now also a PowerPC buildd maintainer. I used to do just one powerpc host at first, but now I maintain both malo and voltaire, with Philipp Kern doing praetorius.

This probably makes me one of the more experienced buildd maintainers in Debian today, together with the likes of LaMont Jones and Ryan Murray. I did do a talk about how this is supposed to work at FOSDEM 2004, but that's now five years ago, and some things have changed since. Also, a not-videotaped talk isn't very helpful if you weren't there.

So I'd thought I'd write up what it means to be a buildd maintainer. There's of course the documentation on the Debian.org website, but that only explains how the system works in theory; it does not explain what us buildd maintainers tend to do on a daily basis.

So let's have a look at that, shall we?

Basically, the work of a buildd maintainer is pretty monotonuous, and an experienced buildd maintainer will usually have a set of scripts to help them. Their work can be categorized into three main categories. In order of frequency, these are:

1. Log handling;
2. State handling;
3. Host and chroot maintenance

Log handling

The first is the most obvious one. Every time the buildd builds a package, it will send a full log of the build to buildd.debian.org and to myself. The successful ones are signed with a simple script:

#!/bin/bash
tmpfile=$(mktemp)
sed -i -e '1,/\.changes:$/d;/^[[:space:]]*$/,$d' $1 | tr -d "\200-\377" > $tmpfile
cat $tmpfile > $1
rm $tmpfile

Easy: use a sed command to fish out the embedded .changes file, and write that to the original file. I use a folder-hook to set this script as my 'editor' in mutt when I'm in my buildd mail directory; thus the result is thereby mailed off to the buildd. In that same folder-hook, mutt is also configured to send the reply gpg-signed in the 'traditional' format, without confirmation, and with just one keystroke, so that (after I have entered my GPG key passphrase) I can send off all the signed changes files in one go. A possible improvement could be to change the macro so that it would work with mutt's 'tag' feature (it doesn't, currently), but that's not a big issue (currently, doing 100 mails takes a few seconds and some careful counting).

Note the 'tr'; this is to avoid 8bit characters from appearing in the mail, which might otherwise be converted to their quoted-printable version in transit to the buildd; and since buildd-mail (the part that receives that mail) does not understand MIME, this would corrupt the GPG signature. This way, we do lose a few characters from the changelog, but that doesn't really matter -- the source still contains the unmodified changelog entry.

With this script, I often handle my 'success' folder several times a day. It's no effort, anyway.

The somewhat harder but much more fun part of log handling, is the handling of failure mails. Since there are loads and loads of possible failures, the scripts to handle these are somewhat more involved. I did receive a script from LaMont at some point, a few years ago, which I then built on so as to improve it. It's not perfect, but it does handle a few common cases with no extra input from me. Some of the others are not so easy, however.

One of the more common cases that cannot easily be automated is the case of the buildd failing to install a certain package, because 'foo depends on bar, but it will not be installed'. This is apt's way of telling you that bar depends on foobar which depends on quux (>= 1:2.3.4-5) which depends on libfrobnitz2, but that has now been replaced by libfrobnitz3. Or some such. The only way to figure out what the hell the problem is, is to walk the dependency tree and figure out stuff from there.

There is an 'edos-debcheck' that reportedly can help with this; personally, I wrote a set of perl scripts that will cache a Packages file into DBM files, and then allow you to walk over them to help you figure out what's wrong. They're not perfect, but if you use the '-v' option to check-dep-waits and verify the output when it tells you about missing libraries, it should be able to figure out the whole dependency tree I described above, and will allow me to write a proper dep-wait response, allowing the buildd host to automatically retry the package when the missing dependency is available.

Also somewhat common and routine are things like transient network failures (in which case we use either 'retry' or 'give-back' if the buildd hasn't figured that out by itself and done the latter), the maintainer uploading a new version of the package while the previous version is building (resulting in wanna-build firing off an email to the buildd host, which in turn results in buildd killing the build by removing the build directory; this is not always easily distinguishable from a regular failure, so I commonly respond to that mail with a failure message; if it did indeed fail because of a newer version, then buildd will notice that and ignore my mail), the incoming.d.o Packages file (which is only available to buildd hosts, so don't ask) being out of sync with reality (which happens 4 times a day for about an hour. In this case build-deps will fail to install, requiring a retry or give-back), and similar things.

Other things are less common; but because of that, they are not routine and require an in-depth investigation. Sometimes the fix is to just file a bug report and/or to mark the package as 'failed' (and let the maintainer or a porter handle the problem); sometimes the failures are due a maintainer script in a package being utterly broken, resulting in either some build-deps being uninstallable or (worse) the buildd chroot being fucked up. Sometimes a build is interrupted halfway through, leaving the chroot in an unclean state (sbuild is not pbuilder, and does not remove and recreate its chroot between builds). This would push us to category 3 of our work.

Basically, however, figuring out which is which takes some experience. Not all compilers are based on gcc (there are some really weird languages in Debian), and thus not all of their error output is the same; learning their different error modes can help quite a lot. Additionally, by continually compiling 10G worth of software, you'll be stress-testing your toolchain. If you've never seen an 'Internal Compiler Error' before, you will once you become a buildd maintainer, and it helps if you know what they are and how to deal with them (even if there isn't much one can do beyond filing bugs).

Obviously, handling failures takes some more time than does handling success mails, and it's not something I do quite as often. The exact time between both varies, but it's usually somewhere between a few days and one or two weeks—unless I suddenly stop receiving success mails from one of my buildd hosts, in which case I know something is utterly wrong and will usually investigate immediately.

State handling

With 'state handling', I mean managing the state of a package in the wanna-build database. There's help about this from the people on the debian-wb-team mailinglist; call me oldfashioned, but I still do consider this to be the final responsibility of the buildd maintainers. After all, the routine state changes are a result of decisions that I make; as such, if I fuck up, it should be me who fixes the fuckup. Also, if I mark a package as 'failed' because I believe the maintainer fucked up, then the debian-wb-team people may not know about my reasoning there, and might give the package back to another failure (although I would consider the latter pretty rare).

These requests are pretty common. Quite often, they're unnecessary—many maintainers are unaware of the intricacies of the wanna-build system, and may misunderstand that when a build is in dep-wait state, it will automatically migrate to needs-build once dependencies are available. About as often, however, they are very much necessary, and, since regular Debian package maintainers do not have access to the wanna-build database, require someone who does have access to said database to update it for them.

Having said that, there are cases where I will preemptively edit the wanna-build database. Usually this is to do something useful with packages in 'Building' state that have been in that state for far too long; either upload the package if its signature mail got lost (which happens once in a blue moon), or give the package back if its build was not attempted even though it is marked as such (this should not happen, but the system is not perfect and it does). Sometimes this is because I figured out that some common build-dependency (say, the GTK or Qt libraries) are in a transitional state and currently not installable; and rather than having a build daemon try a bunch of packages and failing them all, I may want to note in the wanna-build database that they should not bother attempting these 75 packages before the GTK package was done. This isn't done as often on the official Debian machines (since the release managers will do it for me there), but in m68k we do need to do this ourselves.

These kind of requests happen once every few days up to once every few weeks, and take little time to deal with.

Host and chroot maintenance

This is the hardest and least fun part of buildd maintenance, but it is just as necessary. Luckily, it is not as often needed.

Because Debian Unstable is a system that's in a constant state of flux, often things will break. This is even more of a problem on a buildd chroot, since it builds out of incoming; a maintainer may upload a package with a fucked postinst script, have its build succeed, but then fail spectacularly to install. This maintainer may notice that, and may upload a new package half an hour later. As such, the broken package will not end up on the system of a user or Debian Unstable, but between the time of the upload of the broken package and that of the new package, the old package will be available to buildd hosts, who may use it to completely and utterly destroy their build chroot. The joys of having a high turnaround time.

Luckily, Debian package maintainers are not stupid, and this kind of fuckup does not happen every other day. It does happen, however, and when it does, this often means manual work for the buildd maintainer. In the best case, it's a matter of syntactically fixing a postinst script and calling 'apt-get -f install' or 'dpkg --configure -a'. In the worst case (which is almost, but not quite entirely, totally unheard of), it's a matter of rebuilding the buildd chroot. In addition to that, a machine which runs 24/7 for the sole purpose of building packages tends to generate quite a lot of disk activity, which in turn tends to be detrimental to the disk in the long turn. If not looked after properly, disks will die, taking the entire buildd chroot with them. That requires rebuilding them. Obviously, this last issue is dealt with by the Debian System Administration team in the case of official Debian hosts, but the same is not true for the m68k port.

A somewhat more common thing that needs to be taken care of is the fact that buildd does not in all cases clean up after itself. For instance, when a new version of a package is uploaded to the archive between the time that the buildd host built it and the time the buildd maintainer sent the signed .changes file back, then buildd will say "I haven't got that package taken as Building" and refuse to upload it. This makes sense (you can't upload an old version of a package, since there wouldn't be any source for it, and dak would refuse the upload), but it does mean that the packages aren't cleaned out. Arguably a bug in buildd-mail, over time it will result in the disk filling up with outdated packages, and those require manual work from the admin. I recently (as in, a few hours ago now) finished a script to check each .changes file in the "build result" directory against the wanna-build database, and list those that are no longer necessary. I already had a script that, given a list of .changes files, would remove every .deb file listed in the given .changes files, and then proceed to remove the .changes files themselves. Combined, these do make that kind of work somewhat less of a burden.

As said, this kind of work does not need to be done all that often; for instance, I just cleaned the build result directory on voltaire and malo, my two powerpc buildd hosts, and found old files from late 2008...

And that's it, I guess. It may seem to be quite much, but in reality it isn't; the thing I've always liked about buildd maintenance is the fact that you do something little for Debian every day, but that it ends up being something big and helpful after a while.

Of course, the little things are the cherry on the cake. By looking at a lot of build logs, one eventually learns a thing or two about build systems, which is valuable knowledge. Getting build logs from the whole of Debian allows one to learn things about the archive that many people don't know about—for instance, did you know that we had a package called trousers? I didn't, until I signed the buildd log...

Update: changed the URL of this post to be under the buildd/ directory, rather than having it conflict with that and thus killing its permalink and making it impossible to comment on this post. Oops.

/en/computer/debian/buildd

PermaLink

Tue, 21 Jul 2009

Security modules in firefox

One bug I have open against the belpic packages is that upon installation, the security module should be enabled so that the user doesn't have to do this anymore. While I tend to agree that this might conditionally make sense, the problem, of course, is making it actually work that way.

The SuSE folks have written a mono utility to easily enable and disable modules in firefox, thunderbird, and OpenOffice.org. While that's fine, I'd like to be able to enable or disable this security module on a system-wide basis.

Unfortunately, unless I'm missing something, that doesn't seem possible. That is, I can use modutil from the libnss3-tools package to create a security module database in /etc/iceweasel/profile (which gets symlinked to from /usr/share/iceweasel/defaults/profile), but firefox then conveniently ignores it.

I'm guessing the reason for that is the fact that usually, such security modules want to have certificates to go with them. In that case, you wouldn't necessarily want to share them with other users.

But in this case—a security module that enables the use of a smartcard reader to read a key from a smartcard—enabling the module system-wide should not be a security risk.

/en/computer

PermaLink

I love vista.

No, I don't use it, and I wouldn't want to. However, its hardware requirements are so ridiculously high, that hardware manufacturers these days have no option but to seriously bump the performance of their systems. As a result, they ship with ridiculous amounts of RAM and CPU power, while still keeping prices reasonable.

Of course performance still sucks your pants off if you indeed do use Vista, but not if you use an actual operating system.

I love vista.

/en/computer/hardware

PermaLink

Fri, 17 Jul 2009

Death

GNOME-KEYRING MUST DIE

that is all.

/en/computer/cluebat

PermaLink

Wed, 15 Jul 2009

RepRap: followup.

I received some comments on my previous blog post; one of them I guess was from one of the people who helps develop reprap, and who pointed out that the Java software is not the only thing; there are apparently alternatives in python, and a C-based one in development. Goodie.

Another managed to put out this gibberish:

I'd just like to point out that C and POSIX isn't very easily portable to the majority of computer systems that users use (ie. Windows), not to mention that C doesn't have a whole lot of abstractions away from the OS (eg. building up path names is not easily portable in C).

My friend, that is why they have these things called 'libraries' and 'cygwin', or even 'MingW'. There are many programs who were written in C and who are portable across Windows and POSIX; Apache, OpenSC, to name but a few. I'll grant you that it is more work to develop applications that are cross-platform using C, but that doesn't mean it can't be done. At least, however, they'll be easier to install.

/en/computer/hardware

PermaLink

RepRap

Stumbled upon RepRap. Seemed interesting. Before trying to build my own, however, I thought I'd have a look at their software.

So, I downloaded the thing. Then had a deep sigh, as the bloody thing uses Java. And they still live in the middle ages, since the 'Linux version' ships with some .so files for i386 only. Fidgeting around until I find the right version of the amd64 .so file seems somewhat hard.

I think I'll pass on that one, for now.

Whenever someone tells you that 'java' is the right solution if you're looking for 'portability', they're on crack. Seriously. I'll have C and POSIX any day, kthxbye.

/en/computer/hardware

PermaLink

Tue, 14 Jul 2009

Serial API

I've previously expressed my "love" (ahem) for the serial port protocol. There are just too many options.

Now while I dislike the hardware I've never had the "joy" of working with the POSIX serial API. Until now, that is.

If I were nine, I'd say mommy, make it go away!

Whoever came up with the idea of the CREAD control flag (which enables or disables reading from the serial port) and made it be the default to disable reading from said port, should face criminal charges for making life unnecessarily miserable.

That is all.

/en/computer/hardware

PermaLink

Mon, 22 Jun 2009

Dear Google,

Why oh why does Google Maps return Vismarkt, 2500 Lier, Belgium as a result for a search for Vismarkt, Mechelen, Belgium? The place I'm looking for is here, thank you very much.

/en/computer/cluebat

PermaLink

Mon, 15 Jun 2009

On Mono etc

There's again a whole slew of arguments going back and forth about mono.

Me, I don't use mono-based applications anymore. I used to be a Blam! user, until I found Liferea. I used to be an f-spot user, until I switched to digiKam. The reason, in both cases, was that the mono-based applications were much, much slower than their non-mono-based alternatives.

But I don't care either way. If people want to write an application in Mono, that's their business. If other people dislike using it, that's also their business.

What bothers me is the whole band of morons who think they have a say about the subject.

Let me spell it out: the personal dislike of a user is not, and will not ever be, a reason to keep mono in or out of a distribution. The only thing that is, is the availability of alternatives.

Or, in other words: if you dislike mono, don't whine. Instead, be constructive (like the gnote people) and provide alternatives.

If you're not willing to do that, you don't have any say in the subject. It's as simple as that.

It's funny sometimes. When Sun developed Java, it was not free software. People never complained about that; at least not very much. Eventually Java was made free software, but the rights to the Java name and what it encompasses are still firmly held by Sun. Nobody whines about that (and rightly so).

With technology coming from Microsoft, however, everything in that regard is totally different. For no particularly good reason...

Oh well.

/en/computer

PermaLink

Sat, 06 Jun 2009

NBD, TRIM, and sparse files

Ever since I read about the ATA TRIM command, I've been thinking that something like that would make a lot of sense for things like NBD.

Currently, it's possible to serve a sparse file using NBD. I often do this, for example, testing things like the fix for Bug #513568 (nbd-server choking on a >3 TB RAID device) which would otherwise require me to spend significant amounts of money so that I get enough disks to test. Obviously that's not going to happen.

If we're using sparse files, that means we claim to export more than we actually do. This is obviously useful for testing, but there are other cases where this kind of behaviour could be useful; for instance, when exporting swapdevices to several diskless clients, it would be a rare case indeed where all those clients need all of their available swapspace; it might be safe to slightly overcommit the disk space on your hard disk, on the assumption that none of your clients is going to use all that space at the same time.

Similarly, when a file is removed on a filesystem on an NBD device, the kernel might use the generic TRIM layer described by Ted in the article above to relay that removal to the nbd-server process, which could then make sure the diskspace is deallocated.

However, unfortunately, there currently is no way for an nbd-server to tell the kernel to create a new hole in a sparse file. Creating sparse files is done at file creation time; if you later want to add more holes than you did when creating the file, you need to recreate the whole file from scratch in order to do so.

Additionally, when we're talking about a large amount of data that needs to be removed, it's usually much faster to say 'remove this block of data' rather than 'overwrite several megabytes with zeroes here'—not just in API, also in kernel-side implementation, provided the filesystem supports extents.

I think it might be nice if there were a public (userspace) API to tell the kernel that particular bits of a file or a block device are no longer required, and that they may thus be removed. But then, I'm not very experienced with kernel code, and it might be that I'm just plainly missing something here. Anyone?

/en/computer/code

PermaLink

Sun, 31 May 2009

COBOL

According to The Registry, COBOL is now slightly over 50 years old.

I wish I could say I never wrote a single line of COBOL, but I can't. In college, I was taught COBOL for three long years. Even though I've managed to purge most of that knowledge from my brain (good riddance), I still have nightmares about the horrible way in which one writes COBOL.

I wish I could say COBOL is dying, but it isn't. People still write new COBOL today. I mean, seriously, there's a standard called 'COBOL 2002. 'Nuff said.

I wish I could say COBOL isn't a problem, but it's the sole source of most of the Y2K issues way back when. Its features invite many of the kind of horribly wrong coding styles which cause bugs; Y2K is just one.

I wish I could say COBOL code is pretty, but it isn't. Just to give one example: the first 7 characters of every line of code in each and every COBOL program are 0x20. That is, space. Nothing. Utterly useless. There is no reason for this in modern environments, yet it's still there. Note why I dislike significant whitespace. Another example is the fact that you can't just say 'foo = 1 + 1'. Instead, you have to say 'MOVE 1 TO FOO', and then add a second statement that says 'ADD 1 TO FOO'. I'll just use english if I want to write a novel, thank you.

I wish I could say I didn't care about COBOL anymore, but for some weird reason, I do.

And just in case you were confused: no, I do not have warm, fuzzy feelings for COBOL.

If there was a button that would nuke all the COBOL code on the planet, would I push it? Probably not immediately. I'm sure it would take time for me to recover from the sheer joy of knowing that this button actually exists, before I'll be physically capable of keeping my hands steady for the amount of time required for me to actually be able to push it.

COBOL is proof of either the absense of any deity, or the existence of the devil. Given the chance, no sane person, let alone a sane deity, would allow the creation of such an abomination.

At least I don't have to deal with it anymore. That part is not going to change. Ever.

/en/computer

PermaLink

Sat, 16 May 2009

Belpic 3.5.2 has been released.

... and this time, with the source. Finally; it's been about a year since 3.5.0 came out without any source.

That's not to say it's going to be in the archive tomorrow; they changed the build system (again), and the source has been overhauled to such an extent that it basically isn't even the same software anymore. I'll have to re-learn everything, make sure it builds properly, and hope to do so by the time squeeze releases.

Yes, I realize that squeeze is still far away from release. Sigh.

Perhaps this is a good project for debcamp...

/en/computer/debian/belpic

PermaLink

Mon, 11 May 2009

"Please file a bug!"

I received a few comments on my previous post, some of which suggested that I file a bugreport explaining my thoughts. Of course I did consider that; and I do agree that in many cases, filing a bugreport is the right thing to do. However, this is not always the case.

There are times when you just know that a bug which expresses your feelings towards a particular thing will just be closed on sight, or at the very least tagged 'wontfix'. Filing a bugreport in such a case is just not helpful, and a waste of both my time and that of the maintainer. As such, I just don't do it.

Instead, what I will do is rant. Not because I want to annoy the world, but because it helps me to blow off steam—that's what my blog is for. Also, writing out my thoughts on a particular subject will often help me to reconsider things in such a way that I'll be able to better formulate what the real bug really is; and if it doesn't, it's likely that other people will respond and point me towards what I'm misunderstanding—if I am—so that, again, I might be able to better formulate what the bug really is.

If I sound frustrated in a rant, that's because I am. The simple fact that someone changed something in a piece of technology that I'm using with the intent of improving things should not have to mean that I agree that it is, indeed, an improvement. I will not hide my feelings because it might offend someone. I've done that too much in the past.

So please, pretty please, with sugar on top, when I'm ranting, do not tell me to file a bug report.

That is all.

/en/computer/cluebat

PermaLink

Console-setup sucks

I have a few reasons for this:

1. It wants to change the framebuffer font without asking. I seriously dislike the font it sets up.
2. I have a habit of writing my own Xkb keymap. With xorg <= 7.3, that meant creating a file /usr/share/X11/xkb/symbols/wouter and having something like Option "XkbLayout" "wouter" in xorg.conf. Console-setup doesn't pick that up, though, and loads a default keymap that somehow looks closely similar to what I'm using.
3. What's worse, the default keymap it picks up on my Apple Powerbook (which isn't my primary laptop anymore, but considering how my actual primary laptop is in for repairs, is what I need to use for now) is a PC Belgian AZERTY keymap, rather than the Apple AZERTY. This is *wrong*.

I might understand why they did this kind of thing, but the current implementation of autodetection is horribly broken.

/en/computer/cluebat

PermaLink

Mon, 20 Apr 2009

On Xorg and HAL

Recently there's been a bit of a fuzz about the fact that the xorg folks have introduced HAL as a requirement for X. I understand this is to make things easier.

So instead of configuring stuff through /etc/X11/xorg.conf, you now have to configure things through /etc/X11/xorg.conf, /etc/hal/whatever, and /etc/default/console-setup. In three completely and utterly different syntaxes, no less (xorg.conf format, XML, and shell script). How exactly this is 'easier' escapes me.

I presume this makes life easier for those multiseatcomputer folks; but for those of us with a normal computer, it doesn't, really.

Oh well.

/en/computer/debian

PermaLink

Sat, 18 Apr 2009

Using NBD to get rid of an LVM installation.

LVM can be a virtue. However, it can also be a pain at times; for instance, there's loss of diskspace due to LVM's metadata that needs to be stored as well. This amounts to approximately 5% of the diskspace (if I'm not mistaken), which can be quite a bit. Also, this is an extra abstraction layer, which requires memory and CPU time to be processed. This will be negligable on most modern computers, but sometimes it isn't.

I had a system that had quite a few things on LVM, and wanted to get rid of them. Unfortunately, to remove the LVM physical volumes would mean that I'd have to get rid of the data, which would mean storing it somewhere else, which in turn would probably mean that I wouldn't be able to use the system for quite a long time. That wasn't acceptable.

So, instead, what I did was to export a whole hard disk (one with enough space to hold the logical volumes on that machine) using NBD, and migrate stuff that way:

• First, set up the NBD export. The config file should look something like this:

[generic]
	user = nbd
	group = disk
[export]
	exportname = /dev/hde
	port = 1234

This will export all of /dev/hde on port 1234. Obviously you wouldn't want to do this on an untrusted network, but that's always true with NBD (in my case, the link was a 1M crossed cable -- quite safe).

• Next, we'll connect the client:

nbd-client <server> 1234 /dev/nbd0

... assuming /dev/nbd0 is not in use yet. Provided the client machine is running kernel 2.6.26 or newer and nbd-client 2.9.10 or later (e.g., Debian Lenny or later), and you're running udev, this will create a number of /dev/nbd0pX device nodes, with X starting at 1, one for each partition on the disk. Of course, one can also export a specific partition rather than the whole disk, or just one file on a filesystem, or create a physical volume of the entire disk rather than just a partition -- your choice.

• Now we need to add the networked block device to the LVM volume group. Assuming the second partition is the one we want to use:

pvcreate /dev/nbd0p2
vgextend /dev/<vg> /dev/nbd0p2

If you now run 'vgdisplay', you'll see that the size of the LVM volume has increased considerably.

• Next, we'll want to move data over the network. Assuming the 'local' LVM volume is on /dev/sda7:

pvmove -v /dev/sda7

This will show progress information every 15 seconds while the data is being moved from the local hard disk to the NBD device. You'll be able to continue using the system as usual--although of course the system will gradually get slower and slower as more and more data is only available through a comparatively slow network connection.

• Once everything's moved to the other sytem, you're all set to change stuff locally:

vgreduce -a /dev/<vg>
cfdisk /dev/sda
...

• Finally, you'll need to move the data from the NBD device back to the local hard disk. If you're still using LVM, that can be done using another pvmove operation. If not, you'll have to do something else, like cp -a. Obviously in that case, there will be some time in which you won't be able to use the system properly.

This final step might not be as simple as it sounds; e.g., if your /home filesystem is on LVM currently and you want to move that out of LVM, you'll have to make sure only root is logged on; If /var is on LVM, too, you may have to go to single-user; etc. Figuring out the details for this one is left as an exercise to the reader.

However, I will note that since somewhere between etch and lenny, doing root-on-NBD is possible; and if you're running unstable, then doing root-on-LVM-on-NBD should be possible, too, although I would suggest a little caution before trying that.

In any case, using NBD in this way just saved me a whole lot of no-computer-time here. Which is great.

/en/computer/debian

PermaLink

Mon, 13 Apr 2009

Ugly fonts

This week seems like ugly fonts week.

First, KDE4 was uploaded to unstable. Now I'm not a KDE user, but I do cherry-pick a few KDE applications which I find useful or interesting, and use them in my IceWM environment; these are mainly korganizer (with konsolekalendar in my .bashrc), kdebluetooth, and digikam.

First thing I noticed is that something went horribly bad with the fonts -- see this screenshot for an example of what the problem is; the korganizer window in the background has ugly artifacts, while the kbluetooth menu in the foreground is still a KDE3 window which does what I was expecting.

Second, someone thought it good to add console-setup as a dependency of Xorg 7.4. Now by itself, there's nothing wrong with that, except for the fact that console-setup by default changes the console font to something else. I had, in fact, tried out this setup a while back, but eventually (after a few weeks), decided that I did not like this font, because it's a) ugly and b) unreadable on a high-resolution 12" display.

So I changed /etc/default/console-setup to get the VGA font back, ran the console-setup initscript, and all was well.

Until my laptop was resumed from suspend-to-RAM. Apparently the console font is changed at that point in time, too, with some other configuration, and I'm not sure how to fix it.

Oh well.

/en/computer/debian

PermaLink

Mon, 30 Mar 2009

Cinelerra as an advocacy tool

This weekend, I was going to go to an acquaintance so that we could edit the material which we had filmed at the concert. Yes, we did use DVswitch, but due to me being somewhat late in proposing a video team, there was no team, and hence nobody switched anything. So instead we'll have to edit stuff now.

Since I'd never done anything of the sort before, I guess it's fair to say that I'm not exactly the expert. As such, I installed samba, plugged the (LVM2/ext3 formatted) external hard disk containing the movie files to my laptop, and served them over a gigE link to his; the idea being that we could then do the editing on his system, using the software which he knew.

After having copied those files (one 22G DV file, one 15G one, and a few much smaller ones), he loaded them into the editing software. Which promptly sat on its ass, making us wait, as it 'analyzed' the movie clip. This of course took ages.

As said, I don't really know a lot about movie editing. However, in preparation to this, I had been playing with Cinelerra CV, and so I knew that this particular application does not require such an utterly useless delay. This I told Werner, who got interested. So we went over to Cinelerra's website, and had a look at the features list.

That got him interested, and he suggested that it might be more interesting for me to install Linux and Cinelerra on his laptop, so that he could do the editing using that, rather than the Windows application that he wasn't entirely fond of anyway.

So I did. A few hours later, everything was up and running, we had had lunch, and we were copying data from my external hard disk to his. As we were waiting on the data to be copied, I installed foobillard, and we had a bit of fun playing pool and snooker.

Closing words, as we were wrapping up and he had a slightly more general look at the system: "sortof useful these days, isn't it?"

Sure.

I really believe that this kind of thing is the ideal way to do advocacy; rather than suggesting freedom for freedom's sake, one should suggest something people actually care about, and work from there.

Of course, that doesn't always work.

/en/computer

PermaLink