[Pkg-xen-devel] Some words on my debian files...

[Ralph Passgang]

Am Donnerstag, 16. Februar 2006 16:29 schrieb Guido Trotter:
> On Thu, Feb 16, 2006 at 02:28:36PM +0100, Ralph Passgang wrote:
>
> Hi!
>
> > since the repo is up and the debian files from "xen3.0.1-0tha2" are
> > uploaded I want to say some words about my work. This could help to
> > understand what I have done and makes it easier to understand what needs
> > to be done to have it in a good shape for debian.
>
> Thanks!

no problems, the files were uploaded by jeremy, but he missed tha3, because it 
was just one or two hours old as he uploaded the files. I haven't been 
carefull enough and realized that tomorrow morning when it was too late.

But I would like to upload the 2-3 small changed between both versions myself 
if possible :)

> > - I have written down (more or less all) changes to debian/changelog, so
> > reading it might help understanding what is working how and why.
>
> That's great! ;)
>
> > - I haven't patched the upstream, so my debian files should work on
> > xen3.0.1 + all testing changesets after the 3.0.1 release. For "unstable"
> > there are some minor things that needs to be changed (for example kernel
> > version, there are more files to install, ...).
> >
> > - with xen3 there is also a pae support for systems with more than 4gb
> > ram, which needs to be configured at compile time. But because many (old)
> > system doesn't support pae at all we need to have the default xen
> > packages build without pae support.
> >
> > At the moment there is a parameter in debian/rules to enable/disable pae,
> > but this isn't really a solution for debian, instead we need to find
> > another way.
> >
> > I would think of the following:
> >
> > We could compile all stuff without thje pae flag and then (if arch=i386)
> > compile just the hypervisor again with pae support and package that with
> > another name, for example: "xen-pae". If we would make it this way, we
> > would only have one source package for i386, i386+pae and amd64.
>
> Ok, agreed... Also, I recall from the xen mailing lists that they disabled
> PAE by default not because of a concern about older machines, but because
> they thought it wasn't ready yet! Shouldn't we perhaps write that it's
> experimental and to use the normal version if possible (that is: if one has
> less than 4gb of ram) ;)

I have running pae on two servers with no problems (at least there are no 
problems for me anymore), but as Ian Pratt said: "pae is a crock", but for 
some indeed very important, so we should support it in general.

Even if the argument that is not as stable as the default version is true, for 
me it's definitly more a problem with old hardware. we would make xen 
unuseable for maybe 30-50% of all i386 pc's if we would only provide a pae 
version. 

pae only works if your bios and cpu (and maybe even more of the hardware) 
supports pae. many cpu's doesn't do that. you can check your own cpu with 
taking a look at /proc/cpuinfo. a cpu that support pae has the "pae" flag 
available.

for example a one year old pentium m (1,6ghz) doesn't have pae, but a lot 
older celeron 333 mhz cpu has it (but I guess the bios is not aware of 
that)... so it's not just a question how old the hardware is.

ah, and before I forget: pae doesn't need to be enabled in 64bit mode. So I 
think we need to have some hooks in the rules file to seperate the i386 build 
(for the normal and the pae version) and the 64bit a bit.

Maybe we first should split the hypervisor and userspace tools, because then 
it might be easier to package a normal and a pae hypervisor.

> > - the dh_kpatches doesn't produce patches for kernels if an extraversion
> > is set. So I had to remove the extraversion before the dh_kpatches call.
> > This is quite a dirty hack (and not working for xen unstable for
> > example), but afaik needed in the moment. I don't know if this would be
> > ok in debian or if we need another solution.
> >
> > the resulting linux-patch-xen package required (at the moment) a clean
> > 2.6.12 kernel source and will convert it to: 2.6.12.6-xen. But the
> > version will not be in the .config file (because I had to strip the
> > extraversion as I said). For me this was not a problem, because using the
> > make-kpkg option: "append-to-version .6-xen" added the missing
> > extraversion again, but in general this isn't ideal. But I don't know how
> > to solve it, maybe we should ask the maintainers of dh_kpatches.
>
> Yeah, probably this could count as a bug in dh_kpatches which was written
> probably before the "stable kernel" hera, when extraversion wasn't used at
> all...

