2.10.0 cannot be installed on case-insensitive file system

[ilovezfs]

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.

[Thomas Huth (th-huth)]

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.

[ilovezfs (ilovezfs)]

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?

[Peter Maydell (pmaydell)]

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.

[ilovezfs (ilovezfs)]

Hmm I'll try some magic tar invocations.

[ilovezfs (ilovezfs)]

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

[Peter Maydell (pmaydell)]

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

[ilovezfs (ilovezfs)]

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.

[Peter Maydell (pmaydell)]

There is a simple workaround: use
  tar xf qemu-2.10.0.tar.xz --exclude qemu-2.10.0/roms/u-boot/scripts/Kconfig

[ilovezfs (ilovezfs)]

Right. The issue is that solution is O(n) not O(1).

[Peter Maydell (pmaydell)]

Eh? That command line is not particularly slow, especially compared to the time it takes to download the tarball in the first place.

[ilovezfs (ilovezfs)]

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

[Peter Maydell (pmaydell)]

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.

[ilovezfs (ilovezfs)]

>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

[Stefan Weil (ubuntu-weilnetz)]

See https://lists.denx.de/pipermail/u-boot/2017-September/304728.html.

[ilovezfs (ilovezfs)]

Thanks for taking care of that @ubuntu-weilnetz

[Peter Maydell (pmaydell)]

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

[ilovezfs (ilovezfs)]

Hurray!

[Peter Maydell (pmaydell)]

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

[Peter Maydell (pmaydell)]

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.