Next to the binaries, I’m currently checking if the SELinux policy packages can become EAPI-4 compliant (they’re currently still using EAPI-0). Same for the SELinux-specific packages, like policycoreutils, libsemanage, libselinux etc.

During the last few days, I’ve tried to take a few stabs at supporting Python 2 and Python 3 simultaneously. It seems to work for policycoreutils and libsemanage (necessary fixes are in the gentoo-hardened overlay) but any attempt to fix libselinux seems to give me hard walls. So for now, we’re still stuck with Python 2 support when using Portage (note that you can still use Python 3 for all other things, but Portage requires Python 2 as it calls libselinux). This is currently still accomplished through a proper use.mask and use.force setting against Portage.

Of course, the policies themselves are not silent either. I’ve updated the selinux-base-policy package so that Portage can now support NFS-mounted Portage trees and made quite a few openrc-related fixes as well (against the policy, not against openrc ;-)

I promised to take a stab at MCS in the near future, and that’s still the plan. Hopefully in the coming few weeks ;-)

Little did I know that it is UTC that has leap seconds (sometimes you hear in the news that the last minute of a year lasts 61 seconds) whereas UT1 (which is the modern notation for GMT) doesn’t.

All that because I read about a meeting taking place at 2000 UTC…

I’m glad to see that the document is well received. There is still lots of work on it (more excercises, a thorough spelling / grammar check, elaborate on certain topics, …) so stay tuned for further updates. Why are those updates “slow”? Well, let’s say that I use a “fair share scheduling” principle on all my hobbies ;-)

DITA “forces” the technical writer in separating the content of his document in specialized subjects: reference, task or concept, or a specialized version of any of those which you can create/define yourself.

By separating content in those three subjects, you can more easily manage your technical documentation (write concepts as individual topics, tasks as end-user procedures and references for affiliated topics or command information).

Once all these documents are written, you bind them together using a DITA map (a metadocument which holds references to all related concepts/tasks/references) et voila: your documentation is ready.

Well, not really, you need to build it to something end users can read – you can use dita-ot for that. It supports building for Eclipse Infocenter, RTF, XHTML and PDF out of the box.

To keep track of my work, I write an extremely simple task manager: an XML file (for the data), XSL file (for the rendering) and HTML/CSS file (to render and use the browsers’ XSL capabilities). I call it taskviewer due to lack of more imagination ;-)

It is a simple manager with no user interface for managing it at all – so you’ll need to edit the XML file yourself. However, the HTML/CSS file, together with the XSL file, renders the content of the XML file in such a way that you have a nice overview of your tasks.

It’s “features” are simple:

• keep track of events you are waiting for
• keep track of a tasks’ dependencies (events or other tasks)
• get an overview of tasks that can immediately start versus that are blocked, waiting for its dependencies to finish

There is an example available online with some hypothetical data.

If you know of a simple program (preferably java or one available for both Windows and Linux) that has similar features (especially tracking tasks depending on certain events), please do tell me. I’ve looked at tools like taskjuggler but couldn’t find one that remains simple yet has these features.