Closed
Bug 1185666
Opened 9 years ago
Closed 7 years ago
Do l10n repacks of Firefox for Mac on Linux
Categories
(Infrastructure & Operations Graveyard :: CIDuty, task)
Tracking
(firefox55 fixed)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
firefox55 | --- | fixed |
People
(Reporter: Pike, Assigned: Callek)
References
Details
(Whiteboard: [kanban:engops:https://mozilla.kanbanize.com/ctrl_board/6/2212] [capacity])
Attachments
(3 files)
Once we have cross-compilation figured out for OSX, it'll be really useful to investigate the changes required to do l10n repacks on linux. Not only does that allow us to use the cloud, but it might actually allow us to share build processes between linux and osx.
Comment 1•9 years ago
|
||
What parts of the l10n repack process require platform specific tools?
Reporter | ||
Comment 2•9 years ago
|
||
unpacking and packing up the dmg are currently done by platform specific tools, unpacking being l10n specific (mounts the image and copies files over)
Comment 3•9 years ago
|
||
BTW, l10n repacks could be first to be switched. That would free some slaves for other kinds of builds.
Comment 4•9 years ago
|
||
If the packaging pieces are the only platform-specific requirements, we should also look at doing windows repacks on linux. I think all the packaging utilities for windows can work on linux as well.
Reporter | ||
Comment 5•9 years ago
|
||
Agreed, we'll need to cross-compile NSIS for that. I've seen stuff for that back in the days. Not sure how things look today. Bonus points in wall-clock time if we do all platforms for one locale on one machine, as we can save all of l10n repo checkout and l10n-merge.
Comment 6•9 years ago
|
||
Ooooh, that would be really cool. Debian has nsis packaged already: https://packages.debian.org/jessie/nsis
Comment 7•8 years ago
|
||
This will block us from retiring Mac build hardware. We should tackle it soon. Looping in Callek.
Comment 8•8 years ago
|
||
This should be doable using the same tools we're using for packaging the cross-mac builds. Specifically, the `dmg` tool from https://github.com/zarvox/libdmg-hfsplus knows how to unpack and repack dmg files.
Comment 9•8 years ago
|
||
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #8) > This should be doable using the same tools we're using for packaging the > cross-mac builds. Specifically, the `dmg` tool from > https://github.com/zarvox/libdmg-hfsplus knows how to unpack and repack dmg > files. Might try to sprint on this next week at the work week.
Updated•7 years ago
|
Assignee: nobody → bugspam.Callek
Assignee | ||
Updated•7 years ago
|
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 13•7 years ago
|
||
mozreview-review |
Comment on attachment 8852289 [details] Bug 1185666 - Fix l10n repack scripts and config to support OSX on Linux. https://reviewboard.mozilla.org/r/124518/#review127060
Attachment #8852289 -
Flags: review?(aki) → review+
Comment 14•7 years ago
|
||
mozreview-review |
Comment on attachment 8852290 [details] Bug 1185666 - Make sure internal tooltool items are available for TC OSX repacks. https://reviewboard.mozilla.org/r/124520/#review127062
Attachment #8852290 -
Flags: review?(aki) → review+
Comment 15•7 years ago
|
||
mozreview-review |
Comment on attachment 8852288 [details] Bug 1185666 - Move DMG unpack logic to a python script, support linux. https://reviewboard.mozilla.org/r/124516/#review127318 This is looking great! I would like to re-review after the issues are fixed, so cleraing review for now. ::: python/mozbuild/mozbuild/action/unpack_dmg.py:13 (Diff revision 1) > + > +import argparse > +import sys > + > + > +def unpack_dmg(dmgfile, output_dir, dsstore=None, background=None, icon=None): Why do you want a separate function here? The py_action will just call main() by default, so you can just have main call dmg.extract_dmg() rather than call a new unpack_dmg() function that has the same arguments. ::: python/mozbuild/mozpack/dmg.py:225 (Diff revision 1) > + destdir]) > + > + > +def extract_dmg(dmgfile, output, dsstore=None, icon=None, background=None): > + if platform.system() not in ('Darwin', 'Linux'): > + raise Exception("Don't know how to build a DMG on '%s'" % platform.system()) "build" -> "extract" ::: python/mozbuild/mozpack/dmg.py:235 (Diff revision 1) > + with mozfile.TemporaryDirectory() as tmpdir: > + extract_dmg_contents(dmgfile, tmpdir) > + if os.path.islink(os.path.join(tmpdir, ' ')): > + # Rsync will fail on the presence of this symlink > + os.remove(os.path.join(tmpdir, ' ')) > + rsync(tmpdir, output) Why do we need to extract_dmg_contents into a tmpdir() only to then rsync tmpdir to output? Couldn't we extract_dmg_contents(dmgfile, output) instead? ::: python/mozbuild/mozpack/dmg.py:237 (Diff revision 1) > + if os.path.islink(os.path.join(tmpdir, ' ')): > + # Rsync will fail on the presence of this symlink > + os.remove(os.path.join(tmpdir, ' ')) > + rsync(tmpdir, output) > + > + if dsstore: So if I understand these bits correctly, we are copying .DS_Store, .background, and .VolumeIcon.icns back into the places where the came from under objdir/dist. I tried to backtrack this, but can't find the reason. I presume it's because we blindly copy them back from objdir/dist into the package during make_dmg() - is that correct? I believe this originates in bug 305131 from the patch "v4, stop the tears from the other eye". I think we could just leave this in the unpacked dmg, and use the unpacked dmg versions when repacking instead of copying them again from dist. If that sounds like a reasonble thing to you, please file a followup.
Attachment #8852288 -
Flags: review?(mshal)
Assignee | ||
Comment 16•7 years ago
|
||
mozreview-review-reply |
Comment on attachment 8852288 [details] Bug 1185666 - Move DMG unpack logic to a python script, support linux. https://reviewboard.mozilla.org/r/124516/#review127318 > Why do we need to extract_dmg_contents into a tmpdir() only to then rsync tmpdir to output? Couldn't we extract_dmg_contents(dmgfile, output) instead? I did this because its basically what happens during the mount case on OSX now, and I didn't want to pollute the objdir until we have a successful extract. > So if I understand these bits correctly, we are copying .DS_Store, .background, and .VolumeIcon.icns back into the places where the came from under objdir/dist. I tried to backtrack this, but can't find the reason. I presume it's because we blindly copy them back from objdir/dist into the package during make_dmg() - is that correct? > > I believe this originates in bug 305131 from the patch "v4, stop the tears from the other eye". > > I think we could just leave this in the unpacked dmg, and use the unpacked dmg versions when repacking instead of copying them again from dist. If that sounds like a reasonble thing to you, please file a followup. this does sound reasonable (I think) I'll file a followup, but it is low on my priority list.
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment hidden (mozreview-request) |
Comment 20•7 years ago
|
||
mozreview-review |
Comment on attachment 8852288 [details] Bug 1185666 - Move DMG unpack logic to a python script, support linux. https://reviewboard.mozilla.org/r/124516/#review128190 Looks great! Just one nit. ::: toolkit/mozapps/installer/upload-files.mk:218 (Diff revision 2) > - set -ex; \ > - rm -rf $(ABS_DIST)/unpack.tmp; \ > - mkdir -p $(ABS_DIST)/unpack.tmp; \ > - $(_ABS_MOZSRCDIR)/build/package/mac_osx/unpack-diskimage $(UNPACKAGE) /tmp/$(MOZ_PKG_APPNAME)-unpack $(ABS_DIST)/unpack.tmp; \ > - rsync -a '$(ABS_DIST)/unpack.tmp/$(_APPNAME)' $(MOZ_PKG_DIR); \ > - if test -n '$(MOZ_PKG_MAC_DSSTORE)' ; then \ > + $(call py_action,unpack_dmg, \ > + $(if $(MOZ_PKG_MAC_DSSTORE),--dsstore '$(MOZ_PKG_MAC_DSSTORE)') \ > + $(if $(MOZ_PKG_MAC_BACKGROUND),--background '$(MOZ_PKG_MAC_BACKGROUND)') \ > + $(if $(MOZ_PKG_MAC_ICON),--icon '$(MOZ_PKG_MAC_ICON)') \ > + '$(UNPACKAGE)' '$(MOZ_PKG_DIR)' \ > + ); Pretty sure this trailing semicolon is unnecessary.
Attachment #8852288 -
Flags: review?(mshal) → review+
Comment 21•7 years ago
|
||
Pushed by Callek@gmail.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/7c5c1555236c Move DMG unpack logic to a python script, support linux. r=mshal
Assignee | ||
Comment 22•7 years ago
|
||
Pushed all 3 csets to date https://hg.mozilla.org/projects/date/rev/e1df7b730858ba0170004a5b705f2bc484f9e2b0 https://hg.mozilla.org/projects/date/rev/1210d9021f59382ef89bd94924df18c2e80e6add https://hg.mozilla.org/projects/date/rev/2f26fe982afa5f83de3d68a3370bcb0f98df4554 And first patch only to inbound with: https://hg.mozilla.org/integration/mozilla-inbound/rev/7c5c1555236c33817493d7fee8fa16bebfca81e6
Comment 23•7 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/7c5c1555236c
Updated•6 years ago
|
Component: Platform Support → Buildduty
Product: Release Engineering → Infrastructure & Operations
Updated•4 years ago
|
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•