[07:34:33] 10Diffusion, 05Gitblit-Deprecate: Redirect git.wikimedia.org HEAD URLs to Diffusion - https://phabricator.wikimedia.org/T141965#2518118 (10Nemo_bis) [08:39:28] 10Diffusion, 05Gitblit-Deprecate: Redirect git.wikimedia.org HEAD URLs to Diffusion - https://phabricator.wikimedia.org/T141965#2518118 (10Danny_B) What is the desired target? [08:41:14] 10Diffusion, 05Gitblit-Deprecate, 13Patch-For-Review: Update all references to git.wikimedia.org and replace them with the Phabricator equivalent - https://phabricator.wikimedia.org/T137353#2518196 (10Aklapper) [08:41:16] 10Diffusion, 05Gitblit-Deprecate: Redirect git.wikimedia.org HEAD URLs to Diffusion - https://phabricator.wikimedia.org/T141965#2518195 (10Aklapper) [08:41:34] 10Diffusion, 05Gitblit-Deprecate: Redirect git.wikimedia.org HEAD URLs to Diffusion - https://phabricator.wikimedia.org/T141965#2518118 (10Aklapper) Expected target should be https://phabricator.wikimedia.org/diffusion/GTWN/browse/irc-relay IMO [08:46:46] 05Gitblit-Deprecate, 06Project-Admins: Archive #Gitblit-Deprecate - https://phabricator.wikimedia.org/T138986#2518205 (10jayvdb) 05Open>03stalled Thankfully this appears to be on hold until the broken redirects are fixed. [08:46:48] 05Gitblit-Deprecate, 06Project-Admins: Archive #Gitblit-Deprecate - https://phabricator.wikimedia.org/T138986#2518207 (10jayvdb) 05Open>03stalled Thankfully this appears to be on hold until the broken redirects are fixed. [08:46:51] 05Gitblit-Deprecate, 06Project-Admins: Archive #Gitblit-Deprecate - https://phabricator.wikimedia.org/T138986#2518209 (10jayvdb) Thankfully this appears to be on hold until the broken redirects are fixed. [08:48:10] 05Gitblit-Deprecate, 06Project-Admins: Archive #Gitblit-Deprecate - https://phabricator.wikimedia.org/T138986#2518213 (10jayvdb) Interesting; I only submitted one comment. I see it appearing three times. [08:50:57] 05Gitblit-Deprecate, 06Operations, 06Release-Engineering-Team: Clones from git.wikimedia.org are not redirected - https://phabricator.wikimedia.org/T139206#2518214 (10Paladox) This will require us to generate another list to go on due to the difference in the names. [08:52:04] 10Diffusion, 05Gitblit-Deprecate: Redirect git.wikimedia.org HEAD URLs to Diffusion - https://phabricator.wikimedia.org/T141965#2518215 (10Paladox) We should just remove HEAD from URL, ie strip it when it goes to the URL. [08:53:07] 10Diffusion, 05Gitblit-Deprecate: Redirect git.wikimedia.org HEAD URLs to Diffusion - https://phabricator.wikimedia.org/T141965#2518221 (10Paladox) [08:53:09] 05Gitblit-Deprecate, 06Project-Admins: Archive #Gitblit-Deprecate - https://phabricator.wikimedia.org/T138986#2518220 (10Paladox) [11:10:54] 10Phabricator, 06Operations, 07Documentation: Create an offboarding workflow with HR & Operations - https://phabricator.wikimedia.org/T108131#2518585 (10mark) 05Open>03Resolved [12:06:15] qchris__ im wondering if https://phabricator.wikimedia.org/T141329 is an acutal bug? [12:06:29] Since it works through ssh and http but not through gerrit inline editing [12:06:48] I filled https://bugs.chromium.org/p/gerrit/issues/detail?id=4324 [12:16:29] If I am not mistaken, grrrit-wm reports a commit's author, not a commit's committer. As Gerrit's inline editing of a commit makes you the commit's committer (not the commit's author), I'd say it's expected behaviour. [12:17:05] Oh [12:17:22] qchris__ do you know what code i use to get the committer plase [12:17:24] please [12:17:28] since it works for ssh and http [12:17:37] even if you upload over someone elses patch [12:18:00] With ssh and http, you're using git to upload. That's different :-) [12:18:01] We do https://phabricator.wikimedia.org/diffusion/TGRT/browse/master/src/preprocess.js;5fcea169b71fe0048219d6c6a8646160d19415b8$34 [12:18:05] Oh [12:18:11] About getting the comitter .. you mean in grrrit? [12:18:14] (the bot) [12:18:14] Yep [12:18:19] yes please [12:18:39] I never looked at that code :-) I guess it's better to sync up with whoever is maintaining grrrit. [12:18:54] Oh [12:18:56] Looking at it: I see things like [12:18:58] message.patchSet.author.name [12:19:01] Yep [12:19:04] So I assume: [12:19:07] message.patchSet.comitter.name [12:19:12] may do the trick. [12:19:13] Oh thanks [12:19:16] I will try that now [12:19:17] message.patchSet.committer.name [12:19:18] :) [12:19:26] oh [12:19:31] thanks [12:22:17] qchris__ nope it causes the bot to restart itself [12:23:22] Then look at the object that gerrit is returning. [12:23:27] Ok [12:23:32] Typically, they expose both the author and the committer. [12:23:39] oh [12:27:06] user: message.patchSet.committer.name, [12:27:06] ^ [12:27:06] TypeError: Cannot read property 'name' of undefined [12:27:10] qchris__ ^^ [12:28:29] As said above: I'd look at the data object returned by gerrit. That should show you the available properties. [12:28:37] Uep [12:28:39] Yep [12:28:43] how do i do that please? [12:29:15] Run the stream-events command againt a gerrit server. [12:29:26] (using ssh) [12:29:33] Oh [12:29:36] That should expose all the fields that are there. [12:29:50] I doint think i can do that, but i will try that on another test server i have [12:29:51] :) [12:30:03] Yes, a test-server is fine for that. [12:30:06] Ok [12:32:09] Looking at the gerrit code, it looks like message.patchSet may be PatchSetAttribute object. [12:32:23] You should see `author` and `uploader` sub-objects. [12:32:37] Oh [12:32:41] so it's message.patchSet.uploader.name [12:32:45] Oh thanks [12:32:46] (I guess) [12:32:51] Ill try that [12:32:55] :) [12:33:19] qchris__ oh i already tryed that [12:33:23] and that didnt work [12:33:28] https://gerrit.wikimedia.org/r/#/c/302416/3..4/src/preprocess.js [12:34:12] Then check stream-events (against a test-server), and see what is there. [12:34:36] Also you may want to check if grrrit (the bot) is exposing all that Gerrit exposes. [12:35:01] ok [12:36:39] Clicking the above link :-D [12:36:44] uploader was there in first place. [12:36:57] So you /changed/ /to/ author. [12:37:19] Nope, that is a comparision from between patch 3 and 4 [12:37:28] i prevously had message.uploader.name [12:38:02] Ah. True :-) [12:38:14] But note that I suggested message.patchSet.uploader.name [12:38:23] That is different from message.uploader.name [12:38:32] (it has an additional ".patchSet") [12:38:34] Aaaaaanyways. [12:38:40] Look at stream-events. [12:38:46] That's the best source there is. [12:39:09] Yep [12:39:14] i tryed that but failed [13:16:23] https://phabricator.wikimedia.org/P3630 [13:16:26] qchris__ ^^ [13:19:06] So if I am not mistaken, the first line has a patchSet.uploader.name :-) [13:19:41] Oh [13:19:46] So that should work [13:19:48] but it fails [13:19:49] ? [13:20:03] Unless it is fixed in gerrit 2.12.3 but broken in gerrit 2.12.2 [13:21:19] fails as in it still says the wrong [13:21:21] user edited [13:21:25] the patch [13:24:12] It still does [13:24:12]

