Roy's Blog

A Hacker's musings on Code | Tech | Life

So, I've been slowing going back to using GNOME instead of using KDE-4. I do this flip flop every once in a while as I'm never truely satisfied by either. Now, GNOME works quite happily on my Gentoo/Linux machines, but this is not the case on my favoured NetBSD ones. Or rather, parts of GNOME don't work as they should, like the Evolution mail client.

Evolution suffers two problems on my NetBSD box. One, it takes over 5 minutes to load and two, once it has checked and downloaded mail from my server it closes without error. The 2nd problem is probably a programming error in Evolution or one of its many dependencies, but the first problem could be anywhere! Research led me to this possible soltuion. If you look closely, you'll find an old post by me in that thread fixing it with ld --as-needed on Gentoo/FreeBSD, but that isn't a real solution for NetBSD / pkgsrc users. Anyway, at first glance the patch on that thread makes perfect sense. So I came up with better patches (one for glib, one for Evolution) and it now loaded in under 3 seconds! All was well :)

Well, not entirely. Other applications started to show isses as a result. So at least we know we're in the right area. I then spent a few hours wading through the Evolution build chain and came to the conclusion I still hate autotools as it obscures everything but was no better off fixing it. But I did come up with a test case that opened an evolution library and searched for a symbol that did not exist. This should 30 seconds, which is far too long and is also probably what the poster of the FreeBSD patch did in the mail thread.

Cutting to the chase, the runtime linker on NetBSD was checking the same library for the same symbol over and over again. Going back to the FreeBSD linker, they have a patch which implements a negative cache which should solve this. But it doesn't, as it doesn't cache missed weak symbols. Luckily this is easy to rectify and you can find my patch here and an updated one after performance testing elsewhere here. Now Evolution loads in under 3 seconds and crashes right away - but that's an issue to fix another day :)

Continue reading...

It's taken some time, but my terminfo implementation is now merged into NetBSD :)

No doubt there will be some fallout and flames, but it's all about bringing some needed modernization into NetBSD!

Continue reading...

My prior terminfo work has been completed and merged with curses. Userland applications have been re-worked where needed and everything is working just fine!

So NetBSD finally has an up to date replacement for the legacy termcap it currently uses. Well, it will have when merged - I've only just asked for testing so it might take some time before it hits -current.

Continue reading...

openresolv has been imported into NetBSD, which allows more than one daemon to update /etc/resolv.conf sanely and configure local nameservers for enhanced DNS, especially if running on a VPN. dhcpcd already uses resolvconf when available and dhclient in NetBSD has been patched to use it.

This is important for NetBSD, as many packages support resolvconf, but only when /sbin/resolvconf exists. This meant that a lot of packages that supported resolvconf, failed to work with any resolvconf implementation from pkgsrc.

PPP users who maintain their own scripts are encouraged to try it out :)

Continue reading...

Last night I added getdelim(3) and getline(3) to NetBSD.

A few programs in base system needed to be changed due to having their own getline function, most of which aren't anything like getline(3). Hopefully there won't be much fallout in pkgsrc as a result.

getline(3) is prefered over over functions such as fgetln(3) and fgets(3) because it's standards based and you get a dynamic buffer for really really long lines. However, POSIX did drop the ball on making it a standard from the GNU extension - it should return 0 on EOF and more importantly be called fgetline. Oh well.

I shall be rolling getline(3) support into dhcpcd later, but I'll have to do a link test in the Makefile to see if we can use it. I'm unsure if I want to have a mini configure for dhcpcd or to keep using just make extensions ....

Continue reading...