Diego Petten

Ok sometime ago, while I started working on Gentoo/FreeBSD project, I heard some comments about it like "it will always be late respect ports because it's not FreeBSD's.
This is being proved wrong :)

I already told how I was trying to get xine-lib compile out of the box on Gentoo/FreeBSD.
Well right now we have a working (perfectly working) xine-lib-1.1.0 package on Gentoo/FreeBSD (while FreeBSD's ports has 1.0.1), and a working xine-ui-0.99.4 (which needs a big patch to work on FreeBSD as it uses some GNU-only functions, like strndup() and getline()), while ports has just 0.99.3 (they are welcome to use my patch if they want).

I don't see why we should be "always late", also because we usually work with upstream to get thing fixed, so we don't need to have patches for years around.
OpenCDK is another example of software we have more update of ports (0.5.7 vs 0.5.5), which doesn't need the patch there's on ports nor the sed-fu in the Makefile to replace malloc.h with stdlib.h. Why that? Because I sent the malloc replacement upstream, and they just fixed that on the sources.

So, for whoever in FreeBSD project think that we're just bothering their stuff, please take a look of what we're really doing: we're making easier your work, too!

Ok this is time to mix two of my main problems: xine and Gentoo/FreeBSD. As I already said, a couple of days ago xine project released two new xine-lib (1.0.2 and 1.1.0) and a new xine-ui package. Following this release, I started posting to xine-devel mailing list all the patches we have here in Gentoo (well not all, just the one already cleaned up, I need one of the sparc folks to do a clean-fu on one of them). As per Gentoo/FreeBSD, we also have a few patchs took from FreeBSD's ports, so I sent also them. A part from the fact that a couple of them seems to be pointless (and I just added them because they were on FreeBSD), the rest was applied on xine-lib tree. The question now is: why the ports maintainer hasn't submitted those patches before? I think that a patch applied upstream is always better than one that you need to apply by hand every time.
I was able to drop a lot of patches with 1.1.0 version, and I hope to drop some more for the next release.

Now I'm also going to see what to do with xine-ui, 0.99.3 version required quite a few of fixes to build correctly on FreeBSD, I'm not sure about this 0.99.4, but maybe with upstream I'll be able to have a 0.99.5 working quite out of the box.

The alternatives for xine-ui are kaffeine (which seems to work), totem (don't know) and gxine. THe latter fails to instasll as it requires dev-lang/spidermonkey (a javascript implementation from Mozilla) that doesn't get along well with FreeBSD and it's discontinued since 2000 or so.
I'm wondering now why someone should write a multimedia player frontend relying on a mostly-unknown javascript package, discontinued, which don't even got to final release (current version is "1.5rc6a").

Well gxine won't be available on Gentoo/FreeBSD for a bit of time at this point.

On the other hand, I had a report from an user about broken dev-util/indent build, as it's a dependency of ORBit2, but... after having fixed indent and found out that there's a BSD version of it, I started looking at ORBit2 to see if I was able to change it to use a g-prefixed indent and... I haven't found any indent reference!
I really really really hate when this happens :/

I promised an entry about Gentoo/FreeBSD but I forgot to write it, so it's time to do so :)

Ok I started working on FreeBSD's linux compatibility; unfortunately it seems to be a quite problematic task for a couple of reasons: first of all I can't reuse the emul-linux-x86-* packages from amd64 as they are compiled with optimisations, while FreeBSD linux emulation doesn't work when you build binaries with something more than -pipe (-march=i386 breaks them, too). I prepared a local chroot to start working on this, and I've been able to run a simple hello world example compiled under Linux, but java refuses to work, and most of recent java programs uses SWT that doesn't work as it should (remember that SWT uses native libraries, but java's native != FreeBSd, so you get a lot of messed up dependencies). openoffice-bin doesn't work, too, but I still don't know why.

A part from that, today I found out that we have a pmake in portage, which is the NetBSD version of make, the "parent" of FreeBSD's make. I'm then planning to just remove make from freebsd-ubin package and then just add pmake to profile.
This will make simpler to manage the make commands as we can just use pmake when we need to execute with bsdmake, removing all the references to 'bsdmake' alias in overlay.

The transition to pmake should be quite simple: if you're using cvs overlay you'll be asked to update freebsd-ubin and install pmake, that is enough :)
On a BSD system pmake symlinks to bsdmake, on a GNU system it installs mk files used by BSD-style makefiles. This is good as it allows to have a 'pmake' command working fine on Linux, FreeBSD and darwin (where the default is bsdmake actually, need to hope that OSX herd can get this working).

