WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] ioemu

On Monday 01 September 2008 14:16:33 Ian Jackson wrote:
> Christoph Egger writes ("Re: [Xen-devel] ioemu"):
> > On Monday 01 September 2008 12:05:36 Ian Jackson wrote:
> > > I'm not sure I understand what checksum you're referring to here.  Is
> > > it part of the NetBSD ports system ?  What does the ports system
> > > expect ?
> >
> > The checksum is part of the package in pkgsrc. It needs an URL where
> > to download the source archive. After the download, the archive is
> > verified against SHA1 and RMD160 checksums and against its size in bytes.
>
> I've spoken to a local FreeBSD expert and we don't understand this
> part of your complaint. The ports system expects to start with a 
> tarball.

FreeBSD ports and NetBSD pkgsrc are technically different, but there
are some overlapping parts like the UI, the tarball and the capability
to apply extra patches after extraction.

> If you're trying to use the Xen 3.3.0 release, that tarball
> could be the official release tarball.  If you say that that doesn't
> work for you then you need some other tarball but there are no other
> official tarballs.  In particular there are no official tarballs of
> xen-unstable or qemu-xen-unstable.

I started to create the packaging process before the official release.
I created an archive via hg archive and uploaded it to an NetBSD server.

When the official release was there, I just changed the download URL
and updated the checksums.

> Are you producing this tarball yourselves somehow ?  (hg archive
> perhaps).  And your complaint is that its hash isn't always the same
> when you use git ?  git-archive seems to produce reproduceable
> tarballs for me.

# man git
man: no entry for git in the manual.

git 's UI changes that fast, that it's not worth to provide a manpage?

"man hg" works and describes all available commands.

> > It doesn't compile on BSD (and hasn't got the testing).
>
> Does qemu upstream compile on BSD ?  I think you should be looking
> into that if it's a problem.

It does with the extra patches in pkgsrc (which also contain non-BSD specific
bugfixes). FreeBSD ports surely have these, too.

> > Our testing infrastructure is based on changeset numbers. From reading
> > the number you immediately know is this an old or new changeset and
> > you immediately know how many changesets are between two changesets.
>
> Yes, then your test infrastructure will need to be taught how to deal
> with git changeset ids - just like ours did.  It's not very difficult
> and I'm sure you can cope.

Is the format stable or does it change like the UI?

> > > I agree it is a shame that our official tarball isn't made entirely
> > > mechanically.  If you would care to contribute a script that
> > > reproduces the 3.3.0 tarball when dropped into the appropriate
> > > xen-3.3-testing changeset, and also does a sane thing in currently
> > > xen-unstable, we'll consider including it and using it next time.
> >
> > So you are planning to also move the hypervisor to git in the
> > middle/long run?
>
> That doesn't seem to relate to the paragraph of mine you quote, but:
>
> This is not my decision to make, but I expect that Xen will stay with
> hg for quite a while and I don't think it should change soon.
>
> The situation with Xen is much less fraught than that with qemu.
> After all Xen does not have three or four strange semi-forks, whereas
> qemu does (ioemu is one), Xen upstream is already using a dvcs rather
> than svn, etc.  So use of git's features for dealing with bad
> situations much less necessary with Xen.  That means that git's
> downsides (chiefly, the catastrophic and constantly changing UI) are a
> decisive factor - and of course there is no particular incentive to
> change.



-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>