Okay so... remember that I said that there was a GCC issue blocking my work toward the new Gentoo/FreeBSD 6.0 stage? Well it wasn't GCC's fault.
For some reasons GCC defaults to static libgcc when --as-needed is not supported by the platform, and for some reasons --as-needed is not supported on FreeBSD (I have actually no clue why).

The problem points again at binutils. We really need to patch it to respect ld-elf.so.hints. Okay, this time I'm going down to fixing that in a proper way. I've cut down the original 599KiB patch into a 272KiB patch, and that seems ot apply over 2.16.1 almost flawlessy, and seems also to not cause it segfault as it was before.

It seems to me that there are at least two patches mixed in that stuff, one is an ld patch that does what we need, the other is a big bfd patch that updates FreeBSD support.
I'll see to check this deeply so that I can submit the changes upstream, so that binutils would work on FreeBSD out of the box.

Now I'm trying to understand how binutils works, not a simple task but it should be feasible..

I wish to thank vapier and Kevin who pointed me to the right direction, and solar and az who helped me debugging the problem the first time :)

Update 13:45 GMT+1
Okay the issue is bigger than I thought before. I still see the crashes with LD. This time, tho, I'm going to track them down and resolve them. To do that I'm using keepwork FEATURES (as the code is in generated files) and -ggdb flag, without -O or inlining makes difficult finding the stuff.
I need to understand how the internals of ld works, not an easy task at all. But I hope I'm able to get something useful out of it, if nothing else, at least some experience.

For who is wondering, this is finally how the libraries' search seems to work:
a) for libraries passed to commandline linking (-l*) they are looked up in the default library paths (/lib /usr/lib /usr/local/lib) and in binutils' library directory, then in paths provided at commandline (-L*);
b) for libraries that are in DT_NEEDED fields, the search happens in runpaths, and if it's a native linker in the ld.so cache.

And now (again while eating) I was able to find what the problem was (a variable was passed as string while the new version requires a struct)... I'll clean up the patch and prepare it to be sent upstream...

Update 16:27 GMT+1
Okay, I had the patch for ld hints working, both for 2.16.1 and 2.16.91.0.6. I sent them to the upstream mailing list and opened a bug for them. Now I'm rebuilding world in the vm to see if it works or not.
That is not going to be the only thing I have to fix, but at least it's another step forward to reach Gentoo/FreeBSD 6.0 stage.

Yeah I know I promised a working 6.0 stage during this week. Unfortunately there were a few issues that stopped me from continuing as planned. The first blocker is GCC that still misses the specs patch, but it's not alone.

gnupg was something I wasn't keen on missing, either, and finally I was waiting for portage 2.1_pre5 that fixes the annoying "Bad substitution" error message spread over everything using portage.

But a part from those errors, I'm also waiting to see what Azarah thinks of the baselayout porting so maybe I can release the 6.0 stage already with a new updated baselayout.

A part from Gentoo/FreeBSD problems, the last were quite full with bbj's and arachnist's patches for Gentoo/NetBSD and Gentoo/DragonFly, and the overlay is now getting bigger day after day.

Unfortunately seems like dragonfly is going to need a new set of elibtoolize patches that are quite annoying to deal with, also because they add extra load on the tree... although that is probably not even comparable to the load caused by many other patches :P

Anyway, elibtoolize patches will have to wait a bit, in the mean time a solution is to ask upstream to release new versions with newer libtool, instead of sticking with freaking old versions (the same goes for most of the broken stuff with gnulib-using programs).

Okay I spent the day working on this new init system based on current baselayout's trunk. The result is that now the init system mostly works on FreeBSD with almost full features support.
The important things like networking works, at least for the main features (static IP address, dhcp through dhclient), lo0 is also started mostly fine. I get quite a few problems with failures in routes handling because the route command is different from Linux's and I didn't have time to investigate its parameters right.

The bad thing is the init sequence is a bit too verbose, the fsck output is quite complex. Another problem is that localmount throws an error to me because it can't resolve the name "enterprise" I use for my main box (which is in the fstab).

I committed the changes in the porting branch so all the code is available for who wants to mess with it (of course it's a devs-only SVN right now). Don't start thinking that it works flawlessy yet, I'll have to hack on it a bit more.

Was funny when I fixed some of the start issues, and then when bootmisc started it deleted ld-elf.so.hints and the system stopped booting :)

