You might remember that for a while I worked on getting quagga in shape in Gentoo. The reason why I was doing that is that I needed quagga for the ADSL PCI modem I was using at home to work. Since right now I’m on the other side of the world, and my router decided to die, I’m probably going to stop maintaining Quagga altogether.

There are other reasons to be, which is probably why for a while we had a Quagga ebuild with invalid copyright headers (it was a contribution of somebody working somewhere, but over time it has been rewritten to the point it didn’t really made sense not to use our standard copyright header). From one side it’s the bad state of the documentation, which makes it very difficult to understand how to set up even the most obvious of the situations, but the main issue is the problem with the way the Quagga project is branching around.

So let’s take a step back and see one thing about Quagga: when I picked it up, there were two or three external patches configured by USE flags; these are usually very old and they are not included in the main Quagga sources. It’s not minimal patches either but they introduce major new functionality, and they are very intrusive (which is why they are not simply always included). This is probably due to the fact that Quagga is designed to be the routing daemon for Linux, with a number of possible protocol frontends connecting to the same backend (zebra). Over time instead of self-contained, easily out-of-date patches to implement new protocols, we started having whole new repositories (or at least branches) with said functionalities, thanks to the move to GIT, which makes it too easy to fork even if that’s not always a bad thing.

So now you get all these repositories with extra implementations, not all of which are compatible with one another, and most of which are not supported by upstream. Is that enough trouble? Not really. As I said before, Paul Jakma who’s the main developer of the project is of the idea that he doesn’t need a “stable” release, so he only makes release when he cares, and maintained that it’s the vendors’ task to maintain backports. On that spirit, some people started the Release Engineering for Quagga, but ….

When you think about a “Release Engineering” branch, you think of something akin to Greg’s stable kernel releases, so you get the latest version, and then you patch over it to make sure that it works fine, backporting the new features and fixes that hit master. Instead what happens here is that Quagga-RE forked off version 0.99.17 (we’re now to 0.99.21 on main, although Gentoo is still on .20 since I really can’t be bothered), and they are applying patches over that.

Okay so that’s still something, you get the backports from master on a known good revision is a good idea, isn’t it? Yes it would be a good idea if it wasn’t that … it’s actually new features applied over the old version! If you check you see that they have implemented a number of features in the RE branch which are not in master… to the result that you have a master that is neither a super-set nor a sub-set of the RE branch!

Add to this that some of the contributors of new code seems to have not clear what a license is and they cause discussion on the mailing list on the interpretation of the code’s license, and you can probably see why I don’t care about keeping this running, given I’m not using it in production anywhere.

Beforehand I was still caring about this knowing that Alin was using it, and he was co-maintaining it … but now that Alin has been retired, I’d be the sole maintainer of a piece of software that rarely works correctly, and is schizophrenic in its development, so I really don’t have extra time to spend on this.

So to finish this post with a very clear message: if you use Gentoo and rely on Quagga working for production usage, please step up now or it might just break without notice, as nobody’s caring for it! And if a Quagga maintainer reads this, please, please start making sense on your releases, I beg you.

1. UNIX permissions work normally. If UNIX permissions deny access, SELinux rules are not checked. Access is just denied, as expected. SELinux rules can result in more denials, but can never allow more than UNIX permissions.
   
2. Permissive mode is really useful. In that mode the denials are only logged, not enforced. The system should work as usual, and you have chance to note and fix eventual problems. You can actually switch between permissive and enforcing on the fly (setenforce 1, setenforce 0), so you can experiment whether things would work in enforcing mode and quickly switch back otherwise.
   
3. Targeted policy is recommended for desktop systems. It's part of general advice to "start small", but desktop systems have many more available applications anyway. Usually servers are minimal installations, so it's easier to write complete strict policy for them. Targeted SELinux policy uses unconfined_t context by default, which has no restrictions at all. Only selected applications have a specific policy just for them.
   
4. You don't need to worry about SELinux users with targeted policy. Another part that makes SELinux more complicated is that normal Linux users are mapped to SELinux users. This is important when using strict policy, but with the targeted one everyone is just mapped to unconfined_u.
   
5. Most access decisions are made based just on the type. Usual SELinux context, e.g. unconfined_u:object_r:user_home_t may seem quite complicated. However, corresponding allow rule would most likely only need to mention the type, i.e. user_home_t (to be precise, two types: types of the object and type of the subject).
   
6. Many confusions are just matter of vocabulary. For example, there is no practical difference between domain and type (source). My understanding is that domains are types used to confine processes, so every domain is a type, but not every type is a domain.
   
7. Allow rules are actually pretty simple. For example "allow example_t self:process execmem;". Ignore the syntax, the meaning of each rule is really straightforward, and I think it's no different with alternative MAC (Mandatory Access Control) implementations. And when writing a policy for specific domain (in this case example_t), all of the rules are going to start with "allow example_t ...".

As summary says in Gentoo you can finally decide which implementation of libav you want, good old ffmpeg named flavor or the new and shiny libav one.

14 months after I introduced it to main tree we finally got it stable almost everywhere (just ppc missing yet as usual :P). We did *censored* of work in order to support both implementations, introducing virtual package, proper (non-conditional) patches everywhere, etc. etc.

So why should you switch your package?

Basically it does not matter for you. We can say it can be done as personal prefference.
We can say that ffmpeg merges from libav tree and throws some experimental patches over it. Thats why my personal prefference is with libav folks as I don’t trust any idea of merging anything. Otoh the ffmpeg is the “orginal” (well most devs moved under libav) upstream thus they should get our trust for what they are doing.

Today from the distro PoV there are some distributions using libav (Debian, Sabayon) and also ffmpeg (openSUSE [external repo called packman]).

As we in Gentoo really are pro-choice just pick yourself and let us know how happy are you with such decision :-P

So how can I switch?

Just edit /etc/portage/package.use* to keep same useflag from media-video/ffmpeg to media-video/libav and run:

emerge -C ffmpeg && emerge -1v libav

After this move you need to recompile all the packages depending on ffmpeg. This can be done with little help of revdep_rebuild or by using portage-2.2 and its sets by running:

emerge @preserved-rebuild

packages that hard require media-video/ffmpeg

As reported in the first comment the mplayer1 does now strictly require ffmpeg. So I did a little check to see which packages hard-require the other implementation and here is the list:

games-arcade/performous-0.6.1 (media-video/ffmpeg)
media-libs/ffmpegsource-2.16.2.1_pre587 (>=media-video/ffmpeg-0.9)
media-libs/mediastreamer-2.3.0-r1 (video ? media-video/ffmpeg)
media-plugins/audacious-plugins-3.0.3 (ffmpeg ? >=media-video/ffmpeg-0.7.3)
media-plugins/audacious-plugins-3.1 (ffmpeg ? >=media-video/ffmpeg-0.7.3)
media-plugins/audacious-plugins-3.1.1 (ffmpeg ? >=media-video/ffmpeg-0.7.3)
media-plugins/audacious-plugins-3.2 (ffmpeg ? >=media-video/ffmpeg-0.7.3)
media-plugins/audacious-plugins-3.2.1 (ffmpeg ? >=media-video/ffmpeg-0.7.3)
media-plugins/audacious-plugins-3.2.2-r1 (ffmpeg ? >=media-video/ffmpeg-0.7.3)
media-plugins/mediastreamer-x264-1.1.7 (media-video/ffmpeg)
media-plugins/mediastreamer-x264-1.3.3 (media-video/ffmpeg)
media-video/dv2sub-0.3 (kino ? media-video/ffmpeg)
media-video/mplayer-1.0_rc4_p20120213 (>=media-video/ffmpeg-0.10)
media-video/mplayer-1.0_rc4_p20120405 (>=media-video/ffmpeg-0.10.2)
media-video/mplayer-9999 (>media-video/ffmpeg-0.10.2)
media-video/transcode-1.1.5-r2 (postproc ? media-video/ffmpeg)
net-libs/opal-2.2.11 (>=media-video/ffmpeg-0.4.7)
net-libs/opal-3.6.8 (ffmpeg ? >=media-video/ffmpeg-0.5[encode])
                    (x264 ? >=media-video/ffmpeg-0.4.7)
net-libs/opal-3.6.8-r1 (ffmpeg ? >=media-video/ffmpeg-0.5[encode])
                       (x264 ? >=media-video/ffmpeg-0.4.7)
net-libs/openh323-1.18.0 (>=media-video/ffmpeg-0.4.7)

I bet most of these could work with libav, so if you are user of such package and want to try libav just edit the dependency to be on virtual/ffmpeg instead of the media-video/ffmpeg and see if it works.

Parallel build, and parallel install, is not hard, in the sense that it usually doesn’t give you new, undocumented challenges; it actually seems to be repeating the same problems over and over again. Sometimes the exact same problem — as it seems Ruby upstream applied the stupid Funtoo patch instead of mine, and that made it fail again on a parallel install. Luckily I was able to fix it again for good, and now is sent to the ruby-core mailing list.

Another issue came up today, when I noticed a bug for OpenSC which turned out to be a parallel install failure. While Michelangelo’s quick fix is actually a smart way to deal with it quickly, I’ve preferred applying the correct fix, which I also sent to the opensc-devel mailing list.

So this is just a quick post to remember you all: if you see failures such as “file already exists”, remember you’re in front of a parallel install failure, and you can see my previous blog to understand how to fix it properly.

While I’m still trying to figure out how to get the logs analysed for the tinderbox, I’ve been spending some time to work on Gentoo’s Ruby packaging again, which is something that happens from time to time as you know.

