Closed Bug 470811 Opened 14 years ago Closed 14 years ago
often nightly updates fail to install and ask for download of the full program (CRC check failed of the partial update)
641 bytes, text/plain
551 bytes, text/plain
635 bytes, text/plain
555 bytes, text/plain
600 bytes, text/plain
478 bytes, application/octet-stream
478 bytes, application/octet-stream
985 bytes, patch
|Details | Diff | Splinter Review|
5.60 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081222 Minefield/3.2a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20081222 Minefield/3.2a1pre Since the version 3.1b2 very often the nightly updates do not install and there is a request to download the full program to install the update which then works. And it continues with version 3.2a1pre This is also happening with thunderbird 3.0b2pre Reproducible: Sometimes Steps to Reproduce: 1.check for updates 2.download the nightly update 3.accept to install the nightly update 4.Installation fails 5.Request to download the full program 6.Download of the full size program 7.Installation proceeds ok Actual Results: Nighly update does not get installed Expected Results: Nightly update should get installed
Component: Installer → Application Update
Product: Firefox → Toolkit
QA Contact: installer → application.update
Please attach the last-update.log file after a failed update. It should be located in your installation directory in the updates directory.
I think I also have seen this intermittently using both Vista and XP. I will see if I can get the log from Win XP.
Marcia, that would be great. Please check if the log shows it fails on crash reporter in which case that would be a known issue that you have reported in another bug and wouldn't be of any help in this instance.
btw: the log file from Fernando would still be needed to verify that it was the same problem that Marcia has seen. Fernando, will you be able to provide the file as asked for in comment #1?
I have the log file of the update as requested, but I need a email address to send it or let me know how I can attach it here. It is a 123 kb file. I also have the log file for Schreder which has the same problem. Normally the problem happens in both with the same new nightly update
The "Add an attachment" link above these comments can be used to attach it. Please attach both log files. Thanks
Here is the Schreder update log file
here is the Minefield update log file
Attachment #354332 - Attachment mime type: application/octet-stream → text/plain
Attachment #354334 - Attachment mime type: application/octet-stream → text/plain
Fernando, these log files are both for successful updates. Are you sure they were unsuccessful? What specifically happens that indicates the update was unsuccessful?
Attachment #354334 - Attachment is patch: true
Attachment #354332 - Attachment is obsolete: true
Robert: My update log for Shiretoko looks like Fernando's (indicates success). It indicates a success update but I could swear that on my Win XP VM the update failed this AM, and I got an alert similar to when a partial update fails and it has to go out and get the full update. One note is that I have side by side installs on this VM of Minefield and Shiretoko, not sure if that matters.
That's fine but I need the update log from immediately after the failure and before installing the full update.
Filed bug 470979 so we have a copy of the partial update last-update.log when the partial fails and the full succeeds.
Possibly these files correspond to the succesful update with the full program which was downsload automatically upon failure of the nightly update. These files are the ones that appear as the last update log files and carry date of yesterday 22 december. The problem is that the log files destroy the previous one.
btw: partials have been succeeding for me consistently. I believe it is still the case that if you download an hourly build the partial will fail due to the update snippet providing partial update info when there are only mars created by build for a full update from hourly builds. What you need to do to provide the log file from the partial is get the last-update.log immediately after the failure and before the full update. In other words, immediately after the failure.
Here is a copy of the failed update log from my Win XP Machine. I went back and removed all existing FF versions from my machine and installed yesterday's Shiretoko nightly and then manually checked for updates. I did this using an existing profile.
Summary: very often (not every day) nightly updates fail to install and ask for download of the full program → often nightly updates fail to install and ask for download of the full program (CRC check failed of the partial update)
This log points to a CRC check failed. Not sure what is going on since the partial updates are working for me. Marcia, could you go through those steps again and copy the the updates directory along with the active-update.xml and updates.xml for a partial to a safe location (e.g. your desktop) so there are copies to take a look at? Then zip them up and attach them to this bug? Thanks
Here is a compressed version of what Robert requested in Comment 16. This is right after the update failed.
The partial update download appears to have not completed. Size of the attached partial mar 585 KB Size of the partial mar from the active-update.xml 2.21 MB A couple of other tell tale signs are that there is no update.version file which gets created after the update is downloaded and the state in active-update.xml is downloading. Marcia, does an error occur and the update ui display when you restart with the files you attached?
I just tried it with the attached files and it behaved correctly in that it started the process of finishing the download. Marcia, could you try it again and make sure the download completes. I suspect the mar file will be to big for this bug so could you please send it to my internal mozilla address? Thanks.
Attachment #354345 - Attachment is obsolete: true
After I get the update error and I continue with Next the software update is applied normally and I don't receive any error in the update UI. I am wrapping up for today but I will get the MAR file to you tomorrow via email.
(In reply to comment #20) > After I get the update error and I continue with Next the software update is > applied normally and I don't receive any error in the update UI. I am also curious if you get the update error when restarting after putting the files you attached back where they came from with the original names and restart... there shouldn't be one and I didn't get one as well.
Oddly enough, using the same machine I was able to successfully update from the build of Dec 23 to Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20081224 Shiretoko/3.1b3pre. As the reporter notes, this does not seem to happen each time. Back to going from 22nd -> 23rd to see if I can reproduce the original issue.
After uninstalling and going back to the build from the 22nd, I was not able to reproduce the problem on the machine that I was able to repro on yesterday. So for sure I was able to see the problem on the nightly update from 12/22->12/23 on two different Win XP machines, but I guess since I was updating from 22->24th the issue did not manifest itself and unfortunately I do not have the mar file. Sorry rstrong I forget to get you the mar file before I went ahead and continued my testing. I think the best thing we can do is be vigilant and monitor when this happens again, and try to get rstrong a copy of the mar file.
At this point I highly suspect this might be due to the server serving up the mar file since we've had a couple of issues with servers in the last couple of weeks.
The partial nightly update of 20081226 failed. I cannot locale the last-update.log file to send to you. Wait for your answer. the window of software update is waiting a reply saying "the partial update could not be applied.Minefield will try again by downloading a complete update
here is the log file of last update corresponding to 20081226
Attachment #354499 - Attachment mime type: application/octet-stream → text/plain
Ok, we have to wait on Roberts answer. No idea what "failed: 6" means.
Shredder night update for 20081226 also failed. Attached is the last update log file.
Attachment #354506 - Attachment mime type: application/octet-stream → text/plain
That is READ_ERROR... not sure what could be causing this at all and I have never experienced this myself.
Rob, do you have a link to the code where this error is raised?
Not positive off the top of my head where in the file it is but it is in updater.cpp
There are two instances: * WriteStatusFile: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/src/updater/updater.cpp#1151 * UpdateThreadFunc: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/src/updater/updater.cpp#1172 So it looks like we fail in writing the status file?
As I stated previously in comment #24 I highly suspect this is a server issue. Per the log it is unable to read one of the files in the mar and per Marcia the same mar was readable on a subsequent day. The code to read the mar files hasn't changed though it is possible that something changed outside of app update that has caused this. (In reply to comment #32) > There are two instances: > > * WriteStatusFile: > http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/src/updater/updater.cpp#1151 > > * UpdateThreadFunc: > http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/src/updater/updater.cpp#1172 > > So it looks like we fail in writing the status file? No, it looks like it is failing to read a file in the mar
The fact is thqat the problem happens in both Minefield and Thunderbir/Schredder on the same day updates. It usually does not happen in only one of them. And this has happened on several ocasions.
I am sure that this is happening to you and Marcia as the log files have indicated. Additional facts are that this does not happen to everyone, the error is with reading the mar files, the code that reads the mar files has not changed in an extremely long time, there have been server issues recently, and similar errors have occurred previously when we've had issues with the servers that host the mar files.
Also, if someone could get the files asked for in comment #16 then try to complete the update and if it fails let me know in this bug it should be possible to at least find out what is corrupted in the mar file. Keep in mind that if the update succeeds then these files won't provide any additional information and it won't be necessary to provide them or keep them.
Robert, could you elaborate on the server issues ? Do you have any further details that might help us debug ? The only machines in the loop are aus2.m.o and ftp.m.o, and the partial update generator. If the there are known times and IP addresses for download errors then we could ask IT to look at logs for ftp.m.o. Or Fernando and/or Marcia could set app.update.log.all to get more info ? For the case where the partial is truncated, shouldn't the update service to complain that the hash doesn't match, and move immediately to downloading the complete ? Seems odd that it would allow an attempt to apply the partial.
Not sure about the specifics of the server issues. Sam brought me in to help diagnose the problems so I cc'd Sam on this bug a few days ago in case he could provide specifics since he was involved on it more than I was. I know we had the problem with the update xml that I thought you were involved with and there was another issue with the mar file download not starting consistently during one of the security releases. The update service should complain about any mar that doesn't have the same hash but I haven't worked on that code and don't know the ins and outs of it... I'll take a look at that code path and test it. Once again, if someone could provide the files requested it would make it possible to figure out what is going on here since I have consistently been able to apply partial updates.
Please find today last update log file for Minefield 20081229 partial update which failed again. The nightly update of Schredder failed also which I send in next attachment
This is the Schredder log file for the nightly update 20081239 which failed
Can you please download yesterday's installer http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2008-12-28-03-mozilla-1.9.1/ Then: 1. install Firefox from the installer. 2. check for updates. 3. download the update. 4. leave the update wizard open on the last page (e.g. don't click any buttons after the update has finished downloading). 5. copy the updates directory to your desktop in your installation directory 6. copy the active-update.xml and updates.xml files into the updates directory on your desktop. 7. click the restart button on the update wizard. After doing the above make a comment in this bug as to whether the update succeeded or failed.
Attachment #354738 - Attachment mime type: application/octet-stream → text/plain
Attachment #354740 - Attachment mime type: application/octet-stream → text/plain
Yesterdat 20081228 partial update worked well without any problem
I'm not asking for you to try to update to yesterday's build which worked for you. I am asking you to install yesterday's build and update to today's build which did not work for you.
The partial update os Shiretoko failed
Please zip up the updates directory you copied to your desktop per the instructions in comment #41 step 5 and 6. Then try to attach them to this bug. The zip file may be too large and if it is please comment in this bug and I'll give you an email address to send them to.
Following the STR from Comment 41 I was once again able to reproduce the issue on my Windows XP VM and I have all the log files including the MAR file. I should be able to send the MAR file to rstrong via email. The failed log I got is the same as the previous one and indicates a CRC check failed.
Fernando, even though Marcia is able to reproduce I still need your files since you and Marcia are getting different errors and she is using a VM which might cause a different error to occur.
rstrong: I can try to replicate on a non VM machine if you want as well...
Marcia, if you could that would be great. What I am looking for is the same error as Fernando got in his log file.
Size to large of zip file for sending it as attachment. Wait for your email.
Size to large of zip file for sending it as attachment. Wait for your email.
Please send it to email@example.com
It appears that something (probably Firefox) is modifying one of the installation files which prevents the partial update from being applied successfully. The reason this doesn't happen on Vista with UAC turned on is that Firefox doesn't have the rights to modify files in the installation directory.
Marcia, could you try installing again, make a copy of the freebl3.chk file in the installation directory after a failed update, and attach it to this bug? Thanks
rstrong: I was able to reproduce the same issue (CRC check failed} on a Windows XP machine in the lab following the steps in Comment 41. This machine is running Win XP Professional with SP 3. I saved all the relevant files to a folder on the desktop of this machine in case it is needed.
The file I believe may be causing the problem is freebl3.chk... could you please attach one from an install that failed to update with a partial update? Thanks
Nevermind, I was finally able to reproduce.
Attachment #354757 - Attachment description: freebl3.chk from 8/28 extracted from a complete mar → freebl3.chk from extracted from a complete mar BuildID=20081228032813
Attachment #354757 - Attachment description: freebl3.chk from extracted from a complete mar BuildID=20081228032813 → freebl3.chk extracted from a complete mar BuildID=20081228032813
cc'ing a few folks that may know what is going on here. Looks like the freebl3.chk file in the installer is different from the one in the complete.mar which is causing partial updates to fail.
After replacing the installer's freebl3.chk file with the one from the complete.mar it then failed on softokn3.chk. I then replaced the installer's softokn3.chk file with the one from the complete.mar and was able to apply the update.
Fernando, have you been installing using the installer recently? Have you noticed that the failure happens after installing with the installer?
Drivers, though we don't know as of yet where the file modifications are occurring that is breaking software update this should definitely block 1.9.1
There's a RelEng bug on this somewhere. Basically, the .chk files get regenerated when we package. They're checksum files for the DLLs, but they wind up different every time they're generated for some reason.
This is bug 404340.
Email from Fernando, "Just for curiosity my firefox version updated daily keeps the name of Minefield. The version used for test in named Shiretoko but yesterday still I got the update named Minefiels.." It sounds like at some point you may have been running Minefield and installed on top of it with Shiretoko. With nightly trunk builds it is safer to uninstall it before installing a different version. Could you try uninstalling it and then installing a build of Shiretoko?
Sorry I had to go to sleep. I only have one installation going on, Minefield with dayly nightly updates. At a given momento when changing from 3.1axpre to 3.1b1pre Shiretoko showed up and Minefield desappeared though installation continued to be on the same directory. The present Shiretoko installation is in a different directory than Minefield though sharing all the history, bookmarks file and private data which I do not intend o loose as I am not a lab, but a regular user that reports problems. I have done no new installation of Minefield for a long time, just regularly updating via Nightly updates. The Shiretoko installation I did yesterday on you request in the only new one done in my pc which I will uninstall and return to the Minefield that holds all my information
Thanks Fernando All of the update log files point to this being due to the chk files being different. I haven't been seeing this on nightly Shiretoko due to not doing a reinstall from the installer and only updating with app update. Not sure if Minefield trunk behaves differently so I'll try updating it for a couple of days. Not 100% positive about all of the cases but this bug does appear to be due to bug 404340. Specifically, I would expect that after applying a complete update that all future partial updates would contain the freebl3.chk and softokn3.chk files that would properly apply but then again I don't know why these files aren't generated only one time during the build which is why the ones in the complete mar are different from the ones in the installer.
In reading bug 404340 I am believe that bug 313956 will end up being the fix for this bug since it is fine to run shlibsign which generates the chk files but it isn't ok to distribute different chk files, offer a partial update, and expect it to work.
Just checked Minefield using Sunday's Installer which failed the partial update the same as Shiretoko and using an extracted complete mar which succeeded the same as Shiretoko. I'll perform partial updates against both Shiretoko (which has been succeeding for me ever since I can remember) and Minefield (which I haven't checked) without re-installing with the installer for my peace of mind. ;)
(In reply to comment #70) > Just checked Minefield using Sunday's Installer which failed the partial update > the same as Shiretoko and using an extracted complete mar which succeeded the > same as Shiretoko. In case this isn't clear I extracted Sunday's complete mar and then successfully applied a partial update to it which updated it to Monday's build.
Benjamin, since the .chk files can be generated at different stages how about forcing the update for chk files in the partial mar. This would need to be added to make_incremental_updates.py as well but before I do that I'd first like to get your take on this approach.
Comment on attachment 354808 [details] [diff] [review] possible patch [checked in cvs HEAD, hg:m-c & m-1.9.1] I'm ok with the theory. I'm not quite sure the status of all our make-incremental scripts any more, or whether we've replaced this with python yet, so asking ted for an additional review.
Priority: -- → P2
Target Milestone: --- → mozilla1.9.1b3
Comment on attachment 354808 [details] [diff] [review] possible patch [checked in cvs HEAD, hg:m-c & m-1.9.1] I don't know any more than you do, you want to ask bhearsum about that.
Attachment #354808 - Flags: review?(ted.mielczarek) → review?(bhearsum)
Comment on attachment 354808 [details] [diff] [review] possible patch [checked in cvs HEAD, hg:m-c & m-1.9.1] AFAIK we don't use this script anymore. Partials are all done with make_incremental_updates.py for Firefox and Thunderbird. Someone from the community may use it though, may as well patch it?
Attachment #354808 - Flags: review?(bhearsum) → review+
Oh, and to re-iterate what Rob already said - we need to patch make_incremental_updates.py.
Hey Ben, I'm not sure if this covers all of the cases and I'm not sure how to test the python script... could you verify this is correct? Thanks
Attachment #355853 - Flags: review?(bhearsum)
Comment on attachment 355853 [details] [diff] [review] patch - make_incremental_updates.py - rev1 I missed a stray tab before return False in the script and fixed it locally
We still use make_incremental_update.sh for generating partials for _nightly_ updates, so the first patch would need to land on CVS HEAD and the copy at prometheus-vm:/builds/new-mozilla-checkout/mozilla/tools/update-packaging/ updated (and the comment by filename /builds/new-mozilla-checkout/on_tag_UPDATE_PACKAGING_R1 fixed). I'd agree with what Ben said in comment #75 as it applies to _releases_. We could also hardwire the two chk files into force list in each patcher config.
(In reply to comment #79) > We still use make_incremental_update.sh for generating partials for _nightly_ > updates, so the first patch would need to land on CVS HEAD and the copy at > prometheus-vm:/builds/new-mozilla-checkout/mozilla/tools/update-packaging/ > updated (and the comment by filename > /builds/new-mozilla-checkout/on_tag_UPDATE_PACKAGING_R1 fixed). > > I'd agree with what Ben said in comment #75 as it applies to _releases_. We > could also hardwire the two chk files into force list in each patcher config. Nick, I don't have a clue as to the details of what needs to land where, etc. Would you mind taking this bug so everything gets landed / fixed in the right places?
Comment on attachment 355853 [details] [diff] [review] patch - make_incremental_updates.py - rev1 >+def is_chk_file(path): >+ """ Returns True if the file is a chk file""" >+ try: >+ flist = path.split(".") >+ if flist.pop() == 'chk': >+ return True >+ return False >+ This is invalid syntax. Either drop the try: block or catch an exception with 'except'. > > ## TOODO NEED TO ADD HANDLING FOR FORCED UPDATES >- if os.path.getsize(patch_file_abs_path) < os.path.getsize(full_file_abs_path): >+ if os.path.getsize(patch_file_abs_path) < os.path.getsize(full_file_abs_path) and \ >+ is_chk_file(full_file_abs_path): This doesn't seem right. You probably want '... or not is_chk_file(full_file_abs_path)' so chk files end up in the else block and add the full file to the mar. Please update the comment in the else block, too.
Attachment #355853 - Flags: review?(bhearsum) → review-
(In reply to comment #81) > (From update of attachment 355853 [details] [diff] [review]) > >.. > > ## TOODO NEED TO ADD HANDLING FOR FORCED UPDATES > >- if os.path.getsize(patch_file_abs_path) < os.path.getsize(full_file_abs_path): > >+ if os.path.getsize(patch_file_abs_path) < os.path.getsize(full_file_abs_path) and \ > >+ is_chk_file(full_file_abs_path): > > This doesn't seem right. You probably want '... or not > is_chk_file(full_file_abs_path)' so chk files end up in the else block and add > the full file to the mar. Please update the comment in the else block, too. I hardly use python but I would think 'and not' would make chk files end up in the else block.
Attachment #356012 - Flags: review?(bhearsum) → review+
Comment on attachment 356012 [details] [diff] [review] patch - make_incremental_updates.py - rev2 (not landed - see comment #111) Yeah, you're right about that. I got it backwards in my head earlier.
(In reply to comment #79) > We still use make_incremental_update.sh for generating partials for _nightly_ > updates, so the first patch would need to land on CVS HEAD and the copy at > prometheus-vm:/builds/new-mozilla-checkout/mozilla/tools/update-packaging/ > updated (and the comment by filename > /builds/new-mozilla-checkout/on_tag_UPDATE_PACKAGING_R1 fixed). > > I'd agree with what Ben said in comment #75 as it applies to _releases_. We > could also hardwire the two chk files into force list in each patcher config. Nick, this comment gives me pause in regards to checking in. Can you either check this in or comment where and when these should be checked in? Thanks
> Nick, this comment gives me pause in regards to checking in. Can you either > check this in or comment where and when these should be checked in? Thanks I think that was an alternative to this patch. To be honest though, I'm not seeing that make_incremental_updates.py supports forced updates from the patcher config, given this comment: 197 ## TOODO NEED TO ADD HANDLING FOR FORCED UPDATES I'll wait for Nick's comment though...I'm probably forgetting something again.
(In reply to comment #85) > > Nick, this comment gives me pause in regards to checking in. Can you either > > check this in or comment where and when these should be checked in? Thanks > > I think that was an alternative to this patch. To be honest though, I'm not > seeing that make_incremental_updates.py supports forced updates from the > patcher config, given this comment: > 197 ## TOODO NEED TO ADD HANDLING FOR FORCED UPDATES > > I'll wait for Nick's comment though...I'm probably forgetting something again. What I believe the patch to the py script does is add the ability to force updates to chk files but it doesn't add the handling for specifying files to force updates to via a forced_updates param
With today's nightly updates 20090113 there were problems for both minefield and thunderbird/schredder. The updates were downloaded but did not install themselves. In order to install the full updates I had to download them manually from the mozilla web as this time in the check for updates process the full download was not made available. I have the full updates files for minefield including the .mar file, but cannot included them as attachment
With today's nightly updates 20090113 there were problems for both minefield and thunderbird/schredder. The updates were downloaded but did not install themselves. In order to install the full updates I had to download them manually from the mozilla web as this time in the check for updates process the full download was not made available. I have the full updates files for minefield including the .mar file, but cannot included them as attachment I reported bug 473172 with another update problem but similar
Fernando, are you on Windows? I hope its not due to the fix on bug 305039.
In reference to comment 89 yes I am using windows XP SP2
I talked with nthomas on irc and he agreed to take this bug to drive the patches into the repos. Thanks Nick!
Assignee: robert.bugzilla → nthomas
Comment on attachment 354808 [details] [diff] [review] possible patch [checked in cvs HEAD, hg:m-c & m-1.9.1] Checked into CVS HEAD (new rev is 1.13), and updated the copy in prometheus-vm:/builds/nightly-partial-generation/mozilla-checkout/mozilla/tools/update-packaging for the nightly update generation. Note that this change means all platforms have the check files forced, when strictly we only need to on win32. They're small files so this isn't a big deal.
Attachment #354808 - Attachment description: possible patch → possible patch [checked in cvs HEAD]
Nick, since these files also exist in mozilla-central, etc. are you going to also check them in to mozilla-central, etc.?
(In reply to comment #94) I'm heading in that direction.
I downloaded the installer for yesterday's Minefield build, checked for updates, downloaded the partial, and it successfully updated. The following two entries were in the last-update.log which shows two chk files were added (PREPARE ADD) instead of patched (PREPARE PATCH). PREPARE ADD freebl3.chk PREPARE ADD softokn3.chk So far everything is looking good
Above comments also apply to nightly Shiretoko. Thanks Nick!
Marcia, could you also verify that partial updates work now when installing the previous day's nightly and updating? Thanks
Confirming on Win Vista Ultimate, going from the build on the 15th to today's build, the partial applies fine.
Comment on attachment 354808 [details] [diff] [review] possible patch [checked in cvs HEAD, hg:m-c & m-1.9.1] Pushed to hg repos: http://hg.mozilla.org/mozilla-central/rev/359e58e00bf4 http://hg.mozilla.org/releases/mozilla-1.9.1/rev/b48f0e5bb1db
Attachment #354808 - Attachment description: possible patch [checked in cvs HEAD] → possible patch [checked in cvs HEAD, hg:m-c & m-1.9.1]
We have a bit of a messy situation with how we tag patcher for releases, which we don't have time to untangle before 3.0.6/3.1b3. So I'm suggesting we go with this alternative to attachment 356012 [details] [diff] [review] for now.
Attachment #357731 - Flags: review?(bhearsum)
Attachment #357731 - Flags: review?(bhearsum) → review+
Comment on attachment 357731 [details] [diff] [review] Modify patcher configs for 2.0/3.0/3.1 releases [checked in] This only needs to land in one place: mozilla/tools/patcher-configs/moz18-branch-patcher2.cfg 1.26 mozilla/tools/patcher-configs/moz19-branch-patcher2.cfg 1.45 mozilla/tools/patcher-configs/moz191-branch-patcher2.cfg 1.15
Attachment #357731 - Attachment description: Modify patcher configs for 2.0/3.0/3.1 releases → Modify patcher configs for 2.0/3.0/3.1 releases [checked in]
From the update verify run for Fx3.0.6 build1, in particular the update log for the partial update: EXECUTE ADD freebl3.chk ... EXECUTE ADD softokn3.chk
(In reply to comment #96) > entries were in the last-update.log which shows two chk files were added > (PREPARE ADD) instead of patched (PREPARE PATCH). > > PREPARE ADD freebl3.chk > PREPARE ADD softokn3.chk Rob, I've compared a fresh 3.0.6 installation and an partial updated 3.0.5 version. For these versions the above files are different. Could this raise problems? Btw the update was successfully...
There shouldn't be. The chk files can be different between the update and the installer per bug 404340. You should have the PREPARE ADD statements for freebl3.chk and softokn3.chk in the last-update.log and the update must be a partial update to verify this.
Ok, just wanted to make sure everything is fine for the update. Thanks Rob.
Nick, is there anything left that needs to be done for this bug?
We've got both nightly and release cases covered. Assorted tagging operations described in bug 475309 comment #4, although not really relevant to this. Removing dep on bug 313956 as we've worked around (again).
Status: NEW → RESOLVED
Closed: 14 years ago
No longer depends on: 313956
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Nick, it doesn't appear that the patch for make_incremental_updates.py has landed on either mozilla-central or mozilla-1.9.1. Are you going to check it in?
Talked with Nick and the explicit force instructions in the patcher configs makes the changes to make_incremental_updates.py unnecessary as far as this bug is concerned so marking fixed1.9.1.
This came up again for releases with packaging another .chk file, see bug 522943
You need to log in before you can comment on or make changes to this bug.