On Wed, 2011-06-08 at 13:29 +0100, Peter Robinson wrote:
On Wed, Jun 8, 2011 at 1:23 PM, Chris Tyler chris@tylers.info wrote:
On Wed, 2011-06-08 at 09:54 +0200, Dan HorĂ¡k wrote:
Similar package (fake-build-provides [1], [2]) is required in koji on platforms where 32bit userspace lives with 64bit-only kernel (sparc and s390x) so I may be worth adding such package to the collection and track the changes in dist-git instead of using an ad-hocs rpms.
Shouldn't fake-kernel be a subpackage of kernel?
Certainly seems to be the obvious way to deal with it.
That sounds reasonable and obvious, but I was thinking that wouldn't fly with the kernel maintainers...how about we ask them (copied).
Folks: we currently don't have a kernel package in Fedora ARM. Several people are working on fixing this by working on kernel images that support various targets, and it will be excellent to get to a point where we can ask you to endorse a couple of subpackage ARM kernel variants like -omap perhaps by having a branch on the official kernel package that can carry some of the bits being worked on in a more official capacity than them living in separate packages, eventually.
That will combine with support for ARM kernel unification and DeviceTree upstream so that eventually, we can do a single kernel image for most/many ARM systems (esp. v7 systems). But for some while yet, there will be some systems for which we have no useful ARM kernel package. Currently, Fedora ARM carries a special package that just provides fake deps (and we're not alone in this, other secondaries have fake deps packages for other stuff, so there is precedent for doing this).
What do the kernel maintainers think about having a kernel subpackage that just provides fake deps as part of the main kernel package?
Jon.
On Wed, Jun 08, 2011 at 11:14:56AM -0400, Jon Masters wrote:
Folks: we currently don't have a kernel package in Fedora ARM. Several people are working on fixing this by working on kernel images that support various targets, and it will be excellent to get to a point where we can ask you to endorse a couple of subpackage ARM kernel variants like -omap perhaps by having a branch on the official kernel package that can carry some of the bits being worked on in a more official capacity than them living in separate packages, eventually.
...
You want a distribution that can't be supported by the standard kernel package? That sounds like an absolute security nightmare.
On Wed, 2011-06-08 at 16:27 +0100, Matthew Garrett wrote:
On Wed, Jun 08, 2011 at 11:14:56AM -0400, Jon Masters wrote:
Folks: we currently don't have a kernel package in Fedora ARM. Several people are working on fixing this by working on kernel images that support various targets, and it will be excellent to get to a point where we can ask you to endorse a couple of subpackage ARM kernel variants like -omap perhaps by having a branch on the official kernel package that can carry some of the bits being worked on in a more official capacity than them living in separate packages, eventually.
You want a distribution that can't be supported by the standard kernel package?
Nope. Where did I say I want that?
What I said was that there is no official kernel package for Fedora ARM systems at the moment, so everyone rolls their own. We've got a test kernel package in the works for omap systems, and will add perhaps one or two more before ultimately upstream efforts at devicetree allow for a single kernel image to be properly supported. Depending on timing, I would like to have e.g. an official kernel-arm-omap subpackage on the main kernel, just with the OMAP config options turned on.
The current test kernel is just a stock F15 kernel with a few config changes, and a single patch to fig a power regulation bug. I think it won't be too long before we can ask to get an official subpackage of the main Fedora kernel to carry these bits rather than the interim test status they have at the moment. But none of this was really why I sent the mail :) We'll get to a point where Fedora ARM can use a single standard kernel binary in due course, but until then (and for other use cases) I think there's value in perhaps considering having a fake provides kernel subpackage for those systems that need "kernel" deps but aren't going to or cannot run the stock Fedora kernel.
That sounds like an absolute security nightmare.
It's no different than you building a test kernel and posting it out for people to play with. Fedora ARM is a secondary arch. There is no official kernel (yet). We want to change this. It doesn't get changed unless test kernel images are built and things like device tree setup are figured out prior to eventually requesting a merge into the official Fedora kernel config. I'm all for pushing bits into the official kernel as quickly as possible, but it's just not quite ready for this yet.
Jon.
On Wed, Jun 08, 2011 at 01:54:29PM -0400, Jon Masters wrote:
The current test kernel is just a stock F15 kernel with a few config changes, and a single patch to fig a power regulation bug. I think it won't be too long before we can ask to get an official subpackage of the main Fedora kernel to carry these bits rather than the interim test status they have at the moment. But none of this was really why I sent the mail :) We'll get to a point where Fedora ARM can use a single standard kernel binary in due course, but until then (and for other use cases) I think there's value in perhaps considering having a fake provides kernel subpackage for those systems that need "kernel" deps but aren't going to or cannot run the stock Fedora kernel.
I'm clearly misunderstanding. If you have your own kernel images, why do you need the fake ones?
On Wed, 2011-06-08 at 19:09 +0100, Matthew Garrett wrote:
On Wed, Jun 08, 2011 at 01:54:29PM -0400, Jon Masters wrote:
The current test kernel is just a stock F15 kernel with a few config changes, and a single patch to fig a power regulation bug. I think it won't be too long before we can ask to get an official subpackage of the main Fedora kernel to carry these bits rather than the interim test status they have at the moment. But none of this was really why I sent the mail :) We'll get to a point where Fedora ARM can use a single standard kernel binary in due course, but until then (and for other use cases) I think there's value in perhaps considering having a fake provides kernel subpackage for those systems that need "kernel" deps but aren't going to or cannot run the stock Fedora kernel.
I'm clearly misunderstanding. If you have your own kernel images, why do you need the fake ones?
Ah, ok. The point is that we can't support every target yet[0] and are focusing e.g. on OMAP3/4 (BeagleBoard and PandaBoard) in the test kernel available so far. For everyone else, it's desired to have something that satisfies RPM about kernel deps and allows things like dracut to install. All of this works great once the fake deps are in place - I've a system booting with root encrypted LVM with dracut on F13 for example, but the kernel itself is for Freescale iMX5 and not in RPM format yet.
Jon.
[0] Existing ARM kernels are hard to build generically as you know. This is changing and we'll be at a point sooner than later where many of the major targets we care about can be supported in a single kernel image.
On Wed, Jun 08, 2011 at 02:35:55PM -0400, Jon Masters wrote:
Ah, ok. The point is that we can't support every target yet[0] and are focusing e.g. on OMAP3/4 (BeagleBoard and PandaBoard) in the test kernel available so far. For everyone else, it's desired to have something that satisfies RPM about kernel deps and allows things like dracut to install. All of this works great once the fake deps are in place - I've a system booting with root encrypted LVM with dracut on F13 for example, but the kernel itself is for Freescale iMX5 and not in RPM format yet.
So why not provide the fake-kernel package from the kernel SRPM you do have? If you have your own non-mainline packages then it makes more sense to put the hacks there than it does to put them in the mainline distribution.
Matthew Garrett wrote:
On Wed, Jun 08, 2011 at 02:35:55PM -0400, Jon Masters wrote:
Ah, ok. The point is that we can't support every target yet[0] and are focusing e.g. on OMAP3/4 (BeagleBoard and PandaBoard) in the test kernel available so far. For everyone else, it's desired to have something that satisfies RPM about kernel deps and allows things like dracut to install. All of this works great once the fake deps are in place - I've a system booting with root encrypted LVM with dracut on F13 for example, but the kernel itself is for Freescale iMX5 and not in RPM format yet.
So why not provide the fake-kernel package from the kernel SRPM you do have? If you have your own non-mainline packages then it makes more sense to put the hacks there than it does to put them in the mainline distribution.
Because presumably, the goal is that the ARM kernel they *do* build is built using an unmodified kernel spec. We do have ARM bits in the spec right now.
On Wed, 2011-06-08 at 11:14 -0400, Jon Masters wrote:
What do the kernel maintainers think about having a kernel subpackage that just provides fake deps as part of the main kernel package?
Anyway. To get back to the point...there are some systems that cannot run a stock Fedora kernel yet or need fake kernel deps for other reasons. Is there any fundamental objection to the fake-kernel package being integrated by way of an official kernel sub-package? (perhaps even selectively buildable and not built by default on e.g. x86?).
Jon.
Jon Masters wrote:
On Wed, 2011-06-08 at 11:14 -0400, Jon Masters wrote:
What do the kernel maintainers think about having a kernel subpackage that just provides fake deps as part of the main kernel package?
Anyway. To get back to the point...there are some systems that cannot run a stock Fedora kernel yet or need fake kernel deps for other reasons. Is there any fundamental objection to the fake-kernel package being integrated by way of an official kernel sub-package? (perhaps even selectively buildable and not built by default on e.g. x86?).
Do not want. This is just as easily accomplished by a separate spec that doesn't clutter up the official kernel spec even further than it already is.
A kernel-none package would, however, be potentially amusing to even relatively sane arches like x86. Install the kernel-none variant, and you don't get kernel updates via yum, which may be desired, if you're running your own locally built kernel and don't want the bootloader constantly being updated to point to the newly installed kernel rpm when you really want the locally built kernel to keep being the default boot kernel... But this has no way of working in Anaconda, which is another reason why I think it has no place in the actual kernel spec. I presume people "installing" on ARM are creating an image on another host, rather than actually running through an anaconda install.
On Wed, 2011-06-08 at 14:15 -0400, Jarod Wilson wrote:
Jon Masters wrote:
On Wed, 2011-06-08 at 11:14 -0400, Jon Masters wrote:
What do the kernel maintainers think about having a kernel subpackage that just provides fake deps as part of the main kernel package?
Anyway. To get back to the point...there are some systems that cannot run a stock Fedora kernel yet or need fake kernel deps for other reasons. Is there any fundamental objection to the fake-kernel package being integrated by way of an official kernel sub-package? (perhaps even selectively buildable and not built by default on e.g. x86?).
Do not want. This is just as easily accomplished by a separate spec that doesn't clutter up the official kernel spec even further than it already is.
That's fine, it's ok in a separate package. I just wanted to raise it.
A kernel-none package would, however, be potentially amusing to even relatively sane arches like x86. Install the kernel-none variant, and you don't get kernel updates via yum, which may be desired, if you're running your own locally built kernel and don't want the bootloader constantly being updated to point to the newly installed kernel rpm when you really want the locally built kernel to keep being the default boot kernel... But this has no way of working in Anaconda, which is another reason why I think it has no place in the actual kernel spec.
Good points. I generally add kernel to the excludes line in my x86 yum configs, which achieves similar but I still think there are similar uses for this even if that particular one can be handled elsewhere.
For installing, yea, there needs to be a kernel package that at least supports some targets, which is where this is headed. For example, I see a general ARMv7 kernel that supports a good subset of targets as the most likely option in the medium term. I don't see it likely that we'd have a one size fits all kernel image in the next few weeks :)
I presume people "installing" on ARM are creating an image on another host, rather than actually running through an anaconda install.
Right. At the moment, there are scripts to generate a rootfs (and I will be posting a more up to date rootfs example image with pre-canned kernel and bits for some targets soon), but the goal is to get to a point:
1). Where the rootfs image can be generated using appliance creation tools that already exist, since many boards are similarly used.
2). Eventually, where we have support for standard installation. I suspect that would be using a kernel that supports major systems, but where if you have something more exotic, you still install the fake dependency package (after perhaps building an image) on your own.
So would you ACK the importation of such a fake dep package? If it comes up for debate?
Jon.
Jon Masters wrote:
On Wed, 2011-06-08 at 14:15 -0400, Jarod Wilson wrote:
Jon Masters wrote:
On Wed, 2011-06-08 at 11:14 -0400, Jon Masters wrote:
What do the kernel maintainers think about having a kernel subpackage that just provides fake deps as part of the main kernel package?
Anyway. To get back to the point...there are some systems that cannot run a stock Fedora kernel yet or need fake kernel deps for other reasons. Is there any fundamental objection to the fake-kernel package being integrated by way of an official kernel sub-package? (perhaps even selectively buildable and not built by default on e.g. x86?).
Do not want. This is just as easily accomplished by a separate spec that doesn't clutter up the official kernel spec even further than it already is.
That's fine, it's ok in a separate package. I just wanted to raise it.
A kernel-none package would, however, be potentially amusing to even relatively sane arches like x86. Install the kernel-none variant, and you don't get kernel updates via yum, which may be desired, if you're running your own locally built kernel and don't want the bootloader constantly being updated to point to the newly installed kernel rpm when you really want the locally built kernel to keep being the default boot kernel... But this has no way of working in Anaconda, which is another reason why I think it has no place in the actual kernel spec.
Good points. I generally add kernel to the excludes line in my x86 yum configs, which achieves similar but I still think there are similar uses for this even if that particular one can be handled elsewhere.
Oh, duh. That's saner in that it does require this hack, and it does leave you with a fallback distro-provided kernel. But in the ARM case, the distro-provided kernel might not be bootable, so this method just wastes space and adds a non-functional boot target...
So would you ACK the importation of such a fake dep package? If it comes up for debate?
Does it really need to go into the main package repo? Aren't most secondary arches maintaining a handful of arch-specific bits in their own tree already anyway? I suppose long-term, and for it to be a reasonable option for other use cases, it should be in the main repo. I suppose I could get behind that idea.
On Wed, Jun 08, 2011 at 02:15:15PM -0400, Jarod Wilson wrote:
Do not want. This is just as easily accomplished by a separate spec that doesn't clutter up the official kernel spec even further than it already is.
+1.
Frankly, I've been tired enough having to maintain config files for ia64, powerpc, sparc, and arm over the last few years when all they need is kernel-headers. (Note to self, drop ia64 entirely now...) [Note, I don't mean to sound entirely negative here, but in reality it's an awful nuisance for nothing, and waiting for the port people to fix it would just delay my ability to put out updates.]
I'll be posting the split out kernel-noarch spec this week, which should rectify building kernel-doc and kernel-headers, without needing to go through the half-hearted rigamarole to do it now.
We can probably cram the fake kernel crud in there for you, but I definitely don't want it in the main kernel spec. I also don't really know why you don't just build your sub-arch kernels as packages in your secondary build system until you get promoted, but that's your decision...
--Kyle
On Wed, 2011-06-08 at 14:59 -0400, Kyle McMartin wrote:
I'll be posting the split out kernel-noarch spec this week, which should rectify building kernel-doc and kernel-headers, without needing to go through the half-hearted rigamarole to do it now.
Great! Also +1 to considering the fake deps subpackage in there.
We can probably cram the fake kernel crud in there for you, but I definitely don't want it in the main kernel spec. I also don't really know why you don't just build your sub-arch kernels as packages in your secondary build system until you get promoted, but that's your decision...
There are kernel packages being built in the ARM koji and more work will be done, but it's not as straightforward (yet) as building a single RPM package for all possible ARM systems people might choose to use. Until that point, there will be people who can't install the standard kernel package, need to build their own, and just want the dependencies. Like I said, most of the main systems will be supportable in a single kernel RPM in due course, and we can come asking about config changes, etc. that we need later on to roll this back into the standard kernel.
Another question for you, related to this. David Marlin (dmarlin) is currently working on the OMAP kernel packages. He's based his SPEC and sources on F15 and the plan is to basically track the F15 kernel until such time as we're ready to ask to integrate whatever will be integrated back into the official kernel package. He's looking at using split-out kernel config files - can I point him to you and get you to help him figure out how those work? (he wants to make sure he's able to regenerate the config files and merge for building, etc.)
Jon.
On Wed, Jun 08, 2011 at 03:09:55PM -0400, Jon Masters wrote:
We can probably cram the fake kernel crud in there for you, but I definitely don't want it in the main kernel spec. I also don't really know why you don't just build your sub-arch kernels as packages in your secondary build system until you get promoted, but that's your decision...
There are kernel packages being built in the ARM koji and more work will be done, but it's not as straightforward (yet) as building a single RPM package for all possible ARM systems people might choose to use. Until that point, there will be people who can't install the standard kernel package, need to build their own, and just want the dependencies. Like I said, most of the main systems will be supportable in a single kernel RPM in due course, and we can come asking about config changes, etc. that we need later on to roll this back into the standard kernel.
I guess I'm confused by what you are doing. I understand the end result, but not how you're getting there. Do you have many subarch-dependent SRPMs or just a bunch of subarch-dependent binary RPMs from a single package? (I can see why the former would be a problem for you, since there's no one place to add the empty pseudopackage.)
I'll go look for myself though.
Another question for you, related to this. David Marlin (dmarlin) is currently working on the OMAP kernel packages. He's based his SPEC and sources on F15 and the plan is to basically track the F15 kernel until such time as we're ready to ask to integrate whatever will be integrated back into the official kernel package. He's looking at using split-out kernel config files - can I point him to you and get you to help him figure out how those work? (he wants to make sure he's able to regenerate the config files and merge for building, etc.)
Yeah, I'm more than happy to answer whatever I can, although the kernel.spec is mostly tribal knowledge and evolution, so it's entirely possible no one will know answers. ;-) You may also want talk to the people who had been maintaining the Xen branch with how they coped with things changing under them.
--Kyle
kernel@lists.fedoraproject.org