In this case the spark is the fact that I want to make sure that my systems work with Ruby 1.9. Mostly, this is because the blog engine I’m using (Typo) is no longer supported on Ruby 1.8, and while I did spend some time to get it to work, I’m not interested in keeping it that way forever.

I started by converting my box database so that it would run on Ruby 1.9. This was also particularly important because Mongoid 3 is also not going to support Ruby 1.8. This was helped by the fact that finally bson-1.6 and mongo-1.6 are working correctly with Ruby 1.9 (the previous minor, 1.5, was failing tests). Next step of course will be to get them working on JRuby.

Unfortunately, while now my application is working fine with Ruby 1.9, Typo is still a no-go… reason? It still relies on Rails 3.0, which is not supported on 1.9 in Gentoo, mostly due to its dependencies. For instance it still wants i18n-0.5, which doesn’t work on 1.9, and it tries to get ruby-debug in (which is handled in different gems altogether for Ruby 1.9, don’t ask). The end result is that I’ve still not migrated my blog to the server running 1.9, and I’m not sure when and if that will happen, at this point.. but things seem to fall into place, at least a bit.

Hopefully, before end of the summer, Ruby 1.9 will be the default Ruby interpreter for Gentoo, and next year we’ll probably move off Ruby 1.8 altogether. At some later point, I’d also like to try using JRuby for Rails, since that seems to have its own advantages — my only main problem is that I have to use JDBC to reach PostgreSQL, as the pg gem does not work (and that’s upsetting as that is what my symbol collision analysis script is using).

So, these are my Ruby 1.9 pains for now, I hope to have better news in a while.

That’s right, it’s finally out! Thanks go out to all our contributors for the great work (there’s too many — see the shortlog!). The highlights of the release follow. Head over to the announcement or release notes for more details.

• Dynamic sample rate switching by Pierre-Louis Bossart: This makes PulseAudio even more power efficient.

• Jack detection by David Henningsson: Separate volumes for your laptop speakers and headphones, and more stuff coming soon.

• Major echo canceller improvements by me: Based on the WebRTC.org audio processing library, we now do better echo cancellation, remove the need to fiddle with the mic volume knob and have fixed AEC between laptop speakers and a USB webcam mic.

• A virtual surround module by Niels Ole Salscheider: Try it out for some virtual surround sound shininess!

• Support for Xen guests by Giorgos Boutsiouki: Should make audio virtualisation in guests more efficient.

Special thanks from me to Collabora for giving me some time for upstream work.

Packages are available on Gentoo, Arch, and probably soon on other distributions if they’re not already there.

It’s now over two months ago that I landed in the US with the idea of doing my job, do it well, and then consider moving here if the job was right. And two months ago I wrote about some stupid limitations of services based on where you were when you registered.

Now, even though I’m not here stable yet, I’m getting there: I have a bank account and a check card, and I have some billing address that I can use. So finally for instance I got access to Amazon’s App Store, which is not enabled even if you’re paying for Amazon Prime, as long as you don’t set your primary form of payment to a credit card (and address) in the US.

This should be easy, shouldn’t it? Not really; as it turns out, once I switched that around, Amazon stopped letting me buy Italian Kindle books…. which sounds silly given that they let me buy them before, and I haven’t removed my Italian credit cards, just not set them as default! Furthermore I’m not stopped from accessing them if I had them before.

The absurdities don’t stop here though; since I now have a check card in the US, I moved my iTunes Store account over… this actually enabled a few more functionalities, such as the “iTunes in the Cloud” and the fact that I can now re-download my purchased music as well as Books and Apps (which is the only two items that can be re-downloaded in Italy), but on the other hand, it threw off the previous purchases, showing all my purchased Apps as not available. While I was neither expecting nor hoping that my previous music purchases were available, I was pissed by the fact that it asked me to purchase again the software, especially things like TeamViewer, which is quite expensive. Luckily Apple’s tech support solved the issue relatively quickly.

So there you move to Android Market Google Play, that actually enabled me access to the US software simply by popping in the AT&T SIM card… well, while they did enable access to the US software, they still thought better to keep me off the Google Play Music store, as I was still registered in Italy. And while at it, when I actually purchased an App there… it ended up being charged in euros instead of dollars — this might sound strange, but it means that you pay more for it simply because the bank is going to ask you extra money for the currency exchange. Technically, the MII should tell them which currency the card is using by default, but instead of relying on that, they rely on your billing address… which they also don’t validate against the bank (as Newegg does instead).

Oh well… at least things seem to be more or less sane by now: most of the Italian books I had in my Amazon wishlist are available through the publishers’ group webshop which also provide most of them without DRM. Looks like Amazon is making it much nicer for everybody to buy eBooks now. Not all of them of course, but it’s still a step in the right direction.. and at the same time I’m very happy with buying them on the Kindle if I’m on the go, as I’m sure they are not going to kick me in my balls like Kobo did with The Salmon of Doubt (which I’m currently reading, after buying it again).

As I am rather new to the use of Mercurial it took me a bit of time to find an equivalent to Git’s

# git config --global user.name .....
# git config --global user.email .....

earlier today. The answer is editing ~/.hgrc like

[ui]
username = First Last <mail@example.org>

as I learned here eventually.

I should have learned it from the Command equivalence table, though.
So I have added an entry myself now to speed up whoever runs into that problem next.

As from today we have new app-officeext category that will be holding various office extensions. You all for sure know that when I say office I mean libreoffice/openoffice extensions. This means that we can now easily add new and shiny ones if you desire so. Please open bugs for your favorite extensions and we will ship them ASAP (also prefferably open stable requests for the current ones so I don’t have to remember to do it :P).

You might be able to find some fancy extensions there already that might help you improve your workflow with libreoffice.

Here is the list I will do this afternoon as they are part of the libreoffice core we never bothered to provide yet:
google-docs ; barcode ; diagram ; hunart ; numbertext ; oooblogger ; typo ; validator ; watch-window ; ct2n (requres two patches from lo tree -> repack).

Apache Office 3.4 released

From other news there is now openoffice 3.4 release made by folks from Apache Foundation. Gentoo will not package this release as it is basically equal to what we would call libreoffice-3.4.1 with some missing features and lacking all the build fixes that were put in lo-3.4.

But by the Gentoo here I just mean that I am epically lazy to solve again all the build issues 3.3 had. So if anyone is willing to maintain and package it we will gladly add it to the main tree (with the named person as maitnainer). You don’t even have to be a developer, there is a nice proxy-maintainer project so poke me mail if you are interested.

What we could also do is to add hardmasked binary version.That stuff contains security issues and is basically the same like old libreoffice/openoffice binaries which tried to contain everything from python to icu. Also for this someone interested is required. So mail me/comment here.

Dictionaries

There will be progress when I find some more time. New simpler eclass for myspell (actually hunspell) dictionaries is in place and I just need to check and verify all the releases. For this I got nice script from Caolan McNamara (LO guy working for Redhat) that contains upstreams and versioning schemes for most of the languages.

This will also be used with utilizing the euscan tool writen by Corentin Chary to watch for newer versions. Where I will also try to bump those with compatible licensing directly in dictionaries repo of libreoffice so you will be able to enjoy the spellchecking even on fancy platforms that none sane would use (riiiight? :-P).

cups dependency

Lots of you lads whined^Wcomplained about the fact cups is actual hard dependency now in libreoffice. With help of one brave lad (Dave Flogeras) we managed to bake configure switch for cups again. It is currently under review on libreoffice mailinglist (not really it already passed and I was just lazy to commit it in which I will do this afternoon). After it is included our live ebuild will again have switch to disable printing completely.

Internal lo extensions

Libreoffice itself has some internal extensions that are built as part of the build process. In history those were never built, or always built, depending on the complexity of their deps.

This now changes. There is new LIBREOFICE_EXTENSIONS use expand variable that can be used same way like VIDEO_CARDS in make.conf.

All of the extensions are already in except reportbuilder, because I was unable to find some java packages (I mailed java team for help here so those hopefully will be identified soon).

If you are interested in contributing to libreoffice consult various comments I put in the live ebuild as I am too sexy^Wlazy to open easy hacks on freedesktop bugzilla. Any help wrt unbundling stuff is welcome. Currently there is even problem with building javascript engine interface because bundled rhino uses too patched debug interfaces (one can either remove it or make work on the currently provided one) so if you like javascript and java you can have fun.

Hi all,

After some months of people asking me to update the documentation of the pandaboard, i’ve finally done it. The previous documentation was a bit outdated since the Pandaboard ES came into scene.

The problem was on the bootloader part, which didn’t work because they stopped developing X-Loader and integrated it to U-Boot. With an updated U-Boot this problem is solved.

Also on the drivers part, ubuntu released ubuntu 12.04, precise pangolin, with updated packages for the graphics part and a new kernel version. I follow whats stable on ubuntu, so if there’s some problem one could reproduce it with ubuntu and then complain to ubuntu developers After all, TI developers don’t get paid to support Gentoo but to support Ubuntu…

Anyway, ubuntu 12.04 switched from softfp toolchain to hardfloat toolchain(which Debian and Ubuntu call armhf), this means that the graphics drivers which are closed-source must have their binary blobs+libraries built as hardfloat. This means that if you want to use the new versions, you must reinstall your system with a hardfloat stage3…

More on the graphics part…until now since some libraries provided by the package collided with the ones from mesa, i had to remove them. Thanks to lu_zero, eselect-opengl now supports dynamic switching of those libraries, however i still have to fix the ebuild to use this new function.

The new guide is here: http://dev.gentoo.org/~armin76/arm/pandaboard/install.xml … its the same link as the older one

I’d like to thank to the different people that reported me what they had to do to make it work with the Pandaboard ES, since i don’t have one. Thanks!

