[06:42:37] Amir1: will do, and I indeed fixed that by deleting duplicates from watchlist table. [09:25:14] Hello [09:25:14] I have another question [09:25:14] How do continuations work with the api? [09:25:35] I need to read all the images and page names from a generator in the api [09:48:42] alpl: see https://www.mediawiki.org/wiki/API:Query#Example_4:_Continuing_queries [11:33:56] mutante: I have few questions regarding Mailman 3 migration, excellent job! Does this make Wikimedia as the only org which successfully migrated 2 to 3? Wikimedia Polska has some Mailman 2 mailing lists, too... we'd like to move them [11:45:45] saper: legoktm would be the best to ask that [11:46:19] or Amir1 [11:47:43] saper: I don't know about other wikimedia orgs but most open source orgs, python.org, debian, fedora, all migrated to mm3 before us [11:48:08] with all the issues we fixed upstream, migrating should be even easier and straightforward [11:52:00] wonderful [15:57:23] Some cross-dresser regurgitating the tenderqueer stereotype to silence trans people and erase a trans icon like Lily is civilized, but anyone who offend you fragile white trash snowflake is a savage; Richard Morgan calling us Trans-Identified Men and say we are War on Women is just him having an opinion, but we pointing out he's transphobic is us having an agenda. You know what? I do have an agenda: now that you have shown how you will not [15:57:23] give us even scrapes of basic rights and dignity, it's obvious that we can only take it from your corpses. I will find you, and then I will kill you, and and every last one of you. But not quickly, no; I'll make you suffer first, by killing everyone you cared about and feed you their chopped up flesh. You help to silence and murder trans people and other minorities every day, this is only fair don't you think? [16:02:26] huh, just as I was going to suggests they might have landed in the wrong channel. well. [16:02:38] I banned them via Matrix [16:03:19] oh, we have matrix bridged? I guess I should have realized from the [m] [16:05:43] Yeah, all IRC channels are available via Matrix [16:06:14] very nice! um hmm does it have to have your credentials? I am guessing yes? [16:06:36] https://meta.wikimedia.org/wiki/Matrix.org [16:06:58] Yeah [16:07:13] yeah I'm on the element side of slack (which is failry flawed) but there would be less to get right for irc [16:10:36] They hit all the MW-related Matrix rooms I'm in, bleh [16:14:08] ouch [16:27:45] Hi, I'm trying to upgrade MediaWiki 1.22 to 1.35.3, but I have problem with this: [16:27:46] Failed to populate content table revision row batch starting at 115518 due to exception: MediaWiki\Storage\BlobAccessException: Unable to fetch blob at tt:108912 in /home/kizule/web/mywikibiz.kizule.ga/public_html/includes/Storage/SqlBlobStore.php:295 [16:27:46] Stack trace: [16:28:32] Run php maintenance/populateContentTables.php [16:28:39] Then rerun update.php [16:29:16] Honestly, I’m not sure why update.php doesn’t catch this exception and runs it for us. It’s a very common issue when upgrading even from 1.31 [16:29:17] I've run populateContentTables.php already. [16:29:52] Okay, I've executed update.php, let's see. [16:30:04] Same thing. [16:30:19] Looks like database is broken. [16:31:05] I've exported it via mysqldump with --hex-blob and transferred file via scp from one server to another. [16:31:33] Why with hex blob? [16:32:08] https://stackoverflow.com/questions/16559086/does-mysqldump-handle-binary-data-reliably [16:33:00] I tried with and without it. [16:33:28] Try upgrading to 1.27 first [16:33:34] And then to 1.31 [16:34:21] And after to 1.35, right? [16:34:42] Yeah, see where the error happens [16:34:56] Or maybe it gets fixed. Who knows [16:37:32] I will try to create a dump of the database again, but without any settings, because by some miracle I don't get the timeout (it is on shared hosting and I'm moving it on the VPS + upgrade). [16:37:58] Ah, that might explain the database corruption [16:38:54] Worst case try exporting it by table [16:39:26] The current wiki is on shared hosting. I'm moving it on VPS, because wiki is is very big + VPS at Contabo is cheaper. :) [16:39:44] You mean "table by table"? [16:39:49] Yeah that’s great [16:40:41] I seem to be learning a lot more with this project. :D [16:41:27] Yes, table by table. Same thing in English. [16:44:44] I've been thinking about that option as well, but the worst part is that I don't have phpMyAdmin on this shared hosting. [16:44:55] And I don't know how the man managed to create a database outside of phpMyAdmin. [16:45:18] Use mysqldump on SSH [16:45:30] It’s a little intimidating at first but you get used to it [16:45:48] I mean, I know to work without phpMyAdmin, but things are easier with it. [16:45:56] I'm using mysqldump on SSH already. ;) [16:46:01] mysqldump -h hostname -u -ppassword dbname > dbname-dump.sql [16:46:42] I'm using this: mysqldump -u mywikibiz -p mywikibiz -r mediawiki.sql [16:46:59] I missed the shared hosting part. What shared hosting doesn’t offer phpMyAdmin? That’s odd [16:49:18] cPanel is outdated, CentOS 6. I'm not sure is this Hostgator or Hostinger. [16:49:45] But it's not clear to me why they didn't upgrade to the cPanel account and all that. [16:50:06] They all provide phpMyAdmin, even these, but it doesn't exist on this account. [16:50:32] *didn't upgrade the cPanel account [16:50:38] Is the timeout of the dump occurring because of the shared hosting server or because of the MySQL database? [16:51:21] I had it previously, now I don't have timeout. [16:51:30] I'm really sure that shared hosting server was related. [16:51:40] Looks like I'll make it this time. The file type is text/x-sql, not text/x-generic. [16:53:45] BTW, server is soo slooow. I'm transferring the fresh dump file (again) from shared hosting server to VPS.. [16:53:47] mediawiki.sql 2% 148MB 2.3MB/s 41:51 ETA [16:56:01] compress it first [16:56:29] Oh, good idea, I totally forgot about it, thanks. [16:57:06] :)) [17:34:12] Hi there, is there any way to have other CSS style be called by Common.css ? [17:36:32] What do you mean? [17:36:40] Include other CSS files/pages? [17:36:50] Yes [17:39:58] Oh, I think I got it, @import [20:46:36] legoktm: I think it'd be a good idea to show a message on updating the mediawiki .deb reminding to run update.php, since that's not handled automatically by the package [20:47:00] it should prompt you to read the NEWS entry [20:47:15] hmm, I think it didn't [20:47:22] https://salsa.debian.org/mediawiki-team/mediawiki/-/blob/master/debian/mediawiki.NEWS [20:47:58] what did you upgrade from and to? [20:48:15] I did a test install from buster [20:48:20] then upgraded to buster-backports [20:49:00] which produces an error on login if database changes haven't been done [20:49:10] * legoktm tries in a container [20:51:36] ok, in my docker container it did not have me read NEWS, but on my actual Debian VM it always does... [20:52:44] https://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#supplementing-changelogs-with-news-debian-files [20:52:53] "The news will be displayed by tools like apt-listchanges, before all the rest of the changelogs" [20:53:53] It won't work in standard containers because /usr/share/doc/ is typically removed for disk spcae [20:53:54] that's odd [20:54:29] tbh I've been debating having the package just run update.php on upgrade [20:55:14] if /etc/mediawiki/LocalSettings.php exists, then run it on every package upgrade, else skip [20:55:55] The downside is that if update.php fails, you're in a weird apt state since it might've interrupted other upgrades but I guess that's better than silently having your wiki broken? [20:56:39] I thought perhaps it wasn't doing it for big databases [20:58:14] we could tell people to set https://www.mediawiki.org/wiki/Manual:$wgAllowSchemaUpdates if they want it to be skipped [20:59:11] I asked in #debian-devel on OFTC about what it takes for NEWS files to be displayed [20:59:20] makes sense [20:59:48] the real answer of why it didn't do it was because I never fully thought out the ramifications of doing so, and it seemed easier to introduce later on rather than take away [21:01:02] yes, it's something to ponder [21:01:20] we're already deep in the freeze so we can try to do it for 1.39 / bullseye-backports / bookworm [21:03:14] no hurry for this, indeed [21:04:00] btw, there are two really old CVE that it thinks affect the last version, while they don't: https://security-tracker.debian.org/tracker/source-package/mediawiki [21:04:47] oh yeah, I've been meaning to ask Moritz to fix that [21:06:54] the other one says it's oddly waiting for next 1.35.x release while linking to 1.35.3 release announce, but I think you're perfectly aware of thar :) [21:06:58] *that [21:08:20] since the only issue was pretty minor (a purge DoS) and we're in the freeze, we decided to skip it and we'll just go directly to 1.35.4 [21:08:44] oh, it means 1.35.4 [21:08:49] at least it doesn't think CVE-2021-30156 is unpatched, i'm still not sure if that cve should exist or not [21:10:20] seems a grey area [21:11:02] some people would use development branch, but that generally doesn't come with any security guarantee [21:12:17] btw the answer from -devel is that NEWS is the best way to inform users, and that you should install apt-listchanges :) [21:12:53] apt-listchanges is indeed not installed [21:13:43] perhaps the solution should be a dpkg question if you want to run update automatically or you will do that later [21:16:37] if just leaving a note on NEWS, I woul suggest changing «Please see the "Upgrading" section of README.debian and /usr/share/doc/mediawiki/UPGRADE for details on what manual steps need to be taken to upgrade.» [21:16:50] to something like «Note that manual steps may need to be taken when upgrading, please see the "Upgrading" section of README.debian and /usr/share/doc/mediawiki/UPGRADE for details.» [21:19:20] would you like to send an MR? :) [21:20:31] that's the changelog text, it'd be odd to provide a MR for that, I think [21:22:13] it uses the changelog format but it's more like release notes IMO [21:22:28] the version #s are only used to identify what should be displayed to you [21:23:42] oh, I got confused thinking it was showing the changelog :P [21:28:01] would you recommend to run mediawiki from your packaged .deb or from upstream tarball? [21:33:05] mostly I think it depends how much you want to customize MW [21:33:33] if you're just running bundled extensions and just want it to work without much attention, the deb is great [21:34:11] if you you want to customize it, or give it a lot of love, etc. use the tarball or git [21:34:57] https://wikimediadc.org/wiki/Home runs from the .deb, it works reasonably well [21:35:04] well, I was using git [21:35:10] but I'm not giving it enough care [21:35:11] mostly its nice that unattended-upgrades takes care of security releases [21:35:26] brb in 15 [21:35:59] but I guess you need an additional update.php to it, then :P [21:46:17] Platonides: usually security releases never need update.php [21:48:34] yes, you can assume you are able to skip it [21:49:56] btw https://gerrit.wikimedia.org/r/c/labs/tools/wikibugs2/+/701614 [21:51:07] LGTM