Closed Bug 949600 Opened 8 years ago Closed 8 years ago
Move mozbase from github to m-c
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
(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!
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.
More potential fallout: https://tbpl.mozilla.org/php/getParsedLog.php?id=31893817&tree=Try
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.
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.
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]
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
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.
Oops. Ok I'll wait for bug 963176 before further testing.
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
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
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 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+
Fingers crossed: https://tbpl.mozilla.org/?tree=Try&rev=e8810c59365b
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]
This looks good. Only a handful of oranges, none of which look related to this.
Here's the output from qstatus to make the review a little easier.
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+
(by the way I didn't really bother doing a detailed review, just assuming this was a literal copy of the mozbase repo)
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.
Filed bug 974064 to track reconfiguring readthedocs (and patching where necessary) so we generate stuff from m-c.
See Also: → 974064
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: 8 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 → ---
(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.
> /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?
Also which steps I would have to perform to reproduce this on my local system? Is triggering a clobber enough after building Firefox?
(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.
(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.
For simplicity, here's a single patch containing the 3 patches in this bug, plus Henrik's fix in bug 974225. Carrying r+ forward.
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
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.