Just a very quick paragraph on a just-reported issue: if you upgrade your SELinux utilities to the latest version and you switch from /selinux to /sys/fs/selinux as the mountpoint for the SELinux file system, you might get into issues. Apparently, init (which is responsible for mounting the SELinux file system through a call to libselinux) is trying to mount it on – well yes – /sys/fs/selinux but at that time, /sys is not mounted yet.

I haven’t been able to reproduce just yet, because I just recently had to move all my systems to use an initramfs (thank you you-need-an-initramfs-when-you-have-a-separate-usr-partition) which premounts /sys. But the current workaround should be to keep /selinux for now. The utilities support it still, and that gives me some time to look and investigate the issue.

Derek Foreman has finally written up a nice blog post about his Androgenizer tool, which we’ve used for porting PulseAudio, GStreamer, Wayland, Telepathy and most of their dependencies to Android.

If you’ve got an autotools-based project that you’d like to build on Android, whether on the NDK or system-wide this is really useful.

It’s been a while since I last wrote about parallel building. This has only to do with the fact that the tinderbox hasn’t been running for a long time (I’m almost set up with the new one!), and not with the many people who complained to me that spending time in getting parallel build systems to work is a waste of time.

This argument has been helped by the presence of a --jobs option to Portage, with them insisting that the future will have Portage building packages in parallel, so that the whole process will take less time, rather than shortening the single build time. I said before that I didn’t feel like it was going to help much, and now I definitely have some first hand experience to tell you that it doesn’t help at all.

The new tinderbox is a 32-way system; it has two 16-core CPUs, and enough RAM for each of them; you can easily build with 64 process at once, but I’m actually trying to push it further by using the unbound -j option (this is not proper, I know, but still). While this works nicely, we still have too many packages that force serial-building due to broken build systems; and a few that break in these conditions that would very rarely break on systems with just four or eight cores, such as lynx .

I then tried, during the first two rebuilds of world (one to set my choices in USE flags and packages, the other to build it hardened), running with five jobs in parallel… between the issue of the huge system set (yes that’s 4.24 years old article), and the fact that it’s much more likely to have many packages depending on one, rather than one depending on many, this still does not saturate the CPUs, if you’re still building serially.

Honestly seeing such a monstrous system take as much as my laptop, which is 1/4 in cores and 1/4 in RAM, to build the basic system was a bit… appalling.

The huge trouble seem to be for packages that don’t use make, but that could, under certain circumstances, be able to perform parallel building. The main problem with that is that we still don’t have a variable that tells us exactly how many build jobs we have to start, instead relying on the MAKEOPTS variable. Some ebuilds actually try to parse it to extract the number of jobs, but that would fail with configurations such as mine. I guess I should propose that addition for the next EAPI version… then we might actually be able to make use of it in the Ruby eclasses to run tests in parallel, which would make testing so much faster.

Speaking about parallel testing, the next automake major release (1.13 — 1.12 was released but it’s not in tree yet, as far as I can tell) will execute tests in parallel by default; this was optional starting 1.11 and now it’s going to be the default (you can still opt-out of course). That’s going to be very nice, but we’ll also have to change our src_test defaults, which still uses emake -j1 which forces serialisation.

Speaking about which, even if your package does not support parallel testing, you should use parallel make, at least with automake, to call make check; the reason is that the check target should also build the tests’ utilities and units, and the build can be sped up a lot by building them in parallel, especially for test frameworks that rely on a number of small units instead of one big executable.

Thankfully, for the day there are two more packages fixed to build in parallel: Lynx (which goes down from 110 to 46 seconds to build!) and Avahi (which I fixed so that it will install in parallel fine).

Some of you might’ve noticed that there has been a bunch of work happening here at Collabora on making cool open source technologies such as GStreamer, Telepathy, Wayland and of course, PulseAudio available on Android.

Since my last blog post on this subject, I got some time to start looking at replacing AudioFlinger (recap: that’s Android’s native audio subsystem) with PulseAudio (recap: that’s the awesome Linux audio subsystem). This work can be broken up into 3 parts: playback, capture, and policy. The roles of playback and capture are obvious. For those who aren’t aware of system internals, the policy bits take care of audio routing, volumes, and other such things. For example, audio should play out of your headphones if they’re plugged in, off Bluetooth if you’ve got a headset paired, or the speakers if nothing’s plugged in. Also, depending on the device, the output volume might change based on the current output path.

I started by looking at solving the playback problem first. I’ve got the first 80% of this done (as we all know, the second 80% takes at least as long ;) ). This is done by replacing the native AudioTrack playback API with a simple wrapper that translates into the libpulse PulseAudio client API. There’s bits of the API that seem to be rarely used(loops and markers, primarily), and I’ve not gotten around to those yet. Basic playback works quite well, and here’s a video showing this. (Note: this and the next video will be served with yummy HTML5 goodness if you enabled the YouTube HTML5 beta).

(if the video doesn’t appear, you can watch it on YouTube)

Users of PulseAudio might have spotted that this now frees us up to do some fairly nifty things. One such thing is getting remote playback for free. For a long time now, there has been support for streaming audio between devices running PulseAudio. I wrote up a quick app to show this working on the Galaxy Nexus as well. Again, seeing this working is a lot more impressive than me describing it here, so here’s another video:

(if the video doesn’t appear, you can watch it on YouTube)

This is all clearly work in progress, but you can find the code for the AudioTrack wrapper as a patch for now. This will be a properly integrated tree that you can just pull and easily integrate into your Android build when it’s done. The PA Output Switcher app code is also available in a git repository.

I’m hoping to be able to continue hacking on the capture and policy bits. The latter, especially, promises to be involved, since there isn’t always a 1:1 mapping between AudioFlinger and PulseAudio concepts. Nothing insurmountable, though. :) Watch this space for more updates as I wade through the next bit.

For those who wonder why Excelsior is now built for a week and it’s still not running in full capacity, the reason is relatively simple: I’m still trying to figure out how to handle network security so that I can give other developers access to it, and not risk that we have a security breach in other places.

The first problem is that the current setup I need to use and the final one will be very different: right now the system is connected to the internal network of my employer, while in production it will be DMZ’d, with a public IP available straight to it. The latter setup will let me set up an IPv6 tunnel, which means all the internal containers will be available by themselves, while the current one prevents me to set it up at all.

Previously this was much easier to deal with simply because I had control over an external firewall myself, which took care of most of the filtering, which combined with LXC networking options made it decently easy to deal with. Unfortunately this time I have to do without this.

One of the things that might not be obvious from the post above, nor from the documentation, is that the three setups I have drawn are the ones that require the least amount of configuration on the host-side: if you use the standard bridge, you just need to start net.br0 (or equivalent), and LXC will connect the host-side virtual Ethernet pair to the bridge by itself. If you’re using the MACVLAN modes instead, the containers will piggy-back the interface of the host, and then rely on the external router/firewall/switch to deal with the configuration — by the way I’m glad that man lxc.conf now actually says that you’re supposed to have a reflective switch to use those modes. You can probably guess it’s not that great an idea if you expect lots of internal communication.

What I’m going to do for now is setting up a system that is defended as much as possible by depth, with iptables carrying out enough filtering that I should be realistically safe. Unfortunately just iptables is not enough and what you need is iptables and ebtables (for Ethernet Bridging filtering), to make sure that the containers’ don’t dupe your IPs or something.

The idea is that one IPv6 is enabled, you can jump straight into the tinderboxes, which is required to control it, but until then, the host system acts as a jump host through a custom scponly setup, which only allows forwarding, as ProxyCommand, port 22 of others boxes within that same system.

I’d like to show more documentation of what I’m trying to do, and what I achieved already, but to do so, I’m afraid I’ll be needing some more … visual examples, as it’s very hard to explain it in words, while it should be much more clearer with a series of drawings. I guess I’ll start working on them soonish, maybe if Luca can package Synfig for me…

For now, this is enough, I guess.

Today I’ve stabilized the sec-policy/selinux-* packages that provide the 20120215 “series” of SELinux policies. Together with the stabilization, the more recent userspace tools (like the policycoreutils as well as libraries like libsemanage and libselinux) have been pushed out as well. I will be dropping the older policies and userspace tools soon (as they are now deprecated). The documentation has been updated to reflect this too.

Some of the enhancements include
• support for permissive domains (allowing users to mark one specific SELinux domain, such as mplayer_t, as permissive (even though the rest of the system is running in enforcing mode)
• support for file context translations, so we can now say “/usr/lib64 (and below) should have the same contexts as /usr/lib”
• support for role attributes, which means for policy developers, we now have similar freedom as with type attributes
• support for named file transitions, so a policy rule can say that domain A, if creating a file in a directory labeled B, then that specific file should have label C. Same for directories, btw.

Although some of these enhancements were available as features individually, the policies we had were not aligned with it – and now, that has changed ;-)

Okay so Excelsior is here, and it’s installed, and here starts the new list of troubles, which seems to start, as usual, with my favourite system ever: LXC which is the basis the Tinderbox work upon.

The first problem is not strictly tied to LXC, but one of the dependencies required: the lynx browser fails to build in parallel if there are enough cores available (which there certainly are here!). This bug should be relatively easy to fix but I haven’t had time to look into it just yet.

A second issue came up due to the way I was proceeding to do the install, outside of office hours, and is that the ebuild is using the kernel sources, I think to identify which capabilities are available on the system. This should be fixed as well, so that it checks the capabilities on the installed linux-headers instead of the sources, which might not be the same.

The third issue is funny: Excelsior is going to use an hardened kernel. The reason is relatively simple to understand: it’s going to run a lot of code of unknown origins, it’ll allow other people in, one wants to be as as possible… unfortunately it seems like this is not, by default, a good configuration to use with LXC.

