Diego Pettenò

Donnie already written quite a lot about porting applications yet to be ported to modular X, but there is something that is probably difficult for many people to see as a problem.
Porting applications that usually inherits X11 dependency from other libraries.

KDE is a big example of that: most of it uses Qt abstractions instead of accessing X11 directly, so after Qt is ported there was no need to port all KDE packages. Unfortunately this isn't always the case.
When I started dropping support for things like xcomposite and xscreensaver, I added a few dependencies for Modular X to some packages like kdesktop and kwin, but probably many are still missing.

Today I fixed net-im/kopete to have a xscreensaver useflag to enable idle detection, as I added RSIBreak to the tree with libXScrnSaver as an hard dependency, and then I found that it was linking to lot more stuff... I had to rebuild Kopete 4 times today then, and that quite sucks because it takes a lot of time to build :( I should probably ask Matt if it's possible to add a few --disable parameter to configure so one has not to build things like the latex plugin, all the protocols like gadugadu and so on, trying to minimise both the build time and the stuff that can break (remember: more code, more stuff that can break).

This is what I like of Gentoo mainly. I can choose what I want and what I do not want to compile. Not even use, compile. The less libraries I link against, the less chance to soname changes to break my system, the less code I build, the slighter the chances of having security problems.

Anyway, starting tomorrow I'll try to continue fixing the modular x dependencies of KDE, hopefully that will mean that it would be possible to install kde without having to merge xorg-x11 at all :P
And of course where it makes sense, for extensions that people might not want at all, I'll try to provide useflags :)

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

I want to suggest reading last Philip Rodriguez's entry on his blog. It's an interesting insight of the common tasks that can be done without being developers.

I agree with him, and I actually already wrote an article about it, in Italian tho, so not for all the audiences... this is a bit more accessible ;)

Really, give a look to that.

Okay, I originally moved unieject from local SVN to a BerliOs SVN; then I moved from BerliOs SVN to a bzr repo as I was trying to get away from BerliOs SVN after the passwords defaiance.
Well when BerliOs started mangling the downloads (thing that they luckily dropped now), I registered unieject at SourceForge so that I could put there my tarballs..

Now, SourceForge has an SVN hosting... so I simply backed off from bzr again, and I moved the SVN to SourceForge. Getting the dump out of berlios is simple, as I had only to use the last nightly tarball as I didn't committed anything there for a while; then I loaded the dump to the new importing facility and in the matter of half an hour it was imported... a bit hacking around and now the repository is set up with the changes from bzr imported again.

Now if someone wants help with unieject, translations or code, feel free to drop me a mail so that I can add you to the project :)

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).

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).

I'm happy to see that Matt decided to go with a new release of kopete out of KDE's release cycle.
This is probably going to help quite a bit the development IMHO, as there won't be any more 3.x series releases a part bugfixes, but Kopete really need more work on features and protocol support, not just bug fixing.

The new release, 0.12-alpha1, really impressed me: the new chat window engine, using CSS instead of XSL is way faster, although I had to edit the style I choose (from AdiumXtras, that I already knew as I use AdiumX on OSX) to remove my own icon from appearing, this because every time I sent a message it appeared to take my avatar image, and scale it down to what the skin required... pretty CPU intensive, especially as it wasn't caching at all.
Well not a big deal, I don't like watching those avatars anyway :)

Anyway for who wants to test the ebuild is in in my overlay. I'll wait a bit more before looking into adding this in portage, just to solve the possible big issues with it.

I'm anyway good impressed with the work that's being done. Although I didn't enable the jingle (Google Talk's talk support) as it requires an old version of oRTP (0.7.1) that would create a new dependency up-downgrading, and I'd rather wait to see if somebody is going to make it work with the current 0.8 series.

This version seems really to improve the responsiveness of the application in its entirety, so it's a good step forward. Only thing I found strangely long was the shutdown... and I have no idea why, it starts a long series of munmap, takes a long time before it actually closes...

Oh well, I'm really looking forward to beta1.. and I really like being able to use Adium's styles.

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 :)

Okay so a new amaroK is coming: the release candidate of the first beta of 1.4 series of amaroK (how many 'of' are too many in a single phrase?) was released yesterday, and I strangely enough not blogged about that yet :)

The ebuild for such a version, that I named 1.4_pre1 as I couldn't name it 1.4_beta1_pre1 (maybe using redhat-style 1.3.90_rc1 would have helped :P), is currently in my overlay, if you want to try it out.

Note: Ruby is now an hard dependency, as without it you won't get lyrics support, and maybe other in future.

I also dropped the extra use flags for gstreamer's plugins, I was finding that too confusing and the same was for at least a couple of users I heard from. If you want to use gstreamer, please at least learn how to install its plugins :) This might also solve some of the problems I heard of like "gee I unmerged amaroK, ran depclean, and now ｢put some gstreamer app here｣ does not play ｢put some format here｣".

