Closed
Bug 949600
Opened 10 years ago
Closed 10 years ago
Move mozbase from github to m-c
Categories
(Testing :: Mozbase, defect)
Testing
Mozbase
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla30
People
(Reporter: ahal, Assigned: ahal)
References
Details
Attachments
(2 files, 4 obsolete files)
6.59 KB,
text/plain
|
Details | |
440.02 KB,
patch
|
ahal
:
review+
|
Details | Diff | Splinter Review |
This bug will track: 1) Preserving history (if possible) 2) Version bumping all mozbase packages 3) Performing one last sync to m-c 4) Deprecating the github repo
Comment 1•10 years ago
|
||
(In reply to Andrew Halberstadt [:ahal] from comment #0) > This bug will track: > > 1) Preserving history (if possible) > 2) Version bumping all mozbase packages > 3) Performing one last sync to m-c > 4) Deprecating the github repo Don't forget to update the doc autogeneration!
Assignee | ||
Comment 2•10 years ago
|
||
Preliminary try run: https://tbpl.mozilla.org/?tree=Try&rev=e0ef15568b44 This isn't a cutoff point or anything, I just wanted try results as soon as possible to see if there were issues we'd have to hunt down and fix.
Assignee | ||
Comment 3•10 years ago
|
||
More potential fallout: https://tbpl.mozilla.org/php/getParsedLog.php?id=31893817&tree=Try
Comment 4•10 years ago
|
||
Bug 950227 handles the problems as we can see on Windows. Wrong file permissions for files extracted from a zip archive is causing this problem.
Assignee | ||
Comment 5•10 years ago
|
||
Wlach pointed out that we also need to encourage devs to run the mozbase tests locally before committing to avoid unnecessary backouts. Filed bug 950829 to add a mach target for them.
Comment 6•10 years ago
|
||
When we do the merge, we also have to enable mozrunner tests by updating make check, which should pass in the binary. Only then we will be able to run those tests.
Whiteboard: [see comment 6]
Assignee | ||
Comment 7•10 years ago
|
||
Been awhile since the last try run. There are still some known issues that need fixing, but here's a new try run anyway, just to see if the latest changes to mozbase have broken anything else: https://tbpl.mozilla.org/?tree=Try&rev=d7cdf4cf4d12
Comment 8•10 years ago
|
||
You have removed the packages.txt file for mozbase which caused all builds to burn. But even with it included we have a lot of bustage given the pe file inclusion. So I don't think its worth doing a try on latest mozbase from github until we got bug 963176 solved.
Assignee | ||
Comment 9•10 years ago
|
||
Oops. Ok I'll wait for bug 963176 before further testing.
Assignee | ||
Comment 10•10 years ago
|
||
Since the pefile problem was fixed we discovered two new issues related to adding new modules. Here's a new try run with those fixed as well: https://tbpl.mozilla.org/?tree=Try&rev=842b31a7fa8d
Assignee | ||
Comment 11•10 years ago
|
||
Fixed the remaining errors in that last try run.. assuming they weren't hiding further problems we should be good to go. Here's a new try run: https://tbpl.mozilla.org/?tree=Try&rev=dd631ea627ad
Assignee: nobody → ahalberstadt
Status: NEW → ASSIGNED
Assignee | ||
Comment 12•10 years ago
|
||
Attachment #8375044 -
Flags: review?(wlachance)
Assignee | ||
Comment 13•10 years ago
|
||
Attachment #8375045 -
Flags: review?(wlachance)
Comment 14•10 years ago
|
||
Comment on attachment 8375045 [details] [diff] [review] Patch 1.2 - update reftest harness for mozdevice changes Review of attachment 8375045 [details] [diff] [review]: ----------------------------------------------------------------- lgtm. As you know, _checkCmd is an internal api that we shouldn't use, but I'm fine with fixing that later.
Attachment #8375045 -
Flags: review?(wlachance) → review+
Comment 15•10 years ago
|
||
Comment on attachment 8375044 [details] [diff] [review] Patch 1.1 - make mozversion known to m-c Review of attachment 8375044 [details] [diff] [review]: ----------------------------------------------------------------- lgtm
Attachment #8375044 -
Flags: review?(wlachance) → review+
Assignee | ||
Comment 16•10 years ago
|
||
Fingers crossed: https://tbpl.mozilla.org/?tree=Try&rev=e8810c59365b
Assignee | ||
Comment 17•10 years ago
|
||
Bug 966441 tracks pulling the mozbase tests out of make check, so I don't think we should do anything there to run the mozrunner tests. I updated that bug with a comment explaining the mozrunner situation.
Whiteboard: [see comment 6]
Assignee | ||
Comment 18•10 years ago
|
||
This looks good. Only a handful of oranges, none of which look related to this.
Attachment #8375043 -
Attachment is obsolete: true
Attachment #8376839 -
Flags: review?(wlachance)
Assignee | ||
Comment 19•10 years ago
|
||
Here's the output from qstatus to make the review a little easier.
Comment 20•10 years ago
|
||
Comment on attachment 8376839 [details] [diff] [review] Patch 1.0 - the sync Review of attachment 8376839 [details] [diff] [review]: ----------------------------------------------------------------- Great! ::: testing/mozbase/README.md @@ +1,1 @@ > +# Mozbase [![Build Status](https://travis-ci.org/mozilla/mozbase.png)](https://travis-ci.org/mozilla/mozbase) Delete this line
Attachment #8376839 -
Flags: review?(wlachance) → review+
Comment 21•10 years ago
|
||
(by the way I didn't really bother doing a detailed review, just assuming this was a literal copy of the mozbase repo)
Assignee | ||
Comment 22•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/a7f8c25c07ac Yeah, I just did a 'rm -rf testing/mozbase && cp -r ~/git/mozbase testing/'. I needed to be careful about added/removed files, but I stepped through hg status line by line to make sure I didn't leave anything behind.
Whiteboard: [leave-open]
Comment 24•10 years ago
|
||
Filed bug 974064 to track reconfiguring readthedocs (and patching where necessary) so we generate stuff from m-c.
See Also: → 974064
Assignee | ||
Comment 25•10 years ago
|
||
Along the way I decided not to do steps 1 and 2 from comment 0. Steps 3 and 4 are already done, and bug 974064 tracks updating our readthedocs instance. So I don't think there is anything left to do. One thing people may want to look into is porting the versionbump.py script over to hg. Personally I don't have much interest in doing this as I always version bumped manually anyway. Just adding it as a footnote.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Backed out in http://hg.mozilla.org/mozilla-central/rev/8cfebc57002c due to changes that apparently broke CLOBBER: [15:52] <philor> wlach: https://tbpl.mozilla.org/php/getParsedLog.php?id=34869690&tree=Mozilla-Inbound - we touched CLOBBER and now OS X is busted, is it possible I'm right in wanting to blame ahal's mozbase update from this morning? [15:53] <wlach> philor: hmmmmmm.... <philor> it did touch mozfile/mozfile/mozfile/mozfile/mozfile/mozfile.py... <wlach> it did [15:54] this mozfile stuff makes me grumpy let me take a closer look at what it's trying to do <KWierso> wlach, philor: as a side point, I hit the clobberer for linux opt on inbound and retriggered the build, and it seems to be going just fine [15:55] <philor> KWierso: yeah, that would cause the build system's autocobberer to say "nothing to do, no need for me to break" * AutomatedTester mutters about people wanting to centralise a DVCS... <philor> just another reason to clobber early often and constantly [15:58] <wlach> philor: so this is weird philor: we're throwing an exception, except that exception is supposed to be caught http://hg.mozilla.org/integration/mozilla-inbound/file/f8cd1f2d686e/testing/mozbase/mozfile/mozfile/mozfile.py#l151 oh [15:59] it's an errno.EPERM, which we don't retry on [16:00] philor: I think the problem is the build slave, not mozbase why shouldn't we be able to delete that thing if we have permissions? especially on mac <KWierso> wlach: it's more than just the one slave: https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=f8cd1f2d686e [16:02] <wlach> KWierso: ok, guess there's some bigger problem god there were so many changes here it's difficult to unwind I hate mozfile [16:04] ok, looking more closely I think it's a good bet that the new update permissions code in mozfile is to blame [16:05] this update_permissions stuff (where we're seeing the error) seems to be new http://hg.mozilla.org/integration/mozilla-inbound/diff/a7f8c25c07ac/testing/mozbase/mozfile/mozfile/mozfile.py [16:06] philor: I think we should backout philor: could you please reference my irc comments about the new permissions code in mozfile being to blame [16:08] hopefully the fix is not too difficult
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 27•10 years ago
|
||
(In reply to Andrew Halberstadt [:ahal] from comment #25) > ... One thing people may want to > look into is porting the versionbump.py script over to hg. Personally I > don't have much interest in doing this as I always version bumped manually > anyway. I think this would be useful, since whilst much of the old versionbump.py functionality is now redundant (diff to apply to m-c, tagging of mozbase repo etc), the bumping of versions for dependencies & also rolling up of package/upload to pypi is something that would take a bit of figuring out for me & other infrequent contributors each time, having forgotten since the last etc.
Comment 30•10 years ago
|
||
> /builds/slave/m-in-osx64-0000000000000000000/build/obj-firefox/i386/_virtualenv/include/python2.7
So can anyone please tell me what kind of virtual environment this is? For what is it used? Is it still active?
Comment 31•10 years ago
|
||
Also which steps I would have to perform to reproduce this on my local system? Is triggering a clobber enough after building Firefox?
Comment 32•10 years ago
|
||
(In reply to Ed Morley [:edmorley UTC+0] from comment #27) > I think this would be useful, since whilst much of the old versionbump.py > functionality is now redundant (diff to apply to m-c, tagging of mozbase > repo etc), the bumping of versions for dependencies & also rolling up of > package/upload to pypi is something that would take a bit of figuring out > for me & other infrequent contributors each time, having forgotten since the > last etc. Yes, that's something I see as must have. There are too many dependencies between the different packages that we would need at least the --info option working. Without that it would be even hard for me to figure out what version to bump, to not break dependencies. We should really include this file.
Comment 33•10 years ago
|
||
(In reply to Henrik Skupin (:whimboo) from comment #30) > > /builds/slave/m-in-osx64-0000000000000000000/build/obj-firefox/i386/_virtualenv/include/python2.7 > > So can anyone please tell me what kind of virtual environment this is? For > what is it used? Is it still active? So attachment 8377995 [details] gives the answer here. We are trying to modify the permissions of the /usr/include/python2.7/ folder instead for the symlink: $ ll obj-android/_virtualenv/include/python2.7 lrwxrwxrwx 1 mcomella users 22 Feb 14 17:53 obj-android/_virtualenv/include/python2.7 -> /usr/include/python2.7/ I will morph bug 974225 to testing/mozbase to get this problem fixed in mozfile.
Assignee | ||
Comment 34•10 years ago
|
||
For simplicity, here's a single patch containing the 3 patches in this bug, plus Henrik's fix in bug 974225. Carrying r+ forward.
Attachment #8375044 -
Attachment is obsolete: true
Attachment #8375045 -
Attachment is obsolete: true
Attachment #8376839 -
Attachment is obsolete: true
Attachment #8378558 -
Flags: review+
Assignee | ||
Comment 35•10 years ago
|
||
Let us join hands and pray to the tinderbox gods: https://hg.mozilla.org/integration/mozilla-inbound/rev/b36a250468e7 This time, forcing a CLOBBER as well: https://hg.mozilla.org/integration/mozilla-inbound/rev/cc7d6d3ebc7e
Whiteboard: [leave-open]
Comment 36•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/b36a250468e7 https://hg.mozilla.org/mozilla-central/rev/cc7d6d3ebc7e
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in
before you can comment on or make changes to this bug.
Description
•