+++ This bug was initially created as a clone of Bug #1349525 +++ https://archive.mozilla.org/pub/thunderbird/candidates/52.1.1-candidates/build1/logs/release-comm-esr52-thunderbird_release_updates-bm74-build1-build3.txt.gz Traceback (most recent call last): File "tools/scripts/updates/create-update-verify-configs.py", line 106, in <module> pc = PatcherConfig(open(options.config).read()) File "/builds/slave/tb-rel-c-esr52-tb_rel_upds-000/tools/lib/python/release/updates/patcher.py", line 44, in __init__ self.readXml(cfg) File "/builds/slave/tb-rel-c-esr52-tb_rel_upds-000/tools/lib/python/release/updates/patcher.py", line 232, in readXml "No release found for version '%s'" % version) release.updates.patcher.PatcherConfigError: No release found for version '45.8.0' State Changed: unlock buildroot program finished with exit code 1 ----------- from Bug #1349525, per rail... This** is because 45.8.0 was listed in partials but it is not in https://hg.mozilla.org/build/tools/file/tip/release/patcher-configs/mozEsr52-thunderbird-branch-patcher2.cfg. To fix the issue we need to: 1) add <45.8.0> release entry to the config above (the following hunk: https://hg.mozilla.org/build/tools/rev/b95282e941f7#l1.96) 2) add the "post-update" change from the same commit: https://hg.mozilla.org/build/tools/rev/b95282e941f7#l1.78 3) retag the changes and rerun the step

I tried to do this, but I don't think it's right. See: https://hg.mozilla.org/build/tools/log/tip/release/patcher-configs/mozEsr52-thunderbird-branch-patcher2.cfg Look at the changes done by humans, in particular https://hg.mozilla.org/build/tools/rev/e93248b83654 There 45.8.0 was removed: https://hg.mozilla.org/build/tools/rev/e93248b83654#l1.34 so you're sure you want to add it back in?

For the record, I included 45.8.0 in the partials because I thought it likely we might enable automatic updates for some period of time.

nthomas can you look at comment 1? (jlorenzo is pto)

Pretty sure adding 45.8.0 back in will break.

I think we've made changes to the rules in the meantime. One of the failing requests from 52.0.1 was https://aus4.mozilla.org/update/3/Thunderbird/45.1.1/20160526140950/WINNT_x86-msvc-x86/ru/release-localtest/default/default/default/update.xml?force=1 It was giving back 45.8.0 then but now gives 52.1.0 (not 52.1.1 because the thunderbird_release_updates builders is what changes that). BTW, it's using an older url style (/update/3/) which doesn't send the %SYSTEM_CAPABILITIES% in /update/6/, so just completely side steps the SSE deprecation for Windows. Similar explanations for Linux/GTK3 and Mac/10.6-10.8. I'm going to try re-adding 45.8.0, retag, and rerun the updates job. https://hg.mozilla.org/build/tools/rev/20338dbb074a07f84e37c5144064bc876c73c03d https://hg.mozilla.org/build/tools/rev/98aa61cde555ab1f394443133ce5f4ee0b7e2f4e

The updates job was green and the update verifies are running. One thing I spotted in win 5/6, for 45.8.0 ar updating to 52.1.1 with a complete: succeeded calling QuitProgressUI Only in source/bin/distribution/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components: calbasecomps.dll Only in source/bin/distribution/extensions/{e2fda1a4-762b-4020-b5ad-a41df1933103}/components: libical-manifest WARN: non-binary files found in diff aka some lightning files from 45.x. aren't being cleaned up properly. Is it completely JS now so no problem ? Doesn't happen for a partial.

The binary component is now linked into libxul and shipped with Thunderbird, due to some xpcom changes that were made between 45 and 52. Therefore the dll is no longer there which is correct. I'm surprised the partial doesn't have the same behavior.

My hand-wavey theory is that the partial looks at the before and after file listings and explicitly removes discontinued files. Completes rely on the precommplete file from the existing install, and I'm guessing lightning didn't make it into there (distribution and/or extensions is treated specially). If you think there's a problem with the old file persisting then you could put it in removed-files.in.