Luca Barbato

Here some ideas about alternatives and gentoo possible alternative implementation (refer to Diego's post):

- implemented as an eselect module, possibly with an alternatives interface for those who like it
- will work just on executables you directly run
- it will be backed by an eclass to handle post-inst/post-uninst (registration and removal to the alternatives list)
- it will use the environment, a separate config dir, a C wrapper [pick one or all]
- the wrapper will check his argv[0], look at the config dir for the string to call and run it.

Probably even those 5 lines have conceptual bugs but I guess that's enough for a draft.

lu

I'll stay for about a month in Japan, till the latest I was too busy and not so sure I'd make it so I avoided blogging about this till I were sure.

Hopefully I'll have another great time hurrying from a city to another (Hiroshima and Sapporo will be the southern and northern cities I plan to visit) and I'm looking forward to meet the local gentoo community again (I never thanked you enough).

I'm not sure how I'll be able to get a reliable network link, but I think I'll find a way ^^.

You may already know that I have some complaints about pidgin:
- its developers use a brain damaged dvcs (yes monotone sucks, yet another application written in C++ that sucks after cmake)
- The ability to listen to the user feedback is severely reduced.

Since we are talking about alternatives looks like somebody tried to make things a little nicer and forked the code so far and made something fun out of that.

Seems promising, I hope it works well enough to be put on Gentoo soon if the pidgin devs don't come to their senses =P

I'm completely unhappy of the result of those elections, obviously I cannot tell it was unexpected (Idiots watching TV and believing are quite many) anyway today I'll write about alternatives.

You know that I consider cmake one of the worst item available if you want to get a build system sane. I know that people usin cmake won't use those alternatives, most of the time because they aren't that known, fashionable or with spiffy names.
My list
- linux (kbuild) or ffmpeg like systems (note, we need to find a name for it) since those are relatively hard to get working on new projects,
- quagmire seems to provide something you can use but is still its infancy, yet I'll give a stab at it.
- waf seems scons done right, still it lacks the completeness and ease you can archive using the autotools the right way (reusing the good .m4 bits from aclocal and not wasting time rewriting stuff every time)
- bitbake could make some windows oriented people happy while giving the rest of the world the tools expected, but maybe those people cannot stand an heavy known markup (xml based) while loving the cmake's one.
- autotools have the main issue that some part of them are either over engineered (libtool) or annoyingly broking from release to release (automake), still the most useful part now it's autoconf, but iff ffmpeg configure would be chopped into the right bits to be reusable w/out feeling the pain even it could be replaced with ease, recently I discovered dolt, a replacement for libtool that maybe could help a bit.

Right now if you want to build a project autotools, with all their defects and glitches, are the best all around. If you want to get something saner probably you may start looking at dolt and quagmire, if you want to do something for everybody you may start modularizing ffmpeg configure and makefiles or linux kbuild so everybody could enjoy it. In the middle I put other tools that look more or less useful but that for a reason or another I dislike a little.

In a perfect world we don't have people wanting to use microsoft visual studio to build opensource projects, every library would provide a pkg-config file with all we need to know to link against it, and every system has a identical way to build shared libraries (passing --shared to the compiler and linker?).

In a perfect world probably we won't witness human stupidity with a Berlusconi III (the government).

PS: The hunt to .la files is open, please try to remove them from your system and tell us if something must be fixed. The treasure trove about pkg-config files is opened too, if you find a library not exposing one please notify us and upstream possibly with a pkg-config for them ^^

Quick and easy task for this day: check which is the status of openwengo since seems that's the only client providing what skype does, at least in theory...

Part one, get the source - delivered from the site as a nifty .zip

- wget + unzip worked as should

Part two, build the beast.

- cmake! The worst build system since imake, sadly brought into the fashionable stuff because of KDE4,
Now we get something interesting, on a phenom you get:

qlop -tH cmake
cmake: 5 minutes, 12 seconds for 1 merges

A comparison:
perl: 3 minutes, 43 seconds for 1 merges
m4: 29 seconds for 1 merges
automake: 14 seconds for 3 merges
autoconf: 16 seconds for 2 merges
libtool: 44 seconds for 1 merges
make: 30 seconds for 1 merges
cmake: 5 minutes, 12 seconds for 1 merges

Using something less new makes the whole thing even more interesting. Let's say that to build something using cmake I need the 3/2 the time to build perl, just to start.

gentoo has an ebuild for it so it it's just getting it, (why cmake needs xmlrpc-c is a question I'll left unanswered...)

