Luca Barbato

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)

Lately I happened to read something that made me think, basically Miguel de Icaza stance on microsoft's pseudo xml format and microsoft's flash workalike.

He tried to remove some polarization we have on anything made by Microsoft and tried to compare in a less biased way the 2 spec AND flagship programs, most of the people could stop at the first part and get the message "ms stuff isn't that bad afterall" or even the "ms stuff has nice ideas here and there". I read it as in "there is MUCH work to do and ignoring them isn't productive", I'd add my point of view as in, instead of following them and doing their same errors or supporting their same horrors, we could just learn and try to do something different (and broken in different ways) starting for our own foundations and nothing that could be undermined by them?

Having a microsoft offerings workalike may be good for some, but since there are way better tecnologies out there waiting to be improved it's just a waste. (e.g. Vorbis, wavpack, mkv, nut, XUL, D, parrot, Dirac, snow, SVG...)

Anyway the nice thing of opensource is that everybody is free to do whatever he wants and usually sharing good ideas works in the end, if more people make usable/better tools more people will use them.

I had been busy doing my usual load of random stuff, most not completely gentoo related, some a bit more.

Let's start with the nicer ones: Marco spent lots of time and eventually it paid off, ffdirac now supports Iframes just fine, it's quite an important step! As mentor I hadn't to do much beside watching the evolution of the code and suggesting course of action. In the other news there is a new dirac spec released just today, probably some of the changes are due Marco's work =)
Today we tried to do some hackery to get git-svn play nice with the braindamage we have on the ffmpeg soc svn. Sadly my side works great, his side not (fetching from svn and pulling to an ffmpeg.git branch works, pushing back to svn not).

About the dirac project I must say that they started with the right frame of mind from day 0, I couldn't find a group more open to discussion and suggestion, no matter if were things like "It's wrong to implement dirac in C++, nobody would use it" or "the latex pdf output as you made it is unreadable. I hope to eventually have the time to get texlive working or find something that converts the tex files to docbook and provide a better pdf for them, really I cannot stand reading it for more than 5min... Now I hope this summer of code effort will lead to get a better dirac overall (and that eventually BBC will use it for streaming their fine contents, oh, did I mention that I have a student on my university that should work on getting dirac-rtp a reality? check LScube in the next month)

To sum up, I'm quite happy with this summer of code experience and I thank Marco again for being a great person to work with.

While we are at it some more informations about ffmpeg related efforts, I eventually hacked again a bit on roundup resulting in fixing/workarounding some problems with the email integration, if you happen to have some problems on ffmpeg please give it a try.

Beside that, my work at LScube is still going on, sucking lots of my time... Lately I tried to add more packetizers to feng but w/out much success, looks like my aac implementation is a *bit* wrong, usually relooking at it after a while helps me fixing the issue (as I did for h264) I hope to have it (and many more) completed for the next release. On the client side libnemesi is still waiting for more depacketizers while Alessandro is cleaning up the network stacks, making it less quirky.

Now I could speak of gentoo related stuff, I'm trying to fix some of the programs still using the img_* interface, since it is an annoying task I waited a bit hoping upstream would adapt... No reaction so far so I'm starting with something simple as blender and then hopefully move on other ones. What sucks about the img -> sws move is that sws is less commented, has quite ugly but performant code and it's a pain to hack on, I started to clean it up but then got sidetracked so there are still some patches waiting completion...

I guess this is a post long enough, probably I'll add another update tomorrow.