I don't know why dh_kpatches doesn't accept a extraversion, but that definitly 
should get fixed because the hooks I used are really ugly and will brake most 
likely in future versions! :)

> > - My package doesn't have a kernel source included, even if it's needed
> > for building the kernel-patch. Originally Adam used the debian
> > kernel-source and removed all debian specific patches, but he also
> > noticed that this isn't a good solution, because not all kernel-source
> > versions are available in all debian distributions and might disappear in
> > future (and then will brake our packages).
> >
> > My solution is to just ignore that and use the upstream method to fetch a
> > vanilla kernel-source from www.kernel.org. Adam said (some time ago) on
> > the xen ml, that he also will fetch the sources with wget in future
> > versions, but then he never uploaded any new packages after that posting.
> >
> > If fetching external stuff is a problem with debian's policy, even if the
> > external files are the kernel sources and of course open source and even
> > if this is how upstream handles it, then we might want to include the
> > kernel source as .tar.bz2 in the xen upstream directory, because then
> > xen's makefile will use that archive and will not fetch it anymore. But
> > this will blow our source package a lot! But on the other hand will safe
> > traffic on www.kernel.org.
>
> I can't find in the debian policy any rule against downloading external
> code... And since we're downloading a kernel source there shouldn't be an
> issue with that... We might want to check the md5sum or the gpg signature
> of the archive, after the downlpad, just to be conservative, though!

I never took a look at the policy regarding this, but someone told me in the 
past that this is not ok for debian. if it's ok, that I would suggest keeping 
that part as it is.

> > - My packages are also building & working on amd64 but I am not sure if I
> > made it correct. I noticed that xen wants to install libraries in /lib64,
> > but debian expects them to be in /lib (because /lib64 is just a symlink
> > to /lib). I managed that by having the libraries moved to the correct
> > location on amd64 hosts before the files gets packaged (see
> > debian/rules), but I guess it would be better to tell the correct library
> > path at configure/compile-time and not using a hook like this..
>
> Well, it's just because other distros are mixed 32-64 while debian is pure
> 64 (and one can build a 32bit chroot, if he wants too...) so lib64 isn't
> needed...
>
> I think we can apply this patch with dpatch before starting the
> compilation, and that should solve most of the issue! I don't have an amd64
> handy to try it, though!
>
> diff -ru xen-3.0.1.orig/Config.mk xen-3.0.1/Config.mk
> --- xen-3.0.1.orig/Config.mk    2006-02-16 16:19:44.000000000 +0100
> +++ xen-3.0.1/Config.mk 2006-02-16 16:20:10.000000000 +0100
> @@ -27,11 +27,7 @@
>  INSTALL_DATA = $(INSTALL) -m0644
>  INSTALL_PROG = $(INSTALL) -m0755
>
> -ifeq ($(XEN_TARGET_ARCH),x86_64)
> -LIBDIR = lib64
> -else
>  LIBDIR = lib
> -endif
>
>  ifneq ($(EXTRA_PREFIX),)
>  EXTRA_INCLUDES += $(EXTRA_PREFIX)/include
>
> Ciao,
>
> Guido
>
> PS there are a couple more files in the source which references lib64, we
> might have to dpatch those too... Or see if we can make the patch so that
> it only affects debian, and then can be accepted upstream too...

 I can check your patch on a amd64 box if you would like that, but I am not 
sure what is the better way to solve this, really. 

I personally don't like patching upstream if it's not really neccessary. I am 
not sure if my hook is really so bad that patching upstream is the better 
solution. what about the others?

ah, and before everybody has to look it up. my "hook" looks like this:

(if [ "$(DEB_BUILD_ARCH)" == "amd64" ]; then \
   cp -a $(CURDIR)/debian/install/usr/lib64/* 
$(CURDIR)/debian/install/usr/lib/; \
   rm -rf $(CURDIR)/debian/install/usr/lib64 ;\
fi)

--Ralph

P.s.: Argh, I still need rw-access to the svn... I noticed that I seem to have 
some kind of ssh access on alioth, but still not on svn.debian.org. Should I 
try to contact the svn admin myself?