Diego Pettenò

Original date/time: 2005-09-29 21:16 CEST

Okay this is a blog entry wrote in Kate, as I'm currently without a net connection right now. The reason? Seems like my ADSL provider forgot that what they should do is providing an ADSL, not counting on users that exchanges IP packets over pidgeons. I can count at least three people in the neightborhood that are without ADSL access, and probably this is extended to the rest of the users, as they closed the tech support line at about 16:00 while they should respond till 22:00.

I haven't wasted the time without line, though. I continued my work on ATMOSphere, a network monitor for KDE, that uses kioslaves and other KDE component features to provide a functional network monitor without using any external interface but Konqueror, KControl and so on. I also wrote what I think about Gentoo/OSX lead needing. And finally, I'm watching "House, M.D." episodes, in english, trying to improve my speaking.

I also got some old, probably broken, computers today, I hope I can get at least a Pentium box working as I'd like to use it as my router, putting on it OpenBSD, so maybe I can get IPv6 Working here, to assign different IP addresses to my local boxes. There's nothing big enough to run a decent Gentoo installation and I have no harddrives, so I'm quite limited in what I can do with those boxes, but something can be found, I hope, with a couple of extra cards I have at home.

I must say that Inkscape is a quite interesting tool, also for someone like me that can't draw and does not like doing so. I used it to get a couple of icons for ATMOSphere, so I can at least have a decent look'n'feel, as I'm using mainly the same interface of the rest of KDE.

About ATMOSphere, I should probably say that right now I'm able to wake up a box using the wol command, aliased to a simple menu functions, right mouse button click on the box to wake up, and then select "Wake up", simple, eh?
Unfortunately, I'll have to use SNMP to get other data from the boxes, such as statistics about the interfaces and so on. I hope I'll be able to get them in a decent way. The idea was to show the data as HTML pages, but I'm not sure about this, as it can be a bit of a problem to get automatically data about them.
The structure of this version of ATMOSphere (2, or NG, or whatever you want it to call, it's a from scratch rewrite, with different needs in mind actually), it's actually completely different respect anything I've done before. Most of the code resides in a general atmosphere application that runs on the background (I still have to find a way to start it automatically.. there's KDED but I'd like to avoid that if possible as it requires to reload completely the daemon to change its versio, as it caches in memory the library; I should probably restart the work on the kdedtester thingy to allow to start a kded module as a single process), both the kioslaves and everything else that would access to the data about the boxes controlled by atmosphere access their data with DCOP calls, that explicitely name the box to get the data for. Using stubs and skels to sue with DCOP makes this quite simple to achieve, as it's just a normal call in the client.

I'm still thinking if i should integrate things like WakeUp on Lan with the code to send the packets, or I should just call an external tool (right now, "wol") to do the job. I anyway have to use external "ping" command to get the pings, but I'm looking for something more reliable to see if a box is up or not.

Okay, after yesterday's meeting, I was chosen as new Gentoo/ALT lead. This means I have to look after a project that was "idling" in the past months, while its two subprojects did similar things in different ways...

After the meeting we started reorganizing the project pages updating the developers' lists and I asked lcars a new mailing list (gentoo-alt, now in place). I'm planning on a couple of things more that would probably help to coordinate better the two projects, but they needs to be discussed.

I also updated the maintainers' notes that now are for the entire Gentoo/ALT, and moved on Gentoo/ALT project the common tasks, now I just need developers to join those tasks ;)

The meeting's log is on the project page as well, and now I'm working for adding more resources.. also the inheritmembers thing seems not to be completely working on higher level, so I have to contact Paul and asking for his help, too :)

I think this is something that can be useful to people to know.
With new trash support, that should be used by Gnome, KDE and XFCE transparently, one can have a trash directory for every partition, so the "Move to trash" action does not take eons to move big files around...
Also if someone can think that this is something that is just for lusers or similar, I think a trash can be helpful, always, as everybody can be not-so-present with the mind sometimes.

So well, what has one to do to be able to use the Trash effectively outside his home, in a partition where he can't give the user the full write control (like / or /var) ?

Quite simple actually:

sudo mkdir /.Trash
sudo chmod 1777 /.Trash

repeat that for every partition where you want trash support enabled, and there you are :)

Ok the real reason I blogged this was to avoid forgetting this again :P

