So, I've already tried in the past to get a working crosscompiler to FreeBSD from my amd64 box, mainly to distcc stuff.
Unfortunately, to have that working last time I had to install the headers manually, I had to mess with crossdev and overlays, and I only got the C compiler working, not the C++ one.

This time, I'm trying to fix all the stuff up so that I can actually have a decent crosscompiler that can be installed by the usual crossdev actions.

Up to now, I messed with freebsd-headers and partially freebsd-lib, freebsd-mk-defs and a few more stuff. It's not yet straightforward to fix it up, and lots of stuff had to be changed and edited and conditioned, but the results are promising.

I do have FreeBSD's headers merged fine using sys-freebsd/freebsd-headers ebuild, and that's fine. I have a stage1 compiler, that means I can actually build c programs with it. I'm trying to fix freebsd-lib so that it actually merges in crosscompile.

Right now you still need at least sys-devel/pmake and sys-apps/mtree installed manually (a huge thanks to tigger for mtree, or I should have tinkered to add that myself) before running crossdev, and also freebsd-mk-defs are needed for the headers to be installed correctly. The latters has to be keyworded via package.keywords, too.

I'd actually like to be sleeping right now, but I'm waiting for freebsd-lib to at least start to _try_ to build something...

Oh and for those who followed my little rant about shipping costs, I'm probably going to buy the two books from Amazon, as one commenter suggested. The shipping aren't low but they aren't too high, either. Buying only the Agile Web Development with Rails book from Amazon with their shipping costs I'm still paying less than buying the same book (in English) from an Italian e-bookshop.
Still, I'm considering what to do, as it's still €60 to pay now for two books I'm going to receive no idea when :/

Finally, after quite a bit of time. What made me change my decision of using vmware-server? Well it's mainly a factor of time and an opportunity I've seen just today.

When I bought the new monitor, I bought one which had a dual input, to use the DVI with my GeForce card for a dual-monitor configuration. This has the side effect that the VGA analog input is not used... and I just never used that before, until now.

I connected the VGA input to the box I used to work with Gentoo/FreeBSD on, and now I just have to press the source button on the monitor to get its output, without need to detach and reattach the connections every time.

Now it's just matter of burning a new LiveCD and re-install Gentoo/FreeBSD on it, from scratch.

I'll do that tomorrow for sure, as I'm probably going to have not much time in the future, if I'm going to find a job that I won't do from home as I'm working right now. From one point of view that's going to take much of my time, but at least I'll be learning how to work as a helper sysadmin in a real environment :)

I'm trying to use all the time I have lately to fix the last issues with Gentoo/FreeBSD and with video and sound and so on. Today I fixed all the bugs for video I could think of. There are still a few that requires a long work, like xine-ui's freeze with horizontal scrollbars on 64-bit systems, but for that I really need more work.

I'll try to fix also a few sounds bugs tomorrow, but mostly there are bugs for jack and professional audio/music production software that I don't have an idea of at all.

Anyway, I hope to be able to help users this way, but I'm not sure how much I can do in these limited days :|

A few pointers on the status of GCC on Gentoo/FreeBSD. If you've seen GCC failing to compile lately, it's because protoize was enabled by default on newer revisions of the toolchain eclass, but protoize doesn't seem to build at all on FreeBSD, I'm still investigating that, but it can take a while, so in the mean time it's disabled now.

After that, I've added a simple check to avoid patching and building PIE and SSP support on FreeBSD as they are not (yet?) supported, basically behaving like nopie and nossp were enabled by default on FreeBSD. Instead of 4 specs in gcc-config, now there are only two, one for Hardened compiler without PIE or SSP, and one for the vanilla compiler, dropping the extra specs.

Also I want to thanks Javier again for the work he's doing, he prepared a modified version of imlate yesterday, that I'll use to make sure ~x86-fbsd keyword doesn't end up remaining only on obsolete versions.

I also keyworded Xorg 7's drivers that builds on FreeBSD so that they are available for testing (for this, like other arches, I'm following the idea "it works until proved otherwise", as finding people with all those drivers would prove difficult). I'll have to fix nvidia-glx before committing xorg-x11 tho, so keep waiting for a while still :)

Now, I'm not sure if I'll be able to continue working tonight or I'll just go reading Wizard and Glass until I sleep, but between tonight and tomorrow I'll also have to work on finishing fixing up baselayout with Javier's patches.