Now back to openwengo.

I have to create a build dir and run cmake from there, it obviously finds something wrong with ffmpeg even if supposedly it has its stale internal version (remind: ffmpeg changed the include paths some time ago) as fallback (no, you have to run cmake a first time, have it fail, run ccmake, find the right option and turn it on, start again).

I'm not sure if this brain damage is due wengo people or cmake, still I find this annoying. The *oh* so despised configure from autotools can be smarter and does not require that many lines if you know what you are doing...

It still doesn't take in account that there are different endianess for linux (autotools have a nice builtin for this...)...

Once the thing built (took a while), I just got more or less the same thing I got last time I tried it, looks like the 2.2 isn't quite up to date and they are working on the new mayor release =/

Back looking for other alternatives for skype =_=

Lately I started to test some stuff, after hammering openrc inside bsd jails I started to use it on my laptop, the ps3 and the new phenom I bought recently. So far I hadn't anything to complain but just minor glitches that got promptly addressed by Roy. With the help of the other testers and developer you'll get baselayout 2 soon and in a pretty good shape.

Feng and felix got quite an overhaul and hopefully I'll release them once I cleaned up the code:
- felix had lots of experimental stuff added and you may not want it nor look at it right now.
- feng is getting the eventloop reshaped so that you can understand what's doing w/out losing your sanity.

I'm still waiting for more SoC applications (in particular people willing to learn CELL seems fewer than we'd like) you have this week left to apply!

I'm again mentor, again for the same organizations (Gentoo and FFmpeg), with quite yet another batch of strange ideas and demanding tasks for you.

FFmpeg
With Benjamin Larsson and possibly Kristian Jerpetjøn help we are proposing some tasks about CELL that may be interesting for people that want to try to write something for a _quite_ particular architecture. On my own I took the idea of having swscale gpl bits reimplemented on lgpl to the next level, asking for someone to refactor the whole beast to something more sane.
more ...

Gentoo
Recently I found quite useful Wubi, the ubuntu install-from-windows-with-few-clicks application. There are times in which we do not have possibility to install from cd for a number of reason nor by other common means (network, usb storage, butterflies changing the upper ionosphere...) but we have another operating system already in place. The proposal for this summer is about preparing something on the line of debian.exe or wubi for windows or macosx.
Another task involves finding a way to make seemless for the user having pkgcore or paludis as PM, implementing an emerge workalike for them and a eselect module to switch it. The task may appear simple but can get as complex as possible if syncing configuration is put in the equation.
Something I'd wish to have is improve the cross compile support. I think a reasonable step would be having a target support for emerge and make sure emerge --target=foo-unknown-linux-gnu system does the right thing, but I'm still undecided about it.

I guess that's all about Summer of Code

gcc-4.3 seems to be released and I already started building it (right now spu-elf target being built while the powerpc64-unknown-linux-gnu quickpkg is being uploaded to the devspace for the people needing it). I got my alubook back and seems working fine, many thanks to
http://www.pixel.it/ for being that quick in fixing it. Now I'm waiting for the battery replacement and I should be more or less back on business.

The stuff I'm doing at LScube is shaping up nicely and I hope to have the next feng release, sporting the lighttpd and other major changes, out soon (It's nice to have shared configuration across services ^^. Soon I'll update the efika setup and I'll ask you to hammer it again ^^

Looks like the tibook I'm using while the alubook is hopefully being repaired is dying. I'm not exactly sure if the problem is due the disk or the controller, surely that is even more unexpected...