Okay, after some days spent working to get KDE 3.5_beta1 working, thanks to Gregorio and Marcus who fixed, and Chris who tested the ebuilds, I was finally able to start looking at KDE 3.5
After yesterday's odissey with arts, I was finally able to get sound again, but while I was trying the new media manager (that uses new hal and dbus), I found that it was failing to use pumount to umount (and then eject) the CD-Rom. I looked here and there until I found the cause in a wrong parameter to pumount call (/dev/hda/ instead of /dev/hda). I fixed that in both KDE 3.5 branch, and in kdelibs 3.5_beta1-r1.
If you see, my philosophy is to fix also if it's a beta, because I want to have a working setup :) Also, all my patches goes upstream directly.

Anyway, after some use, I can say that KDE 3.5_beta1 is impressive regarding the stability and the new mediamanager is really really interesting. The new "Add Applet.." window is way better than the old add appled menu (and makes now sense to provide big icons for applets.

The only thing I still don't like is Cervisia, but that's not Cervisia's fault: every frontend to CVS that uses the command line client to execute commands is IMHO bad, by design. The only frontend I ever used and found useful was TortoiseCVS, but luckily I don't use it since a looong time.

Today I was really missing my notification sound on new mails on KMail... that because after I updated to 3.5 for the first time, I got arts crashing every time it tried to start. The same gone when I moved back to 3.4, and the same remained with 3.5_beta1.

So tonight I started looking at that, asking around if somebody else had the problem, and then a schema started to come on my mind.
The problem could have caused by GCC4, or by QT 3.3.5, both are masked, but I'm using them.

I looked a bit around, and I found that arts was still building with -fvisibility=hidden .. that was not right. This flag was intended to remove from the resulting objects the symbols for private methods of classes and similar, relieving the loader from loading them and reducing the objects' sizes. But that flag is broken so its use is discouraged.

Now what the deal with that? Me and Marcus found a problem with that on KDE 3.4.0, kasteroids crashed because dynamic_cast failed, due to RTTI being fooled up by the hidden copy of Qt classes, this was worked around removing visibility support in KDE on Gentoo. This was safe after 3.4.1 and was safe for 3.4.2, mainly.
Now, why the same problem happened again? KDE Bug 109386 shows that Qt still does not like visibility, making its support still unstable. But.. Gentoo should blacklist it, no? Well not exactly, for some reason the check that I designed to remove the visibility support was changed, in kde eclass, so not for kde-meta, to let the visibility support pass on KDE different from 3.4.1.. this was not a problem until now, because the support was disabled as Qt was not patched with a special patch, so the ./configure automatically disabled visibility support for us.
So what, again? There should not be problems about that, right? No.. but I'm using the masked QT 3.3.5 that are recognized as *having* the patch.

Okay so the problem was due to a masked package, but not for the reason it was masked for, nor the problem was unavoidable, as if the check was left as I designed it, visibility was basically still disabled and the problem wasn't going to happen.

Well now the problem is finally fixed, I have again sound in gaim, still not on kmail, hope I don't have to recompile kdelibs from scratch :/

I must say, yesterday's night was really a recharge. It was quite a bit of time that I wasn't going out with friends and having fun, and I really needed it.

I was still able to get all of KDE 3.5_alpha1 removed from the tree before going, with about 300 commits.. I was also able to get the system updated with a screened session and a little SSH.

But what that dinner shown to me is that I really need a bit of break, I need to find time for myself, to read, to go out again a bit...

Anyway, now I have to clean up the mess in my room or I'll be killed, so for today you'll see less commits from my side, yesterday was worth a couple of days of commits, in number ;)
No really later I think I'll try to get a hold of GuideXML to start looking at the G/FBSD technotes, or Chris will really kill me when it will be time to add more things and more pages :P

Seems like my xml2man description was too fast.. it wasn't doing exactly what I wanted, but that was not a problem... I was able to change it to suit my needs :)

Now, mxml2man is doing big steps forward, it supports quite a few more tags, but the format is still a bit raw, and the way libxml2 is used makes it difficult to handle it as I'd like.
But that's not the point, as what I want now is being done, this is good :)

On a completely different note, today I seen the last episode of Tru Calling aired in Italy. Quite interesting series, too bad it was cancelled. I should probably look forward if they'll release DVDs, as I'm trying to improve my English and watching TV series joins fun and learn :P

Okay, so today I continued my work on unieject. I started some days ago adding a new function, to lock/unlock the tray of the CD-Rom, similarly as done by cdctl -o option. Unfortunately, also if I was sure of the MMC command to send, and I checked twice in the Linux kernel and in the headers of Microsoft's DDK, the command was just ignored... today, Ghisha remembered me that Linux whitelists just a bunch of MMC commands, so I tried unieject on the FBSD.. and it worked fine... groan.
Now unieject does the locking on Linux using a workaround, hoping that the ALLOW_MEDIUM_REMOVAL command can be whitelisted in the future.