In particular, grsecurity is designed by default to limit what you can do within a chroot, by applying a long list of restrictions. This is fine, if not for the fact that LXC also chroots to start its own set up process. I’m now fixing the ebuild to warn about those options that you have to (or might) want to disable in your GrSec setup to use LXC.

Interestingly, it’s not a good idea to disable all of them, since a few are actually very good if you want to use LXC, such as the mknod restriction, which is very good in particular if you want to make sure that only a subset of the devices are accessible (even when counting in the allowed/non-allowed access of the devices cgroup).

In particular, these have to be disabled:

• Deny mounts (CONFIG_GRKERNSEC_CHROOT_MOUNT)
• Deny pivot_root in chroot (CONFIG_GRKERNSEC_CHROOT_PIVOT)
• Capability restrictions (CONFIG_GRKERNSEC_CHROOT_CAPS)

while the double-chroot would be counter-synergistic as it would disallow services within the container to further chroot to allow a defense-in-depth approach.

Then there is another issue. Before starting to set up the actual tinderbox, I wanted to prepare another container, which is the one I’ll be using for my own purposes, including bumping of Ruby packages and stuff like that. Since the system is supposed to stay very locked down, this time I want to mount the block device straight into the container, which is a supported configuration…. but it turns out that the configuration parser, trying to workaround old issues (yes that’s a one and a half years’ old post) will ignore any mount request that doesn’t have the destination rootfs prefixed.

Unfortunately when you mount a block device, it means that you’ll end up with something along the lines of /dev/sdb1/usr/portage. This also collides with the documentation in man lxc.conf:

If the rootfs is an image file or a device block and the fstab is used to mount a point somewhere in this rootfs, the path of the rootfs mount point should be prefixed with the /usr/lib/lxc/rootfs default path or the value of lxc.rootfs.mount if specified.

Anyway this should be fixed in 0.8.0_rc2-r2 which is now in tree, I’ve not been able to test it thoroughly yet, so holler at me if something doesn’t work.

Glad to see that libbash is accepted by Google Summer of Code this year. Congratulations to André Aparício! Petteri and I will both mentor this project during the summer. Before GSoC begins, I’d like to explain the current status of this project.

I worked on this project in GSoC 2011. After the summer ended, I spent months seeking a job so I didn’t pay much attention to the project at that time. And later, I made several commits to the project and it’s looking better.

So far, we can generate correct metadata for 13849 ebuilds (5435 more than before). Nearly half of the ebuilds in the main tree can be handled by libbash now. So the goal of this year’s GSoC is to make libbash be able to handle the rest of the ebuilds.

What’s stopping us from handling more ebuilds? There are several eclasses that our grammar file can not parse. That means any ebuild that inherits from these eclasses can not be handled by libbash. On the other hand, the runtime part is not fully implemented, which is due to lack of grammar support or low priority. I have to say it’s hard to tell all the problems we are facing at once. I have been working in this pattern for quite some time:
1. Use our implementation of instruo to generate metadata for the ebuilds in the main tree.
2. Sort the error output to see which errors are the biggest enemies.
3. Solve the problems that are figured out from the error output
Generating ebuild metadata will take about 10 minutes so this process is not fast. I need to solve as many problems as I can at one pass. Typically new errors will occur after I fix the old ones. And the new errors are not introduced by the new commits. They were just hidden by the old ones. That’s why it’s hard to move forward and handle more ebuilds in a short time.

In future, the error output should be improved so it would be easy for us to figure out more problems. After constantly working on the error output for some time, I’m sure we will get fewer errors and handle more ebuilds. Looking forward to seeing a working libbash for all the ebuilds at the end of this summer.

It’s been a long time since I’ve worked on much anything computer-related as a hobby.  Things have changed quite a lot in the past year.  I moved to a much smaller apartment in Salt Lake, which is about a third the size of my old place.  The idea was to trim the fat and focus on going back to school, which is my major direction in life these days.  When I moved in, I didn’t have room for setting up a desktop computer anywhere, so it’s been just my netbook and me.  That suits me plenty fine, though, I wasn’t really using it that much either.  I had just upgraded to a six-core so I could rip DVDs much faster, and now it was sitting headless wherever I could find room, and even then, only used occasionally.

It’s not just at home that things have been changing.  At work I got to make the transition from programmer to full-time sysadmin, and I’m absolutely loving it.  I knew I was getting tired of coding, and I had always enjoyed just taking care of servers, and now I get to do that all day long. When I initially started as a sysadmin, I didn’t think our small company would have enough work for me to do after a few months.  In actuality, I’m kept busy all the time.  The part I like the most is that part of my job is doing research, how to do things better, more efficiently, anything to make the workload easier.  It’s fun.

On top of all that, my school attendance is starting to ramp up more, and I’ve been consistently drifting to adding more classes to my workload.  All this stuff has basically booted Linux out of my life as a hobby, and so now I need things to “just work” without hassle, so I leave my installations alone.

One thing I’d been neglecting a little bit was my entire HTPC setup.  I hadn’t been using it much lately just because I would mostly stream some Netflix (yay, Doctor Who!).  My setup has been a beast though, normally running for months on end without the slightest hiccup.  What started to happen though is that I would come back to using it, switching my HDMI input over, and the box would be powered off for some reason.  Most of the time, I would either power it back on and go on with life or just ignore it.  Until one day it wouldn’t power on at all, and I just shrugged it off and determined to look at it later.

Well, later turned out to be finals week, when my brain has been working overtime, and I seriously needed a hobby.  I pulled out my main frontend and started looking at it to see what was going on.  It was plugged in properly and everything looked legit, but when I hit the power, the CPU fan would start up for a second and then everything would stop.  After fiddling with it for a bit, I started to notice that something was smelling burnt.  Once that happened, I abandoned my diagnosis.  Even if I did manage to get it working, I didn’t want it to catch everything on fire.

At the same time, my external USB drive enclosure died on me.  So even if I could have gotten it working, I still wouldn’t have had a way to watch my shows.  Them giving out on me hasn’t bothered me in the least — the entire setup has been running flawlessly for years, and I’d managed to get a lot of mileage out of them.

Now I had to decide what I was going to do.  I have a lot of hardware, but in pieces.  I have four mini-ITX boards altogether, two of them are VIA C7 chipsets, and the other two are Zotac boards both running low-powered Celeron CPUs (around 35W if I remember correctly).  The power supplies for the VIA boards use 20-pin connectors and only run at about 80W, and aren’t enough to handle the Zotac boards which use 24-pin connectors.  So I have this mix of hardware, and nothing powerful enough to act as a frontend.

There are some great packaged systems out there now where for between $200 to $300 you can get an entire package in one go that does exactly what I’m putting together myself. I considered the idea of just starting over, but I decided that it’d be cheaper to just salvage what I could.

So this week I ordered a new USB HDD enclosure, and I also ordered a new power supply for the main Zotac board.  I found a site that sells really small power supplies for mini-ITX boards, called picoPSU.  The design eliminates a lot of the hardware that I would normally need to get all the power to my box.  I was really skeptical about them when I first heard of it, but did some looking around and it looks like it’s exactly what I need.

In the meantime, I ripped out my motherboard out of my desktop, and put both Zotac boards in there to make sure they still work, and thankfully they do.  I got the old setup pieced together using my desktop case, and fired up the old system to play around with it.

I had started to forget how much time I put into this thing.  I forgot that I had put countless hours stitching this thing together, running a custom build of Gentoo suited to run on small environments.  On top of that I made hacks to mythvideo and got those working to polish off some rough edges.  It just started to come back to me how much I’d worked on this … and how much fun it was.

I played around with my frontend a little bit, and fired up a few movies just to try out the surround sound.  It was awesome.  I’d forgotten how nice it was to have that huge library on demand, too.

So I’m excited now to get things up and running.  It’s been a good little while.

If you’re designing an XML-based data format, then I beg you, please read the few following rules and obey them. XML may look easy, and even is easy but that doesn’t mean that writing a good one is. And if you’re going to invent second HTML, then please, just use JSON or any other random container. That will be easier for you, and easier for us.

1. Thou shalt always write a schema

Every XML format should be well described. And no, your ten-stanza poem is not enough. Complete, dedicated Wiki neither. These usually describe nicely (or less nicely) how to write your XML. That could be great if that’s all you’re interested in. But if that’s supposed to be some public format, there is one more important thing…

It’s called reading. Or parsing. Or just transforming. If you need to handle random XML files, coming from various sources, written by random people, you have to know what you can expect and what can you assume. It’s not enough to say what <x/> does — I need to know where it can appear and what I can find inside.

There are already well-deployed XML description formats such as DTD, Relax-NG or XML Schema. Please use one of them, I will be grateful. Not only they describe the format strictly and accurately but they also provide a very simple means to validate XML files. It’s helpful both to us, who parse it, and to people who actually write such XML.

An XML without spec is an XML where every element can appear anywhere in the document. In other words, it’s not even XML but an ugly tag soup.

2. Thy XML shalt be structured, not flat

XML provides means to create neat, hierarchical structures. Use them. If your documents consists of logical parts like sections or chapters, put their complete content in a single <section/> or <chapter>, or any other thing that may come into your head. That’s the correct way of doing that in XML.

Random headings and separators are not enough. Even if your spec says they always and definitely start a new section, that’s not enough. If you don’t believe us, try splitting that thing into parts yourself. Especially when you have sub-headings, sub-sub-headings and so on.

A flat-structured XML is no real XML. It’s just a text file with a few unnecessary elements.

