Diego Petten

Okay seems like new variants of Sober are really hitting the mail servers badly. The problem is that, while they don't really do anything to non-Windows users as a virus, they are a great bore for everyone. I receive daily ten or more Sober.* mails (and I just kill the Paris Hilton thing using maildrop), and some of them is able to get around SpamAssassin's detection.

Last time I had something like this was with Sober.P, and Dirk's rule did his job right that time.

Update: I was able to get it working, don't ask me what I did wrong before, the code for the rule follows


header __SOBER_P_MSGID Message-ID =~ /<[0-9a-f\.]{15,22}\@/
header __SOBER_P_CTYPE Content-Type =~ /text\/plain.*charset=\"us-ascii\"/
header __SOBER_P_PRIO X-Priority =~ /^3 /
header __SOBER_P_IMP Importance =~ /^Normal/

meta SOBER_OTH_VIRUS (__SOBER_P_MSGID && __SOBER_OTH_CTYPE && __SOBER_P_PRIO && __SOBER_P_IMP )
score SOBER_OTH_VIRUS 6.0
describe SOBER_OTH_VIRUS Some W32-Sober virus


Thanks slarti for helping me on #gentoo-dev :)
Finally, no more Sobers! :D

Okay, seems like sandbox-1.2.14 was released without applying FreeBSD fixes, so I've tried completing the port using gnulib. After a *lot* of work and a 50K patch, it does not work yet. The problem is that the replacement getcwd() provided by it... uses once again opendir(), that re-start the complete loop.

Now I'm going to try with a different strategy: I'll import the getcwd from FreeBSD's libc into sandbox (being BSD licensed it's not a problem) and then try to use it, after changing the opendir call to true_opendir.

Wish me luck!

I'm currently listening to Dream Theater's Live at Budokan DVD, that my sister gave me for the birthday... I have to say it was quite a bit of time since last time I heard something from Dream Theater, and... I love them :) This live is also good from the video side, by all means a perfect birthday present :)

Now, I'm actually starting to feel the need for a new amplifier, as mine is as old as me, and it's falling a part :(
I've already put an eye on a Kenwood's model, but it costs quite a bit and I'm still waiting for payment from my publisher for the translation of Sommerville's "Software Engineering". I also need to reorder completely my study room to put the speakers in the right place.
As I haven't passed the driving exam, I want at least to take this opportunity to hear a good DVD with a good sound :)

I never actually thought of how much is interesting to look at a Live DVD until I started watching at this... it's really impressive watching to such artists playing in front of so many people... if I could return back in time, I would probably try to go seeing them as they were in Italy this year, if I remember correctly.

Oh, and the DVD is not a Sony's, so no rootkit as far as I can see ;)

Okay today I was trying to do the less job possible for Gentoo as it was my birthday. I had anyway to employ some time in looking for mail logs as I tried to limit the quantity of spam received because of Sober.* virus.

I must say, I *love* syslog; I use metalog locally, as it allows me to avoid logrotate while not having 20MB logs, and everything that passes through it is correctly categorized. The problem is with the other logs that gets added to the /var/log directory without pass through anything.

So, pretty please, if you're going to write a daemon... please add syslog support to it at least as an option ;)

I wanted to blog about this yesterday, but I wasn't able to find time to do so. Well if somebody hasn't seen it yet, yesterday VideoLan project released VLC 0.8.4 final. So I started working on putting it in portage. Most of the work was already done as I was able to get all the betas but the last one (that was mainly a fix for Win32 users).

I prepared a couple of extra patches while going with it, tho, and updated the maintainer's guide according to that. The most important one is letting libdts to be linked as a plugin instead of builtin, so that it does not get linked to the final executable, at least not directly. Currently, vlc-0.8.4 is the target stable for vlc, as it seems to fix most of the bugs we could have found. 0.8.2 version will go away in the next days after I test it more deeply.
There's also a -r1 version, tho. This version adds hal support (backported from 0.8.4a version that might or might not be released for Linux/Unix), and make ffmpeg a plugin instead of builtin, finally relieving vlc from being linked to a lot of libraries. This still does not remove the builtins completely, as there's still libtheora and libogg that gets linked and I don't really like that.

What I'm going to try when I'll have time is to have also libvlc as a shared object; if I had time, I would probably start looking for adding support into Kaffeine for it, it would be an interesting thing to have at hand, but probably requires lot of tinkering for now :P

Ah the skins2 interface is now enabled with skins useflag, please test it.

I'm going to take direct maintainership of vlc later today just to make simpler to me looking for vlc bugs and to allow autorepoman to signal me of problems.

Today I'm also letting the last touches to the new revision of flac that cleans up the ebuild and adds the manpages, and obviously cleans up the patches we're applying. The list of changes can be found on CVS as now all the important patchsets I work on are hosted there.

On another note, I'm happy to see that my idea about the maintainers' guides does not seem to be dying completely :) Thanks Paul for supporting this :)