The alubook will be hopefully back in shape in a while (I won't believe till I have it back!)... Meanwhile I'm still thinking about what to get as workstation since this experience made me look for a workstation AND a newer laptop. I'm open to suggestions, right now I'm looking at a
phenom gear for the workstation and a laptop from enface.it

This http://www.enface.it/ita/octave150w.php looks nice for that pricetag, pity the lcd resolution is lower than the one I'm using right now (and it's a tibook! an older than 5 years laptop!). I like durable system, possibly with a decent batter life and that aren't too bulky... Anything you could suggest?

Sigh, I have no reason to overspend for an Apple since it now it doesn't provide an interesting powerpc and building my own laptop out of a powerpc current design could be a too costly exercise...

For a week or more I'll be less than present and active =/

Recently I happened to use the newest adium for few minutes (the time to erase my data from the macosx partition while I'm sending the laptop to repair (more on it once it is back, hoping it is back)

Adium probably is the best IM I ever tried, it works fine, in an unobtrusive way, it has all the gloss you may like (from none, to everything), but has just one defect: works just on macosx (that I don't like that much for developing since I'm not into BDSM).
Now, everybody and his dog knows that adium uses the fine libpurple from the pidgin project, and there is a pretty nice gtk client called pidgin that people usually use...
The problem is that seems that some of its developers spend too much time castrating the UI

http://developer.pidgin.im/ticket/4986

NEXT in row: have the chat window unresizable.

PS: no I won't try to hack pidgin, monotone sucks.

Lately I spent lots of time cleaning up lscube related stuff, mostly trying to hack together lighttpd features inside feng. I'm getting ready for the Internet Governance Forum meeting that we will webcast.

My laptops (both G4, one titanium and one aluminium) got their fan broken in a quite unpleasant way and I'm still wandering looking for replacement, maybe it's time to buy something else =_=
Lately I tried to look around and found some more or less nice laptops and even started thinking about getting a phenom system for home...

In the other news Seems that something would appear soonish at least as desktop... so maybe I could stay x86 free for a bit more ^^;

lu

Uberlord fixed the main issue I had in order to get gentoo/freebsd work in a jail: stop-start-daemon accessing /dev/mem and /dev/kmem

Now you can prepare your stage3, install openrc, dummify net and be happy in your nice jail =)

I must say that there are lots of issue here and ther in using FreeBSD with or w/out gentoo, but at least I'm getting a nice environment and got some issues fixed in the way.

ejabbed in Gentoo seems working almost fine while on FreeBSD there are weird issues that I couldn't understand at all, still diversity is the root of evolution.

A moral prize to the people that could guess what's wrong relevant part of the config

  {5222, ejabberd_c2s, [

                        %%
                        %% If TLS is compiled and you installed a SSL
                        %% certificate, put the correct path to the
                        %% file and uncomment this line:
                        %%
                        {certfile, "/usr/local/etc/ejabberd/ssl.pem"}, starttls,

                        {access, c2s},
                        {shaper, c2s_shaper},
                        {max_stanza_size, 65536}
                       ]},

relevant log message when you try to login

**      Data  == {state,#Port<0.367>,<0.374.0>,gen_tcp,"2667452897",
                        {sasl_state,"jabber","jabber.stuff",[],
                                    #Fun<ejabberd_c2s.1.132950982>,
                                    #Fun<ejabberd_c2s.2.53796002>,undefined,
                                    undefined},
                        c2s,c2s_shaper,false,true,false,false,
                        [{certfile,"/usr/local/etc/ejabberd/ssl.pem"}],
                        false,undefined,[],"jabber.bofh-land.net",[],
                        undefined,
                        {0,nil},
                        {0,nil},
                        {0,nil},
                        {0,nil},
                        undefined,undefined,undefined,false,none,[]}
** Reason for termination = 
** {{badmatch,{error,"SSL_CTX_use_certificate_file failed: error:02001002:system library:fopen:No such file or directory"}},
    [{ejabberd_c2s,wait_for_feature_request,2},
     {gen_fsm,handle_msg,7},
     {proc_lib,init_p,5}]}

relevant file that surprisingly doesn't seem to exist.

ls -al /usr/local/etc/ejabberd/ssl.pem
-rwxrwxrwx  1 ejabberd  wheel  1956 Feb  8 14:21 /usr/local/etc/ejabberd/ssl.pem

I started setting up some stuff on a jail I'm sharing with some friend, freebsd-6.2

- installing ejabberd is quite painless through the port (good)
- configuring it was alike gentoo (nice)
- having ejabberdctl working needed some tweaking (and learning what a cookie means for erl)

now, time to test the beast

- web stuff working as should
- connecting doesn't using tls ?!
-- trying on gentoo shown the same issue -> solution on gentoo: set proper perms to the ssl.pem and using absolute paths.
-- on freebsd that isn't working for unknown reason.

Time to play with gentoo on freebsd in a chroot inside a jail.

humor me plenty!

First of all I'm eventually snapshotting a newer ffmpeg, I'll need some help to get it play nice with all the other applications. The new ffmpeg has lots of improvements but it changes its api slightly so every application should update accordingly, time has passed so I hope upstream caught up with the change.

Once it will be unmasked I'll hopefully put the next release of feng in portage, currently I'm studying lighttpd internals in order to

• Have feng using the same lighttpd syntax for configuration
• Improve its behavior as server

So far I started importing lighttpd datatypes and lemon based parser directly in a separate branch and reshaping a bit feng in order to make it more rational. First thing learnt from lighttpd: keep everything in instance variables.

In the other news my alubook got its fan broken (and the tibook is in the same sorry shape), if you know where to find replacement parts for it please tell me (bonus if they aren't that pricey).

There are many ways to get an opensource project fit better your needs:

- you contribute to it by doing the missing bits yourself.
- you contribute to it by funding somebody so you get the bits done.
- you ask politely about those bits and you make a point on how those bits could be useful for the developers too (so they will use their time and skill to implement them)

There are also many ways to hinder an opensource project (trying and failing to have it fit better your needs):

- you assume you can lead who is doing since you are using what's done by them
- you assume that there is democracy and the fact "everybody"* want something (but the people actually doing something) makes that relevant
- you try to annoy people till they give in or give up.

* from interestingly inflated self made estimation

Let me give a bullet list about ways to contact developers:

- IRC: most developers are present on irc, you may query them, talk to them in the topic channels (e.g: #gentoo-media) or ask for voice in the #gentoo-dev channel. Irc logs may or may not be available for past digging.

- email: again you can either contact the developer privately using the ${nick}@gentoo.org email or using the mailing list (gentoo-dev, gentoo-project, gentoo-$topic), you may also read the archived discussions.

- jabber: we got IM too, you may again use ${nick}@im.gentoo.org to contact them directly.

Those are two way communication routes, you ask and you got replies, most of those let you have a nice log so you can even point past discussions for clarification. If someone disregard about you usually can voice it and it remains.

There are 1 and 1/2 way communication routes like blogs, it's up to the blog owner let the comment appear or not (so he could make like he got full support by everybody just silencing who isn't exactly keen on what's there).

There are even 1 way routes like the GWN and GMN in which the editor can write whatever he wants.

If you wonder why I'm just stating the obvious like this, well, seems that some people got a disconnected perception on how communication works so it's sorely required even if dead boring.

Seems that some of people started talking about issues, lots started to listen to them and whatever they said, other picked up blogposts and just wrote on them...

Fine and dandy, still I'm with tsunam and ferdy.

http://archives.gentoo.org/gentoo-dev/msg_150039.xml

We are alive and from what I could see the future isn't that dark on the technical side.

You probably know that I’m a fierce antagonist of anything that isn’t simple, that is over engineered or that is plainly ugly.

Now I’ll spend some lines of this rant^Wlog writing about how HAL is annoying, conceptually broken and ill conceived.

You may start thinking about other technologies that now are maturing in something nicer like dbus (even if could be lighter and faster) or udev, they improved a lot even if I would avoid force feeding ingenuous lambs (I mean people using linux and posix systems before and not yesterday windows converted users that really NEEDED that stuff NOW and that now appear to be the main target for opensource applications nowadays, see David’s post)
) with them.

Now, udev is good at reacting to hw events and dbus is good at passing messages, why something that should be just a little layer of glue between them has to be that complex?
Why it needs to have lots of square wheels reinvented, while we have perfectly round ones available for free?

Cardoe already voiced his frustration about it and I’m plainly not using it while I can, still I’d like to have something lighter, simpler, saner to notify userspace applications that something in the hardware changed, since the idea isn’t that stupid.

I started testing compiz and compiz fusion to keyword it ~ppc, that was my first experience with it...

- I don't use gnome and I hate gconf, I happen also not to use kde...
- Currently I'm using xfce to test compiz
- I have a more or less old xorg configuration

Here the pitfalls list:

X
- make sure you have DRI and AIGLX enabled: (Option "AIGLX" "True" in your ServerLayout in case you are wondering)
- add some options to your Device: Option "AddARGBGLXVisuals" "true" and Option "XAANoOffscreenPixmaps" "true"

compiz
- make sure that compiz-start script doesn't have gconf if you don't want it, otherwise the decorators won't show up.
- ccsm is quite a nice utility if you aren't using a full featured DE
decorators:
- emerald is the decorator you want, at least it allows some degree of configurability.

I think I won't use compiz right now since I'm not so fond of the effects, anyway it looks quite nice.

(once I get the cvs updated so I can keyword the stuff I'll mark most of it ~ppc)