hello guys
any reason to not include fake-kernel into respository ?
http://hongkong.proximity.on.ca/yum/source/12/arm/fake-kernel-provides-1.0.0...
On Mon, 2011-06-06 at 23:35 -0400, Itamar Reis Peixoto wrote:
hello guys
any reason to not include fake-kernel into respository ?
http://hongkong.proximity.on.ca/yum/source/12/arm/fake-kernel-provides-1.0.0...
Yes... it's not in the Fedora package collection. Feel free to tackle that one :-)
-Chris
On 06/07/2011 01:24 AM, Chris Tyler wrote:
On Mon, 2011-06-06 at 23:35 -0400, Itamar Reis Peixoto wrote:
hello guys
any reason to not include fake-kernel into respository ?
http://hongkong.proximity.on.ca/yum/source/12/arm/fake-kernel-provides-1.0.0...
Yes... it's not in the Fedora package collection. Feel free to tackle that one :-)
-Chris
They shouldn't have problems with arch-specific packages. After all I can see "microcode_ctl" being very useful under ARM. :-)
Jeff
On Tue, 2011-06-07 at 01:24 -0400, Chris Tyler wrote:
On Mon, 2011-06-06 at 23:35 -0400, Itamar Reis Peixoto wrote:
hello guys
any reason to not include fake-kernel into respository ?
http://hongkong.proximity.on.ca/yum/source/12/arm/fake-kernel-provides-1.0.0...
Yes... it's not in the Fedora package collection. Feel free to tackle that one :-)
I think it's worth noting that work is ongoing to create some standard kernel packages. David Marlin (copied) is going to post an updted yum repo containing an up-to-date OMAP v7-based kernel soon. This can just be installed and will pull in a kernel supporting Beagle/Panda. We'll get to other kernels in due course...and that's not to say nobody should look into the fake-kernel-provides use case either. Perhaps it will help other architectures in due course (who knows what will come - tile? :) )
Jon.
Jon Masters píše v St 08. 06. 2011 v 03:20 -0400:
On Tue, 2011-06-07 at 01:24 -0400, Chris Tyler wrote:
On Mon, 2011-06-06 at 23:35 -0400, Itamar Reis Peixoto wrote:
hello guys
any reason to not include fake-kernel into respository ?
http://hongkong.proximity.on.ca/yum/source/12/arm/fake-kernel-provides-1.0.0...
Yes... it's not in the Fedora package collection. Feel free to tackle that one :-)
I think it's worth noting that work is ongoing to create some standard kernel packages. David Marlin (copied) is going to post an updted yum repo containing an up-to-date OMAP v7-based kernel soon. This can just be installed and will pull in a kernel supporting Beagle/Panda. We'll get to other kernels in due course...and that's not to say nobody should look into the fake-kernel-provides use case either. Perhaps it will help other architectures in due course (who knows what will come - tile? :) )
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-hoc rpms.
Dan
[1] http://s390.koji.fedoraproject.org/koji/packageinfo?packageID=9724 [2] http://sparc.koji.fedoraproject.org/koji/packageinfo?packageID=10709
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?
-Chris
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.
Peter
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 Wednesday, June 08, 2011 10:14:56 AM Jon Masters wrote:
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).
It likely wont fly with the kernel folks. different arches that do not have a kernel do have need to provide it to the buildroot, We should have a fake- build-provides package in fedora scm so that its a co-ordinated effort, but we should not ship it. like we do not ship glibc32 and glibc64 arm is in an akward position where people need to provide thier own kernel. best bet right now is to work on getting some useable kernels out there.
Dennis
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.
On Wed, 2011-06-08 at 03:20 -0400, Jon Masters wrote:
On Tue, 2011-06-07 at 01:24 -0400, Chris Tyler wrote:
On Mon, 2011-06-06 at 23:35 -0400, Itamar Reis Peixoto wrote:
hello guys
any reason to not include fake-kernel into respository ?
http://hongkong.proximity.on.ca/yum/source/12/arm/fake-kernel-provides-1.0.0...
Yes... it's not in the Fedora package collection. Feel free to tackle that one :-)
I think it's worth noting that work is ongoing to create some standard kernel packages. David Marlin (copied) is going to post an updted yum repo containing an up-to-date OMAP v7-based kernel soon. This can just be installed and will pull in a kernel supporting Beagle/Panda. We'll get to other kernels in due course...and that's not to say nobody should look into the fake-kernel-provides use case either. Perhaps it will help other architectures in due course (who knows what will come - tile? :) )
Actually copying David :)
Jon.