I''ve merged the patches and so on from xen-3.1.0-13.fc8.src.rpm with a recent xen-unstable tip (16635:9d447ba0c99a). With a bit of work I have managed to get a set of packages which appear to be able to work at least in my simple `does this work at all'' test. I''m mentioning it here so that you can have a look at what I''ve done and comment on it. We''ll probably be making official upstream rpms for Fedora 8. Please send me feedback either here on-list or privately. Most of the patches from -13.fc8 have been incorporated upstream so I just deleted them from my srpm. A couple of these patches I''ve included I have also submitted upstream and they''ll be in xen-unstable.hg soon if they''re not already. There were two patches that looked like they would be useful upstream: xen-qemu-bootmenu.patch pygrub-manykernels.patch but I wasn''t able to find clear attribution for the source of this code. Xen upstream operates a `Signed-off-by'' protocol to ensure that we don''t get bitten by copyright problems. Where should I look to try to find the authors/contributors to check on the copyright status ? In my package I have included the hypervisor in the xen-*.rpm rather than making a kernel package too. This is more in line with practice upstream. The new hypervisor seems to work for me with the 2.6.21-2952.fc8xen kernel. I have not included xen-net-bridge.patch which seemed quite a surprising set of changes to me. I was rather puzzled by the part of xen-initscript.patch which removes most of xend''s startup code. I agree that xend''s arrangements are not entirely ideal but is there really much to be gained by making that changes, which obviously makes the patchset much more fragile ? You can find the actual files here: http://www.chiark.greenend.org.uk/~ijackson/xen-3.2rc-fedora8/ THESE PACKAGES SHOULD NOT BE USED FOR PRODUCTION - they''re previews, and Xen 3.2 is still unreleased and in need of more testing. Please check the SHA256''s before installing them: 1209de4470cf505113e684fe8f1f5c13faad40ad8eb4c456e8741eddbe5b6254 xen-3.1.9-0.fc8.i386.rpm 18ad4f2b35c6918ab3070e43d238487f6cbaf10a682cfc90b1d11c4640957395 xen-3.1.9-0.fc8.src.rpm 428da514ccf9064244017a5068c399ec0e7c5816c2d2f4ded17e9af031d50759 xen-debuginfo-3.1.9-0.fc8.i386.rpm 98305f6fc7de7c965b7cb0426a0bed4cb977394a8fce1cedf6fb35d6780df0c5 xen-devel-3.1.9-0.fc8.i386.rpm f45e0ed7ff40bf7ef4e8cd236f639060caba27d3573003745bfa37f3ae0f4943 xen-libs-3.1.9-0.fc8.i386.rpm Regards, Ian.
On Fri, Dec 21, 2007 at 04:30:36PM +0000, Ian Jackson wrote:> I''ve merged the patches and so on from xen-3.1.0-13.fc8.src.rpm with a > recent xen-unstable tip (16635:9d447ba0c99a). With a bit of work I > have managed to get a set of packages which appear to be able to work > at least in my simple `does this work at all'' test. > > I''m mentioning it here so that you can have a look at what I''ve done > and comment on it. We''ll probably be making official upstream rpms > for Fedora 8. Please send me feedback either here on-list or > privately. > > Most of the patches from -13.fc8 have been incorporated upstream so I > just deleted them from my srpm. A couple of these patches I''ve > included I have also submitted upstream and they''ll be in > xen-unstable.hg soon if they''re not already. > > There were two patches that looked like they would be useful upstream: > xen-qemu-bootmenu.patch > pygrub-manykernels.patch > but I wasn''t able to find clear attribution for the source of this > code. Xen upstream operates a `Signed-off-by'' protocol to ensure that > we don''t get bitten by copyright problems. Where should I look to try > to find the authors/contributors to check on the copyright status ?There were both written by Jeremy, so copyright Red Hat. I''ll get them posted upstream.> In my package I have included the hypervisor in the xen-*.rpm rather > than making a kernel package too. This is more in line with practice > upstream. The new hypervisor seems to work for me with the > 2.6.21-2952.fc8xen kernel.We are going to be putting the hypervisor in a ''xen-hypervisor'' package for F9, so it might be work folowing same practice.> I have not included xen-net-bridge.patch which seemed quite a > surprising set of changes to me.Most of those, if not all, should be upstream in 3.2.0> I was rather puzzled by the part of xen-initscript.patch which removes > most of xend''s startup code. I agree that xend''s arrangements are not > entirely ideal but is there really much to be gained by making that > changes, which obviously makes the patchset much more fragile ?The reason for this is that the upstream changset did not play nicely with standard Fedora init script good practice. IMHO duplicating stuff that is already provided by standard initscript shell functions in python is a bad idea, hence we killed it. I did post these changes upstream for review at the time by they weren''t incporated. Should be in the archives somewhere....> Please check the SHA256''s before installing them: > 1209de4470cf505113e684fe8f1f5c13faad40ad8eb4c456e8741eddbe5b6254 xen-3.1.9-0.fc8.i386.rpm > 18ad4f2b35c6918ab3070e43d238487f6cbaf10a682cfc90b1d11c4640957395 xen-3.1.9-0.fc8.src.rpm > 428da514ccf9064244017a5068c399ec0e7c5816c2d2f4ded17e9af031d50759 xen-debuginfo-3.1.9-0.fc8.i386.rpm > 98305f6fc7de7c965b7cb0426a0bed4cb977394a8fce1cedf6fb35d6780df0c5 xen-devel-3.1.9-0.fc8.i386.rpm > f45e0ed7ff40bf7ef4e8cd236f639060caba27d3573003745bfa37f3ae0f4943 xen-libs-3.1.9-0.fc8.i386.rpmFYI, you might want to check the rawhide spec file - for pre-release builds we are standardizing on a numbering format of: ''xen-3.2.0-0.fc8.rc3.dev16606'' NB, the leading the ''0'' in the release number ensures the upgrade path to the final official 3.2.0-1.fc9 package. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Fri, Dec 21, 2007 at 04:45:47PM +0000, Daniel P. Berrange wrote:> On Fri, Dec 21, 2007 at 04:30:36PM +0000, Ian Jackson wrote: > > I''ve merged the patches and so on from xen-3.1.0-13.fc8.src.rpm with a > > recent xen-unstable tip (16635:9d447ba0c99a). With a bit of work I > > have managed to get a set of packages which appear to be able to work > > at least in my simple `does this work at all'' test. > > > > I''m mentioning it here so that you can have a look at what I''ve done > > and comment on it. We''ll probably be making official upstream rpms > > for Fedora 8. Please send me feedback either here on-list or > > privately.FYI, my 3.2.0 RPMs for Fedora 9 are currently in a branch of Fedora CVS called ''private-berrange-xen-unstable'' viewable here: http://cvs.fedoraproject.org/viewcvs/devel/xen/?only_with_tag=private-berrange-xen-unstable Or checkout with cvs -d :pserver:anonymous@cvs.fedoraproject.org:/cvs/pkgs checkout -r private-berrange-xen-unstable xen/devel I''ve not decided yet on wether to name the hypervisor ''/boot/xen.gz'' or include a full version ''/boot/xen-3.2.0.gz'', or version + release ''/boot/xen-3.2.0-1.fc9''. I think i''ll probably go for ''xen-3.2.0.gz'' Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Fri, Dec 21, 2007 at 04:30:36PM +0000, Ian Jackson wrote:> I''ve merged the patches and so on from xen-3.1.0-13.fc8.src.rpm with a > recent xen-unstable tip (16635:9d447ba0c99a). With a bit of work I > have managed to get a set of packages which appear to be able to work > at least in my simple `does this work at all'' test.> Please check the SHA256''s before installing them: > 1209de4470cf505113e684fe8f1f5c13faad40ad8eb4c456e8741eddbe5b6254 xen-3.1.9-0.fc8.i386.rpm > 18ad4f2b35c6918ab3070e43d238487f6cbaf10a682cfc90b1d11c4640957395 xen-3.1.9-0.fc8.src.rpm > 428da514ccf9064244017a5068c399ec0e7c5816c2d2f4ded17e9af031d50759 xen-debuginfo-3.1.9-0.fc8.i386.rpm > 98305f6fc7de7c965b7cb0426a0bed4cb977394a8fce1cedf6fb35d6780df0c5 xen-devel-3.1.9-0.fc8.i386.rpm > f45e0ed7ff40bf7ef4e8cd236f639060caba27d3573003745bfa37f3ae0f4943 xen-libs-3.1.9-0.fc8.i386.rpmCan I request that you include something in the release number to indicate that these are XenSource provided RPMs - just using ''fc8'' will lead to confusion with the base Fedora provide RPMs. Either add ''xs'' after the initial release digit, or tag it on after the %dist tag, eg one of xen-3.1.9-0xs.fc8.i386.rpm xen-3.1.9-0.fc8.xs1.i386.rpm This ensures that if we get Bug reports it''ll be clear which RPMs are being used. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Daniel P. Berrange writes ("Re: [Fedora-xen] Preview Xen 3.2 rc*
packages"):> [stuff]
Thanks for your helpful comments.
> On Fri, Dec 21, 2007 at 04:30:36PM +0000, Ian Jackson wrote:
> > xen-qemu-bootmenu.patch
> > pygrub-manykernels.patch
>
> There were both written by Jeremy, so copyright Red Hat. I''ll get
them
> posted upstream.
I see you''ve done that now, thanks. I don''t know if
they''ll make
3.2.0 at this stage but I''ll include them in my release packages if
not.
> We are going to be putting the hypervisor in a
''xen-hypervisor'' package
> for F9, so it might be work folowing same practice.
Right, yes, I''ll see about doing the same.
> > I have not included xen-net-bridge.patch which seemed quite a
> > surprising set of changes to me.
>
> Most of those, if not all, should be upstream in 3.2.0
I don''t think so but if you think so then fine - I''m happiest
here
just shipping the upstream code unaltered.
> > I was rather puzzled by the part of xen-initscript.patch which removes
> > most of xend''s startup code. I agree that xend''s
arrangements are not
> > entirely ideal but is there really much to be gained by making that
> > changes, which obviously makes the patchset much more fragile ?
>
> The reason for this is that the upstream changset did not play nicely
> with standard Fedora init script good practice. IMHO duplicating stuff
> that is already provided by standard initscript shell functions in
> python is a bad idea, hence we killed it. I did post these changes
> upstream for review at the time by they weren''t incporated. Should
be
> in the archives somewhere....
Hmm. I have some sympathy with this line of reasoning but there are
some subtleties to do with the lifetimes of the various daemons and of
course it might happen that there would be a reorganisation of of
these daemons (into a different set of processes).
I think it''s better to regard these as `parts'' of xend, rather
than
individual daemons in their own right. That also means that when Xen
is ported to a new host OS, less work is needed to adapt the daemon
startup to conform to the host''s arrangements.
In any case the upstream 3.2.0 won''t change in this area at this
stage. It''s probably best of the packages I make for Fedora use your
setup (particularly since otherwise I''d have to tack a hatchet to the
existing FC7 init scripts).
> FYI, you might want to check the rawhide spec file - for pre-release builds
> we are standardizing on a numbering format of:
> ''xen-3.2.0-0.fc8.rc3.dev16606''
I''ll take a look at the rawhide spec file, and your Fedora 9 version,
but mainly for illumination than code. I think the upstream-provided
packages of 3.2.0 for fc8 ought to be based on the 3.1.x fc8 packages.
> NB, the leading the ''0'' in the release number ensures
the upgrade path
> to the final official 3.2.0-1.fc9 package.
Right, I''ll do that next time.
Daniel P. Berrange writes ("Re: [Fedora-xen] Preview Xen 3.2 rc*
packages"):> FYI, my 3.2.0 RPMs for Fedora 9 are currently in a branch of Fedora
> CVS called ''private-berrange-xen-unstable'' viewable
here: [...]
Thanks.
> I''ve not decided yet on wether to name the hypervisor
''/boot/xen.gz'' or
> include a full version ''/boot/xen-3.2.0.gz'', or version +
release
> ''/boot/xen-3.2.0-1.fc9''. I think i''ll probably
go for ''xen-3.2.0.gz''
I would definitely include the hypervisor version in future; I''m less
sure about the package version.
Debian have a very nice arrangement which lets you co-install
different hypervisor and tools versions, and then effectively
dual-boot. Unfortunately their patches are very intrusive so that
won''t be in 3.2.0, but I think we certainly want to move in that
direction upstream in the future (probably with different changes to
achieve the same effect, rather than trying to import and redact
Debian''s patchset).
Daniel P. Berrange writes ("Re: [Fedora-xen] Preview Xen 3.2 rc*
packages"):> Can I request that you include something in the release number to indicate
> that these are XenSource provided RPMs - just using ''fc8''
will lead to
> confusion with the base Fedora provide RPMs. Either add
''xs'' after the
> initial release digit, or tag it on after the %dist tag, eg one of
>
> xen-3.1.9-0xs.fc8.i386.rpm
> xen-3.1.9-0.fc8.xs1.i386.rpm
Of course. I should have done that to start with, really.
> This ensures that if we get Bug reports it''ll be clear which RPMs
are being
> used.
Right.
Regards,
Ian.
On Wed, Jan 02, 2008 at 03:01:05PM +0000, Ian Jackson wrote:> > I''ve not decided yet on wether to name the hypervisor ''/boot/xen.gz'' or > > include a full version ''/boot/xen-3.2.0.gz'', or version + release > > ''/boot/xen-3.2.0-1.fc9''. I think i''ll probably go for ''xen-3.2.0.gz'' > > I would definitely include the hypervisor version in future; I''m less > sure about the package version.Since Kier has said that each bug-fix series 3.1.x and 3.2.x maintain hypervisor <-> ABI compatability, I reckon we should name the hypervisor according to this version, so ''/boot/xen-3.1.gz'' and ''/boot/xen-3.2.gz''. That way people can update the minor releases 3.2.0, 3.2.1, 3.2.2, etc and not have to worry about changing grub configs.> Debian have a very nice arrangement which lets you co-install > different hypervisor and tools versions, and then effectively > dual-boot. Unfortunately their patches are very intrusive so that > won''t be in 3.2.0, but I think we certainly want to move in that > direction upstream in the future (probably with different changes to > achieve the same effect, rather than trying to import and redact > Debian''s patchset).Personally I''d like to see upstream get serious about Hypervisor <-> Tools ABI compatability. If you look at the changes in ABI from 3.1 to 3.2 trees it would have been pretty trivial to maintain compatability for new 3.2 hypervisor against old 3.1 tools. This is an idea that''s been rejected many times before, but I''d still like to see it. cf new Linux releases don''t break glibc each time. Then we could finally get out of the lock-step upgrades.. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|