Okay, yesterday I had a sort-of-driving exam... sort of because the examiner let me wait for 40 minutes in the car, and it was *very* cold, so when she asked me to move, I was half-assed because of the cold and the upsetting of remaining there waiting. She then let me drive only for 3 minutes before rejecting me :|

Also, I took a cold waiting later in the cold rain because of a misunderstanding between me and my father who should have took me home after the exam, so I wasn't feel well at all, and yesterday I had to avoid the LinuxDay (was having fever). I'm sorry for the ones who came there looking for me, but if they still wanted to see my presence on Gentoo or even elsewhere, I wasn't having so much options ^^;

By the way, as Friday was _a lot_ upset because of the exam, so I had a bit of a fight with solar, probably because of misunderstanding there, too, and I'm sorry for that. I'm still a bit pissed off by Mark's comment, who said I just care about my arch, as I consider it an offence, given how much time I spent in the past months for Gentoo as a whole.
The problem is that if I don't get a bugreport, I can't possibly know what problems are in other arches. And after formation of x86 arch team I did not start reiterating over all the bugs to see if people asking for patches applied are now part of the x86 arch team.

Anyway, I'll be off-irc for a while, also because tomorrow is my birthday, but I'll try to cope at least with the basic bugs of vlc and xine when they come.
If people needs me, I'll be reachable by mail and Jabber.

After adding a few more patches for xine-lib, today I thought it was case of cleaning up other misc patches that I had lying around. I started with flac as it's a package patched *a lot* to get it working fine on Gentoo.
Unfortunately while I was trying the patches I just cleaned up, one failed to work fine with epatch, that seems to ignore it and skip that file, I hope Mike can fix it soon :)

In this cleanup mood, I was also able to find the solution to the last PPC problem with libdts! Basically until now we had two patches for libtool support on libdts, one was the default relying on libtool... the other was forcing -fPIC to get it working fine on PPC. Looking at a52dec (which is what libdts derive from) I found that we had to patch it to avoid a -prefer-non-pic flag to build non-PIC libraries... looked at libdts, found the same like, and once I got rid of that I was finally able to remove the second patch using only one :) YAI!

I like when I'm able to decrease the count of the patches in the tree, also if many times I need to add one more ebuild+digest to add improvements (like I'm going to do with flac) that actually *adds* files to the tree....
Oh well, tomorrow i'll try to get a few more packages cleaned up, or at least I'll try!

Okay, the original 1.1.1 release had only three patches in Gentoo's patchset. Unfortunately this was not doomed to continue.

The current patchset is a bit bigger, but the patches are actually quite simple, and are all sent on xine-devel (waiting for responses from upstream).

Unfortunately Stephen found out that xine-lib does not work fine with hardened systems, in partcular it has a lot of TEXTRELs... that is mainly due to ffmpeg code that can't be fixed easily, so we can do little or nothing about it. In the mean time, it can't work with FEATURES=stricter.

I also wrote all of this in xine maintainer's guide I'm trying to maintain.

The 26th of this months, a part the Gentoo Day / Linux Day at VELug, I'm taking the driving exam, one chance, if I don't pass it, I have to restart from theory, and that would suck. So I hope it will go fine, as I don't really have the will to restart again.

I'm going to try to document every thing I do, unfortunately, things like bsdtar or rtorrent are difficult to document as they don't really belong to a specific project.
I would really like help with that.

Okay, if someone is monitoring my CIA stats, lately I started committing more on project pages and gentoo/src repository. I'm trying to provide documentation for what I do, and how I do it, allowing someone else to take care of my tasks if I'm going away. The reason of this is that I really think that time spent on writing process documentation is not wasted, but employed in a productive way.

For this reason now the patchsets are available on the CVS like gcc's or binutil's, instead of my local SVN repo. I also changed quite all the occurrence of my homepage on the tree with mirror://gentoo/ and I'm waiting on a sort of half-automatic script that allows me to put the patchsets on my site only for the time requested to them to get into mirrors.

I'm also working on at least three maintainer's guides: ALSA, xine and VLC. These are the main packages I maintain on sound and video herds, so they are there with all the data I could find on them. There are other packages I maintain such as netatalk, bsdtar and libiconv but they don't belong there so I don't really know where to write them :| Maybe I can add bsdtar and libiconv in gentoo/alt or gentoo/bsd.
It's a bit unorganized this way, I know. But I don't think there would be space for a "maintainers' guides" project :) I really hope other devs would start writing similar documentation, tho, as it really helps when someone else have to take care of task of older devs.

I also thought about writing a quilt tutorial, but I'm not really that good, and it would require to go through the GDP probably, so it needs to be written by someone who knows English better than me :P

