Ok, we got a new council, I'm still there so thank you for renewing the trust on me =)

Looks like that less people found me or what I did that compelling to make me into the council, so surely I did something wrong. Solar got the first place so his cleanly cut ways are perceived better.

I started polling people about what they feel about Gentoo and what they'd like. The first thing I noticed is that people are sick of endless discussions on marginal stuff and even more sick of outside projects trying to push it's agenda on Gentoo using the shovel-in-throat way.

Second item is about trying to make the place nicer for everybody and better involve our large userbase. We used to be the nicest distribution regarding attitude towards newcomers and slow learner, now other distributions are better. We could re-learn from them.

That's what I perceived so far. As I said before I see the council just as the last resort to get something decided if we, developers, cannot find a large agreement. Solar likes more to be proactive in my opinion. You liked him so I guess we as council should try to push people express themselves and get new&interesting stuff done instead of discussing which is the new way to define a quantity next to infinity or why embedding information somewhere is right or wrong in theory.

That said, how wrong I am so far and how we could get Gentoo to improve even more?

There are many discussions about how Theora should be used and about how it smokes x264 somehow.

I do not believe it or at least I don't believe the proofs till I try myself.

Any of the Theora zealots reading could please provide a reproducible benchmark so everybody could see for themselves how good/bad Theora is?

A script that fetches the new theora encoder, ffmpeg, takes an original, produces two videos using theora and h264 (no audio), same bitrate for both and in the end outputs cpu and memory usage would be great.

I'm eventually back home, I'm dead tired, the c-base party was great in many ways (people, food, place) and ending the night (actually starting the morning) playing Go with beer and music was _quite_ fun (thanks again for the games =))

I'll try to wrap up everything in a short post before falling asleep completely: the LinuxTag had been a wonderful experience I had been more there as FFmpeg developer and less as Gentoo developer (mostly because I had to man the FFmpeg booth mostly since we aren't that many and that I failed to chat in a proficuous with the gentoo people even if we spent the evening in the same place most of the time =| In the end I had a refreshing conversation about Gentoo with rbu luckily and I managed to chat a bit more with fauli just before he was leaving...)

Was quite fun going at the end of the event to the fsfe stand to do explain the FFmpeg stance about patents, Theora (more will follow) and why, in our humble opinion at least, isn't correct to propose^Wactually shove down to the web users throat such codec just because of some claims that are yet to be validated...

The discussion was quite pleasant mostly because to my surprise fsfe people there weren't zealots, so the whole discussion discussion even evolved to touch more interesting topics, like reverse engineering, making sure our license is respected and actually multimedia, with a brief discussion on containers, codec and streaming (that part actually started from an explanation why Theora isn't that perfect fruit of opensource that is claimed and why Ogg has many
shortcomings as container and why in multimedia you do not have one-size-fit-all solutions... )

After about 4 years I eventually managed to get there! Today is the first day and I'm actually sort of manning the FFmpeg Booth and from time to time I could happen to be in the Gentoo one as well.

In the FFmpeg stand we are showing BBB high res in a big LCD screen from a small beagleboard. The operating system image is obviously Gentoo as well the other system present showing some jumpy Japanese idol video (not my idea).

See you! (Pictures will come later)

I do not have a paypal account.

I do have a credit card (AMEX) and I'm living in Italy.

Today I tried to setup an account and bind it to my card. I dislike localizations so the first thing I did was having it keeping the English language after I had to tell the system I'm Italian.
Well I registered and everything went smooth till the point of telling paypal the card I want to use...
I followed the links and... =_= Oh, my card isn't in the list...
Strange. Let's try to use the contact module to see what's wrong and... Oh, it says that it isn't available for "U.S. English", I should go to my preferences and switch it to Italian...

In the end apparently IF I'm Italian I cannot use AMEX...

Paypal sucks?

