|
2019-08-28 14:00:28
|
<wm-bot>
|
Technical Advice IRC meeting starting in 60 minutes in channel #wikimedia-tech, hosts: @bd808 - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
|
|
2019-08-28 14:03:11
|
<ToAruShiroiNeko>
|
I question your questions. :p
|
|
2019-08-28 14:03:39
|
<Lucas_WMDE>
|
only one host today? (I can’t help out, unfortunately, I’ll be in a meeting)
|
|
2019-08-28 14:04:02
|
<ToAruShiroiNeko>
|
It would be ironic if you were meeting the host, no?
|
|
2019-08-28 14:04:29
|
<ToAruShiroiNeko>
|
I mean meeting the host during your meeting
|
|
2019-08-28 14:50:12
|
<wm-bot>
|
Technical Advice IRC meeting starting in 10 minutes in channel #wikimedia-tech, hosts: @bd808 - all questions welcome, more infos: https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
|
|
2019-08-28 14:56:59
|
<bd808>
|
Lucas_WMDE: I can probably survive solo, but if there is anyone in the WMDE office that can join me that would be appreciated :)
|
|
2019-08-28 14:59:51
|
<Reedy>
|
"The cleaning lady is in a bit early today"
|
|
2019-08-28 15:01:17
|
<bd808>
|
waits for the bot to notice the time
|
|
2019-08-28 15:02:04
|
<AntiComposite>
|
nudges wm-bot
|
|
2019-08-28 15:03:18
|
<apergos>
|
bad bot!
|
|
2019-08-28 15:03:45
|
<bd808>
|
Ok folks, the bot is AWOL but it is still TAIM time!
|
|
2019-08-28 15:04:01
|
<apergos>
|
I have a question about compser use, since I basically am not a mw dev but only play one on wmf tv :-P
|
|
2019-08-28 15:04:06
|
<bd808>
|
I'm a solo host today, but I see other awesome folks idling in the channel too
|
|
2019-08-28 15:04:36
|
<bd808>
|
apergos: I know some things about Composer. What's your question?
|
|
2019-08-28 15:05:08
|
<apergos>
|
I git pulled and checked out 1.34-wmf.19, then removed vendor and the composer lock files and tried composer install/update
|
|
2019-08-28 15:05:42
|
<apergos>
|
I got the dreaded fail "would ocnflict with minimum stability requirements" message
|
|
2019-08-28 15:06:17
|
<apergos>
|
the conflict was in top level symfony/yaml wanting 3.4.8 and in wikimedia/smash-pig wanting ^2.8
|
|
2019-08-28 15:06:28
|
<apergos>
|
what's the 'right thing to do'?
|
|
2019-08-28 15:06:54
|
<apergos>
|
I did the 'wrong but got me running for now' fix, i.e. put ^2.8 at the top level composer.json file
|
|
2019-08-28 15:07:04
|
<bd808>
|
hmmm... good question for sure.
|
|
2019-08-28 15:07:42
|
<bd808>
|
do you know which extension has a composer.json that is pulling in wikimedia/smash-pig?
|
|
2019-08-28 15:08:12
|
<apergos>
|
the other thing that conflicted was DonationInterface with something-or-other and I needed to chang emonolog from 1.22.` to 1.24.0 and then everything was ok
|
|
2019-08-28 15:08:43
|
<apergos>
|
I think cirrussearch might have been implicated in the first one, iirc
|
|
2019-08-28 15:10:23
|
<bd808>
|
I *think* I remember that https://www.mediawiki.org/wiki/Fundraising_tech/SmashPig is usually on a different MediaWiki branch in production than the "main" wikis
|
|
2019-08-28 15:10:54
|
<bd808>
|
its definitely stuff in the realm of the Fundraising Tech team
|
|
2019-08-28 15:12:08
|
<bd808>
|
I'm wondering if the version mismatch is because of that, that the extension is matching an older version of MediaWiki core than the 1.34.x series
|
|
2019-08-28 15:16:04
|
<apergos>
|
what's annoying is I shuld be able to git pull/checkout then run composer and have it 'just work'
|
|
2019-08-28 15:16:13
|
<bd808>
|
oh... let's look to see which version of core the 'fundraising' role in MediaWiki-Vagrant is using! That might be the right clue
|
|
2019-08-28 15:16:15
|
<apergos>
|
instead of fiddle around and remove stuff that is actually submodules anyways
|
|
2019-08-28 15:18:00
|
<apergos>
|
933a00217017bf56eb5de3e5d42e1611389f1f54 this is the monolog change in the top level composer.json
|
|
2019-08-28 15:18:18
|
<apergos>
|
e0be7e8f26110c1ae0e32b7a176fd1649daf0dc1 for the actual patchset
|
|
2019-08-28 15:18:20
|
<bd808>
|
"fundraising/REL1_31" is the pinned branch in MediaWiki-Vagrant for the fundraising role
|
|
2019-08-28 15:18:21
|
<Reedy>
|
IIRC FR were using a newer monolog
|
|
2019-08-28 15:19:22
|
<bd808>
|
fundamentally, the Fundraising code for payment processing runs differently than the content wikis in production
|
|
2019-08-28 15:19:23
|
<apergos>
|
e000ebf010370015058a55b249c45b2f14e337a9 here is the cirrussearch yaml update for the top level composer file
|
|
2019-08-28 15:19:54
|
<bd808>
|
in part because of the PCI-DSS requirements for the environment where we handle credit card data
|
|
2019-08-28 15:20:17
|
<bd808>
|
PCI-DSS == https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard
|
|
2019-08-28 15:20:45
|
<apergos>
|
299013eb76d838fa5f6c5f353222400bebde6dfd that's the commit for smash-ping (so the yaml issue) for that composer file
|
|
2019-08-28 15:21:03
|
<apergos>
|
I think tht should be all the relevant commits for the two issues
|
|
2019-08-28 15:21:08
|
<bd808>
|
apergos: are you using the "all extensions" sub module in this environment you are testing?
|
|
2019-08-28 15:21:19
|
<apergos>
|
uh
|
|
2019-08-28 15:21:34
|
<apergos>
|
beats me what the heck I am using :-D
|
|
2019-08-28 15:21:53
|
<bd808>
|
heh. ok.
|
|
2019-08-28 15:22:09
|
<bd808>
|
goes to look at the 1.34-wmf.19 tree
|
|
2019-08-28 15:22:27
|
<apergos>
|
I see a bunch of submodules separately configured in my .git/config and i'm sure i didn't add them
|
|
2019-08-28 15:22:48
|
<apergos>
|
I probably did some sort of recursive pull across all submodules and it gave me whatever
|
|
2019-08-28 15:25:39
|
<bd808>
|
the pinned submodules for 1.34-wmf.19 are at https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/wmf/1.34.0-wmf.19/.gitmodules
|
|
2019-08-28 15:25:58
|
<apergos>
|
looks like wht I have
|
|
2019-08-28 15:26:09
|
<apergos>
|
you see CirrusSearch and DonationInterface in there
|
|
2019-08-28 15:27:42
|
<apergos>
|
because I'm not even sure what the 'right' workflow for composer is (like, I've never actually read the docs or anything) I'll just shut up now and let you folks explain what I should be doing...
|
|
2019-08-28 15:28:18
|
<bd808>
|
its complicated honestly
|
|
2019-08-28 15:28:52
|
<bd808>
|
the way that Composer is used in MediaWiki is "special" and not quite what a normal Composer workflow would look like
|
|
2019-08-28 15:29:04
|
<apergos>
|
I don't know a normal one either :-D
|
|
2019-08-28 15:29:39
|
<bd808>
|
We manually curate the mediawiki/vendor repo as a frozen version of libraries that are used in the Wikimedia production wikis
|
|
2019-08-28 15:30:11
|
<bd808>
|
in part because of this potential for version conflicts for libraries when you are using a arbitrary group of extensions
|
|
2019-08-28 15:30:12
|
<apergos>
|
but you don't provide lock files, just the composer.json files
|
|
2019-08-28 15:30:36
|
<apergos>
|
the vendor repo is not part of the git repo is it?
|
|
2019-08-28 15:30:38
|
<bd808>
|
there is a lock in mediawiki/vendor, but not in mediawiki/core
|
|
2019-08-28 15:30:50
|
<apergos>
|
huh
|
|
2019-08-28 15:31:02
|
<apergos>
|
well I outright removed mediawiki/vendor out of desperation
|
|
2019-08-28 15:33:39
|
<bd808>
|
this is the composer.lock that would be used in production with the 1.34-wmf.19 branch -- https://github.com/wikimedia/mediawiki-vendor/blob/wmf/1.34.0-wmf.19/composer.lock
|
|
2019-08-28 15:34:07
|
<bd808>
|
and here is the composer.json that would have gnerated that lock at some point in time -- https://github.com/wikimedia/mediawiki-vendor/blob/wmf/1.34.0-wmf.19/composer.json
|
|
2019-08-28 15:34:35
|
<bd808>
|
which interestingly... does not include smashpig at all...
|
|
2019-08-28 15:35:30
|
<apergos>
|
"conflict": { "symfony/config": "<2.8", "symfony/dependency-injection": "<3.4", "symfony/yaml": "<3.4" },
|
|
2019-08-28 15:35:34
|
<apergos>
|
what does that bit mean?
|
|
2019-08-28 15:35:42
|
<apergos>
|
(sorry bad formatting)
|
|
2019-08-28 15:36:40
|
<apergos>
|
BTW if there's anyone else in here with questions, I don't mean to hog the session. I can wait til later!
|
|
2019-08-28 15:37:15
|
<bd808>
|
https://getcomposer.org/doc/04-schema.md#conflict -- that's a way that a library publisher can state things that known not to work with a given version of their library
|
|
2019-08-28 15:37:44
|
<bd808>
|
usually because they declare the same classes due to some kind of refactoring
|
|
2019-08-28 15:39:21
|
<bd808>
|
Like if myorg/foolib had a Bar class until v1.0.1 and after v1.0.1 you should be pulling in myorg/barlib instead then the myorg/barlib composer.json could declare that it conflicts with myorg/foolib <1.0.1
|
|
2019-08-28 15:39:58
|
<apergos>
|
hm hm hm
|
|
2019-08-28 15:43:12
|
<apergos>
|
./extensions/DonationInterface/composer.json this is where the smash-pig reference comes from, which leads to the bad yaml version
|
|
2019-08-28 15:43:20
|
<apergos>
|
at the top level, there is just the other (conflicting) yaml
|
|
2019-08-28 15:43:33
|
<apergos>
|
for composer.json I mean
|
|
2019-08-28 15:43:39
|
<bd808>
|
there seems to be a special vendor git repo for DonationInterface too -- https://github.com/wikimedia/mediawiki-extensions-DonationInterface-vendor
|
|
2019-08-28 15:43:47
|
<apergos>
|
huh
|
|
2019-08-28 15:43:55
|
<apergos>
|
I bet I have the submodule
|
|
2019-08-28 15:44:10
|
<bd808>
|
ejegg: can you help apergos and I understand a bit how composer works with DonationInterface?
|
|
2019-08-28 15:44:15
|
<apergos>
|
[submodule "extensions/DonationInterface"]
|
|
2019-08-28 15:44:15
|
<apergos>
|
active = true
|
|
2019-08-28 15:44:15
|
<apergos>
|
url = https://gerrit.wikimedia.org/r/mediawiki/extensions/DonationInterface
|
|
2019-08-28 15:44:19
|
<apergos>
|
.git/config
|
|
2019-08-28 15:44:22
|
<bd808>
|
appeals to authority
|
|
2019-08-28 15:44:38
|
<apergos>
|
please feel free
|
|
2019-08-28 15:45:24
|
<bd808>
|
last commit in the DonationInterface/vendor repo was March 5 and related to smashpig
|
|
2019-08-28 15:48:57
|
<apergos>
|
may 30 is the cirrussearch change to add symfony/yaml to the top level composer file
|
|
2019-08-28 15:49:05
|
<ejegg>
|
bd808: oh hey, we can delete that special repo now!
|
|
2019-08-28 15:49:31
|
<ejegg>
|
we had previously been installing composer libs for DonationInterface in its own vendor dir
|
|
2019-08-28 15:49:51
|
<ejegg>
|
but now we're using composer-merge-plugin to put them in the mw root vendor dir
|
|
2019-08-28 15:50:29
|
<ejegg>
|
let's see... bad yaml version?
|
|
2019-08-28 15:50:35
|
<apergos>
|
top level wants 3.4.something
|
|
2019-08-28 15:50:45
|
<apergos>
|
donation interface via smash-pig wants ^2.8
|
|
2019-08-28 15:50:46
|
<bd808>
|
ejegg: cool. My mostly abandonware composer-merge-plugin library is still doing some good then :)
|
|
2019-08-28 15:51:19
|
<ejegg>
|
heh, it is! We started using it for our CiviCRM install and its extensions too
|
|
2019-08-28 15:51:53
|
<ejegg>
|
OK, we can definitely bump the yaml verson for smash-pig
|
|
2019-08-28 15:52:17
|
<bd808>
|
ejegg: the story so far is that apergos checked out 1.34-wmf.19 and is trying to use `composer install` to create a vendor repo from scratch and getting version conflicts from smashing all the Extension composer.json files together using compsoer-merge-plugin
|
|
2019-08-28 15:52:37
|
<apergos>
|
I mean initially I tried composer update with whatever I had already and that barfed
|
|
2019-08-28 15:52:41
|
<bd808>
|
and we are kind of trying to stumble around and recreate why that is a problem an what the "fix" is
|
|
2019-08-28 15:52:48
|
<ejegg>
|
ok, which set of extensions is being installed?
|
|
2019-08-28 15:52:51
|
<apergos>
|
so I poked around some and then finally torched the vendor directory compeltely
|
|
2019-08-28 15:52:57
|
<apergos>
|
well whatever git pull gives me
|
|
2019-08-28 15:53:05
|
<apergos>
|
for 1.34.wmf-19
|
|
2019-08-28 15:53:18
|
<bd808>
|
ejegg: I think ... everything in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/wmf/1.34.0-wmf.19/.gitmodules
|
|
2019-08-28 15:53:22
|
<apergos>
|
I'm not going to use them all in local settings of course
|
|
2019-08-28 15:53:27
|
<bd808>
|
which honestly might be the problem
|
|
2019-08-28 15:53:43
|
<ejegg>
|
oh boy, that's a lot!
|
|
2019-08-28 15:53:49
|
<apergos>
|
but I shouldn't have to remove the ones I don't want in order to get composer to play nice
|
|
2019-08-28 15:54:05
|
<apergos>
|
because in a week I'll be right back here updating to the nextbranch for testing...
|
|
2019-08-28 15:54:08
|
<bd808>
|
I think that is the list of all extensions that are enabled in the union of all production Wikimedia wikis
|
|
2019-08-28 15:54:10
|
<ejegg>
|
right, and DonationInterface is loaded on main-cluster so banners can re-use some messages
|
|
2019-08-28 15:54:42
|
<apergos>
|
and that will be git pull (which will get all the submodules), checkout the branch and oh let's go play with composer again...
|
|
2019-08-28 15:54:45
|
<ejegg>
|
I think for a while we maintained a messages-only branch
|
|
2019-08-28 15:55:09
|
<ejegg>
|
For now, I can at least get rid of that yaml conflict
|
|
2019-08-28 15:55:49
|
<apergos>
|
ty
|
|
2019-08-28 15:56:07
|
<apergos>
|
then there's the monolog one next
|
|
2019-08-28 15:56:12
|
<apergos>
|
and after that everything is ok
|
|
2019-08-28 15:56:16
|
<Reedy>
|
Didn't we have two entry points for DI at one point?
|
|
2019-08-28 15:56:17
|
<bd808>
|
(For those of you following along in the logs or lurking in real time: this is what being a pro software engineer is like. We don't have magic powers, just search and other folks to ask quesions of.)
|
|
2019-08-28 15:56:34
|
<Reedy>
|
We should probably just bump monolog in core/vendor
|
|
2019-08-28 15:57:20
|
<ejegg>
|
ok, I think we set the monolog version in DI to match the composer.json of mediawiki's last LTS version (1.31)
|
|
2019-08-28 15:57:40
|
<ejegg>
|
I should be able to open that up enough to match the current mw version too
|
|
2019-08-28 15:57:44
|
<Reedy>
|
that conflicts with master DI and whatever MW core has?
|
|
2019-08-28 15:57:44
|
<apergos>
|
I think 1.24.0 is the one you want all around
|
|
2019-08-28 15:58:08
|
<ejegg>
|
apergos: that should work with mw 1.31 too?
|
|
2019-08-28 15:58:28
|
<apergos>
|
uh I don't know about that
|
|
2019-08-28 15:58:43
|
<apergos>
|
but 1.24.0 is the one in the top level composer.json for 1.34-wmf19
|
|
2019-08-28 15:58:51
|
<bd808>
|
falls into the rabbit hole of reading the Monolog 2.x upgrade notes and quickly backs up
|
|
2019-08-28 15:58:56
|
<Reedy>
|
https://github.com/wikimedia/mediawiki-vendor/commit/df087ef223c91fc52c6e9c515a122645e241b757
|
|
2019-08-28 15:58:58
|
<apergos>
|
yeah don't go there nopenopenope
|
|
2019-08-28 15:58:58
|
<Reedy>
|
I already did
|
|
2019-08-28 15:59:02
|
<ejegg>
|
Reedy: a loooongg time back DI was actually used on the main cluster to send donors to paypal
|
|
2019-08-28 15:59:19
|
<apergos>
|
reedy, that's the top level one
|
|
2019-08-28 15:59:23
|
<apergos>
|
it's the di one that's the problem
|
|
2019-08-28 15:59:30
|
<ejegg>
|
but then we started accepting cards and needed to go to our own little cluster to limit PCI scope
|
|
2019-08-28 15:59:43
|
<Reedy>
|
bd808: I like how monolog 2.0.0-beta1 is php ^7.1, but beta2 is ^7.2
|
|
2019-08-28 15:59:45
|
<ejegg>
|
I guess banners were already using a bunch of DI messages, so we left it installed there
|
|
2019-08-28 16:00:05
|
<ejegg>
|
though none of the configuration to show payment forms is actually present on the main cluster
|
|
2019-08-28 16:00:06
|
<Reedy>
|
"monolog/monolog": "~1.24.0",
|
|
2019-08-28 16:00:20
|
<ejegg>
|
meanwhile, our payments-cluster stick to the last LTS
|
|
2019-08-28 16:00:49
|
<bd808>
|
I don't see "Donation Interface" on https://en.wikipedia.org/wiki/Special:Version, so I'm sort of wondering where if anywhere we actually enable it outside the payment cluster
|
|
2019-08-28 16:00:51
|
<ejegg>
|
so as that ages we get a bunch of these version conflicts with core/master
|
|
2019-08-28 16:00:58
|
<ejegg>
|
oh hmm
|
|
2019-08-28 16:01:18
|
<apergos>
|
if DI could just get pulled out of the bundle, so much the better (as far as I'm concerned, maybe some folks have requested to have it in, dunno)
|
|
2019-08-28 16:01:20
|
<Reedy>
|
it's loaded into extension-list for l10n
|
|
2019-08-28 16:01:57
|
<apergos>
|
ugh
|
|
2019-08-28 16:02:42
|
<bd808>
|
the saga of trying to recreate "production" in a dev environment is an epic tail of woe and strife ;)
|
|
2019-08-28 16:03:05
|
<ejegg>
|
I can ask the banner team to list which of the DI messages they're still using
|
|
2019-08-28 16:03:07
|
<bd808>
|
*tale
|
|
2019-08-28 16:03:27
|
<ejegg>
|
if it's a small enough list we can maybe just copy them into the Mediawiki namespace on the relevant wikis
|
|
2019-08-28 16:03:27
|
<Reedy>
|
Half wonder if WikimediaMessages might be a better place for them to live
|
|
2019-08-28 16:04:00
|
<ejegg>
|
yeah, especially if there's not much overlap between usage in payment forms and usage in banners
|
|
2019-08-28 16:04:20
|
<Reedy>
|
creating a new set of folders/files in there isn't an issue
|
|
2019-08-28 16:05:06
|
<apergos>
|
bd808: you would know all about that *cough*mw-vagrant*cough*
|
|
2019-08-28 16:05:11
|
<ejegg>
|
I'll make a phab task to investigate moving the messages there so we can take DI out of the bundle
|
|
2019-08-28 16:05:17
|
<bd808>
|
blushes
|
|
2019-08-28 16:05:36
|
<apergos>
|
please drop a link here and I'll subscribe
|
|
2019-08-28 16:07:01
|
<bd808>
|
The Technical Advice IRC meeting is technically over. Tune in next week for more tracing of mysterious code paths and real-time internet searches!
|
|
2019-08-28 16:07:41
|
<bd808>
|
I don't think we solved apergos' problem, but things are looking up for the plucky adventurers.
|
|
2019-08-28 16:07:42
|
<apergos>
|
sorry to be the sole questioner!
|
|
2019-08-28 16:08:00
|
<bd808>
|
no! thanks for coming and asking questions
|
|
2019-08-28 16:08:07
|
<apergos>
|
well it's not compeltely solved but now I know I could ... open a phab task to report the conflict and that it's legit an issue
|
|
2019-08-28 16:08:20
|
<apergos>
|
I also know the intent of the mw composer files in the repo (s)
|
|
2019-08-28 16:08:22
|
<apergos>
|
so that's a win!
|
|
2019-08-28 16:09:00
|
<ejegg>
|
https://phabricator.wikimedia.org/T231474
|
|
2019-08-28 16:09:22
|
<ejegg>
|
Heh, I'm glad I decided to drop in on this meeting for once!
|
|
2019-08-28 16:10:01
|
<apergos>
|
I am too :-D
|
|
2019-08-28 16:17:51
|
<Lucas_WMDE>
|
(bd808, side note, I don’t think mw-bot ever announces the beginning of the meeting, just 60 and 10 minutes before)
|
|
2019-08-28 16:18:11
|
<bd808>
|
Lucas_WMDE: I checked the cron and I think you are correct.
|
|
2019-08-28 16:19:07
|
<bd808>
|
Lucas_WMDE: Do I need to update the TAIM page on mw.o or will somebody else do that tomorrow?
|
|
2019-08-28 16:19:39
|
<bd808>
|
just about this meeting being over and the date/time of the next one
|
|
2019-08-28 16:29:42
|
<Lucas_WMDE>
|
not sure who usually does it
|
|
2019-08-28 16:30:03
|
<Lucas_WMDE>
|
there’s been a few weeks where I only updated it after the wm-bot announcement for the next week pinged last week’s hosts :/
|
|
2019-08-28 16:30:19
|
<Lucas_WMDE>
|
but I’ll update it now
|
|
2019-08-28 22:07:14
|
<Hibgh>
|
Hi
|
|
2019-08-28 22:07:36
|
<Hibgh>
|
I'm a St. S operating system
|
|
2019-08-28 22:10:46
|
<Hibgh>
|
I'm using the CentOS 7 operating system. I have attempted to install the wiki and gave a message on your server sqlite3 the old version of installation. To use this app, you need to update to the top version. But the new version of 3.7 is not currently on the repositories of the operating system. What do I do?
|
|
2019-08-28 22:12:34
|
<Mahdi>
|
/msg NickServ identify 405371Ma@#
|
|
2019-08-28 22:14:34
|
<Mahdi>
|
Is there anyone who has answered my question?
|
|
2019-08-28 22:18:07
|
<Mahdi>
|
. Hi. Aloooo
|
|
2019-08-28 22:53:12
|
<sokote_zaman>
|
Hi. Can you Speaking Persian?
|
|
2019-08-28 23:11:09
|
<wm-bot>
|
I will let you know when I see Mahdi and I will deliver that message to them
|
|
2019-08-28 23:11:09
|
<bd808>
|
@notify Mahdi Your best chance is probably to switch to using MySQL or MariaDB as the database instead of sqlite3. Better performance, and better support in the codebase itself.
|
|
2019-08-28 23:12:39
|
<Niharika>
|
o/ Hi. I'm unable to create a task on phabricator. Keep getting the error "Request ID is required". Anyone know what's up?
|