Anyway, now the main blocker is still GCC's specs, although Benigno provided me another patch, to eutils this time, that should solve the last problems with the build process of GCC, in particular the crt1.o deletion on install.

Unfortunately also udhcp is not portable under *BSD, and porting it seems to be a bit more difficult than porting dhcpcd. Anyway dhclient for now should be enough, it also follow the same package that is provided by FreeBSD base system, that makes it a good solution, I hope :)

Anyway, time to wait for GCC to compile to see if BBJ's patch works, then it's time to look at what it's still missing in Gentoo/FreeBSD 6.0 checklist...

Seems like I got a bad news from Chris (wolf) tonight.. my Athlon64 is not supposed to work with VMware in 64-bit emulation mode, so I won't be able to work on Gentoo/freeBSD AMD64 when 6.0 is ready. Sigh.

Okay this changes the list of things I'm going to work in the next days:

• fix this stage, right now I'm stuck at OpenSSL not compiling, might be a problem with GCC, I'm trying to pin it out with Azarah right now [update: thanks to Azarah and solar, the problem was found, seems like the specs from GCC 3.4.5 are foobar'd (and shaded in original FreeBSD because of their handling of binutils), I opened a bug hoping to get that fixed, it's a blocker for Gentoo/FreeBSD 6.0 release];
• ayout porting so that the init system is the same as in Gentoo Linux;
• start working on Gentoo/FreeBSD 6.1 ebuilds;
• prepare a VMware image for Gentoo/FreeBSD 6.0 ready to test (for me to resume work if I b0rk it, and maybe to release public ;)

So it's not like I have nothing to do in the next days...

If somebody really really wants Gentoo/FreeBSD AMD64... you can always send me an X2 ;)
No really this time, Gentoo/FreeBSD AMD64 has to wait... for someone else to step over, to me to find time to do that hacking on my true devbox or to me to find a job which pays me enough to buy an X2...

So I'm almost ready to release the first stage of Gentoo/FreeBSD 6.0.
Why "almost"? Well I was able to get a working stage that can boot, but that is not releasable as many things still links against the old libraries' names from original FreeBSD 6.0, while I need them to link against the "good ones".
Also there's a quite big problem with kernel, as it builds with -Werror and our compiler throws a few more warnings. The way to solve this is by using "make WERROR= NO_WERROR=" while building the kernel, but it's not yet enough.

Also, I have to fix a few things in the guide as there are some commands which changed, and I also want to add also a way to partition the system with sysinstall without using command line tools, and without rebooting three times to get the partitions done.

The work on baselayout is proceeding, too. I broke farragut as I tried a dirt "move whatever there is and just make use of it", but that is not a problem as I should be able to fix it in a bit.. most of the changes are now already in the bsd-porting-2 branch of baselayout.

For today, I'm probably not going to work hard on Gentoo/FreeBSD, mostly because I need to take some hours off or I'd be driven crazy. Last night I had to go sleeping before midnight, something quite strange for me :P
Well ok, then I got up again at 2am and I read "The Wastelands" till 5am, but that does not count ;) Actually, I liked that book quite a bit. Stephen King is good at writing. Now I just need to find and buy the other four books of the series.

Okay so last night the first seed stage of Gentoo/FreeBSD 6.0 was compiled. Still, it was so far from something usable that I didn't even thought of tarring it up and presenting it with "highly experimental" note.

The first main issue was with the configuration files. The old-school method was to install all the configuration file stored in /etc with freebsd-baselayout. This was probably to align with original FreeBSD that has a freebsd-etc package.
Such a method to install them, tho, had a few disadvantages: the first is that we need to install everything everytime, instead of being able to drop the configuration files we don't use like bluetooth and isdn; the second is that the release is done with certain version of the OS that might not be actual anymore (/dev/cuaa* nodes got away).

So the solution was to move the stuff from freebsd-baselayout to the packages actually using the configuration file. The move is almost all done now, I left just a few of them and only because I was playing with something else at that point. The main issues are solved tho, and I'll complete the stuff tomorrow with a bit more relaxed eye.

