[13:58:28] So the patch review board project kind of died. If anyone has thoughts about it, please add to https://www.mediawiki.org/wiki/Talk:Code_review/Patch_board#Retrospective [14:31:44] bvibber: if you’re around, I could deploy https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/961864 now :P [14:35:05] do iiiit [14:41:30] Am i just using generateSchemaChangeSql.php wrong, or does it really just put all the files in the wrong directories? [14:43:47] I think you might have to use the --sql option to specify the output path, IIRC the default doesn’t match core or all extensions [14:43:59] (partly because “core and all extensions” don’t use the same paths :/) [14:44:09] Like i don't think there is any combination of --type all and --sql that gives the correct output [14:44:17] hm [14:44:19] i guess its only 3 files, easy enough to move around [14:44:43] ah, --type *all*, I missed that [14:44:46] yeah I think that could be true [14:45:00] the maint script wants a mysql/ subdirectory but core doesn’t have that? [14:45:04] (whereas some extensions do) [14:45:22] something like that [14:45:44] Its fine with not having mysql. Core wants mysql in /archives but other things in /postgres/archives and /sqlite/archives [14:46:12] in fariness, the core directory structure is weird [14:46:20] and i don't like it [14:50:52] sofixit [14:50:53] :D [14:50:55] :P [14:51:15] I honestly don't know why we can't fix this easily enough [14:51:21] all the places the paths would be hard coded are pretty limited [14:51:48] I mean, eventually we possibly get to the point of not storing all the individual sql files on disk [14:51:53] just have them done on the fly from the json [14:51:56] but that time is not now [14:53:25] I mean, that is a good question. Is there any reason why we aren't just generating these on the fly if they don't exist, maybe with a fallback where you can specify a manual one for any edge cases? [14:53:46] I guess it's partially not sure if we "trust" it yet [14:53:57] I'm not sure there's a good reason why we can't/shouldn't etc [14:54:08] I guess it could make some debugging harder [14:54:21] But we could also wire that in that the generated/run SQL is output to some log file etc [14:54:35] So if it is some bug in the doctrine layer.. we can fix/workaround/upstream etc [14:56:59] I like having the files, to me they’re more readable than the JSON [14:57:10] but I wouldn’t mind moving tables-generated.json back to tables.json [14:57:32] The empty tables.sql can presumably go too at this point [16:39:42] Lucas_WMDE: ah i mighta missed ya :D [16:41:45] (i gave it a rebase, should be good to go whenever) [17:03:27] Fun fact, there are two files on commons that ran into the limitation that img_width is only allowed to be at most 2^31 [17:03:53] File:Books_from_the_Biodiversity_Heritage_Library_(IA_pliniussecundus00plin).pdf and File:Oiseaux_brillans_du_Brésil_(IA_Oiseauxbrillans00Desc).pdf [17:11:50] hah [17:12:03] iirc PNG has a hard 32-bit limit on width/height [17:12:10] pdf is weird though it has a physical size limit [17:12:44] https://www.reddit.com/r/MapPorn/comments/14op0qq/maximum_pdf_document_size_supported_by_adobe/ [17:13:05] One has to presume that the pdf file is bugged in anycase and its not really that many pixels wide [17:13:12] I guess pdfs are vector-ish so its arbitrary [17:13:16] likely yeah ;) [17:13:38] i suppose svg could be arbitrarily large.... hrm [17:39:50] there was a DOS vector years ago that allowed to crash Chrome or Firefox, by rendering an tag of a png scaled to an insane size [17:57:07] i saw a description of a nice svg dos that uses the '' (iirc) instantiation to take a small number of xml nodes and just scale them up to millions/billions of render nodes [17:57:12] slows browsers to a crawl :D