1 files changed, 147 insertions, 0 deletions
diff --git a/results/classifier/118/all/1714750 b/results/classifier/118/all/1714750
new file mode 100644
index 000000000..1a61c173f
--- /dev/null
+++ b/results/classifier/118/all/1714750
@@ -0,0 +1,147 @@
+x86: 0.972
+architecture: 0.968
+hypervisor: 0.966
+peripherals: 0.964
+risc-v: 0.963
+performance: 0.958
+assembly: 0.955
+device: 0.954
+user-level: 0.952
+permissions: 0.948
+register: 0.947
+arm: 0.946
+i386: 0.945
+debug: 0.943
+semantic: 0.942
+graphic: 0.941
+TCG: 0.936
+kernel: 0.935
+socket: 0.934
+ppc: 0.931
+files: 0.931
+PID: 0.924
+network: 0.922
+VMM: 0.916
+vnc: 0.912
+KVM: 0.907
+mistranslation: 0.886
+virtual: 0.883
+boot: 0.851
+
+2.10.0 cannot be installed on case-insensitive file system
+
+The https://download.qemu.org/qemu-2.10.0.tar.bz2 tarball cannot be unpacked on a case-insensitive file system because it has a file qemu-2.10.0/roms/u-boot/scripts/Kconfig and a directory qemu-2.10.0/roms/u-boot/scripts/kconfig. This prevents installation on most macOS systems since by default the file system is case insensitive. The 2.10.0 upgrade is blocked in Homebrew due to this issue. See https://github.com/Homebrew/homebrew-core/pull/17467. This is a regression from 2.9.0, which didn't have this problem.
+
+That's apparently a problem with U-Boot. Could you please report this issue to the U-Boot project instead (see https://github.com/u-boot/u-boot)? We only include the u-boot sources in the QEMU tarballs, but we do not maintain them in the QEMU project, so we can not fix this issue here for you, sorry.
+
+The offending commit is https://github.com/u-boot/u-boot/commit/61304dbec36dc445bbe7d2c19b4da0695861e0a8 so it should be possible to downgrade u-boot until it gets fixed upstream, no?
+
+I don't think it would be wise to downgrade u-boot. You can always just skip unpacking the u-boot sources -- we don't actually build them, we just ship them for license compliance reasons.
+
+
+Hmm I'll try some magic tar invocations.
+
+>we don't actually build them, we just ship them for license compliance reasons.
+
+Would you be in compliance with the license if the u-boot sources were themselves in a tarball inside your qemu tarball?
+
+Yes, but that's not how we ship them today. (We're actually considering having the ROM blob sources be in an entirely separate tarball from the QEMU sources, for unrelated reasons).
+
+We should fix this bug by:
+ (1) getting u-boot to fix it upstream
+ (2) moving to a fixed u-boot
+
+
+I agree. But it's not really tenable in the interim for the 2.9.0 tarball not to be able to even be unpacked on macOS.
+
+There is a simple workaround: use
+  tar xf qemu-2.10.0.tar.xz --exclude qemu-2.10.0/roms/u-boot/scripts/Kconfig
+
+
+Right. The issue is that solution is O(n) not O(1).
+
+Eh? That command line is not particularly slow, especially compared to the time it takes to download the tarball in the first place.
+
+
+I mean in that every user is going to have to figure this out individually until it's fixed.
+
+In any case it will not be a problem for our Homebrew users, as I will do this:
+```
+diff --git a/Formula/qemu.rb b/Formula/qemu.rb
+index 16a54af167..db0e68d103 100644
+--- a/Formula/qemu.rb
++++ b/Formula/qemu.rb
+@@ -1,10 +1,20 @@
++# Fix extraction on case-insentive file systems.
++# Reported 4 Sep 2017 https://bugs.launchpad.net/qemu/+bug/1714750
++# This is actually an issue with u-boot and may take some time to sort out.
++class QemuDownloadStrategy < CurlDownloadStrategy
++  def stage
++    exclude = "#{name}-#{version}/roms/u-boot/scripts/Kconfig"
++    safe_system "tar", "xjf", cached_location, "--exclude", exclude
++    chdir
++  end
++end
++
+ class Qemu < Formula
+   desc "x86 and PowerPC Emulator"
+   homepage "https://www.qemu.org/"
+-  url "https://download.qemu.org/qemu-2.9.0.tar.bz2"
+-  sha256 "00bfb217b1bb03c7a6c3261b819cfccbfb5a58e3e2ceff546327d271773c6c14"
+-  revision 2
+-
++  url "https://download.qemu.org/qemu-2.10.0.tar.bz2",
++      :using => QemuDownloadStrategy
++  sha256 "7e9f39e1306e6dcc595494e91c1464d4b03f55ddd2053183e0e1b69f7f776d48"
+   head "https://git.qemu.org/git/qemu.git"
+ 
+   bottle do
+```
+https://github.com/Homebrew/homebrew-core/pull/17467
+
+Yes, it's awkward for users who are on OSX (or Windows, I assume). But the 2.10.0 release is already out and we can't change it -- if this bug had been reported for one of the 2.10.x release candidates it would maybe have been a release blocker. As it is we have to wait for a 2.10.1 release (and we need to actually fix the problem, preferably by getting u-boot upstream to do so).
+
+Thanks for putting the workaround into the homebrew packaging in the meantime.
+
+
+>Thanks for putting the workaround into the homebrew packaging in the meantime.
+
+You're welcome. I have now shipped the 2.10.0 binaries.
+
+>if this bug had been reported for one of the 2.10.x release candidates it would maybe have been a release blocker
+
+We should add a `devel` spec to the qemu formula for the next release candidates. I will try to remember.
+
+> As it is we have to wait for a 2.10.1 release
+
+Yeah that is unfortunate.
+
+>(and we need to actually fix the problem, preferably by getting u-boot upstream to do so).
+
+Agreed. If only their mailing list would confirm my subscription ... lol
+
+
+See https://lists.denx.de/pipermail/u-boot/2017-September/304728.html.
+
+Thanks for taking care of that @ubuntu-weilnetz
+
+Update: Sam Protsenko has kindly written and submitted a u-boot patch which resolves the filename clash:
+https://lists.denx.de/pipermail/u-boot/2017-September/307910.html
+
+
+Hurray!
+
+Somebody re-reported this which reminded me that we forgot to tidy up the loose ends here.
+Current status:
+ * this is fixed in upstream u-boot with their commit 610eec7f0593574 (committed October 2017, and in u-boot release v2017.11 and later)
+ * in QEMU's release process we put in a workaround in our commit d0dead3b6df7f6cd97 which puts the u-boot sources in their own tarball rather than extracted; this went into QEMU release 2.11.0
+ * we are still shipping the same old version of u-boot we were in 2.10
+
+So ideally we'd finish fixing this bug report by:
+ * updating our u-boot to some version v2017.11 or later
+ * removing the d0dead3b6df7f6cd97 workaround
+
+
+We updated our u-boot sources to v2019.01 in QEMU commit f2a3b549e357041f86d7e, and we removed the scripts/make-release workaround in commit 082c0543baa6f23770, so all the loose ends I mentioned in comment #18 are now fixed and will be in QEMU 4.0.
+
+