Diego Petten

This is one of the most strange moment of my (computer) life :P I actually have not one, but two backup copies of the important data in my enterprise and defiant boxes, and I'm going to do a backup of voyager tomorrow, adding also the not-so-important-but-still-interesting data in Enterprise. By the way I also found out that defiant's (the G/FBSD box) complete (/ and /home) backup is less than 600MB worth of xar data.

This is good and I'm actually happy of it. Unfortunately my mails are still an issue as they are stored in enterprise, while before I used to have a P166 which worked as mailserver/dns server/irc bouncer. Unfortunately that machine ("northstar") died when a spike reached it caused by my power provider. That sucks.

Ok now I have an Athlon-Thunderbird 1GHz spare, but that does *a lot* of noise and I don't have a fan to replace its one, and also that is the G/FBSD box which is all but stable right now.
I also have hardware for a P3-550 here but I don't have the RAM to put on it and this is bad as the RAM I have is completely b0rk3d.

I'd really like to find some spare box to use as misc local server, currently if I have enterprise down I can't even have a decent DNS in place, but for now I don't have money to bough a new one. The P166 costed me €50 in late November '04 and died on February '05, so that was wasted money. Also if now I have an UPS to protect this, I'm going to wait a bit more.
I'm also thinking about finding an embedded something to use as router as mine doesn't support IPv6 (ok it can be seen as something useless, but having a single IP for a machine is useful to access it from the outside without having to bounce between with SSH).
Oh well I'll wait till the next hard-discount meeting in Pordenone next November.

Yesterday, also if I worked on my FlameBot, I had to bump some packages I'm maintaining.

There were new versions of libtorrent and rtorrent, which is not unusual as it's being developed quite often so a bump is quick, unfortunately both libtorrent and rtorrent must be in sync to the same version so just a rename isn't good (as the versions of the two are different and I need to change the dependency every time.
Not a big deal, tho, as quite all the problems with FreeBSD are fixed and upstream is likely to fix them if they come up.

The other one was... VLC. And here it starts the problem. Some time ago I added a 0.8.2_beta2 version to test a bit the new features and the new dependencies, this was useful to find a showstopper bug on AMD64, as some ASM code used on AMD64 was just x86-specific, which I reported upstream. This bug still isn't fixed in 0.8.2 final.

Now I'm trying to fix two (or three) issues which still seems to be a problem: wxGTK screwing up on some systems (and slp still not working) and Mozilla support not working.

Now, the slp problem was supposed to be fixed upstream after 0.8.1, but this seems not to be the case, and wxGTK problem it's something I can't still reproduce and I need to investigate further.
Now remain the Mozilla problem. +mozilla on VLC requires using www-client/mozilla, but I don't want to compile it all. Then I first tried moving the dep on an or between mozilla and mozilla-firfox, but then xpidl is moved fromt he default location.
Following Roy's hint I tried compiling gecko-sdk, but first this failed because of amd64+gcc4 screwups (logical screwups, as I already wrote about).
After fixing that, I found out that enigmail code, too, has problems, but fixing that is not what I need to do for now, I'll do later but for now I want to fix VLC ASAP, so I removed enigmail support and I'm trying to rebuild it again...
This is going to be a long build, a long long build, and I don't really want to be in the place of users who'd like to use vlc +mozilla...

Ok last weekend I was bored, a lot bored, and then I decided to write something from scratch.
That's my hobby, when I'm bored, I need to do something from scratch, even if it's useless, even if there are better alternatives which works great already.

This time, I wanted to write a bot for IRC. Actually that's not the first one I write, I wrote a quizzer last year, in C++/QT with PostgreSQL backend.. a bit overengineered, perhaps.
Now, on #gentoo-dev @ freenode we have a lot of bots already, so I'm not making it join that channel, but I wanted something interesting with not just gentoo support.

As I hate perl, and going with another C++ bot wasn't an option, I relied on Python with pyirclib support (yeah I know it's a bit deadish).

First, I tried writing a weather bot for my lug's channel, but then I changed my mind as I wasn't finding a good place where to find forecasts and observation in a bot-parsable fashion.
Then I started looking for bugzillas support.. I started it as a simple function, but now it's a module on its own (yes I did it modular at the end) which loads from an XML file with data about different bugzilla sites and then search for bugs in everyone when asked. It was simple as bugzillas have a good XML interface to load the bugs' data from. The only problem was with OpenOffice's IssueZilla because it uses different tagnames in the XML data.