This move also made more and more easy to move from freebsd-baselayout to the actual baselayout 1.12, so I tried messing with it. In the overlay there's currently an ebuild that installs a normal baselayout in both Linux (without difference) and FreeBSD (with only a subset of the files of course). From this point I restarted the work to get baselayout working on bsd, although most of the work now is in the hands of our baselayout guys, starting from Azarah ;)

What's going on now? I have the virtual machine building again system on a newly ROOT directly inside a new virtual disk from which I hope to boot Gentoo/FreeBSD from, after :)

You'll find that the new files in /etc are more or less the standard default from FreeBSD, but there are some things still missing: most of the periodic stuff was cut down, the scripts that checked status were removed, and they are left to the sysadmins to write using cron.* directories (they are quite simple, and usually it's just simpler to make them custom from scratch).

There are still a few things that I want to fix before I can release a true stage, also if I don't think it will be possible to use a pure Gentoo init system when I'll do, I want to try to merge the most changes possible to our baselayout to follow the main one.

Oh and thanks for Benigno B. Junior (bbj) now many packages does not require anymore that you extract the whole freebsd-sys or freebsd-include packages, but instead they use the one already installed, without having to edit all the makefiles. I'm going to convert a few more ebuilds to this idea, as that also saves me from forward-porting the patch when new releases come up, making easier the ebuild update for me. Thanks again Benigno.

Other notable changes in this release are.... well you'll have less cruft in /etc because some configuration files now are installed only when the support is requested (like isdn or bluetooth), but for the rest the code is mostly the same.

And also today I was typing emerge commands while eating dinner, sigh.

So, ok, the work toward Gentoo/FreeBSD 6.0 continues. I got a seed stage, but I'm quite sure it does not work. The reasons are simple: a lot of configuration file changed in 6.0, devices' names changed too, and the result is that freebsd-baselayout installs a lot of crap.

To fix this, I have to move the configuration files from freebsd-baselayout to the packages using them, but that might make things a bit more difficult, as I'd have to fix 5.4, too, probably. Unless I decide to make new versions of freebsd-baselayout only for 6.0 and then mask it on 5.4 profile. That would work, too.

I hope to be able to push on the mirrors an experimental 6.0 stage this week. Unfortunately, the work on baselayout requires a from-scratch approach, or a mostly from scratch at least, as Roy informed me that is too outdated to work with current baselayout changes.
Not a big deal actually, this time I'll see to push all the changes to trunk. Moving configuration files in their own sys-freebsd packages also means that I don't have to care about them and that is good :)

Roy also suggested to leave dhcpcd alone and point to dhclient or udhcpc.. I'll see to give them a try when baselayout and stuff is done. Might take some time.. I just somehow hope that if I find a new job it won't get into this stuff. If it does, you might require some more time (I can always put on DVD my current VMware image and send it to spb (via snail mail) so he can continue the work where I left it... yeah it's a menace! :P).

Okay waiting for my work system to update xorg and stuff, I think I'll just find time to eat something :)

So, tonight I basically slept nothing, as I was able to sleep only at 11am (my back hurts badly, sigh :|), and then I slept in the afternoon, while the vmware was still building system.

The result of this time-clash is that this week we'll have Gentoo/FreeBSD 6.0 stage! :)
And after that I'm probably going to decide what to do: I can start already the work for 6.1 betas, that should be actually quite trivial, or I can try to work on the baselayout. I already asked Roy if he can take a look to see which changes were still missing in bsd-porting branch, if he can do that, I hope to get the baselayout working in 10 days or so (if I don't get a new job that takes my time).

Hopefully with vmware-server I'll be able to work on this more focused, and finally get something useful done. I also hope that GLEP47 can be pushed soon so that the old keywords from GLEP22 can go away finally :)

Oh another thing I'll be working, probably after 6.1 and baselayout are done is the AMD64 version. That is going to be tricky as I have to poke blubb or someone else from AMD64 herd as I need a multilib-enabled toolchain (while freebsd-lib should be already safe for multilib), to build boot0 and stuff. It shouldn't be that hard anyway.

I do really hope that in the next months we can start providing our users with something shiny, possibly some improvement that can be used also by regular FreeBSD/Ports users... unieject is a step in that direction, or at least I hope so; porting dhcpcd can be another good thing.
Let's all work for all this to turn out the best for both worlds, and not only! :)