Unfortunately adding the command to the manpage I found that for some reason txt2man was not working as intended anymore :/ So I remembered that there was a kind of xml2man thing somewhere... I googled and found xml2man command from Apple... looked at it on my iBook, and it seemed to be what I was looking for. For linux I found an xml2man perl script, but not compatible... so, being that APSL... I took the sources, written a configure.ac and a Makefile.am and then released on project page an autotooled version called mxml2man (mxml is the name of the XML format used to create manpages, according to the documentation, this name is different from the original to not collide with xml2man script that I told of above).

This is something that I really like :) A tool that is not GNU not even Linux native is now working fine on both Gentoo/Linux and Gentoo/FreeBSD with minimal change (a couple of includes changed from sys/dirent.h to dirent.h). Perhaps the same work can be done by a good xsl stylesheet, but I'm not yet good enough with them to prepare one, so if someone wants to try, feel free, if it can be replaced by an XSL I would really like to use it.

Oh no, you won't find this in portage for now, I think I'll add that later, I still have to use it for unieject and I'll probably not make it a build dependency.

Cya!

Ok I finished committing KDE 3.5 beta1 this night. I wasn't at my LUG meeting because of my usual gastritis....

Well anyway I just wanted to let everybody know that 3.5_beta1 seems to be quite stable and is worth testing.. it's not yet completely qt-3.3.5 safe, tho, so you could need to wait a bit to use that version also with experimental KDE.

Tomorrow is going to be a long run of tests and fixes :P

Ah I also started cleaning up sound project page.. this is going to be a bit repetitive as in two weeks is the second project page I have to work on :P

Oh well I'll start learning GuideXML, too.

Last, another thanks to amaroK upstream, in particular to Mark Kretschmann, who sent me a patch to amaroK to fix the crash on startup of 1.3 series. 1.3.2-r1 should be now safe. Thanks Mark :)

If you haven't noticed that my commits in the last days were less than usual, well you're going to have quite a bit of a surprise in the next days :P

I'm currently waiting for KDE 3.5 beta1 to compile, after that is finished, I'll start committing the new ebuilds. Seems like the QT mess it's still not cleared up in 3.5, not only in 3.4, so there will be patches applied to 3.5_beta1 ebuilds, too. Luckily, those patches can usually be applied to 3.4, too, so the number of packages failing because of qt 3.3.5 is going to decrease in the next days. K3B and amaroK are already fixed.

Talking about amaroK, I wish to thank Ian Monroe for notifying me of the prerelease tarball, so that I was able to create the new ebuild and test it before the complete release :)

I don't feel right now like writing too much, as I'm waiting for KDE to complete its build, and today was a long long day. I won't be paid for my translation until late November (if nothing goes wrong, eh), so in the mean time I probably have to look for something else as I'm afraid I have to change my audio amplifier soon.

Anyway, tomorrow evening is scheduled a new meeting at my LUG, hoping not to get fighting because of the already said reasons.

And to close, a little personal request for who's reading this :) If somebody knows an European e-shop for multimedia equipment that sells in Italy (and is written in English, French, Spanish or as last option German -these are the languages I can sort of understand... actually I have to have German translated, but that is), with not-so-high shipping costs, can drop me an email (flameeyes _at_ gentoo _dot_ org) with the link? Maybe I can find the amplifier a bit cheaper than here. :)

Good title for a TV series, by the way.

Ok tonight I had quite an argument with a friend of my LUG about the incompatibilities between OpenOffice's and KWord's OpenDocument formats. I'm not going to talk about this now, as it's not what concerns me right now. It's not even Palladium what concerns me. It's absolutely not Microsoft.

It's the people.

Let me explain this. I hope I'm usually open minded, I try to see all the aspects of the things before decide. Maybe that's why I'm intersted in Gentoo/FreeBSD, because it's a new point of view, new way to look at Gentoo, new way to look at FreeBSD, new way to look at Free Software.
I'm not one of the people that fights because GNU/ must be always prefixed before Linux. It doesn't matter for me. I usually say "Linux" because I'm open to non-GNU Linuxes.