3. Thou shalt split text into blocks using XML, not text delimeters

Even if you think that’ll make writing much easier, do not ever try to use simple character delimiters to split text into blocks. If you need a list, create a list of XML elements. Like the following:

<l>elem1</l>
<l>elem2</l>
<l>elem3</l>

And yes, I know elem1,elem2,elem3 is shorter and easier to type. But guess what — it’s hell to parse. It isn’t even XML — you either have to handle it externally or create a complex recursive template which will split it and handle each token separately. That’s very bad.

An XML which uses random delimeters to create lists is no XML. It’s called CSV.

4. Thou shalt not allow insane structures

Even if you think noone will create an insane structure in your document, it’s not enough. Saying it’s disallowed on your awesome Wiki is not enough either. Forbid it if it’s supposed to be forbidden.

Otherwise, someone finally will use it. He or she will deliberately ignore your warning because it works. And even if they don’t, we will have to support it anyway in a compliant parser.

If you expect your data to be interchangeable with widely used formats, take a look at them. Don’t allow insane things which none of these formats do — or we’ll have to either refuse to convert some files, convert them incorrectly or waste our time writing complex blocks converting them to sane ones.

Simply, don’t do it. Even HTML doesn’t do that… well, that much.

5. Thou shalt write readable XML, not bytecode

The major point of using XML is that the data is both readable to machines and humans. Leave it that way. You have the whole human language at your disposal, so don’t write zeros, ones and other random numbers which are explained on your great Wiki.

Say, an attribute called type should actually name some type. Say, article can be some type. 1 usually ain’t. And if that type only describes width of indent, then name it so! Calling it a type is as useful as calling it a thing. Or some-other-thing and a-third-thing.

XML without human-readable text is no XML. Hell, even byte-compiled XML should have readable element names! That’s the whole point with it. Otherwise, you just end up developing another custom, useless format.

Let’s start with the good news: most of Excelsior has arrived and it’s already set up. The only thing that is missing is … the CPUs, which are coming in from Philadelphia, and should arrive here tomorrow, standing to Amazon’s tracking. As I said, the server will be co-located by my current employer, so that’s one issue not to worry about.

Without Yamato, it turns out that my ability to bump the version of my own packages is vastly reduced, mostly because I don’t want to install packages such as MongoDB on this laptop just to test out Ruby Gems, and at the same time I don’t want to have too many extraneous packages installed. Luckily this means that starting tomorrow we should be all ready to start the install phase.

One of the things I’ve been keeping busy with was the split hardware IDs package — sys-apps/hwids, which I’m bumping weekly. This from one side makes it much less important to use the (now gone) network cron scripts to update the IDs files, and on the other allows people who don’t want their systems to access the network directly to be kept up-to-date with the files themselves. This is the first week I’m skipping over the bump, simply because … there is no new content!

I’ve added a new device today to the USB IDs database though so that should mean that next week we might have an update. And tomorrow I’ll probably update it with the possibly missing subsystem IDs for the devices on Excelsior, which will go to the PCI IDs database where I already sent my laptop’s and one of the local server’s subsystems.

Speaking about device identification I can understand why Kay thinks that it might be better to have a general database of everything, instead of multiple small databases… for instance it would be nice if I could just update one database with the IDs of my new external HDD (WD My Passport), and let smartctl know that it has to connect to it with the SAT method, instead of having to write it on a page and then remember about it myself. Speaking about which, WD still is my favourite HDD vendor.

Anyway, thanks once more to all the people who helped the new Excelsior to be built; tomorrow I’ll post a few more details about it, including some photos hopefully, as I’ve got my camera with me as well. There has actually been some trouble with the SSDs and the mounting bays, which I think would be a valuable lesson not only for me.

I know I’ve been tremendously silent in the past week or so, but I’ve been working my ass off — after all of I want to move here I have to work enough to show that I’m worth the investment, and that I l like the job enough. Of course, this means I also have to accept working with Adobe Flash and ActionScript 3, which I easily started to hate (sorry Mike).

At any rate, even though the Pledgie instance is not yet complete (just misses a little over $200!) I’ve ordered all the components for the new Tinderbox host, for which I also found a name: Excelsior following my usual Trekkie naming scheme. While the original plan called for ordering all the components from NewEgg, I’ve had to switch the plan.

The reason is multi-folded. From one side, while NewEgg do support paying through PayPal, they only ship to a verified address, and while I can add bank accounts and credit cards from over here to my account, they do not allow me to add a second, verifiable address outside of Italy to the same account. This is not just a matter of not being able to add an American address, any other country beside Italy is forbidden to Italian account, and I assume that the same applies to all the other countries.

Another issue is that NewEgg does not let me pay through a credit card without verifying the billing address to the number (which is excruciating when you consider that their website by default replace the 5-digits ZIP code with the new, extended 9-digits one), and it does not allow me to add an Italian billing address. Finally, while I do have an US check card… the bank’s daily limit is set at two thousands dollars.

What it ended up to be, well, I ordered the barebone from NewEgg, and the rest of the components I ordered in multiple batches from Amazon (making sure that all the components I’m buying straight from Amazon, to make eventual returns easy). Turns out that this also allowed me to make a couple of changes to the original plan: the memory went from 32GB to 64GB, and the single SSD became two, although I’m now not sure if I should use them to build on when the tmpfs is too small or not.

By Wednesday, all the final components should be in; by end of next week I should have a basic working system, even though it won’t be publicly accessible at that point yet. My employer is going to sponsor the work offering space at the co-lo, assuming they have enough amps available, at which point this will be available to the public. If that’s not going to work due to power drain, I have alternatives in place so the system will be put somewhere pretty soon once it’s complete.

I want to thank all the people who’ve contributed already: without you this wouldn’t have been possible in so short a notice. I’ll make sure to get every single least power drop out of it used for Gentoo.

Whilst I’m hacking on Raspberry Pi images, I have to reinstall the firmware onto a blank image quite a lot. I thought it’d be easier if there was a tool that did this for me. Such a tool would also be useful for normal Raspberry Pi users who want to keep their kernel/firmware up to date to try the latest and greatest new features out.

So I wrote a tool that does just that. It’s called rpi-updater. If you want to give it a shot, then simply follow the instructions linked below. Be warned, however, that it’s rather experimental and could break your image, causing it not to boot. You can’t do any permanent damage to your Pi, though, so as long as you’re not afraid to recreate your SD card, give it a shot.

Instructions on how to install and use the tool are available over at my GitHub account, which you can find here.

Unless you’ve been living under a rock for the past year, you’ve probably heard of the Raspberry Pi. I was lucky enough to get my hands on one of these around a week ago, and I must say, it’s a truly fantastic device. Of course, I got straight to work making it do weird and wonderful things, but you’ll hear more from me on that subject in the coming weeks I hope!

To learn a little about how it’s media APIs work (and to get some music playing courtesy of a Pi whilst I work), I decided to get despotify working on the Pi. It turns out it wasn’t very difficult to do at all, and it runs decently (the library itself works well, but the clients still kinda suck sadly, so it does sometimes hang when you change song).

Since I figure fellow Raspberry Pi owners might want to use this, I’m publishing the changes required and some simple instructions on how to get it working. Do note that you MUST have a Spotify Premium account for this to work. Unlimited/Free accounts will NOT work and never will. With that said, here are the instructions:

• If you’re running Debian, run the following command: sudo apt-get install libtool git libssl-dev libmpg123-dev libvorbis-dev libncursesw5-dev
• If you’re running Arch, then run the following command: pacman -Sy libtool git openssl mpg123 libvorbis ncurses
• Now download the despotify code by running this command: git clone git://github.com/Hexxeh/despotify.git -b raspberrypi
• Now build the despotify code by running this command: cd despotify/src && make
• It’ll then take a minute or two to compile the code. Assuming the compile finishes successfully, you can start listening to music by running one of the two following commands (each one launches a different client, personally I prefer simple)
• ./clients/simple <username> <password> OR ./clients/despotify

Have fun! Feel free to submit pull requests if you can improve the code.

I recently ran into the situation that during installation of some packages in Debian the display started showing graphic errors and the root file system reported to be read only (as it was configure to switch to read-only on errors through its mount options). memtest86+ first complete pass showed no errors at all but later runs indicated errors at at least three addresses:

• 00010c1d370
• 00010c1dab0
• 00004c1da90

Interestingly, grub2 supports masking sections of RAM out of the box, a feature I recently spotted in /etc/grub/grub.cfg by chance. The example and documentation of parameter GRUB_BADRAM in grub.cfg looked like it was just a list of sectors to ignore so I started with “0x10c1d370,0x10c1dab0,0x04c1da90″ for it… to find a frozen Grub after reboot. After a bit of investigation I learned that every second entry is a mask on its predecessor and found a good howto and on how to construct these. The bad RAM mask gave me a few hours of no noticeable errors… and then it came back, from another unmasked section I suppose. That made me order new RAM of a different brand.

On request of Matthew Marchese, I now automatically build an ePub version of Linux Sea for those that like to read such resources on a digital reader. Thanks to the use of DocBook, this was simply a matter of using its xsl-stylesheets/epub/docbook.xsl stylesheet against the DocBook sources and zip the created directory structures (OEBPS and META-INF) to get to the ePub file.

Some may recall my old set up I used to record the AWNOI net. A bit fiddly, but it worked, and worked well. However the machine I used was short-lived. Basically, I wanted to stream in both directions between a sound device connected to a HF radio transceiver, and a USB wireless headset, with a feed being recorded to disk.

