Closed Bug 1060059 Opened 10 years ago Closed 9 years ago

Fix up install_app.py so that it works

Categories

(Toolkit Graveyard :: XULRunner, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: Gijs, Unassigned)

Details

Attachments

(1 file)

1) http://mxr.mozilla.org/mozilla-central/source/xulrunner/app/install_app.py#215 except exn: Unfortunately, this isn't valid python. It really means to say: except Exception as exn: as far as I can tell. 2) http://mxr.mozilla.org/mozilla-central/source/xulrunner/app/install_app.py#216 I'm not sure we should be removing this (bug 1006501), but as it is this fails if the exception from installApp was thrown before the installDir was created because the file doesn't exist, and rmtree throws a fit about that. That also means that you never get to see the actual exception from installApp, because this one hides it. 3) AttributeError: 'ZipFile' object has no attribute 'extractAll' This actually happens twice in the file. The correct method name is "extractall" (note the all lowercase), see https://docs.python.org/2/library/zipfile.html . 4) Traceback (most recent call last): File "install_app.py", line 222, in <module> handleCommandLine() File "install_app.py", line 219, in handleCommandLine print cmds.appName + " application installed to " + cmds.installDir TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' This should probably be using: print cmds.appName, "application installed to", cmds.installDir instead. But also, appName might be read from the app.ini file, and that never gets passed around back into cmds.appName, and so appName is none. However, after fixing all that, the .app bundle generated on mac is still non-functional. I'm still looking into that. :-(
Seems like the next thing that's wrong is that it (a) asserts that installDir should not exist, and (b) updates it with the app name *after* that check - so if you pass "/Applications/" it complains, and if you pass /Applications/Foo.app, the bundle gets created in /Applications/Foo.app/Foo.app
Fixing that leads to a startup crash: Library not loaded: @executable_path/libmozglue.dylib Referenced from: /Applications/Foo.app/Contents/MacOS/xulrunner Reason: image not found
I got that far as well. The only thing that I could do to make it work was to physically move it to another Mac. I think that when it is built, the symlinks link into locations in the source tree, so it won't run inside the app bundle.
Attached patch Initial patchSplinter Review
I'm not sure what the proper fix for the library loading issue is, but here's what I have so far. Benjamin, can you give some hints as to how to fix the library thing?
Attachment #8480870 - Flags: feedback?(benjamin)
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
For reference: http://sourceforge.net/p/verbosio/templates/code/ci/default/tree/sourceutils/install_app.py has the version I'm currently using. Regarding libmozglue: see bug 923979.
(In reply to :Gijs Kruitbosch from comment #4) > I'm not sure what the proper fix for the library loading issue is, but > here's what I have so far. Benjamin, can you give some hints as to how to > fix the library thing? Take a look at attachment 8360177 [details] [diff] [review] for configure.in, and also attachment 8360183 [details] [diff] [review] for the Plist.info changes that need to go in.
(In reply to Alex Vincent [:WeirdAl] from comment #5) > For reference: > http://sourceforge.net/p/verbosio/templates/code/ci/default/tree/sourceutils/ > install_app.py has the version I'm currently using. This looks like it's the one from before Mossop's review comments in bug 747597?
(In reply to :Gijs Kruitbosch from comment #7) > This looks like it's the one from before Mossop's review comments in bug > 747597? That wouldn't surprise me... I've been focused on other tasks (if I hadn't, XULRunner on Mac would be working...)
(In reply to Alex Vincent [:WeirdAl] from comment #6) > (In reply to :Gijs Kruitbosch from comment #4) > > I'm not sure what the proper fix for the library loading issue is, but > > here's what I have so far. Benjamin, can you give some hints as to how to > > fix the library thing? > > Take a look at attachment 8360177 [details] [diff] [review] for > configure.in, and also attachment 8360183 [details] [diff] [review] for the > Plist.info changes that need to go in. Ugh. I was not prepared to have to deal with packaging changes for the build as well. It looks like the mac xulrunner build has been broken on m-c and aurora for a while now, too. :-\ I'm guessing that's a different bug? I can't find one, however... Benjamin?
Flags: needinfo?(benjamin)
This is when builds broke, at least: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c45f6e6d6005&tochange=196d05832e12 (late in the 33 cycle - there's only one checkin mentioning xulrunner, and it's a gaia bump, so I don't think that's it)
Filed bug 1060787 on the aurora bustage, but m-c seems to just fail linking... not sure when that happened.
Flags: needinfo?(benjamin)
(In reply to :Gijs Kruitbosch from comment #9) > Ugh. I was not prepared to have to deal with packaging changes for the build > as well. It looks like the mac xulrunner build has been broken on m-c and > aurora for a while now, too. :-\ > > I'm guessing that's a different bug? I can't find one, however... Benjamin? You can *definitely* ignore the package-manifest changes. That was an attempt by me to bypass the need to --disable-tests.
(In reply to Alex Vincent [:WeirdAl] from comment #12) > (In reply to :Gijs Kruitbosch from comment #9) > > Ugh. I was not prepared to have to deal with packaging changes for the build > > as well. It looks like the mac xulrunner build has been broken on m-c and > > aurora for a while now, too. :-\ > > > > I'm guessing that's a different bug? I can't find one, however... Benjamin? > > You can *definitely* ignore the package-manifest changes. That was an > attempt by me to bypass the need to --disable-tests. Sure, but the fact is that by now a plain ./mach build on OS X fails.
Comment on attachment 8480870 [details] [diff] [review] Initial patch Is "I don't care" an appropriate feedback response?
Attachment #8480870 - Flags: feedback?(benjamin) → feedback+
Assignee: gijskruitbosch+bugs → nobody
Status: ASSIGNED → NEW
XULRunner has been removed from the Mozilla tree: see https://groups.google.com/forum/#!topic/mozilla.dev.platform/_rFMunG2Bgw for context. I am closing all the bugs currently in the XULRunner bugzilla component, in preparation for moving this component to the graveyard. If this bug is still valid in a XULRunner-less world, it will need to be moved to a different bugzilla component to be reopened.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: