I don't know what prevu stuff is for, I've made packages for all ubuntu releases, that should do it ;)
my latest xen 3.4 packages are in my main PPA (not the experimental one) where I put what I consider "usable stuff"

if there are bugs in it , just tell me ;)

for the package maintainer, I've included a few patches that fixes quite important bugs in Xen 3.4.0, I believe you should consider them when you will do your own xen 3.4 source package.

@mikmak, could you create a build (in version *ubuntu, without ppa) and attach the .diff.gz, orig.tar.gz and .dsc file? Then you can subscribe Ubuntu Sponsors for Universe. For second thing, can you test your package 3.4 for other bugs reported on launchpad? Maybe you can fix other bugs.

This bug is tagged needs-packaging which identifies it as a request for a new package in Ubuntu. As a part of the managing needs-packaging bug reports specification, https://wiki.ubuntu.com/QATeam/Specs/NeedsPackagingBugs, all needs-packaging bug reports have Wishlist importance. Subsequently, I'm setting this bug's status to Wishlist.

I'm strongly opposed to merging in this package from Debian; I'd rather continue parallel development.

In my limited experience, I've been pretty dissatisfied with how the Debian maintainer has been handling bugs. For instance, notice that the package in Debian is currently being built without ioemu support, which means that there's no hardware virtualization support.

I agree with Evan; the Debian package is a disaster. A Xen package with no HVM support has no right to be called “Xen”. Also, the Debian package carries an invasive series of patches to completely change the filesystem layout, which makes it painful to maintain or modify (I’ve tried!); see <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=536174#10> for a taste of the problems that has caused.

mikmak: Could you rename the libxen3 package to libxen3-4? This has caused problems with conflicts between Xen 3.2 and 3.3 in backports in the past, and this would allow both 3.3 and 3.4 to exist in the same repository.

In meantime when loading the most recent 2.6.31 pvops kernel under Xen Unstable on top Ubuntu
9.10 Server (alpha 4, apt-get update, apt-get upgrade -> grub 1.97~beta2) i get a message the
/proc/xen is already mounted on xenfs, what causes daemon xend failure to start. Xen-bus appears
not to be activated during Dom0 loading.

Xen 3.4.2 was released around Nov 10th. As much as I'm looking forward to Xen 4.0 I suspect 3.4.2 is the better choice for Ubuntu 10.04. Xen 3.4.2 is available in Debian testing but I can understand if people would rather continue the separate development. Regardless of how it happens it would be good to see Xen 3.4.2 included in Ubuntu 10.04.

Unsurprisingly Xen 4.0 has not yet been released. Debian currently has 3.4.3rc3 in testing/squeeze. Lucid still has 3.3.0 and no Xen dom0 kernel. I get the sense that Ubuntu is going to have no path forward for 8.04 Xen servers. That's probably for the best as migrating away from Ubuntu for Xen server administrators is probably the smartest course of action.

We have been successfully using a xen hypervisor 4.0.0-rc3 build on Ubuntu
9.10.
I would think that packaging either this version or 3.4.x as an interim xen
server release for Ubuntu would be a desirable option as it would provide a
viable migration pack from 8.04 Xen servers.

> Unsurprisingly Xen 4.0 has not yet been released. Debian currently has
> 3.4.3rc3 in testing/squeeze. Lucid still has 3.3.0 and no Xen dom0
> kernel. I get the sense that Ubuntu is going to have no path forward for
> 8.04 Xen servers. That's probably for the best as migrating away from
> Ubuntu for Xen server administrators is probably the smartest course of
> action.
>
> --
> Please merge xen-3.4 (3.4.0-2) from debian unstable
> https://bugs.launchpad.net/bugs/378240
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I'm running the Xen 4.0.0-rc8 with Linux 2.6.32.10 as dom0 using the new paravirt_ops on top of Ubuntu Lucid 10.4 64bits.
Also I have the composite window manager on top of the Xen! With full 3D support!

Packaging is a problem. Direct builds along with hg & git cloning was never problem on Ubuntu 9.10,9.04 Severs
However, Xen Dom0 support or even just a recent Xen Hypervisor was NOT integrated in Ubuntu Karmic Koala Server, Ubuntu Jaunty Server. Moreover :-
# apt-get install ubuntu-virt-server ubuntu-virt-mgmt
put vitrt-install & virt-manager in work with Xen Hypervisor (with correspondingly modified /etc/xen/xend-config.sxp and setting Xen
as preferred hypervisor via root's .bashrc )
On Ubuntu Karmic Koala Server :-
Virt-install allows to install PV & HVM DomUs
Virt-manager allows to install PV DomUs via HTTP sources ( local or remote) and manage any domain created via virt-install.
virsh been compiled against libvirt 0.7.0 just fails to create DomUs when version of Xen goes to 4.0.
That the reason when i keep 3.4.3 on development boxes.
A lot of this stuff was published, view :-http://www.linuxtoday.com/search.php3?query=derzhavets

WARNING: No warranty whatsoever! This happens to work for me, while it may or may not work for you. I may or may not have time to update this if it breaks again... Anyone is welcome to continue, it should not be too hard.

@User Virtual
Could you be so kind to provide *.diff.gz and *.orig.tar.gz files ( like for 3.4.1)
I understand how you make *.orig.tar.gz . Should be the same way as for Fedora's xen-4.0.1.fc13.src.rpm.
Your link seems to be for myself a kind of charade. I need to understand what i am doing,
otherwise
1. hg clone http://xenbits.xensource.com/xen-4.0-testing.hg
2. cd *.hg
Change $CONFIG_QEMU in Config.mk
3. git clone http://xenbits.xensource.com/git-http/qemu-xen-4.0-testing.git qemu-xen.git
4. cd ../
5. cp -R xen-4.0-testing.hg xen-4.0.1
6. Create xen-4.0.1.tar.gz and replicate it over landscape - 30-40 min procedure.

I also believe , that it's possible to write a proper one xen-4.0_4.0.1rc2-0ubuntu1.diff.gz
to create debian packages supposed to install Xen 4.0.1-rc2 and load 2.6.32.15 pvops
for Dom0 support with xend starting with no issues.

News:
1. Tags kernel packages uniquely with UTC time stamp of the git CommitDate: to xen/stable-2.6.32.x. Now, we can see the exact commit that kernel package was generated from in its debian package version.
2. Xen 4.0.1-rc2, (and hopefully -rc3,...) is built automatically.
* Boris Derzhavets note above "Edited your xend , removing attempt to load xen-evtchn module, which was hard linked with 2.6.32.15" not taken into account yet. Will be soon.

News:
1. Load xen-evtchn module only if the device is missing. (Thanks to Boris Derzhavets)
2. Major cleanup. diff.gz reduced from 26k to 19k.
3. Moved udev 40-xen-utils-4.0.rules to 40-xen-hypervisor-4.0.rules, it seems to better fit there.

Device /dev/xen/evtchn should be created by udevd daemon during Dom0 load under Xen 4.0.1 & 2.6.32.X pvops.
Any attempt to fix it at xend startup when Dom0 gets loaded is useless. Please, address this question to xen-devel mailing list

Device /dev/xen/evtchn is at the moment loaded by udevd here as well. I have this code back from some previous attempts when it did not work (maybe RELEASE-4.0.0). However the other device mentioned in docs /dev/xen/gntdev is still missing here (Ubuntu 9.10 karmic, kernel compiled with CONFIG_XEN_GNTDEV=y CONFIG_XEN_DEV_EVTCHN=y). I know I could create it manually but I want it as designed. Everything seems to work even without this /dev/xen/gntdev.
I will probably remove this module loading from init.d/xend as soon as devices are actually created by udevd here.

- Added the very important missing xen-4.0-0ubuntu1.diff.gz for all versions. This was a big mistake making this post unusable since the 21st of Jun, SORRY.

- One line was missing in packageXen40x.sh to update xen repository every time it is run without version argument. Previous version could not automatically pick up 4.0.1-rc3, this can and does the build without error.

- Bruce Edge reminded me to retry standard ubuntus “make-kpkg kernel-image” which was broken when I started. Now it seems to be working again. I added a script for really Ubuntu-way of packaging kpkgXenKernel.sh. It’s practically the same as the older remakeXenKernel.sh except the “make-kpkg (Ubuntu) vs deb-pkg (Linux Kernel source)”.
If one of them fails to build you can try the other.

I've just rebuilt *.debs for 4.0.1-rc4 with now problems.
I tested on the most recent mercurial as well.
root@ServerLDX:/usr/src/xen-4.0-testing.hg# patch -p1 -s -i ../fsimage-zfs-24.patch1
root@ServerLDX:/usr/src/xen-4.0-testing.hg#

I've just rebuilt *.debs for 4.0.1-rc4 with now problems.
I tested on the most recent mercurial as well.
root@ServerLDX:/usr/src/xen-4.0-testing.hg# patch -p1 -s -i ../fsimage-zfs-24.patch1
root@ServerLDX:/usr/src/xen-4.0-testing.hg#

Things I like to see (that makes sponsoring and maintaining easier):
1) Get all patches into the upstream project (if the patch is Ubuntu specific: find a general purpose solution)
2) Collaborate with the Debian Xen Team. You could offer your help, join the team and improve their package (get it maintained in a VCS, make it lintian clean, get patches upstream, make it simpler, ...)
3) Get it lintian clean (check lintian -iIE --pedantic *.changes) [preferred by solving 2) ]
4) The source tarball should be called 'xen' to get it aligned to Debian.

