libreoffice nsplugin will have to leave us

As time goes I spent quite time making the nsplugin work on 3.4 release. My fix was not optimal enough and it caused various regressions (like launching libreoffice everytime you launched browser and so on). In the end we managed to sort this out around 3.5beta2, it was a great shot, it worked perfectly with firefox-3.6 and we were happy.

But now with 3.5.4 it is building the plugin and it fail to register itself in the firefox-10 itself again. And with 3.6 release the plugin even fails to show up in the list of extensions in firefox.

As I never did working plugin for firefox I have no damn idea what is wrong in there. Same applies for the the rest of the developers whom don’t even care much about that extension. So if you are one of those who really like the idea of embedding your documents within browser and you understand (or at least want to work on) the plugins please poke me, or send me some patches right away. As of now you can grab even 3.5 code to hack on because the extension does not work anywhere.

Otherwise I will just drop the useflag from 3.6 on.

So you want me for council? – kinda manifesto

Looks like I was nominated for the council this year. It is quite tough decision for me wether to run for council again or not. Well to cut this summary short in the end I should have enough time if nothing special happens during the year and decided to try.

Lets take look on what are my ideas and why I should obtain dev votes (apart from that I already was in council and did not screw up too much) :-)

Stability and reliabilty

Most of the guys probably already noticed, but once again I have to say that I run stable tree. With this I have to say most developers treat stable tree as something ugly. This means that fixes get to the testing but never or always late to the stable.

I consider stable rolling-updates tree to be our main advantage over any other distro but the key here is to make it reliable and working. When I did the clean hardened install I ended up keywording lots of apps in order to make it work. Now the situation is better I hope. As I stable everything I need or packages which do not work up to my requirements, but still I want to work up some way how to make the stable our primary target (not that all devs should run stable, but stable should be around for our users and testing should be around for testers not final deployments).

We have many guys working in this area lately which also make things look shinier. Ago is stabling almost instantly insane amounts of packages (burnout candidate YAY :-P), PaweĊ‚ is running automated scripts (slightly controversal and I consider it still buggy and in its infant stages) that open stable bugs for mature enough software.

Furthermore I would like to put more work on poor arch testers (not all archs just first one who gets there probably) to actually check and clean ebuilds from cruft. Often when I was stabling stuff from not-well-handled category I ended up mostly redoing the ebuild to clear all the stuff (mostly the changes were trivial but benefitical in longer run) when commiting the stable keyword, resulting in better working ebuild in stable.

Last point for stabilisations is the current tool (bugzilla) is damn ineffective. But there won’t be any solution for that from me, I think there are more fit guys for this in our AT teams to find out solution for this.

Community involvement / getting the edge

On the other hand Gentoo is (and always was) about RICING. Without -OZOMGFAST in CFLAGS are our lifes more dull and gray.

We need more developers that is a real point. 250+- guys can’t manage the amount of ebuilds we have in good shape. We designed lots of automated tools to make our lifes easier but still it is not handling the growing numbers of packages in the tree.

With the git migration done (see point bellow) we should be in great&easy position to adapt new contributors whom do not even need developer status. They just need to use git commit and git format-patch to give us their improvements.

From my experience within Libreoffice comunity the model where users just mail their fixes to ml where they are sorted out and wether asked for improvements or merged to master (our case of testing tree) right away.

This should ensure proper ricing for everyone while with the AT stabilisation testing we should get proper testing and more ensuring testing.

Some people might say that we already have overlays, but I think they are cool for development of features, but not for simple fixes or just plain version bumps. Note that updating major piece of ponies like KDE requires overlay because each version is broken in its own and unique way ;-).


This must be on each manifesto :P Anyway this year it seems to happen regardless on what I do. We only lack the working git-svn with subversion-1.7.

So I expect myself to kick Theo to give me sitrep here and there to see it actually happen. I can be really annoying and he is really tiny.

Reducing supported arch targets

This point gets back to the stable one. With current bugzilla one can see that some arches take 1 year or so to stabilise some packages. This is more than suboptimal… I think we should start working on deciding which platforms we want to actually provide stable packages and which are running out and actually dying (ie is there and ppc32 hw sold in last 5 years).

This should reduce the time to finish stabilisation and make the main tree more up-to-date and slimer.

Final word

Well that should be it. I hope to achieve at least part of this and work on some ideas regardless of being elected :-)

June sitrep

Last month was quite stuffed on updates.

We managed to get out branch 3.6 for libreoffice, which is currently in non-buildable state due to bug in the gnumake handling which means no beta ebuilds in main tree until it is resolved. David Tardon is notified about the breakage and he hopefully fix it for us at some point :-)

Another thing that kept me busy was cups-filters build system rewrite. From apple mumbo in weirdly written raw Makefiles to nice autotools build system. It is already commited in their VCS and it will be present in next release. We also made it dependency of cups 1.6 which means the printing will continue to kinda work on Gentoo. My another evil plan here is to backport this to 1.5 series configurable by some useflag.

Also today I kicked my ass and did something for the dictionaries. Updated 8 of them to new eclass and proper versioning scheme. If you are lucky then you should have better dictionaries at the place, and if not you should waste some of your time and try to update the thing yourself. I hopefully included all the dicts that users reported to me with upstreams and download locations, if not just mail me again (the same apply if you want to give me new info on some dict).

And for last I took over managing Czech translations of XBMC on transifex and spent quite few hours fixing all the strings to match KDE translation memory. And this probably does bother like 0.001% of the Gentoo userbase…