Closed Bug 525674 Opened 10 years ago Closed 10 years ago
Fennec repacks on change busted due that they are trying to load incorect all-locales URL
In my local buildbot install, there are no builds for fennec due to a bustage in resolving the path to all-locales. I have a fix in my head, and that's overloading the AsyncLoader's getDepth to try source-depth first. How does that look on the releng side? I didn't find anything on-push related on the waterfall, do we even have builds for that?
Not sure how it will affect us (if it does). Maybe some code might help us answer that question.
Well, looking at l10nbuilds2.ini, the builders-on-push are "Maemo mozilla-1.9.2 l10n" and "Linux Fennec Desktop mozilla-1.9.2 l10n", and I haven't found a build on those with a non-empty blame list. Looks to me like we're not triggering any builds, and that'd be because the all-locales comes in with an error. Verifying that that is indeed the case requires one to actually look at a twistd.log with debug info on, which our masters do. It would try to load http://hg.mozilla.org/mobile-browser/raw-file/locales/all-locales instead of http://hg.mozilla.org/mobile-browser/raw-file/default/locales/all-locales
OK I now know what you are saying. I can look into this.
Assignee: nobody → armenzg
Status: NEW → ASSIGNED
Summary: Fennec repacks on change busted due to lack of all-locales? → Fennec repacks on change busted due that they are trying to load incorect all-locales URL
Axel we don't have repacks on change for Fennec scenario. For Firefox we have two builders, one for the nightly scenario and another for the repack-on-change. In the Fennec scenario we have only one builder and it is used for the nightly scenario. I have verified the URL is incorrect as well (no "default" in it): Starting factory <HTTPClientFactory: http://hg.mozilla.org/mobile-browser/raw-file/locales/all-locales> Could we turn this bug into "add repack-on-change for Fennec L10n desktop and maemo builds"?
Putting back into the pool while I work on other bugs since this is not a simple fix but requires adding builders and more testing.
Assignee: armenzg → nobody
Status: ASSIGNED → NEW
Component: Release Engineering → Release Engineering: Future
This patch is running on my l10n buildbot now and seems to cut it. It doesn't fork the base L10nConfigParser between compare-locales and buildbotcustom, which is nice, and maps one of the changes that I do in SourceTreeConfigParser on the compare-locales side. This patch can't really land without the builders being set up, though. Not taking that part and getting the changes upstream together with this patch.
Attachment #410024 - Flags: review?(ccooper)
Attachment #410024 - Flags: review?(ccooper) → review+
Now that we have landed the builders, does this patch still apply? Are we still loading the wrong all-locales URL?
Taking so that I know that I did this patch. I wouldn't mind Armen or coop picking this up and making sure that it actually does the trick, as I don't have access to staging.
Assignee: nobody → l10n
Thanks for taking this. We will test in on staging. Are there more patches coming besides the one attached?
There's one more patch in my queue that's not yet ready, IIRC. I'm trying to improve the build properties stuff, still, as right now, I have to hack those in at least twice on my master. I'm not running my master with that patch, though.
Comment on attachment 410024 [details] [diff] [review] overload getDepth with something that looks for source-depth without forking http://hg.mozilla.org/build/buildbotcustom/rev/3f8614275080
Attachment #410024 - Flags: checked-in+
Assignee: l10n → nobody
Status: NEW → RESOLVED
Closed: 10 years ago
Component: Release Engineering: Future → Release Engineering
Resolution: --- → FIXED
Thanks for landing.
Assignee: nobody → l10n
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.