Can somone bring the kernelsources from Ubuntu 6.06 LTS or debian-stable in portage as an stable alternative to vanilla- or gentoo-sources?
Our limited number of kernel maintainers is more that busy maintaining current kernels, why don't you keep such stuff in your overlay?
No, we aren't going to track other distro's kernels here in gentoo. I suggest just using their kernel sources if you like them so much :) Or, could you point out what you find in their kernels that you do not find in ours?
gregkh? wtf? > No, we aren't going to track other distro's kernels here in gentoo. since when? > Or, could you point out what you find in their kernels that you do not find in > ours? stability? 2.6-vanilla is more and more a garbage dump for experimental patches.
(In reply to comment #3) > > No, we aren't going to track other distro's kernels here in gentoo. > > since when? Do you see any other distro kernel packages in our ebuild tree? > > Or, could you point out what you find in their kernels that you do not find in > > ours? > > stability? 2.6-vanilla is more and more a garbage dump for experimental > patches. 2.6-vanilla merely tracks kernel.org. All distros base their kernel on that kernel, so if you are not liking the way the kernel is currently being developed, trying to track another distro's kernel will not help out very much.
(In reply to comment #4) > Do you see any other distro kernel packages in our ebuild tree? no more > 2.6-vanilla merely tracks kernel.org. All distros base their kernel on > that kernel, so if you are not liking the way the kernel is currently being > developed, trying to track another distro's kernel will not help out very > much. I'm looking for a kernel that not implement all new features from vanilla directly like kernels in Ubuntu 6.06 LTS or debian stable. They only bugfixing the kernel for longer times.
(In reply to comment #5) > > I'm looking for a kernel that not implement all new features from vanilla > directly like kernels in Ubuntu 6.06 LTS or debian stable. They only bugfixing > the kernel for longer times. That is something very different than what Gentoo offers for kernel packages. If you want to have something like this I suggest you use a different distro, as it is something that Gentoo does not have the resources to support at this time, sorry.
Reassigning.
*** Bug 350246 has been marked as a duplicate of this bug. ***
dE: You're more than welcome to attach an ebuild for debian-sources to this bug (see discussion in bug 349738).
Created attachment 258557 [details] .
Created attachment 258558 [details] .
Currently there're only 2 archs involved here... if you want more, do complaint.
Created attachment 258577 [details] debian-sources-2.6.32.ebuild This is improved ebuild for debian-sources - it uses vanilla tarball and Debian patches (this limits how much data is being downloaded and makes maintaining this easier). Please test.
Created attachment 258578 [details] debian-sources-2.6.32.ebuild More flexible config generation.
The ebuild fails to install (-) OK bugfix/all/vgaarb-fix-incorrect-der1 out of 1 hunk FAILED -- saving rejects to file arch/m68k/include/asm/siginfo.h.rej Error: Patch failed eference-of-userspace-pointe.patch (+) OK bugfix/all/stable/2.6.32.12-vgaarb.patch (+) FAIL bugfix/m68k/linux-2.6.git-5da3a65d2d1ba333d61999640ef241f150c69c6b.patch
Created attachment 260456 [details] Stabilized kernel.
Created attachment 260457 [details] debian-sources-2.6.32-r1.ebuild Adding ebuilds thah download a lot of binary data just to extract some configuration files is not going to happen. I've just fixed and tested the version that: - downloads vanilla kernel (we have it on mirrors already) - downloads and applies Debian patches. Try this one. Also: 2.6.37 is *experimental*.
The statement of the kernel team remains as is: > No, we aren't going to track other distro's kernels here in gentoo. We, the kernel team, rather pursue supporting our own kernels better. Don't get me wrong, I'm not against it being added if maintained properly... We need a good dedicated maintainer for a package like this, we can't just add it and never look back; adding a package means that someone has to maintain it and bump it with new versions as well as support any bugs that arise from it. If anyone is willing to do this, please do so; if you don't have the privileges and want to proxy maintain instead then feel free to contact us by answering on this bug. A good start would be to update the ebuild to reflect their latest version and bump it to 2013 copyright, EAPI 5 and clean up the src_prepare function where possible; maybe you can get a kernel-2 maintainer to take a look and tell you which things can actually be more easily done through the kernel-2 eclass. Given there is barely any request for this, the bug has been around for years and nobody seems to be supporting or maintaining this; multiple Bugday developers have agreed to close this for now...
