>=sys-apps/openrc-0.2
=sys-apps/baselayout-2.0.0*

As always, any issues should be reported to Gentoo’s Bugzilla and assigned to base-system@gentoo.org

One gotcha is that util-linux’s crypto-loop initscript appears to have been silently updated for OpenRC support. You’ll need to make sure you’re on a 2.13 or higher version and potentially re-emerge it.

The associated bugs for this are #212696 and #213988.

I was thinking of possibly adding this as a Portage QA check. Basically, anything that is installed into /lib, /lib32, /lib64, /bin, and /sbin get passed through scanelf -Ln or ldd to determine if anything would be outside the scope of those directories and it could be fixed.

Also, if any of the people that build binary packages and then do some tests against them want to add this as a test to their system, I’m sure people would be appreciative.

Firstly, I’ve finally taken the plunge and officially joined the base-system herd. For a very long time, I’ve hung around the shadows of base-system so now I’ve finally joined up officially.

For a while I’ve had an issue with regard to MythTV support and the subversion.eclass. Basically we needed svn switch support and a decent revision reporting method. I finally got tired of waiting for the bugs about this to get fixed and started to do the work myself. Turns out zlin had some changes from the KDE herd that he wanted to push into the subversion.eclass as well. We ended up putting our heads together and cleaning up the eclass of a few problematic bits of code as well as provided the additional necessary features.

After that I have been able to get some work done on MythTV 0.21 so you should see some beta quality ebuilds in the tree for the upcoming 0.21 release. There’s still a few USE flag combinations that need to be tweaked and testing of USE flag combinations. As always, help is appreciated but all patches are referred to upstream.  But also remember this code is beta quality so make sure you back up (the official MythTV documentation for backing up your database isn’t the greatest, you can see my updated instructions here) your MythTV database.

Tinkering with MythTV I discovered that Gentoo’s XvMC support is quite lacking in formality. I figured the best solution for Gentoo would be to always use libXvMCW, which is a wrapper for the various XvMC implementations. Then configure libXvMCW to use the proper implementation. This is where app-admin/eselect-xvmc comes into play, its designed to assist users with configuring XvMC on their system. Once it’s 100% tested, I will be adding it as a PDEPEND to x11-libs/libXvMC and all applications using XvMC will just dep on x11-libs/libXvMC and link to libXvMCW. For anyone wondering, x11-libs/libXvMC provides libXvMCW.

Lastly, I also ended up writing an eselect module for fontconfig. Currently, media-libs/fontconfig provides a bunch of configuration files in /etc/fonts/conf.avail/ and requires users to symlink them to /etc/fonts/conf.d/ if they’d like to use them. I got frustrated with trying to setup each box I had to how I wanted it and so I wrote an eselect module which should hopefully make configuration easier for everyone. You should be able to find it at app-admin/eselect-fontconfig and it should be pulled in by default if you have fontconfig on your system.

For a long time I’ve felt that the development has been very one sided, by one individual. No design review, no peer review just simple code dumps every few weeks or months. Feedback is always encouraged but never read and acted upon. Bug reports go ignored.

I brought this up in the past in on the HAL ML, here. Issues with another mandatory component of HAL having code stagnating and then big code drops were brought up by a Debian developer, countered by a Fedora developer, SuSE disproves the counter as do I and another Fedora developer disagree with the counter, all in all a fun thread. Then we have David making a big code drop to which, a Debian developer and I expressed similar concerns with on the thread. And on the #hal IRC channel,  another SuSE developer and Mandriva developer expressed similar concerns.

This was followed up by an IRC conversation with Rob Taylor which I have included here, the conversation takes place after receiving my reply to the last thread I’ve linked.

My biggest issue is that HAL and friends are suppose to be a FreeDesktop.org project that provides a simple and universal API to all DEs and really anything that needs hardware information and it’s designed behind closed doors and a lot of code is written behind closed doors. It’s depended on and used in projects when it’s not mature enough, for example GNOME using the 0.4 version of HAL. If David’s latest rewrite takes place that will be 3 full rewrites before it’s even hit 1.0.