By the way, I'm interested to see if there's someone wanting to work on the support of GNOME on Gentoo/FreeBSD: what it's needed is collaboration between Gentoo's GNOME team, FreeBSD's GNOME team and upstream GNOME developers, so that the efforts aren't redundant nor unportable... yeah it's not an easy or quick job, but it's useful, and if you are a GNOME fan, you might want to give your hand here ;)
KDE works, and XFCE used to so it might still be working already, I haven't tried yet. Enlightenment 0.16 out of portage works, I'm not sure about E17 as there's a patch needed, that I've prepared for E16 but haven't tried on E17. I'm interested in trying it actually, as it seems quite cool, for a WM, and I might want to use it as my WM of choice in testing Gentoo/FreeBSD.

Time to return to work!

So, now that the ~x86-fbsd keyword is being spread on tree, a part from fixing the dependencies on the optional stuff I haven't keyworded yet, I've started also fixing some issues with baselayout and init scripts.

I want to thank Stefano Takekawa, Robert Sebastian Gerus and Javier Villavicencio, who helped by testing and providing bug reports, init scripts and patches to base on. A new freebsd-baselayout is released, along with a few revision bumps of sys-freebsd packages: now net scripts sets routes correctly, included metrics; net.lo0 doesn't warn anymore (both of which are fixes provided by Javier); pf and powerd have init scripts (respectively Robert's and Stefano's); man pages for machine-dependent drivers are installed alongside the rest of manpages to be available to users, and other misc fixes.

enlightenment 0.16.8.1 has a patch and it's keyworded in portage, I'm trying to get a hold of someone in #e @ freenode to get the patch merged upstream, so that the live CVS version would work (and thus I could try e17 ;)), and ffmpeg is fixed (in the mean that CFLAGS are no more ignored so -fomit-frame-pointer can be used to build mmx code and free up a register to allow building).

I've also keyworded tetex that solved a couple of optional dependencies for documentation and stuff. dev-libs/check is still a problem. I'll be keywording some more stuff in the next days, to cover the possible basic needs of users, not much stuff, but at least enough to make Gentoo/FreeBSD usable :)

Unfortunately vmware-server doesn't seem to handle sound support that good, and I can't test it at all. I'll have to find time to reinstall Gentoo/FreeBSD on a real box to work on, it would also help me with the building as I can test two things at a time that way.

I'm thinking if it's worth to release a new stage, with the recent fixes to baselayout, but I'm still not sure, as there are little fixes actually.

Oh a thing.. as there was an interesting discussion about the branding of stuff in Gentoo, although the outcome is still uncertain, I'd like to be able to have something to brand with, if the branding is accepted someway, but of course most of the artwork will be for Gentoo Linux...
Now, we do have the beautiful logo that Marius Morawski drawn, would it be pushing it asking for people to prepare (possibly svg) wallpapers and kde splashscreens? :) (I say KDE because that runs already, if GNOME will be fixed, that would do too).

It's been a while since I last blogged; the reason is found in the recent Italy's elections; I wanted to avoid ending up talking about italian politics. But now elections are ended and I can restart blogging :)

First of all, start with news of the day, Daemon News published an interview done by David Stanford to.. me :) I want to thanks David and the Daemon News staff for this opportunity.

Part two, amaroK 1.4 crazyness... okay I know many people are going to hate me because of the series of bumps of amarok 1.4_beta3. Unfortunately there were a few problems with the released tarballs, regressions since the _rc we all tested, that ended up requiring a final 1.4_beta3c tarball release (1.4_beta3-r2 in Gentoo).
The major change since this release is that xine is no more optional. Upstream decided that one between helix and xine engines had to be built for amaroK to be considered complete, and being helix available only for x86, I did go with xine. If you want gstreamer backend you can select it, but it might not be available in final release as it lacks proper (upstream) maintenance. Xine works in most cases tho, just remember to enable mad useflag if you want to play mp3s.