After that I added a module to display freshmeat projects' data, then a gentoo module with a "glsa" command which shows data about the given glsa.

For last, I wrote a freebsd module, that's why the bot is now in #gentoo-bsd (with name ServoFlame), which shows data about problem reports on FreeBSD database (they aren't in XML so they are parsed with regexps) and about their security advisories.

Then finally, if you want to mess up with the bot, try it yourself or change it (or also write a new module for it), you can find the sources at http://digilander.libero.it/dgp85/files/flamebot-0.0.tar.bz2 . I'll put that on my site on http://dev.gentoo.org/~flameeyes/ later today.

Ok this is getting interesting.
As I bought new keyboard, and it's quite comfortable, I moved working using my desktop system instead of the iBook. This also because the temperature under my hands on the iBook is quite high because of the hard disk.

The problem is, as I have an AMD64 system, that I don't want to use OpenOffice as that's using 32-bit emulation, so I used KWord from KOffice which works good on its own, and it supports also OASIS OpenDocuments.
I must deliver using SXW format so I thought of just saving in OpenOffice format and then send, but.. lists aren't exported in OpenOffice documents.
Then I though of just saving in RTF and open them with NeoOffice/J on the iBook, but... different ordered lists are seen like one continuing list when importing RTFs in OpenOffice. Ok I'm now using KWord and just re-style the lists on NeoOffice/J, but this still isn't a good way to do, so I installed OpenOffice 1.9.109 here and thought of saving in OpenDocument format and then saving them using OpenOffice to the SXW format but... well it doesn't work, the OpenDocument saved by KWord and then loaded in OpenOffice doesn't contain any list.

The problem now is that I just know of two programs which supports ODT: KWord and OpenOffice, and this makes difficult to identify which of the two is at fault now.

:/

Ok as my paid job is getting to an end (well a book always have an end, also if in this case we can't say it's an happy ending), and the last chapter just took me less than 24h, I decided to take a day off to relax myself a bit.

Unfortunately, this was coincident with a bit of habit here at home to stay up till morning on 23th June, so I ended going to sleep at 5am and woke up at 16:30. The result is that half of the day was already gone and I hadn't had too much time to relax.

At the end I wasn't able to do anything I planned to do... my room is still messed up, my life too, and I haven't find a way to inject events in X11.

Oh well tomorrow I hope to complete another Chapter and maybe find the time to cleanup my room a bit at least.

OK today I've fixed the stray problem of the 4th experimental stage for Gentoo/FreeBSD after spb yesterday told me of them, and sent him the amended version of the tarball.
This is getting closer and closer to the release, as quite all the problem which I stumbled across are now fixed.
The bootloader has its own ebuild (sys-apps/boot0) and everything should be fixed as for now.

I've also dropped the dependency over tcp-wrappers for freebsd-usbin adding a NO_WRAP= glob which is enabled by -tcpd useflag; this allows us to avoid installing tcp-wrappers in profile.
As I was there, I also added one more NOINET6= variable which allows us to disable IPv6 support in rpcbind (where the tcp-wrapper dependency was turned on by default).

Also, we don't install telnet, rsh (and derivated) and inetd anymore in freebsd-* packages; if you want them, you can install the portage versions/replacement: net-misc/telnet-bsd net-misc/netkit-rsh sys-apps/xinetd.

If you want the ftp command, by default on FreeBSD it's used lukemftp, from NetBSD developer lukem, but this was replaced by its author with tnftp, which is in portage.
The daemon lukemftpd is still present, as is ftpd, also if I don't suggest it to anyone.

Please also note that for now you can't install /usr in a separate partition as there are a couple of things which needs to be fixed before.

Time to get to work.

OK I've updated my webspace on Toucan fixing the broken links, and removing part of the material I don't maintain anymore.

Mainly, there was references to tarball that I'm still searching in my backup sets and the articles (in Italian) I wrote some months ago were completely missing.

I think one of the things I should do in the near future is to release the code and the data I used to create the site; it's a quite interesting process.

