Of course, I will revisit when upstream feels it’s ready to be tested in distributions once again.
Keeping with the theme of ‘Gentoo is about choice” I’ve added the ability for users to include kdbus into their gentoo-sources kernel. I wanted an easy way for gentoo users to test the patchset while maintaining the default installation of not having it at all.
In order to include the patchset on your gentoo-sources you’ll need the following:
1. A kernel version >= 4.1.0-r1
2. the ‘experimental’ use flag
3. the ‘kdbus’ use flag
I am not a systemd user, but from the ebuild it looks like if you build systemd with the ‘kdbus’ use flag it will use it.
Please send all kdbus bugs upstream by emailing the developers and including firstname.lastname@example.org in the CC .
Read as much as you can about kdbus before you decided to build it into your kernel. There have been security concerns mentioned (warranted or not), so following the upstream patch review at lkml.org would probably be prudent.
When a new version is released, wait a week before opening a bug. Unless I am on vacation, I will most likely have it included before the week is out. Thanks!
NOTE: This is not some kind of Gentoo endorsement of kdbus. Nor is it a Mike Pagano endorsement of kdbus. This is no different then some of the other optional and experimental patches we carry. I do all the genpatches work which includes the patches, the ebuilds and the bugs therefore since I don’t mind the extra work of keeping this up to date, then I can’t see any reason not to include it as an option.
Here’s a snap shot of my system running 3.12.30-gentoo sources and google chrome version 39.0.2171.19_p1.
$ equery l google-chrome-beta
* Searching for google-chrome-beta …
[IP-] [ ] www-client/google-chrome-beta-39.0.2171.19_p1:0
Team members working alongside upstream (and downstream) developer Greg k-h have decided to no longer request stabilization of the vanilla sources kernel. Team members and arch teams (understandably) are unable to keep up with the 1-2 weekly kernel releases (per version), and therefore will now direct users to always run the latest vanilla sources, or to run gentoo-sources for a fully Gentoo supported kernel. We will continue to do our best effort to request and get stabilized g-s versions.
1. Upstream release rate is now a much higher 1-2 kernels a week.
2. Very frequently, these releases contain security fixes.
3. This rate of release puts arch teams in a difficult position, since it is unsustainable to try to keep up to date with stabilization
4. By continuing the policy of providing a stable vanilla kernel version, Gentoo is giving a false sense of security to its users, since by the time the
kernel does get stabilized, a newer version with more security fixes is almost always already released
Eventually, we will be updating our project pages to reflect these changes.]]>
My goal was to get the patch 2.7 / 3.X compatible. It should apply against most of the later kernels, as this script has not changed in awhile.
Guys, please take a look at the newest patch, I have incorporated the suggested changes.]]>
This time, I got 26 people responding offering their help. Four of which are currently Gentoo developers. First, I’d like to thank everyone that responded. I was extremely surprised.
Now, since I cannot mentor 22 people at the same time I need to think of a plan. I’m hoping to lean on the Gentoo developers, as they are already developers and will need a fraction of the instructions that the others will. This is not a slight on anyone’s ability, just the whole Gentoo Way(tm) thing will not have to be taught to these folks. They can also commit todayfor eclass changes and bump kernels as needed. Also, if everything goes well, they can help me mentor who from the other 19 want to follow through the entire process.
I’m going to try to get everyone started triaging bugs and then go from there. Thanks again, everyone. Expect an email from me very soon.
Maintaining the kernel consists of a few jobs:
– Bumping Gentoo sources to keep consistent with upstream releases. I can only support three versions (used to be 2 version supported, with more people) of the kernel at any time. Right now I try to support 3.0, 3.2 and 3.4. When 3.5 comes out, one of those will drop off.
– Kernel Bugs. At the least, I try to help identify patches from upstream to back port to supported kernels to solve issues. Actually digging into kernel code to solve issues is the most time consuming part of the job. Unfortunately, my time constraints lately don’t allow much time for this anymore. The time to dig deeply and solve these issues is always an unknown, and better steered to keeping up to date kernels available for Gentoo as I am the only person.
I would like someone who at least thinks she/he is going to stick around for awhile. The last few people who were on the kernel team lasted around 6 months.
I’m going to steal an old developers call for help:
I’m looking for someone with at least:
– Interest in kernel stuff, or a desire to become interested
– Time to put towards the tasks
– Enthusiasm to ask lots of questions rather than let stuff sit around
– Basic experience with Bugzilla
– Basic kernel experience (i.e. you can compile your own)
Having knowledge of kernel internals or experience with kernel hacking are NOT requirements because if you have time, interest and ask a lot of questions then these will come anyway. A lot of the work doesn’t involve technical stuff, plus I was certainly very clueless about all this when I originally got involved a few years ago.
Being an existing Gentoo developer is not a requirement. Most of the work is done on Bugzilla and via email. This may be a good opportunity to get involved with development and later become a Gentoo developer for those that are interested.
It’s an enjoyable task, you get to interact with a lot of very intelligent people upstream and you end up learning a lot.
If you think you’re interested, you can email me or find me on IRC at #gentoo-kernel]]>
Thanks for wired for pointing this out. I will be removing the ones from yesterday.
The following kernels now contain the fix:
I plan on creating releases for additional kernels with this patch through the day.
See the link for more info on the privilege escalation.
The following kernel versions contain the patch: