Abstract nonsense

Damien’s original message to the foundation list was pretty clear : we have a quite new contributor — new meaning he doesn’t have svn write access, and “quite” new meaning he made already a few big and interesting contributions. We want him with us, in gnome. But he has to go through Damien or myself every time he has something to change, because he can’t get an svn account.

The discussion which ensued (still going on…) about svn & git misses the point entirely : we would like to accept him as an equal! Whatever the tool, if he has to go through us to proceed, this isn’t a suitable solution.

As I already mentioned on the foundation list, svn isn’t the real problem : gna! uses it, and a maintainer was able to grant me access in an hour after I provided a public ssh key.

Perhaps I should contact gna!’s people and learn how they do their tricks.

Eh, quite a few things happened since my last post :

• I turned thirty ;
• I got a new shipment of students. Of course, I couldn’t resist and put them to a surprise test on the previous year (first five minutes with me : how rude!). The average was 3.5/20, which means they will have to work both for understanding the new material, and re-work the old : poor them ;
• I finished doing some refactoring in ekiga, so I’ll now debug said refactoring. I know I introduced at least one problem, so I’m wondering is why nobody complained yet.

So, we have gnome‘s gconf, KDE‘s kconfig (yes, the same name as the target when you want to configure a linux kernel using a qt interface), but we also have dconf, which is a new configuration system for gnome (yes, the same name as this) and elektra, which is even more ambitious.

As an application developper, my initial reaction to this list is a little despair : << Ouch! Do they all expect me to follow their trail!?>> Then my second reaction is : <<Eh, I’m an ekiga developper, and I already coded a wrapper for the system configuration — so hopefully, whichever wins, ekiga will easily switch>>.

Those days, ekiga’s svn trunk is a little bumpy — which is quite normal since it’s being worked on from all sides : network, devices, codecs, base design. But it still works sometimes!

And so beautifully! I took the habit of calling normal phones through it using my ISP’s SIP service, which means most of my calls cost nothing (well, nothing more than the usual fixed fee, of course), and I don’t have to chase that stupid cordless phone wherever my wife chose to lose it.

Notice there are people who don’t break trunk, but still do amazing work : translaters and documenters. This work can go unnoticed because it doesn’t end up with a nice big crash or a new shiny feature, but it still counts so much for the “normal” user!

Ekiga 3.00 will just rock!

After months of outside work, the framework I wrote for contacts in ekiga is finally finding its way into the svn repository.

It’s still lacking trivial features like a search function, but that will come fast : after all, much of the work was trying to come up with something more flexible!

As I already mentioned, I worked on revamping ekiga’s addressbook management those last months (yes, it’s long, but I only have spare time, first wrote GObject code, rewrote in C++/sigc+ — did I mention I have a family too?).

One of the goal of the framework is to give access to the same type of addressbooks as the current stable ekiga — that is of course evolution-data-server and LDAP, but also to KDE’s addressbook.

The most important thing is to display those contacts, but there are three other things we will want the user to do :

• add new contacts, which isn’t very complex since we basically want a name and an address but can give issue (see third point)
• remove contacts, which is trivial
• edit contacts, where things get more hairy

The reason why it gets hairy is that the number of different addresses ekiga can be interested in is quite large, and can be found in quite a few places — there’s obviously the badly named E_CONTACT_VIDEO_URL, but there’s also all of the E_CONTACT_PHONE_* !

Of course, one would think — like I did — that it was just a matter of calling the right api to get a wonderful edit window on the screen. But alas! It doesn’t seem to exist…

So we have openedhand‘s nifty contacts program, which implements a contact-editing window, and gnome’s integrated solution evolution, which implements a contact-editing window. Both based on evolution-data-server.

A quick inspection of the debian packages shows that there is a libedataserver and a libedataserverui, but only a libebook without a libebookui. A quick inspection of the api shows that in fact, libedataserverui contains ui portions for libebook — but no contact edition.

