[00:00:03] on macOS, starting with ARM, PHP now goes to /opt so /usr/bin/php is undefined. [00:00:15] and macOS no longer ships an outdated PHP version either. [00:00:51] in theory that shoudl be fine since we have the installer check, but a long tail of various reasons when it is not set or set incorrectly etc are now more exposed as people upgrade hardware [00:01:53] oh, it's worse than that -- it's just argv[0] [00:02:53] you know that could be anything, it's specified by the process which calls exec [00:05:24] under apache mod_php it looks like PHP_BINARY will be an empty string [00:05:39] it doesn't set `sapi_module.executable_location`? [00:06:30] the FPM, CLI and FPM SAPIs set it, but the Apache SAPI apparently just leaves it as null [00:06:44] main/main.c checks if it's null and sets the constant to an empty string in that case [00:14:52] I wonder if we still need it in MediaWiki. It seems whatever originally used it, no longer does (something JS2 related that was reverted, FlaggedRevs but no longer does, SiteConfig but method was removed, built-in Async Job run now uses HTTP). And what's left is things already on the CLI spawning new processes, but that's presumably a case where PHP_BINARY, argv[0] could be used. [00:15:21] I actually see nothing in the installer setting it today. [00:15:30] looks like that hasn't been true for a very long time, if ever. [00:15:50] so argv[0] at least has a chance of using the user's preferred CLI [00:16:20] the build-time location of the PHP CLI is provided via PHP_BINDIR [00:17:55] https://github.com/WordPress/blueprints-library/blob/228977b666c57fb2f2ebba09224acdd9835e6060/src/Symfony/process/PhpExecutableFinder.php#L36 [00:18:35] maybe the handful of cases where we need it, don't warrant harcoded caching in LocalSettings.php, with the potential benefit of not breaking stuff when you upgrade PHP if you use a versioned PHP CLI. [00:18:54] on the other hand, I'm guessing we don't "just" use "php" to ensure predictable and secure outcomes. [00:19:06] avoid ad-hoc PATH resolution. [00:20:34] we could use a getter function that uses PHP_BINARY on CLI and throw outside CLI if we don't need/want to support spwaning CLI procs on web servers. [00:20:47] or include PHP_BINDIR if we do. [00:22:52] Example on toolforge, where a versioned CLI is used: php > echo PHP_BINDIR /usr/bin echo PHP_BINARY /usr/bin/php7.3; ls -halF `which php`/usr/bin/php -> /etc/alternatives/php /etc/alternatives/php -> /usr/bin/php7.3 [00:23:24] program_suffix is not provided [00:23:50] nor is EXEEXT but I suppose you could guess that (it's .exe on Windows) [00:24:07] yeah, as-is doesn't seem reliable in theory, if there are multiple, PHP_BINDIR/"php" will bring you to the default alternative. [00:29:29] a patch to provide the full path to the CLI binary including program_suffix might be accepted upstream [00:30:10] the build system is not necessarily right, but there is PHP_BINDIR as an excuse or analogy to get it through code review [00:30:30] it would probably work on Debian [00:34:40] but configuration is a pretty cheap and easy solution if hardly anyone is using this [01:26:19] [[Tech]]; AntiCompositeNumber; /* OpenStreetMap does not work anymore */ Reply; https://meta.wikimedia.org/w/index.php?diff=26462855&oldid=26459384&rcid=30527769 [01:26:31] lol [06:10:41] Servers down [06:21:51] Hey I was getting timeouts on en.wp a few minutes ago. It looks like it's stopped now, but I just wanted to see if reporting would be desired, I have the error message [06:22:27] just trying to be a helpful wikizen :) [10:01:13] [[Tech]]; 72.255.3.43; /* Mediawiki latest file download problem */ new section; https://meta.wikimedia.org/w/index.php?diff=26463773&oldid=26463317&rcid=30530308 [14:35:14] [[Tech]]; Sbb1413; /* OpenStreetMap does not work anymore */ Reply; https://meta.wikimedia.org/w/index.php?diff=26465133&oldid=26463773&rcid=30532865 [15:09:22] [[Tech]]; AKlapper (WMF); /* Mediawiki latest file download problem */; https://meta.wikimedia.org/w/index.php?diff=26465184&oldid=26465133&rcid=30533119 [15:10:37] [[Tech]]; AKlapper (WMF); /* OpenStreetMap does not work anymore */; https://meta.wikimedia.org/w/index.php?diff=26465187&oldid=26465184&rcid=30533122 [15:17:36] [[Tech]]; Sbb1413; /* OpenStreetMap does not work anymore */ Reply; https://meta.wikimedia.org/w/index.php?diff=26465201&oldid=26465187&rcid=30533183 [15:18:21] [[Tech]]; Sbb1413; /* OpenStreetMap does not work anymore */; https://meta.wikimedia.org/w/index.php?diff=26465203&oldid=26465201&rcid=30533186 [15:20:04] [[Tech]]; Sbb1413; /* OpenStreetMap does not work anymore */ Reply; https://meta.wikimedia.org/w/index.php?diff=26465205&oldid=26465203&rcid=30533195 [15:53:24] [[Tech]]; AKlapper (WMF); /* OpenStreetMap does not work anymore */; https://meta.wikimedia.org/w/index.php?diff=26465542&oldid=26465205&rcid=30533711 [21:28:57] My Wikimedia gitlab account appear to have gotten relocked, is this expected ? :( [21:29:05] `New signins require approval; you can file an unlock request to expedite access. Support: #wikimedia-gitlab on libera.chat, #GitLab on Phabricator, how to host a project on GitLab.` [21:30:57] > Support: #wikimedia-gitlab on libera.chat [21:32:12] Yep, banner blindness on my end :) [21:49:18] For anyone following along with Sohom_Datta's issue: we updated the global banner about GitLab account registration yesterday to fix a problem where it was not being shown to folks who actually needed to get their accounts approved. As a side effect the dismissible banner is showing up on all screens for everyone again until they dismiss it. https://phabricator.wikimedia.org/T353752#9659409 [22:02:11] thanks, got it too and this was helpful [23:08:07] apaskulin: I've updated the old-style md_docs_* links via https://www.mediawiki.org/wiki/Special:LinkSearch?target=https%3A%2F%2Fdoc.wikimedia.org%2Fmediawiki-core%2Fmaster%2Fphp%2Fmd [23:08:18] https://www.mediawiki.org/wiki/Special:Contributions/Krinkle [23:08:33] and marked the 2 pages in question for translation, so the subpages should propagate in a few minutes [23:09:16] Krinkle: Awesome, thanks!