Note that it is still not finished (no spelling and grammar check done yet, still need to add some exercises, etc); once it is, I will tag the sources appropriately.

On the cvechecker state, it is also still under development, but progress is going nicely. Most of the work now is in updating the versions.dat file with information on how to obtain the current version of a package/tool. It is an easy activity – most of the work is in finding out how CVE entries would label a tool (what vendor and product name would be chosen) and because I am too lazy, I am currently only adding those that already have CVE entries assigned to them (so I can just take a look at the correct values).

It is also my first attempt at using autotools. Quite some overkill for such a small project, but why not. At least it allows me to try to do some new things here ;-)

One thing lacking is to be able to find out which package would provide a file. Unlike the previous tools, this tool cannot rely on the information found on your system as the package isn’t installed yet.

There have been projects in the past that attempted to provide such functionality, almost always through an online queryable database. Many haven’t survived, due to too high expectations or little server infrastructure resources. But it seems like PortageFileList is to stay for a while.

The project not only offers an online interface for querying information, it also provides a package (app-portage/pfl) that allows you to query their infrastructure from the command line. The package provides a tool called e-file which supports SQL-like syntax for the queries.


~$ e-file '%bin/xdm'


The above command will then display, using the well-known emerge/Portage output, which package provides the file (as well as which file was matched by the query).

Definitely a nice tool to have around. Thanks guys of PortageFileList!

Feedback is, as always, very much appreciated.

More exercises on the following chapters will follow soon.

Updates to the script include visual accept/reject of single-choice and multiple choice answers and improved support for Internet Explorer (which I don’t have at home to validate).

I do, and I found it quite difficult to keep the knowledge live without having to reread the things every now and then. For that purpose, I started writing a simple JavaScript/XML/XSL fileset that allowed me to present questions (randomly if necessary) from a structured set of questions. In the beginning, it was too simple to share (string matching) but quickly grew to something more elaborate: regular expression support, multiple string-answer support, in-paragraph answer boxes and single/multiple choice answers.

With this fileset in place, I can keep track of things I would most likely otherwise forget: just select the category which I want to take a test from, and start with a (lot of) random question(s).

I’ve decided to put this fileset online (including demo files) and will extend the demo file with questions regarding my book, Linux Sea, allowing readers of the book to take online tests after they’ve finished a chapter.

What does this mean? Well, previously, Gentoo already supported various masking reasons (like stable versus staging – the x86 versus ~x86 saga, package.mask’ing – for security reasons or critical bugs, …). Now, a new feature is added: license masking.

By default, Portage accepts all non-EULA licenses. If a package uses a EULA license, you’ll get a failure message stating that the license is ‘masked’.

Now, what good does this do for users? Well, you can now ask Portage only to accept certain licenses (like @FSF-APPROVED, which is a list of all FSF-approved licenses) and deny the installation of others. Nice, isn’t it?

I’ve added information regarding package license states (and the global as well as per-package unmasking support through /etc/portage/package.license) to the Linux Sea document.

• Information regarding ndiswrapper
• Some information about udev and the symlinks that it creates

The PDF version has been updated as well.