1074572 - blocklist update failing: blocklist.xml empty

Status: RESOLVED DUPLICATE of bug 1315878

(SeaMonkey :: Release Engineering, defect)

Description

[Edmund Wong (:ewong)]

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... 63.245.215.25
Connecting to hg.mozilla.org|63.245.215.25|: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.

Comment 1

[Edmund Wong (:ewong)]

Ok, the culprit cset was http://hg.mozilla.org/releases/comm-aurora/rev/df5554bd4991.

Comment 2

[Edmund Wong (:ewong)]

Attachment: proposed patch (v1)

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.

Comment 3

[Jan Horak [:jhorak]]

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.

Comment 4

[Edmund Wong (:ewong)]

Going to backout http://hg.mozilla.org/comm-central/rev/df5554bd4991.  That
should remove the empty blocklist changes.

Comment 5

[Edmund Wong (:ewong)]

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.

Comment 6

[Edmund Wong (:ewong)]

Attachment: backout patch

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.

Comment 7

[Edmund Wong (:ewong)]

This is pretty much similar to bug 1315878 which probably has a better
solution.