From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59412) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpBLt-00067U-Uq for qemu-devel@nongnu.org; Sun, 22 Jan 2012 23:17:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RpBLs-0002a8-GE for qemu-devel@nongnu.org; Sun, 22 Jan 2012 23:17:53 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:48695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RpBLs-0002a4-D6 for qemu-devel@nongnu.org; Sun, 22 Jan 2012 23:17:52 -0500 Received: by iahk25 with SMTP id k25so1873449iah.4 for ; Sun, 22 Jan 2012 20:17:51 -0800 (PST) Message-ID: <4F1CDF4B.9050603@landley.net> Date: Sun, 22 Jan 2012 22:17:15 -0600 From: Rob Landley MIME-Version: 1.0 References: <4F1B0C3E.20905@landley.net> <4F1BB581.6030703@weilnetz.de> <4F1C9EF5.9090105@landley.net> <4F1CBB88.9040806@codemonkey.ws> In-Reply-To: <4F1CBB88.9040806@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] Commit 5632ae46 broke the network on mips. List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Weil , qemu-devel On 01/22/2012 07:44 PM, Anthony Liguori wrote: > On 01/22/2012 05:42 PM, Rob Landley wrote: >> On 01/22/2012 01:06 AM, Stefan Weil wrote: >>> This was fixed with commits e9b40fd34ceb23461083d505a444a389c094455b >>> and 0b23c5d40ea933cfece3b4f69427f79c8a23256d in master and stable-1.0. >> >> The git tag for v1.0 does not include that commit. Apparently the >> current 1.0 tarball on the website does, > > Hi Rob, > > I've verified this three different ways.. You must have something > messed up on your end. Entirely possible. > v1.0 tag is: > > commit 1c8a881daaca6fe0646a425b0970fb3ad25f6732 > Author: Anthony Liguori > Date: Thu Dec 1 14:04:21 2011 -0600 > > Update version for 1.0 release Yup, that's the same here. Both of the above mentioned commits are _after_ that tag. (The clue is that there are _two_ of the same commit, one applied to the 1.0-stable branch and one applied to the development branch. If it was _before_ the tag the same commit wouldn't have to be applied twice with two different revision IDs.) So when I check out the above commit, I don't get either of those fix commits. If I go "git log v1.0 | grep" for either of those commit numbers, it doesn't find it in the log of what came before that commit. I just did a fresh pull of git://git.qemu.org/qemu.git into a fresh empty directory, and tested that: the result was the same. On that fresh checkout, if I do a git log of the 0b23 commit it shows the 1c8a commit as its parent. I tried this on my xubuntu 10.04 netbook and on my gentoo server: same result. I'm not a git expert, I just did this: mkdir temp cd temp git clone git://git.qemu.org/qemu.git cd qemu git log v1.0 | grep 0b23c5d40ea933cfece3b4f69427f79c8a23256d git log 0b23c5d40ea933cfece3b4f69427f79c8a23256d It's possible I'm misunderstanding the results. I do know that when I "git checkout v1.0" and build against that, mips network doesn't work. And when I go: git checkout v1.0 vi hw/mips_malta.c I can visually confirm that #include "exec-memory.h" is _not_ followed by sysbus.h on the next line, which is the first change made by the fix commit. What am I doing wrong? > Signed-off-by: Anthony Liguori > > I've verified this locally and on qemu.org. > > md5sum of the tarball is: > > a64b36067a191451323b0d34ebb44954 qemu-1.0.tar.gz git archive v1.0 --prefix=qemu-1.0/ | gzip | md5sum aa7443384602514c31c0e8ef2dab245e - Again, fresh checkout, 2 different machines running 2 different distros. > I've verified that the contents of this tarball match exactly the above > commit after the following commands: > > $ git submodule update --init > $ rm -rf .git roms/*/.git What does "git submodule" do? >> which is odd since e9b4 was >> only applied to the git tree _after_ a January 6th commit. So either >> "git log" is being weird, or you guys retroactively re-released the 1.0 >> tarball without renumbering it? >> >> I'm confused... > > You somehow messed up your repository or have a bogus 1.0 tarball. > Please confirm the md5sum. The tarball works fine. The v1.0 tag points to the same commit you indicated. The problem is that commit is the _parent_ of the fix I need. The fix is included in the tarball. The tarball is not the same as what the v1.0 tag points to. >> >>> My latest QEMU works with MIPS Malta running from an NFS root. >> >> I can confirm that current -master works for me. >> >> The 1.0 tarball includes the fix, the 1.0 git tag doesn't. I'll include >> a note to that effect in my release notes. > > That's definitely not the case. I can reproduce it on two different machines. What am I doing wrong? Rob