So, seems like my system is now stuck in a rebuild loop :)

Two days ago KDE 3.5.2 was released for packagers, and thanks to danarmak who updated the split ebuilds, I started building it, so to spot possible problems with it before user release (and in particular I had to update KPDF's poppler patch,a s a one-line change in KPDF's configure.in.in made the patch unusable as it was, the new version now is for poppler 0.5.1 only).

After upgrading KDE (only one night!), I had to rebuild almost all of it as Thursday I bought a second monitor to help me while working on UML diagrams and code, or with debug and code (Samsung 730BF with DVI input, really nice, and more or less cheap ;) neat to combine with a Samsung 710V that's the other monitor I have), so I had to enable xinerama on the whole system to have it working, as I had it strictly disabled. I launched the rebuild overnight, but had a bit of troubles because of local ebuilds for kio_slp and kerry, and because of ktechlab not building because of a missing dependency in gpsim...

Also, last morning, after waking up quite earlier than usual -as I was waiting for a friend of mine to talk about a job- while working on the UML diagram with Umbrello, I found a problem with Xorg7 and kdelibs... basically in the colour chooser dialog, if you select the "Named Colors" category, it will tell you that it can't find rgb.txt, and that's right as it looks for it in the wrong place. I solved this by editing configure.in.in and adding a new parameter to ./configure: --with-rgbfile, now kdelibs 3.5.2 (and 3.5.1-r1) will pass that parameter when using x11-apps/rgb (that's a dependency OR-ed with virtual/x11), to fullfill the new position of the file. Too bad I didn't spot that problem before or I could have pushed it in KDE 3.5.2 release... the fix is already committed in SVN anyway. If you're upgrading from Xorg 6.8 to 7.0 modular, you'd have to rebuild kdelibs in order to get the new location working, I'm sorry but I can't make it better than this :(

Also seems like CIA stats were reset, all my projets are gone, and now only KDE and Gentoo figures (because I committed to both today).

Adding to the rebuild list, today exg bumped expat to version 2.0.0, that has ABI changes and gets a soname change between libexpat.so.0 to libexpat.so.1. Unfortunately expat links against lots of stuff, starting from fontconfig that's linked on by most of KDE and GNOME packages... and in usual conditions libexpat.so.0 ends up in almost all binaries, leading to an almost complete world rebuild...
Luckily for me, by using --as-needed most of the stuff was clear: I had to rebuild neon and subversion, hal, dbus (for one of the support programs, but the main dbus daemon and library were fine), and of course fontconfig, this one I did for first as after rebuilding that my KDE was stable again. Oh of course I had to rebuild the stuff that can't use --as-needed: wxGTK and users of it, like vlc and mkvtoolnix, but that's an unfortunate thing... I should probably try to investigate the problem in bfd and fix it sooner or later..

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

So it was a bit since last I blogged about multimedia programs, I think, and today is a good day for this :)

First of all, some of you might have noticed that I unmasked/unleashed the first ffmpeg snapshot from 2006. This version had some trouble a while back so I originally masked it because I was unsure of the problem. Today after fighting with xine, ffmpeg and Kaffeine, I found out that when I made ffmpeg respect LDFLAGS I lost xine-lib's support, in the same exact way that it did with the newer snapshot. After I seen that, I knew enough to get looking at the problem and fix up.

Basically the problem was that a lot of symbols related to the postprocessor (libpostproc) were undefined... on a normal system this does not happen as libavcodec links to libpostproc, so it's pulled in in the final plugin linking, and then the symbols are defined. But when using --as-needed as I do, libavcodec is not linking libpostproc, and seems like the same happens with the newer snapshot, which means the plugin does not get the symbols.

So I patched xine-lib to link to libpostproc explicitely when using external ffmpeg, and that solved the problem both with the old snapshot using --as-needed and with the new snapshot.

After xine it was vlc's turn that had the same exact problem, and the solution was basically the same, tweaked the configure.ac so that libpostproc is brought in during linking, so now they both works, yuppie :)

This also means that you can safely unmask the newer ffmpeg version, of course after updating it you have to rebuild xine-lib and vlc, but they'll be fine afterward. And that fffmpeg snapshot has a working h264 decoder on non-x86 (I had quite a bit of problems with it before).
A big thanks to lu_zero for handling ffmpeg's snapshots ;)

Oh, that version also respect LDFLAGS, that might be useful, too.

Okay, today Kopete developers released version 0.12_beta2, last beta before 0.12.0 final.
I have to say, it's a big improvement since 0.11 (KDE 3.5.1), but there are still quite a few unresolved issues.
The MSN file transfer issue is finally resolved, for the joy of many (me between them), the Adium styles support for chats works fine and is way faster than the old XSLT stuff, and also ICQ protocol is improved where it was a bit lost...
But the build system is still quit messy: there's no way to disable most of the plugins (yeah there's a bug in bugzilla with an hacked ebuild to do that, but no, I'm not going to do that just now, I tried contacting Matt Rogers (kopete's main dev) asking him if I can try to get a ./configure parameter to disable at least some of them but he never replied me.
Also, to enable Jiggle (GoogleTalk) support you still need a specific version of speex and ortp, that is not the last one and it's not slotted, so unless someone updates it to use last versions of them, it's unlikely that the support will be added to portage.