Instead of writing all the pages by hand, or using PHP serverside (as I couldn't use PHP on my old site), the trick I'm using makes use of the PHP cli binary.
I've wrote a series of XML files with the data for the pages, and some "glue" PHP scripts which uses other XML files to create the XML files for the main script (the template). Then I launch a shell script which recursively creates the XHTML1.1 files which are then uploaded to my public_html space.

It's a bit complicated process but the result is a lot simpler, because I just need to add a section to an XML file to have a new complete page.

I really need to publish the code for this because it can probably be useful to other people, too.

Ok yesterday (Saturday, 2005/06/18) there was a "Linux Party" here in Venice (well not exactly Venice, but Mestre in the inland) where we tried to have a contact with new users and wannabe users, some of them from Venice's institutions.

It was an interesting saturday, considering that I usually don't do anything during saturday, but it was a very hot day and I hate hot days.

We had a couple of wannabe users who liked to know about Linux itself and some experienced user who wanted to be helped for something they didn't know.
Unfortunately, in spite of the amount of Gentoo installation in our LUG as can be seen during regular meetings, there wasn't new Gentoo users.
Anyway at the end I finished to fix a couple of Gentoo laptops (x86 and ppc, an iBook G4 which was the one with problems).

Unfortunately, many newbies just won't ever use Gentoo before they takes practice with Linux ideas, if they were just used to Windows.

It can be interesting... how many of the devs have an active LUG where they meet and how many of them are Gentoo-based? ;)

Ok after the rm -rf which TFU'ed my defiant box (the Gentoo/FreeBSD development box), yesterday night I started using the stage to install a new Gentoo/FreeBSD 5.4 system, this time without real FreeBSD support, just FreeSBIE LiveCD (thanks to Stucchi and all the FreeSBIE team), and the latest incomplete experimental stage I had.

It wasn't completely free to bugs and complete, but this was workable so I now have a working system and a TODO list of bugs to fix:

• from the stage I missed a bunch of packages (well some of them was just dued to the fact that the stage building process died before being complete);
• ldconfig needs to be used with -i option from within portage code to enable the "insecure mode" aka to allow it to use non-existant dirs (when preparing the stage tarball with ROOT=);
• python needs a new patch because the one which is currently applied doesn't add the support as it should because it doesn't regenerate configure script;
• there was a bunch of missing dependencies which I'm going to fix;
• gcc's problem with crt1.o makes necessary to compile it after freebsd-lib (with a tarbz2 package) and then re-extract the tarball... I'm going to fix this setting schg the crt1.o file;
• /dev *must* be mounted when compiling or scripts which tries to output on /dev/stdout fails, this also makes the built freebsd-lib fail to load;
• ncurses must be linked as libtermcap.so for freebsd packages to compile;
• bootloader misses an ebuild, and must be installed before kernel's make install is launched;
• /proc is required by init scripts but isn't required on G/FBSD to work;
• perl and libperl needs a patch because their Configure script is brainless.

Now that I know what I need to do, tomorrow I'll work on all those and hope to prepare the final experimental stage to release.... but now I'm really really tired.

Ok I've done something wrong. There was a rm -rf /usr without a ${D}, I fixed that quite immediatly in the tree but.. I forgot I frozen the PORTDIR while I was building the experimental stage for G/FBSD, so the fix wasn't applied to *that* tree that I used.
I'm currently trying to rescue that box because.. well I'm not sure if I'll ever be able to recreate a 5.4 setup on top of a 5.3 without the working environment.

I had buildpkg enabled but I did a stupid thing and bunzip2'ed all the file sto detar them forgetting that they aren't just tbz2 files.

On the good side, I should have been able to prepare a 3rdtry stage of just 17MB, without all the profiled libraries and with all the base profiles needed. But I don't know if it will works.

Now I'm rebuilding system with emerge -ave world, ncurses is building but I'm not sure how it will work...

Well, today is being a bad day.. really Friday the 17th (unlucky day here at least). Other than the problem with defiant (the G/FBSD box), I'm also having personal trouble with a friend of mine.. I 'll go to sleep sooner tonight, I want to put an end to this day ASAP.

I've already talked about why our patches rocks, but now I wish to talk a bit on a interesting practice all downstream maintainers (package maintainers) can use to improve their work.

Most of the packages used by a distribution are already present in other distributions; some of them are also already patched for some reason, for their own layout or for real bugs. Some of the things which I needed to do for Gentoo/FreeBSD was looking for specific patches in FreeBSD's ports. To do that, I found very very useful FreshPorts where I subscribed for a couple of packages so to have notify when they are updated (mainly the ports for the packages I maintain and for a couple of bsd-related packages).
Another site which is a lot interesting is the Debian Package Tracking System where you can subscribe to packages notices for new version of debian packages.

Being able to see when other distributions changes a packages makes a lot simpler to manage the changes and merge them on our packages. Also if they don't submit the patches upstream because they change them in a way which is strictly related with their combination of libraries or os, we can fix them and submit them upstream so next versions can have the bug fixed without needing a patch. This is the case for example of a couple of problems with libtorrent and rtorrent on FreeBSD systems that I had pushed upstream or of the xine-lib patch to allow esternal mad support.