I must say, if you just want amaroK to work smoothly, don't try this yet. While markey solved my issue with module files appearing as "No track playing" in OSD (thanks markey :) ), there are a few things I find a bit of regression (trying to get a hold of some dev on #amarok right now to tell them): the randomness is not so random anymore, and the "previous" button while playing a randomised playlist does not return to the last played track, instead it moves to the previous track in the sequential playlist open in amaroK in that moment.

Still, amaroK 1.4 is very well promising, and I'm sure that before the release those glitch will be fixed :) Thanks for all the work, amaroK devs!

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 ;)

Okay, tonight with the help and hints of marienz, I did one more step toward bazaar-ng (bzr). As I found something I don't really like. If this is true, well, it might be quite a bit of a problem, so I don't really think of telling people who would help me to join berlios and use SVN at this point. With bzr the problem is way different.

So what's the deal? I moved unieject on a bzr repository, that can be found at http://dev.gentoo.org/~flameeyes/bzr/unieject . If somebody wants to help me out with code or with translation, feel free to branch that to me and send me an email with the URL you're going to use and what you'd like to work on exactly :)
Also, you might want to read how to set up CIA for bzr so that I can read on unieject's project feed your changes :)

Now I just hope to get someone working on it with me at least for the translations :P

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! :)

Strange entry this time, all coming from Grant's request of adding PAM support for the blowfish crypt() function from OpenWall. Unfortunately such support in simple PAM is going to be quite of a problem, because as it is, it requires the patch to be added to glibc.

Now, I don't think it will be simple to add the support for the PAM module just for those functions as they are, because of the GLIBC interactions. But the code is public_domain ...

So I'm tempted to say, if somebody here would like to add support for blowfish in Gentoo as a PAM module, based on the code from OpenWall, and can make a libbfcrypt.so library, patching the PAM support in OpenWall's TCB, I'd be glad to add that library and the module in portage.

While the GLIBC patches wouldn't be difficult to manage most probably, having the functions in libbfcrypt.so would allow to use the same PAM module on FreeBSD (in particular Gentoo/FreeBSD), and that is certainly an advantage :)

So if somebody would like to make this more Gentoo friendly, is welcome to contact me for adding them in the tree.

It's not the first time I blog of something just not to forget about that :P This time it'st he turn of how to set the name of core dump files to something meaningful so that I can know which hell of an app left them around.
I have to thank ehmsen and brix for pointing me to the right directions as I had no clue how to do that before :)

Why do I need such a name scheme? Well I'm experiencing some strange crashes lately with akregator and a few other programs so I'm tempted to just get a backtrace and then check where the problem is hidden, unfortunately by enabling corefiles for everything you get a lot of files named "core" or "core.<pid>", nothing useful to recognise what you're looking for.

So what's the solution? /proc/sys/kernel/core_pattern is where the kernel take the template for the core files naming... so I just changed that to '%e.%p.core' and now i have the files just called "<executable>.<pid>.core" (so that they don't overwrite each other). Good eh? :)

To make this a stable change, just put at the end of /etc/sysctl.conf the line
kernel.core_pattern = %e.%p.core
Now, I just need to remember how to enable core files for my user to be always generated ... :P
IIRC it should be something like
flame C204800
in /etc/limits (limiting to 20MB of dump). But I still have to try :)

Well I said some time ago, while I don't really have an actual use for IME to be enable on my box (not like I actually know enough of Japanese or other cjk languages to use it "daily") I do like having it at hand for the couple of words I remember. It's also an interesting way to call scripts ;)

Because of this and that, I eventually ended up having, in my overlay, a few updated ebuilds for app-i18n apps like scim and skim, and today I added a new version of scim-anthy (0.9.0 with ~amd64 keyword missing in 0.8.0 in portage) and the new skim-scim-anthy package to configure scim-anthy itself (needed a patch to build with Qt 3.3.5).

I'm trying to find some of the CJK people to get those version bumps in portage, but with scarce results for now :P

For who wonders where my overlay is because wants to try the ebuilds, it can be found as a bazaar-ng repository at http://dev.gentoo.org/~flameeyes/bzr/overlay. To get a copy of it, just to this:

emerge bzr
bzr pull http://dev.gentoo.org/~flameeyes/bzr/overlay

After that a simple bzr pull will bring in all the changes in my overlay since last time :)

On a semi-related (to bzr) note: Brian passed to me the maintainership of confcache ebuild and with that the responsibility of the emerge breakages due to it... it will be funny when portage 2.1_pre5 will be released with confcache support in it :P
I'm starting wondering how many configure.ac I'll have to fix ;)