Last week I spend some time visiting some friends in Massa, a quite nice city near a quite nice seaside. It's all fine with sand, sea and the usual places where to relax. We went in a crepe and piadina shop, there we found the owner pretty depressed: he is thinking about closing the shop by the summer.

Though times you think, well no, Creppolo is quite known and lots of people gather there by the day and by the night, if you want to eat something tasty during the night and you are around there you'll probably end up there... So, why closing? Well apparently the municipality council/major doesn't like to have shops open the whole night (even if it's a tourist city in the seaside...) and decided that by 2AM every shop MUST be closed. Creppolo made most of its sells between midnight and 4AM.

That is pretty annoying since I liked that place and pretty annoying for all the other shops that sell stuff at night (there are many). I always appreciate the short-sightedness of the people elected by people.

Today it's an election day for the Europe, please make sure you don't miss this chance to vote somebody that won't spoil your hard work ^^

That's a follow up from Diego about somebody quite angry that went to vent a bit too much and got quite a backslash. Then he got also some issues with his blogging software hiding all the comments about his rant. Now things are more or less normal and you can read the comments again.

Given I'm the first using strong words about software I dislike (like cmake) I try to be ready to be proven wrong. Since that usually means that that either I got somebody planting some clues on me with the proper bat or things improve in the mean time, both cases usually I'm happy/happier to be proven wrong. Being wrong is something that may happen.

Now, I hope that what Matti and Boudewijn did was out of frustration, since I assume that after stupidity and before malice. If you release something it's YOUR FAULT if it's broken since YOU are the committer in your tree. Smearing other people to cover the fact YOU, too, messed up is plainly wrong...

Recently wesnoth got released and there is already an ebuild in portage.

Since upstream stated that autotools were being deprecated (actually some people come up to avoid that in the end) Mr_Bones crafted an ebuild using cmake.

Here some values:

build time for cmake -> 3.20m (take everything with at least some of variance)

build time for wesnoth using cmake -> 8.15m (again some more, some less depending on the runs)

build time for wesnoth using autotools -> 8.00m (again some less, some more depending on the runs)

my method is quite simple:
- first I fetch the sources and then build some times cmake and wesnoth 1.6a and use time to see how much it takes.
- then I use the older ebuild 1.4.7, remove the no-python from src_prepare since its unneeded, I call it 1.6a-r1 and then build some times that one as well.

Apparently cmake nearly add about 1/3 to the actual build time if you don't have it already installed (and you shouldn't) and compared to the autotools system it adds some time by itself.

In short people shouldn't use cmake if autotools are available.

Here a bullet list about doing benchmarks

• Reproducibility: your numbers worth nothing if nobody could reproduce them, so you have to give along them a script or a detailed description of what you did.
• Statistics: outliers and other artefacts may screw your results, make sure your script is run enough times
• Indices and values: if you want to proof something you need hard numbers possibly something everybody can understand easily and cannot be misunderstood: cpu cycles, time to complete, memory usage, are quite good, given you aren't testing on particularly different architectures or systems.

Quite short, isn't it? Still many people just state their values by inference (like "it ought to do 2x the syscalls thus should be twice slow"), or just tries to benchmark something that isn't what you want to test (like "glxgears is slower now, mesa is slower at rendering complex scenes") or have a quite different settings and configurations (think about having your application with a minimal configuration and the same one with a larger one)

Usually the best way to get a meaningful benchmark is preparing a script and give instructions about how to use (like which version of companion software are you using) and then provide the numbers (media with variance if you are inclined) and a summary of the system, this way others can play and try themselves. This is quite useful since the optimization you are working on may be great on gcc4.3 on PowerPC but be problematic on x86 with gcc-2.95.

Other times you want just people to compare something that is _quite_ influenced by the surrounding system or is annoying to setup, in those cases having a full system image is quite a boon, _everything_ could be the same. And given how easy is to use virtualization/emulation software nowadays it just take a bit of bandwidth.

During the last month we got many arguments about how fundamental was one or another change to portage and how this or that had been a life change for many users.

