Closed Bug 1074572 Opened 6 years ago Closed 4 years ago
blocklist update failing: blocklist
After fixing the blocklist url in bug 1066896, we're now busted with the following error: --2014-09-27 03:02:17-- http://hg.mozilla.org/releases/comm-aurora/raw-file/default/suite/app/blocklist.xml Resolving hg.mozilla.org... 18.104.22.168 Connecting to hg.mozilla.org|22.214.171.124|:80... connected. HTTP request sent, awaiting response... 200 Script output follows Length: 0 [text/xml] Saving to: ‘blocklist_hg.xml’ 0K 0.00 =0s 2014-09-27 03:02:17 (0.00 B/s) - ‘blocklist_hg.xml’ saved [0/0] HG blocklist does not appear to be an XML file. wget error? program finished with exit code 1 elapsedTime=0.428947 When I manually plug in that url: http://hg.mozilla.org/releases/comm-aurora/raw-file/default/suite/app/blocklist.xml, I get an XML error. Apparently, the blocklist.xml in c-a suite/app is empty.
Ok, the culprit cset was http://hg.mozilla.org/releases/comm-aurora/rev/df5554bd4991.
Summary: blocklist update failing: blocklist invalid format → blocklist update failing: blocklist.xml empty
Here's my rationale. Currently, the behaviour is this: If the current blocklist.xml in repo is empty and sync-hg-blocklist.sh tests the size if is > 0 or it has an invalid xml header. Since the blocklist.xml is empty, the whole condition is true and thusly the error is shown: HG blocklist does not appear to be an XML file. wget error? But if the previous 'update' to the blocklist saved an empty file (which is what happened in this case), the retrieval of the blocklist.xml file and the subsequent test will produce the error. What we want is that that the empty blocklist.xml be overwritten by the new amo list (which is valid... otherwise, we won't even get to this part). However, if the retrieved blocklist was not empty but corrupted, then that's when we should go red.
Assignee: nobody → ewong
Status: NEW → ASSIGNED
This is also in ftp://ftp.mozilla.org/pub/firefox/nightly/31.2.0esr-candidates/build1/source/firefox-31.2.0esr.source.tar.bz2 tarball. To be more accurate, file: mozilla-esr31/browser/app/blocklist.xml is also empty in build1 of firefox 31.2.0esr.
Going to backout http://hg.mozilla.org/comm-central/rev/df5554bd4991. That should remove the empty blocklist changes.
Ok.. combined with fixing bug 1066896, and backing out df5554bd4991, the blocklist builder is now green. The attached patch hopes to avert writing over a good blocklist.xml with an empty one.
Possibly needs to be pushed to c-a, c-b and c-r. (actually, it's essentially a backout of the last empty blocklist.xml update.
This is pretty much similar to bug 1315878 which probably has a better solution.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1315878
You need to log in before you can comment on or make changes to this bug.