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

[Guido Trotter]

On Thu, Feb 16, 2006 at 05:48:37PM +0100, Ralph Passgang wrote:

Hi,

> 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 :)
> 

Well, of course, just go ahead and commit the differences in subversion...

Oh, by the way, wouldn't it be better to have all the files inside a "debian"
directory, rather than "trunk" itself? (well, it doesn't matter too much, but I
think it can make a couple of things simplier...)

> 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.
> 

Ok!

> 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. 
> 

For me having both versions is better too, so if there are no objection let's go
this way!

> 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.
> 

So, not to build pae when we are building on amd64, ok!

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

Ok! Upload your changes then we'll proceed this way!

> 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! :)
> 

Is there a bug reported against debhelper? Can you file one, or comment in the
existing one? (Since you first noticed the issue you're probably the best one to
do it properly)

> 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.
> 

I just couldn't find the paragraph where this was forbidden. Anyway I would
objected too if the code we downloaded would get *used*, but since we're only
diffing it... Another option is just to prepare the patch manually on someone's
system, and keep it inside our version, if anybody complains we can just do
that... Or we can ask on -policy just to be sure!

>  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. 
> 

Yeah, please go ahead! My patch doesn't seem a bad way... It just removed the
upstream hack to move the libraries depending on the architecture... Another
option could be some code with this semantic:

if (arch == amd64 && not_building_for_debian):
	use lib64
else:
	use lib

This would probably also be accepted upstream! (I guess they added the hack to
support the way fedora and suse work on amd64, so I think they wouldn't have an
issue recognizing that debian doesn't...)

> 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?
> 

Well... Patching upstream for paths etc is not so bad... And if we can make a
patch as the one above that could be accepted then we're more than OK...

> 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)
> 

Yeah, I noticed it... ;)

> 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?
> 

What's the issue? It seems your user exists on "costa", and is a member of
xen-pkg group...

Can you ssh "svn.debian.org" as user "tha-guest"? 

What command did you use to checkout? What does

svn checkout svn checkout svn+ssh://tha-guest@svn.debian.org/svn/pkg-xen/trunk

do?

And after that if you try to modify anything and commit what's your result?

Guido