| View previous topic :: View next topic |
| Author |
Message |
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1480
|
 Posted: Mon Feb 25, 2013 3:15 pm Post subject: Canonical sponsored LTS-Linux-3.5.7.6 nobody? |
 |
|
https://bugs.gentoo.org/show_bug.cgi?id=458384
is marked wontfix because of the workload team gentoo-sources
I wonder if
ck-sources
pf-sources
could? |
|
| Back to top |
|
 |
eyoung100
Veteran
Joined: 23 Jan 2004
Posts: 1428
|
| Posted: Thu Feb 28, 2013 11:25 pm Post subject: |
|
|
Why are you upset that your request was dropped? Gentoo follows Kernel Development, as close or closer than any other flavor out there. The Kernel maintainers have their reason for WONTFIX in the link you provided:
| Herton Ronaldo Krzesinski wrote: | | ...as it is not anymore an stable series maintained upstream. |
If there is some option that you want from the 3.5 series fight for inclusion into a stable kernel that's still available, instead of asking our maintainers to maintain an obsolete branch. It's a lot easier to write a diff patch then it is to code an entire trunk...
5 branches between 2 maintainers, especially of kernel code is a Herculean Effort in my book.
_________________
The Birth and Growth of Science is the Death and Atrophy of Art -- Unknown
Registerd Linux User #363735
Adopt a Post | Strip Comments| Emerge Wrapper |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Fri Mar 01, 2013 12:09 am Post subject: |
|
|
| eyoung100 wrote: | | 5 branches between 2 maintainers, especially of kernel code is a Herculean Effort in my book. |
Do you mean the gentoo-sources stable look like the... Augean stables... ?
Well... if it's the case, it's not ulenrich's fault.
| ulenrich wrote: | I wonder if
ck-sources
could? |
I have been wondering too when I discovered the existence of the non-official extended support.
But I forgot about it when I discovered that my benchmarks were giving stock 3.5 less performing than 3.4 and 3.6
Considering in addition to this that 3.5-ext support will be over before 3.4's support... that there are no tarballs... I do not see any personal interest in following 3.5
However, if you are actually interested and have a good strong reason for willing a 3.5, I won't WONTFIX and am ready to reconsider my position.
(As far as the ck-sources are concerned of course)
EDIT : Hmmm... events such as http://seclists.org/oss-sec/2013/q1/420 are going to complicate things a little...
At least for the 3.5.7.6 I mean.
_________________
|
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1480
|
| Posted: Fri Mar 01, 2013 10:07 pm Post subject: |
|
|
@aCOSwt, I have not that much of a personal interest and I could patch linux sources to 3.5.7.6 myself. What I'd like to know is the policies of Gentoo regarding kernels. Because of the overload of "stable" there are some expectations from users:
- "stable" ebuild should compile and run with other "stable" packages
- "stable" should be running without errors
- "stable" software should be maintained regarding security issues
How is security achieved with EndOfLife kernels?
I just found out:
Now I see:
gentoo-sources-3.5.7-r1 has the backport of the
"Fix out-of-bounds access to sock_diag_handlers[] "
of your link! I now see for the really bad there is some Gentoo maintainance of the old kernels!
But if Gentoo maintainers do this work of backporting on their own, I would think this is more effort than to just merge the Ubuntu-Canonical LTS tree?
| Code: | * sock_diag: Fix out-of-bounds access to sock_diag_handlers[]
-- Brad Figg <brad.figg@canonical.com> Mon, 25 Feb 2013 |
And for the benefit there are a lot of additional evil bugs fixed in their LTS. I don't understand why there was constantly grumbling about Canonical not giving back and now there is just ignorance but not any recognition on our side. But this purely is a political argument!
I remember the Linux-3.5 tree was better fit and robust to be patched with the BFScheduler from Con Kolivas. Maybe that robustness of the 3.5 version costs some performance?
Now I run Linux-3.7 with RCU boost priority set higher and the timer down a bit to CONFIG_HZ_300=y , which results in a responsive system just like using BFS! Which is a quiet unintuitive change to Linux .config I found out for myself 
But this 3.7 Linux tree isn't supported upstream any more and Linux-3.8 is in beta baby state  |
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Sat Mar 02, 2013 11:42 am Post subject: |
|
|
| ulenrich wrote: | | - "stable" ebuild should compile and run with other "stable" packages |
Approximately yes. But, in order for this condition not to enter a dead-lock or chicken&egg problem, one package needs to be a starting point.
And that package is : The kernel.
I agree that, from a source distribution standpoint, this choice might appear questionable and could be challenged by the toolchain.
Anyway, apart from being buildable with last stable toolchain, the stability of the kernel must not depend on the stability of whatever package. Would it be drivers.
| ulenrich wrote: | | - "stable" should be running without errors |
Approximately yes. But this being absolutely impossible, this must be restricted to a particular kind of errors : Regressions.
A stable kernel should be running without regressions.
Upstream works like that too. Remember the stabilization of the 2.6.33 with regards to the data corruption generated by the journal-checksum mount option.
The bug was indeed severe. But... was already there in 2.6.32
The only difference was that T-Tso had made journal-checksum default with 2.6.33 so the problem was impacting much much more systems.
What did upstream do in order to stabilize 2.6.33 ? Solve the bug ? No !
T-Tso reverted the journal-checksum option to its not-default 2.6.32 status !
The error was still there uncorrected but... it was not a regression !
| ulenrich wrote: | | - "stable" software should be maintained regarding security issues |
Absolutely not ! Long-Term-Stable should ! Not Stable.
That is indeed what makes the difference between stable and LTS.
I agree that Gentoo does not get that LTS concept.
I think it is because the maintainers are personally responsible for their packages and just cannot guarantee they will never give up for whatever reason.
I am trying to introduce this concept with the 3.4 branch of the ck-sources but I know it is very fragile.
For the time being I have been able to design the patches needed to adapt the ck-patch to recent linux releases but... who knows for how long... could be possible that one day some linux patch for the 3.4 makes so I am no longer capable for whatever reason to adapt the ck-patch for this branch.
| ulenrich wrote: | | But if Gentoo maintainers do this work of backporting on their own, I would think this is more effort than to just merge the Ubuntu-Canonical LTS tree? |
When I took over the ck-sources package, I first looked for policies, directives...
I did not find many.
About all maintainers appear to be on their own with their package.
So the first policy I found is... the one I forged myself and is a basic of honesty towards users : Provide what you say you provide !
That might sound an evidence but it is rather important here.
I mean if your package claims "Full Linux 3.5 kernel sources with Con Kolivas' high performance patchset and Gentoo's genpatches." Then it is exactly what you get to provide.
How does this constraint things here ?
Well... strictly speaking... the canonical thingy (no disrespect) is *not* Linux 3.5 !
| Herton Ronaldo Krzesinski wrote: | | it will be for now a fork of latest 3.5.7 stable release |
I understand from this that It is a fork
So... can I feel authorized to provide something like "Canonical's fork of Linux-3.5 with Matthias Kohler's fork of Con Kolivas' high performance patchset & aCOSwt's patched genpatches" ?
Hmmm... I do not think so.
Well I mean not as what users know as ck-sources.
Look the pf-sources. They are not Linux based but they say it : "Linux kernel fork..." and even there, canonical cannot even be an option for the Gentoo package maintainer if his upstream does not provide it as an option.
The ck-sources are a little bit more free. The package is actually packaging. I mean we get no upstream.
But... there are limits on what we can feel authorized to package. And these limits are fixed by the definition of the package.
But I do get the intention to propose the Matthias Kohler's fork as an option when it gets... stabler!
_________________
|
|
| Back to top |
|
|
eyoung100
Veteran
Joined: 23 Jan 2004
Posts: 1428
|
|
| Back to top |
|
|
aCOSwt
Bodhisattva
Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space
|
| Posted: Sun Mar 03, 2013 6:31 pm Post subject: |
|
|
| eyoung100 wrote: | | Wow with that kind of response to back up your argument, I'm tempted to give the ck-sources a try |
You are welcome
_________________
|
|
| Back to top |
|
|
|
Kernel & Hardware
