[00:18:44] gn8 folks [00:19:57] Romaine: see http://www.mediawiki.org/wiki/Extension:ArticleFeedback (or use the search-function of that wiki) [01:15:00] is there a global CSS file for skins such sd vector, monobook, etc or are they all set on each wiki? [01:29:58] Soapy, set on each wiki at the moment [01:30:19] really? huh [01:30:42] You mean the customisations right? Not the CSS files provided by the software [01:30:57] no, I mean the "core" CSS [01:31:01] that supposedly has a bug in it atm [01:31:15] The files in MediaWiki core are on all wikis [01:31:21] is that just rolled out from wikimedia,org or something [01:31:33] Though they may be running different versions of the software at different times [01:34:43] if it has a bug, can you tell us what the bug is instead of musing over where the files might be served from? [01:35:26] it's being worked on [01:36:38] http://en.wikipedia.org/wiki/Wikipedia:VPT#New_color_on_the_edit_tabs.3F [01:36:55] bottom of that section says it will be fixed shortly [01:37:07] whether it counts as a bug or not I guess is a matter of definition [01:39:12] that was half a day ago [01:42:01] ah [01:42:04] tiem flies [01:42:08] even time [01:45:37] I can't find any bug for it [01:45:52] so I guess whoever told Edokter that it was going to be fixed shortly was incorrect [01:47:34] I'm sure they'll live [01:50:33] \but anyway, the "core" files are on mediawiki.org? [01:50:43] so it's not even on meta or something [01:51:02] What? [01:51:34] monobook [01:51:50] he's asking if monobook is part of meta [01:54:54] the problem is probably specific to wikipedia [01:55:26] I see in firebug that the background of those tabs is calculated through about 5 layers of specificity overrides [01:55:40] probably one of them broke somehow [01:55:53] the light blue probably comes from the https://en.wikipedia.org/wiki/MediaWiki:Monobook.css [01:56:07] search for "light blue section" [01:56:51] Strange bug just came up in -stewards: https://test.wikipedia.org/wiki/Special:ListUsers/checkuser - some people listed there don't have CU [01:58:10] Krenair: For example? [01:58:21] Read the groups next to the users [01:58:29] Refreshing it made one disappear [01:58:31] Snowolf is a steward. [01:58:37] I know he is, Brooke [01:58:44] There was someone else in the list [01:58:52] Yeah they just removed their CU right [01:58:55] Reedy: that was bsadowski, he removed cu from himself [01:59:06] I kept mine, but it doesn't show up [01:59:08] nor do I have access to the tool [01:59:23] ha! i lost admin on test.wiki because of inactivity [01:59:43] Krenair: You're not good at explaining bugs. The bug is that CheckUser is installed but we stewards do not have access to it (rights don't show, etc.) [02:00:07] [bureaucrat,checkuser,sysop,*,user,autoconfirmed,patroller] [02:00:13] The API thinks Snowolf is a CheckUser. [02:00:23] Bsadowski1, I'm pretty sure the fact that you appear on the list but do not have CU listed next to your name is a bug. [02:00:28] Brooke: And yet we can't access Special:CheckUser [02:00:35] https://test.wikipedia.org/wiki/Special:UserRights/Snowolf [02:00:35] Weird. [02:00:36] Reedy: pretty much I granted myself CU from meta to perform a check; I have done so in the past without issue; this time despite the granting being performed correctly, I am not listed on the user list as one, despite being on the list, and I have no access to the CU interface [02:00:38] Krenair: There is more to it [02:00:50] The whole not being able to access the CU tool problem is probably part of the issue, Bsadowski1 [02:00:50] Yeah, file a bug. [02:02:02] Brooke: should I file it under the cu extension? [02:02:02] or? [02:02:18] Wikimedia problem. [02:02:26] Wikimedia --> General/Unknown is fine. [02:02:46] It seems like a test.wikipedia.org weirdness issue. [02:04:17] Just put it anywhere and somebody will fix it. [02:04:29] ^ [02:04:31] bug has been filed. [02:04:38] https://bugzilla.wikimedia.org/show_bug.cgi?id=41772 [02:04:49] QueenOfFrance: ty! [02:09:09] Bsadowski1, are you guys completely unable to perform a check on that wiki at the moment? [02:09:42] "You do not have permission to check user's IP addresses and other information, for the following reason: [02:09:42] The action you have requested is limited to users in the group: CheckUsers. [02:09:42] " [02:09:50] Yes, as you can tell. [02:09:52] :| [02:10:19] (show/hide) 20:02, 4 November 2012 Bsadowski1 (talk | contribs | block) changed group membership for User:Bsadowski1@testwiki from editor and reviewer to editor, reviewer and CheckUser (Testing a bug) [09:06:01] andre__: have you seen https://bugzilla.wikimedia.org/show_bug.cgi?id=39644 ? [09:15:09] Nemo_bis: yeah, but how many requests are there for such a component? if it's just a few I'd stay with General/Unknown [09:17:40] andre__: it's not only about number [09:18:02] look at https://bugzilla.wikimedia.org/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=Shell%3A%20All%20Open%20Requests&sharer_id=9593 [09:18:35] they are all shell requests, but some are complex maintenance scripts and some easy config changes [09:19:49] the result is that old easy stuff gets buried and that complex stuff is never handles by shell users because they look at the list only when they're in "config changes mood" [09:19:59] *handled [09:20:21] anyway, just clarifying the component description (or name?) would be a good step :) [09:21:47] Nemo_bis, I see. Do you have anybody in mind who should be default CC for such a new component? [09:23:45] Or do you know who renamed it? [09:23:55] I hate the fact that I don't have a log for this... :( [09:24:49] andre__: there's nobody in charge (that's another issue) and I've no idea who changed the component name or when [09:24:53] probably Reedy? [09:25:47] that might be part of the problem: a huge amount of people having admin rights in Bugzilla (not an issue per se) but some of them "just change it", without telling others (yet) [09:27:59] Nemo_bis: i think it was hashar or hex that changed that one [09:28:07] reedy would have changed it ages ago [09:28:12] if that was the case [09:29:27] Nemo_bis: I think I'd prefer if you could bring that problem up in a bigger audience (wikitech-l?), because just renaming the component or creating a new one doesn't mean that somebody would handle the requests, but that's part of the problem [09:31:35] p858snake|l: it was ages (as in months) ago [09:31:58] i'm more than aware of that Nemo_bis [09:32:04] andre__: well clarifying the description doesn't seem bad nor require it [09:32:05] p858snake|l: ok [09:33:07] Nemo_bis: sure, but if somebody change the name of the component s/he probably had an idea why, and I'd like to discuss if it was really useful, before I just revert that change [09:38:23] andre__: ok, so I've added some people to cc and asked clarification [09:38:43] Nemo_bis, and I'll add it to my todo-list so I won't forget. Thanks :) [09:38:51] btw I seem to completely ignore the rule "don't add others to cc" which is in the bugzilla usage docs :p [09:38:58] Nemo_bis, that rule is bullshit [09:39:15] andre__: thanks for making it less stringent [09:39:42] you cannot generalize. I also try to avoid adding people, but it really depends on the person you add and how s/he is able to handle bugmail. [09:39:59] quite often adding the right person to cc resolves years-old bugs [09:40:04] which might even boil down to an ignorant "not my problem, protest if you don't want me to add you" [09:40:09] exactly. [09:40:27] so if anybody ever complains, send them to me :D [09:40:42] for instance Wikimedia>General is a horrible mess but by adding the right person to cc I was able to get many bugs closed [09:40:56] it is, and I need to triage the tickets in there at some point :( [09:41:17] (or rather "we", thinking in terms of a bugsquad) [09:41:27] the problem is that to do so one needs to know more or less all the WMF/Wikimedia internal organisation :p [09:41:47] although some bugs are just in the wrong component [09:41:48] Nemo_bis, yes, and I'm afraid that will take me another year [09:42:01] feel free to move wherever you feel safe :) [14:15:53] has wikitech lost some interwikis? like RT: and bugzilla: https://wikitech.wikimedia.org/view/Server_admin_log [14:16:14] maybe mutante or TimStarling would know as they updated the wiki? [17:19:34] j^: https://bugzilla.wikimedia.org/show_bug.cgi?id=41761 [17:19:35] Should I just update to master again and deploy? [17:25:54] Reedy: yes please update MwEmbedSupport and TimedMediaHandler to master [17:26:54] I won't bother updating 1.21wmf2, enwiki is due to be upgraded today [17:27:19] I'm not quite sure when, due to timezone changes [17:27:51] any other wiki still running 1.21wmf2 after upgrade today? since we also want to enable TMH on all wikis but commons [17:28:31] during the deployment window in 30 minutes i think [17:30:14] Reedy: I would assume 11am PST, so an hour later than last week [17:30:31] yeah, I was thinking it should be the later time like "usual" [17:31:02] hey j^ in the rt ticket you filed, you mean that tmh1/2 aren't getting updated when code is pushed, yes? [17:31:18] Based on what I saw in the SAL by apergos earlier... I think that's the case [17:31:34] "11:38 apergos: synced apache/common-local by hand to tmh1 and tmh2 and restart job runners on both hosts (the directory was previously empty)" [17:32:07] I will put them in the mediawiki-installations dsh group [17:32:07] that should solve [17:32:39] notpeter: yes, first they did not have any mediawiki code, and yes i guess adding to group should be all thats needed [17:33:15] j^ yeah, if they're up and running now, then added them to the dsh group should be what's required for them to continue running properly [17:33:30] ok, added [17:33:36] I'm going to close the ticket, but feel free to ping if anything else is amiss [17:34:08] Might need/want another manual sync-common to make sure they're upto date [17:34:20] sure [17:34:37] lol notpeter [17:34:37] tmh2: rsync: failed to set times on "/apache/common-local/php-1.21wmf3/extensions/TimedMediaHandler/resources": Operation not permitted (1) [17:34:37] tmh2: rsync: mkstemp "/apache/common-local/php-1.21wmf3/extensions/TimedMediaHandler/MwEmbedModules/EmbedPlayer/.EmbedPlayer.loader.js.pL1BFZ" failed: Permission denied (13) [17:34:42] :/ [17:34:53] seeing similar errors for boht [17:34:57] * Reedy waits for the sync to finish [17:35:09] I presume I'll be able to log into those boxes.. [17:35:17] no idea how they were set up.... [17:35:27] running sync-common on tmh1 [17:36:00] reedy@tmh2:~$ sync-common [17:36:00] install: cannot change owner and permissions of `/usr/local/apache/uncommon': No such file or directory [17:36:00] Unable to create /usr/local/apache/uncommon, please re-run this script as root. [17:36:04] yeah [17:36:21] Ownership should be mwdeploy:mwdeploy on everything [17:36:32] Which... it's not! [17:36:39] ah, gotcha [17:37:05] do I need to fix locally? [17:37:07] or can this be fixed on fenari? [17:37:13] Needs fixing locally [17:37:21] Well, unless running sync-common as root fixes it [17:37:25] didn't [17:37:57] chown -R mwdeploy:mwdeploy /usr/apache/common-local [17:38:03] then run sync-common again.. [17:43:13] Reedy: that is inconsistent with the other perms. you sure about that? [17:43:24] Other perms where? [17:43:57] currently everything in /usr/apache/common-local is mostly reedy:wikidev [17:44:00] Yeah, exactly [17:44:05] Which is the same as it is on nfs [17:44:32] ok, cool [17:44:38] So needs to be wikidev [17:44:46] *mwdeploy [17:46:24] Reedy: ok, done [17:46:41] sync-commons done, I mean [17:47:39] Looks good [17:52:46] Reedy: are all 1.21wmf2 wikis updated to php-1.21wmf3 today? [17:52:53] No, unfortunately [17:53:05] if not would be good to also sync TMH master to 1.21wmf2 [17:53:05] I've made a commit to update it, going to deploy it in a few minutes [17:53:05] Yup [17:53:21] see my question on #-operations :) [17:54:13] the hell [17:54:27] I just got served a page in russian by wikidatawiki [17:54:27] Has it frozen over? [17:54:29] Krenair_: Known caching issue [17:54:31] Logged out? [17:54:43] * Krenair_ logs in [17:54:59] Related to ULS [18:07:45] hi j^, mdale, AaronSchulz [18:08:14] robla: hello [18:08:34] hi [18:08:34] are all of the bugfixes we need deployed now? [18:08:40] you mean merged? [18:09:06] merged+deployed [18:09:11] yes all bugfixes are deployed on 1.21wmf2 and 1.21wmf3 [18:09:26] cool, thanks j^ [18:09:27] yay, nice. [18:10:21] \o/ [18:13:34] notpeter: the tmh1 and 2 had never been synced [18:13:51] so I did that. as t the dsh groups, the rt ticket is there more to remind us that we need a way to maintain those [18:14:04] other than manual additions [18:14:15] that's all I had in mind [18:14:22] I habeeb that there is a ticket to gen dsh groups from puppet... [18:15:06] ok, cool [18:19:12] AaronSchulz: time to deploy TMH to non-commons sites? [18:19:25] I suppose [18:20:25] robla: not RIGHT now, but http://wikitech.wikimedia.org/view/Deployments#Upcoming_holidays_.2F_other_events - Monday employees are off for Veterans' Day so should we move the Mon 12 Nov deployments to Tues 13 Nov? [18:21:13] * ^demon won't be off [18:21:46] sumanah: will deal with that later [18:21:53] k [18:22:06] Reedy: searchidx1001 still wonk ;) [18:25:25] sumanah: There seems to be a precedent for Reedy deploying stuff anyway on holidays :) I've sort of started assuming the deployment train stops for nothing, and I'm curious to see what's gonna happen come Christmas [18:25:43] Christmas day is a tuesday ;) [18:26:06] "your christmas present: 1.21wmf9" or whatever [18:26:22] so, new year's is a tuesday then [18:26:26] so at least one has a present [18:29:15] j^: mdale: http://fr.wikipedia.org/wiki/Ours_blanc#Comportement <-see video [18:29:23] apergos: About? Is there somewhere I can put an adhoc database dump of wikidatawiki? [18:29:29] I am here [18:29:38] I do see the video [18:29:38] for whom? [18:29:55] 1.4GB uncompressed, 27MB compressed [18:29:55] is it supposed to be downloadable by the world or you just want to stash a copy in case things explode? [18:29:57] all deployed. next up, transcoding and commons :) [18:30:17] note we do xml dumps of it already [18:30:28] http://de.wikipedia.org/wiki/Benutzer:JanGerber/commonstest looks like it works [18:30:29] Yeah, the first one only has 3 revisions of Main page [18:30:30] or maybe that was you who pointed it out to me :-D [18:30:44] It's going to be a few weeks before the next one... [18:30:44] * robla may drop off of IRC for a couple of minutes [18:30:44] a few weeks? [18:30:45] what? [18:30:53] j^: output in rt [18:31:09] 1.5 weeks maybe [18:31:16] robla: we going to try and get test2 transcodes running today? [18:31:16] Hmm [18:31:32] mdale: that's what notpeter's message is about [18:31:35] i thought it was end of the month/start of dec for the next one [18:31:48] enwiki [18:31:48] once a month [18:31:50] the rest on a rolling basis [18:31:52] Ohh [18:32:03] small ones get a bit more often than the big ones cause dewiki takes too long [18:32:13] Yeah [18:32:23] wikidata is "small" :-D [18:32:24] Wikidatawiki took about 10 minutes on fenari for all revisions etc [18:32:55] 10-23, 11-05 seems to be the spacing for small dumps [18:33:01] 12 days [18:34:15] ffs, nosebleed [18:34:19] ugh [18:35:02] they're getting regular again. Since a medication decrease :/ [18:35:09] uh oh [18:35:16] time to see the dr again? [18:37:00] just a fyi, the first dump runs are usually very tiny because we pick up the wiki as soon as it shows up in the db list and there's a worker ready to run a new job [18:37:14] Ahh [18:37:16] makes sense [18:37:16] the next one, 10 or so days later, will have more substance [18:37:21] if there has been editing [18:37:30] and so the cycle goes :-) [18:37:46] all automated, thank brion for the way that part of it works [18:37:48] yay [18:37:52] I think so.. Or I just revert the medication decrease, which is what he's told me to do previously [18:38:06] ah, if you already know that's ok, sounds sensible [18:38:19] though seeing him anyways might not be a bad idea [18:38:22] or call anyways [18:39:08] gonna wander off in search of dinner, I'll check in again in a bit [18:39:10] later [18:39:18] wikitech wiki has indeed forgotten the interwiki links, but the table in db is there and has the entries [18:39:25] are you low on platelets ? [18:39:27] it is called mw_interwiki [18:39:41] hoi [18:39:42] just got an error: "[6c972cc9] 2012-11-05 18:39:03: Fatal exception of type MWException" [18:39:43] may it be configured somewhere to look for interwiki without the prefix? [18:39:49] odder: where? [18:40:03] Platonides: I know my blood pressure has likely increased [18:40:28] Is wikipedia slow for anyone else ? [18:40:32] Reedy: on Meta; I was editing a page with {{#tag:timeline}} in it [18:40:49] When I've got 2 free hands again, I'll dig it up [18:42:55] Reedy: it prevents me from saving the page, so I guess I'll just wait :-)) [18:43:43] (I now see it doesn't work on page previews, either.) [18:43:59] j^: mdale: could you take a look at https://en.wikipedia.org/wiki/Tommy_(film)?debug=true [18:44:02] ...and the javascript console [18:44:22] this problem was buried in https://bugzilla.wikimedia.org/show_bug.cgi?id=41736#c3 [18:44:38] what is the issue? [18:45:30] Port error: Could not establish connection. Receiving end does not exist. miscellaneous_bindings:235chromeHidden.Port.dispatchOnDisconnectmiscellaneous_bindings:235 processEmbedPlayers:: playerSelector: video,audio,playlist load.php:11116 processEmbedPlayers:: Do: 1 players [18:45:43] jQuery.fn.embedPlayer :: video,audio,playlist load.php:11116//upload.wikimedia.org/wikipedia/commons/thumb/8/87/Gnome-mime-sound-openclipart.svg/50px-Gnome-mime-sound-openclipart.svg.png //upload.wikimedia.org/wikipedia/commons/8/87/Gnome-mime-sound-openclipart.svg /w/index.php?title=User:Brion_VIBBER/hidpi.js&action=raw&ctype=text/javascript:6//upload.wikim [18:45:59] j^ watch seemed to work for me there. [18:46:06] Reedy: just for the record, I was editing the timeline at https://meta.wikimedia.org/wiki/Affiliations_Committee [18:46:50] j^ what browser? [18:47:35] .names [18:48:45] * jeremyb hands odder a / [18:49:03] mdale: in Chrome, watchlist works for me, but still getting a lot of JS console spam [18:49:17] probably indicative of something breaking [18:49:31] console spam .. as in debug messages from TMH ? [18:49:32] or actual errors? [18:49:40] in debug mode or production mode? [18:50:07] thanks jeremyb :-) [18:50:51] mdale: "Port error: Could not establish connection. Receiving end does not exist." [18:50:58] both debug and release modes [18:52:13] in chrome?... I am not able to see that.. will try and restart chrome .. [18:53:50] hmm still not able to recreate. [18:55:37] mdale: ah, I was misreading the output. looks like it's just debugging stuff surrounding an unrelated error [18:55:48] ok... [19:00:43] odder: i'm able to edit the timeline [19:04:19] aude: still doesn't work for me from under Chrome, I'll try a different browser then [19:05:38] j^: mdale: 2 PHP Warning: Invalid argument supplied for foreach() in /usr/local/apache/common-local/php-1.21wmf3/extensions/TimedMediaHandler/handlers/OggHandler/OggHandler.php on line 250 [19:05:59] i'm using chrome [19:06:08] j^ was that not fixed? [19:06:13] i only changed the size of the timeline [19:06:32] I created it in the first place, without problems :-)) [19:06:42] now I'm getting "[76704baf] 2012-11-05 19:05:56: Fatal exception of type MWException" [19:07:35] Reedy, mdale dont think that was fixed, still dont know what page causes it [19:07:35] hmm [19:07:47] i'd love to see a stack trace [19:08:09] j^ its not an issue of ogg files with empty track list ? [19:08:35] Reedy: if we could get the page where that issue is showing up? [19:09:40] mdale: possible, or missing metadata [19:09:56] I really wish my IRC client actually would tell me when I've disconnected from the server instead of silently failing [19:11:17] mdale: we can hide the error by checking if tracks is defined but i would want to know in what situation this happens [19:11:22] Its not logged... [19:11:53] Reedy: does that not make the log a wee bit less useful? [19:12:10] We have the information for fatals and other exceptions [19:12:14] that's just a warning [19:12:44] robla: fyi, 05 19:06:06 -!- robla [~robla@wikimedia/robla] has quit [Ping timeout: 240 seconds] [19:12:47] ;-) [19:12:54] odder: 2012-11-05 19:05:56 srv265 metawiki: [76704baf] /w/index.php?title=Affiliations_Committee&action=submit Exception from line 77 of /usr/local/apache/common-local/php-1.21wmf3/includes/parser/StripState.php: Invalid marker: UNIQ6ff7537b259682ea-h-0--QINU [19:13:27] jeremyb: yeah, even the server notices faster [19:13:35] hah [19:13:42] huh [19:14:15] thanks Reedy [19:16:03] mdale, Reedy: we could deploy something like https://gerrit.wikimedia.org/r/#/c/31874/ to get rid of the warning [19:16:47] j^: Which warning are we talking about? [19:17:16] Nathan2055: PHP Warning: Invalid argument supplied for foreach() in /usr/local/apache/common-local/php-1.21wmf3/extensions/TimedMediaHandler/handlers/OggHandler/OggHandler.php on line 250 [19:17:32] problem is we dont know what file causes it [19:17:48] Meh, not the one I was thinking of. [19:18:38] * Nathan2055 is annoyed at the "Fatal exception of type MWException" warnings [19:18:42] j^ - tmh* have 12-cores and 16gb ram each [19:19:35] Nathan2055: join the queue https://bugzilla.wikimedia.org/show_bug.cgi?id=38095 [19:20:21] woosters: 12 cores hm, guess i have to add a threads flag to ffmpeg2theora in that case [19:20:41] Great. At the moment it breaks the Teahouse script installer and compare pages when used on two JS files. [19:20:53] I'll notify the people involved. [19:21:25] is searchidx1001 still throwing key errors? [19:26:09] most emphatically yes [19:32:26] Reedy: mdale is there a reaon for timed media handler to be enabled everywhere? [19:32:40] except apparently commons, but commons has timed text namespace [19:32:55] aude: what do you mean? [19:33:28] i see it on wikipedia, on wikidata, etc. [19:33:44] Right .. once commons is using TMH ... all wikis that want to embed video should use TMH [19:33:49] * aude doesn't understand totally how it works but thought it was a commons thing [19:33:53] ah, okay [19:34:18] it's probably a rare use-case for wikidata but possible then [19:35:07] aude: yea.. I mean a more robust model would probably be just embedding iframes from commons and running a very very thin embed support on the other wikis [19:35:08] but that is not how shared repo stuff works [19:35:15] that's fine [19:35:24] just curious about the extra namespaces, etc. [20:08:32] Hmm what's wrong with interwiki links on wikitech? http://wikitech.wikimedia.org/view/Deployments [20:10:46] Known issue [20:10:53] Has no interwikis since upgrade [20:11:00] Being discussed in -operations [20:29:28] tewwy: https://bugzilla.wikimedia.org/show_bug.cgi?id=41786 [20:40:22] Nemo_bis: tnx [20:56:19] tewwy: the Deployment page looks good to me again, so mw: works, i am just wondering why we dont have wikt: and w: [20:56:41] background: uses interwiki.cdb now vs. mysql table [21:05:35] AaronSchulz: https://gerrit.wikimedia.org/r/#/c/31890/2 [21:45:18] question : My bot (pywikipediabot) run on Wikiversities and it tell me that a 710 ans a 711 namespace exist "timedtext" but it's only for wikimediacommons ? [21:45:24] -ans +and [21:48:30] dcrochet: is your code up to date? [21:48:30] yes [21:49:00] r10664 [21:49:00] ah looks like those namespaces were created on all wikis [21:49:05] Reedy: is this normal? [21:49:21] Possibly [21:49:29] doesn't look so [21:49:43] AaronSchulz created db tables on all wikis... [21:49:43] j^: mdale ^^ [21:50:12] yes for any wiki to have local uploads it will need that transcode table [21:50:34] They're asking about the namespaces [21:50:46] Yes ... it creates 710 and 711 for timed text [21:50:57] if you upload a local asset you can put timed text there [21:50:58] it's not in InitialiseSettings.php ? i don't see that ? [21:51:41] dcrochet: what is the question ? [21:52:00] mdale: was the namespace created also on wikis with local upload disabled? [21:52:10] good question [21:52:15] (in general, it doesn't make much sense to upload videos locally anyway) [21:52:17] the "creation" of these namespace are not visible in the initialisesetting.php ? [21:52:20] .. I think it probably was. [21:52:41] dcrochet: probably it's in commonsettings [21:52:49] mdale: why can't it be opt-in? [21:53:03] Nemo_bis: it should be I guess [21:53:28] mdale: ok, who should change it then? [21:53:51] in any case communities need to know what they can/have to do [21:53:56] (later) [21:54:20] ... hmm we could do a small commit that checks if uploads are enabled or not .. and if not .. don't define TimedText namespace ? [22:01:27] [[Tech]]; Jerome Charles Potts; /* Server response times */ new section; https://meta.wikimedia.org/w/index.php?diff=4448833&oldid=4219532&rcid=3666653 [22:04:51] [[Tech]]; Reedy; /* Server response times */ reply; https://meta.wikimedia.org/w/index.php?diff=4448857&oldid=4448833&rcid=3666656 [22:15:01] * hashar awards Reedy the "quick tech support" badge :-) [22:15:15] haha [22:25:53] mdale: I think the easiest is disabling for everyone but commons and enable on request [22:26:12] (very few wikis upload videos locally anyway) [22:27:08] Nemo_bis: en uploads lots of fair use audio files ( for example ).. if fair use fairly rare? [22:27:33] mdale: yes, very rare outside en.wiki [22:27:39] for audios and videos [22:28:02] actually I don't even know if policies currently allow audio or videos in fair use on other wikis [22:28:22] ok... hmm... so we want a flag to disable video uploads.. do these other wikis allow local image uploads? [22:29:48] most wikis have local uploads enabled [22:30:18] and disabling upload (even just for some kinds of media) would require discussion [22:47:01] Nemo_bis, if it was never enabled, it could be argues that it's not really disabling... [22:49:20] Platonides: wasn't it enabled? [22:49:42] I'm not aware of per-extension file upload restrictions *confused* [23:02:56] ^demon: do you have a sec to look at https://gerrit.wikimedia.org/r/#/c/31605/? the only thing that changed since you last +1'd it is the addition of a change from "My Page" => "Page". [23:04:42] <^demon> Where does mypage show up? Is that the hover text? [23:08:20] ^demon: as far as i know it is nearly obsolete, being used only by the Nostalgia skin to point to the user's page [23:08:37] <^demon> lol, nostalgia. [23:08:46] <^demon> If we could merge my other patch, that wouldn't be a problem ;-) [23:08:52] presciently name [23:08:57] *named [23:09:30]