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 <aligu...@us.ibm.com> > 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 <aligu...@us.ibm.com> > > 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