This is the reason why I just reported this as a bug. That won’t necessarily make the ball roll — the best would be if I could spare some time and prepare a patch. But I’m pretty hopeful showing there is an itch to scratch there will make someone move. Especially since there is ready-made code to build upon in two projects!

So yesterday evening I was hacking on ekiga, and compiling it all over again. For some reason, the load began to rise, and the box was soon unresponsive… Something it had already done a few days ago. Sigh. It ended up with an unnice reboot.

This time too I finally rebooted the box (magic keys). Of course I asked for a sync. But on reboot… the bios rebooted, but grub stopped with a sinister error 16.

Since it’s not the only computer at home, I could search what that mean : something wrong with the filesystem. Ouch.

Easy escape : since I’m in the process of selecting a new laptop to buy, I have very recently burned a live-CD (well, two : ubuntu & mandriva). So I try to boot on them.

Ha! That was supposing that the flaky CD burner which successfully burned them just a few days ago was still able to work. It doesn’t.

So I find myself with a box unable to boot on the harddisk, and unable to boot on CD. Things get interesting at that point.

I end up peeking in the BIOS, trying to find out what that thing is able to boot on (I have an external USB harddisk). Ah! It is supposed to boot from network too.

It took some time to dig for an appropriate ethernet cable to hook to another box. I installed a dhcp server, a tftp server… fought long to make things work, and finally the laptop boots on debian’s netinstall. Yeah!

Unfortunately, debian’s netinstall has everything to configure network interfaces, but nothing for harddisk access. Aie.

Well, that’s easy : just get another kernel+initrd.img, then reboot. Yeah again!

Since grub has issues booting, I just went straight at /boot/grub/ to see what it looked like. I just get a list of the files in there with “permission denied” in front of them. That explained a lot.

A little mv later, I had no more buggy /boot/grub/ to hinder me. But since I highly doubted it would be enough, I decided to go for reconstruction surgery : I still had grub’s .deb in /var/cache/apt/archives/, so with little effort (ar&tar) I could rebuilt my directory except menu.lst and the system map. That had to be enough.

And it was : since it had no menu, grub gave me a command line. Typing qwerty on an azerty was a game after what I had already gone through, but I finally could boot on my poor system.

Both my system and home partitions had many, many errors, and needed repair.

The final steps for reviving the system was just playing with grub-install, update-grub, a little customization and update-grub again.

I think reiserfsck made a good job repairing my partitions, but I’m still wondering :

• what did I lose except /boot/grub? (perhaps I could have salvaged it if I had run the check from the debian image instead of after booting) ;

• how come I lost this directory?! I don’t think it was in use when the problem occurred, so I’m bewildered at how it could be affected…

I think I’ll keep my backups even more up to date.

My last post about vala was seen by some as a little trollish. I must admit that the title was a silly joke, and the closing suggestion about rewriting parts of gtk+ with it was a little far-fetched.

But still, given the choice between on the one hand :

• writing 1000 lines of code
• maintaining all of them myself
• using a community-written toolchain

and on the other hand :

• writing 10 lines of of vala code
• maintaining those myself
• using another community-written toolchain

I wouldn’t hesitate a second! After all, I’m used to writing things in a language, and expecting the toolchain to give something correct with it. And this expectation is generally met.

Of course, you’ll notice I wrote “toolchain” and not just “compiler” — indeed, as noted for example by Dodji of nemiver fame, having a good preprocessor is good as long as you are able to debug your source, and not your preprocessed source.

So vala is lacking a suitable debugger. That will indeed hinder its use on a large, serious scale. But what they have already is certainly enough to have some fun, and as such, I have high hopes said debugger will just pop in existence one day.

So while my work on ekiga now uses C++/sigc++ and not C/GObject anymore, which means I probably won’t contribute to this undertaking, it certainly doesn’t mean the vala project is uninteresting — nor that I am uninterested.

Don’t we know another little opensource desktop project which uses a preprocessor, although being C++-based, by the way?

Born 2007-08-11 at 23:45+0200. Stop.

2kg940. Stop.

Baby and mother ok. Stop.

Father happy. Sleep.

Big image of a small boy