From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Egger Subject: Re: ioemu Date: Mon, 1 Sep 2008 17:00:39 +0200 Message-ID: <200809011700.39344.Christoph.Egger@amd.com> References: <200809011123.17339.Christoph.Egger@amd.com> <200809011334.50496.Christoph.Egger@amd.com> <18619.56609.7173.414662@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <18619.56609.7173.414662@mariner.uk.xensource.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Ian Jackson Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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 byte= s. > > 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=20 > tarball. =46reeBSD 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 specif= ic 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. =2D-=20 AMD Saxony, Dresden, Germany Operating System Research Center Legal Information: AMD Saxony Limited Liability Company & Co. KG Sitz (Gesch=E4ftsanschrift): Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Registergericht Dresden: HRA 4896 vertretungsberechtigter Komplement=E4r: AMD Saxony LLC (Sitz Wilmington, Delaware, USA) Gesch=E4ftsf=FChrer der AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy