Closed Bug 1074572 Opened 6 years ago Closed 4 years ago

blocklist update failing: blocklist.xml empty

Categories

(SeaMonkey :: Release Engineering, defect)

x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1315878

People

(Reporter: ewong, Assigned: ewong)

References

Details

Attachments

(2 files)

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.
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
Attachment #8497208 - Flags: review?(bugspam.Callek)
Blocks: 1072713
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.
Attached patch backout patchSplinter Review
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.
Attachment #8497208 - Flags: review?(bugspam.Callek)
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.