Okay, after a few problems with modular Xorg and FreeBSD, I wanted to start playing with it on a Linux system. I first installed it on the iBook, making it a bit experimental, while stable. I have to say it works quite fine there, also Xcomposite seems to be stable. The biggest problem I've seen was KControl missing the keyboard's layout using Modular Xorg (#51096), but I fixed that on KDE SVN and committed a patch to Portage to let it work fine on modular Xorg (the commit was tagported to rc2 so next KDE version is going to use that).

I wanted also to try it out on the desktop; unfortunately because of the keyboard I use here, I'm using an hacked up evdev driver, to allow keycodes > 255, and the code of evdev changed at the point my hack does not apply anymore. I hoped the problem was already fixed, but it was not. So I'm not going with Modular Xorg on this box for a while still.

Oh btw, please do not submit any more bugs for media-video or sound packages to fix Xorg modular's deps, as the idea of using virtual/x11 was wrong and did not consider the way portage is designed right now. I won't apply any change to deps until that is sorted out from portage or X11 devs. Donnie found another way to solve this, hopefully, but I'll wait before using it to make sure it *really* works this time.

Some time ago I talked about my problem with ruby and https.. to summarize, I was unable to get data out form bugzillas that used https with self-signed certificates because openssl library started bitching about that. Quite reasonable, eh? :)

Lately, I fixed that by spawning a wget process to get the pages, way more simpler than having to deal with ruby internals too much.
Now, in the last days I also added a few more bugzillas to the list ServoFlame accepts, and then I added a listzilla command to show the supported bugzillas :)


[00:22] <Flameeyes> listzilla
[00:22] <ServoFlame> kernel, kde, sourceware, abisource, gnome, fdo, openoffice, gcc, gentoo, novell, redhat


ServoFlame can be found on freenode on some #gentoo-* channels (for example #gentoo-dev) and accepts requests in the form Servoflame bug zilla #number. It does output something similar to GenBot's (mozbot) output.

I have yet to release the code for the bugzilla plugin.. I'll do that in the next days. I think I can try to get working an rbot snapshot from SVN as the current one seems to fail to recognize when it gets disconnected by the server, and I can't disable extra plugins such as karma and quotes (that I don't really need!).

I might also want to add support for dump/restore of the zillas list as when I change the on-file layout I usually break them... or maybe I can try to get a hold of yaml format used by rbot itself :)
This because I plan on trying supporting mantis, too.. but that requires HTML parsing, while bugzilla just require XML parsing that's way easier.

Oh well, I'll see.

Okay after a bit of time while I had no time or will to work on Gentoo/FreeBSD, today I restarted, after reviewing Wikipedia's articles, tonight I started looking at some details, before starting the trouble on GCC again.

I found out that pw as using the wrong place to get the skel files from: while Linux uses /etc/skel directory, and bash ebuilds installs there, FreeBSD still used /usr/share/skel, ignoring bash files.
It also used dot.name for files, instead of .name, so I thought I had to patch both pw and freebsd-share. Luckily, pw respects .named files, and it have a handy configuration file to select where the skeleton is looked up from.

I've committed the new freebsd-usbin already, I'm going to commit freebsd-share too, soon.

About the GCC issue that is blocking Gentoo to get into FreeBSD 6, the problem lies on us being unable to upgrade to decent binutils. If somebody knows about binutils internal and wants to help us splitting up the path patch from FreeBSD's patch, it would be *really* welcome. Just mail me, flameeyes@gentoo.org, or leave a message here, and I'll tell you the details.

Thanks everybody :)

Today I found out that one of the issue of using confcache is when an ebuild exports CC/CXX variables to allow crosscompilation and/or cross-distcc. Basically on a normal ebuild CC is simply unset, and the configure takes care of finding out the right compiler as ${CHOST}-gcc; when an ebuild is using an old version of autotools, for crosscompile sake it's usually needed to pass the right CC compiler to econf, by using toolchain-funcs functions, such as tc-getCC; an alternative is to use tc-export CC that just exports a CC variable.
When confcache passes from a normal ebuild to an "exporter" ebuild, the cache gets invalidated because CC differs (unset versus ${CHOST}-gcc), thus confcache is useless. The same goes when it passes from an exporter to a normal ebuild, as then it's ${CHOST}-gcc versus unset.

I discussed with Brian a way to avoid this, but he's filled with work and it will probably take a bit to fix this mess. In the mean time I'm testing a workaround...

This is unsupported experimental workaround, don't cry if this will break, it will probably happen; I won't guarantee it to work in any case, wine is probably the first package to break with it, but it *might* work and help you a bit while a better solution can be found

The trick is simple, just set inside make.conf:


CC="${CHOST}-gcc"
CXX="${CHOST}-g++"
LD="${CHOST}-ld"
AR="${CHOST}-ar"
RANLIB="${CHOST}-ranlib"
CPP="${CHOST}-gcc -E"


