I blog so rarely these days. So, in the beginning (100 000 bugs ago) there was Daniel Robbins who got all the incoming bugs and he assigned them. Then Gentoo grew to 15-20 developers and I came along and we created bug-wranglers to handle the majority of incoming bugs (that are not recruiters, devrel or infrastructure related). As of a few weeks ago we created two new aliases: maintainer-wanted and maintainer-needed. The first is to put all the “this is a new package, I want it in portage, and optionally I’ve attached an ebuild” bugs. The second is for packages that are pretty much orphaned and unloved in the portage tree. Among the second list was openAFS. Then along came Stefaan De Roeck (don’t click, you probably can’t see that bug anyway). And he spent a few weeks combing through all the openAFS issues, and came up with two brand new ebuilds (no packages.gentoo link yet because I just finished committing them to portage for him) to fix all those issues.
A few things of note about the new openafs stuff (1.2.13 for the 2.4 kernel users and 1.3.85 for the sexy users (2.4 or 2.6, doesn’t matter). There are now three packages. That’s right, I said 3. We have openafs-kernel, which serves the purpose of not having to recompile openafs everytime you install a new kernel. Now, you have a much smaller compile of just the kernel module. Additionally, openafs itself now installs into FHS-correct locations (instead of crap like /usr/afs and /usr/visi or whatever that was). There are those who vehemently disagree with any sort of fhs-correctness for packages like heimdal and openafs, but I personally am not totally convinced. I’d rather see patches and correct ebuilds and problems with current ebuilds — like actual problems caused by current ebuilds.
So, that brings us to this: what about those legacy binary-only type programmes that expect openafs in its old locations???? Well, that’s easy: Stefaan created openafs-legacy to install all sorts of symlinks to bugger your filesystem up with /usr/afs and the like.
In sum, please test, please report.
Hmm… I did not know Gentoo bugzilla had “confidential” bugs.
What is the reason for this ?
cool i have been wondering how OpenAFS was going.
just installing this now.
is there a primary bug i can report my results on?
Hi Ivan,
Yes Gentoo does indeed have some confidential bugs. There are a few circumstances where this is necessary. From a developer-relations (devrel) standpoint, there are certain times when a developer you’re hiring or who is under review or whatever who might not want some information disclosed to the general public.
From a security standpoint — sometimes upstream projects discover a vulnerability that is being addressed. They do notify distributors via certain mailing lists, etc, but request that the vulnerability is disclosed on their own schedule (while a fix is being worked out etc). Because we do play nice with upstream and others, we like to co-operate. Hence, some security bugs are private/confidential. As soon as a fix opens up, we open up a public counterpart bug, so everything does get disclosed later.
I hope you’re not alarmed. Indeed I hope that you can see the necessity for confidentiality in some certain situations. Having said that Stefaan’s recruitment bug is now open to the public 🙂
Rendhalver!
I think the best would be to open a new bug, because the new releases basically address 18 months (or more!) worth of bugs in bugzilla. I believe there are twelve or so in total bugs being addressed. So we may as well open a new one, unless something in those bugs has not been fixed. The openafs stuff I think is all assigned to stefaan (at his non-gentoo address).