I don't have the physical time to work on this, too... if anyone wants to see GoogleTalk support or to disable plugins like the LaTeX one, then please try to fix the API issue and send the fixes to Kopete developers, or just ask Matt if he can reply to my mail and I can provide a few ./configure switches, or fix that yourself :P

Okay this is not news, but seems like it's still a problem for someone, so I'm following fox2mike's suggestion (from yesterday.. I initially forgot about doing so), and I'm blogging about it...

So many people using ~arch or some packages out of ~arch might have seen that a new update to shadow (>=4.0.12-r2) blocks pam-login, and pam-login blocks newer versions of shadow.
Why this? Well it's simple to say for me, as I know the background, but might be less easy to understand without knowing that.

So let's start with the reason why /bin/login was not provided by shadow when using pam (thing that happens on most desktop systems)... to be honest, I don't know that for sure, probably it's just that shadow weren't providing a PAM-enabled /bin/login or it had problems in the past.. so we just gone using pam-login package from SuSE (in the good days when people _provided_ the tarballs for other distributions to use), the 3.x series.
This was all good until shadow 4.0.something started providing a valid /bin/login, so we just had pam-login ebuild to build /bin/login from shadow source code.. but that meant we had to build the same code two times, and maintain patches for two packages instead of one.

So as this was planned for a while but Azarah hasn't had time to handle that, I decided to do the merge between the two: since shadow 4.0.14-r2 the single sys-apps/shadow package replaces both shadow AND the old pam-login package. This means that they block each other now, so you have to do something like:

emerge -C pam-login && emerge -u shadow

if you want to have your system working fine. If you just unmerge pam-login but NOT update shadow, you won't be able to login in the system if you restart (although already running sessions, already waiting login prompts, xdm and variants and ssh won't be affected).

Please also note that you need a recent version of util-linux, that dropped the pam useflag, if you want to be sure that it won't request you to merge pam-login again; ~arch version is fine. For older versions you might want to just set util-linux to use -pam with package.use as it doesn't change anything anyway.

Now, don't start asking for better way to handle this, as portage does not provide anything to improve this. This works without strange surprises, so just drop pam-login and you'll be fine :)

Update: Comments have been closed because this post had too much spam coming. If you want to say yours, use the repost. Thanks, Diego.

Yeah okay, I took a couple of days off lately because I don't feel well, I must have caught a cold and my throat hurts quite a bit. I have a bit of fever too, and that's mostly why I preferred taking these days off (although my throat is pretty annoying, especially since I end up not talking for many hours, fever makes me sleepy and more error prone).

Today I ran a cvs update and updated world just because I wanted to make sure I wasn't stuck with an old vmware-server beta that was going to expire... it wasn't a good idea, I'm afraid. The update of glibc to 2.4 first broke DNS resolution, then ssh and dovecot started failing at authenticating myself, repeating that id 501 was not in /etc/passwd (it always was).

