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)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: Gijs, Unassigned)
Details
Attachments
(1 file)
4.10 KB,
patch
|
benjamin
:
feedback+
|
Details | Diff | Splinter Review |
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. :-(
Reporter | ||
Comment 1•10 years ago
|
||
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
Reporter | ||
Comment 2•10 years ago
|
||
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
Comment 3•10 years ago
|
||
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.
Reporter | ||
Comment 4•10 years ago
|
||
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)
Reporter | ||
Updated•10 years ago
|
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Comment 5•10 years ago
|
||
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.
Comment 6•10 years ago
|
||
(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.
Reporter | ||
Comment 7•10 years ago
|
||
(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?
Comment 8•10 years ago
|
||
(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...)
Reporter | ||
Comment 9•10 years ago
|
||
(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)
Reporter | ||
Comment 10•10 years ago
|
||
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)
Reporter | ||
Comment 11•10 years ago
|
||
Filed bug 1060787 on the aurora bustage, but m-c seems to just fail linking... not sure when that happened.
Flags: needinfo?(benjamin)
Comment 12•10 years ago
|
||
(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.
Reporter | ||
Comment 13•10 years ago
|
||
(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 14•10 years ago
|
||
Comment on attachment 8480870 [details] [diff] [review]
Initial patch
Is "I don't care" an appropriate feedback response?
Attachment #8480870 -
Flags: feedback?(benjamin) → feedback+
Reporter | ||
Updated•9 years ago
|
Assignee: gijskruitbosch+bugs → nobody
Status: ASSIGNED → NEW
Comment 15•9 years ago
|
||
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
Assignee | ||
Updated•9 years ago
|
Product: Toolkit → Toolkit Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•