No, I haven't completed the port yet, _but_ now I have a VM where FreeBSD 6.0 is installed and I can actually start the work.

The first part was the installation process, and that was bad enough because of my hacked evdev driver on the keyboard (I can't use the arrows, I have to use the Keypad instead). Now it's time to see if I can get a working chroot so that I can have a reference 6.0 system while creating the new setup (useful especially to get the libraries if I broke some of them, too :P
I'm wondering if solar has something in portage-utils to find orphan files, because that would _really_ be useful in this situation.

Preparing a 6.0 stage is not so different from preparing a new stage from scratch, with the sole difference that this time the ebuilds should be all already working.
I need to build (by hand) bash and those few packages portage requires, then python and last portage. For this last step I'm basically waiting portage 2.1_pre5, that should come out hopefully today :)

A bit of strange thing not finding screen in ports nor in packages, and not even in base system's sources. I really want portage! :)

Oh and on another note: binutils-2.16 works fine with freebsd-lib, so that is what we're going to use until someone wants to take time to fix freebsd-lib to build with binutils-2.16.91.5, so that --as-needed at least try to work :)

So, as arachnist is working, slowly but somewhat steadily, on Gentoo/DragonFly, I thought I can at least try to do my part on that. My part in this case is to provide a virtual to satisfy the required dependencies of desktop environments and a few more cases: virtual/eject.

The ones who read this blog from its start should know that I started working on unieject because the default eject command in FreeBSD had a command line incompatible with the default eject command in Linux, that then was mostly unusable for KDE, Gnome and other software using eject. For this reason I started unieject that is both a library and an eject command using mostly libcdio for accessing the CD-Rom devices (although it has lots of workarounds on both FreeBSD and Linux because of the incompleteness of both cdio and kernel implementation: for example there's no way to get the features of a CD-Rom device in FreeBSD (thus I have to consider the CD-Roms there as capable of anything and just hope it works) and on Linux I can't use the MMC commands to lock the door (or the kernel filters the command).

I tried porting unieject on Mac OSX, but the problem there is that the device is occupied when I want to access it and I'm then unable to run the eject command on it. libcdio's has to be expanded to support Mac OSX properly before I can port unieject there.

Now it's the turn of DragonFly, that uses mostly FreeBSD 4 interface, so it shouldn't be that difficult. Unfortunately libcdio itself does require to be patched to work on DragonFly, as the CHOST is not recognised; the patch is trivial and seems to work (although I can't test it yet, as I'm just running it through vmware-server), probably it's similarly trivial to change unieject to use the same access used on FreeBSD also on DragonFly.

A part this trivialities of porting it on a different flavor of FreeBSD, there is one thing my unieject misses from standard eject that is needed: the command to eject SCSI/USB devices, useful for pendrives. This feature has to be done in a completely different way, as it's not CDIO-provided, and a part from that, it has to be done in different ways depending on the operating systems (although it shares the unmount support with the CD-Rom interface).
The problem why I can't add such a support right now is actually simple: I don't have a pendrive to test with. Yes, I'm one of the few people that still does not have any USB pendrive, flash card reader or anything like that, the only thing I have is the USB enclosure for HDDs (that I blogged about, especially about the problems I'm still having), and that does not have support for ejecting it.
So probably unless I can find someone to borrow the USB pendrive from, I'm probably going to ignore that support and let things like libgpod not using unieject but rather standard eject. Too bad because that would be an useful feature as, as far as I can tell, FreeBSD does not have an utility to do the same.

Anyway, if somebody is wanting to help with writing translations of unieject, feel free to contact me, so that I know where to take the bzr from ;)

Just a quick note with a big thanks to Mike Auty :) His ebuild in bug #56881 works fine to get vmware-server working :)
I'm not completely sure what the problem was at the end, maybe the 2.6.12+ kernel problem or some permissions not right on my system, anyway now it works fine.

Thanks again Mike.

Now I just need to start working on getting FreeBSD 6.0 working..

