Installs the redhat enterprise kernel from source RPM.
Created attachment 45947 [details] Redhat kernel 2.4.21-9.0.3
Created attachment 45948 [details] Redhat kernel 2.4.21-15.0.4
Required by TSM server (see bug http://bugs.gentoo.org/show_bug.cgi?id=74337) and IBMtape device drivers (see bug http://bugs.gentoo.org/show_bug.cgi?id=74335)
this is actually the second suggestion I have had with this. Unfortauntely, I cant justify its addition to the portage tree. Mostly due to its unsupportability. If someone is willing to break out the specific 3ES patches, then this would be more viable. I do however thank you for your work, and will not close it until I have heard your comments. This will always be considered for the future. Regards, John
I don't mind stripping out the patches and creating a tarball of them separately if necessary. I thought that using the RPM was the easiest solution, but I realise that it probably doesn't fit into the way gentoo distributes its kernels. Would it help if I rewrote the ebuild so that it uses the vanilla 2.4.21 as a base and contains the patches (or a tarball of patches) in the files directory? If you can give me a pointer to some docs on how gentoo kernel ebuilds should be coded I can try and redo it so its compatible.
Hi baz. Further to the email you just sent - yeah the structure of mm-sources is much more reasonable. If you are able to obtain the patches in a breoken-out manner (individual patches rather than 1 big patch) it would be the most ideal. In that situation we are able to look at applying just the 3ES stuff, and ignoring some of the other junk in there. Regards, John
I've created an ebuild for the latest redhat 3ES kernel, 2.4.21-27.0.1. I've redone the ebuild to use the kernel-2 eclass and have extracted the patches from the RPM and tar-bz2'd them (they are currently in my gentoo web space, see SRC_URI). The only other attachment is a small tar.bz2 file that contains the redhat supplied config files. I wrote a small script that parses the redhat spec file and extracts the patch order number, which is then prepended to the patch names as found in the patch tarball. This is to ensure patches are applied in the desired order. Hopefully this is a more acceptable format for the ebuild. Its the first time I've used the kernel-2 eclass so please excuse any misuse of its functionality.
Created attachment 48365 [details] Ebuild for redhat enterprise kernel 2.4.21-27.0.1
Created attachment 48366 [details] tarball of redhat kernel configs
We aren't developing against 2.4 at the moment and are trying to avoid adding more kernels to portage.