We also have something like that as Gentoo-Portage.com which allows devs from other distributions to find out when we change something, and this is good.

I think that sharing patches across distributions and OSes is going to be a great improvement for the users, because they can always have updated packages looked after by many more people...

But now the question is... there are other Linux distributions which has bsdtar? :P

This can seem like some strange and absurd thing, but bsdtar on Linux is quite an interesting topic.

As many of you know, I'm one of the Gentoo/FreeBSD developers; one of the things we want to be sure that is not changed when we use Gentoo/FreeBSD respect normal FreeBSD is the userland, not only the libc but also the utils. That's why we avoid replacing BSD utils and BSD libraries with version not used by default FreeBSD installations.
For this, we usually prefix 'g' to the comamnd names when they collides with BSD's commands, so we have gsed gmake gtar gm4 and so on.

But another interesting thing to do is using BSD userland on Linux, and this is quite always possible without problems. The bsdtar package is one of the best examples of that.

bsdtar handles few file formats which aren't managed by GNU tar, like zip files or cpio files, and handles them directly without spawn bzip2/gzip process and then another tar.
This makes a slight improvement in the time needed to extract things:

flame@enterprise ~/test $ time tar xf /var/portage/distfiles/kdelibs-3.4.1.tar.bz2

real    0m17.072s
user    0m5.763s
sys     0m1.190s

[ in the mean time the directory was removed ]
flame@enterprise ~/test $ time bsdtar xf /var/portage/distfiles/kdelibs-3.4.1.tar.bz2

real    0m14.421s
user    0m5.581s
sys     0m1.288s

and also the size is in favour of bsdtar:

flame@enterprise ~ $ ls -l `which tar` `which bsdtar`
-rwxr-xr-x  1 root root 266568 mar 18 19:34 /bin/tar
-rwxr-xr-x  1 root root 171392 giu 16 00:39 /usr/bin/bsdtar

