[03:15:43] Gerrit is down? [03:15:58] According to the channel topic. [03:24:40] Ursula, was. back now. [11:29:55] Hello, anyone with GitHub WM repository access? We are dealing with several issues and noone wants to help us in Pywikibot [11:30:44] ? [11:33:48] GitHub repository for Pywikibot was renamed recently and since that time we are dealing with multiple issues where WM GitHub access is needed, but noone from us has it. See [[phab:T186206]] for more details and its subtasks [11:33:48] T186206: Misleaded tests and maintenance pages after renaming of github repository (tracking) - https://phabricator.wikimedia.org/T186206 [11:39:49] We have to fork wikimedia/pywikibot to username/pywikibot and make our tests on our own forks, which is much more difficult [11:43:14] I'm not sure, why the repository was renamed, but for the trouble afterwards, all the people from [[phab:tag/GitHub-Mirrors]], [[phab:tag/Repository-Admins]], [[phab:tag/Release-Engineering-Team]] or [[phab:tag/Continuous-Integration-Config]] are completely silent and unresponsive [11:43:55] The hooks on that repo look to be a mess [11:44:08] You've got at least 3 to https://ci.appveyor.com/api/github/webhook [11:46:50] There should be only 2 for Travis and AppVeyor, one for Magul's quick test and one for regular post-build test. And just 1 hook for each Codeclimate and Codecov [11:47:33] Codecov and travis are setup as "installed github apps" [11:47:48] Yes, they are working fine [11:48:02] There's still 6 webhooks (I deleted two of the failing appveyor ones because 1 was passing) [11:48:05] But AppVeyor and Codeclimate are not working as supposed [11:48:40] One of the appveyor ones is [11:48:58] All of those after github.com/wikimedia/pywikibot-core renamed to github.com/wikimedia/pywikibot [11:49:08] Is there public logs for that one? [11:49:17] I've no idea [11:49:39] It's unclear how to map the id to anything useable on appveyor [11:50:16] scrutinizer-ci and whatever shippable is are also failing [11:51:30] Maybe these two services not working properly should be switched from hooks to GH installed apps like Travis and Codecov? [11:52:13] I dunno if there's apps for them all [11:52:24] Shippable: "Project not found for projectId: 540e7c1e3479c5ea8f9ec97b" [11:53:29] Dunno too [11:53:38] scrutinizer An Error Occurred: Not Found [11:56:42] Lego, Amir and jayvdb all have admin access on the repos... They would be best placed to fix this stuff probably [11:58:04] Amir and Jayvdb stepped away from Pwb and don't want to have much in common with the project as they both don't like each other. So I think Lego could help [12:00:44] But he is also not much active [12:01:46] has anyone filed a phab task yet? [12:01:55] Ahh and here we go again. All the guys from Pywikibot's early years are gone and the current devs have no access to project settings, services and other stuff [12:02:07] https://phabricator.wikimedia.org/T186206 [12:02:33] Maybe just file a task requesting GitHub access for a specific list of accounts [12:02:40] Then you can fix it yourselves [12:03:35] That seems much more sensible than trying to get other people to fix it for you [12:06:26] I see, this idea never crossed my mind. Let's make it happen. But what Phab project should I ask when the 4 mentioned above were not responding to current tasks? [12:06:56] Dunno.. I can make it happen, but I want an audit trail of the request etc [12:07:04] Repo-Admins and GitHub-Mirrors? [12:07:23] Github-Mirrors is the relevant tag for the wikimedia org on github, i believe the previous access requests have been under there as well [12:08:21] Once the request is filed, notifying the pywikibot list wouldn't harm either. It looks like it's not drowning in traffic anyway. [12:09:33] I once tried to leave an email in Pywikibt's list, but with no success (I think I ended in some too strict spam filter?) [12:09:44] I'm preparing the task [12:22:53] See https://phabricator.wikimedia.org/T196810 [12:38:52] Dvorapa: did you subscribe in the first place? [12:39:20] Is that needed? [12:40:03] Well, it is not high traffic, so it should be ok for me to subscribe, but I thought any one from outside can also write to the list? [12:41:24] Mailing lists usually require subscription [12:49:51] Who could I add to subscribers of that task who could help with that? [12:54:28] Dvorapa: the relevant people will probably already watch the projects and will get alerts about the task already [12:57:19] p858snake|L: Hopefully yes, but as I said earlier, the tasks to those projects from Pywikibot have no activity from their side. [12:58:39] and? the morjoraity of that task has nothing to do with pywikibot, its to do with those that have access to the github org to add other users [13:14:53] Reedy: I created the task, but now after Dalba's comment on that task I'm not sure if anyone of us can understand or fix the hooks there. I can do basic stuff from GitHub.com settings page, but probebly only the basic stuff. Hopefully and obviously we want just to make those services run correctly as before that repository rename. And Magul's quick [13:14:53] test, but that would not be easy as noone from us really understands, how it worked (it just worked). Magul is also inactive and inaccessible these days [13:15:23] None of it is complex [13:15:29] It's pretty straight forward [13:18:41] Ok then, I'll trust you in this :) [17:43:46] hello [17:44:35] oh looks like Amir beat me to it [19:21:01] Hello, I'm working on T196749. I downloaded all the files that are to be imported into id.wikimedia.org to a directory on Toolforge. It's ~120 MBs together (including descriptions), split to ~28k files. Should I proceed with my original plan (give it a publicly accessible URL and ask for a server side upload) or should I rather upload it using API? [19:21:01] T196749: Server-side upload ~20k images to idwikimedia - https://phabricator.wikimedia.org/T196749 [20:49:32] Urbanecm, normal upload is preferred where possible [22:42:43] how would one mark all edits as minor via js for ve/the new wikitext editor? [22:57:34] Lith, *all* edits as minor? [22:57:40] yep [22:57:51] why would you do that? [22:58:22] because all, if not most, of my edits are minor edits [22:58:44] so basically you want that to be checked by default? [22:58:48] yep [22:59:28] minor edits are a fallacy [23:02:31] Lith, it looks like VE respects the minordefault user preference [23:02:38] is that not sufficient? [23:02:50] nope because of https://phabricator.wikimedia.org/source/mediawiki-config/browse/master/wmf-config/CommonSettings.php$1213 [23:03:29] lol [23:03:38] sounds like your wiki bans what you are suggesting then [23:07:03] nah, they just don't want people setting the option [23:07:07] https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=373611341#Preference_to_mark_all_edits_minor_by_default_asked_to_be_removed_in_bugzilla:24313 for example [23:08:07] tried to get around it with the API [23:08:15] {warnings: "Validation error for "minordefault": not a valid preference."} [23:09:31] Lith, I take it you already figured out how to set the checkbox by default in the traditional editors [23:09:34] using JS [23:10:33] ye [23:12:15] it's definitely possible just a pain and there's no stable API for doing it [23:13:58] ye, I poked around a bit with inspect element and ended up with `document.getElementById('ooui-1').checked = true;`, but that won't work by itself as the edit button is now in a popup modal, so it thinks the element doesn't exist [23:14:59] well it doesn't [23:15:20] and I'm not sure that would work anyway [23:16:28] huh, it works for me if I use the line of js after the minor edit checkbox is on the screen [23:21:36] yeah I dunno if that behaviour is guaranteed [23:36:30] Lith, okay [23:37:34] https://phabricator.wikimedia.org/P7233 [23:37:40] Lith, try that [23:38:07] that has the VE client ignore what the server thinks the wpMinoredit default should be and set it to true [23:39:56] it pretty much injects its code into VE [23:40:32] by overriding the target creation to allow it to override how the target handles the response from the server [23:41:19] looks like its throwing an error, "JavaScript parse error: Parse error: Unexpected token; token 3 expected in file 'User:TerraCodes/common.js' on line 19" [23:41:22] it may break in some cases, or if they change too much about how the loading mechanism works in VE [23:41:45] also it looks like VE has a hook for when the save modal comes up? [23:42:18] so that might easier to use [23:43:44] Lith, maybe try changing .default to ['default'] [23:43:53] it worked when I pasted it into console [23:44:12] Lith, maybe but I've done it now. plus it's probably better to intercept the default at our first opportunity [23:45:44] stop any other VE code seeing what the server said [23:45:53] ah [23:46:02] also changing .default to ['default'] worked [23:49:07] thanks~ [23:49:22] default is a JS keyword [23:49:27] so I wonder why that worked in console actually [23:49:46] maybe Krinkle would know