BTW, pmake is compiled from Debian's sources with their patches, this makes it the second package doing that maintained by bsd herd. I really want to thanks Ciaran for versionator eclass, as it's really simpler to handle debian patches as third version value when packaging them :)

I wrote yesterday that I was going to get a little break. Unfortunately, I couldn't take it as I wanted, for two main reasons: the first is that if I'm not doing something I'm just stuck at thinking of all the errors I did in the past and the ones I'm going to do in the future about my real life; the second is Gentoo-related and is the release of new xine stuff.

Yesterday night both new xine-lib and new xine-ui were released, with actually two versions of xine-lib at the same time (1.0.2 and 1.1.0). All the three of them are now in portage; 1.1.0 of xine-lib was a bit of a problem as a couple of patch needed to go away (for example the no-ARCH_ patch that took me quite a bit of time, or the warns fixes, that too a lot time consuming); that also means that i have less patches applied to xine-lib and xine-ui, so I resent all the remaining patches upstream to get fixed, unfortunately this will take a bit more of time as the author is going on holiday (good for him :)), but I hope next version will have a more light patchset tarball.

Anyway xine-lib wasn't my only commit since yesterday; I also had to update libtorrent to 0.7.0-r1 with a patch provided by upstream to fix a little bug (I've not gone to take 0.7.0-1 version, as that would have mean using versionator eclass to get the filename (0.7.0.1 -> 0.7.0-1) and required users to re-download the patch; as the patch itself was a oneliner, I just revbumped the ebuild and added the patch to portage; the old ebuild gone, too.

Also Gentoo/FreeBSD required me a bit of love, as two new security advisories came up, one for zlib (no use for us :P) and one for ipsec in FreeBSD kernel (fixed on freebsd-sources-5.4-r4), so I committed that, too. I'll write later about Gentoo/FreeBSD specifically, too.

A part from the bad news, yesterday NewsForge published an article I wrote about portable patches, and I'd like to thank spb for the proofreading of the draft :)

I blogged quite a bit in the last days, but then i suddenly stopped yesterday. I'm not going to dismiss unieject project, nor I'm going to leave gentoo, but I need a little bit of a break.
Yesterday I had an argument with my best friend, I quite messed up our friendship and I was afraid of losing her, I think that the worst thing I could ever think of at the moment. The mood in which I am now is still not good, but at least I was able to tell her what I really feel and now the argument is closed, but I'm still a bit upset about this.

Cause of that, I think it's better for me not to commit to the tree for a while, just for the time needed to return to my normal "mental status". As I don't want to waste the time I'll take off from the tree, I'll spend it to look at unieject's support for pumount (and in general configurable unmount wrappers) and if I'll be able to, to start looking at OSX/Darwin IOKit to improve libcdio and use it to work with unieject.

On another note, I'm still waiting for the payment of the translation I submitted at the start of the month. Having to wait quite a month to have the payment due for april is kind sucky, but that it is.

To close this up.. I hate the summer, it drives me crazy for the hot, and that makes me say some things I should have never said.. I almost lost my best friend because I'm a stupid geek behaving like a geek :/

Yesterday npmccallum on #gentoo-dev made me note that eject can unmount partitions just by root for a permission problem (well not exactly a permission problem, I knew of that and I thought it's right basically), and that it should use pmount, a suid mount wrapper, to do the actual unmount...

Ok now I'd really like to have unieject working on most systems as possible, so I don't want to constrain it in any way. I think it's really really important that it's designed, wrote and used in the more flexible way as possible. So I'm thinking of getting this stuff working, maybe via a configuration file to use as "run this command to unmount".

Surely, that's possible but... I'm still thinking about this: I don't like system() calls because you rely on someone else to do the job, in this case I should do a system() call to execute a suid executable. I'm not sure if this is the right way to go at all.
At this point one can just suid unieject, and it will work out of the box, being it suidded it can unmount the partitions without permission problems also by root.. and actually it just needs a "capability bit" to be able to do that, as the umount() call in glibc just requires CAP_SYS_ADMIN capability.

