Follow Chromium-related blogs on planet.chromium.org

If you're interested in development of Chromium, there is one, new, very good place to look for news. It's http://planet.chromium.org/ and it aggregates info about releases, new features, and more.

www-client/chromium plugin incompatibilities

Recently some reports about plugins incompatible with Chromium appeared in the bugzilla, so this is a little explanation what to do in case you hit a problem.

First, Flash works just fine, so you don't have to worry about it. By the way, if you don't like Flash, I recommend this nice FlashBlock extension.

Some plugins are known not to work with Chromium. For example, gecko-mediaplayer may cause you some headaches. If any other plugin is misbehaving, please report it to the Gentoo Bugzilla.

Now you have two choices with plugins. By default Chromium package has USE="plugins-symlink" enabled, which will make it use the system-installed plugins by default, so that things can work out-of-the-box. With more recent versions of the package this USE flag will also prevent installation of known-incompatible plugins. The other choice is to disable "plugins-symlink" USE flag, and manage /usr/lib/chromium-browser/plugins (chromium) or /opt/chromium.org/chrome-linux/plugins (chromium-bin) manually. For the full story see http://bugs.gentoo.org/301911.

Stabilizing a package is a serious thing

I recently joined the x86 project, and I'm helping with marking packages as stable on that architecture.

Even in this short period of time, I've hit several things that prevented or delayed a package from becoming stable. I think it's a good idea to warn people before rather than after, so if you want your package to become stable, please watch out for any of these:

• unstable dependencies; just file bugs for these first
• failing tests; you should be running with FEATURES="test" all the time to catch these
• upstream considering the version experimental; why should we consider it stable then? There are exceptions to this rule however if older versions are unmaintained.
• open bugs for the package
• repoman warnings for the package, or QA concerns on manual ebuild inspection (like not calling die on emake failure)
• requiring the user to do manual configuration that could be instead performed automatically that if not done prevents the package from working completely

Additional note: if you know any issues about the package that might raise concerns of any of the arch teams, indicate so in the stabilization bug report.

One more note: does every minor version bump need to get stabilized?