Diego Petten

I think I already talked about the importance of warnings while programming, if I didn't, I surely thought of doing so.
Today, I was reading michkap blog and I found this entry quite interesting (for the one who're wondering, yeah I don't feel strange reading MSDN blogs, and in particular michkap's is mostly focused on Unicode and i18n, topics that I'm quite interest about).

What he says there is true for every reality, not only closed-source proprietary software development; for Gentoo users, this should be simpler to see than for other distributions, as the programs are built in front of users' eyes, that can easily see the whole lot of warnings some packages outputs.

I try to make sure that my packages has no warnings as this usually means there are less chances that the software will break with newer versions of the compiler, I've also sent more than one time patches around just to fix warnings; I even committed to arts sources to fix some of them (and people who knows me are aware that I refrain also from touching arts's ebuild). Unfortunately there are some people who simply ignore warnings and don't even try to build their software with -Wextra -pedantic. Too bad :(

Oh for people wondering, there's an option in gcc to suppress warnings' generation, and it's -w. If you really don't care about warnings, you can try to put that in CFLAGS/CXXFLAGS; while I don't think it would change anything in build speed, it might make the output more pleasant to the eyes, especially joined with -s in MAKEOPTS; but of course this means that you have to remove both if you want to report a bug, as we usually need to see warnings and build output.

Okay after my --as-needed experiment proved not so bad (well a part many GNOME packages and MySQL and so on), I looked forward for something new to test that was conservative enough but still a good deal, and I ended up trying -Bdirect support by Michael Meeks.
This is a bit less conservative than --as-needed at it requires to patch both glibc and binutils, but I heard Michael praising those patches so much, that I hoped they were working fine :)

The bug for who wants to follow the -Bdirect function is #114008. I put the patched glibc and binutils ebuilds in my overlay for who dares to test them.