Every comment is welcome.. should I just make unieject use a system call to call a suid executable, or just create a wrapper with the capability?

Oh and BTW I started preparing for gettext the project, so starting from version 3, translations will be possible.

Ok following the release 1 from yesterday, I released a version 2 of unieject, working fine on FreeBSD and Linux, with a complete manpage and a cleaner API. It also has cdspeed support and a non-working cdslot option.

This version is now in portage (just ~amd64... i still think that an x86 arch team is needed, but that is), with its dependency txt2man.

To work on FreeBSD it needs a patch in libcdio code, so I just added it as 0.75-r1, that patch is not needed on Linux. I've submitted it to libcdio-devel mailing list and to FreeBSD's ports maintainer if he wants to update the ports version of libcdio.

But there's a question unanswered for now: "Why someone should think to use unieject under Linux instead of eject?"

Good question, and I don't really have a clear and safe answer for it.. i can just say a couple of things about this. The first one is that eject is not exactly "maintained" (and imho is also a bit overwhelmed, I'm still wondering why it should set cdrom speed and so on), the second one is that it uses system() to call umount when it tries to unmount a device.. I don't really like that, unieject uses library functions to do the unmount job so it's, imho, safer.

Another reason is simply that it's simple to have one single portable version of eject than many different ones, but that's just a gentoo specific requirement (no other distribution is cross-os).

Well now I really need to start adding gettext support to unieject and force kito to help me with unieject on OSX :)

Unieject seems to be one of my most complete projects since a long time: yesterday after I completed FreeBSD support I started the release cycle with unieject-1, and also opened a Freshmeat project page.
I haven't used a trunk/ tags/ layout on my svn server, but for those version is not a problem: until it can't be stable there's no reason on using major/minor versions.

I also wrote the unieject.1 manpage (my first manpage!) thanks to txt2man it's just a matter of writing a structured text file.
Unfortunately this adds a new build-dependency, but that is not a problem for gentoo at least :) (txt2man is a sh-script with gawk, so it's just a matter of copying itself in /usr/bin); I added app-text/txt2man to portage yesterday.

The new upcoming version is going to have a few more options from Linux eject, if they are supported, such as setting the max speed of a drive. Unfortunately it seems like eject doesn't care at all about the fact that the drive supports the speed settings, and just says to have set it. Instead unieject looks at the drive's capabilities as reported by libcdio to see if it can set or not the speed.

I should probably also start documenting the public interface of the library via manpages as well, fortunately txt2man is simple enough to work for me.

I also started working on the osx port of it, fortunately seems like the code to get mounts and unmount them is the same as FreeBSD, but seems like libcdio needs a few tweaks to work on Tiger (and it doesn't report the CD-Rom unit, also when the driver is loaded), maybe it's supposed just to work on Darwin, I'll ask kito :P

Unfortunately most of the extra functions of eject I can't really test, so I need to put them and hope (cd changers and so on).
Also the scsi, floppy and tape ejection mode needs to be rewrote completely as libcdio can't (obviously) manage them.

Well, version 2 will probably be released today, and that will go in portage, as a virtual/eject provider, also if it needs a few workarounds for FreeBSD as it's now (I can eject a CD-Rom working in CAM mode, I can't do that for CD-Roms in native mode for now).

Another thing I need to take care is the localization, I never used gettext before so I need documentation about it.

I hope to have a valid eject alternative soon :)

Ok I'm working on unieject to improve it and find a good way to handle FreeBSD's CD-Roms. Seems like the access to CD-Rom via ATAPI isn't possible at all, and GENERIC kernel doesn't enable atapicam (SCSI emulation), so I'm thinking of just adding a new GENTOO kernel configuration file with atapicam enabled.