I'm talking about the whole discussion about glep54 and the following one.

When it was first proposed I found the glep lacking details and given that some people were vehemently against it I asked to have it updated. Since some other people found the idea of improving our support for live ebuilds as whole (not just the versioning) interesting I tried to gather ideas and put them all into a draft. The thing got quite big and covered many steps needed, most of them not detailed yet.

Basically the live template draft aims to have portage do the following:

- let you automatically merge from a specific live branch
- have emerge --fetch work as supposed introducing a phase just for that
- let you track what you installed and possibly re-install as is
- have a way to generate automatically snapshot ebuilds and binpkgs in a non ambiguous way
- some more (like have portage show you which revision and from which branch comes what you installed on emerge -upv)

Glep 54 just aim to make sure versioning is theoretically and thoroughly correct, no matter how crazy overlays, upstream and package maintainer could be. To make an example, right now if someone wants to provide a live ebuild he could prepare an ebuild with a large version value (say 9999) and assume nothing bigger would appear, version usually are small values like 1.2.3.
Now, nothing forbids to have a version that is, say, 10000, making invalid the assumption cat/pkg-9999 is the higher value. The glep54 comes with a solution for this issue, have a new prefix to state that he ebuild is live, thus has to be considered above all the others within it's range. This change has to be folded within a EAPI change or even better to a file extension change as stated in glep55 since it's as simple to state as radical: older portage, not knowing anything about what this prefix is, will issue a warning.

Installing from live sources is completely unsupported thus those ebuild are rightfully p.masked and their use is quite specific. The current amount of them is scarce: 90 on 26130 ebuilds are live.

So, if you got the question about if you'd approve this proposal and consider implementing that and all the changes due that would follow or just put it on hold till it would be more useful what would you do?

A pragmatic approach would either be either reject it since does pretty much nothing in the big scheme (0.003 is nearly nothing) a less pragmatic approach, due the tendency to thinker, would be just try to make it more useful so it could be of appeal to a wider interest...

Probably the same time would have been better spent on things that are more interesting like have a better way to state what a dependency is (if it is something I'll need to link to, something that I need to run) to ease the life of our embedded arches (say ppc, arm, sh, mips) or to fully support multislot and multiabi so we can avoid emul-linux on amd64 and have ppc64 being able to run xlc w/out many annoyances *cough*, or start thinking about how to enable pgo as widely as possible since it appears to make the difference in certain situations (e.g. firefox).

During August I was supposed to prepare something new for the LScube project.
I was supposed to do a bit more for the Summer of Code (Sorry Keiji and Seraphim) and the FFmpeg project (libswscale isn't yet in shape I know).

Sadly I spent about a month with a bad pneumonia and just now I'm starting to catch up really. (I hoped to stay better before but, as my 2 miss on council meetings shown, wasn't ok yet)

Diego is doing a wonderful job rationalizing LScube suite, Ale almost finished his Flux (started as a way to show me that C++ isn't the problem, just people misusing it), Michael decided to make libswscale the default in FFmpeg forcing more people taking care about it.

What now?

Well first I'll try to not miss new council meetings (and I'll ask Chrissy and Diego to back me up when happens I cannot be there).

I have some pending stuff about libswscale that will end up having a better structure to provide arch specific optimizations, once they hit I'll try to do again a witch hunt over ffmpeg using applications to provide the new libavcodec in portage.

Hopefully the next feng (and friends) release will hit portage and the stale fenice and libnemesi will be replaced accordingly ^^;

There is plenty of new stuff on the CELL land to be tried and provided (like mars)

I'll try to take some time to merge the openmoko patches to the new (and gcc-4 building) qemu so I won't have to provide an qemu-openmoko to help people interested in getting Gentoo on the freerunner (openrc could help a bit the boot time possibly and bitbake is a bit annoying from time to time)

Last but not least Syoyo is getting his blazing fast renderer Lucille to be usable even by common people.

Lots is happening (with and without me) =)

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

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 =/