The problem with newer sound devices is the rather limited sync range possible with the modern audio CODECs. Many will not do sample rates that aren’t a multiple of 44.1kHz or 48kHz, and I have a headset that won’t record any other sample rate other than 16kHz. ALSA’s plug: doesn’t play nice with JACK, and I shelved the whole project for later.

Well, tonight I did some tinkering with gstreamer to see if it could do the routing I needed. Certainly all the building blocks were there, I just had to get the pipeline right. A bit of jiggling of parameters, and I managed to get audio going in both directions, and to a RIFF wave file to boot. I’ve put it in a shell script for readability/maintainability:

#!/bin/sh
# GStreamer bi-directional full-duplex audio routing script
# Stuart Longland VK4MSL

CAPT_BUFTIME=50000
CAPT_LATTIME=25000
PLAY_BUFTIME=20000
PLAY_LATTIME=1000

STREAM_FMT=audio/x-raw-int,channels=1,width=16,depth=16,rate=16000
OUTPUT_FMT=audio/x-raw-int,channels=2,width=16,depth=16,rate=16000
OUTPUT="${1:-out.wav}"

HEADSET_DEV=hw:Headset
HEADSET_CAPT_FMT=audio/x-raw-int,channels=1,width=16,depth=16,rate=16000
HEADSET_CAPT_BUFTIME=${CAPT_BUFTIME}
HEADSET_CAPT_LATTIME=${CAPT_LATTIME}
HEADSET_PLAY_FMT=audio/x-raw-int,channels=2,width=16,depth=16,rate=48000
HEADSET_PLAY_BUFTIME=${PLAY_BUFTIME}
HEADSET_PLAY_LATTIME=${PLAY_LATTIME}

SNDCARD_DEV=hw:NVidia
SNDCARD_CAPT_FMT=audio/x-raw-int,channels=2,width=16,depth=16,rate=48000
SNDCARD_CAPT_BUFTIME=${CAPT_BUFTIME}
SNDCARD_CAPT_LATTIME=${CAPT_LATTIME}
SNDCARD_PLAY_FMT=audio/x-raw-int,channels=2,width=16,depth=16,rate=48000
SNDCARD_PLAY_BUFTIME=${PLAY_BUFTIME}
SNDCARD_PLAY_LATTIME=${PLAY_LATTIME}

exec    gst-launch-0.10 \
    alsasrc device=${HEADSET_DEV} \
            name=headset-capt \
            slave-method=resample \
            buffer-time=${HEADSET_CAPT_BUFTIME} \
            latency-time=${HEADSET_CAPT_LATTIME} \
        ! ${HEADSET_CAPT_FMT} \
        ! audioresample \
        ! audioconvert \
        ! ${STREAM_FMT} \
        ! queue \
        ! tee name=headset \
        ! audioresample \
        ! audioconvert \
        ! ${SNDCARD_PLAY_FMT} \
        ! alsasink device=${SNDCARD_DEV} \
            name=sndcard-play \
            buffer-time=${SNDCARD_PLAY_BUFTIME} \
            latency-time=${SNDCARD_PLAY_LATTIME} \
    alsasrc device=${SNDCARD_DEV} \
            name=sndcard-capt \
            slave-method=resample \
            buffer-time=${SNDCARD_CAPT_BUFTIME} \
            latency-time=${SNDCARD_CAPT_LATTIME} \
        ! ${SNDCARD_CAPT_FMT} \
        ! audioresample \
        ! audioconvert \
        ! ${STREAM_FMT} \
        ! queue \
        ! tee name=soundcard \
        ! audioresample \
        ! audioconvert \
        ! ${HEADSET_PLAY_FMT} \
        ! alsasink device=${HEADSET_DEV} \
            name=headset-play \
            buffer-time=${HEADSET_PLAY_BUFTIME} \
            latency-time=${HEADSET_PLAY_LATTIME} \
    interleave name=recorder-in \
        ! audioconvert \
        ! audioresample \
        ! ${OUTPUT_FMT} \
        ! wavenc \
        ! filesink location="${OUTPUT}" \
    headset. \
        ! queue \
        ! recorder-in.sink1 \
    soundcard. \
        ! queue \
        ! recorder-in.sink0

Now the fun begins ironing out the kinks in my data cable for the FT-897. At present, it works for receive, and seems to work for transmit. I use VOX on the radio itself and keep the headset’s microphone on mute when I don’t want to transmit.

At present, I was getting a bit of distorted audio coming back through the headset when I transmitted, almost certainly RF-pickup in the cable and line-in circuitry of the computer’s sound card. I’ll have to see if I can filter it out, but the real test will be seeing if such distortion is present on the outgoing signal — or rather, if it’s significantly audible to be a problem.

I am really happy to announce that I’ve been invited to the Tizen Developer Conference, in San Francisco, CA next month (May 7-9). I’m going with a friend of mine, Michele Tameni, who seems to have won the Intel consolation prize (damn you!).
I really need to thank Giovanni Martinelli and Mauro Fantechi for sponsoring my trip there and across the whole San Francisco Bay Area (I’ve been told that it’s full of Gentooers, gonna catch you!).

This is a great opportunity for me to meet a good deal of hardcore FLOSS devs and have a beer together (just one?). There are also several exciting talks I couldn’t really miss.

Feel free to contact me if you want to meet up for a drink. A post to the gentoo-core ML will follow next week.

If you speak some fancy language other than english, then this post is exactly for you. While I was working on updating some of the lingua packages in the cvs based on euscan reports I checked their websites to ensure the euscan reports to be correct (in some cases it might miss a bump, or report some beta files). And I hit huge problem, all of those damn pages are writen in native language (eg hungarian spell is in hungarian, dutch in dutch…) which effectively means I can’t read s**t. It might be briliant to get more contributors, but most packagers for the software are developers which just try to make the users happy and do not speak your language at all (google translate is not much help in some cases).

To the point. If you can could you look up dictionaries for your language and check for new versions (ispell/aspell/myspell/…)? If there are some just drop me mail, open new bug and CC me on it, or whatever suits your plan.

Another problem with our app-dicts team is that it is not existing. Currently it is just pva (doing his best) and nobody else did any relevant work on dictionaries since 2k8. We have old support code for openoffice-1/2 and so on. Luckily it does not break anything much, but still it is quite cruft. So if you ever considered being Gentoo contributor this might be easy area how to get involved.

And for the end we need to rework all the myspell-* language packages as they still use old openoffice infrastructure. This was shot down when oracle given all the stuff to apache foundation so all the links are dead. Job here is to search up dict/thes/whatever and set up proper homepage and download locations, maybe asking on irc channels of both projects ( libreoffice and openoffice) to see where they moved it up.

So anyone up for any of the tasks (no, I don’t want to do it because I am lazy, but I have quite lot of stuff within the libreo stuff itself)?

In my previous post, a very valid question was raised by Alexander E. Patrakov: why still use chroot if you have SELinux?

Both chroot (especially with the additional restrictions that grSecurity enables on chroots that make it more difficult to break out of a chroot) and SELinux try to isolate an application so it only has access to those resources it needs. Chroot does this on file-level basis (and a bit more with grSecurity), SELinux on more general resources. However, things that make SELinux strong (flexible and detailed policy language, fine-grained authorizations) are also its weakness (consolidating files into groups having the same file label), and chroot does have an advantage on this.

Suppose that a flaw exists in BIND through which an attacker can read files on the host (through BIND). With SELinux, the domain in which BIND runs is prohibited from accessing and reading files whose label is not one of the labels that the policy thinks BIND should be able to read. More specifically, the BIND policy in the reference policy (which is what both Gentoo and RedHat base their policies on, and generally policies are only enlarged, never really shrinked):

