39721 2010-05-26 03:50:19 -0700 [chromium] Upstream layout tests expectations for Geolocation. 2010-06-10 07:17:05 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) All All RESOLVED FIXED P2 Normal --- 0 bulach webkit-unassigned bulach commit-queue dglazkov dpranke jorlow victorw oldest_to_newest 230649 0 bulach 2010-05-26 03:50:19 -0700 Geolocation is now supported on both DumpRenderTree and test_shell, need to upstream the test expectations. 230703 1 57093 bulach 2010-05-26 07:30:24 -0700 Created attachment 57093 Patch 231645 2 57093 jorlow 2010-05-28 05:14:11 -0700 Comment on attachment 57093 Patch LayoutTests/platform/chromium/test_expectations.txt:709 + BUG11246 DEFER SKIP : fast/dom/Geolocation/callback-exception.html = TEXT Just rebaseline it in this patch. Use the rebaseline tool. 231670 3 57324 bulach 2010-05-28 06:40:07 -0700 Created attachment 57324 Patch 231672 4 bulach 2010-05-28 06:41:11 -0700 (In reply to comment #2) > (From update of attachment 57093 [details]) > LayoutTests/platform/chromium/test_expectations.txt:709 > + BUG11246 DEFER SKIP : fast/dom/Geolocation/callback-exception.html = TEXT > Just rebaseline it in this patch. Use the rebaseline tool. duh, of course! rebaselined. another look please? 231675 5 57324 jorlow 2010-05-28 06:49:28 -0700 Comment on attachment 57324 Patch LayoutTests/platform/chromium/fast/dom/Geolocation/callback-exception-expected.txt:1 + CONSOLE MESSAGE: line 22: Uncaught Error: Exception in success callback This worries me some. Does it show up with JSC? I feel like maybe you could catch the exception in the test. LayoutTests/ChangeLog:9 + * platform/chromium/fast/dom/Geolocation/callback-exception-expected.txt: Added. Does this work? I believe you have to add it to -win and -mac. Dimitri has confirmed this in the past. But, now that I think about it, maybe that's silly? Especially if this works. (Are you sure it does?) 231676 6 jorlow 2010-05-28 06:49:47 -0700 Dimitri, can you take a quick look? 231678 7 jorlow 2010-05-28 06:52:25 -0700 (In reply to comment #5) > (From update of attachment 57324 [details]) > LayoutTests/platform/chromium/fast/dom/Geolocation/callback-exception-expected.txt:1 > + CONSOLE MESSAGE: line 22: Uncaught Error: Exception in success callback > This worries me some. Does it show up with JSC? I feel like maybe you could catch the exception in the test. Nm. I'm an idiot. :-) 231681 8 bulach 2010-05-28 06:55:07 -0700 (In reply to comment #7) > (In reply to comment #5) > > (From update of attachment 57324 [details] [details]) > > LayoutTests/platform/chromium/fast/dom/Geolocation/callback-exception-expected.txt:1 > > + CONSOLE MESSAGE: line 22: Uncaught Error: Exception in success callback > > This worries me some. Does it show up with JSC? I feel like maybe you could catch the exception in the test. > > Nm. I'm an idiot. :-) so the difference between V8 and JSC is the "Uncaught " word.. I could certainly change the test, but that would be a separate change.. > > LayoutTests/ChangeLog:9 > + * platform/chromium/fast/dom/Geolocation/callback-exception-expected.txt: Added. > Does this work? I believe you have to add it to -win and -mac. Dimitri has confirmed this in the past. But, now that I think about it, maybe that's silly? Especially if this works. (Are you sure it does?) "works for me!" :) dimitri, could you please confirm it'll work everywhere? 231684 9 dglazkov 2010-05-28 06:57:45 -0700 (In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #5) > > > (From update of attachment 57324 [details] [details] [details]) > > > LayoutTests/platform/chromium/fast/dom/Geolocation/callback-exception-expected.txt:1 > > > + CONSOLE MESSAGE: line 22: Uncaught Error: Exception in success callback > > > This worries me some. Does it show up with JSC? I feel like maybe you could catch the exception in the test. > > > > Nm. I'm an idiot. :-) > > so the difference between V8 and JSC is the "Uncaught " word.. I could certainly change the test, but that would be a separate change.. > > > > > LayoutTests/ChangeLog:9 > > + * platform/chromium/fast/dom/Geolocation/callback-exception-expected.txt: Added. > > Does this work? I believe you have to add it to -win and -mac. Dimitri has confirmed this in the past. But, now that I think about it, maybe that's silly? Especially if this works. (Are you sure it does?) > > "works for me!" :) > dimitri, could you please confirm it'll work everywhere? Not that I am a aware. I think you still need to put 'em in -win and -mac. Ask dpranke. He knows. 231688 10 jorlow 2010-05-28 07:01:46 -0700 If there's a good reason platform/chromium can't be in the search path for Linux, Win, and Mac, then we need to delete everything from that directory. (IIRC, there are a bunch of other expected results in there!) If there's not, we should probably change the re-baselining tool, send a FYI email to chromium-dev, and optionally create a script to move all the duplicate files in -mac and -win to the shared folder. I hope the answer is the latter. :-) 231919 11 dpranke 2010-05-28 13:57:40 -0700 (In reply to comment #10) > If there's a good reason platform/chromium can't be in the search path for Linux, Win, and Mac, then we need to delete everything from that directory. (IIRC, there are a bunch of other expected results in there!) > > If there's not, we should probably change the re-baselining tool, send a FYI email to chromium-dev, and optionally create a script to move all the duplicate files in -mac and -win to the shared folder. > > I hope the answer is the latter. :-) platform/chromium is in the search path on all three platforms. It's fine to put files that are the same on all three Chromium ports but different from upstream there. I thought the rebaselining tool automatically dealt with this, but I could be wrong. Copying victorw for thoughts on this ... (watch me pass the buck!) 231948 12 victorw 2010-05-28 14:37:45 -0700 Personally, I prefer not having baselines in platform/chromium. For now, since the fallback paths are chromium-linux->chromium-win->chromium-mac, if baselines for all three ports are same, then the baseline would be in chromium-mac and chromium-mac is serving the same purpose as platform/chromium. I think having baselines in platfomr/chromium may add extra maintenance work. For example, if a baseline for all ports are same but latter linux has a different baseline, then in addition to add new linux baseline, we also need to remove baseline from platform/chromium and add it to platform/chromium-mac. It makes rebaseline tool little harder when it tries to rebaseline for one platform and the tool needs to figure out where to add new baseline. I agree these issues could be resolved by making rebaseline smarter, but don't feel it worth the effort to do that, at least for now. I prefer keeping it simple and just use the existing path, thoughts? (In reply to comment #11) > (In reply to comment #10) > > If there's a good reason platform/chromium can't be in the search path for Linux, Win, and Mac, then we need to delete everything from that directory. (IIRC, there are a bunch of other expected results in there!) > > > > If there's not, we should probably change the re-baselining tool, send a FYI email to chromium-dev, and optionally create a script to move all the duplicate files in -mac and -win to the shared folder. > > > > I hope the answer is the latter. :-) > > platform/chromium is in the search path on all three platforms. It's fine to put files that are the same on all three Chromium ports but different from upstream there. > > I thought the rebaselining tool automatically dealt with this, but I could be wrong. > > Copying victorw for thoughts on this ... (watch me pass the buck!) 231953 13 dpranke 2010-05-28 14:40:44 -0700 (In reply to comment #12) > Personally, I prefer not having baselines in platform/chromium. For now, since the fallback paths are chromium-linux->chromium-win->chromium-mac, if baselines for all three ports are same, then the baseline would be in chromium-mac and chromium-mac is serving the same purpose as platform/chromium. Except that neither chromium-linux nor chromium-win fall back to chromium-mac. 235220 14 bulach 2010-06-08 05:35:18 -0700 (In reply to comment #13) > (In reply to comment #12) > > Personally, I prefer not having baselines in platform/chromium. For now, since the fallback paths are chromium-linux->chromium-win->chromium-mac, if baselines for all three ports are same, then the baseline would be in chromium-mac and chromium-mac is serving the same purpose as platform/chromium. > > Except that neither chromium-linux nor chromium-win fall back to chromium-mac. thanks everyone for the feedback! it seems that platform/chromium is indeed the fallback for all platforms? should we go ahead with this patch or is it better to duplicate it and add to chromium-win and chromium-mac? 235221 15 jorlow 2010-06-08 05:37:55 -0700 Unless there's a good reason to separate win/mac, I think we should go forward with this patch, change the default behavior of the rebaselining tool, and file a bug to unify all the tests which have identical mac/win baselines. 235271 16 victorw 2010-06-08 09:04:22 -0700 (In reply to comment #15) > Unless there's a good reason to separate win/mac, I think we should go forward with this patch, change the default behavior of the rebaselining tool, and file a bug to unify all the tests which have identical mac/win baselines. I don't think we should put baselines in platform/chromium. We already have a baseline location for each platform and fallback logic works well through platform-linux->platform->win->platform-mac. I don't see much benefit if we add additional layer to this fallback path, but does see there is maintenance cost (either through rebaseline tool or manually update baselines) introduced by this extra location. Like I said, if we have this extra layer and baselines for all three platforms are same, the baseline is added to platform/chromium, then if the baseline for any platform changes, not only you need to add/update the baseline for that location, you may also need to update the other platforms and remove the file from platform/chromium. I don't mean we could not do this in rebaseline tool or manually rebaselining, but think this makes our rebaseline process more complicated and the benefit by adding this extra layer is not much. 235277 17 jorlow 2010-06-08 09:18:31 -0700 (In reply to comment #16) > (In reply to comment #15) > > Unless there's a good reason to separate win/mac, I think we should go forward with this patch, change the default behavior of the rebaselining tool, and file a bug to unify all the tests which have identical mac/win baselines. > > I don't think we should put baselines in platform/chromium. We already have a baseline location for each platform and fallback logic works well through platform-linux->platform->win->platform-mac. I don't see much benefit if we add additional layer to this fallback path, but does see there is maintenance cost (either through rebaseline tool or manually update baselines) introduced by this extra location. Like I said, if we have this extra layer and baselines for all three platforms are same, the baseline is added to platform/chromium, then if the baseline for any platform changes, not only you need to add/update the baseline for that location, you may also need to update the other platforms and remove the file from platform/chromium. I don't mean we could not do this in rebaseline tool or manually rebaselining, but think this makes our rebaseline process more complicated and the benefit by adding this extra layer is not much. By that logic, we should not have linux fall back on the win baselines for the same reason, right? Also, if that's the case, we need to move all the baselines out of platform/chromium to avoid further confusion. 235283 18 victorw 2010-06-08 09:36:32 -0700 (In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #15) > > > Unless there's a good reason to separate win/mac, I think we should go forward with this patch, change the default behavior of the rebaselining tool, and file a bug to unify all the tests which have identical mac/win baselines. > > > > I don't think we should put baselines in platform/chromium. We already have a baseline location for each platform and fallback logic works well through platform-linux->platform->win->platform-mac. I don't see much benefit if we add additional layer to this fallback path, but does see there is maintenance cost (either through rebaseline tool or manually update baselines) introduced by this extra location. Like I said, if we have this extra layer and baselines for all three platforms are same, the baseline is added to platform/chromium, then if the baseline for any platform changes, not only you need to add/update the baseline for that location, you may also need to update the other platforms and remove the file from platform/chromium. I don't mean we could not do this in rebaseline tool or manually rebaselining, but think this makes our rebaseline process more complicated and the benefit by adding this extra layer is not much. > > By that logic, we should not have linux fall back on the win baselines for the same reason, right? Jeremy, maybe I didn't make my comments clearer. I do think we should have linux fallback to win (lots of baselines for linux and win are same). The point I am trying to make here is each baseline location is associated with one platform (mac, win7, vista, winxp, linux etc). The new location platform/chromium is not associate with one platform, it is for hosting files if baselines for all platforms are same. This case has already been handled now by simply adding the baseline to platform-mac. Adding this new location will make the process MORE complicated and seems to me it is not necessary. > > Also, if that's the case, we need to move all the baselines out of platform/chromium to avoid further confusion. Yes, I agree. 235286 19 victorw 2010-06-08 09:50:01 -0700 (In reply to comment #18) > (In reply to comment #17) > > (In reply to comment #16) > > > (In reply to comment #15) > > > > Unless there's a good reason to separate win/mac, I think we should go forward with this patch, change the default behavior of the rebaselining tool, and file a bug to unify all the tests which have identical mac/win baselines. > > > > > > I don't think we should put baselines in platform/chromium. We already have a baseline location for each platform and fallback logic works well through platform-linux->platform->win->platform-mac. I don't see much benefit if we add additional layer to this fallback path, but does see there is maintenance cost (either through rebaseline tool or manually update baselines) introduced by this extra location. Like I said, if we have this extra layer and baselines for all three platforms are same, the baseline is added to platform/chromium, then if the baseline for any platform changes, not only you need to add/update the baseline for that location, you may also need to update the other platforms and remove the file from platform/chromium. I don't mean we could not do this in rebaseline tool or manually rebaselining, but think this makes our rebaseline process more complicated and the benefit by adding this extra layer is not much. > > > > By that logic, we should not have linux fall back on the win baselines for the same reason, right? > Jeremy, maybe I didn't make my comments clearer. I do think we should have linux fallback to win (lots of baselines for linux and win are same). The point I am trying to make here is each baseline location is associated with one platform (mac, win7, vista, winxp, linux etc). The new location platform/chromium is not associate with one platform, it is for hosting files if baselines for all platforms are same. This case has already been handled now by simply adding the baseline to platform-mac. Adding this new location will make the process MORE complicated and seems to me it is not necessary. > > > > > Also, if that's the case, we need to move all the baselines out of platform/chromium to avoid further confusion. > Yes, I agree. I think it is more logically clear and simple if baseline for each platform are added to it own location and no dupe check if there is no storage concern, but lots of baselines are same so we need the fallback logic to save storage. Adding platform/chromium does not save us any space but does make the process more complicated. 235367 20 dpranke 2010-06-08 11:03:37 -0700 (In reply to comment #16) > (In reply to comment #15) > > Unless there's a good reason to separate win/mac, I think we should go forward with this patch, change the default behavior of the rebaselining tool, and file a bug to unify all the tests which have identical mac/win baselines. > > I don't think we should put baselines in platform/chromium. We already have a baseline location for each platform and fallback logic works well through platform-linux->platform->win->platform-mac. To repeat what I said in comment #13, neither platform/chromium-win nor platform/chromium-linux falls back to chromium-mac, which means there is no place we can put a single file that has the same expectation on all chromium ports but is different from upstream webkit. I think it makes sense to have such a place, because that is easy to understand for people writing new tests, and that way people don't get confused if we tell them to put a result in chromium-mac even if it is the same on all three platforms. In addition, we know that it is something of a hassle to rebaseline all three platforms (although the rebaselining tool does make it easier than it would be by hand), and it does introduce a source of error for both committers and reviewers. So, if I put a file in platform/chromium, and the mac baseline changes, then I don't have to remove the file from platform/chromium (linux and win will still pick it up). This is no different from how the rest of the fallback code works. Things would be a little clearer if we removed the platform/mac (not chromium-mac) baseline, so that it was clear that the win (and linux) platforms never depended on mac-specific *anything*. I think most of the mac-specific baselines picked up by the win bots are for mac-specific tests, so arguably we could stop running those as well. However, you're right that storage isn't a concern. 235396 21 victorw 2010-06-08 11:29:57 -0700 (In reply to comment #20) > (In reply to comment #16) > > (In reply to comment #15) > > > Unless there's a good reason to separate win/mac, I think we should go forward with this patch, change the default behavior of the rebaselining tool, and file a bug to unify all the tests which have identical mac/win baselines. > > > > I don't think we should put baselines in platform/chromium. We already have a baseline location for each platform and fallback logic works well through platform-linux->platform->win->platform-mac. > > To repeat what I said in comment #13, neither platform/chromium-win nor platform/chromium-linux falls back to chromium-mac, which means there is no place we can put a single file that has the same expectation on all chromium ports but is different from upstream webkit. > > I think it makes sense to have such a place, because that is easy to understand for people writing new tests, and that way people don't get confused if we tell them to put a result in chromium-mac even if it is the same on all three platforms. > > In addition, we know that it is something of a hassle to rebaseline all three platforms (although the rebaselining tool does make it easier than it would be by hand), and it does introduce a source of error for both committers and reviewers. > > So, if I put a file in platform/chromium, and the mac baseline changes, then I don't have to remove the file from platform/chromium (linux and win will still pick it up). This is no different from how the rest of the fallback code works. > > Things would be a little clearer if we removed the platform/mac (not chromium-mac) baseline, so that it was clear that the win (and linux) platforms never depended on mac-specific *anything*. I think most of the mac-specific baselines picked up by the win bots are for mac-specific tests, so arguably we could stop running those as well. > > However, you're right that storage isn't a concern. I see. Somehow, I thought the chromium-win falls back to chromium-mac as we have in downstream code. This is why I thought the new platform/chromium is not that useful. If this is not the case, I agree adding platform/chromium to fallback path is fine. Since platform/chromium is already in search path and chromium-win or chromium-linux does not fall back to chromium-mac, the existing rebaseline tool should work as you said in your comments. Sorry for the misunderstanding. 235726 22 bulach 2010-06-09 03:07:16 -0700 (In reply to comment #21) > (In reply to comment #20) > > (In reply to comment #16) > > > (In reply to comment #15) > > > > Unless there's a good reason to separate win/mac, I think we should go forward with this patch, change the default behavior of the rebaselining tool, and file a bug to unify all the tests which have identical mac/win baselines. > > > > > > I don't think we should put baselines in platform/chromium. We already have a baseline location for each platform and fallback logic works well through platform-linux->platform->win->platform-mac. > > > > To repeat what I said in comment #13, neither platform/chromium-win nor platform/chromium-linux falls back to chromium-mac, which means there is no place we can put a single file that has the same expectation on all chromium ports but is different from upstream webkit. > > > > I think it makes sense to have such a place, because that is easy to understand for people writing new tests, and that way people don't get confused if we tell them to put a result in chromium-mac even if it is the same on all three platforms. > > > > In addition, we know that it is something of a hassle to rebaseline all three platforms (although the rebaselining tool does make it easier than it would be by hand), and it does introduce a source of error for both committers and reviewers. > > > > So, if I put a file in platform/chromium, and the mac baseline changes, then I don't have to remove the file from platform/chromium (linux and win will still pick it up). This is no different from how the rest of the fallback code works. > > > > Things would be a little clearer if we removed the platform/mac (not chromium-mac) baseline, so that it was clear that the win (and linux) platforms never depended on mac-specific *anything*. I think most of the mac-specific baselines picked up by the win bots are for mac-specific tests, so arguably we could stop running those as well. > > > > However, you're right that storage isn't a concern. > > I see. Somehow, I thought the chromium-win falls back to chromium-mac as we have in downstream code. This is why I thought the new platform/chromium is not that useful. If this is not the case, I agree adding platform/chromium to fallback path is fine. > > Since platform/chromium is already in search path and chromium-win or chromium-linux does not fall back to chromium-mac, the existing rebaseline tool should work as you said in your comments. > > Sorry for the misunderstanding. thanks all for the clarifications! so should we go with this patch as is then?! :) 235729 23 57324 jorlow 2010-06-09 03:10:28 -0700 Comment on attachment 57324 Patch r=me 236354 24 57324 commit-queue 2010-06-10 07:16:58 -0700 Comment on attachment 57324 Patch Clearing flags on attachment: 57324 Committed r60956: <http://trac.webkit.org/changeset/60956> 236355 25 commit-queue 2010-06-10 07:17:05 -0700 All reviewed patches have been landed. Closing bug. 57093 2010-05-26 07:30:24 -0700 2010-05-28 06:40:01 -0700 Patch bug-39721-20100526153022.patch text/plain 1518 bulach ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv ZwppbmRleCA1MDk3ODdjMDc4NmQ4MmIxMzQ5ZGQ5NWEwMTVkNDQzNjIzNmFiNTVhLi4xNGEyYWIy YWU2ZjkyNWZjNjg4Y2U2ZmQ0NTgwZGJiMTNkMGU4MGViIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0 cy9DaGFuZ2VMb2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTIgQEAK KzIwMTAtMDUtMjYgIE1hcmN1cyBCdWxhY2ggIDxidWxhY2hAZ29vZ2xlLmNvbT4KKworICAgICAg ICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBbY2hyb21pdW1dIFVwc3Ry ZWFtIGxheW91dCB0ZXN0cyBleHBlY3RhdGlvbnMgZm9yIEdlb2xvY2F0aW9uLgorICAgICAgICBo dHRwczovL2J1Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9Mzk3MjEKKworICAgICAgICAq IHBsYXRmb3JtL2Nocm9taXVtL3Rlc3RfZXhwZWN0YXRpb25zLnR4dDoKKwogMjAxMC0wNS0yNiAg QWxleGFuZGVyIFBhdmxvdiAgPGFwYXZsb3ZAY2hyb21pdW0ub3JnPgogCiAgICAgICAgIFJldmll d2VkIGJ5IFBhdmVsIEZlbGRtYW4uCmRpZmYgLS1naXQgYS9MYXlvdXRUZXN0cy9wbGF0Zm9ybS9j aHJvbWl1bS90ZXN0X2V4cGVjdGF0aW9ucy50eHQgYi9MYXlvdXRUZXN0cy9wbGF0Zm9ybS9jaHJv bWl1bS90ZXN0X2V4cGVjdGF0aW9ucy50eHQKaW5kZXggYzQwYmIzMTVkMDZhZmZhMTM5NmM4YjBl M2ZmMGY5MmYzMDY2MmVlOS4uMDYwMzY0OGRmYWM0NGM2MjRiMjM1MGIyZjgzZjVjYTEwNTdiN2Zj MiAxMDA2NDQKLS0tIGEvTGF5b3V0VGVzdHMvcGxhdGZvcm0vY2hyb21pdW0vdGVzdF9leHBlY3Rh dGlvbnMudHh0CisrKyBiL0xheW91dFRlc3RzL3BsYXRmb3JtL2Nocm9taXVtL3Rlc3RfZXhwZWN0 YXRpb25zLnR4dApAQCAtNzA0LDkgKzcwNCw5IEBAIEJVRzI3Njk3IFNLSVAgOiBzdG9yYWdlL2hh c2gtY2hhbmdlLXdpdGgteGhyLmh0bWwgPSBQQVNTCiAvLyBXZSBkbyBub3QgdXNlIFNhZmFyaSdz IHByaXZhdGUgYnJvd3NpbmcKIFdPTlRGSVggU0tJUCA6IHN0b3JhZ2UvcHJpdmF0ZS1icm93c2lu Zy1yZWFkb25seS5odG1sID0gUEFTUwogCi0vLyBJbXBsZW1lbnQgSFRNTDUgR2VvbG9jYXRpb24g QVBJLgotQlVHMTEyNDYgREVGRVIgU0tJUCA6IGZhc3QvZG9tL0dlb2xvY2F0aW9uID0gRkFJTAot QlVHMTEyNDYgREVGRVIgU0tJUCA6IGZhc3QvZG9tL1dpbmRvdy93aW5kb3ctcHJvcGVydGllcy1n ZW9sb2NhdGlvbi5odG1sID0gVEVYVAorLy8gSFRNTDUgR2VvbG9jYXRpb24gQVBJLgorLy8gTWlz bWF0Y2ggYmV0d2VlbiBWOCBhbmQgSlNDIG1lc3NhZ2UuCitCVUcxMTI0NiBERUZFUiBTS0lQIDog ZmFzdC9kb20vR2VvbG9jYXRpb24vY2FsbGJhY2stZXhjZXB0aW9uLmh0bWwgPSBURVhUCiAKIC8v IEhUTUw1IGRhdGFsaXN0IGVsZW1lbnQuIFdlIGRvbid0IGVuYWJsZSBpdCBiZWNhdXNlIFdlYktp dCBpbXBsZW1lbnRhdGlvbgogLy8gaXMgaW5jb21wbGV0ZS4K 57324 2010-05-28 06:40:07 -0700 2010-06-10 07:16:58 -0700 Patch bug-39721-20100528144005.patch text/plain 2554 bulach ZGlmZiAtLWdpdCBhL0xheW91dFRlc3RzL0NoYW5nZUxvZyBiL0xheW91dFRlc3RzL0NoYW5nZUxv ZwppbmRleCA0NDRkNzQ4NjA2ZDMwZTQ5YTk5YjEwNzMzMzgyOGRhNTgxYWRiZGVhLi44ZDE3ZGJm MmVlMTRjNDAwNDQwMzkwYThlMTA1MTc4OGMxNWIyN2M3IDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0 cy9DaGFuZ2VMb2cKKysrIGIvTGF5b3V0VGVzdHMvQ2hhbmdlTG9nCkBAIC0xLDMgKzEsMTQgQEAK KzIwMTAtMDUtMjggIE1hcmN1cyBCdWxhY2ggIDxidWxhY2hAZ29vZ2xlLmNvbT4KKworICAgICAg ICBSZXZpZXdlZCBieSBOT0JPRFkgKE9PUFMhKS4KKworICAgICAgICBbY2hyb21pdW1dIFVwc3Ry ZWFtIGxheW91dCB0ZXN0cyBleHBlY3RhdGlvbnMgZm9yIEdlb2xvY2F0aW9uLgorICAgICAgICBS ZWJhc2VsaW5lIGZhc3QvZG9tL0dlb2xvY2F0aW9uL2NhbGxiYWNrLWV4Y2VwdGlvbi1leHBlY3Rl ZC5odG1sIGR1ZSB0byBKU0MgeCBWOCBtZXNzYWdlcy4KKyAgICAgICAgaHR0cHM6Ly9idWdzLndl YmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTM5NzIxCisKKyAgICAgICAgKiBwbGF0Zm9ybS9jaHJv bWl1bS9mYXN0L2RvbS9HZW9sb2NhdGlvbi9jYWxsYmFjay1leGNlcHRpb24tZXhwZWN0ZWQudHh0 OiBBZGRlZC4KKyAgICAgICAgKiBwbGF0Zm9ybS9jaHJvbWl1bS90ZXN0X2V4cGVjdGF0aW9ucy50 eHQ6CisKIDIwMTAtMDUtMjcgIE1PUklUQSBIYWppbWUgIDxtb3JyaXRhQGdvb2dsZS5jb20+CiAK ICAgICAgICAgUmV2aWV3ZWQgYnkgT2phbiBWYWZhaS4KZGlmZiAtLWdpdCBhL0xheW91dFRlc3Rz L3BsYXRmb3JtL2Nocm9taXVtL2Zhc3QvZG9tL0dlb2xvY2F0aW9uL2NhbGxiYWNrLWV4Y2VwdGlv bi1leHBlY3RlZC50eHQgYi9MYXlvdXRUZXN0cy9wbGF0Zm9ybS9jaHJvbWl1bS9mYXN0L2RvbS9H ZW9sb2NhdGlvbi9jYWxsYmFjay1leGNlcHRpb24tZXhwZWN0ZWQudHh0Cm5ldyBmaWxlIG1vZGUg MTAwNjQ0CmluZGV4IDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAuLmVl Y2UxNGZmMjg0Mzg4ZjU2NDlhOWMwZGY0OWU4MjhhNTE5OWM2YmIKLS0tIC9kZXYvbnVsbAorKysg Yi9MYXlvdXRUZXN0cy9wbGF0Zm9ybS9jaHJvbWl1bS9mYXN0L2RvbS9HZW9sb2NhdGlvbi9jYWxs YmFjay1leGNlcHRpb24tZXhwZWN0ZWQudHh0CkBAIC0wLDAgKzEsMTMgQEAKK0NPTlNPTEUgTUVT U0FHRTogbGluZSAyMjogVW5jYXVnaHQgRXJyb3I6IEV4Y2VwdGlvbiBpbiBzdWNjZXNzIGNhbGxi YWNrCitUZXN0cyB0aGF0IHdoZW4gYW4gZXhjZXB0aW9uIGlzIHRocm93biBpbiB0aGUgc3VjY2Vz cyBjYWxsYmFjaywgdGhlIGVycm9yIGNhbGxiYWNrIGlzIG5vdCBpbnZva2VkLiBOb3RlIHRoYXQg dGhpcyB0ZXN0IHRocm93cyBhbiBleGNlcHRpb24gd2hpY2ggaXMgbm90IGNhdWdodC4KKworT24g c3VjY2VzcywgeW91IHdpbGwgc2VlIGEgc2VyaWVzIG9mICJQQVNTIiBtZXNzYWdlcywgZm9sbG93 ZWQgYnkgIlRFU1QgQ09NUExFVEUiLgorCisKK1BBU1MgcG9zaXRpb24uY29vcmRzLmxhdGl0dWRl IGlzIG1vY2tMYXRpdHVkZQorUEFTUyBwb3NpdGlvbi5jb29yZHMubG9uZ2l0dWRlIGlzIG1vY2tM b25naXR1ZGUKK1BBU1MgcG9zaXRpb24uY29vcmRzLmFjY3VyYWN5IGlzIG1vY2tBY2N1cmFjeQor UEFTUyBzdWNjZXNzZnVsbHlQYXJzZWQgaXMgdHJ1ZQorCitURVNUIENPTVBMRVRFCisKZGlmZiAt LWdpdCBhL0xheW91dFRlc3RzL3BsYXRmb3JtL2Nocm9taXVtL3Rlc3RfZXhwZWN0YXRpb25zLnR4 dCBiL0xheW91dFRlc3RzL3BsYXRmb3JtL2Nocm9taXVtL3Rlc3RfZXhwZWN0YXRpb25zLnR4dApp bmRleCA5MmJhODY3M2U5MDE0OWY2MzEzMjBiYzVhZmMzM2QwN2FmNmVhYzcwLi41MzZiOGVkMjk4 Y2Q3OTZmYzdiMzk1ZDFjMmUzZGEyYjY0NjczMWFiIDEwMDY0NAotLS0gYS9MYXlvdXRUZXN0cy9w bGF0Zm9ybS9jaHJvbWl1bS90ZXN0X2V4cGVjdGF0aW9ucy50eHQKKysrIGIvTGF5b3V0VGVzdHMv cGxhdGZvcm0vY2hyb21pdW0vdGVzdF9leHBlY3RhdGlvbnMudHh0CkBAIC03MDQsMTAgKzcwNCw2 IEBAIEJVRzI3Njk3IFNLSVAgOiBzdG9yYWdlL2hhc2gtY2hhbmdlLXdpdGgteGhyLmh0bWwgPSBQ QVNTCiAvLyBXZSBkbyBub3QgdXNlIFNhZmFyaSdzIHByaXZhdGUgYnJvd3NpbmcKIFdPTlRGSVgg U0tJUCA6IHN0b3JhZ2UvcHJpdmF0ZS1icm93c2luZy1yZWFkb25seS5odG1sID0gUEFTUwogCi0v LyBJbXBsZW1lbnQgSFRNTDUgR2VvbG9jYXRpb24gQVBJLgotQlVHMTEyNDYgREVGRVIgU0tJUCA6 IGZhc3QvZG9tL0dlb2xvY2F0aW9uID0gRkFJTAotQlVHMTEyNDYgREVGRVIgU0tJUCA6IGZhc3Qv ZG9tL1dpbmRvdy93aW5kb3ctcHJvcGVydGllcy1nZW9sb2NhdGlvbi5odG1sID0gVEVYVAotCiAv LyBIVE1MNSBkYXRhbGlzdCBlbGVtZW50LiBXZSBkb24ndCBlbmFibGUgaXQgYmVjYXVzZSBXZWJL aXQgaW1wbGVtZW50YXRpb24KIC8vIGlzIGluY29tcGxldGUuCiBCVUcyMDIyNiBERUZFUiA6IGZh c3QvZm9ybXMvZGF0YWxpc3Qtbm9ub3B0aW9uLWNoaWxkLmh0bWwgPSBURVhUCg==