leave ${CHOST} as it is, as that would probably be expanded by portage and *might* work with wine then.
This method has the side effect to let also cross-distcc use the right compilers, without manual ebuild tweaking (thing that I've been doing for a while now).

While it's unsupported, I'd like to hear from someone who dares to test how does it go..

I already knew there was a wikipedia article about Gentoo/FreeBSD before, but I never paid too much attention to it. Today I was wandering through Wikipedia to research material about a thing I'm trying to write, and see GNU reference on that page... GNU? Something is wrong.
I start looking to the history, and an user that seems to be a Free Software paranoid^Wadvocate started considering Gentoo/FreeBSD a GNU-based operating system... can I say I hate people that suppose what they want about things? No Gentoo/FreeBSD is not a GNU variant, it's a FreeBSD distribution. What you're looking for is probably GNU/kFreeBSD, from Debian developers; there's also a Gentoo GNU/kFreeBSD stage0 by Debian's developer rmh, but there's current nobody working on GNU/kFreeBSD on Gentoo.

So what's the point of stating GNU-things about something you don't really have a clue about, eh?
Sorry, I can't really stand fanatics of any kind, I don't really have problems with GNU project or with FSF. But don't start labeling what I do with GNUs when there's no point in it.

Okay my iBook is taking form with KDE 3.5, and all the needed utilities for when I'm not at home. I don't really want it to be any kind of development box, it needs to be stable as I want it to be the work box.
It's also a quite sealed box, as I don't want it to be a server of any kind, so I'm using UberLord's firewall script to close everything but ipp (for CUPS broadcasting).

The main problem I've seen yesterday at VELug is that I wasn't having a way to SSH my home computer as I just use a public key access. The problem is that I don't like re-adding the same passphrase every time, and I don't feel like using permanent ssh-agent on a laptop.
The solution I've found now is to use kaskpass, a ruby script that uses korundum to use as replacement for x11askpass, using KDE's Wallet to store the passphrase.

Now I trust more KDE's Wallet than a perpetual ssh-agent, as I can stop it by just locking the session, and it's anyway protected by a shorter password (that I can type quicker than the passphrase), but I don't like having on the laptop the public key of Gentoo's CVS so I'll just open a new one.

Oh unfortunately my driving exam was moved from 29 to 26 November :| That sucks.

Okay, the Gentooification of my iBook is completing, yesterday I finished compiling KDE, I set up the FBSplash logo at startup (leave me a bit of eyecandy on that :P), configured KMail, and installed Konversation and Kile.

The sleep mode works like a charm, and distcc helps quite a bit. Unfortunately, I'll have to get the HD changed as it's still warranted, but I'll do that after LinuxDay, as I need the laptop there. Before going to assistance I'll backup the box with one big tar command on the main box, so that I can re-setup it just reconfiguring yaboot. The OSX part was just freshly installed, so I don't need anything more than copying again the Library on a newly installed version.

Now I'm having a problem to share data between enterprise and voyager-linux. To share between OSX and Linux I use netatalk, as it does not require super-user support or anything else, but this is not the case on Linux, as KDE does not have an afp kio_slave afaik.
A solution could be NFS, but I don't know if I can ask it to ask me an user/password couple when I try to access a given share, so that I can authenticate within Konqueror.
Fish is not a solution: I don't want to have ssh-agent running on the laptop for security and I just have key-authenticated access to my main box.

I'm thinking about setting up samba again and use CIFS for sharing, as it can be used as a KIO slave, but that would mean having a low low low speed :|
Does anybody have alternatives?

On a side note I'm testing Brian's confcache. To work on KDE it needed to change the eclass to do like any other ebuild and use econf, unfortunately this broke KLibido. I'm going to fix that, I must say that if it was breaking this way, it was probably broken by design and was working on a dirty hack :|
Don't use Brian's workaround to alias ./configure to a function! It will break every ebuild that has a ./configure script that's *not* an autoconf script.

Oh I also changed all the tests used on unieject's configure so that they do cache results. It was quite interesting thing to do anyway :)

I blogged quite a bit in the past about the real mess caused by the -fvisibility=hidden flag that KDE 3.4+ insisted to enable when finding *some* of the conditions needed to get it working.
After a lot of discussions with other devs, after looking at the logic, and after looking at the code, I decided that, while it's a big size save option, it's too unstable to get used at all, as both GCC is too untested and the change of a default parameter to linking is bad by itself.

The problem was originally blamed to Qt missing visibility support, then to pre-GCC4 patches by Gentoo and other distros, then by GCC 4.0.1 that was broken, then by another patch neede to 4.0.2 (and that added a lot of ICEs and crashes here and there), then by STL not supporting it yet...

Well today I was looking at KDE's admin dir to fix the kde eclass a bit, and found this out:

------------------------------------------------------------------------
r480611 | mueller | 2005-11-15 19:38:50 +0100 (mar, 15 nov 2005) | 3 lines

disable -fvisibility=hidden by default. Too many gcc bugs to
workaround on popular linux distributions (that break LSB compliance)

compare this with KDE bug #109386. I said on 2005-09-27 to add a configure switch for that, as it was not safe. I continued reporting the problems, but seems like Dirk stopped looking at them in the mean time.
Now, it breaks LSB compliance, so it *must* be disabled, eh, it's logical... when it breaks RedHat, is a true problem, when Gentoo devs tell that it's unsafe and should be disabled by default it's just shit, eh?

Oh well, I'm happy to be proved right about that, now I can remove the pissed off status caused by ALSA.

Okay after the ALSA incident, and my story with the iBook (that is a G4, for who was wondering :), thanks to JoseJX and lu_zero for helping me out on getting it working btw.

Well this morning I wake up (after just 5 hours of sleep, sob), end up the NFS setup of the laptop and start the real emerges... but... alsa-driver won't emerge, argh!
Okay, after a couple of checks and a lot of annoying questions to lu_zero, we work out the problem is with the way 2.6.14 moves headers around trying to merge PPC and PPC64 arches. Lovely!
I workaround the configure problem and then... the code does not compile. I bother johnm, and then start googling and I find the problem in a patch that was applied to alsa-driver related to a set of about 30 patches that changes deeply the behavior of input drivers. Sigh! After a while bothering lu_zero again, I consider reverting that patch in alsa-driver, and commit the workaround to configure, so now alsa-driver works on PPC. Well actually originally it worked only if you had set ALSA_CARDS="powermac" or whatever else, because with the default (all) it was going to check the PNP support that is obviously disabled. Thanks for #gentoo-ppc people reporting this, I conditioned that check and now it works fine with just emerge alsa-driver.
There's still a problem actually: the init.d script does not autodetect the snd-powermac driver as it's not a pci card, so it does not load it if you don't add the alias line inside /etc/modules.d/alsa. I have an idea on how to fix this, but I'll do that later, look forward for a revbump of alsa-utils (in ~arch this time).

This should close the alsa chapter for a while, I hope.

Then i have also two side notes. The first is about Brian's confcache: I'm currently trying that out with the iBook that's compiling xorg modular and KDE... for now I've seen it boost libtool a lot in xorg. I hope it does the same for KDE as the split ebuilds are an hell to compile :)

