On Tue, Mar 1, 2016 at 3:36 PM, David Strine <dstrine(a)wikimedia.org> wrote:
> We will be holding this brownbag in 25 minutes. The Bluejeans link has
I'm not familiar with bluejeans and maybe have missed a transition
because I wasn't paying enough attention. is this some kind of
experiment? have all meetings transitioned to this service?
anyway, my immediate question at the moment is how do you join without
sharing your microphone and camera?
am I correct thinking that this is an entirely proprietary stack
that's neither gratis nor libre and has no on-premise (not cloud)
hosting option? are we paying for this?
-----BEGIN PGP SIGNED MESSAGE-----
I (with Reedy's help) recently started work on librarizing MediaWiki's
IP class into a separate composer package (wikimedia/ip-utils). The
main motivation was so that the Parsoid PHP port could use it.
However, I ran into an unexpected hitch, as it seems we're using
the IP class before the composer autoloader is even intialized. Here's
the basic initialization in Setup.php:
- - AutoLoader.php (MediaWiki's)
- - Defines.php
- - DefaultSettings.php
- $wgServer = WebRequest::detectServer()
- Calls IP::splitHostAndPort()
- - GlobalFunctions.php
- - vendor/autoload.php (composer's)
My understanding is that composer's autoloader runs late so extensions
registering themselves using it can add their stuff to the necessary
And we call WebRequest::detectServer() in DefaultSettings.php so that
in LocalSettings.php people can use the value of $wgServer for other
I see 3 main ways to move forward:
1. Move vendor/autoload.php earlier in Setup.php, potentially breaking
extensions that still rely on composer autoloading for initialization.
2. Set $wgServer = false or something in DefaultSettings.php, and then
fill it in later in Setup.php *after* the composer autoloader has been
loaded, potentially breaking anyone relying on the value of $wgServer
3. (status quo) not librarize code that runs before composer
autoloader initialization. :(
- -- Legoktm
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
It's time for Wikimedia Tech Talks 2019 Episode 6!
Next month's talk will take place July 10, 2019 at 4:00 PM UTC.
Topic: A Deployment Pipeline Overview
Speaker: Alexandros Kosiaris, Senior Operations Engineer
Summary: The deployment pipeline project has been ongoing for a while,
sometimes with more resources poured into it, sometimes less, but it's
finally in a state that is ready to be used (it's already being used!).
This tech talk is about a presentation to wider technical audiences,
discussing the goals of the project, the implementation decisions and
how it's meant to be used and adopted by the deployers of services
(and eventually MediaWiki) in the coming months.
YouTube stream for viewers: https://www.youtube.com/watch?v=i0FTcG7PxzI
During the live talk, you are invited to join the discussion on IRC
Those in the SF office can watch this in R124.
You can watch past Tech Talks here:
If you are interested in giving your own tech talk, you can learn more here:
(Standing in for Sarah Rodlund who is currently away on sabbatical)
I'm getting a new error today that was not happening with the identical
With MW 1.31.1 and 1.31.2 I'm getting errors after installing dependencies
and extensions with Composer. I have the following composer.local.json:
"pear/net_smtp": "1.8.0" <-- remove this when using MW 1.31.2
SyntaxHighlight_GeSHi and Elastica are both tracking their REL1_31
branches, which haven't changed in about a year. Despite that, yesterday
running `composer update` caused no issues. Today I started getting the
[Wed Jun 26 16:16:18.364715 2019] [php7:warn] [pid 12304] [client
my.ip.add.ress:46156] PHP Warning:
failed to open stream: No such file or directory in
/opt/htdocs/mediawiki/vendor/composer/autoload_real.php on line 70,
[Wed Jun 26 16:16:18.364896 2019] [php7:error] [pid 12304] [client
my.ip.add.ress:46156] PHP Fatal error: require(): Failed opening required
in /opt/htdocs/mediawiki/vendor/composer/autoload_real.php on line 70,
Using MW 1.32.1 and 1.31.2 I did the following:
rm -f ./composer.lock && composer install && sudo systemctl reload httpd
# no mention of phpstorm-stubs in output
# page loads fail
rm -f ./composer.lock && composer install --no-dev && sudo systemctl reload
# output includes: Removing jetbrains/phpstorm-stubs (dev-master)
# page loads succeed (no phpstorm-stubs)
composer install && sudo systemctl reload httpd
# output includes: Installing jetbrains/phpstorm-stubs (dev-master
9d01ce3): Cloning 9d01ce3476
# page loads succeed (phpstorm-stubs @ 9d01ce3)
composer update && sudo systemctl reload httpd
# output includes: Updating jetbrains/phpstorm-stubs dev-master (9d01ce3 =>
1b99060): Checking out 1b9906084d
# page loads fail (phpstorm-stubs @ 1b99060)
I need the httpd reload to invalidate opcache in my config. Based upon the
above it seems that the phpstorm-stubs that is getting required from
non-dev dependencies doesn't have issues, but the one from dev dependencies
does. Or perhaps something to do with Composer or with the Composer merge
plugin is causing one version of phpstorm-stubs to be checked out but the
autoloader to be setup for the other version. Any thoughts?
I wanted to restart the thank you Tuesday thread for this week. So heres my list of thanks:
Paladox, and releng, for all you do for maintaining Gerrit, Phabricator, and CI so we can keep making so many needed changes to mediawiki and other software/projects.
Andre, for sorting through hundreds if not thousands of tickets every day, without him, I’m sure phab would be a mess of unsorted tasks!
Finally, thanks to all the volunteers and staff that are constantly deploying, and creating patches to make MediaWiki and related projects as bug-free and user friendly as possible.
Devin “Zppix” CCENT
Volunteer Wikimedia Developer
Africa Wikimedia Developers Member and Mentor
Volunteer Mozilla Support Team Member (SUMO)
Quora.com Partner Program Member
**Note: I do not work for Wikimedia Foundation, or any of its chapters. I also do not work for Mozilla, or any of its projects. **