Now if app was written in an open source manner, a lot of issues and problems could be addressed with the design from the get go and the code could be properly peer reviewed and we could move forward from there. Instead we have distros commonly shipping HAL with over a dozen some odd patches, not to mention the patches necessary to it’s associated utilities. I bring this point up for a very good reason, the front of FreeDesktop.org’s website states, “freedesktop.org is open source / open discussion software projects working on interoperability and shared technology for X Window System desktops.” Yet HAL developers will clearly admit that this project does not follow this principles and even argue that it should not follow those principles.

Because of these issues, I have given up on HAL and will no longer maintain it. In fact, I’m no longer interested in having it installed on my system. It’s time to choose another DE to use instead of GNOME.

• Do we really want to go with the PolicyKit route? Right now I’m leaning towards yes since this allows for granualar controls of permissions from HAL and future versions of HAL will require it so might as well bite the bullet. But this will require some more discussion with the other distro maintainers since David Zeuthen has pretty much disappeared from developement. If we go with PolicyKit that will require some more bits:
  • Document and explain PolicyKit and how it works and why it exists.
  • Work with Diego to merge in the necessary ConsoleKit bits into the PAM configuration. Test and evaluate the non-PAM routes for users like compnerd.
  • Clean up the few gotchas that testing has uncovered with PolicyKit.
• dberkholz, seemant, dang, leio and a few users in #gentoo-desktop have been having problems with the HAL version in Gentopia, we need to work with each of these users to resolve the issues and get those fixes into the ebuild or the code.
• Test KDE. No idea if it works with the new HAL.
• Document the new xorg-server interactions with HAL and how users can solve their configuration issues. Also work up some proper defaults if need be.
• Fix all the known memory leaks and merge the necessary patches from upstream and from the mailing list.
• Review all the issues that SuSE and Debian unstable have had in switching to HAL 0.5.10 and ensure we have all those use cases covered.
• Decide what our minimum supported kernel is. Technically, HAL supports as low as kernel 2.6.19 but there are still some issues.
• Publish a git tree with all of the patches

Right now the only machine that I have HAL working nicely on is running about 25 extra patches, all of which have been cherry picked from upstream or the ML or written by others to addresses issues we’ve found. I haven’t had the time necessary to do much maintenance and code writing for HAL so I’ve been a bit neglectful of the package.

I hope this answers everyone’s questions of what needs to happen with HAL 0.5.10 before it hits the tree.

Drop into a file and save it into /etc/hal/fdi/preprobe and viola, HAL will completely ignore this device and you will be all set.

Edit: I was asked to provide a license under which the above snippet is under. Basically, do with the above what you wish. So it’s under a 2-clause BSD license, copyright to me, Doug Goldstein (Doug Klima) effective from the date this post was made. A copy of a 2-clause BSD license is available at: http://www.freebsd.org/copyright/freebsd-license.html

Well you get the idea. We need a new Heimdal maintainer badly. Please e-mail Seemant and I if you’re interested it helping out. We’d sure appreciate it.

Oh and if you’re an MIT Kerberos guy, that’s ok too. MIT Kerberos maintenance could use a hand as well.

Heimdal bugs in Gentoo Bugzilla

After some debate in #gentoo-dev about a good syntax we have setted on the following:
<use> <!-- lang is optional, like in the rest of metadata fields -->
<flag name="disk-partition">Uses libparted from <pkg>sys-apps/parted</pkg> to read partition tables and in the future allow for partition table modification.</flag>
</use>

The new flags added are “use” which has an optional  lang attribute to specify additional languages. Then “flag” which does your heavy lifting via the name attribute. And lastly, I proposed adding “pkg” which would allow cross-linking/referencing from packages.gentoo.org (this was discussed with jokey) and additional apps like kuroo. The “pkg” tag would also be added to “longdescription”.

The final updated metadata.dtd can be seen at http://dev.gentoo.org/~cardoe/files/metadata.dtd and the diff at http://dev.gentoo.org/~cardoe/files/metadata.diff.