At this point I have a working eject replacement for Linux (just CD-Roms for now, not scsi, tape and so on, also because I don't have them at all), able to unmounting the devices if needed; and an ejecter for FreeBSD, able to eject CAM-enabled devices.

As the code to get the mountpoints and to unmount devices is way different between operating systems, I've autotooled unieject giving it a configure script.
Also, I started splitting it in unieject and libunieject as Sebastien suggested. It will tightly tied to libcdio, tho, as it's not completely opaque to it. This probably is useful also, because many of the uses of libunieject could be on software which already manages CD-Rom drives.
I've moved from getopt_long to popt, too, as it's way easier to manage that as the cli tool must be as simple as possible.

I'll prepare a snapshot version of this bug I won't do a "full" release until the FreeBSD version is able to unmount devices, too.

I'm also thinking about the versioning scheme... probably I'll just release 1, 2, 3, and so on version, and get into minor version just when the changes are trivial.

BTW I'm using subversion locally to develop unieject, but maybe sooner or later I'll be able to put that online directly.

From harshy's blog, I took this test and...

The funny thing is that Elrond was the name of my character on Ultima OnLine for a long time :)

As I wrote yesterday, I've started working on an universal eject command for Linux, FreeBSD and OSX, using libcdio to issue MMC commands to the cd readers.

The first try, with just linux support, is here, and works fine to eject and load drives under Linux. Obviously it's not complete, it's just the work of 40 minutes of coding with getopt manpage open (because I never used it before).

To compile use this commandline: gcc --std=c99 unieject-DATE.c -o unieject -lcdio .

Unfortunately it doesn't work on FreeBSD... why that? because libcdio doesn't seems to work too well, either. The default access method requires SCSI emulation support, the ioctl support which would work on ATAPI cdroms doesn't work either as it doesn't fill the capabilities of the drive.

What I can do now is just improve libcdio so that it will work with ATAPI drives on FreeBSD, if I really want to have an universal eject.

P.S.: about the mail I talked about yesterday... the letter was received in time (after 6 days from the sending) but the return receipt hanged for 9 days at my local post office... and I still haven't seen the money for the job :/

Some time ago I talked on gentoo-dev mailing list about the need for a virtual/eject to satisfy dependencies of packages which needs the 'eject' command, as every OS has its own version of this command.

For Gentoo/FreeBSD we have an eject-bsd package which works fine for most of the usage of eject command.
Unfortunately this is not 100% syntax compatible with the one we use on Linux, so programs depending on that syntax doesn't work well on Gentoo/FreeBSD.

I'm thinking right now of an alternative. We already have libcdio library to access CD/DVD drives functions, and that's portable between Linux and non-Linux systems.. maybe we can do something with that, creating an universal eject command working fine both on Linux and FreeBSD and OSX.

I'll try to investigate this further, but in the mean time I'm also working to complete my translation job. By the way, Italian postal service sucks, and sucks great.. they lost the mail (was an assured delivery) in which I sent my personal data for the payment. DAMN!

In the last days I got a bit of a "break". As Gentoo/FreeBSD is advancing well with the experimental stages released, I wanted to stop a bit from it and from general bug squashing, I spent (almost) two days playing and relaxing with my iBook on the bed. It was since February that I wasn't having a break, so that relaxed me a lot.

Unfortunately there are things from which you can't take a break, real life and temperature are the main problems. I hate summer and hotness.. and my real life is a mess on itself, not counting the fact that I'm still missing the money for the job. Adding the fact that I'm being a total dork with my best friend doesn't really help.

Fortunately, UserFriendly exists, and this at least helps me relaxing without needing a complete break :P

By the way, I ever said I can't stand the damn advertising of mobile phones' ringing tones? Hope out there the situation is not so bad as here..

Please note that this is "not-so-official" as I'm posting here before telling of this to anyone.. just one of my crazy ideas.

Gentoo isn't exactly one of the most "styled" distributions out there, as you usually are able to use whatever theme/artwork you want.
I'd like, however, to have a Gentoo/FreeBSD artwork to use for snapshots and to put on livecds (when they'll be done).

So why this post? Well I just suck as an art designer, so I'm asking all of them out there to try to do your best for a Gentoo/FreeBSD logo ;)
You can probably use the BSD daemon, but in such a case you should probably read the usage guidelines.

If you feel like trying to get something out for this, please consider what's going to be used:

• A fullscreen logo, 800x600 or 640x480, as splashscreen for LiveCDs (I don't think we can have the border like on Linux with FreeBSD, but maybe)
• A KDE splashscreen.. I use KDE as main window manager, and it's the first WM to compile and work fine out of the box on Gentoo/FreeBSD, it deserves a splashscreen

Artists, enjoy this :)

