Closed
Bug 761516
Opened 12 years ago
Closed 12 years ago
Build webapprt/linux on any gtk2 platform including *bsd
Categories
(Firefox Graveyard :: Web Apps, defect, P1)
Tracking
(firefox15 verified)
VERIFIED
FIXED
Firefox 16
Tracking | Status | |
---|---|---|
firefox15 | --- | verified |
People
(Reporter: gaston, Assigned: gaston)
References
Details
(Whiteboard: [qa!])
Attachments
(3 files, 1 obsolete file)
1.94 KB,
patch
|
Felipe
:
review+
|
Details | Diff | Splinter Review |
1.26 KB,
patch
|
Felipe
:
review+
Gavin
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
881 bytes,
patch
|
marco
:
review+
Gavin
:
approval-mozilla-aurora+
Felipe
:
checkin+
|
Details | Diff | Splinter Review |
Since landing of #745018 , make package fails on OpenBSD (and probably any non-tier1 platforms) since MOZ_WEBAPP_RUNTIME defaults to 1 because toolkit is gtk, but webapprt/Makefile.in only cares about Win/Mac/Linux. So package tries to add non-built files. See bottom of http://buildbot.rhaalovely.net/builders/mozilla-central-amd64/builds/413/steps/package/logs/stdio. I have no friggin' idea what webapprt is not if it's supposed to run on unices different from Linux (a quick look at the code shows it should), so there are two options: - only define MOZ_WEBAPP_RUNTIME on platforms that _actually_ support it - enable/add the BSDs (and others ?) to webapps/Makefile.in For #2, the following unportable code : if (readlink("/proc/self/exe", curExePath, MAXPATHLEN) == -1) should be fixed to use something better (glandium pointed me at BinaryPath::Get used by {b2g,browser}/app/nsBrowserApp.cpp, dunno if that's 100% equivalent)
Comment 1•12 years ago
|
||
Marco - Can you take a look at this?
Updated•12 years ago
|
Component: Web Apps → Build Config
Product: Firefox → Core
QA Contact: webapps → build-config
Version: unspecified → Trunk
Updated•12 years ago
|
Component: Build Config → Web Apps
Product: Core → Firefox
QA Contact: build-config → webapps
Comment 2•12 years ago
|
||
This should stay under webapps, because the "linux" runtime should be enabled, and fixed for support of non-linux.
Assignee | ||
Comment 3•12 years ago
|
||
Trying a fix here (ie build under linux if TOOLKIT=gtk2 + replace readlink by BinaryPath::Get). Since we're tied to gtk here, might aswell use glib functions g_dirname for GetDirFromPath() and GIO functions for CopyFile()..
Assignee | ||
Comment 4•12 years ago
|
||
This patches fixes the issue for me. dist/./webapprt-stub gives an error dialog about missing webapp.ini, so at least it goes further than GetBinary::Path. One could argue that putting the gtk code under a linux/ dir was a slightly wrong decision...
Assignee: nobody → landry
Attachment #630131 -
Flags: review?(jst)
Comment 5•12 years ago
|
||
The first implementation was using GIO, but I later decided not to use it (as Firefox isn't built with GIO by default). I was working on the Linux implementation, this is why I put the code under the linux/ dir. Indeed we should set MOZ_WEBAPPS_RUNTIME only for Linux GTK2 or, if the implementation is working on other *nix platforms (even if it wasn't supposed to work), use your solution. (You have to install an application to completely test the binary, this is probably why webapp.ini was missing)
Assignee | ||
Comment 6•12 years ago
|
||
I see no reason it wouldn't work, and atm it breaks builds. As the code landed before the mc->aurora uplift the same failures probably happen on aurora, so once we have something commited to m-c i'll nominate it for approval-aurora..
Comment 7•12 years ago
|
||
It'd be good to actually verify that it works in other *nix, and if it does maybe we should rename webapprt/linux to webapprt/gtk2?
Assignee | ||
Comment 8•12 years ago
|
||
(In reply to Felipe Gomes (:felipe) from comment #7) > It'd be good to actually verify that it works in other *nix, and if it does > maybe we should rename webapprt/linux to webapprt/gtk2? It 'works' on openbsd in the sense that it doesnt blow up at startup. If you give me a procedure on how to actually test it (ie dl a "webapp" and run it ?) i can do some testing.
Comment 9•12 years ago
|
||
Yes, install a webapp either from https://apps.mozillalabs.com/appdir/ or http://testmanifest.com The app should show up in your system. Then launch it and see if it opens the right webpage in a standalone application
Comment 10•12 years ago
|
||
Here's a test case to try specifically: 1. Go to apps.mozillalabs.com/appdir 2. Install Mozilla QA WebRT Tester 3. Launch Mozilla QA WebRT Tester 4. Try some of the functionality in the Mozilla QA WebRT Tester such as: a. Launch a pop-up b. View a swf file 5. Close the app
Assignee | ||
Comment 11•12 years ago
|
||
Mhh.. so what ive done so far with a 16.0a1 build with that patch : - go to https://apps.mozillalabs.com/appdir/ (note that the applist doesnt show up in webkit browsers, and in ffx 12 if i try to install an app it says 'network error' - there should be smth for firefoxes not supporting webapps,no ?) - click on install mozilla qa webrt - there's the 'do you want to install' prompt, i select install - the throbber which replaced the 'install button' spins indefinitely If i look at my profile, i have /home/landry/.mozilla/firefox/gupt1o5c.xxx/webapps/ webapps.json {50ea0339-fddf-4952-bcb6-3552a85b0f30}/ {50ea0339-fddf-4952-bcb6-3552a85b0f30\}/manifest.webapp < No sign of webapp.ini, so i'm not sure the installation completed. And where should the app 'show up in my system' ? It creates a launcher .desktop file somewhere ? In a fd.o compliant menu ? somewhere in firefox menus ? Where is it supposed to show up on linux ?
Comment 12•12 years ago
|
||
Thank you for your testing. The installation creates a directory under your home and a desktop entry file under ~/.local/share/applications. Their name's format is: https://mxr.mozilla.org/mozilla-central/source/browser/modules/WebappsInstaller.jsm#655 The application icon will be in the applications menu (it depends on the desktop environment you're using).
Comment 13•12 years ago
|
||
Landry: yeah the installation should create a launcher as Marco said. If it's not there the installation is failing at some point, and there should be a useful error message in the Error Console
Updated•12 years ago
|
Priority: -- → P1
Target Milestone: --- → Firefox 16
Comment 14•12 years ago
|
||
Comment on attachment 630131 [details] [diff] [review] Build linux/webapprt on all gtk platforms r=jst. If this doesn't work, it seems we should file a bug to put the /proc/self/exe code that this removes into mozilla::BinaryPath::Get(), and run that on linux systems instead of the guessing game that we do there now.
Attachment #630131 -
Flags: review?(jst) → review+
Assignee | ||
Comment 15•12 years ago
|
||
Att #630131 didnt apply since Bug 749930 landed, posting another patch in a sec.. and a patch against aurora too. I've also successfully tested webapp rt tester and marble run apps.
Assignee | ||
Updated•12 years ago
|
Summary: make package fails on *nix platforms != linux since bug 745018 → Build webapprt/linux on any gtk2 platform including *bsd
Assignee | ||
Comment 16•12 years ago
|
||
Attachment #630131 -
Attachment is obsolete: true
Attachment #631842 -
Flags: review?(jst)
Assignee | ||
Comment 17•12 years ago
|
||
[Approval Request Comment] Bug caused by (feature/regressing bug #): 745018 User impact if declined: Build failure on non-linux gtk2 platforms Testing completed (on m-c, etc.): Yes, in this bug Risk to taking this patch (and alternatives if risky): none ? String or UUID changes made by this patch: none
Attachment #631843 -
Flags: review?(jst)
Attachment #631843 -
Flags: approval-mozilla-aurora?
Comment 18•12 years ago
|
||
This could also fix bug 763192, as on Ubuntu there are problems with /proc/self/exe on some kernels (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1007089)
Comment 19•12 years ago
|
||
Comment on attachment 631842 [details] [diff] [review] Build linux/webapprt on all gtk platforms Simple line number update, it's not necessary to re-request review on these cases
Attachment #631842 -
Flags: review?(jst) → review+
Comment 20•12 years ago
|
||
Let's get this landed on mozilla-central before approving for Aurora.
Comment 21•12 years ago
|
||
Marco, is changing webapprt/linux to webapprt/gtk2 something that we also want to change? Should we do this together with this bug or do you want to wait to check if there will be more work involved to support gtk2 on all *nix?
Attachment #631963 -
Flags: review?(mar.castelluccio)
Comment 22•12 years ago
|
||
Comment on attachment 631843 [details] [diff] [review] Build linux/webapprt on all gtk platforms (aurora patch) (I will re-request aurora approval after this sticks in mozilla-central)
Attachment #631843 -
Flags: review?(jst)
Attachment #631843 -
Flags: review+
Attachment #631843 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 23•12 years ago
|
||
oops, i've already pushed att 631842 to m-i before seeing your patch.. http://hg.mozilla.org/integration/mozilla-inbound/rev/5c5336ccf186
Assignee | ||
Updated•12 years ago
|
Comment 24•12 years ago
|
||
Comment on attachment 631963 [details] [diff] [review] Rename webapprt/linux to webapprt/gtk2 Yes, I think we can do this now. After all, it's just a name change :)
Attachment #631963 -
Flags: review?(mar.castelluccio) → review+
Comment 25•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/5c5336ccf186
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 26•12 years ago
|
||
Marco - Can you verify this fix on mozilla central or inbound?
Whiteboard: [qa+]
Assignee | ||
Comment 27•12 years ago
|
||
Shouldn't this bug stay open for the linux->gtk2 rename and the pending aurora approval ?
Comment 28•12 years ago
|
||
(In reply to Landry Breuil (:gaston) from comment #27) > Shouldn't this bug stay open for the linux->gtk2 rename and the pending > aurora approval ? Yes for the rename. For the aurora approval, set status-firefox15 flag to fixed when the aurora patch lands, but the bug is not reopened for that.
Comment 29•12 years ago
|
||
Comment on attachment 631963 [details] [diff] [review] Rename webapprt/linux to webapprt/gtk2 Landed the rename on inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/d42e98ca091a we can now close the bug when it gets merged to m-c, and then request aurora approval
Attachment #631963 -
Flags: checkin+
Comment 30•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/d42e98ca091a
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 31•12 years ago
|
||
I suppose that both commits have to be backported to aurora, no ?
Comment 32•12 years ago
|
||
(In reply to Landry Breuil (:gaston) from comment #31) > I suppose that both commits have to be backported to aurora, no ? Yes. Please nominate for Aurora.
Assignee | ||
Comment 33•12 years ago
|
||
Comment on attachment 631843 [details] [diff] [review] Build linux/webapprt on all gtk platforms (aurora patch) [Approval Request Comment] Bug caused by (feature/regressing bug #): 745018 User impact if declined: Build failure on non-linux gtk2 platforms Testing completed (on m-c, etc.): Yes, in this bug Risk to taking this patch (and alternatives if risky): none ? String or UUID changes made by this patch: none
Attachment #631843 -
Flags: approval-mozilla-aurora?
Assignee | ||
Comment 34•12 years ago
|
||
Comment on attachment 631963 [details] [diff] [review] Rename webapprt/linux to webapprt/gtk2 [Approval Request Comment] Bug caused by (feature/regressing bug #): 745018 User impact if declined: Build failure on non-linux gtk2 platforms Testing completed (on m-c, etc.): Yes, in this bug Risk to taking this patch (and alternatives if risky): none ? String or UUID changes made by this patch: non
Attachment #631963 -
Flags: approval-mozilla-aurora?
Updated•12 years ago
|
Attachment #631843 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Updated•12 years ago
|
Attachment #631963 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Assignee | ||
Comment 35•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/621324aea193 https://hg.mozilla.org/releases/mozilla-aurora/rev/0287e34ea0f8
Updated•12 years ago
|
tracking-firefox15:
? → ---
Updated•12 years ago
|
Flags: in-moztrap?(mar.castelluccio)
Comment 36•12 years ago
|
||
I can't set *bsd as environment for a test case with MozTrap.
Assignee | ||
Comment 37•12 years ago
|
||
What's needed to run such a test? If you give me the steps i can try
Comment 38•12 years ago
|
||
MozTrap is the mozilla tool to handle manual test cases, we should simply add *bsd as a platform where we should do webapps related tests. I'd also need to verify the fix on *bsd, could you send me a bsd build?
Assignee | ||
Comment 39•12 years ago
|
||
You can grab my builds at http://buildbot.rhaalovely.net/builds/ but you'll need to install openbsd -current to try it
Comment 40•12 years ago
|
||
(In reply to Marco Castelluccio from comment #36) > I can't set *bsd as environment for a test case with MozTrap. Took care of adding it to the list of environments and linked it to the existing Linux test cases. If you search for "apps" and "Open BSD," then you should see the list of test cases for testing this feature so far under Open BSD. We should probably do a quick spot check to make sure that the web runtime works on Open BSD.
Updated•12 years ago
|
Flags: in-moztrap?(mar.castelluccio) → in-moztrap+
Comment 41•12 years ago
|
||
Landry - Are you able to install web apps on the latest nightly and launch them on Open BSD?
Assignee | ||
Comment 42•12 years ago
|
||
It worked 3 weeks ago.. do you think another change broke it in the meantime ? What do you want me to test in particular ?
Comment 43•12 years ago
|
||
(In reply to Landry Breuil (:gaston) from comment #42) > It worked 3 weeks ago.. do you think another change broke it in the meantime > ? What do you want me to test in particular ? In that case, I'll mark this as verified. Was looking to know if the patch works on a release build.
Updated•12 years ago
|
QA Contact: jsmith
Updated•8 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•