base kernel to build fedora
jwboyer at gmail.com
Mon May 24 23:09:48 UTC 2010
On Mon, May 24, 2010 at 11:31:09PM +0200, Tomasz Torcz wrote:
>On Mon, May 24, 2010 at 01:14:07PM -0700, Jesse Keating wrote:
>> On Mon, 2010-05-24 at 13:01 +0100, Richard W.M. Jones wrote:
>> > On Sun, May 23, 2010 at 04:45:49PM -0500, Bruno Wolff III wrote:
>> > > People already ready run scripts to look for FTBFS packages now. Having to
>> > > deal with all of these at once would be a real problem. Doing this this way
>> > > allows us to spread out the fixing over time.
>> > The problem isn't FTBFS packages, but packages that require devious
>> > workarounds because Koji isn't quite like any other distro out there.
>> > Koji is a Fedora userspace running on top of a RHEL 5 kernel. This
>> > tests out all sorts of strange and interesting paths inside glibc,
>> > because glibc emulates a lot of system calls which didn't exist in
>> > RHEL 5. While extra testing is usually great, it's not clear that
>> > dumping this testing on to package maintainers is a good thing,
>> > particularly since Koji is about the only real world case where people
>> > actually run mismatched userspace and kernel like this. (There is no
>> > distro that I know of that advocates running a brand new userspace on
>> > top of an old kernel -- but please correct me if I'm wrong about
>> > that).
>> While building in vms is starting to make sense on x86, it still doesn't
>> make sense (or not possible) on other arches like ppc, s390, arm, sparc,
>> ia64, etc... So building for those arches is going to continue to use
>> the mock path, which means if we don't do it for x86, we're going to run
>> into these odd code paths on even "odder" arches and make keeping those
>> up and running even harder.
> + some mail-list disscussion about KVM on SPARC.
> It is certainly possible. Often in experimental state, but nevertheless.
>We have the technology for VMs.
Actually, we don't for PowerPC. Right now, you have two options for virt on
1) kvm for PPC 440. Fedora doesn't support PPC 440 (it could, but it's an
embedded CPU and would require yet another kernel.)
2) LPARs for ppc64. This is actually a bit more feasible, but it requires you
to have a POWER machine with LPAR support configured. Most of the existing
builders are blades, which generally don't do LPARs.
More information about the devel