After yesterday I restarted working directly on Gentoo/FreeBSD, something that, for a while, I had to leave alone. The first important step was of course an update of the installed stuff to see if there are new problems and if the old ones are solved.
Unfortunately, seems like a few packages now does not build in their last ~x86 incarnation. In particular, findutils 4.3.0 does not build at all, and seems mostly GLIBC-oriented (this happens every other release I've seen; I should probably take a look to their release schedule and watch their development so that when they prepare for release I can check the version to work on FreeBSD.

Also, I've enabled nls support on my Gentoo/FreeBSD mainly because I wanted to know which packages were failing because of that; the result ended up in e2fsprogs failing because the static version of libiconv was missing, so I fixed that in 1.10-r1.

Another failing package is flex, that I hope can be fixed easily, but I wouldn't count on it too much. Binutils 2.16.91.5 seems to behave well this time, a part the freebsd-lib problem I already wrote about, I think next step would be to remove the patch from 2.16.1 (that leads to segfaults) and try if that can be mainline for the time being.

Again, if someone knows how to make vmware-server work on amd64 (it seems not to :( ) please tell me, that would _really_ help with Gentoo/FreeBSD.

It was a bit since last I wrote about Gentoo/*BSD. Actually I had to spend some time away from the project, but now I'm mostly back, finally! :)

So to return with some surprises, the first notable change is within portage: the error "Syntax error: Bad substitution" is now gone, it was due to bashisms in a system() call. Thanks to antarus and marienz for applying the changes (should also make a bit quicker portage itself because of one less subshell called when importing portage :P).

Another change I'm testing now is with binutils. Remember we had to stick with a patched binutils 2.15 because of errors in libraries not being found during linking requiring us to use ld-elf.so.conf ? Well I thought about it, and being stuck on 2.15 is not fine.

Why we needed that patch? Because of the sucky imake... and now Xorg is using autotools (should work on FBSD and if it doesn't, I can try to fix it, autotools is good for me, in spite of imake), so the problem should be gone. I'm trying with last version of binutils (snapshot) and I'll soon report my results.
For who's wondering, without that change the directories specified in ld.so.conf are not considered, exactly as it's being done on Linux.

Unfortunately, freebsd-lib 5.4 does not build with binutils 2.16.91.5, I'll have to see if I have to fix that or just use 2.16 version instead... I should also start to work on FreeBSD 6.0 support, unfortunately vmware-server seems not to work for me on amd64, if somebody can confirm it does work with amd64, please tell me and I'll have to check why it doesn't here.

Oh by the way, Grobian tonight sent GLEP 47 that aims to replace GLEP22 keywords, finally! :)

Okay, so I've started getting Gentoo/FreeBSD 6.0 stage working. The main big problem now is with openssl and python. In particular, seems like the LD_LIBRARY_PATH value is simply getting ignored, they try to run binaries loading the libraries from /usr/lib, that are linked against libc.so.5, then python loads two libc versions and gets killed.
Without LD_LIBRARY_PATH I'm actually a bit stuck, so while I don't find the reason why it doesn't load the just compiled version.

Until this is sorted out, I'm mainly stuck.

In the mean time, who wants to update to 6.0, please sync, and then re-emerge world with gcc built with --disabled-shared, to be safe.

Okay after rebuilding my dev box, I wanted to start working again on Gentoo/FreeBSD 6.0.
The first step was to disable shared version of libgcc to allow to build a libc.so.6 not linked to libc.so.5.. this was accomplished by editing toolchain eclass and re-emerging GCC. The result is good, libc.so.5 was self contained, finally.
The next step was to build libc.so.6 and watch if it worked. To do so I had to build the actual source tarballs for 6.0-RELEASE that weren't ready yet, but that was simple to do with the extract script.

In SVN's overlay there are all the ebuild for 6.0 series, although only some of them are actually compile-tested, I still have to test the kernel, too.

The procedure is more or less this:

1. change the profile to use 6.0 instead of 5.4;
2. emerge -avu freebsd-sources, check that /usr/src/sys is a link to sys-6.0(-rX);
3. emerge -avu freebsd-lib;
4. change CHOST value in /etc/make.conf to i686-gentoo-freebsd6.0;
5. emerge -av1 gcc binutils;
6. emerge -ave system;
7. revdep-rebuild --soname libc.so.5;
8. emerge unmerge =freebsd-lib-5.4*.

Currently I'm rebuilding system, so The last part is theorical, and might have some quirks still.

Oh for the ones following my --as-needed battle, the patches I had are now merged in ebuilds in Portage. I still have to fix avidemux. Rebuilding the system took me 7.5 GB total of /usr/lib/debug files, building with -g3. I still have to try a reboot, tho.
Oh and yeah, splitdebug works on FreeBSD, too!

Following Simon's idea I want to give a status report of 2005 for what I've seen in the projects and herds I'm in.

• First of all, with Gentoo/FreeBSD, when I joined, we wre finally able to get the 5.4 release working mixing portage and FreeBSD code to have a working stage3 support, it took a while.
• We started doing changes to the real portage tree to support FreeBSD, fixing dependencies and adding patches so that packages will build "out of the ebuild".
• FreeBSD 6.0 is still giving us headaches, but I'm currently having an idea that might work.
• Grant (g2boojum) left the lead role for Gentoo/*BSD for Stephen (spb) and I joined as his deputy.
• The Gentoo/Alt project was reorganized, pvdabeel, who seems to have disappeared from Gentoo scene, left the lead role, and I took it by decision of the developers working on Gentoo for Mac OSX and Gentoo/*BSD.
• Fabian (grobian) was chosen as lead for Gentoo for Mac OSX project, taking the place of pvdabeel.
• Kito and Fabian, with help of Brian (ferringb) started working on the prefix support for Gentoo for Mac OSX, preparing the base for other Gentoo/Alt prefixed project eventually.
• The tree started a long road of de-GNU-ification, lots of syntaxes that caused problems on Gentoo/Alt projects are going to be dropped from ebuilds and check written to make sure they won't get again into them, the first notable thing is enewuser which doesn't accept /bin/false (being a Linux-only shell) as disabled shell anymore.
• Damian (thunder) started and released a Gentoo/NetBSD port, Robert (arachnist) started a Gentoo/DragonFly port (but still has problems that hinder the release until they are fixed, part of the code is being merged already, tho), reb restarted the work on Gentoo/OpenBSD which was dismissed by Grant.
• Gentoo/Alt Project Page started collecting technotes and documentation about the various Gentoo/Alt projects, providing a reference for other devs and users wanting to help. The gentoo-alt mailing list was created and an alt@gentoo.org alias is being used for Bugzilla's issues that are common to different Gentoo/Alt projects.
• KDE herd got not one but two major releases using the new split ebuilds, 3.4 and 3.5. We also had to "fight" with the visibility support, that was first introduced in 3.4 but was creating problems because of a short sight in upstream.
• A new Linux-PAM release was marked stable (0.78) making possible to use pamd files compatible with both Linux-PAM and OpenPAM in all packages; also pam eclass was introduced to make simpler their installation.
• Video and Sound team had lots of cuts in their members, mainly because of Chris White leaving them, I took over xine-lib and vlc entirely, and cleaned up the build process with upstream help; after eradicator stopped maintaining XMMS related ebuilds, Luis (MetalGod) took them over; Luca (lu_zero) prepared many snapshot of ffmpeg to cope with requirements of new packages such as xine-lib with external ffmpeg and vlc.
• The GCC4 introduction required lot of patching in packages and shown the limitations of some packages like transcode 0.6, which finally stepped down for the new transcode 1.x releases unmasked last week; the domino effect of those limitations also made us drop avifile support to have more stable multimedia support; currently vlc, xine and mplayer players works fine with no major problems.
• About AMD64, Simon already told everything, I just want to say I'm glad I'm one of the six ATs who joined as a full-time dev :)
• Oh and thanks to Daniel (dsd) we have Planet Gentoo, and we can write these posts to let you all know that we're alive and what we've done (this really helped, especially with Gentoo/FreeBSD and Gentoo/Alt, as it shown a different approach to the whole communication problem).

Yeah we probably did nothing, eh?

Okay, this post is just a recruitement call that I'm trying to launch.
Gentoo/FreeBSD needs more devs, the effort is, right now, most handled by me alone, and I cannot go on with this alone at this point. Stephen is the usual slacker ;) No, OK, he's probably having some reasons why he doesn't work on this full time anymore. Aaron, too. Michael cleaned up the current handbook, and that's a big effort.

What I'm looking for now is workforce wanting to join the project to improve it on some different points:

- somebody that knows binutils, and wants to help with porting to binutils 2.16;
- somebody that wants to coordinate effort to port GNOME to work on FreeBSD out of the box for next release... this is something that would require coordination not only with upstream, but also with FreeBSD people, if they are wanting to do this, but I doubt it (and that makes me feel really really hated :( );
- somebody wanting to split out the token ring support from dhcpcd (that's linux specific) so that it works on FreeBSD;
- somebody that wants to finish my work on baselayout porting, fixing the last issues with networking and making the current baselayout stuff to work on FreeBSD; most of the work is already done, you just need to complete networking and trying to work with UberLord and Azarah to merge them in mainline baselayout.

Already Gentoo devs and non-Gentoo devs are wellcome to speak on gentoo-bsd mailing list (or on IRC, but I'm currently not there because of the new job).

Really, the efforts required are becoming more "mundane" with time passing, so it's not a big problem. But if I'm going to take more jobs in the future, the project is probably going to stand still while I'm working if nobody else is going to help me :)

Thanks to Michael Kohl, yesterday night I finally removed the old Gentoo/Alt documentation and linked instead to the new Gentoo/Alt handbook :)
I've also updated a few bits of the documentation, starting from removing the SVN mirror that's no more available, and then updating the notes about the bindnow-flags function usage.

Today, I'm going to read it more again, and see what I can improve on it. There are a few topics that needs extensions.

As the bugs for de-GNU-ifying the tree wasn't so successful after a while, today I'm going to fix things the hard way: I'll just remove cp -a calls and similar from ebuilds, and make sure they works fine, and commit them.
Hope I won't upset anyone, but that's something I have to do to get Gentoo/Alt rolling.

For side notes about another previous post, I was able to build wine correctly now, but I needed a) to export CHOST and CBUILD to x86 values on ebuild b) to install binutils for x86 via crossdev to be able to select it with eselect binutils. After this, wine built fine. Now the problem is how portage is supposed to handle that out of the box, without requiring users to build cross-binutils.
And for who's wondering how debuginfo works here, I've 557MB of debug data right now, with just a few packages actually.. the most important being kdelibs, that allowed me to get a decent backtrace from KDigest failure; Richard Dale is currently looking at that as he can reproduce the bug. I hope it can be fixed before 3.5.1, so that I can actually release KDigest then :)
Now, to check better, I'm rebuilding ruby, qt, smoke, qtruby and korundum with debuginfo, hope that would turn out good.

It's a sad news, but carpaski's SVN mirror is now no more updated, so until a new solution is found, the SVN mirror of Gentoo/ALT overlay is stuck on an old version and unusable. For this reason, the only way to get the overlay, as stated in Gentoo/Alt documentation, is to use the daily snapshot present on the mirrors.

Just a friendly reminder: if you use the daily snapshot, get rid of the old copy of the overlay before extracting the new one, because we delete packages from time to time: in the last days I've got around removing a bit of packages from overlay, to minimize the occupied space.

On a side note, I broke my installation, again :P I patched the libc trying to get sandbox working, but it does not work as I hoped, and the result is that now I have to restore farragut with a FreeSBIE LiveCD.. I'm getting used to it :P

First of all, a news for everybody who had problems in the past weeks with the Gentoo/Alt overlay's snapshots and the "Invalid keyword" x86-fbsd. After a downtime on lark (the CVS/SVN server), the snapshot generation gone byebye, and the latest commits was lost, these commits included the support for overlaid arch.list (thanks to bbj for the patch).
So, update the overlay from the snapshot, and re-emerge portage to see going away the portage warning.

On a parallel note, Robert Sebastian Gerus (arachnist) resumed work on Gentoo/DragonFly, that would be the fourth Gentoo/*BSD port :) What makes me wonder a bit is that 3 out of 4 ports are currently managed by polish (thunder for Gentoo/NetBSD, reb -with an open dev bug- for Gentoo/OpenBSD, and now arachnist).
The first code to support DragonFly started making his way into the tree (as usual, egetent, enewuser and enewgroup fixes), and I'm waiting for him to submit a few more patches in the next days ;)
Keep it up with the work, Robert! :)

My publisher still has to pay me, sigh :(