Also, KOffice 1.5_beta2 update wasn't so smooth, as I had to change the eclass to fix the change in upstream's URL scheme, sigh.

Also, from an entry of Bram Schoenmakers today on Planet KDE, I found that kde-misc/rsibreak was incorrectly marked stable on x86... sorry for anyone who thought that was intentional, now it's back again in ~x86.

Why I can't have a normal break, at least one time? :'(

Okay, if you read my blog since enough time you should know I sometimes take time to fight some "unfriendly" packages, that for some reasons break QA, or annoy me someway. Today's foe is packages that strips their binary during compile or install, either by running strip, by adding -s to LDFLAGS or by using install -s.

Why I want to fight this enemy? because they waste my space right now.. I use splitdebug and compile with -ggdb to get debug information, and having stuff with stripped debug information is plainly annoying.
I'll start with the packages I maintain myself, and then go down to open bugs for packages I don't maintain, so that the stuff I get in .so.debug is not stripped.
After that, I'll also probably spend some time to make sure splitdebug doesn't start copying stripped .debug files to /usr/lib/debug at all.

I hope that might be of help to other people, too.. I know it's not something _that_ important, but I like thinking that these little things are still things to fix. I'm this way, I don't maintain big central packages that anyone has to use like base-system does, I don't even handle most of KDE that impact users, I just like the little fixes that nobody notices :)
Oh well, I think that can't be helped, it will simply mean that I won't be the most famous developer ;P

So, I've been playing with qualudis since yesterday to cleanup media-libs and media-sound. I've added quite a few metadata.xml files and removed some virtual/libc dependencies.

Today I felt _extremely_ bored and I decided to do one more step, I started looking at custom makefiles, to check if they were respecting CFLAGS and LDFLAGS. Many weren't, sigh.

Basically I spent most of the day following this routine:

• check qualudis log for a media package with warnings;
• check if the packages is owned by one of the herds I'm in and has no direct maintainer or if it misses metadata;
• if metadata is missing, put a maintainer-needed one;
• drop virtual/libc dependencies and in general clean them up;
• check if the package respect cflags, if it doesn't fix it;
• check if the package respect ldflags, if it doesn't fix it;
• if the package strips by itself, drop stripping;
• if the package doesn't build with GCC4, fix it;
• if the package isn't ported to modular x, fix it;

and I ended up doing more than 70 commits, sigh.

Although I'm quite happy that I finally managed to cleanup at least the stuff for sound's herd media-sound category (not counting the ones maintained directly by someone else), I think I've seen creepy stuff probably inherited by long long ago and never touched since then... some ./configure direct calls for example, or big seds where a simple redefine on make command would have helped, or make called without emake... and so on.

Luckily I should have been able to fix most of the oldest stuff.

Okay time to get again to work on that -waiting to hear for my actual job :P-

Okay, today was a very bad day for me, and I'm sorry to all the people I treated badly on IRC, wasn't my intentions, just sometimes you're so tired that repeating the same thing as usual becomes a problem.

Just to say what happened, as that might be of interest, I spent two days rebuilding world because with last upgrade from gcc 4.1.0_pre20060227 to gcc 4.1.0 final stuff started crashing down, but that didn't solve, this morning when I returned to my desk I found konversation and kopete still crashing and that was annoying enough by itself. Add to that about 80 bugmails mostly caused by ffmpeg's update, plus another 17 comments just for the kpdf and poppler bug, and the fact that one of Level3's routers which carries data for my ISP to America seemed to be having problems, making unreachable to me both bugzilla and cvs, and you have a good situation of what I faced today.

Little note for people who wants to know what might annoy maintainers often: changing API in a non-compatible way in a micro release is something that people won't like that much....

Anyway, KPDF is fixed now, and builds with poppler 0.5.1. It took me a while because not only because I had the connection trouble, but also because I wanted to provide a true solution instead of a dirty hack.