Now, the main problem is that xorg-server does not start when built with -Bdirect and if the variable LD_BIND_DIRECT is set (either to 1 or 0!). The problem can be worked around by starting X with LD_BIND_DIRECT unset (thus disabling direct binding) and then re-setting it to 1 in the session script, as I done here with kdm. On kdm the line to change in /usr/kde/*/share/config/kdm/kdmrc is

ServerCmd=/usr/bin/env LD_BIND_DIRECT= /usr/bin/X -br

the default Xsession of KDM will already reload the profile in /etc/profile so if you set LD_BIND_DIRECT in /etc/env.d you're already safe.

The speed increase seems interesting, with KMail at least that was built by itself with no other deps being using it. I'm really looking forward to it to see how it will behave on a complete system.

And for another note, thanks to KingTaco today I moved my SATA disks from the on-board VIA controller to the on-board Promise controller... it feels faster..

It's probably one of the most annoying things in the world. But it's also one of the most useful. That's at least what I think. I started some time ago by writing maintainers' guides to my packages, so that people who would consider handling them when I'm occupied would know the main problems with them.
This month I also wrote a guide to fix failures with --as-needed flag (with a description of what it does and why it's useful), and put that under qa's project (thanks Sven for allowing me to). Yesterday night, after seeing pinentry dying because of being linked to libcap also if not requested (a fixed ebuild is in my overlay, it's also reported on bugzilla), and looking at vsftp doing basically the same, I thought it was the case of writing something about automagic dependencies, too.

So I did, I fired up my Kate and wrote a new guide, always in GuideXML, about it, and can be found again in qa project, that I've also updated to put a reference to the two guides (the --as-needed one was unlinked before, a part some of my entries and a few mails).

I also tried to explain the reasons why automagic dependencies are bad for source-based distributions because I often found myself explaining that to upstream developers to get my patches applied, now I can actually point them to the guide, as I've done lately for the --as-needed patches.

What should I write next? I still have some notes about a parallel make fixing guide, that might come useful, as I found myself explaining that yesterday, too, but it contains lots of vague things, special cases like Qt's moc files and libtools linkings and double-file commands....
Another thing that might come useful is a guide to autotools failures fixing, that explain how to resolve problems like missing macros and stuff.

You'll see today or tomorrow if I'm going to write something about them ;)

Ah I also wanted to throw a stone in the lake in gentoo-dev, by asking if LINGUAS variables should be set in IUSE, as Donnie is doing for INPUT_DEVICES and VIDEO_CARDS in xorg-x11. It might be hilarious to see what comes out of it, but whatever the result is, I'm going to improve LINGUAS support in some kde-extra packages, so that they won't build tons of extra po files and documentation for languages that aren't used (why I have so much po files for Kaffeine!? :P).

Okay it's sunday night, and I'm at home. I don't have anything to do a part the infamous paid job that's driving me crazy and I'm waiting new info for. So what can I do? I can try to fix one of the KDE bugs I suffer from! :)
In particular, I gone for a KMail bug I encountered while replying to a mail of a friend of mine who's using an Italian webmail (not the provider she's connected with, or I'd have configured a Thunderbird on her box). Basically it does not accept some email/realname combinations if the realname contains @s .

Well the code where the problem was seemed to be KPIM::EmailParseResult KPIM::isValidEmailAddress(), that's a quite complex stateful parser, which flow took me some time to understand. How could I fix the problem in such a messy (IMHO) code?

I opted for a rewrite, so I started, and rewrote the function replacing the stateful parser with a series of regular expressions and string checks. This makes it simpler in terms of LOC (61 insertions(+), 157 deletions(-)) and also, always IMHO, easier to read.
This time I didn't work directly on KDE's SVN as this change is not exactly small (while also kxkb fixes for KDE 3.5.1 were mostly a rewrite), and it might have some problems right now (I'm still compiling KMail to see if it works fine). It also does not consider a couple of error situations that it was considering before, that might be a showstopper (basically I don't bail out if ',' is present or if \ is at the end of the string. It shouldn't be difficult to fix in case, tho.

Now does this mean I'm actually bored? Yeah it means that, but not only that, it also means that my personal life really needs a shock to change, shock that's not going to happen in the next century or so...

Update: I've actually rebuilt KMail and my patch does work for most of the cases, actually it works for the \ present at the end of the string because of the way I structured it, returns a different error but it does not allow the wrong address to pass through. I checked with a forged To line with my email address and then tried also replying to my friend's last mail. I attached the patch on the aforementioned bug and committed an ebuild using that patch in my overlay, but it's using 3.5.1 version that's still unreleased so people are not going to just emerge it to have the patch for now ;)
Should work with 3.5.0 too anyway.

... of finally having decent versions of xine-lib and xine-ui in tree :)

Since I joined and started taking care of xine, version 1_rc8 had to stay in the tree because it was last stable version on mips arch, and after a while version 1.1.0 joined with last ~mips keyworded version. As mips team can't actually maintain the proper keywording for it (as nobody seems to have a machine powerful enough to use it), I've finally removed those version dropping the keyword. I had to fiddle a bit with enlightenment stuff to get rid of a coupe of ~mips keywording on emotion and one of the packages depending on it, but finally I was able to restrict xine-lib to versions 1.1.1-r3 (stable) and 1.1.1-r4. This means less maintenance work for me mainly, but also that some more file gone away (ebuilds, digests and orphan patches).

Also xine-ui finally got the last version keyworded as that seems to work better than old one and also fixes the head -1 issues (that are non issues as coreutils didn't remove that deprecated syntax, but rather made it not yell that's deprecated).

Now I just need to try to get gxine 0.5.3-r1 stable (0.5.4 fixes problems to fluxbox users, but 0.5.x series should solve some problems, and I'm not really keen to think of doing the modular x porting of 0.4.5 myself (0.5 is already fixed). Unfortunately 0.4 is still last sparc and ~sparc version.

Oh well time to go working again, while I'm also trying to understand that work, still, I'm also trying to continue the work on RubyTag++, today I added support for the conversion functions that translates the C++ objects into Ruby's and viceversa.

It's been a while since my last blog entry as I'm trying to spend most of my time on trying to understand how the environment I have to work with is structured for the paid job I was given... actually I'm not understanding too much of it and I'm really tempted to reject the job: it's not PHP coding, it's a damn RAD environment that I don't really understand, proprietary, with sucky documentation and it does not respect what the commissioner said it should do. Add to that a particularly depressed personal life, and you have pictured my last days :P

I wish to thank all the ones who replied to my early post where I asked for a way to recover data out of an NTFS partition. Today my friend gave me the HD to try to restore the data and.. it wasn't NTFS, it was a FAT32 partition, but the disk was too corrupted to be able to take something out of it, every 4 bytes, 2 were NULL or 0xFFFF. gpart actually was useful, but while being keyworded amd64, 64-bit systems aren't supported (so I've marked it -amd64 now and opened a bug for it, I'm unable to solve the problem atm anyway).

The title of the entry refers to something I thought about while getting a DD image of the disk using the USB enclosure I bought last year. This enclosure, branded "Magnex", but referred to as ViPowER in lsusb, it's quite interesting: it's an IDE to USB 2.0 interface, and it has a rack support that's exactly the same I was using on my old Defiant box. That's why I bought that, as I used to have three different HDDs that I wanted to use with it. Unfortunately it never worked that right. It works fine when talking about transfers and it's actually quite reliable on reading and writing.... after turning it up; unfortunately after 20/30 minutes of activity, the HDD is spinning down and produces strange noises, whichever HD I put in it. I originally thought of a power problem, but the power supply comes out of the UPS, and the ac/dc converter seems to work fine (I've tested with a multimeter). I thought it might have been heat, but it's quite cool actually.
I'll be grateful to whoever has an idea of what the problem is :P

On another note, I wanted to try again to setup an IME on Linux, as I already have it on Mac OS X. Not like I actually know Japanese enough to use it well, but I'm always interested in learning it when I have time (that's why I started reading this site while I have nothing to do and I want to relax :P). Last time I tried, not only I wasn't able to actually make it work, but I was also losing us_intl support.. luckily new versions of scim supports the "dead keys" method too :)
I just needed to emerge skim, scim-anthy (found that suggested on some site, doesn't require a running daemon like canna, seems interesting :P), scim-qtimm (required to rebuild qt with immqt-bc) and setup the environment variables as told by pkg_postinst. Now I can actually write 炎の二目 ;)

Okay this might be of help to who wants to try GCC 4.1 and uses VMWare (I'm actually running the 30 days evaluation license, as I hope to stop using Windows before it expires anyway :P), as the modules as they are won't build with GCC 4.1 requiring the whole kernel to be built with 4.0.. well I didn't want to rebuild everything, so I looked what's up with that.

The cause of the problem is that the tests used to recognise if the kernel has or not some of the features VMWare modules are using failed: the tests runs with -Werror to make sure that incompatible declarations don't leave the compilation going on. Unfortunately, 2.6.14's headers has a warning in it while using GCC 4.1: include/asm/apic.h:47: warning: value computed is not used.

The fix at this point is trivial:

tar xf /opt/vmware/vmware-workstation/lib/modules/sources/vmmon.tar
tar xf /opt/vmware/vmware-workstation/lib/modules/sources/vmnet.tar
sed -i -e 's:-Werror:-Wno-unused-value -Werror:g' vm{mon,net}-only/Makefile*
tar cf /opt/vmware/vmware-workstation/lib/modules/sources/vmmon.tar vmmon-only
tar cf /opt/vmware/vmware-workstation/lib/modules/sources/vmnet.tar vmnet-only

This make sure that the warning is not thrown thus fixing the tests, at which point, the modules will build fine and will be happy to load and start VMWare up.

Okay, this is just an update post to make sure that nobody thinks that I'm disappeared :)

First of all, I'd like to inform all xine users that I've called arches to stable xine-ui 0.99.4, so soon it will hopefully be the only version of xine-ui in portage, fixing the problem with head and tail using obsolete options (that seems still to work for me but I'm unsure of the reason), and a few other problems; xine-ui is another of those programs that have an optional xinerama useflag that allows to disable libXinerama entirely when using modular Xorg :) Always talking about xine, I've started the process of removing xine from (~)mips keywording as it was lingering around too much, so I think that if you're running mips and you want xine, you really have to contact the mips team, if you have a machine powerful enough to start maintaining the keyword for them, you might be of help.
The situation of keywords with xine-lib is quite difficult to manage, as often I had to drop the keywords, either because a new ffmpeg snapshot was added (and Luca called for a new testing request) or because I've added a new dep (like in 1.1.1-r4) that requires keywording or dropping. Last version of xine seems to solve most problems tho, while I still have to prepare a new patchset this week with a few more patches to fix the last minor bugs open.

Then yesterday I submitted a new patch to gutenprint to fix --as-needed support without breaking on older OS X/Darwin systems, and readded the patch in portage (also more lightweight than the old one as this time I don't have to add gtk.m4, as upstream added it). In a similar note, I've sent a patch to netpbm to its author (Bryan Henderson) who also suggested me a few changes to the --as-needed guide (really: what I was smoking when I called GNU ld "dynamic linker"? sigh I should read what I write before committing sometimes). Unfortunately seems mysql is another of the programs that doesn't like --as-needed... but to fix that build system is something I'm not really tempted to.

For the less Gentoo side, rubytag++ is still on hold while I try to complete my paid job, that's showing itself as an Hell of unspoken proportions: I'm being a PHP code monkey, using MySQL 4.0 (no way to use 4.1), in Windows (it's not working with the default php.ini for Unix, and I didn't get the settings to change to have it working with the code to work on, so I have to do everything from Windows; I had to spend three days to get a working environment and I'm now fighting with a proprietary application that provides a RAD-like environment for PHP but it's documented poorly and wrongly, and the function that should format a date for SQL seems not to know how to do that, as it's formatted in a "mm/dd/yyyy H:mm:ss" format that's unrecognised by MySQL's DATE type.

Ah and something that I'm really glad of, after findutils starting having a stricter input format, is that with KDE 3.5.1 the KDirOperator class is working in Korundum (KDE's Ruby Bindings) so JulyTagger is going to actually work now, and that amaroK 1.4 will require Ruby (well, optionally, but if you want lyrics, you'll need it), so it's not like my future programs will be so much of a problem for people because they won't require things that almost nobody has installed like Ruby (while I have it installed for many other reasons anyway, starting from gorg and going to rbot, and my own script for portage's checks).

Finally, I want to reply to a couple of comments about the compiler's stats. WRT Konversation, I found strange to see that much of mmx/sse used by Konversation, but it's not the only one, seems like both 4.0 and 4.1 already does a good work with -ftree-vectorize flag, but with 4.1 the number of MMX instruction used by many programs seems to increase vastly, while the size of the executables and libraries drops quickly. This is both interesting because it should make things faster (as the extensions should be faster than the normal operations) and still gives a low footprint in memory). Unfortunately 4.1 seems also to take quite a lot more time to compile things :(

For who was asking about the analyse-x86.pl script that I'm using, it's a modified version of solar's original script, that I still don't remember who gave me :P I think it was morfic, but I'm not sure... so who knows who gave it to me, step up! :P

Okay, after Sebastian, I also wanted to move to GCC 4.1 and see how it was, last time it wasn't so likely to go along with KDE.
From a feasibility of its use, it's surely improved: KDE doesn't get killed while using it, many parts of the tree were changed to not require support for -f(no-)stack-protector(-all) flags, and so on.

I wanted to try it with xorg-server as it's an interesting test I already started. It has to be noted that there's a maybe big change between the build with gcc4.0 and the one with gcc4.1: the first was using -g3, the latter -g -ggdb.
The time required for it to build something is actually longer:


Tue Jan 3 10:06:21 2006 >>> x11-base/xorg-server-1.0.1-r1
merge time: 36 minutes and 46 seconds.

Tue Jan 24 20:27:32 2006 >>> x11-base/xorg-server-1.0.1-r1
merge time: 1 hour, 32 minutes and 50 seconds.


The size of the final executable (stripped) is a little smaller the old one:


-rws--x--x 1 root root 1709984 2006-01-03 10:04 /usr/bin/Xorg

-rws--x--x 1 root root 1687568 2006-01-24 20:24 /usr/bin/Xorg


The size of the whole package is absolutely different, but that mainly because of the difference in CFLAGS:


x11-base/xorg-server-1.0.1-r1: 384 files, 47 non-files, 360023.132 KB

x11-base/xorg-server-1.0.1-r1: 384 files, 47 non-files, 109325.470 KB


The generated code seems to differ quite a bit:


Checking vendor_id string...AuthenticAMD 64
Disassembling /usr/bin/Xorg, please wait...
i486: 13 i586: 0 ppro: 0 mmx: 1835 3dnow: 0 ext3dnow: 0 sse: 1036 sse2: 3662 sse3: 0
/usr/bin/Xorg will run on AMD Athlon64 or higher processor.

Checking vendor_id string...AuthenticAMD 64
Disassembling /usr/bin/Xorg, please wait...
i486: 13 i586: 0 ppro: 0 mmx: 1939 3dnow: 0 ext3dnow: 0 sse: 1065 sse2: 3514 sse3: 0
/usr/bin/Xorg will run on AMD Athlon64 or higher processor.


The quantity of i486 instructions is always the same since monolithic, the number of mmx instructions increased, and that feels a bit strange as 4.0 was decreasing it; sse increased too, all in spite of sse2, that decreased and it's now less than the one in the original monolithic version. I think that the average is an improvement, or at least I hope so.

But I said interesting, so here comes the funny part:


Checking vendor_id string...AuthenticAMD 64
Disassembling /usr/bin/konversation, please wait...
i486: 0 i586: 0 ppro: 0 mmx: 1548 3dnow: 0 ext3dnow: 0 sse: 0 sse2: 68 sse3: 0
/usr/bin/konversation will run on AMD Athlon64 or higher processor.


Konversation is using some sse2 instructions and quite a few mmx instructions... why that? I have nfc, but it is.. interesting, eh?

So, I'm taking a bit of inactivity time now. The reason is that I found a paid job that is going to take me lot of time.
I'll still be around for urgent things, but I'll be a bit less responsive in the mean time.

Actually, the inactivity started Saturday, but that day it was for a completely different reason (had to help a friend of mine with an HD problem, by the way if someone has ideas on how to try to recover data from an HD which partition table is completely messed up and cannot be attached to a Windows box (either as EIDE or as USB), please leave a comment... unfortunately the partition is NTFS so the quest is harder than what I coped with before.. recovering data out of a FAT partition is not that difficult).

Anyway, I'm going to have lunch and then continue setting up the environment for the job, wish me luck :P

I've read an interesting post of Hubert Figuiere (note: SPAM protection doesn't allow me to point you to the right post, sorry :|) tonight in Planet GNOME, and I'd like to leave a couple of comments about that.

While I don't want to comment on Fluendo's release, that already got some legal debate coverage and RMS's attention while discussing GPLv3, I'd like to concentrate on what people don't actually see about it.

Actually, Figuiere got the right wording the first time: "Christmas Present to the Linux community", but then, he repeated it wrong: "a USD$50,000 gift to the open source community" it is not a gift to opensource community. It might be considered a gift to the Linux Community, not to the Linux Open Source Community, not to the Linux Free Software Community, it's Linux or Linux Proprietary Community, because at the end of the day, the MIT license under which the sources are released is yet another patent's trap; by all means that plugin is _proprietary_ software.

Actually, one should change that again, it's not yet a gift to the whole Linux Proprietary Community... it's a gift to the Linux Proprietary x86 and x86_64 Community. Linux is not limited to those architectures, but all the rest of architectures can't use it at all (building it from MIT sources? why should anybody? it can't be considered the same of the binary version, it won't have the same reasoning behind of the binary version, and while libmad might be flaky sometimes, it does exists since long time and it's GPL-2).
It can't be considered a generic gift to the Open Source Community because that plugin can run only on Linux, no *BSD at all.

And improving the MIT-licensed code will just make proprietary software better, not Free Software better at all... I think time can be better employed by using non-patent-covered formats and their support in _true_ Free Software.

Okay so I'm continuing working on taglib's bindings for Ruby, using the C++ interface. My M4 file now is able to generate most of the structure code that I need by providing it the basic informations about the classes and the methods I want to bind. Unfortunately, this is not yet enough to get something working: I have yet to generate the constructors, that are the most important part of all of that, and I'm having trouble to assess if an alloc function is needed for the classes that cannot really be created by users, as they are only returned by TagLib itself.

I think I'll try to concentrate on having something that loads on Ruby soon, and then start having something that works later. Right now I have also put in place autotools' support so that it goes looking for Ruby and TagLib. The main problem is that to create a shared library I'm using libtool, and that don't allow me to call the library "rubytagpp.so", but wants to call it "librubytagpp.so". I have to find how to get around that.

Leaving for a while RubyTag++ alone, I've been pleasantly surprised by Google's decision to open Google Talk to the other Jabber servers. The first thing I've done after that was to move all my contacts from Talk to Jabber, so that I don't need an extra account to talk with some friends. I think this is really going to improve Jabber's appeal: while some of us has access to decent servers (like im.gentoo.org, thanks infra again ;)), jabber.org is somewhat unreliable and many other public jabber servers seems to have similar problems (I can name for example jabber.linux.it that was having more problems than working support), with Google Talk, part of the problem is solved, who can't find a decent Jabber server can use Google Talk and stick with that, others can still reach him :)
I really hope this is going to change the distribution of users in the IM services, especially I'd like to get rid of most of my ICQ contacts if they move somewhere else.

Okay, just a few things again on the Ruby bindings for Taglib's C++ interface. M4 is really helping out, it has a quite steep learning curve but when you know how to use it, it's really simple to let it write the code. Basically I just have to engineer the macros one time, and then I can reproduce it for the infinity.
I'm also trying to make it generic enough so that it can be easily used to write other kind of bindings.

What I have to do now is to allow defining classes inheriting from parent classes and then allow to reorder the classes in modules (miming the namespaces in TagLib). It's giving me headaches to think how to do that from outside, but the same happened for the rest before I got into it to start coding it out. The C++ code I've been able to generate right now does not yet compile, also because I'm missing the functions that "bridges" the TagLib's types with Ruby's internal representations.

The road I have to follow is still long, but considering I started yesterday night, I can say I'm happy with it.

As I said, there's currently no good TagLib bindings that I can use for the tagging program I'd like to write, as the only ones available (ruby-taglib and rtaglib) are using the (very limited) C interface.

So I've decided to start working on new ruby bindings using the C++ interface. The extension API of Ruby is not the worst I've seen: when I tried writing bindings for Python in my UO Server Emulator, I _really_ was being driven crazy.

What I'm still looking for is if there's a way to get something called when an instance has to be disposed by the garbage collector (so that I can delete it). For the rest, it's mainly requiring work on the code to compile, as that's what the bindings consist of: lots of functions that just calls the true function.

I think I can "simplify" the work by using some M4 magic (the idea came from ciaranm and his bragging around about the M4 macros he wrote to avoid rewriting the same thing over and over), but that surely requires lot of refinements, because of course without having the code it's also difficult to design the interface.
Anyway, this thing is actually interesting me because it's something different from what I've done in the past and it seems like it can be of help :)

If somebody wants to see what I'm talking about the M4 things, I've used bazaar again: http://dev.gentoo.org/~flameeyes/bzr/rubytag++ . The version (1.4) is related to the API version of the library, it will proceed like 1.4.1, 1.4.2, and so on and bump to 1.5 following taglib.

Update
Thanks to Caleb who replied me as usual really quickly, now I know what I have to do :)
I'm working on the actual code that generate implementation (it's M4 code, thanks again to Ciaran for giving me the idea), and I already have something done. The road to work is really long but it's a starting point :)

As I said today the option to recode tags in amaroK is now gone and it wants that the tags are filed with valid UTF-8 support. EasyTag, while seemed to work originally, seems not to work on the long run, it crashes on its own processed files!
And there are currently no good choices for KDE/Qt based software for tagging that I know of (okay amaroK has support for some tag editing but it's not the same of EasyTag.

So I'm tempted to start a tag editor written in Ruby, using Korundum. Why Ruby and not native C++? It's because of a series of reasons: there are already bindings for freedb access and taglib, Ruby is natively UTF-8 compliant and I don't have to deal with that myself, I don't even have to care about endianness.. Then there's the thing that I'm being a completely Ruby freak lately that _might_ make me biased :D

I think JulTagger can be an interesting name (you have to guess the reason of such a name tho :D); I'll give that a shot now, I have some free time and I want to take a bit of work on something for a while non-gentoo-related.

Update
Okay, I started working on it, it's not difficult at the end to at leat mock the design up when using Korundum. I've placed it as usual in KDE's SVN, playground/multimedia module, so whoever wants to get it and start looking around.. it's only barbone right now.
Unfortunately this barebone is enough for me to see that ruby-taglib is not powerful enough for what I need to do, it only provides basic API support because it uses the TagLib's C interface.
I'd have to write something more complex if I really want to continue this way, and I want, but that might take some more time...

Okay, as I promised, yesterday I finished taking a snapshot of amaroK 1.4/trunk and it's now my overlay (use Bazaar-NG to get a copy of it entire).
I wish to thank amaroK upstreams developers for the support and the good work, in particular lfranchi who helped me with taking the snapshot yesterday.

I have to say that it seems to work fine for what I can see up to now; the only issue I had is that the recode support is no more present so the old UTF-8 tags got loaded wrong; EasyTags seems now able to fix them, but it's crashing now, sigh.

On another note, I found that my problems with rtorrent/libtorrent are due to -Os, so I made the ebuild change it to -O2 and now works fine :)

It's midnight now, I'd like to be in my bed, reading The Wastelands (by Stephen King, The Dark Tower series), but instead I'm here, in front of my workstation, again. I'm actually not doing anything particular, that's why I'm writing here, I'm probably going to take time to read some webcomic, but I'm not really in the mood.

What I'm doing here? Well right now I'm waiting rtorrent to complete the download of a torrent so that I can check if -fomit-frame-pointer is breaking on amd64, too. Still an hour to go. On another term instead I'm checking out amarok's localisations as I'm preparing a snapshot for the ones who dares to try it. It will be in my bzr overlay that I've started publishing lately.

I'm quite tired, today I spent the day... well I can't really tell, it flied away quite quickly, I had to do a bit of real-life cleanup, then there was the GCC4 test (turned out the culprit is patchset 1.3, I hope Mark can get to fix that soon).. I spent some time reading vgcats, too.

I planned lots of things to do today, and I basically did nothing, mostly because I thought of waking up at 9am, and I didn't wake up until 11am (sigh), but also because I'm trying to give up with coke (not THAT coke, I mean Coca-Cola! :)) and I feel that missing caffeine I'm less productive :P
Are there some caffeine patches for caffeine addicted? It would be handy.

Anyway... I'll wait :P

Okay, after today's rant, something more interesting.

When I originally started testing --as-needed support, I also found a problem with wxGTK and aMule that I thought related to that flag but it wasn't. It's bug #118361.

From the bug I got the idea that the problem was related to our patchset, but I wasn't so ready to sacrifice the stability of my live system for that, and adding yet another chroot was going to be a long time to go. Fortunately, thanks to AMD who donated the boxes, and KingTaco and the other admins who gave me access, I could use Pitr to do the tests :)

But I can be a stupid also when I don't try to, so I actually spent two days trying to reproduce the problem... using GCC 3.4, sigh. I found that oly when I tried my own CFLAGS to see if it was a flag problem and gcc bailed out as it wasn't knowing anything about -ftree-vectorize, meaning GCC3 was being used.

Okay so I started again and pitr is now rebuilding GCC and then wxGTK and aMule to see which patchset breaks it (as I'm sure I used to build both with GCC4 without problem); so far patchsets 1.5 and 1.4 proved bad, going with 1.3 now.

I'll try to keep the bug up to date on what I'll find so that Mark can find the culprit :D (yeah I'm a slacker, I'll stop at finding the patchset).

Sometime ago Greg KH started an 'how to piss of a kernel subsystem maintainer' saga... on a similar fashion, I'd like to write a (hopefully) single entry on how to annoy an ebuild maintainer.

As I wrote yesterday amarok 1.3.8 was near, and in fact was released in the night. Okay so what's the problem with that? Well there're no problems with that release, I was able to try out both rc1 and rc2, the ebuilds was already in place and so on.

So right after the release, I downloaded the tarball, digest, emerge, start and simple try, then copied the tarball to go on Gentoo mirrors (as there seemed to be problems with the SF.net's mirrors at the relesae), and committed the ebuild. It took less than half an hour, mostly technical time.

So then, the first bug was filed, I asked Jakub to take care of it because I was tempted to lose PG rating if I was to reply to that.

After a while another bug was filed, and I replied to that with as much calm as I could.

So, just to make this clear, when you're tempted to file a bug for a version bump, think! Not only the usual rules for bugs apply (look for dupes, check if the bug is already fixed in the current tree, that is, the bump was already committed), but also don't start filing bugs for things that were released less than 24 hours ago! It might be useful if you know that the package is usually bumped late, but amaroK was always bumped the day of, or in case the day after the release. In general, don't file bump requests before a week from release.

Oh just as an update from what I said yesterday about the coming 1.4 series: I'll try to get a snapshot in my overlay for testing, libifp is probably going to be maintained by chutzpaz (or how's spelt that ;)) as he'll become developer, libgpod doesn't work with unieject -yet, I'm missing SCSI eject support, I'll have to check for that-, so I won't probably install it and just rely on upstream working ;) This all means that amaroK 1.4 will have the flags for ifp and gpod most probably, but they comes "untested" in Gentoo. No big deal tho.

Continuing the I'm out of cool titles saga, this is mainly a changelog entry for myself that I want to put some lights on :)

I think I already wrote about amaroK's team way to inform packagers of new versions of amaroK. And who idles around in #amarok @ freenode, probably already knows that before the actual release there are usually one or two (or more) release candidate releases. Last time I put them directly on portage, under p.mask, but I wasn't happy enough of that solution because the SRC_URI was broken and I was really expecting bugs about that.
This time, as yesterday I made public my overlay, I pushed those ebuilds directly there so people can get them when they want. If you want to be updated when push something there, the changes appear in my CIA page (sorry yesterday the commits appeared on Gentoo project, now I changed them to flameeyes project anyway).

The current version available is 1.3.8_rc1 as the rc2 in #amarok's topic was foobar and was code of 1.4 series instead ;) Well this mistake was actually useful to me as I could take a look at the new deps at least. Unfortunately, it's probably going to be an headache, especially for me. The new (optional) deps are mostly missing in portage: libifp is completely missing, a bug is filed about that, but it's in maintainer-wanted and the ebuild does not work as intended anyway; libgpod is handled by joem, and I'm not even sure if it's the right version, the dependency over sys-apps/unieject is a problem for me as I'm using unieject here, I think it can be changed to virtual/eject but I want to hear from joem about that; exscalibar is not even reported on bugzilla.

What does that mean? Well it means mainly that amarok 1.4 on Portage won't have the useflags to enable ifp and exscalibar support and _might_ have libgpod support but that would be untested by me at least (I don't have neither an iRiver nor an iPod). Gentoo developers that might want to add and manage them and test amaroK's features related to thos are obviously welcome to step up; non developers wanting to join Gentoo are welcome, too. For the ones who are not developers and don't want to become, and still wants amaroK ebuild to support libifp and libgpod and the features to be tested working.. find someone else to take care that has the hardware, or donate the hardware, that's a solution too.

Okay and as I said "ebuilds" in the title, I actually have an interesting change to 1.3.x series ebuilds, too... from 1.3.8, the $LINGUAS variable will be respected, so it won't install lots of locales and build documentation for all the languages it supports. In my case, it just built Italian language and documentation as I have LINGUAS="it en" (I actually have that only to get Italian spell checker, as I use the entire system in English, but anyway).
That is probably going one of the main reasons to update to 1.3.8 as the changes from 1.3.7 are actually bugfixes, most of which we don't really care about (NMM and HelixPlayer backends are disabled in Portage) and the important one (lyrc's change) is already applied in 1.3.7-r1 (thanks Ian again :) ).

So, before being a developer I used to maintain my own overlay on my site with many changed ebuilds, with extra patches and stuff. That's how I actually ended up being a developer :)

Now, it's been a while that I wasn't publishing it, while I was still having things in overlay, obviously. The reason was that I wasn't really sure how to provide, and what to provide in it anyway. I used to use tarballs but they took quite a bit of time to prepare and I can't spend extra time just to package an overlay that little or no people would use.

With today's work with Brian and bzr, I thought that might be a good way to handle it; I already managed my local copy with subversion, so moving to another SCM was not going to be difficult, and with bzr push command it was quite simple to let it online.

So now, if you want, you can get my overlay at http://dev.gentoo.org/~flameeyes/bzr/overlay . It's not a 100% complete overlay as I had it locally, as many things are still only on my overlay, mainly things that are not complete to final users.

The ebuilds on my overlay are obviously unsupported :) I tried anyway not to put things that may screw users around, I originally put my patches for xkbdata and evdev driver I wrote this summer as applied unconditionally and that would break users not having and using an lx700 keyboard, but then I decided to put an lx700 userflag on the two so that they won't break anything (hopefully). So if you want my lx700 patches just put lx700 in useflag and re-emerge xf86-input-evdev and xkbdata and you'll get them :P

I just hope it can be of help to someone :)

Preamble: this entry is mainly oriented to Gentoo developers who wants to use bazaar on their devspace on dev.gentoo.org (toucan). I hope nobody gets angry because of that.
I won't try to explain how bazaar works as I haven't use it before today, and was guided by Brian to use it, I'll just try to simply explain how I configured it to make use of bzr push command to put the stuff. It's sort of an hack, but it works.

First of all, with bzr 0.6 you don't have bzr push in the default command set, instead you need bzrtools, too.
After emerging it, edit the file /usr/lib/python2.4/site-packages/bzrlib/plugins/bzrtools/bzrtools.py, at line 227 add to the rsync() call ssh=True parameter. This is the hacky part, we have to force rsync to use ssh instead of looking for an rsync daemon, as there's no rsync daemon on toucan.

Then it comes to the configuration. If you try to access rsync now, you'll get errors because it can't find rsyncd.conf and a series of other errors. Create then a new file on your home on toucan called rsyncd.conf and configure it this way:

use chroot = no

[username-bzr]
path = /home/username/public_html/bzr
comment = user's Bazaar repositories
read only = no

the parts in italic are the ones that has to be changed and can be changed, the first identifies the module to use, the second the path, the third the name. The third can actually be skipped, probably. It's important to disable chroot (as it won't work not being root), and to enable write access as bzr push has to write.

Then when you want to push the things you just do

bzr push rsync://username@dev.gentoo.org/username-bzr/repo

Et voil

Okay yesterday I finally managed to write a guide to --as-needed flag and to the ways to fix it. It's not complete, it's still a draft, and I didn't link it in the resources for the QA project (where it's currently laying).
You can find it here; feel free to comment about it to me (here or directly to my mail address).

It's not the only thing I did yesterday actually, I spent quite a few time cleaning up the maintainers' guides for vlc and xine-lib, refreshing the sparc specific notes on the alsa guide and so on.

Today instead I found time to get rid of a few bugs of xawtv, hopefully 3.95 is going to be candidate stable as soon as possible as it fixes lot of different issues.

I'm also working on getting virtual/libintl in portage, to improve at least a bit the dependencies for Gentoo/FreeBSD (next step would be to add virtual/iconv but that's more complex. The big problem is to avoid circular deps with glibc as that would be the "provider" for glibc systems.

Anyway, this was just a quick entry to show the --as-needed guide, so no need to increase it too much ;)

Yeah if you can't tell, I'm running out of cool titles for blogging.
Anyway this is quite self-explaining. Tonight I spent some time, after a careful emerge depclean, patching KDE to remove some stray linking to libXcomposite and libXscreensaver in kwin, kdesktop and kicker.
The patches consisted mainly of configure.in.in mangling to remove the reference, and I committed them on upstream SVN so that they are available for next versions, too.
I just hope we'll have someone handling KDE bump to 3.5.1 with split ebuilds because I'm mostly scared of doing it again.

Okay, I think I'll go back looking for what links to xinerama, maybe I'll find something that can be patched to get rid of that one form my system as I don't use it.
The first target is gxine, as usual ;)

Update: okay I ended up adding a few more patches and xinerama useflag then. Gxine, Kaffeine and KSplashML are honouring --without-xinerama in main portage now (and with the exception of Gxine they are also upstream). I have a local modified ebuild for x11vnc and tvtime, both submitted upstream and waiting for them to see if I should send the patches to swegener and obz. I'm rebuilding GTK+ now but I might have hit an issue with --as-needed due to test programs linking to installed libraries instead of the ones just built, waiting now to see if it's a trivial fix as I hope.

VLC is the last package I have on the system that links against xinerama (well ok there's still wxGTK here but it's probably a consequence of GTK+ as it does not support --as-needed), but I have yet to try preparing a patch for it as I wanted to leave it as last.

If I'm able to fix these three remaining packages, I should be able to get rid of xinerama altogether! Yeah! Obviously it would be more complex if I wasn't using --as-needed as in that case libXinerama.so.1 was linked in most of my system.

I'll be back tomorrow with more status updates.

Okay, some time ago I started using and contributing to two/three C++ libraries from a fellow Italian developer (Giancarlo Niccolai): wefts (for multiplatform threading support), mxmlplus (for XML DOM parsing) and cabal (for multiplatform networking support). I was using those three libraries for another project, an Ultima OnLine server emulator (Hypnos) that then I dropped (and now you can see that lisa is not the only addicted, but well, I'm in rehab now :) ).

While working on them, I also wrote ebuilds for the libraries, and two of them got added to portage, specifically dev-libs/wefts and dev-libs/mxmlplus. What's the matter then? Well some fixes I committed in the libraries CVS were missing, and at the end quite a bit of patching was needed to make them work right.
Lately, with C++ herd creation, I thought of restarting work on them but I wasn't able to find time. Last week I convinced myself to at least prepare working snapshot for them and move them to dev-cpp with the full name (libwefts/libmxmlplus). So I did it. I cleaned up autotools support that was a lot rough, used libtool in the right way, added pkg-config support making easier to use them, and finally packaged and moved them.

Now, I didn't got around to add more features or things like hiding symbols, but it's at least cleaned up so that new work on them can be done without big issues with new compilers and stuff.

Okay now a quick comment on xine-lib status: after a keywording cleanup that finally allowed me to have xine-lib stable keywords all on the same version (or about), I had to drop again some keywords, this time because I've added a conditional dependency on libmodplug for the latest version 1.1.1-r4. Another dependency to fix in configure so that it wouldn't be automagic. Versions -r3 and -r4 are at the same patchset level, so there's no difference in them if you hadn't libmodplug installed and you have -modplug. -r3 applies the patch but then disable modplug entirely. I'm still waiting for mips to decide what to do with xine-lib package.

Okay so I continued working on --as-needed. I also started drafting something up for a guide to explain the reasoning of --as-needed and the way to fix packages having problems with it.

First of all, --as-needed did not kill my system at all. Also glibc built fine with it. wx-based packages has to filter it out because they make ld crash, but that's just a side problem. I've added filtering to vlc, mkvtoolnix and wxlib eclass to solve this.

avidemux still fails, and probably so does a few other packages that I don't have merged but this is going to be fine soon I hope :)

For the rest, if you want to spend time testing, --as-needed might be worth the time spent on it.

Okay, so I've started getting Gentoo/FreeBSD 6.0 stage working. The main big problem now is with openssl and python. In particular, seems like the LD_LIBRARY_PATH value is simply getting ignored, they try to run binaries loading the libraries from /usr/lib, that are linked against libc.so.5, then python loads two libc versions and gets killed.
Without LD_LIBRARY_PATH I'm actually a bit stuck, so while I don't find the reason why it doesn't load the just compiled version.

Until this is sorted out, I'm mainly stuck.

In the mean time, who wants to update to 6.0, please sync, and then re-emerge world with gcc built with --disabled-shared, to be safe.

Okay after rebuilding my dev box, I wanted to start working again on Gentoo/FreeBSD 6.0.
The first step was to disable shared version of libgcc to allow to build a libc.so.6 not linked to libc.so.5.. this was accomplished by editing toolchain eclass and re-emerging GCC. The result is good, libc.so.5 was self contained, finally.
The next step was to build libc.so.6 and watch if it worked. To do so I had to build the actual source tarballs for 6.0-RELEASE that weren't ready yet, but that was simple to do with the extract script.

In SVN's overlay there are all the ebuild for 6.0 series, although only some of them are actually compile-tested, I still have to test the kernel, too.

The procedure is more or less this:

1. change the profile to use 6.0 instead of 5.4;
2. emerge -avu freebsd-sources, check that /usr/src/sys is a link to sys-6.0(-rX);
3. emerge -avu freebsd-lib;
4. change CHOST value in /etc/make.conf to i686-gentoo-freebsd6.0;
5. emerge -av1 gcc binutils;
6. emerge -ave system;
7. revdep-rebuild --soname libc.so.5;
8. emerge unmerge =freebsd-lib-5.4*.

Currently I'm rebuilding system, so The last part is theorical, and might have some quirks still.

Oh for the ones following my --as-needed battle, the patches I had are now merged in ebuilds in Portage. I still have to fix avidemux. Rebuilding the system took me 7.5 GB total of /usr/lib/debug files, building with -g3. I still have to try a reboot, tho.
Oh and yeah, splitdebug works on FreeBSD, too!

Okay my fake-emerge-world completed. I have no big deals on my system with --as-needed problems, so just a summary.

wxGTK needs to be fixed, I'll try to do that tomorrow if I can find time (have work to do for the family plus I'd like to watch one of the DVDs I bought today). aMule follows wxGTK. mkvtoolnix and vlc blacklists --as-needed when wxWidgets is enabled because they make ld segfault.
mt-daapd is currently blacklisting, I can fix it tomorrow.
For net-snmp I have a patch, that I still have to try.
libwww took me a while, but thanks to ccache and continue "make clean all", I sorted it out, a bug is available.
Avidemux requires fixing (but I might probably just blacklist it).

Update: libwww fails to install, have to see why this, if it's related to my patch or not. net-snmp instead works fine, yeee!

GNOME users has little to be happy about, unfortunately. Sebastian sent me some failure logs, some of them are quite interesting because there are circular deps that are difficult to fix.
If I won't be able to fix them, the only alternative is to blacklist --as-needed until they're fixed.

Just for telling you that, I've also restarted working on Gentoo/FreeBSD as I fixed my box, the result is that I'm actually going to try the FreeBSD 6.0 jump soon, I had a few tricks told me by azarah and vapier that I might be able to find, if not a solution, at least a workaround. I also fixed readline today that was simply failing before.

Following Simon's idea I want to give a status report of 2005 for what I've seen in the projects and herds I'm in.

• First of all, with Gentoo/FreeBSD, when I joined, we wre finally able to get the 5.4 release working mixing portage and FreeBSD code to have a working stage3 support, it took a while.
• We started doing changes to the real portage tree to support FreeBSD, fixing dependencies and adding patches so that packages will build "out of the ebuild".
• FreeBSD 6.0 is still giving us headaches, but I'm currently having an idea that might work.
• Grant (g2boojum) left the lead role for Gentoo/*BSD for Stephen (spb) and I joined as his deputy.
• The Gentoo/Alt project was reorganized, pvdabeel, who seems to have disappeared from Gentoo scene, left the lead role, and I took it by decision of the developers working on Gentoo for Mac OSX and Gentoo/*BSD.
• Fabian (grobian) was chosen as lead for Gentoo for Mac OSX project, taking the place of pvdabeel.
• Kito and Fabian, with help of Brian (ferringb) started working on the prefix support for Gentoo for Mac OSX, preparing the base for other Gentoo/Alt prefixed project eventually.
• The tree started a long road of de-GNU-ification, lots of syntaxes that caused problems on Gentoo/Alt projects are going to be dropped from ebuilds and check written to make sure they won't get again into them, the first notable thing is enewuser which doesn't accept /bin/false (being a Linux-only shell) as disabled shell anymore.
• Damian (thunder) started and released a Gentoo/NetBSD port, Robert (arachnist) started a Gentoo/DragonFly port (but still has problems that hinder the release until they are fixed, part of the code is being merged already, tho), reb restarted the work on Gentoo/OpenBSD which was dismissed by Grant.
• Gentoo/Alt Project Page started collecting technotes and documentation about the various Gentoo/Alt projects, providing a reference for other devs and users wanting to help. The gentoo-alt mailing list was created and an alt@gentoo.org alias is being used for Bugzilla's issues that are common to different Gentoo/Alt projects.
• KDE herd got not one but two major releases using the new split ebuilds, 3.4 and 3.5. We also had to "fight" with the visibility support, that was first introduced in 3.4 but was creating problems because of a short sight in upstream.
• A new Linux-PAM release was marked stable (0.78) making possible to use pamd files compatible with both Linux-PAM and OpenPAM in all packages; also pam eclass was introduced to make simpler their installation.
• Video and Sound team had lots of cuts in their members, mainly because of Chris White leaving them, I took over xine-lib and vlc entirely, and cleaned up the build process with upstream help; after eradicator stopped maintaining XMMS related ebuilds, Luis (MetalGod) took them over; Luca (lu_zero) prepared many snapshot of ffmpeg to cope with requirements of new packages such as xine-lib with external ffmpeg and vlc.
• The GCC4 introduction required lot of patching in packages and shown the limitations of some packages like transcode 0.6, which finally stepped down for the new transcode 1.x releases unmasked last week; the domino effect of those limitations also made us drop avifile support to have more stable multimedia support; currently vlc, xine and mplayer players works fine with no major problems.
• About AMD64, Simon already told everything, I just want to say I'm glad I'm one of the six ATs who joined as a full-time dev :)
• Oh and thanks to Daniel (dsd) we have Planet Gentoo, and we can write these posts to let you all know that we're alive and what we've done (this really helped, especially with Gentoo/FreeBSD and Gentoo/Alt, as it shown a different approach to the whole communication problem).

Yeah we probably did nothing, eh?