(PS21) Chad: Logstash: Enable log4j provider [puppet] - https://gerrit.wikimedia.org/r/302601 [13:24:25] even though i did that [13:26:14] qchris__ maybe message.author.name ? [13:27:59] Oh wait i tryed that [13:28:02] and that also broke it [13:34:47] paladox: If you've tried the same Gerrit version that's running in production, then you verified that the needed properties are exposed by gerrit. So I'd go and check the grrrit sources to see what's arriving there, and how gerrit's data objects get processed. [13:35:01] Oh ok [13:35:26] I'll be away for the next few hours, but I'll read up the logs later on, just in case ;-) [13:35:38] ok [13:55:21] qchris___away i left more info at https://phabricator.wikimedia.org/P3630 [13:57:46] patchset-created seems to use the owner in the gerrit inline edit [13:57:53] and not the current user who edits it [14:05:08] qchris___away deffintly seems like a bug since line 17 in that paste was me who did it and not the jenkins bot [14:05:13] yet it has no mention of me [15:51:36] qchris___away seems someone uploaded a patch to fix this [15:51:37] https://bugs.chromium.org/p/gerrit/issues/detail?id=4324&can=2&start=0&num=100&q=&colspec=ID%20Type%20Stars%20Milestone%20Status%20Priority%20Owner%20Summary&groupby=&sort= [15:51:46] https://gerrit-review.googlesource.com/#/c/80830/ [15:51:47] :) [16:38:33] qchris___away This https://gerrit-review.googlesource.com/#/c/80830/ deffintly fixes it, now gets the correct author and gets owner too [17:19:28] The Phabricator pages for extensions all say that you can use a URL like "ssh://vcs@git-ssh.wikimedia.org/diffusion/ESFO/extension-semanticforms.git". [17:19:40] But when I call "git clone" on that, it displays this error message: "ssh: connect to host git-ssh.wikimedia.org port 7822: Network is unreachable". [17:19:54] (Other people have gotten different errors, apparently.) [17:20:28] Is something down right now? [17:21:46] Yaron, hi it works for me [17:22:00] you need to have your ssh key in your account [17:22:14] $ git clone ssh://vcs@git-ssh.wikimedia.org/diffusion/ESFO/extension-semanticforms.git [17:22:14] Cloning into 'extension-semanticforms'... [17:22:19] Yaron: port 7822 sounds off [17:23:12] Yaron: then if you get Permission denied (publickey,keyboard-interactive), you need to set up your ssh key as paladox suggested [17:23:23] Yep [17:25:06] paladox: valhallasw`cloud: thank you, I'll try that. [17:25:26] Ok, your welcome. [17:26:52] How do I configure the port number, by the way? I'm assuming that it's using port 7822 because I'm using port 7822 to SSH into the server that I'm calling this from. [17:27:06] i.e., it considers that the default port. [17:27:47] Yaron: ~/.ssh/config [17:28:23] Yaron: or possibly /etc/ssh/ssh_config if it's some global option on that server [17:28:54] ....actually, that might be what's happening. A misconfiguration where a clause 'Port 7822' was added to both sshd_config /and/ ssh_config [17:29:23] anyway; a line Port 22 in ~/.ssh/config should work [17:29:24] Aha, yes - I have only /etc/ssh/ssh_config, where it's set to 7822. [17:29:37] I'll create the personal config file. [17:31:22] Okay, I did that, and now calling the "git clone" leads to this error message: "Permission denied (publickey,keyboard-interactive)". [17:31:46] I guess this is what I need to create the SSH key for? [17:33:19] It's strange, because I already have an SSH key - that's how I've doing all the SSH Git stuff until now. [17:33:49] Yep [17:33:55] You need to add it in phabricator [17:33:56] is it in Phabricator? https://phabricator.wikimedia.org/settings/user/greg/page/ssh/ (replace "greg" with your pahb username) [17:34:19] Aha! [17:34:54] No, I have no public keys added. [17:37:43] Yay, now it works! [17:38:02] Thanks, paladox, greg-g and valhallasw`cloud . [17:38:15] Your welcome [18:18:32] Well, two steps forward and one step back: I have the Git repository set up now, but I can't call "git review" - it gives me the following error: "Exception: Could not connect to gerrit at ssh://yaron@gerrit.wikimedia.org:29418". [18:18:39] Is that port again incorrect? [18:20:02] port is correct [18:24:15] Could it be that I need to change my developer username from "yaron" to "Yaron_Koren"? [18:24:34] "yaron" was what I used before, but on Phabricator it's "Yaron_Koren". [18:27:55] make sure you have an ssh key in gerrit, too: https://www.mediawiki.org/wiki/Gerrit/Tutorial#Add_SSH_key_to_your_Gerrit_account [18:30:05] greg-g: that one I have already - I just checked again. [20:33:28] paladox: Yay for the author/uploader fix! \o/ [20:33:39] Yep :) [20:34:10] qchris__ now it seems we having https://phabricator.wikimedia.org/T141448 that problem [21:01:36] paladox: I chimed in on the task. [21:01:55] Ok thanks [21:13:24] 05Gitblit-Deprecate, 06Project-Admins: Archive #Gitblit-Deprecate - https://phabricator.wikimedia.org/T138986#2520663 (10Danny_B) 05stalled>03Open No need to set stalled status to tasks which depend on subtasks which are open. [22:10:07] qchris__ hi could you for https://phabricator.wikimedia.org/T141448 upload the patch also upstream [22:10:11] for its-phabricator [22:10:12] please [22:10:18] so it isent reverted in future [22:10:19] thanks [22:10:24] I could push-for-review upstream too :) [22:13:09] Oh [22:13:11] yes please [22:13:14] :) [22:14:56] ostriches by upstream do you mean the its-phabricator [22:15:01] in review-gerrit [22:29:03] paladox: Sure. It should be upstreamed. I just never came around to do it, as we've been stuck on an incompatible version. But if it's rebase on master and still works. Sure, send it upstream. [22:29:15] Oh [22:29:18] Yep [22:29:24] qchris__ ostriches rebased it for you [22:29:29] ontop of gerrit 2.12.3 [22:30:11] And he even built it. So if you could run it on a testinstance and check if it's working, that'd be great. [22:30:14] Yep [22:30:18] Ok [22:30:21] i will do that now [22:30:31] I carnt test if it will write on phabricator [22:30:38] since it keeps failing for me with token error [22:31:08] You can write against the test phabricator instance. [22:31:29] I carn't it fails with token error [22:31:38] (You can add a new user there, get the token for it, and use that token for its-phabricator) [22:31:55] ^ will help you with the token error ;-) [22:33:07] Yep [22:33:09] I did [22:33:11] but failed [22:33:39] Its upstream too [22:33:40] https://gerrit-review.googlesource.com/#/c/80880/ [22:35:40] Mhmmm. That's how I had tested things in the past ... I guess I'll have to find a different means to test then. I'll look at on the weekend. [22:37:50] Oh [22:37:55] I mean it failed for me [22:38:01] but should work if you know how to [22:39:31] Caused by: com.googlesource.gerrit.plugins.its.phabricator.conduit.ConduitErrorException: Method 'conduit.connect' gave: ERR-INVALID-CERTIFICATE, Your authentication certificate for this server is invalid. [22:40:31] It's been a while since I run it. I'll have to look into it again. I can do so on the weekend. [22:40:43] Ok [22:40:44] thanks [22:41:02] could you also review https://gerrit-review.googlesource.com/#/c/80880/ too please [22:41:05] at the weekend [22:41:06] :) [22:42:16] If you need it today, or tomorrow, I'd say that there is not so much risk in trying to test the new jar in production. Gerrit can load/unload them at runtime. So there should not be downtime. If the plugin fails/dies, its-phabricator is not working for 5 minutes or so, while you roll-back. [22:42:34] But if it's pressing, that should be an acceptable risk. [22:42:43] I expect that it just goes fine. [22:42:59] Oh yep [22:43:00] (And if it fails, the plugin is not working. Gerrit is up and usable just fine) [22:43:11] ostriches ^^ could we test the plugin in production please?