Then, amaroK 1.4 beta2 was released, enjoy! :D I've bumped it in portage less than half an hour after official release as I was idling in #amarok at the time ;) My overlay also started carrying the rc1 version in mid afternoon, I didn't know portage now handles names like 1.4_beta2_rc1... that comes handy for these kind of releases ;)
I think there are a few changes in amaroK that are worth noticing, the first is that the GStreamer 0.8 engine is no more, and amaroK now supports only GStreamer 0.10, so if you're still using GStreamer 0.8 you have to stick with amaroK 1.3, then also arts engine is no more, and this has another side effect: we were installing amaroK in KDE's prefix to let aRTs find the plugins it was installing -and because of splash screen in 1.3, but that's already solved as it uses KDE's resources system now- so I did two versions of amaroK 1.4_beta2 ebuild... the first one is a "classic" one, that installs in KDE's prefix, the -r1 instead installs in /usr, without the hacks for moving around amaroK's .desktop and icon files. Please give it a try and report if there are troubles.

Another update instead for Kopete users: as the obnoxious bug with MSN filetransfer has now a resolution upstream, I've applied the patch to net-im/kopete-0.12_alpha-r1, kde-base/kopete-3.5.1-r1 and kde-base/kdenetwork-3.5.1-r1. I tried this with a friend and it works fine indeed :)

Oh a little end note for the people asking for rsibreak and katapult on x86. I'm on AMD64 arch team, and I only have an AMD64 at hand (well no, ok, I have the iBook that's actually not yet completely updated, but I never asked to be able to mark ~ppc and that wouldn't help either ;)), so for the ~x86 keywording you have to ask the x86 arch team by filing a bug asking for the keyword to be added. Please don't ask me, I can't do much about that.

So, up to now I usually responded to strict aliasing breakage from programs with adding -fno-strict-aliasing to be safe.
In the last days I tried, on Donnie's suggestion, to investigate of possible solutions to those strict aliasing rules breakage and see if I can fix at least some of them.

I found interestingly that most of the cases that can be found patched on google, and that causes the warnings are not actually involving structs and unions as the gcc documentation shows, but rather double pointers. What's a double pointer? A pointer to a pointer, of course!

Taking a look to XdTV, I found a quite interesting thing: this is a double-linked list implementation that comes out of AleVT code, that is used by XdTV too. The cause of the warnings come out of lines 20 and 22. I'll look only at line 20:

h->first = (struct dl_node *)&h->null;

well seems fine no? But wait... &h->null is a struct dl_node ** ...
And later on, h->first is going to be used as a struct dl_node * ...
So for some kind of miracle this seems to work, but I'm not that sure that this is something that's going to work forever.

And there are other casts that works probably only for sheer luck in AleVT's code. Upstream seems to be dead sicne 2 years (last update on the site is January 2004), and we don't have really good alternatives to it...
If someone wants to write something useful to people.. probably a replacement for alevt using zvbi would be useful ;)

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

I was lately thinking that the quantity of extra KDE applications in portage is really low. There are lots of tiny programs that might be of help to users, but for a reason or another they are not in portage.
Some of them can't be added in portage because they have problems: crashes, security issues, automagic dependencies; others simply because we have not enough man power to handle all of them, although most of them just requires a bump from time to time.

So what I'm doing? Well after adding RSIbreak yesterday, today I'm going to add Katapult 0.3.1.1. I wish to thank Mez for his help :)

Unfortunately the main problem is that these applications really needs to be checked and verified to be working with latest versions of KDE, so I can't just add things I'm not going to use. I've added RSIbreak because I'm trying to avoid remaining all the day long at the keyboard never stopping, and Katapult because Mez asked me (and I started using it, and it's quite interesting :) ), but most of the stuff I won't use and won't find its way in portage through me... so you have to find someone else to add them or become a dev yourself ;)
I'm really hoping to be able to improve the KDE experience in Gentoo, as lately it has become a bit of a problem. The 3.5 series is not good enough to get into stable, and the 3.4 has its share of problems right now. Yesterday I added to KWin the patch that solves the problem with systray icons at login moving into the left-top corner of the screen.

Sometimes I wonder what will happen if I take a "normal" job and I have to drop some of the Gentoo stuff I do :P

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

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