What scares me are people that looks at the things just from their only point of view not considering others'. The ones that insults me because I think the "GNU/" in front can be omitted in daily speaking, the ones for which I cannot state that I find some choices in OpenOffice opinable, because it's "great" and "opens ms office files".. well if I just have to look at opening MS Office files... I would go with MS Office, no? What is important to me there is the "Open" part that, IMHO, is a bit missing lately.

Those people scares me, as scares me people that is trying to hinder Gentoo/FreeBSD because I'm "making them waste time" asking them for one line changes and offering to do that myself if they want, as scares me people that works on a new OS just because "Linux is just about fighting Windows"...

I don't think that different solutions are wrong. I don't even think that the same solution apply to everyone. I don't use Windows, but not just because it's non free or just because it's not suited to my needs. I don't use it because it's non-free and it doesn't suite my needs. I use MacOSX, also if it's not completely free.. because it's partially free and this is an improvement and it suits my need for the "battle" box (the iBook).

These people scares me, because I was told to be partial about Gentoo and KDE because I work on them, so I always say that they works for what I use them for. Well it can be hard to tell for someone, but I haven't started using them because I was working on them, I started working on them just when I thought they were suited to my needs. If they weren't I was surely not working on them! (Cause-Effect principle)

Another thing that was really pissing off was that when I was told that, because I don't have a job in an office I cannot know what the "real world" is. Well, I'm sorry if I'm still a student, but still, I think that what I do for Gentoo and the other project I work on is at the same level. It's volunteer, and I'm not paid to do that? This doesn't matter! I do that with the same seriousness that I would put in a paid work. I do that because I enjoy it, but I'm still doing it seriously!
If I'm going to be paid to do something that I really don't like, I would probably try to change that work, not telling everyone that is doing something enjoying it that "doesn't know what the real world is".
About the pay thing, telling me that my work doesn't count as I'm not paid is like when people say that Linux is not good because you don't pay for it. It shows the nonsensical, stupid prejudice that is hindering Free Software application.

I would like to be paid for my work on Gentoo. I'm not. This doesn't change the commitment I have for this. If I'll find a paid job I might reserve less time for Gentoo, but without changing my way to do what I do. In the mean time, I think that knowing that someone else is going to make use of my work, that someone else might be saving time, maybe to use it with his family, is a payment on itself. But I wouldn't do it for something that doesn't suite my needs. I wouldn't use or develop software just for Windows just for the sake of it if it doesn't suite my needs. I'd rather use my time to work on software on Linux and FreeBSD, for Gentoo and KDE, for KOffice, for whatever I find suits my needs!

That said, do whatever you want, if you piss me off enough, I'll simply start ignoring you and your requests.

Edit: Thanks to Brian for make me note that the writing was a bit complex to read, I shouldn't do such posts at late hours, without caffeine in veins :P

I think this is worth some blogging, as this problem has been quite common. Yesterday qt 3.3.5 was updated on portage. This version featured an early patch from Aaron Seigo to fix an UIC bug.

Unfortunately this patch is not enough to work fine as it should, so we started receiving bugs of "KDE does not compile", eh, right.

Unfortunately not all the problems are fixed on SVN, and most of them are actual source bugs. amaroK 1.3.1-r2 is fixed, but most of KDE fails, and so does a lot of the extra software we have in portage.

Now, qt-3.3.5 is p.masked. If you feel like daring this, unmask it and try to merge kde and other stuff.. please don't submit bugs for that unless you have patches, too. If you want to make patches, they are welcome :)

Update: comments disabled because I was receiving lots of spam comments just here...

For the glory of "the less, the best", I just removed one more big program from my system: Apache.

While I was always using Apache2 until now, tigger^ convinced me that it was like shooting at a bird with a H-bomb, so I gave lighttpd a try.

The thing I was most glad to see is that lighttpd works fine on Gentoo/FreeBSD, too, without changes nor edits, and it supports kqueue natively ;)

For the rest, I usually use the local webserver just to give files here and there instead of mailing or sending it by various IMs, so I don't need any of the super-duper functions of Apache, lighttpd is probably the best shot for me :)

It was a bit that I haven't blogged about unieject, my eject drop-in replacement that works on Linux AND FreeBSD based on libcio.

Well many things changed from the last time I blogged about it. The release 4 is out for a while and seems to behave in a decent way :)
The next version will probably feature more clean code AND the opportunity to disable extra options like the configuration file that depends on libconfuse. This makes possible to use unieject without installing all of its exotic dependencies (libpopt is not so exotic, as RPM and many other packages uses it).

