1350164 - Fix cross compiling tools for creation of DMGs to not fail OSX's fsck

Status: RESOLVED FIXED

(Firefox Build System :: General, defect)

Description

[Justin Wood (:Callek)]

So, in testing some TC Migration stuff we're doing with signing, :aki found there was a dialog warning about a corrupt dmg when mounting it.

In investigating we found this dialog pops up only on OSX Sierra, and only on cross compiled dmg's (signing doesn't matter).

Some users had no issues with Sierra and this DMG, but both :ted and :aki could reproduce.

In further investigation :ted confirmed that fsck on linux of the .dmg didn't fail, while it did on OSX 10.11 or 10.12 (though only 10.12 had the dialog).

We suspect its a bug in the cross compile toolchain (dmg tool or hfs tooling) that causes this. The resulting actual disk mount seems perfectly fine, and the app can extract and work, but the dialog is scary enough for our users, to be a bad idea..

I (or someone) will fill this bug with more details over the coming days, but in the meantime, IRC logs:

Initial Ping http://logs.glob.uno/?c=mozilla%23build&s=23+Mar+2017&e=24+Mar+2017#c39821
Continue of convo: http://logs.glob.uno/?c=mozilla%23build&s=23+Mar+2017&e=24+Mar+2017#c39849
Roping in Amy (for potential change of plans heads up) http://logs.glob.uno/?c=mozilla%23releng&s=23+Mar+2017&e=24+Mar+2017#c287665
Ted's followon commentary in that channel (and others): http://logs.glob.uno/?c=mozilla%23releng&s=23+Mar+2017&e=24+Mar+2017#c287744

Comment 1

[(not currently active) Ted Mielczarek]

mshal did some investigation and found that this problem was introduced in this libdmg-hfsplus revision:
https://github.com/andreas56/libdmg-hfsplus/commit/326b15a9b78028956d37faee9561ff91936afc72

We updated the revision of libdmg-hfsplus we were using in bug 1337393 to pick up this fix:
https://github.com/andreas56/libdmg-hfsplus/commit/5c92af354b279809bc64f8013805ca0b51b29960

from IRC:
<mshal> ted: seems like it should work if we start on rev 1d72dd62a13632134667a378f926e8904f70bf25 and cherry-pick 9fb07c2d and 5c92af354b279809bc64f8013805ca0b51b29960
4:44 PM I ended up with https://people-mozilla.org/~mshal/0001-hfslib-create-copies-instead-of-symlinks-on-Windows.patch and https://people-mozilla.org/~mshal/0002-hfslib-set-permissions-when-extracting.patch as patches since neither applies cleanly

Comment 2

[Michael Shal [:mshal]]

Shortly after those messages, aki also said this:

 <aki> the app says it's damaged and can't be run when i try to launch it, but i haven't been running that test against anything else

Did that get sorted out on Friday?

Given how hacky and error-prone these tools are, I'm wondering if we should give some more thought into doing dmg-packaging-as-a-service on an actual mac. Personally I don't have a high degree of confidence at the moment in releasing something built with these tools.

Comment 3

[Nathan Froyd [:froydnj]]

(In reply to Michael Shal [:mshal] from comment #2)
> Given how hacky and error-prone these tools are, I'm wondering if we should
> give some more thought into doing dmg-packaging-as-a-service on an actual
> mac. Personally I don't have a high degree of confidence at the moment in
> releasing something built with these tools.

Could that just be an addition to the taskcluster graph for mac builds, as an intermediate step between the Linux builds and actual test machines?

Comment 4

[Michael Shal [:mshal]]

(In reply to Nathan Froyd [:froydnj] from comment #3)
> Could that just be an addition to the taskcluster graph for mac builds, as
> an intermediate step between the Linux builds and actual test machines?

That's actually what we're planning to do today even if the repackaging is on Linux machines. The tasks are roughly:

build -> [dmg] -> signing -> [.tar.gz] -> repackage -> [signed dmg]

We're trying to do the repackage task in Linux using the dmg & hfsplus tools, but that currently has some issues. I thought we would have to have a mac running a repackage service that the task could call out to, but if we can just run repackage as a task on a mac directly from Taskcluster that would be even easier :)

Comment 5

[(not currently active) Ted Mielczarek]

(In reply to Michael Shal [:mshal] from comment #2)
> Shortly after those messages, aki also said this:
> 
>  <aki> the app says it's damaged and can't be run when i try to launch it,
> but i haven't been running that test against anything else
> 
> Did that get sorted out on Friday?

We didn't follow up on that. I can do a little testing around this.

> Given how hacky and error-prone these tools are, I'm wondering if we should
> give some more thought into doing dmg-packaging-as-a-service on an actual
> mac. Personally I don't have a high degree of confidence at the moment in
> releasing something built with these tools.

I agree that these things are hacky, and I think using a Mac just for repackaging is a decent fallback strategy (as we discussed last week), but I'm also not *as* worried about shipping these. Fundamentally as long as the DMG mounts without error and the app bundle copies into /Applications the same way it normally would (the HFS permissions bug was one thing breaking that, definitely) there's not a lot of other moving parts here.

Comment 6

[Aki Sasaki (not active)]

(In reply to Michael Shal [:mshal] from comment #2)
> Shortly after those messages, aki also said this:
> 
>  <aki> the app says it's damaged and can't be run when i try to launch it,
> but i haven't been running that test against anything else
> 
> Did that get sorted out on Friday?

I'm able to run a signed-app-from-tarball from a signing task on Date, so I think we're good.

Comment 7

[Kim Moir [:kmoir] ET]

Can this bug be closed?

Comment 8

[Michael Shal [:mshal]]

I think so - pretty sure this is just fixed by bug 1351474.