[01:42:45] hi again [01:44:02] still don't have a fix for SVGs being displayed as just a black shadow [01:46:43] I would suggest using rsvg instead of image magick [01:46:54] * bawolff has to go, and can't help you with that [01:47:02] rip [01:47:40] i /am/ using rsvg [02:06:56] anyone have any bright ideas [03:12:52] okay i finally got progress on my svg issue, i have all of the svgs displaying but they are all in black and white [03:20:13] hecc: You're rasterizing SVGs to PNGs? [03:20:48] It's mostly about intercepting the rsvg command and then diagnosing what's going wrong with it, probably. [03:21:17] Could be missing packages/libraries, could be missing command-line arguments, could be path or permissions issues, could be lots of things. [03:21:51] yes i guess, been messing with imagemagick and rsvg and mediaviewer is still broken but i get a black image of the svg [03:22:27] tripled checked packages and libraries, i think it is a path or permissions thing because i have like 4 places where imagemagick is apparently [03:23:03] I'm not sure why you're using both rsvg and ImageMagick. [03:23:12] I thought they were mutually exclusive for SVG rasterization. [03:23:20] But maybe I'm misremembering. [03:23:59] If you can get the commands and reproduce on the command-line yourself, that'll likely be helpful. [03:24:13] /usr/bin/rsvg whatever [03:24:19] Or whatever path it's actually calling. [03:29:12] out of curiousity how many of the svg config lines do i need to use in localsettings [03:30:01] Which svg config lines do you have? [03:30:21] if the image is black and white...thats odd [03:30:49] no sort of permission error would get rid of the colours. Maybe try a different test image [03:32:21] https://i.imgur.com/witlAM2.png [03:32:27] this is the third test image [03:34:00] So the imagemagickconvert command config wont be used for svgs in that setup [03:34:24] just for other formats (png, jpg etc) [03:35:09] that would explain a bit [03:35:28] I cant remember how wgUseImageResize works, but im pretty sure that that doesnt affect svg rendering [03:35:59] that's fine, i copypasta'd that from some site saying that would fix it [03:36:55] so how do i change that config to work [03:38:05] So im not sure the precise problem you are having [03:38:36] i mean i know your getting b&w images, but i have no idea why that would happen [03:39:12] https://www.mediawiki.org/wiki/Manual:%24wgSVGConverters is the setting that controls exactly what command mediawiki uses for svgs [03:39:54] So since wgSVGConverter is set to rsvg [03:40:54] I would check what happens in the commandline if you type [03:41:23] rsvg-convert -w 600 -h 600 -o out.png inputfile.svg [03:41:45] and see if it succesfully creates out.png [03:42:41] Additionally, if you enable mediawiki debug logging, it will show you precisely the command being executed [03:42:45] !debug [03:42:46] For information on debugging (including viewing errors), see https://mediawiki.org/wiki/Manual:How_to_debug . A list of related configuration variables is at https://mediawiki.org/wiki/Manual:Configuration_settings#Debug.2Flogging Also see https://mediawiki.org/wiki/Manual:Errors_and_symptoms [03:46:32] ran it, nothing happened [03:53:20] god i hate mediawiki sometimes [03:53:23] no offenese [03:59:42] This isn't really MediaWiki. [03:59:50] MediaWiki just shells out to a command-line tool for this, AFAIK. [04:01:15] is there any more information i can provide that might narrow down the problem [12:16:23] Hello. I have an odd problem: MW 1.31, php 7.2.7, Elasticsearch 5.6.10. My test instance used to show a "sister projects" sidebar in search results; after upgrading MW (and extensions) and PHP that no longer appears. Multiple browsers, multiple OSes, multiple skins, so I'm pretty sure it's backend-ish. Does anyone have any thoughts on this? [12:19:01] jss: sister project search is quite complex to setup, could you paste somewhere you existing config? [12:19:23] Yes, though it was working prior to the MW and PHP upgrade. Stand by... [12:19:43] sure but something certainly changed in the code and the config might need to be adjusted [12:22:01] http://www.clock.org/~jss/search.txt has the LocalSettings.php excerpt. [12:24:37] And now also the elasticsearch.yaml file (comments and newlines excised). [12:27:05] jss: if you set $wgCirrusSearchEnableCrossProjectSearch = true; does it enables the sidebar? [12:28:51] Aha; Yes, though the styling is different than it used to be (the project name is below the results, which are formatted a little less prettily but I can f*ck with the CSS later). [12:29:27] yes sister project completely changed [12:29:55] and we thought it was prettier ;) [12:29:59] Excellent. [12:31:18] Well, I'd like a little more space between the individual results in the sidebar, and I do like the shading and the favicon+project name being below not above. [12:31:53] But I are not a graphics designer or UI expert, so... . :) [12:32:00] Thanks for the fix! [12:32:20] jss: there are a bunch of new options for CrossProject search (number of results, ordering...), feel free to have look at docs/settings.php and search for "CrossProject" [12:32:25] jss: you're welcome [12:33:03] Will do! [12:58:52] Does anyone know how I can mass block spambots using a bot? The community of the site I'm running it on has approved the task. I need to be able to block using a pywikibot style list [14:56:57] Hello all! I was wondering if there were any known issues with upgrading from 1.30 to 1.31 that would result in the wiki suddenly getting much slower in every way [14:59:36] qchris ping [15:01:05] Ulfr: check your caching settings [15:01:24] make sure that whatever thing you have set up for your $wgMainCacheType is actually functional [15:02:28] if it's CACHE_MEMCACHED, ensure your memcached server is running, accessible, and configured correctly. If it's CACHE_ACCEL, ensure that the apcu extension is installed, enabled, and configured correctly in php.ini [15:03:12] if it's not one of those two things, then that's a cause of slowness right there [15:03:21] Almost positive I have caching set to disabled for reasons that escape me right now. Wasn't a problem on 1.30 though [16:46:54] Skizzerz: No joy. cache was set to CACHE_ANYTHING and is now set to CACHE_NONE and it's still slooooow [16:46:59] Any other ideas? [16:47:25] yes, no caching is slow [16:47:37] it should be either ACCEL or MEMCACHED, with one of those set up properly [16:50:57] Skizzerz: I understand I'm taking a performance hit with caching disabled, but there are reasons why it's not desirable and 1.30 ran just fine with existing settings. It only slowed down when I upgraded [16:53:18] What reasons? [16:54:12] sorry, i just loooked at backscroll, I see you are not sure [16:54:36] But CACHE_ANYTHING is usually a poor choice for wgMainCacheType, sometimes it can be just as slow as CACHE_NONE [16:54:48] In a nutshell? My boss got REALLY angry about some settings that I claimed had changed but still appeared broken and as such caching is forbidden. I didn't say it was a GOOD reason, just A reason [16:54:59] lol [16:55:28] Correct, I've got robust servers to compensate, but for some reason after the update to 1.31 my users are eyeballing torches and pitchforks over just how slow it is [16:56:30] MediaWiki is generally developed with the assumption that users have wgMainCacheType setup...so from a dev perspective its barely even considered a bug if performance flucuates in the no cache set up (Unless its extreme fluctuation) [16:56:39] Can't find anything worth getting excited over in the error logs or the debug logs, it's just really slow [16:56:53] But, if you want to track down further, you could try enabling profiling to see what is slowing things down [16:57:10] https://www.mediawiki.org/wiki/Manual:Profiling [16:57:13] I mean I understand that ultimately it's on me to fix this, I was just hoping it was something obvious, like resetting the flux capacitor or sommat [16:57:26] Or enabling caching :P [16:57:55] If we can narrow it down to what is causing the slowness (E.g. with profiling), its possible there is some sort of quick fix [16:58:06] But hard to say if the only symptom is "its slow" [16:58:49] Honest to god I understand completely what you're saying. When my users come to me and say the website is slow they get a fearsome glare [16:59:14] but it's everything that's slowed down. Searching, editting, reading [17:00:03] Its always possible it could be something like localizations are malfunctioning and being rebuilt on every request, or something like that [17:00:16] or some other bug like that [17:00:19] Ugh. That one is probably what caused my first ulcer [17:01:17] database servers kept going splat from being constantly redlined at all times day and night, fiddle with an unrelated issue to support some other language and voila, DB servers are content once more. [17:03:27] bawolff: If I run tideways while the servers are under load, will it tank performance even further? [17:05:20] I've never used it, but its meant as a performance monitoring tool, so they have probably been careful to ensure it doesn't cause too much load [17:06:34] hooboy [17:13:26] bawolff: At the risk of sounding stupid, where on https://www.mediawiki.org/wiki/Manual:Profiling does it tell me how to make sure it's running? I accessed the StartProfiler.php file and it caused no errors, but there's nothing being outputted on the page or in the html despite the output being set to Text [17:14:23] In theory it's supposed to be in an html comment [17:14:33] I haven't tried using it in years to be honest [17:15:23] * Ulfr facepalms [17:15:39] When I reset the webserver to enable the profiler extension for PHP the LB switched me [17:18:49] oh yah it works juuust fine. I can see why you'd need a GUI to actually understand the output tho [17:19:16] Time to start digging. Tyvm for the help [17:21:17] ... did Reedy set something up specifically to mess with me? 80% of the load time for a page seems to be bloody sleeping! https://pastebin.com/5avpsR2z [17:23:07] That's interesting [17:23:26] So probably has to do with how mediawiki ensures slave replicas are up to date [17:24:00] you're using a master/slave db setup I assume [17:24:16] Correct. Database servers are beefier than the webservers [17:24:50] That reminds me kind of of 52af356cad3799 [17:25:56] https://phabricator.wikimedia.org/T190082 [17:25:58] Bless you. Do you need a tissue? [17:25:59] oh [17:27:34] I'm not sure if its really the same issue, just sounds kind of similar [17:27:42] Yeah, just about. [17:27:55] is there a $wgQuitNapping variable I can set? [17:31:25] There's probably something in LoadBalancer that will disable chronology protector, but then users may see out of date info [17:35:46] Uh, any recommendations on how I go about doing that? because I'm willing to have a little bit of timeline discrepancy if it means I'm not burning 4 seconds every time I try and load a page [17:36:45] MediaWikiServices::getInstance()->getDBLoadBalancerFactory()->disableChronologyProtection(); will maybe do it (I'm not sure exactly what the consequences are) [17:37:32] ...Is there a blue telephone box near by I can consult with? [17:44:06] Yeah I'm going to leave that setting enabled and see if there's anything in the slave's logs that might be holding stuff u [17:44:07] up [17:45:03] You could also try blindly backporting patches mentioning ChronologyProtector or cpPos and see if one of those fixes it [17:46:44] First we're tinkering with time protection, now I'm blindly teleporting? I might just take it back down to 1.30 until 1.31.1 comes out [17:48:18] Although that's assuming I can safely downgrade. I should be OK if I just switch back the configs, right? [17:48:24] [17:44] jynus> if those are miliseconds [17:44] jynus > that is 5 secnods stuck waiting [17:44] jynus >the op's solution would be to reduce the timeout to 0 [17:48:40] You can usually safely downgrade between versions [17:48:52] Someone get that man a sherlock holmes hat, he's clearly got a future as a detective [17:49:28] It does look like its waiting 5 seconds for the slave to catch up (Which happens to be POS_STORE_WAIT_TIMEOUT), so probably ChronologyProtector is getting stuck, hitting the timeout and then doing nothing [17:50:03] But the slave isn't behind? I've been checking it and it's always set to 0 seconds behind master [17:51:08] oh... [17:51:11] I was reading the code [17:51:25] I'm thinking that maybe this code relies on caching actually working [17:53:01] Uh, it was just as slow with CACHE_ANYTHING set instead of CACHE_NOTHING [17:53:21] if you don't have caching set up, CACHE_ANYTHING will not do anything [17:53:34] (it'll write the cache to the db, which doesn't work well when it's the db that's acting up) [17:53:35] Hmm, and there's code to disable chronology protector if you have no cache setup [17:53:57] (line 521 of LBFactory.php) [17:54:58] so effectively I have to start running some sort of cache or it's going to remain hideously slow? [17:55:01] So in theory, if you have no cache, you should get a log message of "Cannot use ChronologyProtector with Empty BagOStuff.", and it should disable chron protector [17:55:14] I guess that's not working [17:58:30] So by default it uses $wgMainStash I think [17:59:10] which by default is "db-replicated" [17:59:28] which is the database [17:59:46] meh, so I guess that should work fine in the no stash case [18:00:18] meh, I have to go to a meeting, but I'll file a bug about this. Maybe Aaron will see, he's the most familar with that area of code [18:00:28] Thank you! [18:39:19] Hello and BIG THANK YOU THANK YOU for the most awesome wiki engine in the known universe [18:42:20] Got a question about the "email options" in Special:Preferences .. I have ticked the checkbox "Email me when a page or a file on my watchlist is changed" but not "Email me also for minor edits of pages and files". Is this use of word "minor" refering to the editor ticking the "this is a minor edit" checkbox or is it determined by the number of bytes changed or something like that. I'm wondering because someone edited an article and I didn't receive [18:42:22] email of it (even though I usually get email when an anonymous user edits a page). Could be that the emailing has broken somehow. [18:43:06] Did you recieve e-mails before? [18:43:12] Ulfr: Yes. [18:44:39] jubo2: Try and trigger it yourself, make an anonymous edit and see if you get an e-mail [18:44:54] Let me try editing a page while being logged out (on another browser) [18:45:35] just make sure you're still set to watch the page. (Sort of obvious I know but it's best to cover all the bases :D) [18:48:16] I'm using a lifetime email forwarding service .. that can sometimes be a little clogged so maybe the notification emails will show up [18:50:12] Now I edited the Sandbox as an IP-address (and checked I am watching the Sanbox page). No email in my inbox [18:51:07] Let me check how the mail is transported (just to be sure). I think I set it up to use my registrar's SMTP server with credentials [18:51:48] Hold on.. I ssh in [18:56:20] Oh yeah.. Now I get what's wrong.. Ended up in a mess when I put founding date of Consumerium.org into twitter's "birthday" field and the child-locking got activated. Twitter required I answer from a certain email address (which was a forward) so I deleted one mailbox to make quota to temporarily make that email box exist. Turns out I deleted the one that the Mediawiki is using to shoot out it's mails [18:57:08] Looks like I gonna need to pay the registrar some more money to get the premium email package.. the domain registrations include only 2 mailboxen [18:59:09] bawolff Skizzerz Turning on caching fixed it. Sorta awkward because it really needed fixed by my boss really hates caching :( [18:59:33] well... all I can say is that your boss is wrong [19:00:28] The man makes my salary in the time it takes him to take a dump. I'm not saying you're wrong, I'm just saying there are certain battles best left unfought. Hopefully he doesn't notice [19:08:51] Thanks again for the help all! (I'd really like that bug to get fixed so I can stop sneaking superior technology, I'm rather fond of being employed) [19:13:20] The Mediawiki always notices when the LocalSettings.php is modified, right? No need to force-reload the Apache ? [19:16:05] Correct. [19:16:14] Only time you need to restart apache is if there's new php modules or whatever [19:17:15] I wouldn't say always, but it usually does [19:17:40] if you have PHP opcode caching enabled and disable file modification checks in the settings for the opcode cache, it won't know that you've changed it until you clear that cache [19:18:15] you'd be able to determine whether or not that applies to you by looking at your php.ini [19:19:48] Hmmm... no email coming from the anon edit. I do have the right password in the LocalSettings.php .. I wonder what am I missing here [19:20:52] could be any number of things [19:21:03] do emails come through for other edits? [19:21:14] did you check your spam/junk folder? [19:21:28] is the server getting a bounce message for that email? [19:21:46] do emails come through for other features, such as password reset? [19:21:51] not in junk folder [19:21:55] (if the last one is "no" then your email settings in mediawiki are probably wrong) [19:22:07] or the server is rejecting all of your emails [19:22:19] unfortunately diagnosing email errors is a bit tedious [19:22:37] especially if you don't have insight into the email servers themselves to check their logs to see if anything was actually sent or received [19:22:44] Skizzerz: Can I safely request password reset? (without needing to actually change the password) [19:22:57] yep [19:23:08] Okays. I try that then.. [19:23:24] just don't click the link in the email [19:24:11] I requested a new password .. and I just now see it in my inbox [19:24:22] ok [19:24:30] so your email settings are correct [19:24:44] Hmm, ulfr left. I discovered he has https://phabricator.wikimedia.org/T197206 [19:25:50] jubo2: did you get an email for someone *else* editing that page shortly before the anonymous user edited it? [19:26:10] Skizzerz: nope [19:26:20] hmm [19:27:02] When I look at the recent changes in my watchlist I can see the edits that should have triggered the "Anonymous user edited article Blaah" [19:27:13] and they're not marked as minor? [19:27:16] or bot? [19:27:26] (anons shouldn't be able to do either, but just to be safe) [19:27:31] No, they are not [19:27:39] k [19:28:04] give me a few mins [19:28:45] Sure. [19:32:27] what sort of edit did the anonymous user make? [19:33:09] 2 x http -> https (1 byte changed) and another one was to add some text to the end of a pre-existing URL [19:37:34] I verified that the minor edits email notification does indeed only care whether or not the minor edit checkbox was checked -- amount changed doesn't matter [19:37:47] so, I'm not entirely sure what's going on :( [19:58:31] Ok thanks for your help and the information that "minor" means the checkbox was ticked. I don't know why the notifications about anon-edits are not being sent. Actually the "Email me when a page or a file on my watchlist is changed"-checkbox would imply that email is sent _every time_ even a logged-in user edits a page in my watchlist. Then again no-one logged-in besides me ever edits develop.consumerium.org so how would I know.. :( :( [19:58:37] Skizzerz: Thanks [22:10:42] davidwbarratt: pong. Heya. What's up? [22:12:03] qchris hey! I was just looking for someone to create a repo and everyone said you were the one to fullfill the request, but lego was able to make the gerrit repo, but it doesn't look lik eit's on phabricator and github https://www.mediawiki.org/wiki/Gerrit/New_repositories/Requests [22:12:14] *like it's on [22:12:45] That's something I should be able to help with. [22:17:12] oops [22:17:53] legoktm haha, no worries, I just noticed it, not a big deal for what I was doing, I still got it onto npm thanks to James F. :) [22:18:18] qchris thanks! probably should have more people that know what to do (read: not me). :) [22:18:57] https://phabricator.wikimedia.org/diffusion/RITN/ is alive and kicking. https://github.com/wikimedia/react.i18n exists now and should get the code after your next push to gerrit. [22:19:14] davidwbarratt: ^ [22:19:34] qchris nice! thanks! [22:19:40] yw