• etc_runtime_t (read) means access to the files in /etc that are modified at runtime (like mtab, profile.env, gentoo’s /etc/env.d)
• named_var_run_t (read) is access to /var/run/bind and /var/run/named (and a few other related locations)
• named_checkconf_exec_t (read/execute) is access to read and execute /usr/sbin/named-checkconf
• named_conf_t (read) to read the BIND-related configuration files
• dnssec_t (read) to read the DNSSEC keyfiles
• locale_t (read) to access /etc/localtime, /usr/share/locale/*, /usr/share/zoneinfo/*
• etc_t (read) to read the general configuration files in /etc (including passwd, fstab, …)
• proc_t (read), proc_net_t (read) and sysfs_t (read) to access those pseudo filesystems
• udev_tbl_t (read) to access /dev/.udev and /var/run/udev (but I have no idea yet why this is in)
• named_log_t (read/write) for the log files of BIND
• net_conf_t (read) to access /etc/hosts (including deny/allow), resolv.conf, …
• named_exec_t (read/execute) the BIND executables
• named_zone_t (read) to access the zone files, also write access in case of slave system
• cert_t (read) to read certificate information
• named_cache_t (read/write) to access its cache
• named_tmp_t (read/write) to work with temporary files

Isolation provided by SELinux is as powerful as the width of its labeling. For instance, by giving the named daemon read access to /etc files like passwd, fstab, group, hosts, resolv.conf and more, a malicious user who can exploit this hypothetical vulnerability can obtain information that might help him in his further attempts. By chrooting BIND, the files placed in the chroot itself should not offer the information he might be looking for (for instance, the passwd file, if needed at all, is limited to just the named and root accounts, etc.)

Chrooting, but not enabling SELinux, could lead to escalation. A chroot cannot restrict what a process is allowed to do beyond the regular access privileges that are given on the user. If a user can upload an exploit through BIND and have BIND execute it, he can use this as an attack vector for further activities. SELinux here prohibits BIND to write stuff it can also execute (there is no write and execute privilege defined here). It also ensures that the BIND daemon never exists his security domain (transitioning towards another domain with perhaps other privileges) as there are no transition rules from named_t to any other domain.

Another MAC system that would be better suited to fit both is grSecurity’s RBAC model. Iirc, it uses path definitions to say which files are allowed to access and which not. The weakness SELinux here has (aggregation into sets of files with the same label) doesn’t exist for grSecurity. This debate on path-based versus label-based access controls have been going on for very long time now – just google it ;-)

So, Alexander, in short: chroot further limits the SELinux-allowed privileges to a more fine-grained set of file system resources (files/directories).

BIND, or Berkeley Internet Name Domain, is one of the Internet’s most popular domain name service software (DNS). It has seen its set of security flaws in the past, which is not that strange as it is such a frequently used service on the Internet. In this post, I’ll give a quick intro on how to use it in Gentoo Hardened (with PaX)… chrooted… for IPv6… with SELinux ;-)

Installing is of course, as usual, dead easy on Gentoo (Hardened/SELinux). Make sure you have USE=”ipv6″ set, and then emerge bind. Also install bind-tools as they contain some great tools to help with DNS troubleshooting. Then we’re editing /etc/conf.d/named to set the CHROOT variable. I also set CHROOT_NOMOUNT so that Gentoo doesn’t bind-mount the information in the chroot but instead uses the files in the chroot.

CHROOT="/var/named/chroot"
CHROOT_NOMOUNT="1"

Now we need to either temporarily add some privileges in SELinux, or run the portage_t domain in permissive mode. If you go for privileges, then add the following:

allow portage_t var_t:chr_file { create getattr setattr };

If you however want to temporarily run the portage_t domain in permissive mode, do that as follows:

~# semanage permissive -a portage_t

We are doing this because we are now going to ask the BIND ebuild to prepare the chroot for us. Doing so however requires portage to work on our live file system (and not in the regular “sandbox” mode). SELinux however forces portage in the portage_t domain and only gives it the privileges it needs for building and installing software.

~# emerge --config bind

When done, remove the previous SELinux allow rules again (or set the portage_t domain back in enforcing mode, through semanage permissive -d portage_t). Next we need to relabel the files in the chroot. By default, all files are labeled by SELinux as var_t in that location because it isn’t aware that it needs to see /var/named/chroot as a “root” location.

~# setfiles -r /var/named/chroot /etc/selinux/strict/contexts/files/file_contexts /var/named/chroot

So far so good. Now let’s create a simple named.conf file (in /var/named/chroot/etc/bind):

options {
  directory "/var/bind";
  pid-file "/var/run/named/named.pid";
  statistics-file "/var/run/named/named.stats";
  listen-on { 127.0.0.1; };
  listen-on-v6 { 2001:db8:81:21::ac:98ad:5fe1; };
  allow-query { any; };
  zone-statistics yes;
  allow-transfer { 2001:db8:81:22::ae:6b01:e3d8; };
  notify yes;
  recursion no;
  version "[nope]";
};

# Access to DNS for local addresses (i.e. genfic-owned)
view "local" {
  match-clients { 2001:db8:81::/48; };
  recursion yes;
  zone "genfic.com" { type master; file "pri/com.genfic"; };
  zone "1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa" { type master; file "pri/inv.com.genfic"; };
};

The zone files referenced in the configuration file are located in /var/named/chroot/var/bind (in a subdirectory called pri – which I use for “primary”). The regular one would look similar to this:

$TTL 1h ;
$ORIGIN genfic.com.
@       IN      SOA     ns.genfic.com. ns.genfic.com. (
                        2012041101
                        1d
                        2h
                        4w
                        1h )

        IN      NS      ns.genfic.com.
        IN      NS      ns2.genfic.com.
        IN      MX      10      mail.genfic.com.
        IN      MX      20      mail2.genfic.com.

genfic.com.     IN      AAAA    2001:db8:81:80::dd:13ed:c49e;
ns              IN      AAAA    2001:db8:81:21::ac:98ad:5fe1;
ns2             IN      AAAA    2001:db8:81:22::ae:6b01:e3d8;
www             IN      CNAME   genfic.com.;
mail            IN      AAAA    2001:db8:81:21::b0:0738:8ad5;
mail2           IN      AAAA    2001:db8:81:22::50:5e9f:e569;
; (...)

while the one for reverse lookups looks like so:

$TTL 1h ;
@       IN      SOA     1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa ns.genfic.com. (
                        2012041101
                        1d
                        2h
                        4w
                        1h )

        IN      NS      ns.genfic.com.
        IN      NS      ns2.genfic.com.

$ORIGIN 1.8.0.0.8.b.d.0.1.0.0.2.ip6.arpa.

1.e.f.5.d.a.8.9.c.a.0.0.0.0.0.0.1.2.0.0         IN      PTR     ns.genfic.com.
8.d.3.e.1.0.b.6.e.a.0.0.0.0.0.0.2.2.0.0         IN      PTR     ns2.genfic.com.
; (...)

We can now start the init script:

~# rc-service named start

On the slave, don’t set the allow-transfer directive and set its type to “slave”. In each zone, you will need to tell where the master is:

zone "genfic.com" {
  type slave;
  masters { 2001:db8:81:21::ac:98ad:5fe1; }
  file "sec/com.genfic";
};

By default, the SELinux policy for BIND does not allow BIND to write stuff in its directories. On the slave system, you will need to change this. A SELinux boolean here does the trick:

~# setsebool -P named_write_master_zones on;

There ya go ;-) Okay, all very condensely written, but it should give some feedback on how to proceed. I’m adding this information to the new online resource I’m writing – A Gentoo Linux Advanced Reference Architecture. Nothing really ready yet, just writing as I go forward with exploring these technologies…

This is not your average Linux-focused post, I’ m sorry if you were expecting one.

As I said lately, I’m now in Los Angeles, and while my dayjob involves working with a Gentoo-based firmware (and a Flash-written interface), I also have to complete a few tasks for customers at home, one of which requires me to use Windows 7 and Visual Studio 2008, both of which I own a license of … but in Italy.

While my original plan was to use TeamViewer (of which I also have a license — no kidding I know the value of Free Software, given how much I must spend on proprietary software to perform the task that FLOSS is unable to), but unfortunately the same router crash that caused Yamato’s unavailability has caused me to lose access to the laptop I used for this task.

This became even more troublesome considering that while my Dell laptop came with a Windows 7 Professional license, I decided to not install it back last time I decided to repartition it, and even more importantly, when I came here to the US I replaced the 250GB SATA hard drive with a 64GB SSD which is entirely dedicated to my Gentoo installation.

How to solve this situation? Well, seems like I did set me up with the single component to handle this properly: an eSATAp-to-SATA cable, a passive adapter, which can be used in combined eSATA/USB ports, which my laptop has (incidentally, that works just fine if you boot the system with it connected; it also works fine if you resume with it connected… but Linux seems not to have a way to rescan the bus properly, making it unsuitable for hotplug), The other part to this task is of course having the product keys (the Windows 7 one is under my battery, the Visual Studio one is on my NAS, which means a friend of mine can access it), and the discs… luckily, Microsoft’s official ISO files are available, even though you have to hunt for the Windows 7 ones, as they are not public. Visual Studio 2008 and the SP1 are available as downloads, the first as a 90 days convertible trial, which is fine.

My idea was to hope for the best, install Windows on the secondary disk, and then re-install grub2, through SysRescue, to be able to boot from the external drive. Well, it turns out it was much more easy than that. For whatever reason, my laptop can keep booting UEFI and non-UEFI modes without having to reconfigure the firmware every time, just by using F12 to choose the different boot device. So I started the Windows installation in UEFI mode, and watched it progress (I already knew that the firmware can easily boot from the external harddrive, as the eSATA interface only shows it on a different AHCI host, but it’s initialized the same way as the internal one).

After the first installation step was completed, I was honestly surprised to find out that… Windows didn’t even touch grub2! Instead, what it did was create its own EFI boot partition on the secondary harddrive, leaving the main harddrive totally clean… I just have to select “Windows Boot Manager” from the F12 menu, and Windows 7 boots and doesn’t give anything about being on a physically external drive. Even their performance score system is not showing any difference from having it internal (although I’m sure it would show the difference if it was Windows on the SSD).

Of course this is not to say that Microsoft’s software is not the usual stinking stuff… but at least they can leverage UEFI, with all its faults, to make for something… and luckily, they no longer want to be the sole owners of my laptop to just let me use their stuff for one job.

If you are following news regarding openSUSE and MySQL, you probably already know, that we have both MySQL and MariaDB in openSUSE to allow users to choose what they want to use. And if these two options are not enough, we’ve got server:database repository with newest and greatest development versions of both and MySQL Cluster on to of that. I think all this is great and awesome, that we have all of that.

Now to the not so great part. Unfortunately I’m bare human, I have to eat, sleep and I have some work, some bugs that takes a lot more time that I expected, some school duties to take care of and of course openSUSE Conference to organize! So as a result of all that, I can’t polish MySQL and MariaDB as much I would love to. And on top of that, I’m not expert in MySQL configuration. Part of that is that it just works and I never had any server where MySQL was slowing things down. But there is plenty of skilled MySQL administrators out there in community! So I’m calling out for help. You skilled MySQL admins probably have a lot of interesting tweaks you are applying to default configuration file. So take a look at them and think what could be useful for everybody, not just in your specific use-case. And either send me snippet with short explanation in the comments, or create .cnf file add it to the flavor directory and send me pull request on github! I’ll keep credits and your explanation of the snippet inside, so people will know, who came with this cool option and what does it do

Oh, and don’t get discouraged if I don’t include it right away, it may take me some time to get to it, but I’ll appreciate every suggestion

Optional runtime dependencies (or «suggested dependencies») are one of the late problems we’re facing in Gentoo. There’s definitely a need for some standard solution, and it’d be great to put it in the next EAPI. Sadly, there’s no consensus how to solve it.

The optional dependencies problem

Gentoo has a very neat solution for handling optional dependencies and optional features, probably ever since the beginning. It is called «USE flags» and they work very well with the «traditional» optional dependencies. By that, I mean optional dependencies which are both build- and run-time.

Such a dependencies have to be pulled in before the build process starts, and usually require passing specific options in the configure phase. What’s important, both enabling and disabling features requires rebuilding the program in question because of code branches being switched. Thus, it’s perfectly fine if changing USE flags implies rebuilding the package.

Sadly, when it comes to optional runtime dependencies, USE flags are not a perfect solution. «Switching» such a dependency doesn’t require rebuilding the program anymore. It’s usually not even switching — the program can determine in runtime whether a particular dependency is available, and either enable or disable respective features. Simple like that.

If one decides to use USE flags for that, they become partially meaningless. Unless flags start stripping off the code (which is a bad idea), feature availability is dependency- rather than flag-based. So, USE=-ssl is irrelevant if, say, pyopenssl is installed. What’s even worse, flag imply needless rebuilding of such packages just to pull in an additional dependency.

The simple hack — pkg_postinst() messages

The simplest solution right now is just listing the suggested dependencies in pkg_postinst() messages. Combined with has_version helper, those messages can give a pretty nice output, pointing out already installed packages — just take a look at sys-apps/systemd ebuild.

Of course, it’s not a real solution, rather relying on user doing the hard work. The biggest disadvantage is that the dependencies are often going to end up in @world. And then, if user decides to unmerge our package, portage is unable to find and unmerge them as well.

The SDEPEND solution

A pretty common idea is to establish a new variable called SDEPEND (for «suggested»). Such a variable would simply list relevant dependencies, and let portage handle the UI part somehow. It is a minimalistic solution, quite consistent with other parts of PMS. Sadly, it has a few big shortcomings.

First, using our current dependency syntax, you can’t specify that a particular feature requires more than one package; in other words, that two or more suggested dependencies are supposed to be pulled in together. Of course, solving this one would be pretty easy — e.g. by allowing grouping them with parantheses.

A much more important issue is describing what particular dependencies do. Although sometimes this could be guessed by package descriptions pretty well, usually a more friendly text would be great. So, we end up having to implement that somehow.

And that’s usually when Ciaran comes in with ugly exherbism DEPENDENCIES. Sure, it solves most of the issues pointed out here but, hell, do we really want such a thing? Isn’t dependency syntax obscure enough already?

And it’s all rather dependency-oriented. In other words, package comes first, then goes the feature description. «Pass dev-python/pyopenssl or dev-python/python-gnutls to enable secure connections support». I don’t think that’s the most user friendly solution.

The USE flag solution

Another solution is brining a new category of USE flags. It’s not important whether they would be specified using a special variable, common USE_EXPAND or another magical features. In fact, that could be a thing totally separate from USE flags. The point is that some of the package flags would be runtime-switchable.

Unlike traditional USE flags, such flags wouldn’t be stored in vdb. They would be evaluated in place instead, using package.use or similar files, and the dependency tree would use current state of such flags. Of course, they would be allowed for RDEPEND (PDEPEND) use only.

Why reuse USE flags for that? Because it’s the most user-friendly solution. User doesn’t have to learn anything new. He/she enables a flag, does emerge -vDtN @world and notices that new dependencies are pulled in but the package doesn’t have to be rebuilt for that.

If we just add some additional magic for regular USE flags, enabling run-time dependant SSL support could be exactly the same as enabling build-time one — even using the same USE=ssl.

And we could basically even give «backwards» support for older EAPIs. Package managers not supporting the new feature would simply treat runtime-switchable USE flags as regular USE flags, requiring rebuilds of the package.

A quick help request from the community: if you know of any Gentoo documents that need updates in order for end users to know when and how to use initramfs, please file bugreports and have them block bug #407959. Currently, we have updated the Gentoo Handbook, Gentoo Quickinstall guides and added an Initial ramfs Guide.

The tracker bug is also used to check if and when the eventual roll-out of software can happen, and we want to make sure that we do not forget documentation (something we learned from the openrc migration). Not that the change is as large as was the case with openrc, but it is still nice to have updated documentation in time ;-)

mkdir -p /etc/portage/patches/kde-base/plasma-apps
cp debug.patch /etc/portage/patches/kde-base/plasma-apps/
emerge -a1 kde-base/plasma-apps

 >>> Preparing source in /var/tmp/portage/kde-base/plasma-apps-4.8.2/work/plasma-apps-4.8.2 ...
 * Applying user patches from /etc/portage/patches//kde-base/plasma-apps ...
 *   debug.patch ...                      [ ok ]
 * Done with patching
>>> Source prepared.

I have never blogged about shoes before. So let’s see what it’s like. After all for being shoes these make me quite happy right now. Shoes! My old sneaker’s started to die so with a single pair of shoes only I had to do something. I liked the fresh look of the red ones so I ended up with both of these. Very comfortable to wear so far. So Pictures!

Apropos new shoes: Paolo Nutini knows what new shoes can do, join his tune:

For quite some time I have been using Meld to detect relevant changes between two releases when I update a package in Gentoo. I run

# ebuild foobar-1.2.ebuild manifest prepare
# ebuild foobar-1.3.ebuild manifest prepare

and throw Meld at both outputs

# meld /var/tmp/portage/[..]/foobar-1.2/work/foobar-1.2/ \
       /var/tmp/portage/[..]/foobar-1.3/work/foobar-1.3/ &

Meld makes it easy to see what has changed and (especially) what has not changed. With sole diff -r that would be difficult.

I usually start by inspecting changes to configure.ac. If upstream did a good job that diff tells what dependencies to touch, already. Near the left and right margin you can see where else the file has been modified. No need to scroll-search down for more: you already know what you get.

The NEWS and ChangeLog files usually offer pointers of interest, too.

If my hint on Meld made a single Gentoo packager juggler’s life easier or more efficient, I have achieved what I was aiming for. Sorry for the noise to everyone else.

PS: The second preview image up there has been losslessly reduced by 40% in size just by running it through optipng -o7.

If you are using stable profiles, you might want to verify if you are already running a kernel with devtmpfs support enabled. Why? Well, currently you might not need it, but the upcoming openrc/udev packages require it and they currently do not fail at install time if you have it enabled or not. As a result, upgrading these packages might give you a system that might fail to boot (if you have no initramfs but separate /usr partition) or gives many errors (if you have an initramfs).

To verify if it is enabled, check your kernel configuration:


# zgrep DEVTMPFS /proc/config.gz
# CONFIG_DEVTMPFS is not set


If you get the output as described above, best update your kernel configuration to include it. The second devtmpfs-related option (to automatically mount it on /dev) is not needed afaik.

And for those that have been with Gentoo for a while – devtmpfs is not devfs. Well, it is. But it isn’t. Somewhat. Oh well, there’s discussion on that which I’m not going to elaborate on. Safe to say that we’re getting older if we start feeling “Been there, done that, got the t-shirt” ;-)

Edit: as Robin mentioned in the comments, the udev ebuild does check at it. However, it doesn’t fail an installation so you could miss the message. Apologies for the lies, Robin ;-) Post updated.

While repoman does a good job of finding smells in ebuilds, a tool to evaluate an overlay with respect to the state of the Gentoo main tree has to my knowledge been missing so far.

overlint is a simple command line tool. From a technical view point it reports

• which version bumps from the overlay are missing from the main tree (e.g. the overlay has 7.1 but the main tree has 7.0, only),
• which revision bumps are missing from the main tree (e.g. the overlay has 3.0-r1 but the main tree has 3.0, only), and
• which exact same revisions exist in both trees with differing ebuilds.

On a higher level these findings often indicate that

• certain changes are still to be integrated with the Gentoo main tree to benefit a wider audience and/or that
• an ebuild appeared in an overlay first but can be removed now as the Gentoo main tree has grown an equivalent (or identical) copy.

As a consequence overlint has two main use cases, each with a different user audience:

• Overlay maintainers can use overlint to better keep their overlay in shape.
• Gentoo developers and proxy maintainers can use overlint to detect valuable patches missing from the main tree.

Here is example output of overlint 0.4.1 for the calculate overlay:

# overlint-cli /var/lib/layman/calculate/
===============================================================
Version bumps missing from Gentoo main tree
===============================================================
net-misc/
  italc :: 1.0.13, 2.0.0
net-print/
  foo2zjs :: 20081129, 20110512
net-wireless/
  madwifi-ng :: 0.9.4.4178.20120131
  madwifi-ng-tools :: 0.9.4.4178.20120131

===============================================================
Revision bumps missing from Gentoo main tree
===============================================================
app-arch/
  unzip :: 6.0-r9
app-text/
  wgetpaste :: 2.18-r1

===============================================================
Ebuils that differ at same revision
===============================================================
app-forensics/
  unhide :: 20110113
dev-util/
  bin_replace_string :: 0.2
  qt-creator :: 2.4.1
sys-auth/
  pam_keystore :: 0.1.3
sys-block/
  tw_cli :: 9.5.3
sys-boot/
  grub :: 1.99-r2
sys-libs/
  talloc :: 2.0.7
virtual/
  linux-sources :: 0

To get it run:

# sudo emerge -av app-portage/overlint

The source code is up on http://git.overlays.gentoo.org/gitweb/?p=proj/overlint.git;a=summary. For small patches just send them along, for bigger ones get in touch before the work, please. Thanks!