[18:44:09] TimStarling: the H5dep README.md says it requires maven2, but when I ran `mvn package`, I got: "[INFO] Error resolving version for 'org.apache.maven.plugins:maven-compiler-plugin': Plugin requires Maven version 3.0". I had to uninstall the maven2 package and install maven. This is on Ubuntu 15.04. [18:57:14] ori: that is for html5depurate right? It depends on 'maven' which on both Jessie and Trusty bring in maven 3 [18:57:53] yes, but the README says: Ubuntu build/test dependencies: * openjdk-7-jdk * maven2 * jsvc [18:57:59] ah [18:58:12] so yeah trust debian/control , should be amended to state maven3 [18:58:19] nod [19:01:30] Sigh. Is there any way to tell composer that I really don't want it to try to screw around with extensions/AntiSpoof, no matter that something else's composer.json claims to require it? [19:07:32] anomie: cf https://phabricator.wikimedia.org/T67188#1509715. You could try running composer with --no-plugins, which should prevent composer-merge-plugin from running, which should in turn stop composer from recursing through something else's composer.json [19:08:23] ori: Although that means that the dependencies for the extensions' composer.json wouldn't be installed, which will probably break those extensions. [19:08:28] Or will it? [19:09:03] dunno, I guess it depends [19:09:03] iirc some extensions had other extensions listed as dependencies in composer, can it be your problem? [19:09:42] it might be a load order problem. Ie you have extension A depending on B [19:09:50] you have both A and B available [19:10:11] maybe composer process A first, resolve B and fetch it from packagist before it had a chance to find the B ext on the local disk [19:10:12] yes, this is jeroen's fantastically bad idea. bd808 tried to make things better with composer-merge-plugin but I think you can't gloss over two different ways of thinking about composer this way, as jeroen himself seems to have recognized [19:10:14] (pure speculation) [19:10:49] well we were composer newbies back at that time :D [19:11:03] (composer-merge-plugin is very useful and we should keep it, don't get me wrong) [19:11:10] one idea was that one would download mediawiki then composer add extension/foo [19:11:16] and everything would be sorted out magically [19:11:49] eventually legoktm / bd808 found out that resolving deps with composer would not work for us [19:11:52] yes, it was a bad idea; composer is for installing dependencies, not extensions, which are a different thing [19:12:00] and we went with composer-merge-plugin and the extension registry [19:12:05] jeroen threw a tantrum [19:12:17] so imho, any composer.json referencing an extension as a dependency is a bug and they should be removed [19:12:29] agreed [19:12:52] then dont blame Jeroen :) [19:12:57] err [19:13:05] sorry my english is crap let me rephrase that [19:13:20] "I would not blame Jeroen or anyone involved in composer a few years ago" :D [19:14:22] actually I am the one to blame for suggesting that back in 2012 ( https://www.mediawiki.org/w/index.php?title=Composer&oldid=743849 ) [19:14:57] TranslationNotification require mediawiki/translate [19:14:59] eek [19:15:31] ahhhhhhhhhhhhhhhhhhhhhhhhhh [19:15:54] that version is my last edit on the page [19:16:13] that was really a rough experiment [19:16:37] then a year or so after, Jeroen stepped in and added composer on most of the repo he managed \o/ [19:17:15] we need a Chief Operating Historian [19:18:12] hashar: In my case, the problem is AbuseFilter requiring mediawiki/anti-spoof [19:20:20] "mediawiki/anti-spoof": "dev-master" [19:20:21] yeah [19:20:24] should be dropped [19:20:49] and that dependency expressed in extension.json I think [19:21:02] legoktm would know for sure [19:22:49] anomie: comes from https://gerrit.wikimedia.org/r/#/c/48836/ [19:22:59] Feb 2013 [19:24:16] and [19:24:17] The key of the requires object is the name of the dependency (currently only MediaWiki supported), [19:24:22] from https://www.mediawiki.org/wiki/Manual:Extension_registration#Requirements_.28Dependencies.29 [19:26:28] is anybody present here who could explain to me how CSRF tokens are working? [19:28:08] SMalyshev: Maybe. What exactly do you want to know about them? [19:28:51] anomie: well, I understand when I do modifying action via API, I supposed to get a token, right? [19:28:59] anomie: and the API to use seems to be https://en.wikipedia.org/w/api.php?action=query&meta=tokens&format=json [19:29:04] date -R [19:29:13] but every time I call it I receive token of "+\\" [19:29:28] SMalyshev: If you get a token of "+\", you're not logged in. [19:29:30] so I'm not sure if I'm doing anything wrong or it's supposed to be this way? [19:29:44] ahh, ok. So all anonymous edits get the same token> [19:29:45] ? [19:30:17] Yeah. [19:30:18] yeah. there's a task about changing it somewhere. [19:30:41] aha, ok. I just wanted to make sure I'm not doing something wrong [19:31:12] so any anon edit can just supply token of "+\" and it be fine I understand [19:32:32] T40417 is the task, but it's private. [19:41:25] I wonder if it would make sense to vary it at least with time... [19:56:06] Wouldn't do very much good, it'd just be ever-so-slightly harder for an attacker to abuse it. [19:58:21] still harder than now :)