1324834 - Identify commands to support INNER_UNMAKE_PACKAGE of a .dmg on linux

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Justin Wood (:Callek)]

This would be using the tooling we have for cross compiled OSX builds, :ted promised to figure out the commands necessary to reproduce...

https://dxr.mozilla.org/mozilla-central/rev/567894f026558e6dada617a3998f29aed06ac7d8/toolkit/mozapps/installer/upload-files.mk#249

The resulting implementation will be similar to https://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/action/make_dmg.py

Comment 1

[(not currently active) Ted Mielczarek]

Okay, so looking at the `INNER_UNMAKE_PACKAGE` definition, and trying some things out with a current Mac Nightly in a slightly outdated desktop-build docker image, I have some useful info for you.

First, I believe the only thing we really need to port is the `unpack-diskimage` line here:
https://dxr.mozilla.org/mozilla-central/rev/567894f026558e6dada617a3998f29aed06ac7d8/toolkit/mozapps/installer/upload-files.mk#253

The rest of the commands are just a series of mkdir and rsync which should all work fine.

The `MOZ_PKG_MAC_RSRC` bits do invoke `hdiutil` and `DeRez`, but dxr shows no usage of `MOZ_PKG_MAC_RSRC` in mozilla-central or build-central, so I think that's dead code:
https://dxr.mozilla.org/mozilla-central/rev/567894f026558e6dada617a3998f29aed06ac7d8/toolkit/mozapps/installer/upload-files.mk#268

Looking at a repack log from a current nightly shows that we don't execute those commands, which supports that hypothesis:
https://archive.mozilla.org/pub/firefox/nightly/2017/01/2017-01-04-03-02-14-mozilla-central-l10n/mozilla-central-macosx64-l10n-nightly-1-unknown-bm86-build1-build15.txt.gz

Given that, what `unpack-diskimage` does is not that complicated, it's just complicated because the tools OS X provides suck:
https://dxr.mozilla.org/mozilla-central/rev/57ac9f63fc6953f4efeb0cc84a60192d3721251f/build/package/mac_osx/unpack-diskimage

The Linux->Mac cross compiles have a dmg.tar.xz in their tooltool manifest:
https://dxr.mozilla.org/mozilla-central/rev/57ac9f63fc6953f4efeb0cc84a60192d3721251f/browser/config/tooltool-manifests/macosx64/cross-releng.manifest#35

It contains `dmg` and `hfsplus` binaries from the libdmg-hfsplus project. Using those binaries, the following two commands should be equivalent to the contents of `unpack-diskimage`, and they seem to work fine for me in the previously mentioned docker image (using the variable names from that script):

dmg extract "${DMG_PATH}" firefox.hfs
hfsplus firefox.hfs extractall / "${TARGETPATH}"

`firefox.hfs` is just a tempfile, it can be named whatever and you should clean it up afterwards.

Comment 2

[(not currently active) Ted Mielczarek]

FYI, I found that while trying to use these commands on a taskcluster-produced DMG file they didn't work because the DMG files we're generating from cross-builds are not quite the same. I was able to do:
dmg extract "${DMG_PATH}" firefox.hfs 0 # note the trailing zero

and then:
mount -t iso9660 -o loop firefox.hfs path

This might be fixable by bug 1197325.

Comment 3

[Kim Moir [:kmoir] ET]

Attachment: bug1324834.patch

Callek as discussed yesterday these are my wip patches, not sure if they are useful as I didn't have much time to work on this while you were away

Comment 4

[Chris Cooper [:coop] (he/him)]

Callek, kmoir: should this be reassigned, possibly to mshal?

Comment 5

[Justin Wood (:Callek)]

Personally I think I'd call this bug fixed as written, which was a bug to identify the set of commands to do this. Which :ted did for us.

I'm ok with morphing it for work we need for landable code though. (And however it morphs can determine whom should own)

Comment 6

[Kim Moir [:kmoir] ET]

agree with callek's assessment

Comment 7

[Chris Cooper [:coop] (he/him)]

Let's close it. Please file a new bug assigned to mshal to cover his build system work.