Closed
Bug 1001224
Opened 11 years ago
Closed 11 years ago
Updates to gaia-node-modules are burning TBPL
Categories
(Firefox OS Graveyard :: Gaia, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
2.0 S1 (9may)
People
(Reporter: kgrandon, Assigned: kgrandon)
References
Details
(Whiteboard: [p=3],[systemsfe])
Attachments
(5 files)
From my dev-gaia email:
We have had to do a few backouts recently due to gaia-node-modules updates burning TBPL. I think there is something wrong with sockit-to-me rebuilding on TBPL. I am not entirely sure what's going on yet, so if anyone has any ideas it would be greatly appreciated. We are seeing errors like:
https://tbpl.mozilla.org/php/getParsedLog.php?id=38375867&tree=B2g-Inbound
https://tbpl.mozilla.org/php/getParsedLog.php?id=38432781&tree=B2g-Inbound
In the meantime, please avoid updating package.json or gaia_node_modules.revision without pushing to gaia-try first.
We think this may be related to the fact that there are two versions of sockit-to-me in the modules dependency tree. We should probably just be using 0.2.0.
Comment 1•11 years ago
|
||
Do we really need the dependency twice? It seems that we have circular once.
Definitely having the same version of sockit-to-me everywhere would help.
Comment 2•11 years ago
|
||
First of all, thanks for looking into this issue.
I found that some binaries of sockit-to-me would be updated when we we try to do "npm install marionette-client", as shown in the following changes,
https://github.com/mozilla-b2g/gaia-node-modules/commit/b7d10840775e9699e60881f662794121b5800cc5
This binaries updating would happen even when I installed marionette-client 1.1.5 (current in-use version in Gaia), and 1.1.5 should be using sockit-to-me 0.2 right now.
Not sure why sockit-to-me got changed while no obvious version update.
Comment 3•11 years ago
|
||
Duh. This shouldn't happen: it is definitely wrong.
Assignee | ||
Comment 4•11 years ago
|
||
Guess I'll take this.
Assignee: nobody → kgrandon
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•11 years ago
|
||
I think this is mostly manifest bumps, so going to go with R=me unless there is anything different that needs to happen.
First step is to land a marionette-plugin-forms update.
Assignee | ||
Comment 6•11 years ago
|
||
Comment 7•11 years ago
|
||
After looking further, it seems that I never updated the binaries for sockit-to-me in the npm module.
Assignee | ||
Comment 8•11 years ago
|
||
Assignee | ||
Comment 9•11 years ago
|
||
(In reply to Hubert Figuiere [:hub] from comment #7)
> After looking further, it seems that I never updated the binaries for
> sockit-to-me in the npm module.
Hmm, if we are going to keep using this extension we really need an automated solution for it =/
Assignee | ||
Comment 10•11 years ago
|
||
Anyway, I'm testing this change on try to see what it does, but it sounds like we may need to do another round of package bumps.
https://tbpl.mozilla.org/?tree=Try&rev=88e0f40d6bab
Assignee | ||
Comment 11•11 years ago
|
||
On try again with the latest sockit-to-me: https://tbpl.mozilla.org/?tree=Try&rev=99304ae95f8b
Assignee | ||
Updated•11 years ago
|
Whiteboard: [p=1],[systemsfe]
Target Milestone: --- → 2.0 S1 (9may)
Assignee | ||
Comment 12•11 years ago
|
||
Hub - I can't seem to figure out if we got these binaries in properly. I'm now seeing the following error, any chance you could look into it?
https://tbpl.mozilla.org/php/getParsedLog.php?id=38657462&tree=Try
Thanks!
Flags: needinfo?(hub)
Assignee | ||
Comment 13•11 years ago
|
||
Also pinging Aus here so he is aware and may have some insights.
Flags: needinfo?(aus)
Comment 14•11 years ago
|
||
Did we compile both 64 and 32bit linux binaries? We need both for tbpl. Is there also a reason why we can't have tbpl compile the module during install? I know that travis needs it pre-compiled but, maybe we can case it so that tbpl always gets a fresh binary.
I think Gareth worked on making this function as expected on Travis so I'm CC'ing him too.
Flags: needinfo?(aus) → needinfo?(gaye)
Assignee | ||
Comment 15•11 years ago
|
||
The remaining problem is a sockit-to-me one, so unassigning from myself.
Aus/Hub - we *really* need a fix for this so we can iterate on modules. If we don't have one by EoD we're probably going to need to move forward with reverting to 0.1.8 so we can unblock people.
Assignee: kgrandon → nobody
Comment 16•11 years ago
|
||
(In reply to Ghislain Aus Lacroix [:aus] from comment #14)
> Did we compile both 64 and 32bit linux binaries? We need both for tbpl.
Yes I did.
> Is
> there also a reason why we can't have tbpl compile the module during
> install? I know that travis needs it pre-compiled but, maybe we can case it
> so that tbpl always gets a fresh binary.
>
> I think Gareth worked on making this function as expected on Travis so I'm
> CC'ing him too.
It worked before fine. The issue rose because I didn't realize I didn't rebuild the binaries, and then somebody replaced them by mistake.
Flags: needinfo?(hub)
Comment 17•11 years ago
|
||
(In reply to Kevin Grandon :kgrandon from comment #15)
> The remaining problem is a sockit-to-me one, so unassigning from myself.
>
> Aus/Hub - we *really* need a fix for this so we can iterate on modules. If
> we don't have one by EoD we're probably going to need to move forward with
> reverting to 0.1.8 so we can unblock people.
I'll what I can do. It worked for a while fine so.... If only the whole thing was not that fragile *sigh*
Comment 18•11 years ago
|
||
Here the problem kevin. In gaia-node-module:
./node_modules/marionette-client/node_modules/sockit-to-me/build/Release/sockit.node: Mach-O 64-bit x86_64 bundle
Because this should NEVER have been checked in.
Will fix it.
Comment 19•11 years ago
|
||
With this it should not be a problem.
Attachment #8414803 -
Flags: review?(kgrandon)
Assignee | ||
Comment 20•11 years ago
|
||
(In reply to Hubert Figuiere [:hub] from comment #18)
> Here the problem kevin. In gaia-node-module:
>
> ./node_modules/marionette-client/node_modules/sockit-to-me/build/Release/
> sockit.node: Mach-O 64-bit x86_64 bundle
>
> Because this should NEVER have been checked in.
>
> Will fix it.
Thanks Hub. Let's go with this for now and test it on try. If files are getting checked in that should not, then we need to update some gitignore files or documentation.
Flags: needinfo?(gaye)
Assignee | ||
Updated•11 years ago
|
Attachment #8414803 -
Flags: review?(kgrandon) → review+
Assignee | ||
Comment 21•11 years ago
|
||
Landed in gaia-node-modules: https://github.com/mozilla-b2g/gaia-node-modules/commit/3dffe8543113000eb4ff11565223aa3f2e37e5fb
Assignee | ||
Comment 22•11 years ago
|
||
Latest gaia-node-modules updates are on gaia-try now: https://tbpl.mozilla.org/?tree=Try&rev=434d0ba4e3de
Assignee | ||
Comment 23•11 years ago
|
||
Hub - I think this could fix inadvertent updates in the future? Look good to you?
Attachment #8414986 -
Flags: review?(hub)
Comment 24•11 years ago
|
||
Comment on attachment 8414986 [details]
Gitignore update
I had a similar .gitignore ready for a PR.
Attachment #8414986 -
Flags: review?(hub) → review+
Assignee | ||
Comment 25•11 years ago
|
||
Awesome, thanks! Landed the gitignore: https://github.com/mozilla-b2g/gaia-node-modules/commit/b4de3a6573321b0868e6e650849fe9f17f3aa6fb
Assignee | ||
Comment 26•11 years ago
|
||
Try is green, so I think we are going to be good to land here.
Assignee: nobody → kgrandon
Whiteboard: [p=1],[systemsfe] → [p=3],[systemsfe]
Assignee | ||
Comment 27•11 years ago
|
||
Let's see if this sticks: https://github.com/mozilla-b2g/gaia/commit/68e4ae3bc6af77091635e0b72d831748e6c2a620
Thanks for the work on this Hub!
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•