What is that? Well as the stage is now public, we're getting new bugs on bugzilla, and that's good,
Unfortunately not all packages can be made easily working, and for those I need upstream's help.
xine-ui is the first problem. I'll talk with upstream about this soon.

From the other side of the coin, FreeBSD 6.0-BETA1 is out, still I wasn't able to find a ChangeLog for this as I'd like to read it to know what we need to change for 5.4.

Stephen is now working on a new stage with fixed missing packages and other misc fixes. I'm going to update the freebsd-sources ebuild to have a symlink flag as we have on Linux kernel sources.

app-text/ghostscript was replaced with app-text/ghostscript-gnu which works fine out of the box, so it's now the default virtual/ghostscript provider with the other p.masked.
Unfortunately seems like kde broke and I'm now rebuilding xorg-x11 to see what happened. Also gamin seems not to work as it should.

Hope this get fixed soon.

Some days ago solar asked about security on Gentoo/FreeBSD project. I liked the fact that he asked, because that means that Gentoo/FreeBSD project is no more considered just a toy :)

About that I think it's worth telling what's going on about this. We should start saying that the only release of FreeBSD we're looking forward now is FreeBSD 5.4, so G/FBSD 5.4, too. This means that who installed with the old instructions using 5.3 is not covered by any kind of support since now on. We already released an experimental stage (no it's not going to work out of the box, join #gentoo-bsd on FreeNode to know how to use it), and that's going to be the first full release of Gentoo/FreeBSD when it will be ok.

About security, I'm monitoring all the FreeBSD's security advisories since 5.4-RELEASE, quite all the advisories were against libraries built in freebsd-* packages for pure FreeBSD systems but built from portage on G/FBSD, so it's normal security team who takes care of them, For the rest of the SA, there was a few related to FreeBSD's kernel, and they are applied in sys-kernel/freebsd-sources-5.4-r2 (and -r1 for the first load of them).

So what's going on? Well for now as the project doesn't have a public stable release we can manage security in normal ways, when the project will be stable and merged in portage, maybe we could enroll someone to have contact with FreeBSD's security team, or we'll just continue following SA's releasing new versions of our packages.

By the way.. GLSA needs a new name after our release :) GSA doesn't seem to have the same "appeal" so maybe we can call it Gentoo Land Security Advisories ? :D

One of the things that lately became more and more important for Gentoo, IMHO, is the lack of an x86 team. As the time goes by, amd64 desktops are getting more and more used, and this is good, IMHO, because a lot of software bad coded is not working there, removing a lot of cruft from the packages base users are going to have (am I referring to Helix Player? well not exactly but that's one of them).

Unfortunately one of the things that this is making clear is that we need an x86 team as many devs (like me) are getting access only to amd64 hardware so can't test and mark for x86 systems.
Also if this can seem a problem not exactly extended, at the time of writing I have marked stable a couple of packages (xine-lib and libtorrent/rtorrent) which aren't stable on x86.. instead of an amd64-imlate.txt file (which shows which packages are stable on x86 but not on amd64) this time we need an x86-imlate.txt.

It can seem a little problem but consider that, just myself, I'm maintaining 13 packages, and I'm on media-video, sound and pam herds (and also az who's the other main pam developer uses amd64 as main arch). This means that 13 + eventual packages that I mark stable on media-video, sound and pam are going to be marked amd64 before x86.
Add to that the other devs in my same situation and we're going to have more than a few packages maintained on just amd64.

I hope nobody at VideoLan project will get mad at me. VLC is a great software and I'm using it without problem on OSX, what I'm going to tell here is just a way to express the frustration of a package maintainer when upstream (for some reason) is not hearing him.

Ok let's start from the start (as usual). At the firsts of June I added to portage a 0.8.2_beta2 version of VLC, using the test2 tarball VideoLan project release. Unfortunately that wasn't working on AMD64: from version 0.8.1 they enabled by default the x86 extensions like MMX, MMX2, SSE and SSE2 on AMD64 systems, this is a good thing but they done it in the wrong way. The CPU detection code wasn't working at all, so I fixed it with some help from other Gentoo/AMD64 devs, and sent them a patch in Videolan bug #2078. That patch wasn't applied on 0.8.2, and we need to apply it again on 0.8.2 final version on Gentoo.

Now I'm having a bit of a problem with mozilla plugin: the link fails because it must create a shared (.so) library, but there's a non-PIC enabled library in the link input. It took me quite a bit of checks with Danny to find out the why of that as the commandline used to compile the source code had -fPIC in it.. the problem is that the MMX asm code used there is not PIC-enabled and that means that the code is not going to work at all until it's fixed for PIC support.
I've searched for a dev in #videolan on FreeNode but seems nobody's there, then I reported a new bug for them and now I'm looking for a workaround.

If you'll see mozilla useflag in media-video/vlc would mean I've fixed it :)

One of the things I actually enjoy quite a bit is following the "enemy" moves.. so I'm used to read Microsoft/Sun/Novell blogs from time to time.
Sometimes you also get something interesting as this entry by Scott Densmore which has nothing to do with computers :)
Simple rule: Italicize the ones you've seen and Bold the ones you actually liked.

1. Titanic (1997) - $600,779,824
2. Star Wars (1977) - $460,935,665
3. E.T. the Extra-Terrestrial (1982) - $434,949,459
4. Star Wars: Episode I - The Phantom Menace (1999) - $431,065,444
5. Spider-Man (2002) - $403,706,375

=> Read more!

As I'm mainly focusing on 5.4 profile and release of Gentoo/FreeBSD (which is way more Gentoo than the 5.3), and I want to have Stephen and the rest of the BSD herd focusing on that, too, I've removed from CVS all the 5.3 ebuilds and the 5.3 profile.
This makes gentoo-project/bsd/fbsd tree way lighter than before, after having removed from rcscripts all the configuration files which aren't needed anymore in 5.4 profile (to have a new freebsd-baselayout release soon).

On a side note, after cleaning up the overlay and all that stuff, I also fixed smbfs patch (damn $Id:$ in patch) so that it builds now. Interesting thing: perl that made me have an headache becuase it was still failing building, come up to need one of the system packages build without +build useflag (used to prepare the stage) or it fails with absurd errors.
Stephen is looking for the broken package right now.

This makes g/fbsd release always more near. So what's missing now? A part from a working stage, we need a bootstrap script, and then having a way to automatically symlink sys-5.4-rX to /usr/src/sys (that's something I'll take care of soon). Then we really really really need a livecd.. I'm thinking on starting tinkering with FreeSBIE tonight.

Well time to go tinkering! :)

Introductory note: this post can be a bit of a "flamebait". Please note that's just an idea that hasn't been discussed with anyone, just something that transited between my ears, inside the empty box of my head, while I was doing eastern cleanings today (a bit late, I know :P).

I was discussing with a couple of friends some time ago about the fact that Gentoo's tree breaks quite a few of times and that there are a lot of unmaintained packages (that's something which come up lately with the new maintainer-*, too), which ends up "rotting" as they aren't updated regularly.

Today I was reading gentoo-dev, and there's a discussion about the QA process in Gentoo. I think Ciaran's comment summarize what I think:

Gentoo's 'moving target' development model is not the development model
used by your typical 'stable release once or twice per year' large
software development project.

We aren't a stable project as the ones developed by big companies, we are a community-driven project, at the end, and while this doesn't means we must lack any kind of QA (that would drive all of us mad), nobody can't even require us to do something if we don't really feel like doing that.

What I'm going to say is something which is true for me, but I think it can be also for other devs.
Most of the packages I maintain, such as netatalk, xdtv, vlc, xine or bsdtar, are packages that I use regularly, most of them daily. I'll take care of them as it's something I should do anyway also if I wasn't their maintainer as I'm using them and I prefer having them the clean as possible.
I used to maintain my own overlay with my own set of ebuilds for the packages I used. That's how I became a developer, too.
I'm not going to add ebuilds and maintain packages for something I'm not going to use, because I don't like, I don't need, or I don't have the hardware to use them.

