[06:15:13] TimStarling: is there anything else you'd like to see before I tag a new release of poolcounter? [09:33:17] Hi. I'm getting a fatal when running maintenance/findDeprecated.php [09:33:21] \maintenance\findDeprecated.php: Call to undefined function posix_isatty() [09:33:53] Error from line 181 on maintenance\findDeprecated.php: Call to undefined function posix_isatty() [09:34:06] any ideas? [09:53:19] Hauskatze: that’s because windows does not support posix I think [09:53:38] sigh [09:53:58] https://stackoverflow.com/questions/41328157/how-to-install-posix-in-windows [09:54:39] You could try running in windows on bash [13:07:21] https://github.com/auchenberg/volkswagen [14:34:41] DanielK_WMDE_: the Wikibase pageid problem sounds a bit like the problem with having {{subst:PAGEID}} in the first revision of the page [14:35:15] we talked about redoing the PST if the content varies on page/revision, maybe that's worth doing? [14:35:39] and then plugging the page ID into the JSON could be done as a PST [14:49:45] tgr: but that means PST has to be re-done after the page row is inserted, but before the content row is written. So it would happen during the DB transaction, while we are holding a lock [14:50:10] tgr: I'm more inclined towards a PLT (post-load transform) [14:51:54] tgr: or we introduce a mechanism for committing a dummy row into the page table before PST. BUt stuff listing pages would get that incomplete row (incomplete because it would have page_latest = 0) [14:52:33] you don't need to commit the row, just reserve the ID [14:52:58] how do you do that without comitting, and without holding a lock? [14:53:04] oh, you could insert and delete again, i guess [14:53:20] not sure how well that's supported cross-DB; postgres and oracle at least have clean ways of doing it, in mysl you can just insert in a transaction and then not save it [14:53:37] not commit it I mean [14:53:46] that sounds like behavior that may change unexpectedly... [14:54:00] if you don't commit, you hold the lock, no? [14:54:12] or can you roll back and still have the ID? [14:57:13] yeah, roll back and you still have the ID [14:57:23] not sure how stable that behavior is but it's documented [14:58:03] we use it in a bunch of maintenance scripts I think [14:59:25] PageUpdater could provde access to that [14:59:43] Wikibase would need quite a bit of refactoring to be able to use that, though [14:59:48] but it's doable [15:00:06] anyway, i have another meeting in a minute [15:00:14] uh, now. [17:17:46] tgr: i didn't mean to bypass you on the McrUndoAction thing. Having this fixed in DE would of course be much better. I just wanted the blocker out of the way asap. [17:17:57] If you make a patch for DE, I'll review it [17:18:42] I also updated McrRestoreAction https://gerrit.wikimedia.org/r/c/mediawiki/core/+/461162/2 [17:18:57] Let me know if there's anything else that needs fixing there [17:19:01] anomie: --^ [17:37:41] DanielK_WMDE_: sure, no harm in getting it merged, just wanted to mention somewhere that I want to follow that up [17:38:17] ack [17:40:11] re: restore, I think setting the original revision ID would be safe in this case, but given it's a temporary hack it does not matter much [17:41:40] i also think it would be safe, but it's not needed, and it would require some refactoring. [18:05:38] DanielK_WMDE_: one small annoyance with mcrrestore is how it handles edit conflicts [18:05:50] you start with a restore= GET parameter [18:06:29] you use preview / show changes which converts it into POST (probably saving right away would also have the same effect) [18:07:15] if there was a conflicting edit, you get a message about how the edit could not be undone, since internally it uses undo parameters and the undo does not apply any more [18:08:01] and there is no straightforward way to get a form for reverting from the new current revision to the one you clicked edit on [18:08:27] if restore was a GET parameter you could just reload but with POST that just gives a different error [18:08:38] not sure if this is worth fixing [18:09:02] ideally, it would show the message and at the same tim e just show the new diff, and allow this to be confirmed [18:42:28] DanielK_WMDE_: do you want to do that or not worth the effort? given that the proper EditPage refactoring is already being worked on, I'd lean towards the latter [18:42:48] naw, not now [18:42:57] it's a rare enough situation [18:57:58] waaat? someone's brave enough to touch EditPage? [19:17:36] tgr: thanks! [19:17:47] tgr: SlotROleHandler is ready for review, I think: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/434544 [19:18:26] tgr: the interface isn't very elegant with all the stuff depending on Title. I'm really tempted to introduced PageTypeHandler at the same time, to take care fo at least part of that [19:18:33] but I'll think more about this tomorrow. [22:39:30] Reedy: Shall we do T106067 now then? [22:39:31] T106067: Undeploy DisableAccount extension - https://phabricator.wikimedia.org/T106067 [22:40:00] Sure [22:40:12] 20 minutes is enough, right? [22:40:35] Should've thought so [22:40:39] We don't need to scap [22:40:49] just sync CS, then IS and extension-list [22:40:57] Yeah. [22:41:08] You doing it or should I? [22:41:29] I've just started it off :) [22:41:33] * James_F grins. [22:41:38] see what jerkins has to say [22:42:36] See if we can get EP gone by the end of the week too [22:42:44] That'd be lovely. [22:43:08] What about CodeReview? ;-) [22:43:37] codereview4lyf [22:44:03] We kinda need to decide what to do about the data in CR [22:44:54] * James_F sighs. [22:45:13] Wasn't the svn->git export the moment we decided what data we wanted to keep and what we could live with losing? [22:45:31] The extension is still around years later... (nearly a decade now? :P) says otherwise [22:46:09] That speaks more to laziness. :-) [22:46:24] It's "only" seven years. [22:46:31] We should start a discussion if we do like a html dump or something [22:46:59] James_F: Can we convert the comments to Flow? [22:47:01] * Reedy hides [22:47:16] * James_F snorts. [22:47:38] How about we do a dump of the tables, stick it on download.wikimedia.org, and call it done? [22:48:00] That's certainly the minimum [22:48:24] And people that really really want us to do more can use that to do it. [22:54:00] I frequently look at CR discussions :/ [22:54:05] HTML dumps are a must I think [22:57:08] Could we make a tool that hosts the old CR data? Would it need to be a full MediaWiki deploy or could we scrape it to HTML somehow? [23:01:11] mutante did it for bugzilla [23:01:25] I dunno if MW it's more of an effort/maintenance burden [23:56:28] Reedy: Too aggressive? ;-) https://usercontent.irccloud-cdn.com/file/FFf00hgG/image.png [23:56:42] RIP [23:56:51] James_F: only after it's actually archived :) [23:56:58] Sadly EP has a "get all the data out" task. [23:57:01] Unfunded. [23:57:05] But demanded anyway. [23:57:10] * James_F sighs. [23:57:23] I just need to sanity check the sql dumps