[00:51:57] Is CampaignEvents good to install today? [00:55:06] need somenyan to merge puppet [01:01:11] 𝐈 𝐰𝐢𝐥𝐥 𝐡𝐞𝐥𝐩 𝗲𝗮𝗿𝗻 $𝟏𝟎𝟎,𝟎𝟎𝟎 𝘄𝗶𝘁𝗵𝗶𝗻 𝗮 𝘄𝗲𝗲𝗸 𝗯𝘂𝘁 𝘆𝗼𝘂 𝘄𝗶𝗹𝗹 𝗽𝗮𝘆 𝗺𝗲 𝟭𝟬% 𝗼𝗳 𝘆𝗼𝘂𝗿 𝗽𝗿𝗼𝗳𝗶𝘁 𝘄𝗵𝗲𝗻 𝘆𝗼𝘂 𝗿𝗲𝗰𝗲𝗶𝘃𝗲 𝗶𝘁. 𝗡𝗼𝘁𝗲 𝗼𝗻𝗹𝘆 𝗶𝗻𝘁𝗲𝗿𝗲𝘀𝘁𝗲𝗱 𝗽𝗲𝗼𝗽 [01:42:01] I have a problem with the puppet PR. Using databases.php for the timers runs on all wikis, but then since the extension won't be installed on all of them it's going to error on 99% of them, we would need to create a database list just for CampaignEvents, but a permanent extension-based database list is not exactly convenient either. [01:42:53] Are the timers absolutely necessary for the extension to function? [01:59:00] At least one of them is, aggregate answers. Technically the UTC one only ensures timezone accuracy but aggregate answers is a required timer for it to function. [01:59:19] At least one of them is, aggregate answers. Technically the UTC one only ensures timezone accuracy but aggregate answers is a required timer for it to function. [01:59:45] I don't know how we do this then lol [02:00:04] Is there another way to add cronjobs? [02:00:17] There is not. [02:00:41] Then we might wanna ask the extension maintainers to not rely on cronjobs for aggregate answers, seems kinda silly. [02:00:42] I guess maybe we add a script in MirahezeMagic which doesn't error if an extension isn't enabled just immediately skips it... [02:01:04] That could work I guess. [02:01:07] seems hacky and dangerous [02:01:08] Just a wrapper that can check an extension enabled. [02:01:09] on brand [02:01:27] It wouldn't do anything else but act as a wrapper. [02:01:45] I would like to not rely on cronjobs for the extension though if possible [02:02:02] We could make CampaignEvents a default extension, people don't have to use it. Although that may use unnecessary resources so idk. [02:02:18] We really shouldn't do that. [02:03:04] I suppose I can have it generate a database list for the extension on the timer and clean it up afterwards... [02:03:22] So it runs only on wikis with the extension enabled. [02:03:45] But lazily creates the database list as to not cause production performance issues. [02:04:10] Its just kinda a tricky situation... [02:04:35] This really shouldn't depend on cron jobs... [02:04:49] It should use a job to update the data on demand. [02:05:33] That's what I suggested we talk to them about. [02:06:03] That might be a good idea. But I do kinda doubt it'll change anytime soon. [02:06:16] Realistically cronjobs should be for stuff like refreshlinks and whatnot. [02:06:33] I guess this task will sit for a while. [02:06:38] friend encountered this [02:06:56] [3fa6b8675137f4b01259f8c4] [02:07:00] It's a DB query error, meaning it either couldn't query the database or something broke. [02:07:00] Is anyone around to look that up in graylog right now? [02:07:04] That's useless. [02:07:06] soonish [02:07:17] That's just a randomly generated string that means nothing. [02:07:20] im just sending it just in case [02:07:20] Its not useless. That's how the logs are looked up [02:07:35] Its the request ID [02:09:22] Thats actually the only thing we need to find logs which is why it's what is shown on-wiki for any error because it tells us how to find the actual log in Graylog, which is what we use as the logging backend. [02:10:21] Wouldn't each wiki have their own log anyway? [02:10:31] No it's a central logging system. [02:10:43] i think we could filter by wiki though? [02:10:50] but req id is easier to lookup [02:11:18] You could but then you'll have hundreds of logs maybe even thousands to dig through so the request id is really easier. [02:11:20] narrowing it down by wiki + timestamp + ip address doesn't sound fun [02:11:59] I'll make a ticket on Phab about CampaignEvents then. [02:12:36] Feel free I suppose. If they can't do anything and it continues to require a cron job I'll see what I can do about that. [02:12:38] Ideally we could make a workaround with MirahezeMagic, but yeah it shouldn't need a cronjobs for that one necessary script. [02:13:49] alright i'm on lappy :3 [02:16:34] I wonder... do forwarded messages rely to IRC...? [02:17:11] https://cdn.discordapp.com/attachments/1006789349498699827/1350654099606995007/message.txt?ex=67d78627&is=67d634a7&hm=add3b715ace364553b2ecb18b1437b80b2db06c4345919f9213a089a13bac278& [02:17:14] this pos [02:18:02] ah it's that one... to large of an upload I guess? [02:18:09] That happens a lot it seems [02:18:14] ikr wtf [02:18:41] Why did this suddenly happen. It didn't used to... I guess it's a 1.43 issue... [02:19:02] lappy! [02:19:10] theres a task for this somewhere [02:19:16] Yeah I saw it [02:19:33] Like an hour ago when I was taking a look at every task... [02:20:23] I was just opening them all really and taking a look seeing if anything I could do within a few seconds. [02:22:52] [1/2] https://meta.miraheze.org/wiki/Steward_requests/Restricted_changes#Outlaster_Wiki [02:22:52] [2/2] do i just enable SMW in MW and briefly visit the main page to see if nothing broke? [02:23:55] Wouldn't Cargo be a better alternative instead of semanticising their wiki? [02:24:08] Technically only Stewards are suppose to do restricted ManageWiki changes unless it needs tech intervention. However I wouldn't be opposed to opening it up more to tech to work with Stewards more on that also. [02:24:21] was asked in #tech-stewards to do that [02:24:30] https://discord.com/channels/1006797886027214949/1285783046733299712/1350635177197568001 [02:24:40] Unknown channel 😔 [02:24:51] unknown server technically [02:24:54] But it doesn't need tech intervention anymore. [02:24:58] ah okay [02:25:08] so i'll just do nothing in this case? [02:25:44] (wiki mechanics cough) [02:25:58] Its all been automated so Stewards can do it 100% of it now. It used to need tech to run setupstore on all servers but I changed that to not be required anymore except for one server which ManageWiki does. [02:26:20] lol I forget that exists... [02:26:23] oopsie :3 [02:26:34] How do you even become a wiki mechanic. [02:26:41] everyone does [02:26:47] RfP [02:26:55] well that's one thing off my list [02:27:06] What is RfGP [02:27:07] its a werid kinda dumb and basically unused role [02:27:15] request for global perms [02:27:32] i would support trashing it in the neext ombds rights rfc [02:27:35] Why is it dumb. [02:27:40] It is kinda useless tbh [02:28:13] In theory it was a good idea but in practice it didn't work out. [02:28:19] Well the only other people with wiki mechanic rights are stewards, if I didn't wanna do all the tasks stewards do wiki mechanic would be perfect. [02:29:26] eh [02:31:01] id rather a semi steward role in the other direction but account for bias from me, someone who is on that other side of the commmunity role tree [02:42:21] Corruption from within!!! [02:43:46] whaaaaaaaa meeeeeee noooooooo [02:44:18] I'll give you $20 to block Claire. Of course not. [02:44:33] naaaaah i aint turning on my bestie [03:27:48] what do i do when a wiki has content model ids that don't match https://meta.miraheze.org/wiki/Tech:Fixing_slot_roles_and_content_models? [03:27:59] e.g. css is id 6 [03:33:33] cc @paladox: ^ [03:33:41] there's luckily like four pages only [03:34:15] should i manually set the content model ids for the contents? [03:35:56] fuck it we ball [03:56:49] fml i have to debug the refreshLinks issue [04:51:41] i'm gonna edit the mw source code directly [04:51:46] say hello to 502 [05:00:04] i mean how else do you do it [05:04:04] i keep forgetting that psysh is not a debugger [05:04:20] so i'm out here trying to traverse through stack frames and getting Undefined constant "MediaWiki\Deferred\LinksUpdate\up" [07:03:02] [1/11] so [07:03:02] [2/11] ``` [07:03:02] [3/11] > $pl->setStrictTestMode(true) [07:03:03] [4/11] = null [07:03:03] [5/11] > sudo $pl->strictTestMode [07:03:03] [6/11] = true [07:03:03] [7/11] > $pl->update() [07:03:04] [8/11] Wikimedia\Rdbms\DBQueryError Error 1062: Duplicate entry '2681-0-' for key 'PRIMARY' [07:03:04] [9/11] Function: MediaWiki\Deferred\LinksUpdate\LinksTable::doWrites [07:03:04] [10/11] Query: INSERT INTO `pagelinks` (pl_from_namespace,pl_target_id,pl_from) VALUES (8,3223,2681),(8,3225,2681),(8,3226,2681),(8,3227,2681),(8,3228,2681),(8,3229,2681),(8,3230,2681),(8,3231,2681),(8,3232,2681),(8,3223,2681),(8,3225,2681),(8,3226,2681),(8,3227,2681),(8,3228,2681),(8,3229,2681),(8,3230,2681),(8,3231,2681),(8,3232,2681). [07:03:05] [11/11] ``` [07:03:19] seems like one page can only outlink to another page [07:03:39] [1/3] and this is a bit suspect [07:03:40] [2/3] https://cdn.discordapp.com/attachments/1006789349498699827/1350726191585427497/2025-03-16_18-00.png?ex=67d7c94b&is=67d677cb&hm=1ea466a3f1a6a6f32f2b61a08eed0bb950ab6c51de124d596387b7c5f9ce8c5f& [07:03:40] [3/3] https://cdn.discordapp.com/attachments/1006789349498699827/1350726191920840734/Screenshot_2025-03-16_at_18-00-49_Manual_pagelinks_table_-_MediaWiki.png?ex=67d7c94b&is=67d677cb&hm=09ff6957b8907fe602bd8f6a769b1a24c9758cf8f0b10215978461ed2bd41df1& [07:12:53] looks like i toggled a mode meant for unit tests [07:12:58] and that revealed our schema fuckery [07:13:13] wonder if we should ask in #mediawiki to make it enabled by default [08:04:12] @blankeclair just to confirm that https://github.com/miraheze/mw-config/pull/5874 is okay to do? [08:04:49] yea [08:13:07] [1/2] @cosmicalpha as far as I can tell, the cronjobs for CampaignEvents aren't required for the extension to function, but for aggregating participant answers then that cronjob is required, otherwise the extension will most probably function fine, we just might need to add a notice about it not working, unless we should only push extensions that people expect to work 100% and not 60% or 70 [08:13:07] [2/2] % of the time. [08:20:52] [T388996](https://phabricator.wikimedia.org/T388996) is the ticket. [08:28:36] The timer for aggregating data is a privacy compliance tool [08:28:40] It's definitely needed [08:29:14] We shouldn't deploy an extension if we can't comply with our legal obligations [08:29:47] Ah, well that makes sense then. Then yeah, it shouldn't be a stupid ass cronjob. [08:30:07] Use systemd:⏲️:job in puppet [08:30:20] Will give you monitoring and the lot [08:31:01] I hate cron jobs [08:37:16] Yeah, we can't do that. [08:37:47] As CA has said, running them through puppet runs them on every wiki, and not every wiki will have CampaignEvents installed. [08:38:11] no it doesn't [08:38:22] We have dblist generators that should work [08:41:26] If you want to try doing that you're more than welcome, I'm just repeating what I was told. [08:41:57] @rhinosf1 this was the start of our conversation about puppet oday. [08:45:17] Store the dblist in /tmp [08:46:20] https://discord.com/channels/407504499280707585/1006789349498699827/1350650546851282946 probably the best option. Use mwscript in the timer maybe. I don't know. I want to make it as simple as possible though. [08:48:06] I do not necessarily like it being a cron job and would like it to be automatic but I'll admit I don't fully understand how the extension works yet may need to play around with it some locally. It may be like how other extensions have a maintenance script we run in a cron to regularly purge PII. I'm not 100% sure though. [08:50:33] Well yeah, AggregrateAnswers purges PII. [08:51:23] I guess it makes sense to be a cron job/timer in that case but docs are super confusing and not clear on what's needed with that at all... [08:52:36] Yeah, I mentioned that in the ticket. [08:52:44] The documentation says nothing on how to setup the cronjobs. [08:53:36] Anyway it's 3AM so I'm going to go sleep but I'll look at giving you what to do it your puppet PR tomorrow so we can finally finish that extension... [08:53:51] Well I guess technically today [08:56:00] Alrighty, whilst you're asleep I'm going to make twenty PRs to enable extensions that have not worked since 1.33. [12:10:22] Oh yeah, the Interwiki extension has been merged with MW Core in version 1.44 per [T33951](https://phabricator.wikimedia.org/T33951) last December. [12:10:52] I don't think anything database-wise has changed, but it's not an extension anymore. [12:13:11] Should I make a task about it just in-case something has changed and needs to be docuemnted? [12:14:42] Add it to the 1.44 tracking task [12:17:13] So, make the task and then add it? [12:31:54] Yeah [12:32:47] Alrighty, I attached it. [16:20:44] theres an issue with the SimpleTooltip extension where adding a tooltip in a bullet point causes the rest of the content after that point to have an indent [16:20:50] where shall i complain [16:22:06] Uuuuuu [16:22:20] Is it an extension or MH issue [16:22:53] I’d say probably WMF Phab, if that’s what the extension uses for its issue tracker [16:23:11] Probably add the affects Miraheze tag [16:23:13] extension ? [16:23:24] Im Scared [16:23:50] Why [16:27:09] Don’t worry no one will see it anyways [16:27:17] sigh [16:27:35] Let me see [16:27:54] The newest task is T389007 [17:24:15] @cosmicalpha sitting down to try and finish the CW PR maaaaybe if i can lock in, if i get the other stuff done can you explain how tf to do tests [17:54:34] I wonder if echo is getting merged into MW core from 1.44? https://github.com/wikimedia/mediawiki/blob/master/includes/Notification/Notification.php [18:09:49] I already removed it and fixed it all for 1.44 so when we upgrade we don't have to worry about that one. [19:20:56] @cosmicalpha right so, https://github.com/miraheze/CreateWiki/pull/605#discussion_r1951864708, did some stuff [19:21:34] https://cdn.discordapp.com/attachments/1006789349498699827/1350911894537633812/i2ufP16.txt?ex=67d8763e&is=67d724be&hm=9a09c3d05f68cbd4c595567c3c05b72b9f2091d4a9eccf60938dd94f9baed22f& [19:22:06] https://cdn.discordapp.com/attachments/1006789349498699827/1350912026557550672/wnEW5oo.patch?ex=67d8765d&is=67d724dd&hm=8f8643bca70d7ea22709c1c9666a6d689e9534c56e9701d7dc6bb48bce4e337e& [19:22:48] actually i think my reformat broke some things, is it not using mediawiki standads [20:37:40] Still need to be removed from mediawiki-repos etc [20:37:48] It's good to have a task [20:58:14] I already did [20:58:31] Well I set versions so it isn't installed on 1.44 in mediawiki-repos [20:58:53] will look at that in a bit. [20:59:31] Then it's just cleanup to remove all that then [21:01:32] [1/2] The only thing it will need after upgrade is to remove the void code that does nothing with version checks yeah. I already deleted it from 1.44 on beta also and it won't ever install when 1.44 is added to prod servers. I added a version check in GlobalExtensions and in mediawiki-repos that need removed and that's all. Oh and the config that now uses virtual [21:01:32] [2/2] domain on 1.44, so the config does nothing on 1.44 also. Already set virtual domain though too. [21:02:12] Yup [21:02:15] That's still something [21:02:52] yep. I also changed the install path for tables-generated that was moved in 1.44 using a version check so that'll also need removed. [21:02:58] Things to be done in months time should always be tracked somewhere [22:28:39] Will also commit and push up in a few hours so I don’t forget [23:56:39] https://issue-tracker.miraheze.org/transactions/editengine/maniphest.task/view/22/ [23:56:51] any reason why policy settings are visible?