That's true, but I used to have also ebuilds for software I wasn't using in my overlay. Some of them were just interesting and I had so much time that I started adding them just for the sake of it. Others were just requested by some friends of mine, who asked me to write an ebuild for a beer for example (well I'm abstemious so they haven't offered me anything anyway, but if I wasn't :P)..

Sometimes you can just ask politely to someone you have confidence with for an ebuild, in case just offering him "a beer" or an equivalent trade. I'm not saying that this is something that should be made official; actually I think that should not be made official. Nobody should ever have the power of saying to a dev "you *must* do that", a part from another senior dev, obviously. Just let that be like a "tip" for the devs, a way to say "Thanks man for your work".

Obviously this is something that shouldn't be exploited by devs, there shouldn't be hurry to add something, or to band-aid something, just because an user is paying for this. The QA should be maintained, it should just be a reward for the work that is already done.

From my POV... I'd be happy to receive a tip for my work, but that's not important. I don't really do something I should be tipped for and anyway I much prefer having users help with their work than with money. Submit a good patch or a good ebuild that works fine and I'll be as thankful as if you gave me 10 euros.

By the way.. if you want to write good ebuilds, you should take a look to the Unofficial Guide started by Ciaran, thanks Tim to continue hosting it :)

After the Gentoo Updates a bit of personal updates, as I really need to write again about this, as maybe other people will take that into account in the future.

One of the problems I had to join Gentoo was that, when Jan, Otavio and Aaron asked me to join, I hadn't had a Gentoo/Linux system. Not that I never had one, but my system broke just a week before, and took three weeks having the new amd64 box here.

What happened to my box? Eh, a bad thing. At the start of February the OpenBSD box I used as DNS, mail server and IRC Bouncer died, because of a power spike; at the end of the same month, after rebooting the Gentoo box I got a unreadable HDD, from which I was able to retrieve just a fraction of all the data stored.

That disk had a bit of a story behind it: I ordered a Maxtor 160GB EIDE, but they sent me a Maxtor 160GB SATA (costing a bit more).. but I hadn't had a SATA controller on that machine. Fortunately my sister bought me a Promise TX4 SATA controller, which worked fine until the disk died.

That said, I started looking for information about *how* that disk died, as the power spike wasn't responsible for it this time. I then found out that the same problem happened to a couple of friends of mine, and one of them, calling Maxtor, was told that the problem was in a Maxtor's fault in design of the 160GB models which dies when writing somewhere between 140GB and the end of the disk.
I then sent the disk to be RMAed, but now, 5 months later, it's going to come back without replacement because "Maxtor's software doesn't find problems, so Maxtor doesn't recognize any kind of problem I have". Initializing the disk with Maxtor's software sets the size of the disk to 140GB to Windows's enquiries... Linux instead ignore that software and just see 160GB which makes it unusable for my purposes. I'll just give that disk to my sister, and leave the Promise controller alone without disk connected to it (because the new machine has already 4 SATA channels, two of which are connected to two 160GB SAMSUNG disks.

On a side note, I started a new (personal) blog in Italian for Italian readers ;) Just for fun I also created a wishlist in Froogle... I know nobody is going to look at it :)

Ok I had just a little time to update my blog lately so it's time to get a bit of an update.

First, a good and a bad news: the good one is the one everyone already talked about, the software patents in Europe are cancelled for now; the bad one is the yesterday's event in London.. I think there's nothing I can say that hasn't already been said.

Moving to more Gentooish topics, vlc is still driving me mad with mozilla support (it requires some .so libs we don't have in gecko-sdk because it needs -fPIC love).
For now latest version has slp and mozilla support disabled. The first one will remain until a new version can fix it to use the latest API, the latter is the one I'm trying to take care of.

Also, I took over netatalk (package for file and printer sharing between *BSD/Linux and MacOS with its original protocol), adding version 2.0.3 which fixes most of the bugs open on bugzilla (also the one with future dates in 64-bit arches), and which is available now also for ~amd64.

libtorrent and rtorrent are still releasing one version every week or little more, and as I couldn't wait for the latest version to be in portage for more than a month to mark it stable, so I took the latest version of the two packages which had big bugfixes (0.6.4/0.2.4) and marked it stable for amd64 (my "maintained" arch).

Third news: I'll take care of media-tv/xdtv as soon as I have the amd64 support for mmx/sse extensions sorted out with upstream. Just wait a couple of days and you'll find xawdecode's successor on portage with ~amd64 (it can seem absurd, but it won't have ~x86 until someone will test it as I don't have x86 hardware to test it on).

I think I'm starting maintaining more useful packages :)