(note: dates are expressed in italian also if I have LANG="en_US", don't ask me why).

bsdtar and GNU tar shares the same basic syntax, also if they aren't compatible for strange extensive syntax which is not POSIX anyway.

If you want to try it, it's in portage as app-arch/bsdtar, it doesn't overwrite your tar as it's installed as bsdtar (and then linked to tar if $USERLAND == "BSD") so it's safe. I'm wondering if there's a way to provide a selection of tar tools to use, as portage uses a quite portable syntax which doesn't seem to have problems with bsdtar anyway.

I hope someone will find that useful.. I for one I've set alias tar=bsdtar in my bashrc file.

P.S.: obviously linking tar to bsdtar isn't supported and nobody will ever support you if you do that, so please really avoid that, thanks.

Ok this is becoming a rite: everytime I buy a new keyboard, something is just wrong and I need to fix it. This time the problem was the extended keys as I already told in the previous blog entries. Well today I think I have dominated it completely, now it works :D

THe solution of this required quite a bit of work, but 34 hours after I bought the keyboard, it was working fine. I have prepared a a patch which can be used to make it working, but it's not complete yet.

If you want to know in deep which problem was it, the solution I found and the way to make it work if you have one, continue the read of this entry.

[little edit: I'm too used to use ~flame, but my username on d.g.o is flameeyes :P Fixed the patch's URL]

Pages: 1 2 3 4

Ok following my last entry, today I took the combination of situations to go finding a new keyboard with my syster.
The keyboard which I chosen between the not-so-vast-but-neither-too-small selection I had on the shop I gone is a Logitech Cordless Desktop LX700; it has a lot of extra keys which I really really like, and also if the mouse is now my third optical mouse at home, it's quite handy.

Unfortunately, I had a couple of problems trying to get it working. Well actually the base keyboard works fine, but as I paid it a bit too much (

In the last days I used my time to work on my paid job more than on Gentoo, just because I'm quite at the end of the job and I want to complete it ASAP.

This doesn't mean that I haven't done anythign in a while: you can find on portage a beta version for VLC (0.8.2_beta2), hardmasked, to test the new 0.8.2 version which should come soon. This because the new version has quite a few changes and I preferred having it tested so that users can see if it works before the final release is done.
So if you feel like testing recent VLC versions, try with 0.8.2_beta2, but remember but it's supposed to be broken respect to 0.8.1.

I'm also still working on Gentoo/FreeBSD and OpenPAM stuff. I managed to have a testing chroot with OpenPAM instead on Linux-PAM on Linux Kernel and GNU userland.. it wasn't all simple because pam-login and shadow depends on the use of libpam_misc which isn't provided by OpenPAM, but that is something I already worked out. The problem now consists of the fact that the modules built from Linux-PAM doesn't get along well with OpenPAM, or at least so it seems; the ones from FreeBSD hardly depends on FreeBSD's libc (or probably on a generic BSD libc) and this makes them useless on Linux. I think I'll need to fork the modules from Linux-PAM and use them with OpenPAM to have a working PAM environment with minimal modules support (ho pam_chroot, no pam_pwdb, no pam_cracklib and so on, having only the base modules as you have in FreeBSD, anyway a lot of other modules are available on their own and can be used if you want them.

Talking about FreeBSD, today with inspiration by KingTaco, I though of using a Firewire connection to mount the NFS share, with portage tree, CVS, distfiles and package tarballs, in the G/FBSD development box, removing its load from the switch and the general ethernet network shared with the router, the Access Point and the eventual new machines which are going to be added in a not-so-near future.
Unfortunately, seems like BSD support for IP-over-FireWire isn't so stable: it stops working after a few minutes of hard-load NFS transactions, and that's something really bad, but I'm going to sort this out soon because I really want to have this working.. at least the FireWire cable isn't going to be unused, it costed me quite a bit.

A part from technical issues with OpenPAM; Gentoo/FreeBSD and in general with Gentoo, the last days are being difficult mainly for my keyboards: my desktop's keyboard is breaking, the keys doesn't press too well, and the one of my iBook, being used every day for my job is having its key's label deleted by the use.
I'm a bit afraid of change my desktop's keyboard, for two reasons: the first one is that when I bough that keyboard I was able to provide Pavlik Vojtech the information needed to have the keyboard's scroll wheel working on Linux; the second one is that I don't know a shop where I can go trying a couple of keyboards, because I really need to feel the way they type, and I want a keybord with as more extra buttons as possible, because with KDE I can remap quite everyone to provide extra functions. The one I have here has a lot of them and didn't cost me too much, but I'm not going to take another one because it has the problem of being PS/2... I'd like to try an USB keyboard, also because in that way I can hook it up on the iBook if it types better than its own keyboard (also if it's difficult.. iBooks' keyboards are really good to work at). If you have suggestions on a model of keyboard which works fine under Linux, which has extra keys and perhaps a scroll wheel, they are really really welcome as comments in this blog entry :)

As anybody who read my blog before could have seen, one of the things I'm more concerned with is portability. Not only between different OSes (Linux and FreeBSD) but also between different architecture (AMD64).
The portability is a simple process actually, you just need to care a bit more about the size of the datatypes and of their internal structure, not relying on the byte disposition (little endian or big endian), also because, as many developers pointed out for me in #gentoo-dev, we can't be sure of the endianness neither on architectures which usually uses a given endianness, like PPC which can be different from implementation to implementation.

What I'm trying to say here is that portability is going from now on to be always more and more important: not only Linux and *BSD runs on a wide variety of hardware platforms, but now also Apple with their MacOS is going to change platform. What that means for us? Well most of the multi-platform projects will need to restructure the code if they was assuming that OSX == PPC == Big Endian. But how they can do that? There are out there some development kit but they aren't ensured to be the final product; actually we can't ensure what is going on in the market two months for now, how can we predict what will be the final hardware platform Apple will choose? We actually know that it will be an Intel chip and won't be compatible with PPC, but which will be the internal structures is something we don't know yet.

So what's the deal then? What can software producers do now to avoid the hell of portability when it will come to the new platform?
The first problem is with size of integers and with printf arguments: fortunately there are the standard integer types intX_t uintX_t, which can usually be trusted without problems, and then there are the macros like PRId64 to select the right type for the output, just a bit more attention to this can avoid having to mess around with #ifdef conditionals to have the things working well.

The other problem is with endianness of types, and more specifically with data structures written in binary form on disk (in files). The solution to this is to specify their structure and endianness in a complete form, making sure that they are loaded with special functions used to preserve their endianness; also if the most widespread hardware platform currently available (Intel IA-32 and derived) and the one which is imposing itself in 64-bit desktop market (AMD x86_64 and derived) are littleendian, probably the most natural way to define data structures on disk is big endian. I know this can seem stupid, but the use of bigendian data structures on disk means that they can be seamlessy streamed over the network: quite all the binary protocols currently used uses big endian as endianness, that's why it's sometime called Network Endianness. It's also the more logical natural form for numbers, for humans.

Not relying on data structure internal format can be sometime a bit slower than accessing them directly, as you needs to use shifts and bitwise and operations to get the part of the structure you need, but with today's hardware such an overhead is probably not significative for the complessive performance of the system.

Then just remember: developing something portable from scratch is going to be a lot less of a pain than need to port something to a new architecture when the mainstream OS you are using is changing its platform, and this is true not only for Linux, *BSD, OS X and Windows programs but also for all the programs which wants to run on "strange" or new operating systems, or for the ones who wants to run on every operating system of the world... that can seem to be something too difficult to do, but looking for the right services of the operating systems, it's not impossible to work on something which is so much abstract to run everywhere, without need to use something like Java or MONO/.Net and various virtual machines.

Anyway I really hope that with the new 4.x series of GCC a lot of the old, fooledup, really really bad styled code is going to become deprecated, and I'm going to do my part as much as I can.

Ok today I'm working very hard on Gentoo/FreeBSD. Now we also have a CHOST to identify Gentoo/FreeBSD systems: i686-gentoo-freebsd5.4; useful for configure scripts which tries to install with a defined layout depending on distribution (apcupsd is an example of this).

As gcc still has problems with crt1.o (it eats it during src_install()), I'm trying to get sandbox installed fine. I had many problems with it, I needed to update dev-libs/publib (and take over maintainership of it as it was orphaned), and I prepared a big patch to it removing a lot of cruft dued to some kind of compatibility with strange Unix versions probably previous to autoconf stuff.
Unfortunately that isn't enough. sandbox compiles, installs and also works fine to prevent access to the external filesystem, but make bash crash on opendir (seems like an infinite recursion on ".."), and I'm not able to find Azarah to talk with about this :/

Azarah is also the one I need to find to decide if it's time to move pam modules in their own category (I'm also waiting for this for a couple of new pam modules which I'd like to add).
So at the moment he is the showstopper for at least two task I'm taking care of :P

After that, I really need to complete the cleanup of FreeBSD packages, as I want to release the first experimental stage to public ASAP. Also because I want to remove 5.3 ebuilds soon, as they are completely unmaintainable.
Another thing I'm taking care of is splitting out non-base freebsd stuff from freebsd-* packages..

Unluckily I don't have too much time to work on this as I have a paid job I need to fullfill...

Well time to get to work... I really need to complete this work soon as I need money to upgrade the obsolete hardware.. and maybe to get another box to use for another gentoo/alt port :P

Ok I'm not dead, I'm not lost, I just haven't found the time to write a blog entry in the past weeks.

As starting point, a little update on Gentoo/FreeBSD status: I managed to fix a couple of PAM-related problems on G/FBSD overlay, and many of the fixes for OpenPAM compatibility are now in main tree (also because most of them fixes also amd64 no-symlinks profile); at the same time, I also managed to add support to /lib/security path on OpenPAM. KDE 3.4.1 has already all the dependencies fixed and the patches applied so that it works out of the tree for G/FreeBSD, fixed ghostscript and jpeg.
I gave Stephan an experimental stage for 5.4 profile, but I'm probably going to rebuilt it completely fixing dependencies so that it works better.
GCC still deletes my crt1.o file so I need to fix that, too.. too bad that there's no sandbox available for FreeBSD.

But now I want to talk about general Gentoo patches. One of the things most annoying when looking to external patches on other distributions is that they usually change the packages to suit their needs. Sometimes they apply patches conditionally on some archs (when they support more than one arch, sure). That's true not just for Linux distributions, but also for FreeBSD's ports, for Fink and for DarwinPorts. This makes those patches not good for upstream merge.
I think one of the strengths of Gentoo is that our patches are usually applied unconditionally and must work on many different architectures, and now that we are working on Gentoo/FreeBSD we have at least three operating systems to deal with (Linux, Mac OS X, FreeBSD), with many and many combinations which must work with the patches. That makes the patch quite always good for every kind of merging on upstream.

Why this is important for me? Because having patch applied upstream requires less extenral patches in distributions, problems distribution-local are less likely and the code is updated cleanly by the original devs.
That simplifies the work for us downstreams and for upstream (which has to deal with less-edited code when bugs are reported), specially when are released new versions, as we doesn't need to see if the patches still applies.

Oh well, time to continue working and submitting patches! :)