The other note regards xine: 1.1.1 version was released, and there's a 1.1.0-r7 version that fixes the problems found on -r6 (like ogg crashing xine, flac not being loaded, and similar). I'm going now to check which patches should I drop from the patchset as, as usual, xine-lib is released with more patches merged :) Thanks xine guys :)
Wait for it till tomorrow, tho!

Okay this is not the first time, but it doesn't happen so often. I'm officially pissed off. By what? Well it's long to explain.

Up to ALSA 1.0.9, the ALSA related packages were handled by Jeremy (eradicator); in the last months, tho, Jeremy seemed to have less time, so when ALSA 1.0.10rc1 was released, after a while I took care of adding the ebuilds to the tree under p.mask.
After that, rc2 was released, and was a bit of a mess because for the first tome one of the packages, alsa-jack, was not updated to rc2. That was fixed, too. I had also to patch alsa-utils in the mean time and a patch to alsa-driver for some Audigy card gone through, too. Other reports were from src_test failures for Hardened and general. I quite ignored them until rc3; it was p.masked stuff, it was RC, I wasn't going to follow every bug for them. As the bugs where reproduceable with rc3, I patched alsa-lib to fix it.

Then come out the kernel 2.6.14... bad thing, the kernels lately started doing massive changes also in API, and the old alsa-driver 1.0.9 didn't compile: the kernel is ship with ALSA rc1. This also requested to unmask alsa-lib as the drivers and the libs are better maintained in sync to avoid the old bugs with 1.0.8 and 1.0.9 (people told me that it shouldn't be _always_ an issue... but you know, we hadn't had an 1.0.10 yet, and I for sure didn't wanted to try!). ALSA 1.0.10_rc2 and rc3 gone wild on ~arch!
Note: I didn't delete rc2, not really sure why I did that, but that's the important thing.

Then, 2.6.14 needed to go stable, soon. When I saw dsd's commit telling the urgency, I openend a bug to arches to stabilize ALSA. I gone for rc2 as rc3 was newer and didn't have the time needed for stabling. The src_test problem stroke back, and I fixed that at last applying the same patch, I originally forgot of rerunning eautoreconf, and that caused another bug that I fixed quite immediatly (I forgot because the bug was not reproduced by who marked it stable). Problem solved? Well a part a few discussion with x86 arch team and the kernel guys, the incident seemed quite fixed now, for the future we'll all try to make things clearer and smoother to mark stable. I made the first mistake by not CCing kernel guys on the arch bug, and I'm sorry about that....

No it does not end so well. A new bug come up, alsa-driver rc2 does not build on 2.4 kernels. A bit of a problem, but rc3 seems to work fine, that's fine for me, normal problem, will be solved as soon as a non-rc alsa come up and we can mark that stable. Note that it wasn't for 2.6.14, I wouldn't have marked 1.0.10_rc* ~arch, let alone stable!
But no, that can't be just considered a side problem of 2.4 users that should try to get a hold by themselves, I have to do something, but what? Now tell me, what I could have done more than that?

I try to be as calm as I can be, I try to do the best I can do. Maybe it's not enough, but you can't ask me to consider 2.4 kernels while marking stable a driver that is needed for last stable tree to work fine, being on an architecture with no 2.4 support, not being the arch team which marked it stable, and being ignored by arch teams, too!

I'm officially pissed off, for tonight, I'm off.

