[00:00:13] nice debugging work on that too. I feel like I always learn things from seeing your work with gdb. [00:11:52] thanks. Next step, a proper workaround in excimer, is looking like it will be complicated [00:12:22] upstream patch is probably simpler but we will need a workaround for the next 15 years or so, until the new glibc filters down to everyone [01:19:24] (03open) 10swfrench: mediawiki-deployments.yaml: remove debug: true [repos/releng/train-dev] - 10https://gitlab.wikimedia.org/repos/releng/train-dev/-/merge_requests/128 (https://phabricator.wikimedia.org/T389499) [01:54:00] 10Continuous-Integration-Config, 10Math, 10MediaWiki-Platform-Team (Radar), 10MW-1.44-notes (1.44.0-wmf.24; 2025-04-08), 13Patch-For-Review: Allow control over which extra extensions are installed (Math REL1_43 jobs exceed 60min timeout) - https://phabricator.wikimedia.org/T389998#10706514 (10Krinkle) >>... [02:05:24] TimStarling: Why is it that Scribunto is the likely cause as opposed to the critical section callbacks created via Excimer? Theres a jump there I didn't quite get, but I do have a guesses: The critical sections, while short, are long enough (even at ~1ms for a db query) to not trigger the bug? If LuaSandbox creats/destoys a time super quickly earlier in the request, the critical section is a visible "next" victim to receive a re-used [02:05:24] timer ID and thus affected. If true, this would mean Lua is likely affected too, but much less visibly I guess since that doesn't cause fatals when timers fire too soon. Worst case luasandbox may fire fatals when fired too late. [02:08:21] the bug occurs when a timer event is actually sent. Timers set for 180s are unlikely to actually expire. Lua profiling timers are set for 20ms so have a fair probability of actually firing [02:11:22] The bug occurs when a timer event is in flight when the timer is deleted. A new timer is created with the same address. The in-flight event is then delivered to the new timer [02:11:46] If the new timer were a LuaSandbox profiling timer, no big deal. If it's a critical section timer, we see an exception [02:27:52] TimStarling: hm.. I see, so we have: 1) Lua creates a new timer, 2) The 20ms timer is reached and sent to LuaSandbox, 3) Lua deletes its side of the timer so it won't get delivered, 4) MW starts timeout for a critical section, gets given the same ID, which is then immediately delivered from #2. [02:30:07] yes [02:33:32] the reused ID here is the timer_t allocated by glibc, it is a pointer returned by malloc(), shifted right one bit [02:34:11] the kernel IDs are apparently not reused, but glibc doesn't check them [09:31:38] Yippee, build fixed! [09:31:38] Project beta-update-databases-eqiad build #83725: 09FIXED in 11 min: https://integration.wikimedia.org/ci/job/beta-update-databases-eqiad/83725/ [09:53:45] (03merge) 10cgoubert: mediawiki-cli: Add moreutils [repos/releng/release] - 10https://gitlab.wikimedia.org/repos/releng/release/-/merge_requests/158 (https://phabricator.wikimedia.org/T388538) [10:23:27] (03update) 10btullis: Add data-engineering/refinery to the trusted runners [repos/releng/gitlab-trusted-runner] - 10https://gitlab.wikimedia.org/repos/releng/gitlab-trusted-runner/-/merge_requests/104 (https://phabricator.wikimedia.org/T383417) [10:29:28] (03update) 10btullis: Add data-engineering/refinery to the trusted runners [repos/releng/gitlab-trusted-runner] - 10https://gitlab.wikimedia.org/repos/releng/gitlab-trusted-runner/-/merge_requests/104 (https://phabricator.wikimedia.org/T352650 https://phabricator.wikimedia.org/T383417 https://phabricator.wikimedia.org/T390736) [10:30:57] (03update) 10btullis: Add data-engineering/refinery to the trusted runners [repos/releng/gitlab-trusted-runner] - 10https://gitlab.wikimedia.org/repos/releng/gitlab-trusted-runner/-/merge_requests/104 (https://phabricator.wikimedia.org/T383417) [10:31:20] (03open) 10btullis: Add data-engineering/refinery to the trusted runners [repos/releng/gitlab-trusted-runner] - 10https://gitlab.wikimedia.org/repos/releng/gitlab-trusted-runner/-/merge_requests/111 (https://phabricator.wikimedia.org/T352650 https://phabricator.wikimedia.org/T383417 https://phabricator.wikimedia.org/T390736) [10:39:38] (03update) 10btullis: Add data-engineering/refinery to the trusted runners [repos/releng/gitlab-trusted-runner] - 10https://gitlab.wikimedia.org/repos/releng/gitlab-trusted-runner/-/merge_requests/111 (https://phabricator.wikimedia.org/T352650 https://phabricator.wikimedia.org/T383417 https://phabricator.wikimedia.org/T390736) [10:40:44] (03update) 10btullis: Add data-engineering/sync-utils to the trusted runners [repos/releng/gitlab-trusted-runner] - 10https://gitlab.wikimedia.org/repos/releng/gitlab-trusted-runner/-/merge_requests/111 (https://phabricator.wikimedia.org/T352650 https://phabricator.wikimedia.org/T390736) [10:45:36] 10Release-Engineering-Team (Radar), 10Scap (SpiderPig 🕸️), 06Infrastructure-Foundations, 07LDAP: Create 'spiderpig-access' ldap group - https://phabricator.wikimedia.org/T390338#10707294 (10MoritzMuehlenhoff) 05Open→03Resolved I've created the spiderpig-access LDAP group with me as the initial grou... [11:00:57] 10GitLab (CI & Job Runners), 06Release-Engineering-Team, 06collaboration-services: GitLab Runner job logs are truncated - https://phabricator.wikimedia.org/T390816#10707341 (10Jelto) 05Open→03Resolved All Runners (Trusted, Shared and Cloud Runners) are using a bigger limit of 20MB job log now. I tri... [11:42:44] (03PS1) 10Phuedx: layout.yaml: Publish MetricsPlatform JavaScript docs [integration/config] - 10https://gerrit.wikimedia.org/r/1133877 [11:43:48] (03PS2) 10Phuedx: Zuul: [mediawiki/extensions/MetricsPlatform] Publish JS docs [integration/config] - 10https://gerrit.wikimedia.org/r/1133877 [12:37:26] \o Hey, what's the correct approach to have a new team members's Github account added to the WMF org? [12:51:31] 06Project-Admins, 06MW-Interfaces-Team, 10WMF-JobQueue, 07Documentation: WMF-JobQueue Phabricator project description is out of date - https://phabricator.wikimedia.org/T380543#10707727 (10HCoplin-WMF) 05Open→03Resolved a:03HCoplin-WMF Closing; these edits are fine. [13:25:08] Bleh. [13:28:35] (03PS1) 10Jforrester: Docker: [quibble-bullseye] Revert MardiaDB to 10.5, Wikimedia package lacks mysql_install_db [integration/config] - 10https://gerrit.wikimedia.org/r/1133912 (https://phabricator.wikimedia.org/T366646) [13:28:48] (03CR) 10Jforrester: [C:03+2] Docker: [quibble-bullseye] Revert MardiaDB to 10.5, Wikimedia package lacks mysql_install_db [integration/config] - 10https://gerrit.wikimedia.org/r/1133912 (https://phabricator.wikimedia.org/T366646) (owner: 10Jforrester) [13:29:01] (03Abandoned) 10Jforrester: jjb: Upgrade quibble bullseye jobs to MariaDB 10.6 [integration/config] - 10https://gerrit.wikimedia.org/r/1133903 (https://phabricator.wikimedia.org/T366646) (owner: 10Jforrester) [13:29:49] (03CR) 10CI reject: [V:04-1] Docker: [quibble-bullseye] Revert MardiaDB to 10.5, Wikimedia package lacks mysql_install_db [integration/config] - 10https://gerrit.wikimedia.org/r/1133912 (https://phabricator.wikimedia.org/T366646) (owner: 10Jforrester) [13:30:58] (03PS2) 10Jforrester: Docker: [quibble-bullseye] Revert MardiaDB to 10.5 [integration/config] - 10https://gerrit.wikimedia.org/r/1133912 (https://phabricator.wikimedia.org/T366646) [13:31:03] (03CR) 10Jforrester: "…" [integration/config] - 10https://gerrit.wikimedia.org/r/1133912 (https://phabricator.wikimedia.org/T366646) (owner: 10Jforrester) [13:32:48] (03Merged) 10jenkins-bot: Docker: [quibble-bullseye] Revert MardiaDB to 10.5 [integration/config] - 10https://gerrit.wikimedia.org/r/1133912 (https://phabricator.wikimedia.org/T366646) (owner: 10Jforrester) [13:33:15] !log Docker: [quibble-bullseye] Revert MardiaDB to 10.5, for (against) T366646 [13:33:18] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [13:33:18] T366646: Raise Quibble jobs' tested version of MariaDB to 10.6 - https://phabricator.wikimedia.org/T366646 [13:53:34] 10Scap, 06Data-Platform-SRE, 10Wikidata, 10Wikidata-Query-Service, 10Discovery-Search (2025.03.22 - 2025.04.11): scap service restarts for WDQS are inconsistent - https://phabricator.wikimedia.org/T221709#10708049 (10dcausse) [13:54:02] 10Scap, 06Data-Platform-SRE, 10Wikidata, 10Wikidata-Query-Service, 10Discovery-Search (2025.03.22 - 2025.04.11): scap service restarts for WDQS are inconsistent - https://phabricator.wikimedia.org/T221709#10708052 (10dcausse) a:03dcausse [13:58:31] (03PS2) 10Atieno: Zuul: Configure the REL1_44 test and gate pipelines [integration/config] - 10https://gerrit.wikimedia.org/r/1133403 (https://phabricator.wikimedia.org/T390695) [13:58:37] (03PS1) 10Jforrester: jjb: Upgrade Quibble bullseye jobs to latest (no-op) [integration/config] - 10https://gerrit.wikimedia.org/r/1133920 [13:58:42] (03CR) 10Atieno: Zuul: Configure the REL1_44 test and gate pipelines (032 comments) [integration/config] - 10https://gerrit.wikimedia.org/r/1133403 (https://phabricator.wikimedia.org/T390695) (owner: 10Atieno) [14:01:06] (03CR) 10CI reject: [V:04-1] Zuul: Configure the REL1_44 test and gate pipelines [integration/config] - 10https://gerrit.wikimedia.org/r/1133403 (https://phabricator.wikimedia.org/T390695) (owner: 10Atieno) [14:18:40] 10Continuous-Integration-Config, 10ci-test-error (WMF-deployed Build Failure), 05MW-1.42-release, 05MW-1.43-release: quibble-composer-mysql-php8[23] fail since 31/3 - https://phabricator.wikimedia.org/T390754#10708155 (10SLopes-WMF) [14:26:09] (03approved) 10damilare: Add wmf-cv wrapper script to CiviCRM Docker image [repos/releng/dev-images] - 10https://gitlab.wikimedia.org/repos/releng/dev-images/-/merge_requests/74 (https://phabricator.wikimedia.org/T383097) (owner: 10jgleeson) [14:26:20] (03merge) 10damilare: Add wmf-cv wrapper script to CiviCRM Docker image [repos/releng/dev-images] - 10https://gitlab.wikimedia.org/repos/releng/dev-images/-/merge_requests/74 (https://phabricator.wikimedia.org/T383097) (owner: 10jgleeson) [14:43:34] (03merge) 10dancy: Add data-engineering/sync-utils to the trusted runners [repos/releng/gitlab-trusted-runner] - 10https://gitlab.wikimedia.org/repos/releng/gitlab-trusted-runner/-/merge_requests/111 (https://phabricator.wikimedia.org/T352650 https://phabricator.wikimedia.org/T390736) (owner: 10btullis) [14:49:53] (03PS3) 10Jforrester: Zuul: Configure the REL1_44 test and gate pipelines [integration/config] - 10https://gerrit.wikimedia.org/r/1133403 (https://phabricator.wikimedia.org/T390695) (owner: 10Atieno) [14:50:41] (03PS4) 10Jforrester: Zuul: Configure the REL1_44 test and gate pipelines [integration/config] - 10https://gerrit.wikimedia.org/r/1133403 (https://phabricator.wikimedia.org/T390695) (owner: 10Atieno) [14:52:52] (03CR) 10Jforrester: [C:03+2] Zuul: Configure the REL1_44 test and gate pipelines (032 comments) [integration/config] - 10https://gerrit.wikimedia.org/r/1133403 (https://phabricator.wikimedia.org/T390695) (owner: 10Atieno) [14:54:15] (03Merged) 10jenkins-bot: Zuul: Configure the REL1_44 test and gate pipelines [integration/config] - 10https://gerrit.wikimedia.org/r/1133403 (https://phabricator.wikimedia.org/T390695) (owner: 10Atieno) [15:06:38] !log Zuul: Configure the REL1_44 test and gate pipelines, for T390695 [15:06:40] Logged the message at https://wikitech.wikimedia.org/wiki/Release_Engineering/SAL [15:06:40] T390695: Configure CI to support REL1_44 - https://phabricator.wikimedia.org/T390695 [15:07:17] 10Continuous-Integration-Config, 10MediaWiki-Releasing, 05MW-1.44-release, 13Patch-For-Review: Configure CI to support REL1_44 - https://phabricator.wikimedia.org/T390695#10708465 (10Jdforrester-WMF) 05Open→03Resolved [15:24:44] klausman: I think "ask an org owner" is the only process for github still. https://github.com/orgs/wikimedia/people?query=role%3Aowner [15:25:17] * bd808 is an @wikimedia org owner for example [15:26:02] 10Continuous-Integration-Infrastructure, 07Jenkins, 07SecTeam-Processed, 07Security, 05Vuln-VulnComponent: Jenkins security advisory 2025-04-02 - https://phabricator.wikimedia.org/T390926#10708723 (10sbassett) [15:26:05] 10Continuous-Integration-Infrastructure, 07Jenkins, 07SecTeam-Processed, 07Security, 05Vuln-VulnComponent: Jenkins security advisory 2025-04-02 - https://phabricator.wikimedia.org/T390926#10708725 (10sbassett) p:05Triage→03Medium [15:26:30] 10Continuous-Integration-Infrastructure, 07Jenkins, 07SecTeam-Processed, 07Security, 05Vuln-VulnComponent: Jenkins security advisory 2025-04-02 - https://phabricator.wikimedia.org/T390926#10708740 (10sbassett) a:03hashar [15:26:31] In this case, it would be https://github.com/omkarakaya, Özge Karakaya, who started on Tuesday [15:31:39] 10Beta-Cluster-Infrastructure: deployment-acme-chief0{5,6} puppet failures for 'profile::opensearch::cirrus::enable_remote_search' - https://phabricator.wikimedia.org/T390128#10708801 (10bd808) 05Open→03Resolved a:03bd808 [15:35:06] 10Continuous-Integration-Config: Using an invalid dblist in InitializeSettings.php should cause a CI error - https://phabricator.wikimedia.org/T390988 (10Tgr) 03NEW [15:38:03] 10Gerrit, 07Upstream: Gerrit allows merging the same patch twice - https://phabricator.wikimedia.org/T355080#10708916 (10hashar) Another case is https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1131960/1 That was already submitted as https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1132105 Rebasing it... [15:39:10] Yippee, build fixed! [15:39:10] Project mediawiki-core-phpmetrics build #350: 09FIXED in 5 min 9 sec: https://integration.wikimedia.org/ci/job/mediawiki-core-phpmetrics/350/ [15:58:12] 10Phabricator: Please deactivate this account - https://phabricator.wikimedia.org/T390997#10709080 (10Zabe) 05Open→03Resolved a:03Zabe [16:33:39] 10Phabricator, 06Release-Engineering-Team, 06collaboration-services, 06DBA: Prepare a database test for m3 - https://phabricator.wikimedia.org/T390034#10709288 (10brennen) I think we could test running the upgrade from `phab2002` (the backup server), and yeah I think we'd just run the migration by hand fro... [16:48:58] https://lore.kernel.org/git/CAESOdVAspxUJKGAA58i0tvks4ZOfoGf1Aa5gPr0FXzdcywqUUw@mail.gmail.com/T/#u [16:49:11] 10Scap (SpiderPig 🕸️), 10logspam-watch, 10observability: Add a log view to SpiderPig - https://phabricator.wikimedia.org/T391005 (10brennen) 03NEW [16:49:24] 06Release-Engineering-Team, 10Scap (SpiderPig 🕸️), 10logspam-watch, 10observability: Add a log view to SpiderPig - https://phabricator.wikimedia.org/T391005#10709359 (10brennen) [16:53:16] (03open) 10dancy: Refactor exception handler code in cli.py and main.py [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/737 [16:53:18] (03update) 10dancy: Refactor exception handler code in cli.py and main.py [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/737 [16:58:47] (03update) 10dancy: Refactor exception handler code in cli.py and main.py [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/737 [17:09:21] 10Continuous-Integration-Config: Reconcile dependencies.yaml and phan_dependencies.yaml - https://phabricator.wikimedia.org/T391008 (10Daimona) 03NEW [17:09:51] 10Continuous-Integration-Config: Reconcile dependencies.yaml and phan_dependencies.yaml - https://phabricator.wikimedia.org/T391008#10709460 (10Daimona) [17:09:56] 10Continuous-Integration-Config, 10Math, 10MediaWiki-Platform-Team (Radar), 10MW-1.44-notes (1.44.0-wmf.24; 2025-04-08), 13Patch-For-Review: Allow control over which extra extensions are installed (Math REL1_43 jobs exceed 60min timeout) - https://phabricator.wikimedia.org/T389998#10709461 (10Daimona) [17:12:27] 10Continuous-Integration-Config, 10Math, 10MediaWiki-Platform-Team (Radar), 10MW-1.44-notes (1.44.0-wmf.24; 2025-04-08), 13Patch-For-Review: Allow control over which extra extensions are installed (Math REL1_43 jobs exceed 60min timeout) - https://phabricator.wikimedia.org/T389998#10709464 (10Daimona) >>... [17:13:37] It's time for me to confess that I don't understand a thing about how LibUp works. Does someone know why it's not pushing this patch? https://libraryupgrader2.wmcloud.org/r/mediawiki/extensions/VisualEditor [17:14:29] Everything seems to be fine from the logs, yet it's not pushing it. Would it make sense to add something to the logs explaining what happens (or does not happen) next? [17:14:42] (03merge) 10dancy: spiderpig: Render progress reports [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/730 [17:14:44] (03update) 10dancy: JobCard.vue: Use font-weight: bold for the job status [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/736 (https://phabricator.wikimedia.org/T383835) [17:15:20] (03merge) 10dancy: JobCard.vue: Use font-weight: bold for the job status [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/736 (https://phabricator.wikimedia.org/T383835) [17:15:24] And that's not even getting into the more common scenarios of it encountering errors when bumping dependencies, which sometimes result in the patch being created and sometimes they don't. [17:16:35] Daimona: taavi and/or James_F are probably the folks to talk to [17:16:41] https://openstack-browser.toolforge.org/project/library-upgrader [17:16:52] there is some level of "this isn't 'enough' to push" [17:17:08] Yeah, I just didn't want to harass anyone in particular :D [17:17:17] file a task and wait $time [17:17:38] Right, but my understanding is that anything with a weight >= 10 should get pushed immediately. Even if it were that, a line in the log wouldn't hurt I guess. [17:17:41] * taavi looks [17:17:51] Daimona: harassing the commons harasses me :P [17:18:03] https://gitlab.wikimedia.org/repos/ci-tools/libup-config/-/commit/71ac6db6947b8ee38b1649560ae8e5a9f4a1b536 [17:18:03] So far I've always gone like "it'll update it sooner or later". But not today. Today is the day I want to understand this :P [17:18:06] I can't remember what the weight means [17:18:15] but it'll be related to that [17:18:26] yup it is [17:18:28] "weight" allows for having multiple updates happen in the same commit. LibUp will [17:18:28] only push a patch to Gerrit if it has a weight of at least 10, so if a package is [17:18:28] ready to be updated, but not critical enough to merit its own commit, you can set [17:18:28] the weight to 5 and LibUp will wait for another update to come along before pushing [17:18:28] the commit. This may be any integer value, but for simplicity it's recommended to [17:18:29] be either 5 or 10. [17:18:40] hmm [17:18:42] no it's not [17:18:46] it *should* be pushing [17:18:53] Yeah that matches my understanding [17:18:58] Apr 03 15:19:05 libup-runner08 libup-celery[2780299]: [2025-04-03 15:19:05,112: WARNING/ForkPoolWorker-1] mediawiki/extensions/VisualEditor (main, git: master) has other open changes, skipping push [17:18:59] huh [17:19:03] I mean, of course it does. I read that exact page before :D [17:19:18] it'd been really useful to include the ids of the open patches in that log message [17:19:33] taavi: you must be new here [17:19:44] aha [17:19:59] It would also be useful to surface this information in https://libraryupgrader2.wmcloud.org/r/mediawiki/extensions/VisualEditor [17:20:02] * Reedy looks at legoktm [17:20:16] it does the filtering by "has open patches in that branch with the 'bump-dev-deps' label" [17:20:16] I mean, anything would be more useful than dumping the entire package-lock :P [17:20:23] so https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/1131859 is blocking it [17:20:58] heh [17:21:51] it's passing CI so I +2'd it [17:22:14] 10Phabricator, 06Release-Engineering-Team, 06collaboration-services, 06DBA: Prepare a database test for m3 - https://phabricator.wikimedia.org/T390034#10709515 (10Dzahn) Hi @Marostegui could we use this IP, please: 10.64.16.125 (2620:0:861:102:10:64:16:125). This host is called `phab1005.eqiad.wmnet` and... [17:22:48] Daimona: yeah, that's currently easier said than done unfortunately [17:23:08] I'm filing a task and will take a look [17:23:33] right now there's a celery job for each patch to be pushed [17:23:48] (03open) 10dancy: web: Ran npm audit fix [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/738 [17:23:51] (03update) 10dancy: web: Ran npm audit fix [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/738 [17:23:59] except that "oh no, there's an another patch blocking" just results in that job thinking it was successful and getting removed from the queue [17:24:14] so you'd need to store that data in the libup run model somehow [17:24:38] (also the web interface currently has no direct access to the job queue itself and I really don't want to change that) [17:30:25] I have no idea how LibUp works internally, but I imagine it would be useful if it could figure that out before it even tries to update stuff. It could check for open patches as the first thing and bail out immediately. Unsure how feasible that is though. [17:30:38] Anyway, filed T391011 [17:30:39] T391011: Add information to LibUp logs on why patches are not being created - https://phabricator.wikimedia.org/T391011 [17:30:56] (03merge) 10dancy: web: Ran npm audit fix [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/738 [17:31:02] 10Scap (SpiderPig 🕸️): SpiderPig UI: address user interface feedback - https://phabricator.wikimedia.org/T383835#10709580 (10dancy) [17:31:05] Daimona: https://gitlab.wikimedia.org/repos/ci-tools/libup glhf :P [17:31:57] i'd rather fix T357207 instead [17:31:57] T357207: If there's an existing LibUp patch but a new run has a different outcome, push a new patch using the old Change-Id - https://phabricator.wikimedia.org/T357207 [17:32:07] "someone else pushed a patch with the same topic" is kind of an edge case here [17:32:08] Yeah I will definitely have fun reading python on gitlab :P [17:32:28] probably the filter should be updated to check for the libup user instead of the topic [17:32:57] Oh yeah that makes a lot of sense. [17:33:23] heh [17:33:32] you want to ignore James_FBot [17:35:20] I also just found T263922 for the other issue I was observing. I will never fully understand the point of having code checkers emit soft warnings, but probably that's just me. [17:35:20] T263922: libup should set warnings to off in .eslintrc.json when using maxWarnings: 0 - https://phabricator.wikimedia.org/T263922 [17:35:39] Don't want to scare the developers [17:36:12] Well but we think with booleans don't we. Something is either right or wrong. There's no space for things such as warnings. [17:37:46] As a developer also, it's really confusing if my patch is failing eslint and I need to skim dozens of soft warnings just to find the one single error hiding in there. [17:38:05] that's what nullable bools are for [17:40:09] (03open) 10taavi: Stop James's hard work from disrupting automated progress [repos/ci-tools/libup] - 10https://gitlab.wikimedia.org/repos/ci-tools/libup/-/merge_requests/71 [17:40:13] (03update) 10taavi: Stop James's hard work from disrupting automated progress [repos/ci-tools/libup] - 10https://gitlab.wikimedia.org/repos/ci-tools/libup/-/merge_requests/71 [17:40:17] For triggering type errors you mean? :P [17:40:50] error suppression [17:42:26] (03merge) 10taavi: Stop James's hard work from disrupting automated progress [repos/ci-tools/libup] - 10https://gitlab.wikimedia.org/repos/ci-tools/libup/-/merge_requests/71 [17:42:39] lmao [17:42:58] Great commit message summary [17:43:02] haha [17:44:21] Thanks to everyone who has worked on logspam reduction. I'm only seeing two lines (ignoring expected deployment noise) of logspam-watch output right now and it's great. [17:44:55] (15 minute window) [17:44:57] ^ +1 [17:47:51] [18:46:57] LibUp: Add information to LibUp logs on why patches are not being created - https://phabricator.wikimedia.org/T391011#10709673 (Umherirrender) LibUp does not look for changes to package.json, it looks for open patches with `topic:bump-dev-deps` to avoid re-push itself or to avoid conflicts with other using t... [17:47:52] heh [17:48:21] gahhhh [17:48:22] Continue with sync? [y/N]: Y [17:48:22] Invalid choice: 'Y' [17:49:08] Soon you'll just be able to pick 'yes' or 'no' in your browser. [17:50:06] Also, what's with typing an uppercase Y? :-) [17:50:29] Aren't you from the 80s like me? [17:51:15] Oh wow, I went writing a comment on phab, and by the time I'm back LibUp got improved conflict detection. taavi and James saved the day once again. Thanks! [17:51:29] They are amazing heros [17:51:57] You too btw, Daimona. I've seen you doing a lot of work to improve things and I'm impressed. [17:52:27] anyhow, if anyone has strong opinions on LibUp, patches are most definitely welcome. Amir somehow managed to transfer the project to me while like a day after he got access and I've been stuck with it ever since [17:52:49] (03merge) 10dancy: mediawiki-deployments.yaml: remove debug: true [repos/releng/train-dev] - 10https://gitlab.wikimedia.org/repos/releng/train-dev/-/merge_requests/128 (https://phabricator.wikimedia.org/T389499) (owner: 10swfrench) [17:53:39] I simply have strong opinions and low fault tolerance, that's all :P [17:54:05] You've been quite possibly bamboozled eh? [17:54:42] i've, uh, been given great exposure to the many creative ways people find to break it [17:57:37] (03open) 10dancy: Release 4.149.0 [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/739 [17:59:37] (03merge) 10dancy: Release 4.149.0 [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/739 [18:03:58] (03update) 10bd808: SpiderPig: auto select first backport search match [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/731 [18:05:27] 10Release-Engineering-Team (Priority Backlog 📥), 13Patch-For-Review, 05Release, 05Train Deployments: 1.44.0-wmf.23 deployment blockers - https://phabricator.wikimedia.org/T386218#10709788 (10Reedy) [18:24:45] * hashar remembers PrettyTable supports markdown/HTML/json and dish custom formatting code [18:58:46] (03open) 10dancy: web: Use vite-plugin-vuetify [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/740 [18:58:48] (03update) 10dancy: web: Use vite-plugin-vuetify [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/740 [18:58:57] (03PS1) 10Hashar: Tool to inspect projects submit strategies [integration/gerrit-admin] - 10https://gerrit.wikimedia.org/r/1134018 (https://phabricator.wikimedia.org/T390719) [19:00:16] (03update) 10dancy: web: Use vite-plugin-vuetify [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/740 [19:05:37] 10Gerrit, 06Release-Engineering-Team, 13Patch-For-Review: Change Gerrit default submit strategy to 'Rebase if Necessary' and allowing content merge - https://phabricator.wikimedia.org/T390719#10710223 (10hashar) I wrote a script that fectch the projects configuration and report the submit strategy and conten... [19:06:06] (03PS2) 10Hashar: Tool to inspect projects submit strategies [integration/gerrit-admin] - 10https://gerrit.wikimedia.org/r/1134018 (https://phabricator.wikimedia.org/T390719) [19:06:48] 06Release-Engineering-Team, 10Scap (SpiderPig 🕸️), 10logspam-watch, 10observability: Add a log view to SpiderPig - https://phabricator.wikimedia.org/T391005#10710228 (10dancy) > How often can/should we hit that API? Consider eventually scaling to hundreds of users. Should we cache errors locally? Probably.... [19:07:43] (03PS1) 10Hashar: Add tox to integration/gerrit-admin [integration/config] - 10https://gerrit.wikimedia.org/r/1134026 [19:07:55] (03CR) 10Hashar: [C:03+2] Add tox to integration/gerrit-admin [integration/config] - 10https://gerrit.wikimedia.org/r/1134026 (owner: 10Hashar) [19:09:12] (03Merged) 10jenkins-bot: Add tox to integration/gerrit-admin [integration/config] - 10https://gerrit.wikimedia.org/r/1134026 (owner: 10Hashar) [19:27:47] (03PS3) 10Hashar: Tool to inspect projects submit strategies [integration/gerrit-admin] - 10https://gerrit.wikimedia.org/r/1134018 (https://phabricator.wikimedia.org/T390719) [19:28:13] (03CR) 10CI reject: [V:04-1] Tool to inspect projects submit strategies [integration/gerrit-admin] - 10https://gerrit.wikimedia.org/r/1134018 (https://phabricator.wikimedia.org/T390719) (owner: 10Hashar) [19:53:04] 10Continuous-Integration-Infrastructure, 06Release-Engineering-Team: Upgrade docker-tox image - https://phabricator.wikimedia.org/T356883#10710360 (10hashar) →14Duplicate dup:03T342019 [19:53:07] 10Continuous-Integration-Infrastructure, 13Patch-For-Review: Add Python 3.10, 3.11 and 3.12 to Wikimedia CI - https://phabricator.wikimedia.org/T342019#10710357 (10hashar) [19:54:01] 10Continuous-Integration-Infrastructure, 06Release-Engineering-Team: Upgrade docker-tox image - https://phabricator.wikimedia.org/T356883#10710362 (10hashar) We now have a `docker-registry.wikimedia.org/releng/python-all` which ships several python versions thanks to https://github.com/pyenv/pyenv/ [20:41:59] Project beta-update-databases-eqiad build #83736: 04FAILURE in 8 min 23 sec: https://integration.wikimedia.org/ci/job/beta-update-databases-eqiad/83736/ [20:41:59] Project mediawiki-core-doxygen build #9387: 04FAILURE in 17 min: https://integration.wikimedia.org/ci/job/mediawiki-core-doxygen/9387/ [20:50:06] maintenance-disconnect-full-disks build 689853 integration-agent-docker-1065 (/: 20%, /srv: 96%, /var/lib/docker: 36%): OFFLINE due to disk space [20:55:04] maintenance-disconnect-full-disks build 689854 integration-agent-docker-1041 (/: 25%, /srv: 96%, /var/lib/docker: 33%): OFFLINE due to disk space [20:55:04] maintenance-disconnect-full-disks build 689854 integration-agent-docker-1065 (/: 20%, /srv: 93%, /var/lib/docker: 36%): RECOVERY disk space OK [21:00:03] maintenance-disconnect-full-disks build 689855 integration-agent-docker-1041 (/: 25%, /srv: 68%, /var/lib/docker: 32%): RECOVERY disk space OK [21:04:44] 10Beta-Cluster-Infrastructure, 10CirrusSearch, 10Data-Platform-SRE (2025.03.22 - 2025.04.11), 10Discovery-Search (2025.03.22 - 2025.04.11): Migrate deployment-prep elasticsearch cluster to opensearch - https://phabricator.wikimedia.org/T389971#10710660 (10EBernhardson) I suspect this is complete and can be... [21:30:03] (03update) 10thcipriani: Refactor exception handler code in cli.py and main.py [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/737 (owner: 10dancy) [21:31:32] Yippee, build fixed! [21:31:32] Project beta-update-databases-eqiad build #83737: 09FIXED in 11 min: https://integration.wikimedia.org/ci/job/beta-update-databases-eqiad/83737/ [21:34:38] (03merge) 10thcipriani: Refactor exception handler code in cli.py and main.py [repos/releng/scap] - 10https://gitlab.wikimedia.org/repos/releng/scap/-/merge_requests/737 (owner: 10dancy) [22:00:04] maintenance-disconnect-full-disks build 689867 integration-agent-docker-1050 (/: 25%, /srv: 99%, /var/lib/docker: 41%): OFFLINE due to disk space [22:05:04] maintenance-disconnect-full-disks build 689868 integration-agent-docker-1042 (/: 25%, /srv: 95%, /var/lib/docker: 39%): OFFLINE due to disk space [22:05:04] maintenance-disconnect-full-disks build 689868 integration-agent-docker-1050 (/: 25%, /srv: 10%, /var/lib/docker: 36%): RECOVERY disk space OK [22:10:03] maintenance-disconnect-full-disks build 689869 integration-agent-docker-1042 (/: 25%, /srv: 44%, /var/lib/docker: 39%): RECOVERY disk space OK [22:31:41] Yippee, build fixed! [22:31:41] Project mediawiki-core-doxygen build #9388: 09FIXED in 13 min: https://integration.wikimedia.org/ci/job/mediawiki-core-doxygen/9388/ [23:01:25] (03PS1) 10Krinkle: commands: Fix casing in "Run QUnit tests" section label [integration/quibble] - 10https://gerrit.wikimedia.org/r/1134091 [23:01:48] (03CR) 10Krinkle: "I expect this to fail the fixtures that use the same casing, I'm waiting for CI to confirm this." [integration/quibble] - 10https://gerrit.wikimedia.org/r/1134091 (owner: 10Krinkle) [23:03:15] (03open) 10daimona: Check maxWarnings when disabling eslint rules [repos/ci-tools/libup] - 10https://gitlab.wikimedia.org/repos/ci-tools/libup/-/merge_requests/72 (https://phabricator.wikimedia.org/T263922) [23:05:03] maintenance-disconnect-full-disks build 689880 integration-agent-docker-1041 (/: 25%, /srv: 95%, /var/lib/docker: 33%): OFFLINE due to disk space [23:07:01] good [23:07:32] (03CR) 10CI reject: [V:04-1] commands: Fix casing in "Run QUnit tests" section label [integration/quibble] - 10https://gerrit.wikimedia.org/r/1134091 (owner: 10Krinkle) [23:08:29] (03PS2) 10Krinkle: commands: Fix casing in "Run QUnit tests" section label [integration/quibble] - 10https://gerrit.wikimedia.org/r/1134091 [23:10:03] maintenance-disconnect-full-disks build 689881 integration-agent-docker-1041 (/: 25%, /srv: 94%, /var/lib/docker: 33%): RECOVERY disk space OK [23:10:34] (03update) 10daimona: Check maxWarnings when disabling eslint rules [repos/ci-tools/libup] - 10https://gitlab.wikimedia.org/repos/ci-tools/libup/-/merge_requests/72 (https://phabricator.wikimedia.org/T263922) [23:10:43] (03CR) 10CI reject: [V:04-1] commands: Fix casing in "Run QUnit tests" section label [integration/quibble] - 10https://gerrit.wikimedia.org/r/1134091 (owner: 10Krinkle) [23:11:47] (03PS3) 10Krinkle: commands: Fix casing in "Run QUnit tests" section label [integration/quibble] - 10https://gerrit.wikimedia.org/r/1134091 [23:14:59] (03update) 10daimona: Check maxWarnings when disabling eslint rules [repos/ci-tools/libup] - 10https://gitlab.wikimedia.org/repos/ci-tools/libup/-/merge_requests/72 (https://phabricator.wikimedia.org/T263922) [23:30:36] (03open) 10daimona: releases: Bump api-testing to 1.7.1 [repos/ci-tools/libup-config] - 10https://gitlab.wikimedia.org/repos/ci-tools/libup-config/-/merge_requests/70 [23:44:28] integration-agent-docker-1041 is disk space unhappy [23:45:03] maintenance-disconnect-full-disks build 689888 integration-agent-docker-1041 (/: 25%, /srv: 97%, /var/lib/docker: 33%): OFFLINE due to disk space [23:47:52] 06Release-Engineering-Team, 10Scap (SpiderPig 🕸️), 10logspam-watch, 10observability: Add a log view to SpiderPig - https://phabricator.wikimedia.org/T391005#10711202 (10bd808) > The general public can't be allowed to see production logs. At the moment I don't think we could ever expose SpiderPig to non-ND... [23:50:03] maintenance-disconnect-full-disks build 689889 integration-agent-docker-1041 (/: 25%, /srv: 68%, /var/lib/docker: 32%): RECOVERY disk space OK