Please resubscribe ubuntu-sponsor when you have a feature freeze or when maverick+1 is open for upload. For making reviewing easier, please attach a debdiff (from Debian -> Ubuntu) to this bug report if you have a merge prepared or add the source files excluding the source tarballs (.dsc and .diff.gz / .debian.tar.*) if you have an update prepared.

Debian squeeze has 4.0.1-2 currently. Isn't it possible to just pull this package into Ubuntu and be done with it? It's been over 1.5 years, and we're still stuck on 3.3.. Instead of reinventing the wheel ( and getting nowhere ), why not just cooperate with the Debian maintainers of the Xen package and get Xen support out of the sorry state it is now in Ubuntu?

> Debian squeeze has 4.0.1-2 currently. Isn't it possible to just pull
> this package into Ubuntu and be done with it? It's been over 1.5 years,
> and we're still stuck on 3.3.. Instead of reinventing the wheel ( and
> getting nowhere ), why not just cooperate with the Debian maintainers of
> the Xen package and get Xen support out of the sorry state it is now in
> Ubuntu?
>
>

Ubuntu doesn't even hava 3.3 anymore. Ubuntu 8,04 (Hardy ?) did, but now
there's no dom0 kernel in Ubuntu.
It is pretty sad, what with the current virtualization push et al that
Ubuntu has zero Xen options other than roll your own.

I 2nd Bart Verwilst's statement. Is there some sort of process that needs to happen to get the Ubuntu team to drop unmaintained software in favor the the maintained Debian versions? If anything I'd like to see that process be automated: any package untouched by Ubuntu maintainers after 3 or 4 releases just gets dropped and replaced with the Debian version.

I've created a package set for Xen 4.0.1 based on the debian packages with minimal changes. They are available in my PPA, but i'd love to file the appropriate bugs and so on if I only knew what to report and where. There doesn't appear to be a policy for this sort of thing.

And as a note, I don't think it is a good idea to start this mess all over again, by packaging 4.1 outside of the Debian packages. Sure, it'll get Xen 4.1 in faster, but it will most likely end up in the same situation as we are in now.

I think it's clear to everyone that the Ubuntu Team has zero interest in maintaining Xen packages thus Ubuntu should simply use the Debian packages. The question that remains is how to make that happen.

So, after conferring with Chuck Short, this will need to be a new source package as libvirt needs xen-3.3. So, Debian is currently using xen for 4.x, so for simplicity, I'm moving this bug to that source package. We still need the Freeze exception for it.re.

I can forward the fixes to Debian, but both of the patches originate from upstream and they are pulled to Debian anyway later on. So unless we can justify a freeze exception for the package there is little point in overloading the Debian maintainers.

Renaming the source is only natural, since Debian already uses xen as the source package name. As for libvirt, the dependency on 3.3 is a build time dependency and my version of libvirt changes that (and that way reverts the package closer to the debian original).

On 03/07/2011 10:50 PM, Sami Haahtinen wrote:
> I can forward the fixes to Debian, but both of the patches
> originate from upstream and they are pulled to Debian anyway later
> on. So unless we can justify a freeze exception for the package
> there is little point in overloading the Debian maintainers.
>
> Renaming the source is only natural, since Debian already uses xen
> as the source package name. As for libvirt, the dependency on 3.3
> is a build time dependency and my version of libvirt changes that
> (and that way reverts the package closer to the debian original).
>
> In any case, I'll start preparing the debdiffs and exception
> request.

My point was that it might be easier to get it in without changing
libvirt and working on that next cycle.

As for the freeze exception, most of the rationale is already mentioned here. But to recap:

Xen packaging in Ubuntu is outdated and originates from a source outside of Debian. This patch will allow the usage of Debian xen package in Ubuntu. This package requires pulling xen-common package from Debian as well as rebuilding libvirt with libxen-dev as the dependency.

Current Xen packaging is horribly outdated and will hurt Ubuntu's image if a release is made with it.

For anyone that's interested I've packaged Xen 4.1.0 and 4.0.1 for Ubuntu. So far I've only released on 10.04 but I hope the debs will work for other Ubunutu versions, and Debian as well. My strategy was to create a package that duplicated the Xen install without all the extra packaging done by the Ubuntu and Debian packages. I've also catered to my needs, so at the moment no SDL and no pvgrub. Still it's a lot easier than compiling Xen on every single server. You can find them here:

Xen is at version 4.1.0-3ubuntu4 in Oneiric. Closing this bug as "Fix Released" and unsubscribing Ubuntu sponsors. Thanks to everyone who contributed and help influence the process that is bringing excellent Xen support to Ubuntu. I would encourage you all to test out Oneiric and continue to give feedback in bug reports and on the ubuntu-server mailing list!

FYI, last week updated to enable packaging 4.1.1 and 4.0.2. No more patches needed for 4.1.1 (and latter), all is directly from XenSource just packaged. The same goes for packager for dom0-kernels used here - directly from xensource.com. Let's hope this was the last update. (Using this to run packaged xen4* since Jun'10)