Okay after about 2 years, it's time for me to install Gentoo Linux on my iBook :) The driver from Jo, Joseph, Michael and Danny is going to fix the airport problem (and I hope soon), so I have time to getting used to it.
So, as last time I just messed it up badly, also because I had problems setting up yaboot, this time I can always bother lu_zero until I get it working ;)

I reinstalled my OSX yesterday night with Grobian's help to get rid of extra things I installed in the past such as iMovie, AppleWorks and GarageBand, then I partitioned the system to have a 5GB share partition and two partitions with the two OSes.

I prepared a crosscompiler on my AMD64 box to have a distcc-able machine, crossdev rulez :) Now I have 4 different profiles here:

i686-gentoo-freebsd5.4 i686-gentoo-freebsd5.4-3.4.4/vanilla
i686-pc-linux-gnu x86_64-pc-linux-gnu-4.0.2/x86-vanilla
powerpc-unknown-linux-gnu powerpc-unknown-linux-gnu-4.0.2/vanilla
x86_64-pc-linux-gnu * x86_64-pc-linux-gnu-4.0.2/amd64-vanilla

After that, I got the livecd and the stage3 unpacked on the new partitions, and started merging glibc and gcc experimental :P While I want a more stable system on the iBook, I wanted GCC4, so I needed a decent glibc, and I trusted more the 2.3.6 than the snapshots of 2.3.5. Oh and I wanted eselect compiler :)

Now after unmerging nano (i don't want it :P) and selecting vim as new virtual/editor, I'm rebuilding world with gcc4. It will take time, but I hope it would be done after :)

I hope this is the time I can get it working. And if that's the case, I probably be able to use KDE for my presentations on LinuxDay.

Update: I'm currently running a dd if=/dev/hda of=/dev/null following hansmi's suggestion, as I had errors related to the hda drive and reiserfs, so to check if the errors were caused by reiserfs or by my hdd. If the hdd is faulty... that is going to hurt :|

2nd update: fixed the authors of driver, thanks Danny for be more precise than me ;) Oh and btw, seems like my HDD has a problem within the last GB, I'll isolate that for the 26 that I have LinuxDay and then see if it's the case to get it replaced, depending on the time it would take to have it replaced.

Okay, that I was crazy is something that people knew after looking at me.. or at the herds I'm currently in :P (sound, video, kde ...). But what I'm talking here is supreme crazyness :D

It was a bit that I was wanting to try GCC 4.1.. quite after the first snapshot I'd say. Unfortunately it always failed on AMD64, so I left it "a bit of time" to fix itself; the last week talking with Halcy0n, it seemed like GCC 4.1 was at least stable enough to try it without sacrificing the newborns, so I tried it again and, surprise! It still failed on AMD64; me and vapier told Halcy0n the same problem, so it was not only my system being screwed up.

After a bit, and fights between binutils and gcc guys about who was doing the wrong thing, a patch came up, but it's not yet committed. I wanted to try it anyway. I copied latest 4.1.0_beta20051112 ebuild on my overlay, and added the patch, GCC 4.1 compiled fine. Thanks to eradicator's eselect compiler i was able to select the compiler without having to re-source the profile, and that is way useful :)

I tried it first with unieject and then with xine-lib, just to give a look to the problems of the programs I maintain directly. But then, I had KDE 3.5.0_rc1 waiting for me :)
Unfortunately I suddenly stopped in front of arts, as one of the patches, that adds -fno-stack-protector-all flag, was making GCC 4.1 fail (because that flag is not supported), so I reworked the logic of the ebuild to check which flags are enabled, to allow building arts with compilers such as vanilla GCC that does not have the -fno-stack-protector-all flag.

Now, I'm building KDE and it seems to go through safe, without big troubles for now. KMobile seems to be a piece of broken software, and it's not even compiled by default kde, so I'm wondering if we should remove it entirely. The speed of GCC 4.1 is helping out, as kdelibs took an hour less than last time. I just hope the generated code has decent performance :P (possibly, better than GCC 4.0).

Oh I wish to thank Colin Lear for his help with the XSLT thingie and SeJo for letting me know I can both^Wask him if something else come up :P
For who was wondering, the solution I'm using now is:

<xsl:template name="block" match="block">
<xsl:param name="id" select="@id" />
<xsl:param name="title" select="@title" />
<xsl:param name="content" select="./" />
<xhtml:div class="darkerBox">
<xsl:attribute name="id"><xsl:value-of select="$id" /></xsl:attribute>
<xhtml:h1><xsl:value-of select="$title" /></xhtml:h1>
<xsl:apply-templates select="exslt:node-set($content)" />
<xhtml:br />
</xhtml:div>
</xsl:template>

using exslt function node-set() that creates the nodes starting from the string value. Now I can say I'm *really* separating the content from its visual style :)

Okay, today I felt down, maybe because it was the birthday of a friend of mine that I don't seem to be able to talk with anymore, so when my sister proposed me to go shopping, I took the chance to buy the USB cable for my V180. 10 euro it costed, for a simple standard cable... oh well :|

Now, I had already merged moto4lin and tried to use that version (0.3 release). Unfortunately a) it needs to run as root as there's nothing setting the permissions of both /dev/ttyACM0 and the usb device for libusb to something usable by user but ok no problem.
The 0.3 version, though, don't seem to work fine for me, it found a lot of unusual stuff in the phone and uploading a midi file it got in the wrong place creating a fake directory structure that i don't seem to be able to get rid of. The CVS version worked better, and after fiddling a bit with it I was able to set the ring tone to the Neon Genesis Evangelion opening theme I wanted. Tip: remove MyToneDB.db and TempToneDB.db files, then reset the phone.

After this little bit of a problem (I'll wait to mark ~amd64 moto4lin until I can ask r3pek if he can add a CVS snapshot for it), I've looked for a way to access the data on the phone. I first tried kandy but didn't work, kmobile wanted gnokii that does not support my phone, I tried installing gammu and was able to see it but still kmobile didn't work. KMobileTools worked way better, I can see my SMS, I can call and hangup, I can also see the battery level, yeee :)
The problem is that I don't seem to be able to sync korganizer or kontact with it, too bad :|

Oh well, later I'll see to fix a bit of a problem I found with moto4lin, then I'll see if I'm able to let it work "out of ebuild" with correct permissions ;)

As I said, I want to create a virtual/tar to allow people to choose between GNU tar and bsdtar.
The reason of this is that I like bsdtar more than GNU tar, and I feel like it better suits the base user profile, as for example it does not provide the rmt script or similar thingies that are not requested by normal users.

Also, this will allow the de-GNUification of Linux :P No really, this is another step toward the "don't be pissy about the GNU/* thing", as one can actually get rid of a GNU package.

Right now I was able to get the two respect the /bin/tar symlink, so I can effectively have /bin/tar not being overwritten every time.

The next step is to find a way to tell "externally" which other package provides a command, so that I can recreate /bin/tar if I remove one of the two using the other one. I have to find a way to handle this so that I can do that within an ebuild without using eselect, as I don't want to add it to RDEPEND for tar. But then, it must be parseable with eselect, too, as I want it to find out which commands can be selected and how.

Updates in the next days.

Okay, I wanted to blog about that yesterday, but I ended up the site restyle at 4am and also if I was able to sleep only at 6am, I wasn't going to blog with that insomnia. I wish to thank haran who doesn't know me ;) He wrote some of the most beautiful webdesigns for OSWD, and are his most of the ones I used for my site (and its one of his heavy elaborated the one used for Ziotto website -note: it's an Italian crazy and fun site of some friends of mine, and me, too :P-).

This time using XSL I was able to abstract most of the work so that I just had to change a base template file to do most of the job, but I still have some problems with XSL that I want to nail down, for who wants to help me, in the second page I'll show what I'm trying to do and does not work as I expected.. if you're an XSL expert, please help me :')

Pages: 1 2

Okay another update for sound :) After this week's GWN, where the sound team is in second place for amount of closed bugs (yuppie!), the bugs in bugzilla starts being a bit less pressing.

Unfortunately today a new version of alsa came up, and I had to update to rc3 the packages :P For some reasons, I seem to be handling alsa, also if Jeremy used to before. Well I hope he won't mind :)

While going to test new alsa... amaroK crashed on me, sob ;_; luckily, I seen kde-apps feed update of amaroK 1.3.6 (where did the packagers' notify go this time?) and before trying to compile with debug information, I tried that... now it's in portage replacing 1.3.5, as the problem seems solved. Hoping so at least :)

Oh on another note, seems like the @gentoo address receives so much spam that neither gmail's spam filtering is able to filter all of it :P

Well as vivo asked me yesterday, and I haven't said anything about this in quite a few time, I think it's time to say this :)

