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. http://www.linux-kvm.org/page/PowerPC http://www.mjmwired.net/kernel/Documentation/ia64/kvm.txt http://www.mjmwired.net/kernel/Documentation/s390/kvm.txt http://sourceforge.net/projects/arm-kvm/ + some mail-list disscussion about KVM on SPARC. It is certainly possible. Often in experimental state, but nevertheless. We have the technology for VMs. -- Tomasz Torcz Morality must always be based on practicality. xmpp: zdzichubg@xxxxxxxxx -- Baron Vladimir Harkonnen -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel