214957 2020-07-29 20:58:42 -0700 Replace 'http://svn.webkit.org' with 'https://svn.webkit.org' in webkitpy scripts 2021-01-07 08:50:58 -0800 1 1 1 Unclassified WebKit Tools / Tests WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED InRadar P2 Normal --- 1 fujii fujii annulen ap clopez darin dbates emilio ews-watchlist glenn jbedard kallisti5 rniwa svillar webkit-bug-importer oldest_to_newest 1676300 0 fujii 2020-07-29 20:58:42 -0700 Replace 'http://svn.webkit.org' with 'https://svn.webkit.org' in webkitpy scripts There is a problem I found * "webkit-patch land" asks username and passoword everytime because SVNRepository.has_authorization_for_realm fails to find ream string. 1676302 1 405544 fujii 2020-07-29 21:21:39 -0700 Created attachment 405544 Patch 1676310 2 405544 dbates 2020-07-29 22:28:32 -0700 Comment on attachment 405544 Patch Patch looks good. 1676321 3 fujii 2020-07-29 23:58:32 -0700 Committed r265077: <https://trac.webkit.org/changeset/265077> 1676322 4 webkit-bug-importer 2020-07-29 23:59:20 -0700 <rdar://problem/66313904> 1681654 5 svillar 2020-08-20 02:01:51 -0700 It stills asks for username/password to me everytime I try to land a patch. 1681692 6 ap 2020-08-20 08:39:24 -0700 Could you please file a new bug? The patch here was landed and not reverted, there is no evidence that the issue is related in any way other than the symptom. 1698422 7 clopez 2020-10-15 18:46:50 -0700 This patch caused me a few headaches. It broke webkit-patch land for me because I had configured the svn server of the git repository (git-svn) to be http://svn.webkit.org (not https). I did the setup some years ago when https was not an option. So the config I had in ~/subversion is for http://svn.webkit.org and not for https://svn.webkit.org, therefore after this patch SVNRepository.has_authorization_for_realm failed for me causing webkit-patch to exit with a cryptic error: COMMIT FAILED: Traceback (most recent call last): File "Tools/Scripts/webkit-patch", line 80, in <module> main() File "Tools/Scripts/webkit-patch", line 75, in main WebKitPatch(os.path.abspath(__file__)).main() File "/home/clopez/webkit/webkit/Tools/Scripts/webkitpy/tool/multicommandtool.py", line 305, in main result = command.check_arguments_and_execute(options, args, self) File "/home/clopez/webkit/webkit/Tools/Scripts/webkitpy/tool/multicommandtool.py", line 123, in check_arguments_and_execute return self.execute(options, args, tool) or 0 File "/home/clopez/webkit/webkit/Tools/Scripts/webkitpy/tool/commands/abstractsequencedcommand.py", line 55, in execute self._sequence.run_and_handle_errors(tool, options, state) File "/home/clopez/webkit/webkit/Tools/Scripts/webkitpy/tool/commands/stepsequence.py", line 73, in run_and_handle_errors self._run(tool, options, state) File "/home/clopez/webkit/webkit/Tools/Scripts/webkitpy/tool/commands/stepsequence.py", line 67, in _run step(tool, options).run(state) File "/home/clopez/webkit/webkit/Tools/Scripts/webkitpy/tool/steps/commit.py", line 89, in run svn_revision = scm.svn_revision_from_commit_text(commit_text) File "/home/clopez/webkit/webkit/Tools/Scripts/webkitpy/common/checkout/scm/scm.py", line 107, in svn_revision_from_commit_text return match.group('svn_revision') AttributeError: 'NoneType' object has no attribute 'group' I tried (hard) to re-configure my setup to use https://svn.webkit.org but there is no way git-svn likes this. I even tried to purge all of my .git/svn* data and resync everything but it doesn't work. I suspect it may be related with the fact that the svn string we log in all git commits (at the end, where it says git-svn-id:) has actually a http:// prefix and not an https:// one. I ended workarounding this by adding manually the config for https://svn.webkit.org on ~/subversion to make SVNRepository.has_authorization_for_realm happy Now, i wonder.. i'm the only one that had trouble with this? Does "webkit-patch land" work fine for you from a git repository? 1698427 8 clopez 2020-10-15 18:49:48 -0700 (In reply to Sergio Villar Senin from comment #5) > It stills asks for username/password to me everytime I try to land a patch. This is likely caused by default svn config. Check that you don't have "store-passwords = no" on ~/.subversion/config You can set also "password-stores = gnome-keyring" to not store it on plaintext More info: https://stackoverflow.com/q/2899209 1698439 9 fujii 2020-10-15 19:35:32 -0700 Use WebKit-https.git. Follow this https://webkit.org/getting-the-code/#checking-out-with-git As far as I tested, webkit-patch setup-git-clone fails for WebKit.git. So, all commiters should use WebKit-https.git. 1698459 10 clopez 2020-10-15 20:47:15 -0700 (In reply to Fujii Hironori from comment #9) > Use WebKit-https.git. Follow this > https://webkit.org/getting-the-code/#checking-out-with-git > > As far as I tested, webkit-patch setup-git-clone fails for WebKit.git. > So, all commiters should use WebKit-https.git. Oook.. that explains it.. so there is a git://git.webkit.org/WebKit-https.git repository that has the entries for git-svn-id: with https instead of that. Didn't know that, interesting. The problem I see with this is that this repository has a different git hash for every commit (because the commit log changes due to using https for git-svn-id) So if you keep several remotes (like I do) for example to easily push/pull from different forks on github, gitlab, etc.. using this WebKit-https.git repo is a problem since the hashes don't match with every other fork of the webkit repository out there and git can't merge the common commits :( so I guess this will cause issues when rebasing/merging branches 1698496 11 svillar 2020-10-16 01:25:27 -0700 (In reply to Carlos Alberto Lopez Perez from comment #8) > (In reply to Sergio Villar Senin from comment #5) > > It stills asks for username/password to me everytime I try to land a patch. > > This is likely caused by default svn config. > > Check that you don't have "store-passwords = no" on ~/.subversion/config > You can set also "password-stores = gnome-keyring" to not store it on > plaintext > More info: https://stackoverflow.com/q/2899209 I doubt it's a problem in my svn config because I haven't touched it and it has been working fine for years. BTW store-passwords is not set to no and I had already set "password-stores = gnome-keyring,kwallet" so that is not the problem either. 1698616 12 jbedard 2020-10-16 08:41:14 -0700 I don't think sorting out the http vs https and different hashes in the git clone is going to be very worthwhile. The git clone, as is, has a number of deficiencies (namely, it doesn't actually have any branches) At the moment, I'm doing a deep git clone of WebKit for the GitHub transition, and I intend to add commit identifiers into the commit messages of all historical commits (which obviously breaks existing hashes). 1698619 13 clopez 2020-10-16 08:52:29 -0700 (In reply to Jonathan Bedard from comment #12) > I don't think sorting out the http vs https and different hashes in the git > clone is going to be very worthwhile. The git clone, as is, has a number of > deficiencies (namely, it doesn't actually have any branches) > > At the moment, I'm doing a deep git clone of WebKit for the GitHub > transition, and I intend to add commit identifiers into the commit messages > of all historical commits (which obviously breaks existing hashes). why adding commit identifiers to the current repo is needed? those are already tagged with the git-svn-id tag. The new tagging system can be used for the commits after the migration, but the older ones are already tagged with the revision number. I foresee pain for developers if we switch to a new git repo that breakes the hashes of the de-facto webkit repository (the one mirrored in github). To start with all the forks we have in github will be completely broken and will not longer be a fork but a disjoint repository with no commits in common. 1698633 14 jbedard 2020-10-16 09:15:53 -0700 (In reply to Carlos Alberto Lopez Perez from comment #13) > (In reply to Jonathan Bedard from comment #12) > > I don't think sorting out the http vs https and different hashes in the git > > clone is going to be very worthwhile. The git clone, as is, has a number of > > deficiencies (namely, it doesn't actually have any branches) > > > > At the moment, I'm doing a deep git clone of WebKit for the GitHub > > transition, and I intend to add commit identifiers into the commit messages > > of all historical commits (which obviously breaks existing hashes). > > why adding commit identifiers to the current repo is needed? those are > already tagged with the git-svn-id tag. The new tagging system can be used > for the commits after the migration, but the older ones are already tagged > with the revision number. > > I foresee pain for developers if we switch to a new git repo that breakes > the hashes of the de-facto webkit repository (the one mirrored in github). > To start with all the forks we have in github will be completely broken and > will not longer be a fork but a disjoint repository with no commits in > common. The GitHub mirror is explicitly advertised as an unofficial one. And SVN revisions will be dying in the very near future, so everyone will find they are not of much use in the near future. We're trying to optimize for the future, I'm not aware of anyone actively tracking hashes in the WebKit mirror, breaking forks seems like an acceptable trade-off in exchange for a consistent labeling scheme. 1698761 15 rniwa 2020-10-16 14:56:11 -0700 (In reply to Jonathan Bedard from comment #14) > (In reply to Carlos Alberto Lopez Perez from comment #13) > > (In reply to Jonathan Bedard from comment #12) > > > I don't think sorting out the http vs https and different hashes in the git > > > clone is going to be very worthwhile. The git clone, as is, has a number of > > > deficiencies (namely, it doesn't actually have any branches) > > > > > > At the moment, I'm doing a deep git clone of WebKit for the GitHub > > > transition, and I intend to add commit identifiers into the commit messages > > > of all historical commits (which obviously breaks existing hashes). > > > > why adding commit identifiers to the current repo is needed? those are > > already tagged with the git-svn-id tag. The new tagging system can be used > > for the commits after the migration, but the older ones are already tagged > > with the revision number. > > > > I foresee pain for developers if we switch to a new git repo that breakes > > the hashes of the de-facto webkit repository (the one mirrored in github). > > To start with all the forks we have in github will be completely broken and > > will not longer be a fork but a disjoint repository with no commits in > > common. > > The GitHub mirror is explicitly advertised as an unofficial one. And SVN > revisions will be dying in the very near future, so everyone will find they > are not of much use in the near future. We're trying to optimize for the > future, I'm not aware of anyone actively tracking hashes in the WebKit > mirror, breaking forks seems like an acceptable trade-off in exchange for a > consistent labeling scheme. FWIW, we can probably archive the existing GitHub mirror as DepreactedWebKitMirror or something for a while so that people who have links, etc... can reference the old mirror. Alternatively, we can build some conversion tool / service to map old Git hashes to new ones. 1699025 16 emilio 2020-10-17 17:07:07 -0700 (In reply to Jonathan Bedard from comment #14) > I'm not aware of anyone actively tracking hashes in the WebKit > mirror. I don't think it necessarily changes the trade-offs, but permalinks to https://webkit-search.igalia.com do use the commit hash. 1699165 17 annulen 2020-10-18 16:28:11 -0700 (In reply to Jonathan Bedard from comment #12) > At the moment, I'm doing a deep git clone of WebKit for the GitHub > transition, and I intend to add commit identifiers into the commit messages > of all historical commits (which obviously breaks existing hashes). I think this is completely unnecessary and doesn't justify breaking 2000 existing forks. There are at least two better alternatives: 1. Start adding new identifiers in new commits and just leave old ones alone. They were made in "svn era" when svn repo was a source of truth. These commits are addressed by their revision number in existing products, and AFAIU adding new post-factum identifiers won't solve any real world task. 2. Use lightweight tags and keep new identifiers completely separate from commit messages. Decorated git log will show these new identifiers for all commits. 1699166 18 annulen 2020-10-18 16:30:49 -0700 (In reply to Konstantin Tokarev from comment #17) > 2. Use lightweight tags and keep new identifiers completely separate from > commit messages. Decorated git log will show these new identifiers for all > commits. It would be also possible to use new identifiers for addressing commits in git commands, which seems to me as must have feature for any alternative identifiers system. 1699167 19 rniwa 2020-10-18 16:32:23 -0700 (In reply to Konstantin Tokarev from comment #18) > (In reply to Konstantin Tokarev from comment #17) > > 2. Use lightweight tags and keep new identifiers completely separate from > > commit messages. Decorated git log will show these new identifiers for all > > commits. > > It would be also possible to use new identifiers for addressing commits in > git commands, which seems to me as must have feature for any alternative > identifiers system. No, we really need to be address all past commits the same way. That's simply not acceptable. We track down regressions multiple years, even decades all the time. 1699168 20 annulen 2020-10-18 16:35:05 -0700 Did you quote the right part of my comment? Because using lightweight tags is exactly a way which allows to add new identifiers to old commits without changing history. 1699172 21 annulen 2020-10-18 16:55:03 -0700 Another possibility is using git notes [1] instead of tags. They can also be show in git log (though they won't work as native commit identifiers) [1] https://git-scm.com/docs/git-notes 1699175 22 rniwa 2020-10-18 17:23:53 -0700 I really don't think we should give a high priority to preserving the history with the existing forks. Having the information of existing branches, etc... is way more important for most WebKit contributors. I certainly don't care that all of my got clones need to be re-created. 1699176 23 annulen 2020-10-18 17:34:50 -0700 >Having the information of existing branches, etc... is way more important for most WebKit contributors. Branches can be easily added to existing GitHub mirror simply by changing git-svn configuration, see e.g. https://github.com/qtwebkit/webkit-mirror >I certainly don't care that all of my got clones need to be re-created. So you don't care, and those who do should suffer? Okay. 1699177 24 rniwa 2020-10-18 17:44:52 -0700 (In reply to Konstantin Tokarev from comment #23) > >Having the information of existing branches, etc... is way more important for most WebKit contributors. > > Branches can be easily added to existing GitHub mirror simply by changing > git-svn configuration, see e.g. https://github.com/qtwebkit/webkit-mirror > > >I certainly don't care that all of my got clones need to be re-created. > > So you don't care, and those who do should suffer? Okay. That's right. The consideration we give should be proportional to the contributions they make back to the WebKit project. If they're making a fork and making changes there, I don't really see why we'd give much considerations for them. 1699178 25 annulen 2020-10-18 18:11:55 -0700 We have to make forks because there was a rule that upstream WebKit port should have at least three full-time people working on it. Any plan to change this rule so forks are not needed anymore? 1699183 26 rniwa 2020-10-18 18:53:40 -0700 (In reply to Konstantin Tokarev from comment #25) > We have to make forks because there was a rule that upstream WebKit port > should have at least three full-time people working on it. Any plan to > change this rule so forks are not needed anymore? No plan to change that. Again, the requirement is there to avoid situations in which ports that don't contribute much beyond maintaining their own port will put undue burden onto the rest of the community with a high maintenance cost. If a port has less than 3 full time people, then this will most certainly happen. The same goes for this Git hash concerns. The concerns of the majority of contributors come first because they're the ones making forward progress in the project. We can't make their experience worse / make them less productive to care for forks of unofficial Git mirrors. Right now, the official VCS of the WebKit project is Subversion. If you're using anything else to have your own fork, you're on your own. 1699185 27 annulen 2020-10-18 19:14:27 -0700 >We can't make their experience worse / make them less productive to care for forks of unofficial Git mirrors. How does using git tags or git notes make them less productive then rewriting commit messages? The latter way requires parsing identifiers back from commit messages to make any use of them, which is far from being "productive" in my book. >If you're using anything else to have your own fork, you're on your own. Sorry, but using Subversion for maintaining forks is extremely non-productive because of inferior tooling. 1699262 28 jbedard 2020-10-19 08:51:12 -0700 (In reply to Konstantin Tokarev from comment #17) > (In reply to Jonathan Bedard from comment #12) > > At the moment, I'm doing a deep git clone of WebKit for the GitHub > > transition, and I intend to add commit identifiers into the commit messages > > of all historical commits (which obviously breaks existing hashes). > > I think this is completely unnecessary and doesn't justify breaking 2000 > existing forks. There are at least two better alternatives: > > 1. Start adding new identifiers in new commits and just leave old ones > alone. They were made in "svn era" when svn repo was a source of truth. > These commits are addressed by their revision number in existing products, > and AFAIU adding new post-factum identifiers won't solve any real world task. > > 2. Use lightweight tags and keep new identifiers completely separate from > commit messages. Decorated git log will show these new identifiers for all > commits. I noticed this weekend that the GitHub clone is the http clone anyways, so we're defiantly going to be breaking hashes on clones of that version of the repository (since the deep clone will be https). 1699265 29 jbedard 2020-10-19 08:57:05 -0700 (In reply to Emilio Cobos Álvarez (:emilio) from comment #16) > (In reply to Jonathan Bedard from comment #14) > > I'm not aware of anyone actively tracking hashes in the WebKit > > mirror. > > I don't think it necessarily changes the trade-offs, but permalinks to > https://webkit-search.igalia.com do use the commit hash. Are those using the GitHub http hashes or the https hashes? 1699268 30 annulen 2020-10-19 09:02:13 -0700 > I noticed this weekend that the GitHub clone is the http clone anyways, so > we're defiantly going to be breaking hashes on clones of that version of the > repository (since the deep clone will be https). The only difference is having "https" urls in git-svn-id messages instead of "http". Does it really matter? 1699281 31 jbedard 2020-10-19 09:40:39 -0700 (In reply to Konstantin Tokarev from comment #30) > > I noticed this weekend that the GitHub clone is the http clone anyways, so > > we're defiantly going to be breaking hashes on clones of that version of the > > repository (since the deep clone will be https). > > The only difference is having "https" urls in git-svn-id messages instead of > "http". Does it really matter? We already have an https git clone in use, so unifying the repository in GitHub will be breaking someone regardless of what we do. Which is why I'm an advocate for making things the best they can be for the future, even if that means some temporary pain. 1699303 32 clopez 2020-10-19 10:34:01 -0700 (In reply to Jonathan Bedard from comment #31) > (In reply to Konstantin Tokarev from comment #30) > > > I noticed this weekend that the GitHub clone is the http clone anyways, so > > > we're defiantly going to be breaking hashes on clones of that version of the > > > repository (since the deep clone will be https). > > > > The only difference is having "https" urls in git-svn-id messages instead of > > "http". Does it really matter? > > We already have an https git clone in use, so unifying the repository in > GitHub will be breaking someone regardless of what we do. Which is why I'm > an advocate for making things the best they can be for the future, even if > that means some temporary pain. I noticed past week that we have an alternative git repository with "https" for the git-svn-id hashes. Not sure how popular this alternative https-git repository is, but I would bet it isn't nowhere as popular as the one in github (the one with "http" in the git-svn-id), which is also the original git repository provided by this project as an alternative to svn at git.webkit.org/git/WebKit.git That repository in github is forked 2k times. I wouldn't want to break 2k forks if there is an alternative to keep the future repository compatible with those existing forks. 1699318 33 annulen 2020-10-19 11:09:41 -0700 FWIW, if we settle on breaking old history, I'm going to set up alternative automatic mirror which will have new commits rebased onto old history. Anyone will be able to use it instead of official one for keeping their forks up to date. 1717306 34 kallisti5 2021-01-05 07:58:04 -0800 Hi! Haiku project here! We're suffering a *LOT* of pain on this one as well. Webkit is placing new platforms into a weird catch-22 situation. 1. No new platform code accepted until testers + builders 2. Testers + builders won't work until new code in tree 3. Git history churn means you can't keep new platform support forks for very long. Our team spends 99% of it's time now just dealing with git churn and rewrites at webkit and not making any port progress. Please help by stopping this. This isn't how git works. 1717307 35 jbedard 2021-01-05 08:05:11 -0800 (In reply to Alex from comment #34) > Hi! > Haiku project here! > > We're suffering a *LOT* of pain on this one as well. > > Webkit is placing new platforms into a weird catch-22 situation. > > 1. No new platform code accepted until testers + builders > 2. Testers + builders won't work until new code in tree > 3. Git history churn means you can't keep new platform support forks for > very long. > > > Our team spends 99% of it's time now just dealing with git churn and > rewrites at webkit and not making any port progress. > > Please help by stopping this. This isn't how git works. We had two different git histories, the http and https one. The work over the last month on the new GitHub mirror was about cleaning up our history so we can move forward, eventually deprecating SVN in favor of git. We are done editing history now (at least on main, but we aren't canonically tracking other branches in Git yet anyways). If you need help rebasing branches on the new history, let me know. It shouldn't be too difficult, and will be a one-time operation. 1717308 36 kallisti5 2021-01-05 08:11:58 -0800 We can always use a hand :-) https://github.com/haiku/webkit/tree/rebased I got in over my head pretty quickly trying to rebase on master lol. 1717309 37 jbedard 2021-01-05 08:21:05 -0800 (In reply to Alex from comment #36) > We can always use a hand :-) > > https://github.com/haiku/webkit/tree/rebased > > I got in over my head pretty quickly trying to rebase on master lol. I have a partial set of instructions to do the rebase which I was going to send out to everyone who forked the project this week, give me a bit to double-check that process against your fork, and I will post it to this bug. 1717962 38 jbedard 2021-01-07 08:50:58 -0800 Here is the set of instructions to rebase onto the new primary branch: Checkout the latest updated WebKit into your fork: git remote add canonical https://github.com/WebKit/WebKit.git git fetch canonical Determine the identifier of your branch point, called “branch-point-old”: git checkout canonical/main Tools/Scripts/git-webkit find <branch-point-old> where “branch-point-old” is a git reference (either hash or branch, usually) to the point your fork diverged from WebKit’s main branch. This should give you an identifier of the form <integer>@<branch>. Map that branch point onto the canonical repository, whose’s ref we will call “branch-point-new” : Tools/Scripts/git-webkit find <integer>@main Create a new branch and rebase your changes from the old repository onto the new: git branch -f <my-branch-new> <branch-point-new> git rebase —onto <my-branch-new> <branch-point-old> <my-branch-old> where “my-branch-new” is a new branch name. The issue with this approach (as I discovered working with Alex) is that it breaks-down with merge-commits, if your fork has been combining WebKit changes with your own changes, rather than rebasing your changes on top of WebKit's changes, things are going to be more difficult. 405544 2020-07-29 21:21:39 -0700 2020-07-29 22:28:32 -0700 Patch bug-214957-20200730132138.patch text/plain 7705 fujii U3VidmVyc2lvbiBSZXZpc2lvbjogMjY1MDczCmRpZmYgLS1naXQgYS9Ub29scy9DaGFuZ2VMb2cg Yi9Ub29scy9DaGFuZ2VMb2cKaW5kZXggYjM4YmQ4YmQxMmE3ZGNjYmM1ZGRhOWVhODFlMDRiNzE1 NjRkYWJmZC4uZjg2ZGJkNGNmMzg4Y2ZlYTg5ZmRlOWU1M2ViZWY5YjYwNmUxYjZhZSAxMDA2NDQK LS0tIGEvVG9vbHMvQ2hhbmdlTG9nCisrKyBiL1Rvb2xzL0NoYW5nZUxvZwpAQCAtMSwzICsxLDIx IEBACisyMDIwLTA3LTI5ICBGdWppaSBIaXJvbm9yaSAgPEhpcm9ub3JpLkZ1amlpQHNvbnkuY29t PgorCisgICAgICAgIFJlcGxhY2UgJ2h0dHA6Ly9zdm4ud2Via2l0Lm9yZycgd2l0aCAnaHR0cHM6 Ly9zdm4ud2Via2l0Lm9yZycgaW4gd2Via2l0cHkgc2NyaXB0cworICAgICAgICBodHRwczovL2J1 Z3Mud2Via2l0Lm9yZy9zaG93X2J1Zy5jZ2k/aWQ9MjE0OTU3CisKKyAgICAgICAgUmV2aWV3ZWQg YnkgTk9CT0RZIChPT1BTISkuCisKKyAgICAgICAgU1ZOUmVwb3NpdG9yeS5oYXNfYXV0aG9yaXph dGlvbl9mb3JfcmVhbG0gZmFpbGVkIHRvIGZpbmQgdGhlIHJlYWxtCisgICAgICAgIHN0cmluZy4K KworICAgICAgICAqIFNjcmlwdHMvd2Via2l0cHkvY29tbW9uL2NoZWNrb3V0L2NoYW5nZWxvZy5w eToKKyAgICAgICAgKENoYW5nZUxvZ0VudHJ5KTogUmVtb3ZlZCBhIHVudXNlZCB2YXJpYWJsZSAn c3ZuX2lkX3JlZ2V4cCcuCisgICAgICAgICogU2NyaXB0cy93ZWJraXRweS9jb21tb24vY2hlY2tv dXQvc2NtL3NjbV91bml0dGVzdC5weToKKyAgICAgICAgKiBTY3JpcHRzL3dlYmtpdHB5L2NvbW1v bi9jb25maWcvdXJscy5weToKKyAgICAgICAgKiBTY3JpcHRzL3dlYmtpdHB5L3Rvb2wvY29tbWFu ZHMvc3VnZ2VzdG5vbWluYXRpb25zLnB5OgorICAgICAgICAoQWJzdHJhY3RDb21taXRMb2dDb21t YW5kKTogQ2hhbmdlZCBfcmV2aXNpb25fcmVnZXhwIHRvIHVzZSAnaHR0cHM/JyB0byBhY2NlcHQg J2h0dHBzJy4KKyAgICAgICAgKiBTY3JpcHRzL3dlYmtpdHB5L3Rvb2wvY29tbWFuZHMvc3VnZ2Vz dG5vbWluYXRpb25zX3VuaXR0ZXN0LnB5OgorCiAyMDIwLTA3LTI5ICBEYXJpbiBBZGxlciAgPGRh cmluQGFwcGxlLmNvbT4KIAogICAgICAgICBBZGQgc2NyaXB0IHRvIGhlbHAgdXMgY291bnQgdXNl cyBvZiBub24taW5jbHVzaXZlIHRlcm1zCmRpZmYgLS1naXQgYS9Ub29scy9TY3JpcHRzL3dlYmtp dHB5L2NvbW1vbi9jaGVja291dC9jaGFuZ2Vsb2cucHkgYi9Ub29scy9TY3JpcHRzL3dlYmtpdHB5 L2NvbW1vbi9jaGVja291dC9jaGFuZ2Vsb2cucHkKaW5kZXggOGY0OTE1NjM4NjZkOGFhMzNiYjUx MjIyNDZlY2M0ZjExZGU3ZTAxMC4uYWEyYjRhZTdlYTJkOGFiOWI4MWZjNDUwYzIyOTQ3ZWEwY2Iz MjBjZiAxMDA2NDQKLS0tIGEvVG9vbHMvU2NyaXB0cy93ZWJraXRweS9jb21tb24vY2hlY2tvdXQv Y2hhbmdlbG9nLnB5CisrKyBiL1Rvb2xzL1NjcmlwdHMvd2Via2l0cHkvY29tbW9uL2NoZWNrb3V0 L2NoYW5nZWxvZy5weQpAQCAtMTAzLDkgKzEwMyw2IEBAIGNsYXNzIENoYW5nZUxvZ0VudHJ5KG9i amVjdCk6CiAgICAgIyBlLmcuID09IFJvbGxlZCBvdmVyIHRvIENoYW5nZUxvZy0yMDExLTAyLTE2 ID09CiAgICAgcm9sbGVkX292ZXJfcmVnZXhwID0gcidePT0gUm9sbGVkIG92ZXIgdG8gQ2hhbmdl TG9nLVxkezR9LVxkezJ9LVxkezJ9ID09JCcKIAotICAgICMgZS5nLiBnaXQtc3ZuLWlkOiBodHRw Oi8vc3ZuLndlYmtpdC5vcmcvcmVwb3NpdG9yeS93ZWJraXQvdHJ1bmtAOTYxNjEgMjY4ZjQ1Y2Mt Y2QwOS0wNDEwLWFiM2MtZDUyNjkxYjRkYmZjCi0gICAgc3ZuX2lkX3JlZ2V4cCA9IHInZ2l0LXN2 bi1pZDogaHR0cDovL3N2bi53ZWJraXQub3JnL3JlcG9zaXRvcnkvd2Via2l0L3RydW5rQCg/UDxz dm5pZD5cZCspICcKLQogICAgIHNwbGl0X25hbWVzX3JlZ2V4cCA9IHInXHMqKD86LCg/OlxzK2Fu ZFxzK3wmKT98KD86XnxccyspYW5kXHMrfCYmfFsvKyZdKVxzKicKIAogICAgIGRlZiBfX2luaXRf XyhzZWxmLCBjb250ZW50cywgY29tbWl0dGVyX2xpc3Q9Tm9uZSwgcmV2aXNpb249Tm9uZSk6CmRp ZmYgLS1naXQgYS9Ub29scy9TY3JpcHRzL3dlYmtpdHB5L2NvbW1vbi9jaGVja291dC9zY20vc2Nt X3VuaXR0ZXN0LnB5IGIvVG9vbHMvU2NyaXB0cy93ZWJraXRweS9jb21tb24vY2hlY2tvdXQvc2Nt L3NjbV91bml0dGVzdC5weQppbmRleCA1MjMxOTE1Yjg1NzM2YTY1ZDAxMTZkYWUxOThiYTk1MjNj ODc1MTg0Li4wZGRiZDJlYTIzZjhhZGI4Y2I3NGU1ZGVmZTJkNzEyMjcwNTM3ODZhIDEwMDY0NAot LS0gYS9Ub29scy9TY3JpcHRzL3dlYmtpdHB5L2NvbW1vbi9jaGVja291dC9zY20vc2NtX3VuaXR0 ZXN0LnB5CisrKyBiL1Rvb2xzL1NjcmlwdHMvd2Via2l0cHkvY29tbW9uL2NoZWNrb3V0L3NjbS9z Y21fdW5pdHRlc3QucHkKQEAgLTgwOCw3ICs4MDgsNyBAQCBrZXljaGFpbgogSyAxNQogc3ZuOnJl YWxtc3RyaW5nCiBWIDM5Ci08aHR0cDovL3N2bi53ZWJraXQub3JnOjgwPiBNYWMgT1MgRm9yZ2UK KzxodHRwczovL3N2bi53ZWJraXQub3JnOjQ0Mz4gTWFjIE9TIEZvcmdlCiBLIDgKIHVzZXJuYW1l CiBWIDE3CkBAIC04MjIsNyArODIyLDcgQEAgRU5ECiBLIDE1CiBzdm46cmVhbG1zdHJpbmcKIFYg MzkKLTxodHRwOi8vc3ZuLndlYmtpdC5vcmc6ODA+IE1hYyBPUyBGb3JnZQorPGh0dHBzOi8vc3Zu LndlYmtpdC5vcmc6NDQzPiBNYWMgT1MgRm9yZ2UKIEsgOAogdXNlcm5hbWUKIFYgMTcKQEAgLTg1 Miw3ICs4NTIsNyBAQCBFTkQKIEsgMTUKIHN2bjpyZWFsbXN0cmluZwogViAzOQotPGh0dHA6Ly9z dm4ud2Via2l0Lm9yZzo4MD4gTWFjIE9TIEZvcmdlCis8aHR0cHM6Ly9zdm4ud2Via2l0Lm9yZzo0 NDM+IE1hYyBPUyBGb3JnZQogSyA4CiB1c2VybmFtZQogViAxNwpAQCAtMTc2OSw3ICsxNzY5LDEy IEBAIE1PQ0sgcnVuX2NvbW1hbmQ6IFsnZ2l0JywgJ2xvZycsICctMScsICctLWdyZXA9Z2l0LXN2 bi1pZDonLCAnLS1kYXRlPWlzbycsICcuL01PCiAgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwoc2Nt LnN2bl9icmFuY2goc2NtLmNoZWNrb3V0X3Jvb3QpLCAndHJ1bmsnKQogICAgICAgICBzZWxmLmFz c2VydEVxdWFsKHNjbS5zdm5fdXJsKHNjbS5jaGVja291dF9yb290KSwgJ2h0dHA6Ly9zdm4ud2Vi a2l0Lm9yZy9yZXBvc2l0b3J5L3dlYmtpdC90cnVuaycpCiAKLSAgICAgICAgc2NtLl9tb3N0X3Jl Y2VudF9sb2dfbWF0Y2hpbmcgPSBsYW1iZGEgZ3JlcF9zdHIsIHBhdGg6ICdnaXQtc3ZuLWlkOiBo dHRwOi8vc3ZuLndlYmtpdC5vcmcvcmVwb3NpdG9yeS93ZWJraXQvYnJhbmNoL3NwZWNpYWxTdWJt aXNzaW9uQDI1ODAwMCAyNjhmNDVjYy1jZDA5LTA0MTAtYWIzYy1kNTI2OTFiNGRiZmMnCisgICAg ICAgIHNjbS5fbW9zdF9yZWNlbnRfbG9nX21hdGNoaW5nID0gbGFtYmRhIGdyZXBfc3RyLCBwYXRo OiAnZ2l0LXN2bi1pZDogaHR0cHM6Ly9zdm4ud2Via2l0Lm9yZy9yZXBvc2l0b3J5L3dlYmtpdC90 cnVua0AyNTgwMjQgMjY4ZjQ1Y2MtY2QwOS0wNDEwLWFiM2MtZDUyNjkxYjRkYmZjJworICAgICAg ICBzZWxmLmFzc2VydEVxdWFsKHNjbS5zdm5fcmV2aXNpb24oc2NtLmNoZWNrb3V0X3Jvb3QpLCAn MjU4MDI0JykKKyAgICAgICAgc2VsZi5hc3NlcnRFcXVhbChzY20uc3ZuX2JyYW5jaChzY20uY2hl Y2tvdXRfcm9vdCksICd0cnVuaycpCisgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwoc2NtLnN2bl91 cmwoc2NtLmNoZWNrb3V0X3Jvb3QpLCAnaHR0cHM6Ly9zdm4ud2Via2l0Lm9yZy9yZXBvc2l0b3J5 L3dlYmtpdC90cnVuaycpCisKKyAgICAgICAgc2NtLl9tb3N0X3JlY2VudF9sb2dfbWF0Y2hpbmcg PSBsYW1iZGEgZ3JlcF9zdHIsIHBhdGg6ICdnaXQtc3ZuLWlkOiBodHRwczovL3N2bi53ZWJraXQu b3JnL3JlcG9zaXRvcnkvd2Via2l0L2JyYW5jaC9zcGVjaWFsU3VibWlzc2lvbkAyNTgwMDAgMjY4 ZjQ1Y2MtY2QwOS0wNDEwLWFiM2MtZDUyNjkxYjRkYmZjJwogICAgICAgICBzZWxmLmFzc2VydEVx dWFsKHNjbS5zdm5fcmV2aXNpb24oc2NtLmNoZWNrb3V0X3Jvb3QpLCAnMjU4MDAwJykKICAgICAg ICAgc2VsZi5hc3NlcnRFcXVhbChzY20uc3ZuX2JyYW5jaChzY20uY2hlY2tvdXRfcm9vdCksICdz cGVjaWFsU3VibWlzc2lvbicpCi0gICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwoc2NtLnN2bl91cmwo c2NtLmNoZWNrb3V0X3Jvb3QpLCAnaHR0cDovL3N2bi53ZWJraXQub3JnL3JlcG9zaXRvcnkvd2Vi a2l0L2JyYW5jaC9zcGVjaWFsU3VibWlzc2lvbicpCisgICAgICAgIHNlbGYuYXNzZXJ0RXF1YWwo c2NtLnN2bl91cmwoc2NtLmNoZWNrb3V0X3Jvb3QpLCAnaHR0cHM6Ly9zdm4ud2Via2l0Lm9yZy9y ZXBvc2l0b3J5L3dlYmtpdC9icmFuY2gvc3BlY2lhbFN1Ym1pc3Npb24nKQpkaWZmIC0tZ2l0IGEv VG9vbHMvU2NyaXB0cy93ZWJraXRweS9jb21tb24vY29uZmlnL3VybHMucHkgYi9Ub29scy9TY3Jp cHRzL3dlYmtpdHB5L2NvbW1vbi9jb25maWcvdXJscy5weQppbmRleCAwNDZhY2VkOTMzNDNkMjY3 NmMzYTU5ODI5YWY3NDZlZDQxOGQxM2JhLi5jZmNmM2RlZmFjMzY2M2U0OWFiMDRhZDBhOTg2OTk0 OTgxZGFlYTY0IDEwMDY0NAotLS0gYS9Ub29scy9TY3JpcHRzL3dlYmtpdHB5L2NvbW1vbi9jb25m aWcvdXJscy5weQorKysgYi9Ub29scy9TY3JpcHRzL3dlYmtpdHB5L2NvbW1vbi9jb25maWcvdXJs cy5weQpAQCAtNTMsNyArNTMsNyBAQCBkaXJlY3RfYXR0YWNobWVudF91cmwgPSByImh0dHBzPzov L2J1Zy0oP1A8YnVnX2lkPlxkKyktYXR0YWNobWVudHMuJXMvYXR0YWNobWVudAogYnVpbGRib3Rf dXJsID0gImh0dHBzOi8vYnVpbGQud2Via2l0Lm9yZyIKIAogc3ZuX3NlcnZlcl9ob3N0ID0gInN2 bi53ZWJraXQub3JnIgotc3ZuX3NlcnZlcl9yZWFsbSA9ICI8aHR0cDovL3N2bi53ZWJraXQub3Jn OjgwPiBNYWMgT1MgRm9yZ2UiCitzdm5fc2VydmVyX3JlYWxtID0gIjxodHRwczovL3N2bi53ZWJr aXQub3JnOjQ0Mz4gTWFjIE9TIEZvcmdlIgogCiBld3NzZXJ2ZXJfZGVmYXVsdF9ob3N0ID0gImV3 cy53ZWJraXQub3JnIgogCmRpZmYgLS1naXQgYS9Ub29scy9TY3JpcHRzL3dlYmtpdHB5L3Rvb2wv Y29tbWFuZHMvc3VnZ2VzdG5vbWluYXRpb25zLnB5IGIvVG9vbHMvU2NyaXB0cy93ZWJraXRweS90 b29sL2NvbW1hbmRzL3N1Z2dlc3Rub21pbmF0aW9ucy5weQppbmRleCAxMWEyNDAxOWM1MTI1NzE2 NmQ5YjkxNzZmNzZlOWYzYTRjN2YyNDc1Li4wZmMxNDQ4MGJjYzdjYmVkNzBjMTIzNTA4Zjk2MGU3 N2I5OTQxN2ZlIDEwMDY0NAotLS0gYS9Ub29scy9TY3JpcHRzL3dlYmtpdHB5L3Rvb2wvY29tbWFu ZHMvc3VnZ2VzdG5vbWluYXRpb25zLnB5CisrKyBiL1Rvb2xzL1NjcmlwdHMvd2Via2l0cHkvdG9v bC9jb21tYW5kcy9zdWdnZXN0bm9taW5hdGlvbnMucHkKQEAgLTUyLDcgKzUyLDcgQEAgY2xhc3Mg QWJzdHJhY3RDb21taXRMb2dDb21tYW5kKENvbW1hbmQpOgogICAgIF9wYXRjaF9ieV9yZWdleHAg PSByZS5jb21waWxlKHInXlBhdGNoIGJ5ICg/UDxuYW1lPi4rPylccys8KD9QPGVtYWlsPltePD5d Kyk+IG9uICg/UDxkYXRlPlxkezR9LVxkezJ9LVxkezJ9KSQnLCByZS5NVUxUSUxJTkUpCiAgICAg X2NvbW1pdHRlcl9yZWdleHAgPSByZS5jb21waWxlKHInXkF1dGhvcjogKD9QPGVtYWlsPlxTKylc cys8W14+XSs+JCcsIHJlLk1VTFRJTElORSkKICAgICBfZGF0ZV9yZWdleHAgPSByZS5jb21waWxl KHInXkRhdGU6ICAgKD9QPGRhdGU+XGR7NH0tXGR7Mn0tXGR7Mn0pICg/UDx0aW1lPlxkezJ9Olxk ezJ9OlxkezJ9KSBbXCtcLV1cZHs0fSQnLCByZS5NVUxUSUxJTkUpCi0gICAgX3JldmlzaW9uX3Jl Z2V4cCA9IHJlLmNvbXBpbGUocideZ2l0LXN2bi1pZDogaHR0cDovL3N2bi53ZWJraXQub3JnL3Jl cG9zaXRvcnkvd2Via2l0L3RydW5rQCg/UDxzdm5pZD5cZCspICg/UDxnaXRpZD5bMC05YS1mXC1d ezM2fSkkJywgcmUuTVVMVElMSU5FKQorICAgIF9yZXZpc2lvbl9yZWdleHAgPSByZS5jb21waWxl KHInXmdpdC1zdm4taWQ6IGh0dHBzPzovL3N2bi53ZWJraXQub3JnL3JlcG9zaXRvcnkvd2Via2l0 L3RydW5rQCg/UDxzdm5pZD5cZCspICg/UDxnaXRpZD5bMC05YS1mXC1dezM2fSkkJywgcmUuTVVM VElMSU5FKQogCiAgICAgZGVmIF9faW5pdF9fKHNlbGYsIG9wdGlvbnM9Tm9uZSk6CiAgICAgICAg IG9wdGlvbnMgPSBvcHRpb25zIG9yIFtdCmRpZmYgLS1naXQgYS9Ub29scy9TY3JpcHRzL3dlYmtp dHB5L3Rvb2wvY29tbWFuZHMvc3VnZ2VzdG5vbWluYXRpb25zX3VuaXR0ZXN0LnB5IGIvVG9vbHMv U2NyaXB0cy93ZWJraXRweS90b29sL2NvbW1hbmRzL3N1Z2dlc3Rub21pbmF0aW9uc191bml0dGVz dC5weQppbmRleCAxM2JmYzhkNDdmNzRhYTZjMzZkZjRlYzYzN2I5YmE3ODc2NzE3NmI5Li40ZmFm Zjg1ZDJlYmNkNmU3ZTMxZDRhZTI0MjQ5MjY5OTdmYmU0NzY2IDEwMDY0NAotLS0gYS9Ub29scy9T Y3JpcHRzL3dlYmtpdHB5L3Rvb2wvY29tbWFuZHMvc3VnZ2VzdG5vbWluYXRpb25zX3VuaXR0ZXN0 LnB5CisrKyBiL1Rvb2xzL1NjcmlwdHMvd2Via2l0cHkvdG9vbC9jb21tYW5kcy9zdWdnZXN0bm9t aW5hdGlvbnNfdW5pdHRlc3QucHkKQEAgLTQzLDcgKzQzLDcgQEAgRGF0ZTogICAyMDExLTA5LTE1 IDE5OjU2OjIxICswMDAwCiAKICAgICBSZXZpZXdlZCBieSBHZW9mZnJleSBHYXJlbi4KIAotICAg IGdpdC1zdm4taWQ6IGh0dHA6Ly9zdm4ud2Via2l0Lm9yZy9yZXBvc2l0b3J5L3dlYmtpdC90cnVu a0A5NTIxOSAyNjhmNDVjYy1jZDA5LTA0MTAtYWIzYy1kNTI2OTFiNGRiZmMKKyAgICBnaXQtc3Zu LWlkOiBodHRwczovL3N2bi53ZWJraXQub3JnL3JlcG9zaXRvcnkvd2Via2l0L3RydW5rQDk1MjE5 IDI2OGY0NWNjLWNkMDktMDQxMC1hYjNjLWQ1MjY5MWI0ZGJmYwogIiIiCiAgICAgbW9ja19zYW1l X2F1dGhvcl9jb21taXRfbWVzc2FnZSA9ICIiIkF1dGhvcjogZnBpemxvQGFwcGxlLmNvbSA8ZnBp emxvQGFwcGxlLmNvbUAyNjhmNDVjYy1jZDA5LTA0MTAtYWIzYy1kNTI2OTFiNGRiZmM+CiBEYXRl OiAgIDIwMTEtMDktMTUgMTk6NTY6MjEgKzAwMDAKQEAgLTUzLDcgKzUzLDcgQEAgaHR0cHM6Ly9i dWdzLndlYmtpdC5vcmcvc2hvd19idWcuY2dpP2lkPTY4MTQzCiAKIFJldmlld2VkIGJ5IEdlb2Zm cmV5IEdhcmVuLgogCi1naXQtc3ZuLWlkOiBodHRwOi8vc3ZuLndlYmtpdC5vcmcvcmVwb3NpdG9y eS93ZWJraXQvdHJ1bmtAOTUyMTkgMjY4ZjQ1Y2MtY2QwOS0wNDEwLWFiM2MtZDUyNjkxYjRkYmZj CitnaXQtc3ZuLWlkOiBodHRwczovL3N2bi53ZWJraXQub3JnL3JlcG9zaXRvcnkvd2Via2l0L3Ry dW5rQDk1MjE5IDI2OGY0NWNjLWNkMDktMDQxMC1hYjNjLWQ1MjY5MWI0ZGJmYwogIiIiCiAKICAg ICBkZWYgX21ha2Vfb3B0aW9ucyhzZWxmLCB2ZXJib3NlPUZhbHNlLCAqKmt3YXJncyk6CkBAIC05 MSw3ICs5MSw3IEBAIFNvdXJjZS9XZWJLaXQvY2hyb21pdW06CiAKICogV2ViS2l0Lmd5cDoKIAot Z2l0LXN2bi1pZDogaHR0cDovL3N2bi53ZWJraXQub3JnL3JlcG9zaXRvcnkvd2Via2l0L3RydW5r QDk1MTg4IDI2OGY0NWNjLWNkMDktMDQxMC1hYjNjLWQ1MjY5MWI0ZGJmYworZ2l0LXN2bi1pZDog aHR0cHM6Ly9zdm4ud2Via2l0Lm9yZy9yZXBvc2l0b3J5L3dlYmtpdC90cnVua0A5NTE4OCAyNjhm NDVjYy1jZDA5LTA0MTAtYWIzYy1kNTI2OTFiNGRiZmMKICIiIgogCiAgICAgZGVmIHRlc3RfYmFz aWMoc2VsZik6Cg==