But the most important change in unieject project is the fact that now is hosted on BerliOS. That means that there is a public SVN repository, a place where submit patches and a decent mirror for releases :)
This change is also needed to make possible to actually *have* translations, as just enabling gettext makes impractical for translators to submit their work. So if you want to have unieject in your language, well just send me an email and I'll add you to unieject project so that you can commit your own translations. The same obviously goes if you want to help code or document it :)

I must say that in the last days I was a bit slacking off the night at least, as I started enjoying watching movies in english (without subtitles, and I can understand what they say, w00t! :P), and tonight I found my new addiction, flobopuyo! That game is great :P I was already a puyopuyo fanatic, and having that now, is really a way to refresh the mind :D

Ok well, for who's curious of what my tastes are, I have also updated my froogle's wish list, also if I don't think I will ever able to buy anything from that list :P

Oh by the way if someone remember the logitech wireless keyboard I bought some time ago, seems like tonight the batteries faded out, so I replaced them with a couple of rechargeable that at least will cost me less :)

Ok going to do something useful now :P

Not sure if anybody will notice this change, but I just renamed the Gentoo/FreeBSD category of my blog in Gentoo/*BSD. The reason of this is that the progresses of Damian with Gentoo/NetBSD are showing that we can say that Gentoo/*BSD is doing something good a part from FreeBSD world.

In the last days thanks to Damian start-stop-daemon.c started working on NetBSD userland, and now enewuser works there, too (actually, now enewuser is a bit more complex than before: instead of looking for the exact $USERLAND used by the system, it looks for which shell is present, this way it's possible to have /sbin/nologin on a Linux system, for example (there was a package in bugzilla some time ago for that, maybe now it can be resurrected? who knows), to improve the support for nologin users.
Also, this works fine for Darwin/OSX, too, so from that point of view the code is much cleaner and works better.

Gentoo-ALT project is having big steps forward in the last months, and this is really good to see, especially considering that I have used most of my (maybe) free time working on this :) Now there's the meeting on #gentoo-alt scheduled for the 26th to see a bit the organization of the project and the coordination between the subprojects, and we'll see what will happen with that...

By the way, I want to thank Mark Kowarsky, Jakob Petsovits and Marius Morawski for the logos they sent for the Gentoo/FreeBSD logo contest. Your works are really appreciated, I think we'll wait a bit more (say, about until the meeting that we already scheduled), and then declare the winner :)

Who dropped by #gentoo, #gentoo-bsd or #gentoo-media in the last weeks knows that there was a ServoFlame bot laying there. That bot was using my flamebot script.

I already considered before to move to rBot but I discarded the idea mainly because I wanted to have something "mine". Now I think I already was able to show to myself that I'm able to create an irc bot in python, and wanted to move to something more usable, also because ServoFlame is going to be a little more useful (being able to parse project-maintained herds thanks to herdstat, it has something that jeeves misses right now) and he's now hanging around #gentoo-x86, too.

So what I did? I installed rbot, and started hacking at it a bit... what was the result? You'll find ServoFlame in the same places as before, with the cloak, a little different mask and answering to the usual herd, meta, glsa and "bug blah" commands.. plus a few more as it still have rbot default commands.

I'll end cleaning up bugzilla plugin and see to send that upstream, as it can be useful to someone else, maybe.

My developer site was, until now, using PHP on my local system to build the XHTML pages starting from some XML files. This was a bit of a problem as PHP is... a mess.

Edit: just to clarify, I think PHP is a mess for two reasons: a) php can be great to add simple dynamic contents to a page, but it's not so suited for CLI usage to create a series of static pages b) the XML parsing code *IS* messy if you don't use simplexml, and simplexml requires PHP5, and still it had a couple of problems with my content, and I had to quote its content into a <[CDATA[ section to get it right.

By the way, the time needed to recreate all the site with the same content is way less using xslt than continuing PHP-parse the XML datafiles to get the output xhtml files. :tidE

Being working lately with ProjectXML and GuideXML files in bsd project pages, I though of looking at the xslt pages to do a similar work.

The result is that I reworked a bit my XML datafiles to aggregate the data without using two-stage xml files, and then wrote a series of XSL files to translate them to XML with xsltproc...

No changes on the site, but now is way simpler and faster for me to add a new release of a project, or add a news, or whatever else :)

I'll probably release a copy of the sources soon, in the mean time if someone wants to look at them, just mail me and I'll send you :)

emerge unmerge php ...

Okay, I don't like writing documentation, and I don't like at all writing documentation user-oriented. But that's what we need right now.
As I need help, Gentoo/FreeBSD users that wants to help need to know what to do an how. There must be a way to tell what is required to be done, and there must be a guide on how to do common things.

I started working on the super sekrit devwiki, but that's just for developers' eyes so it wasn't working. I needed something that other people in the project could update easily, with a revision control, but was simple to look at for users... yesterday Donnie made me think of the project space.

Yesterday, Gentoo/*BSD project page was empty and obsolete. Now it's full and updated :)
The tasks are being tracked there, the developers are updated, and the gentoo-bsd mailing list is advertised clearly.

Still the tech documentation is not there, but thanks to Chris White, that's going to be fixed soon :)

Now what's missing there? Well probably I'll let herds.xml take the list of developers from the project page instead of re-listing all the devs there with the strange and funny keywording thing. But for that I'm waiting for a bit of clarifications from pauldv about the inheritmembers stuff that would really make simpler managing bsd herd.

Hmm I have already pointed out at my read-by-nobody article ?

Okay, today I really feel pissed off about the continue rantings about Gentoo/FreeBSD and I want to state again what I think about this.

Gentoo/FreeBSD is a great opportunity for both FreeBSD developers and users. During all this time, ports are the only way to build software for FreeBSD, and this means that many people just assume that ports "will take care", of patching, of fixing, of blacklisting. "If it's not in ports, it won't work." It's not true. Things can work if they are not in ports, just need to be fixed in case. Unieject is not in ports, but it works, for example.

Having to patch things "downstream" is a continue waste of time. Every time a new release of a patched software is done, the downstream maintainer has to check which patches applies, which are no more pertinent, and which needs to be redone by scratch. When patches are applied upstream, they can simply be dropped.

On Linux this practice is more followed because upstream releases for many different downstreams, and they all want to do the less work possible, and sometime they also like to share their fixes with everyone else who could need them. On FreeBSD, being ports the only way to install software (or this being what they want you to think), patches are not always sent upstream, making life difficult for users that does not want to use ports.

Gentoo/FreeBSD is the first try to get a different way to install software, not using ports, fixing things that needs to be fixed upstream. Is this reinventing the wheel? Yeah kind of. But improving it with more eyes. The more the merrier, the more the better. We can be of help as we can focus on things that ports does not focus on. We have no interest right now to support 4.x series or <5.4 versions, so we can focus on the part we take care of. When our base system is working fine and we'll have enough people working on it, we could also focus on packages that ports ignores.

Unfortunately, while some devs and users seems to like the idea of a parallel work, also if they don't want to switch and prefer their own system, some of them seems like suffering from NIH syndrome (Not Invented Here), trying to disturb us from our goals, and making our life harder. All I can say is a great "Thank You" to the devs that are willing to help and to accept our patches, The others.. we'll see what will happen, and then talk about it, eh?

So what's up with RPM then? Well I think that what make many people think that BSD is dead is because of the above mentioned problems. Having more than two teams working, focusing on different issues, is probably what made Linux so successful: there's Mandriva for newbies, there's Fedora for who wants, there's Debian for who likes stability, there's SuSE for enterprises, there's Gentoo for who knows what he wants :) All of them contributed something to the general Linux landscape, all of them continue working on specific issues.
What I'd like to see now, is an RPM-based FreeBSD distribution. It can be more tricky than Gentoo/FreeBSD as at least ports and portage share the source thing, but I don't think it would be too difficult to create a true FreeBSD (not a FreeBSD derived, of course) with RPM as software manager. If somebody is ever going to try to do this, I hereby promise that I'll help with patches and with debugging of programs that need fixes.

Ok well ending here.. somebody did read my article ?

Just a little note trying to get more people reading this old blog entry about the not-so-official Gentoo/FreeBSD logo context.

I have received nothing for now... nobody wants to help with this? :)

Another status update, with good and bad news.

The bad news are with Xorg, better with modular Xorg. Since Donnie started working on it on Gentoo, I've tried on getting it working on Gentoo/FreeBSD, too. Unfortunately there was quite a few bugs that stopped me from having it working. Now after some time I retried, also because the bugs were told to be Gentoo/FreeBSD specific, but then, I had a new issue. media-libs/mesa is now an hard dependency of xorg-server and it wasn't building. I was able to make it work with a couple of patches and a sed line (submitted to mesa's bugs tracker, the build fix is applied, the install-script fix is still not applied, but that's ok for now).
After that, I finally was able to confirm that the problems laid on the new autotooled buildsystem and updated the bugs according... but I was still told that the problem was just us.
Why? Because ports works... it doesn't matter that ports are not using the modular build, they works, what's the matter? Yeah sure.
Okay this was not referred to the entire Xorg team, so please nobody read that wrong.. I wish to thank Eric Anholt for the time, the merge of the mesa patch, and for working on it.
If somebody wants to know: modular Xorg with autotools does not work on FreeBSD, with the same problems I hit on Gentoo/FreeBSD, so the problem is not with portage, is with Xorg.

After this consideration, the good news: baselayout.

As Stephen is still being lazy ;) (or better he's still trying to get his box up), I've started annoying Martin and Roy with baselayout to get 1.12 working on Gentoo/FreeBSD.
The result of yesterday's tinkering is that I have a box which is using a partially-1.12 baselayout, with checkroot and checkfs ported to work on both Linux and FreeBSD, and with hostname and domainname working out of the box with the new layout (conf.d/hostname instead of /etc/hostname).
This means that also the new network setup is not so far away :)

reboot still doesn't work, so you're forced to use shutdown -r now if you want it to stop the services correctly, but at least it starts up fine.
Oh by the way this also probably (not sure, haven't tried) mean that we'll have the interactive bootup as Linux has already, as soon as we'll have an updated baselayout :)

Thanks Martin for the portability changes :) Blame to Stephen for the delay! :P

.. willing to help with Gentoo/FreeBSD and Gnome.

Ok trying to summarize what the problem is. Yesterday a new gamin was released. Gamin is GNOME's alternative to SGI's FAM, and it's currently the only FAM provider for Gentoo/FreeBSD (SGI's FAM can work, but requires quite a few patches that I don't want to mess with). Since version 0.1.0 is available, patched, on Gentoo's portage, so that it can be installed with a simple emerge gamin on a G/FBSD system.
A few patches needed to be updated, usually taking them from ports, but the main patch, the kqueue engine (kqueue is FreeBSD's equivalent of inotify, basically) was applied upstream a few versions ago. Now, more portability patches are applied on 0.1.6 version, so I had to relook at the patch as it wasn't applying cleanly... most of the patches were applied, but one of the check was done in a way that doesn't work as expected. I reported this, with a patch, in gnome bug #315615, and the maintainer applied the patch in a few hours, thanks Daniel.

Now what's the problem? The problem is that I have to wait for someone to fix the kqueue engine to the new internal API that changed in 0.1.6 version to install it on Gentoo/FreeBSD. We need someone that would follow gamin development and make sure that kqueue engine is updated and the code works on Gentoo/FreeBSD.
I don't have enough time to work on this, that's why I'm asking for help... if someone is interested, please send me an email to flameeyes_at_gentoo_dot_org, and join #gentoo-bsd on FreeNode.

Gamin is not the only program that requires this treatment, also general GNOME has this problem and it's not the only one. Pushing upstream the patches is the first important thing to make this work simpler, and is what it seems to be missing in FreeBSD's ports handling process.

Seems like Gentoo/FreeBSD 6.0 will take some more time...

I started working on beta3, and then moved on beta4 that was released today, I had a couple of problems with freebsd-lib but today I got it to complete... the problem is that the sonames changed and.. I broke the system.
I'll rescue it later, as I have the binpkg of everything, but it'll take a bit until I can figure a good way to have a quite transparent upgrade from 5.4 to 6.0 .

In the mean time this doesn't means that I have to stop working on Gentoo/FreeBSD :) thanks to Christoph I still have a Gentoo/FreeBSD box for the maintenance of 5.4 :)

Now, I have a couple of solutions in mind, but both are a bit hacky: the first one is to use an upgrade script that builds system profile static and then installs the new one, so that the different soname doesn't mess it around; the second one is to slot on $RV (Release Version, it's 5.3, 5.4, 6.0), and provide an upgrade script that disable collision protection, installs the 6.0 ebuilds, that will overwrite the 5.4 ones, recompile with revdep-rebuild the (quite entire) system, and then removes the 5.4 installed files.
I'll see what is simpler, a complete re-emerge of world is anyway needed, so... this will also help with elibtoolize changes.

On a secondary note, with Betelgeuse I prepared a workaround to have Java virtuals satisfied on Gentoo/FreeBSD: dev-java/kaffe-sdk is a dummy ebuild (for now just on Gentoo/FreeBSD overlay) that provides the two virtuals with 1.4 version, RDEPEND-ing on kaffe so that it will be used as system jdk and jre.
I've set, after that, the default virtuals to the dummy ebuild and un-masked java useflag. Please note that it's better if you try to use dev-java/kaffe ebuild from http://gentooexperimental.org/svn/java/ overlay.

In the last days, I entered the magic, wicked world of libtool patches collection.. this because I want to give to Gentoo/FreeBSD a simpler way to update their system without breaking binary compatibility with every single update of glib, gtk and so on.

Let's start from the start: one of the problems on Gentoo/FreeBSD respect Gentoo/Linux is that libtool usually creates library with a single version info. This makes so that also a single release can change SONAME and break binary compatibility. This is the case for example of libiconv.. 1.10 release would have broke compatibility with 1.9 if I wasn't going to do something, and that would have meant breaking gcc, as it links to libiconv.

My solution was hacking at libtool and tell it to use Linux-way to create libraries, using three version information values... so that libiconv-1.9 would install libiconv.so.2.2 and 1.10 libiconv.so.2.3, not breaking binary compatibility (SONAME remains libiconv.so.2).
This works not only with libiconv but with many other major libraries such as glib and gtk.

This is still experimental, as I don't really know why FreeBSD used the .so.X way to create libraries, but seems to work till now. We'll can only say trying that.
Now, the problem is that not every ebuild right now calls elibtoolize, and we'll probably need to add it to some packages if they change often the SONAME right now, but maybe Martin will implement soon the elibtoolize-in-econf so that we can make use of that without having to call it directly.
Oh another little drawback actually. I was able to create patches for the most common libtool versions, but it's possible that some package uses a strange version of libtool where the fbsd-conf patch doesn't apply clean. In such a case, elibtoolize is told to kill the process. Please report elibtoolize failures on Bugzilla (in product Gentoo/FreeBSD) so that I can fix them.

Little note: I'm happy to see that an x86 arch team is being formed, this really is good news to me as I can finally get rid of x86-specific problems in xine and let x86 team handle them... as I don't know how to fix them at all!

Following Marcus's entry, I also took this quiz.
I can't say I wasn't prepared to this :)

You scored as Buddhism. Your beliefs most closely resemble those of Buddhism. Do more research on Buddhism and possibly consider becoming Buddhist, if you are not already.

In Buddhism, there are Four Noble Truths: (1) Life is suffering. (2) All suffering is caused by ignorance of the nature of reality and the craving, attachment, and grasping that result from such ignorance. (3) Suffering can be ended by overcoming ignorance and attachment. (4) The path to the suppression of suffering is the Noble Eightfold Path, which consists of right views, right intention, right speech, right action, right livelihood, right effort, right-mindedness, and right contemplation. These eight are usually divided into three categories that base the Buddhist faith: morality, wisdom, and samadhi, or concentration. In Buddhism, there is no hierarchy, nor caste system; the Buddha taught that one's spiritual worth is not based on birth.

Which religion is the right one for you? (new version)created with QuizFarm.com

Should I say that I'm reading "Zen and the Art of the Sword" (or what is the translation of "Lo Zen e l'arte della spada" from Italian to English)?

Yai, today I spent most of the afternoon working on this, but then the new box, farragut, is up and running :) Thanks to egore who donated it, now I'm going to start working on Gentoo/FreeBSD 6.0 :)

Just for the sake of telling a story, today I was able to go looking for a NIC, as the last one I had at home was burnt out by a power spike :/ I found a D-Link that is recognized as a Realtek, good enough for me, connected my last UTP cable (now I miss the one I usually use for tech assistance, so I need to find a new one), and fired up the machine after connecting the monitor to it.
Start installation but ... WTF? UDMA errors? ... Look at the cable, it's a 40c... Ok I took the 80c cable of my current motherboard, as I don't have EIDE discs connected, just a DVD+-RW, and rebooted... uh? it doesn't start? Damn, I disconnected a ram bank while at it... ok fixed that and starting up..

I prepared the partitions and the labels, downloaded the stage, extracted, configured and so on, then compiled the kernel, installed boot0, but it didn't boot, so I know now that there's an exact sequence to respect, and I'll send Michael an email to update it.
I also found a couple of problems in domove.sh script, now is fixed. Actually, today Luigi Mantellini already told me of a couple of typos, but then I found a couple more. domove was directly not working at all :/ Please relaunch it everyone.

Anyway now I was able to boot and have it working fine in networking, I configured my authorized key and now I'm merging the base utilities (apcupsd to let it connect to the master ups daemon, screen, sudo). Next week I'll start the work on the 6.0 profile and ebuilds.

Stay tuned!