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