From the Gentoo/*BSD part, I want to thanks Mike for adding the ldhints patches to Gentoo patchsets for binutils 2.16.1-r2 and 2.16.91.0.7, and Nick Clifton (from upstream binutils) who applied that patch on upstream, too. This means that right now binutils from HEAD supports FreeBSD completely out of the box! Yuppie! Well --as-needed seems not to work, I have to fix that, but that's lower priority.

I'm still working on baselayout, as there are still troubles, for example rc-daemon doesn't work as intended, and currently all the filesystems are checked twice (this is fixed in SVN thanks to Javier Villaviciencio who reported it), and dhclient fails to set routes. Most of this will be fixed soon tho :)

Also, Xorg7 works, KDE 3.5 works too. kdebase-meta, kdenetwork-meta and kdegraphics-meta are (almost fully) keyworded and works fine. I had to add a last minute fix to mesa to get rid of -ldl from .la files installed, so if you have it installed and have problems linking due to libdl missing, run the following command: sed -i -e 's:-ldl::g' /usr/lib/libGL{,U}.la /usr/lib/opengl/xorg-x11/libGL.la, and that it will fix it.

sdl seems to work, too, so I'm going to keyword it together with flobopuyo (my favourite game and what I've tested a lot with ;) ) later on, although you need the patched libusb 0.1.12 from the overlay if you have libusb already installed, as 0.1.11 has a bad bug that makes libSDL fail to find the usb joystick support on FreeBSD and ends up failing because of undefined symbols on the final library.

Right now I've talked with UberLord and I might know what the deal is with dhclient, but I can't test it right now, I'll wait for arachnist to test, and in the mean time I'm going to bump alsa to 1.0.11_rc5, sigh.

Anyway, the binutils patch merged upstream is really a milestone for me... next step, patching gcc to recognise the extra format strings added by FreeBSD while using the right FreeBSD target :)

I'd like to contact some FreeBSD developer to submit the patches to build freebsd-lib and -sources with binutils 2.16 but I'm not sure who to send them to :(

I really want to thanks the VMware guys for their vmware-server... today the beta2 was released, and tonight I was having a few issues with vmware-server itself, so I decided to update it and see...

I was about to curse for a while, as it was really giving me hard times with slowness, but then I seen it had somehow started also another virtual machine I didn't need. I started the Gentoo/FreeBSD 6.0 VM and.... magic! the "negative runtime" warnings that were coming up during the boot phase are now gone! Great! Thanks VMware.

Anyway, the stage is now on my home on dev.gentoo.org, waiting for one of the mirrors' admins to pick it up and put it on mirrors.
Right now I"m testing Emanuele's patch to build freebsd-lib with newer binutils, I hope vapier will merge my patch into binutils for tomorrow, that would really help.

Anyway, now it's 2:27 and I _really_ need to sleep as last night I haven't sleep at all (and slept only during the afternoon, 11-16).

It's fortunate that I can conciliate the work on Gentoo/FreeBSD with my actual job, if I were to have a way more committing job, I would have to drop most of G/FBSD maintenance, and that would be bad at the current status :(

So, as I promised to a couple of users before, I'm going to provide an updated Gentoo/FreeBSD 6.0 stage this week. What will figure in this updated stage? Lots of new shiny things :)

First of all, the new baselayout, where the net script actually works for routes, too. It still has some glitches, for example stopping cups or openntpd causes a termination :( but this is still a minor problem. Consider this is still experimental so please submit any bugs you'll find in Bugzilla.

There's also an updated version of binutils, 2.16.1-r2 fixed with the FreeBSD patch; I was almost going to provide a 2.16.91.0.7 version, but then I remembered that I still have to patch freebsd-lib to build with it with the patch kindly provided by exg :) (who also explained me how to fix these kind of issues, thanks exg).

There will be a newer GCC too, but that's not much useful. It will solve two big issues, namely the libarchive/bsdtar merge and expat's soname change. You'll also find a couple more packages, like cronbase (used by freebsd-ubin to have cron.daily directory, as locate now has updatedb working without periodic) and pidof, new dependencies added when sanitising ebuilds for main tree merge.

Oh yeah this will also be the first stage only using ~x86-fbsd keyword, the first one using in-tree packages (although you still need the overlay). It will featurea also vim, for the pleasure of its users.

Please note that currently the ~x86-fbsd tree is _not_ complete, there are things like tcp-wrappers that are even in system but if enabled will ask you to keyword stuff ~x86, and USE=doc and USE=test are not yet fixed... I'll do that time allowing.

There's also a new portage in the stage, although when 2.1_pre8 goes out I'm going to strictly require that on profile, if antarus is kindly enough to implement per-package use.masking in it :)

Anyway, I hope to be able to prepare updated stages more quickly in the future, even if vmware-server has still issues..

I think that, after an year, we really had big improvements. I had a bit of a mess up last fall, and with newer versions of xorg it wasn't working anymore, now thanks to Xorg upstream and the modular release, we actually have a working Xorg, and I started keywording stuff so that it won't disappear easily. Right now it's possible to have a quite minimum system but working fine... well minimum depends what suits you, it _does_ have most of xorg keyworded and kdebase, too....
Oh well ;)

(again, a quote from a TV Series I like, this time Scrubs...)

Okay so I've found my problem with the mouse I was having before, /dev/sysmouse does not work, the right device is /dev/psm0, although xorgcfg doesn't recognise that, I might have to tell that to the Xorg guys.

Anyway, now that the problem is solved, I've keyworded also xf86-input-vmmouse that's the driver I'm using right now.
After keywording the part of xorg I actually installed and thus made sure it works, I wanted to restart the work on KDE, while I'm still validating sys-freebsd ebuilds so that i can put them on tree in the next days.

I've keyworded quite a bit of the dependencies, but I'm now waiting for Qt to build. I'm sure it works, it always worked, but I have to compile it first.

Although sys-freebsd is still to be committed, I managed to keyword the base system and most of the important utilities we have, like portage-utils, screen, vim, and so on. gcc and binutils 2.15 are keyworded, 2.16 requires the patch that Mike hasn't merged yet.

I have to say that I have left as RDEPEND.badindev most of the dependencies for doc and test useflags, as I don't have time to test these right now. I also haven't use.masked stuff I didn't know already broken (like java for example), so you might get problems, they'll be fixed, somehow.

I actually miss working on a real machine rather than a virtual one: a virtual machine is easier to monitor the console of, but it shares the compile power with my own workstation and that's pretty annoying on the long run. I might reinstall the box I have here sooner or later, but right now going to move the monitor connection from one box to the other is really not the case, especially as from today I'm working pretty hard on my paid job.

(If you didn't get the title, it's a reprise of the title format for Friends, one of my favourite series.)

Last time I provided interesting screenshots... this time I won't as I'm not yet done and I'm still fighting with it, but Xorg modular builds and runs on Gentoo/FreeBSD, yai!

The only problem remaining is that /dev/sysmouse is silent even when i put the mouse on VMware and try to move it... maybe I've forgotten something on kernel configuration or VMware is being silly.. yet to find out.

Now as people might have seen yesterday by #gentoo-commits or by my commit log, I've merged the Gentoo/FreeBSD profile into main tree and started keywording ebuilds with ~x86-fbsd keyword.
What does this mean? Well the first important thing is that finally we don't risk to see packages go away when they are the last version supporting gentoo/freebsd, but also we'd know when something requires more porting.

Unfortunately keywording everything alone is going to be a big problem, also because I have an hacked perl in my main PORTDIR to support LDFLAGS, and I still have to test it thoughtfully so that Michael will accept it, so I haven't keyworded that yet, I'll do it later today probably.

I'm also going to retry with sandbox later, although I'm not sure how much I got it right this time. The code should work, as it works on NetBSD at least, remains the usual problem with findutils and the call cycle.

Oh of course I'll also be merging patches to fix build issues with GCC 4.1, with glibc 2.4, with libdvdread 0.9.5-r1 and also providing patches to avoid stripping binaries and to respect LDFLAGS, as well as improving modular xorg porting when i can ... if I find time to do this of course, as I'm also working on a paid job right now... I need longer days.

Okay, I don't think there are many users actually using bsdtar on Gentoo out there, but this might be interesting for them, although it's history already.

Since last week upstream author Tim Kientzle releases libarchive and bsdtar in a single source tarball called libarchive-${PV}.tar.bz2 ... I decided to maintain the tarball merged as the author does, but named it bsdtar instead for an easier access to users (although it's a bit messier for developers looking for libarchive).

One unfortunate thing of the 1.2.51 release is that it does abort during extract phase on FreeBSD when using the -p switch, as done by portage when extracting a binpkg. This means that, until upstream fixes this behaviour, or suggests me a way to work it around, buildpkg and binary packages are not working on Gentoo/FreeBSD.

Also please note that there's a block (similar to the shadow/pam-login one) between newer bsdtar and libarchive, but this is worse as you can't unmerge libarchive (or bsdtar stops working, and it's system tar on FreeBSD), so you have either to build bsdtar static before upgrading (safe and my way) or trick portage to do the dirt job for you...

The first case consists of this:

USE="static" emerge -1 '<bsdtar-1.2.51' && emerge -C libarchive && emerge -u bsdtar

while the second is

emerge -Ou bsdtar && emerge -C libarchive

They should both work, but I would be safe only on the first.

Anyway, as soon as the extraction issue will be set down, I'll roll a new stage tarball with the conflict already fixed, as I did in the past with bsdtar changes.

Update: (not exactly an update since I haven't saved yet but anyway) seems like libarchive has an automagic dependency on acl and attr and bsdtar does link statically on libarchive.... I'm going to fix this now, and send a couple of patch to the author, we'll see what happens :)

Okay, no big deals today to report actually. I've fixed the baselayout ebuild that I forgot to recommit, so if you had lots of trouble after updating baselayout to the snapshot version, it should be fixed in tomorrow's snapshot (or already if you're a developer and you can use the SVN). I'll also prepare a newer snapshot version later today probably.

But a few progresses were made anyway. Yesterday I fixed eselect's env update to work with FreeBSD's and DragonFly's ldconfig; the patch is in the overlay (will be in tomorrow's snapshot probably) and I submitted it to our lovely eselect developers so they can put it in the next versions. Then I discovered that there is a port for libbfd recently updated to 2.16.1, that way it should be simpler to forwardport the patches and then submit them upstream.

For the ones following pidof's odyssey, I've decided to go with GPL, as that allows me to reuse code from sysvinit and also might be helpful if, instead of releasing a single pidof package, I decide to create a better suite to add some of the things that we end up missing on FreeBSD because are GNUisms and things like that.

I hope to provide something interestingly new in the next days, maybe an updated stage, but I"m not yet sure, I still need to fix the route adding problem, but if there is an unix-like command I _never_ understood, that command would be route(8)...

Oh well...

So, I already blogged time ago (if I remember correctly) about the need for a pidof command on Gentoo/FreeBSD to go with a newer baselayout. I found this version, but I had to patch it quite a bit, I also sent the patches upstream but after an initial discussion, I got no response and no new releases were due.

So what's the problem? That pidof patched as it is in Gentoo/FreeBSD is just a workaround, we can't continue with it as it might be unreliable, and probably will need some changes to work on other BSD platforms (thing that we actually need), so I'm thinking of taking that code and writing a new pidof from it.

What's the problem then? novel's pidof is released under BSD license, as almost every tool that is used in BSD core system, but I'm pondering about changing the license over GPL. From one side, using BSD it would still be a classic tool for BSD platforms, from the other, by using GPL I can use gnulib's porting facilities (if we end up in an operating system needing more of that), and I can also reuse code from sysvinit's pidof command (that is GPL-licensed).

I'll let you know later today what I decided to do about it, and I'll also provide a bzr repository where to take the code of the new version from at that point.. bzr is useful because I can use it directly on my dev space so that it's available for users too, so thunder, arachnist, reb and bbj can access it and tell me if it works on their operating systems :P

gnulib is an interesting way to make sure that software is written with more portability concern in mind, and works quite fine, usually. Unfortunately this is not always the case. In the last weeks we found at least two/three cases where gnulib was faulty and had to be fixed or updated. As updating gnulib from an ebuild is not a trivial way, the solution is usually an hack around it.
What I found now is a subtle problem with openat.c unit: basically it uses a va_arg call on mode_t type, but it warns you that you should rather use int, and that if the code is reached the program will abort.

I've prepared a patch for that, by looking at update gnulib code, and CVS's CVS is already updated with a newer version of that unit that doesn't present the bug. Unfortunately, it's probably not the only software using it. I'll see to prepare an automatic check for it with bashrc but I can't say I'll be able to do one working...

Also, ruby has some weird way to deal with FreeBSD/DragonFly systems, and I'm not actually sure why that is done. I'll see if I can handle it in a decent way so that we have linux-style linking on Gentoo/FreeBSD at least.

So as I promised, the VMware Image, usable with VMware Player and VMware Server is released to public. It can be downloaded with torrent at the new torrent tracker that curtis119 set up for 2006.0 release and Gentoo/FreeBSD 6.0 release :)

Update: as I forgot that we don't have update docs yet, better telling here what the root password is.... unbelievably "Flameeyes" (no it's not my usual password).

This is still using the old baselayout and old portage, but it's a completely set-up box with compiled kernel and bootloader, directly usable without passing through installation instructions.

Yesterday I also continued the work on the forward ported baselayout. Now stopping interfaces works fine, and also halting works fine, without having to deal with /etc/init.d/{shutdown,reboot}.sh, as shutdown takes care of both of them in FreeBSD instead of requiring us to take action as it's done in Linux. This made my work simpler although I had anyway to spend time fixing the two scripts before seeing that processes were given two term signals and finding what the problem was.
/etc/services is still an issue but I haven't fixed it yet. I also have still to fix rpcbind so that it doesn't crash if services is corrupted or replaced with Linux's version. It will still fail, but a graceful failure is way better than a crash that gets into library.

By the way, there seems to be an unpatched vulnerability in FreeBSD's nfsd. Right now there's no init script for nfsd in Gentoo/FreeBSD.. if someone wants to write one... ;)

And for a mainly unrelated note, yesterday I spent a bit of time cleaning up Audacious's compiler's warnings, today I did the same with cdio (in Linux for now, next will come FreeBSD, then DragonFly and so on). I have to say that I'm starting loving vim more and more (when I'm not _writing_ code from scratch but rather fixing others' code, that is... in the first case Kate is still my first choice).

Oh I forgot to update the binutils patch with dragonfly in the ld hints conditional... I'm going to now, it really slipped my mind lately. That also remembers me that I should install DragonFly on a true box and work on making sure that cdio works (as VMware's virtual CD device seems to have some problems also in FreeBSD)... sigh a KVM would be fine now.

Okay time to restart work, although I should probably try to make use of RSIbreak to try doing something else like clean up my room :P

So, with the stage now out of the door and the VMware image getting its way out sooner or later, I wanted to start caring a bit more about details. Today I already discovered we were always stripping binaries because of how the bsd mk definitions were set, and I fixed that (without revbumping the whole set of packages, tho, because that is still an experimental stuff.

I'm also going to fix freebsd-sources to not install in a /usr/src/sys-6.0 directory anymore, as that will create problems when 6.0-r1 comes up, so I'll rather install it in /usr/src/sys-6.0-r0 and then symlink it to sys-6.0, that way it will always work with the ebuilds that symlinks it into workdir.

But there are a list of "junior jobs", minor glitches and improvements that might help to work on. I should probably put this on a page on the project space but I haven't had time to update that in a while, I'll see if I'm able to do that later on today after getting my hair cut and before going to watch CSI: NY (now that the stage is ready I'm trying to relax a bit more, that might be why I finally started sleeping decently).

The first thing that would be good to fix is the output of /etc/issue. The getty command used on FreeBSD doesn't parse it to output the special strings that are parsed by Linux's getty. It would be good to have that on FreeBSD, too, especially since the /etc/issue file we're going to use looks stupid on FreeBSD as it is now.
Another thing is related to portage, better it's ore than one thing but all regards the handling of BSD-style flags (used not only for FreeBSD but also for other BSDs). Currently what it does is to take out all the flags before merging and then repplying them on the merged filesystem no matter what they looks like; this creates a few problems, first of all the time required for these operations is not so minimal, every time getflags is called it has to pass python to extension boundary, then call the libc, and then back to python again, this could be avoided by using the st_flags member of the struct returned by the stat() function (and derived) with the new versions of python (that's a patch I provided to python and is already applied for next versions, although 2.4.2 still doesn't seem to apply it); then there's the point that it does reapply all those flags also if they are actually "0" (no flags), and that's silly because we already reset them to 0 to move the files around, and considering the quantity of files in most of the packages and the percentage of the ones for which the flags should be changed, well.. it's quite a waste; finally the way it's removed before merge and reapplied after merge, it means that portage can't strip some files :(

Then there is more work that needs to be done on init scripts, work to change periodic jobs to cron jobs, and so on.

So don't think that there's too much "high level" work needed to help with Gentoo/FreeBSD, or that it requires just and only ebuild skills or working with the packages already in portage, there is plenty of space to help if you want :)

So, the stage is done and now it's time to clean up. I'm still waiting for a new portage version, but that release is up to zmedico so I don't know when it's due :P I started working on the new baselayout tho, with a 20060222 version that I committed yesterday.

Main problem I found until now is that rpcbind (used by NFS) crashes if the services file is used out of the Linux version of baselayout, probably because it misses some entries. What I don't know how is why on earth I can't debug that crash, gdb doesn't load symbols from the splitdebug libc.so.6 because also the /usr/lib/debug copy is stripped, and I just found why (BSD's mk files uses -s to strip binaries if I don't define a DEBUG_FLAGS). I'll patch that out and then rebuild my system...

BETA2 of 6.1 was released but I'm not in a hurry to update to that, I want to be slower with updates and make sure I don't have main screwups going on and on since 5.4... I think this is one of them.

I've sent Michael a few more updates for Gentoo/FreeBSD installation doc, so that it will be soon updated to respect the actual 6.0 install procedure.

Anyway, time for me to go back to work on Gentoo/FreeBSD, seems like I started sleeping aain and my private life is leaving me enough time to work on it :)

So, ok, I have the stage. Which stage? Gentoo/FreeBSD 6.0 x86 stage. It's an experimental stage for now as it's still using portage 2.1_pre4 and the old baselayout, and I'm probably going to refresh it next week. I'm at least ten days late on my original time table, but the result is quite interesting.
I can't release it right now as I need to wait for the overlay to get updated with a new patch I added to freebsd-sources to be able to build kernel with new versions of flex. Seems like 2.5.31 release got quite a few of cleanups changing behaviour.. and it's interesting to see how many people to such changes started yelling "broken, broken!"... well I was a bit annoyed by those changes, but that's not because flex is broken, mostly because I hoped in a "-permissive" switch at command line...

But anyway, since I restarted working full time on Gentoo/*BSD, there were lots of steps forward. I think this was the most productive month I ever seen in respect to Gentoo/*BSD; maybe because I'm not sleeping that well (or at all sometimes) since last month.. personal life does suck indeed.

Oh by the way, I think I found the reason why FreeBSD is told not to support --as-needed. Some of the system's libraries doesn't get linked against the libraries they need, to avoid putting a circular dependency, for example, between the lib package and openssl. This is indeed a problem, but I think I can get around it, maybe splitting out the libc itself to a package and the rest of it with the dependency they need. That way I should be able to make --as-needed working on FreeBSD, an interesting achievement, I think.

On a completely unrelated note, last week I seen the last series of Friends (again, I already watched it in Italian when they aired it here), when I completed the DVD series that came with an Italian magazine... I'm missing it quite a bit... not only for the series (that I like), but also because I'm out of stuff in English to watch :P Although there are some great dubbers in Italy, the original voices are something you cannot replace (well a part some exceptions like Gimli in The Lord of the Rings...). The same magazine is now publishing Angel's DVD (always with prices good enough for me) but unfortunately it's not being shipped where I usually buy magazines here :(
I think I need a new job... possibly not as an underpaid codemonkey using a stupid RAD environment on Windows as I had to do last time... underpaid because I spent three weeks working on that, one week just to get the test environment working (because they didn't send me a decent spec in the form of "you need thesee versions of PHP, MySQL, Apache, configured in this this and this way", but just told me "it works with PHP Apache and MySQL"... what the?!), ending up having to re-create the environment three times (okay first time was partly my error, forgot PHP4 and MySQL 4.1 in Windows doesn't get along that well)... they started ranting when I noted 8 hours trying to get one of the features they required working and failing (not my fault here, if the library isn't able to cope with a simple thing like a start/end date for a calendar event), and when I left them without adding the three extra hours I needed to complete the requested feature, they ever said that I took too much time to do the job... without even being able to evaluate if what I did was good for them because they didn't actually know what they asked me to do!

I must say that Gentoo is for me almost like a job... with the main difference that I don't usually eat while working, but I eat while working on Gentoo :P

Anyway, I'll try to relax tonight and see if I'm able to sleep finally...

It's been almost an year that I'm working on Gentoo/FreeBSD project. It's an interesting thing because too often I had to leave away projects after a few months, but Gentoo/FreeBSD still remains my main concern.

Last year, the only thing that was available was an overlay stage over FreeBSD 5.3, with many ebuilds that hacked aroudn installing stuff. Now we have already a 5.4 pure stage, and I'm working on the 6.0 one.

This year was sure full of events at least for me. The stage, the documentation, the project takeover, the amazing logo Marius drawn. It also proved that what we want to achieve is possible. There are no big obstacles for it, portage demonstrated to be flexible as we need, although some things still have to be nailed down, and it's not difficult to maintain compatibility without sacrificing features in ebuilds.

One thing that still hasn't changed is -again, sigh- the baselayout, that remained mostly the same of one year ago, and it's something I want to get rid of soon.

But Gentoo/FreeBSD had implications also out of the purely Gentoo scope, and that is what make me like the idea of continuing also if I'll get against all the upstream developers. I provided Tim Kientzle patches for libarchive and bsdtar so that now libarchive builds as a shared library also from the split tarball, as being done on FreeBSD (so that we don't have regressions by using it); some portability patches were merged into GNOME packages like ORBit and gnome-applets, although way more work is needed on that side; Unieject project started and now provides an eject command for FreeBSD that is compatible with Linux's version, and with that libcdio received a couple of fixes so that it could work on FreeBSD; xine-lib patches lingering in ports were applied upstream, removing the maintenance of them from ports maintainer; Mesa finally build on FreeBSD without failing at install because of broken script using GNUisms..

I know these little changes, compared to the whole quantity of software in portage, is almost nothing, but it's something that can be worked on.. heck, most of that I did alone! If you want free software to improve, consider joining the effort and making sure that the patches applied by ports are cleaned up and sent upstream, instead of lingering there.

Think of ld hints for binutils that I'm working to be applied upstream... think of how many other stuff was never sent upstream because ports maintainers supposed to be "the only ones" for that platform...
Upstreaming is our passphrase :)

Okay, so my TODO list for the day was quite long. Working on at least half of the FreeBSD patches for binutils, starting recruitment process for Benigno, working on the new baselayout from the branch I prepared to work on Gentoo/FreeBSD, providing at least a temporary package while Azarah finds time to merge it into trunk and eventually in 1.12.

Unfortunately, I stopped at the first two points. I actually started the recruitment process by opening the bug after working on his quiz answers, and I have the working patch in overlay.
Luckily, binutils upstream developers seems quite friendly and answered me during the day, so that I could refine the patches a bit more for cross-linking environment.

Unfortunately, I couldn't finish all this list. I haven't worked on baselayout nor on the package for it. I haven't started working on the bfd update patch. I haven't worked on the new stage.

There are lots of things I would have liked to do today, but I hadn't had the time to work on them. Flex was a big problem to deal with, now it's fixed in portage tho, and upstream already fixed it before, fortunately. The worse thing is that I have now a biiig headache and I really need some sleep.

But anyway, for the daring ones, here some pointers of how the process is going. The patches are now in the overlay, both for binutils 2.16.1 and 2.19.91.0.6; --as-needed works on those versions; I'm trying getting them applied upstream.
As --as-needed works with these binutils (that are not supported by original FreeBSD), it should be possible to use the extended specs for GCC that allows to link libgcc_s only when it's actually needed and always shared, instead of using what we use currently (static link for executables, always dynamic link for libraries). Unfortunately up to GCC 3.4.5 the check for --as-needed was under a Linux conditional... it's better on GCC 4.x. Unfortunately I don't think FreeBSD 6.0 likes GCC 4.x yet.. when I'll release the stage, if someone wants to go through the code of FreeBSD's base system and fix it to build with GCC4, that's something quite fine ;) (obviously, it will require to fight with upstream to get those changes applied). It would be interesting to see a Gentoo/FreeBSD system entirely based on GCC 4 and binutils 2.16, the latter not even available in ports for what I can see.

Oh well anyway, now I really need to take a break to sleep. Today's thanks to vapier (again :P) for merging the flex patch, and mcummings (for the two perl patches).

Not so easy, eh? I found the cause of GCC's failures, I was working on preparing the patch for binutils to submit upstream, and then I discovered that what Status reported yesterday on #gentoo-bsd is a big big big screwup of flex 2.5.31, that assumes that "m4" is GNU m4.

Okay, upstream already fixed it, I hacked up a minimal patch for Gentoo and submitted it to base-system (still to commit on overlay tho). Not a big deal from that.
But then, when flex was calling the right m4, I found that it's incompatible with current freebsd-lib, sigh.

Now I hope this is the only thing I have to fix, but I'm not counting on that.

This is going to be a loooong day.

Update 16:32 GMT+1
I forgot to update this entry ;)
The problem with flex seems to be fixed now, the overlay contains a patched version, the hack has been submitted to base system and freebsd-lib is now patched to compile fine with flex 2.5.31 (actually requiring it, unfortunately, I wasn't able to get a backward-compatible patch and I wasn't going to spend time in has_version conditionals).