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:
There is a serious bug introduced in the 3.1.0 code. The Gentoo Kernel Team advises any of our RAID10 users running 3.1.0 (vanilla or gentoo-sources) to patch their kernel or immediately upgrade to gentoo-sources-3.1.0-r1 which includes the upstream patch to correct the issue.
Upstream considers this a “serious flaw”.
From the original patch submission on LKML:
“Anyone running RAID10 with 3.1 is advised to either apply this patch or revert an earlier kernel as soon as possible. In the mean time, remove any hot spares from an RAID10 array.”
From the patch:
“It would normally be possible to recover the data, but that would need care and is not guaranteed.”
Summary: RAID10 3.1.0 kernel users, please upgrade to gentoo-sources-3.1.0-r1 or patch your kernel manually.]]>
Currently, deblob support is not available due to the kernel tarball being named 3.0 and the deblob script being 3.0.0. The eclass needs to be looked at to see how to handle this. It would be helpful if everything was named either 3.0 or 3.0.0. A mix makes things a bit more challenging.]]>