November 26th, in Mestre/Venice, at Villa Franchin there will be VElug's LinuxDay, and at the same time and place GECHI will have the Italian Gentoo Day.
I'll be there, as part of VElug, and I'll have a talk about Gentoo FreeBSD and a guided installation (hopefully... I'll have probably to bring defiant with me, so I have to dump the Solaris installation before). A part from that I'll have another two presentation, about Ruby and "how to help free software without being programmers" (this is one of my articles).

For who'll be there, I can't ensure, but I'll try to get also a few PGP keys signed (with precedence to devs, if someone come up ;) )

Oh I also updated my wishlist for who wants :P (no, I don't expect anyone will take me seriously, also if that _is_ my wishlist, as I already said it's there just to let people know me a little more).

I can't really say why I'm feeling this way. All the pressure I'm having lately to find a job, to take the driving license... is making me feel like I'm getting old.

I feel like I'm going to become older, and older, and older. I feel like I'm really having the weight of the responsibilities on my shoulders.

That's a strange kind of entry for me, but... oh well.

Yesterday I had a looong day and I wanted to relax during the night, watching CSI, The Closer (on TV) and Friends (on DVD).. at one point, I was going to look for an old anime I got on a UDF-formatted DVD, so I put it on and asked KDE to mount and open it.. "Unable to enter folder".

I started looking, and seems like UDF-formatted disks are loaded by pmount with 007 umask, root:root, so unreadable by anyone but root, by default. The only way to change this is to pass --umask option to command line, but that's not simple when the call is done by the desktop environment.

"Obviously", pmount does not have a configuration file, sob.

Yesterday I was too tired for starting hacking at it, today maybe, if I i find time, then I'll hack it around to add support for a simple configuration file via libConfuse. I hate when software's default does not feel right for me... but I like when I can change them by myself :D

Eh ok, some time ago I changed mail server, from courier-imap to dovecot, as the first had problems with Apple's Mail that's my client of choice on OSX. Today, I started hitting problems with dovecot.
KMail started to go crazy, and at first I thought it was KMail or kio_imap4 in trouble... but when I investigated deeper, I found out the problem was dovecot, getting Out of Memory errors on the process that controlled the IMAP session.
I started looking and found it was a problem with 64-bit machines on alpha3.. ok good, I'll try with alpha4 then. Bumped locally, but nothing, still same problem. I tried debugging it, but I was unable to get data with simple printf()s here and there. I tried gdb, but then, the program exits with correct status code, doesn't segfault or anything, so I can't just "wait", and when I told it to put a breakpoint on file:line... it segfaulted. Sob. I'm not sure if the problem with gdb is that the code I want the breakpoint to is in a library..

Anyway, now I'm running a backup dovecot on Farragut, the Gentoo/FreeBSD box, after sharing the maildir via NFS. Not a clean solution, but at least it works. I'll wait for alpha5 hoping that's better.
I'm just wondering why this came up only today, as it was working right before :|

Oh well... tomorrow I'll have again a drive lesson at 19:00 so will be another day that I won't be totally present, but at least I'm starting having a bit more confidence when I drive, so my driving license is nearer :)

After a lot of fights, of insults I received, of "it's a portage problem" answers, finally Xorg modular compiles clean on Gentoo/FreeBSD :)
I've just committed it to the overlay with a patch (already submitted upstream) to fix its compile on FreeBSD systems.
Yesterday I found out that mesa 6.4 did not require any kind of patching as the patch I submitted upstream was applied, and that really made me feel like finally we're getting a bit of attention :)

I wish to thank Donnie for his patience with me trying to get that working on portage, and Eric Anholt for his job on maintaining Xorg working on FreeBSD. I do not want to thank one specific Xorg dev, and everybody who knows me well enough knows who I'm referring to; no thanks for you trying to hinder the bugfixing, as you don't care if it's non-Linux.

Well now that we are sure that we won't lay around with a broken Xorg, GNOME fixing is probably one of the important things we should be up to... the problem of that is the need for devs. People if you want to help, please join #gentoo-bsd or the gentoo-bsd mailing list, and start looking at the doc to become devs. We need you! :)

P.S.: Michael, how's the G/ALT Handbook going? :P

Following Doug and Chris, I am looking for a job, too. I already whispered something, but I still have no news yet.

I'm sending out my curriculum to publishers that print Italian translations of computer, programming or Linux books, but they seems to be just a couple and that is not simple :|
My curriculum is quite empty, a part the free software tasks with Gentoo (but not limited to), as I just did two paid jobs in my life, and I just have my high school diploma...

In the mean time, I have yet to update my wishlist to remove the mobile (now that I already have changed it), unfortunately seems like latest changes in Froogle are not compatible with Konqueror...

Or maybe not so lovely. A bit of background to start: for Gentoo/ALT and in general for portability I have here three machines that uses non-Linux operating system, defiant (Solaris 10), farragut (Gentoo/FreeBSD 5.4) and phoenix (OpenBSD 3.something). To share easily ebuilds or code when I'm hacking at it with quilt (needing GNU userland), I make use of a simple /var/portage NFS export where I have the CVS checkouts of the trees, the distfiles and so on. The share is mounted automatically by defiant as it's used for portage handling.

Yesterday, I found out that after rebooting with updated nfs-utils I was unable to mount the NFS share from defiant. I had no time yesterday to look at that, as when it fails to mount it it also fails to start (yeah I know I should set a limit to the retries, but whatever), but today I wanted to. Seems like it stopped accepting the box as a known one, stating that it was "unknown" host.

I thought of a problem with NFSv4 so I stepped back to nonfsv4 flag and seen with that, but nothing... after looking a bit more deeply, I found that specifying the exact IP of the machine instead of 192.168.*.* I was using before, it worked. I tried then the alternative 192.168.0.0, nothing again. I resolved putting an explicit 192.168.0.0/16, that seems to work fine. This makes me wonder if the manpage is, then, outdated...

Anyway, the issue is resolved, and if someone had similar problems, maybe this can help him :)

Oh a couple of notes before leaving... thanks to everyone who stepped up for the KDE -arts thing, I was able to resolve with phreak`` anyway, so the problem is gone :)
And thanks also to everyone who helped me last night to find a curriculum class in LaTeX :) yes I'm looking for a job... I'm writing an article -in italian- on portability (more comprehensive than the ones I wrote on NewsForge/Linux.com before) trying to applying with a magazine... wish me luck! :P