User Details
- User Since
- Nov 25 2014, 1:50 PM (501 w, 6 d)
- Availability
- Available
- LDAP User
- Jarry1250
- MediaWiki User
- Jarry1250 [ Global Accounts ]
Mar 26 2023
toolforge-jobs run lister --command /data/project/jarry-common/public_html/scripts/lister.php --image php7.4 --mem 500Mi --schedule "3,18,33,48 * * * *"
toolforge-jobs run announcements --command /data/project/jarry-common/public_html/scripts/announcements.php --image php7.4 --mem 500Mi --schedule "17 5 * * *"
toolforge-jobs run blocks --command /data/project/jarry-common/public_html/scripts/wmukblocks.php --image php7.4 --mem 500Mi --schedule "13 * * * *"
toolforge-jobs run clear-permatemp --command /data/project/svgcheck/public_html/clearPermatemp.php --image php7.4 --schedule "27 3 * * *"
Mar 19 2023
Thanks for the reminder. I've removed jsub references from my crontab and instead run the following:
Thanks for the reminder. I've removed jsub references from my crontab and instead run the following:
Jan 6 2023
Feb 5 2021
Okay, sorry, just looked at this again. When i tried to log in with LDAP, it prompted me to link it instead (email address already in use). I just did that, and it all seems to be working now. So happy to mark this as resolved.
Mar 30 2019
Thanks for the report. Fixed in 387abd89. Let me know if it recurs. Best, Jarry1250
Mar 29 2019
Thanks for reporting.
Hi all. Sorry to be a pain but -- while I am very grateful to have 2.40.16 on Kubernetes, for which many thanks -- it would be much more helpful to have 2.40.18 installed as that is the version that is running in production. See also T218828 (which relates I think to CVE-2017-11464 which was fixed in 2.40.18). Alternatively, if I would be better off asking for 2.40.18 to be backported to Stretch, let me know. Best, Jarry1250 (volunteer)
Mar 17 2019
Any better now?
Dec 19 2018
OAuthHandler (edited from an original by Anomie IIRC) is at : https://github.com/Jarry1250/labs-jarry-common/blob/master/libs/OAuthHandler.php
This script is at: https://github.com/Jarry1250/labs-svgtranslate/blob/master/svgtranslate.php
Thanks for reminding me about this. I've updated a related bug which already refers to this (now sadly longstanding) bug.
Nope, no luck. I moved the script onto a new consumer with https:// but doesn't seem to have helped.
Aug 19 2018
Hello. As noted above I am the current (non-)maintainer on SVGTranslate and was the main contributor to TranslateSVG.
Hmm, it might be that the redirect url is HTTP but the consumer is HTTPS. I'll try fixing that and see what happens.
Yes, as you say it's the rsvg-* that are of interest to me. This is what I do (very happily) not on k8s (with both paths sanitised, naturally):
Jan 2 2018
Fair enough. I don't really want to change the default after all this time, but I'm happy to add a checkbox: c58cc27e.
Thanks for reporting. ".JPG" files added in d64fd7c5. In your example, you'll need to blacklist e.g. File:Penion_cuvieranus_cuvieranus.JPG as a result (although that file may need to be moved!).
Thanks for reporting -- fixed in 27d5d7d7 and deployed.
Oct 7 2017
Thanks for reporting. Belatedly added in https://github.com/Jarry1250/labs-svgcheck/commit/9d19193f .
I've belatedly expanded the list of accepted mime-types in https://github.com/Jarry1250/labs-svgcheck/commit/729c5f69
Thanks for reporting! I've restarted the webservice, which seems to have fixed the issue. Not sure why it failed though. Probably a freak occurrence given I hadn't touched the underlying script in years.
Aug 5 2017
Fixed in 12ea82d6
By the way I still can't log in with LDAP...
Jun 11 2017
Excessive warnings fixed in https://github.com/Jarry1250/labs-svgtranslate/commit/f4c75bc43d71dbaaf316e1596292ad97b651052d
Jan 15 2017
Apologies, I work fulltime during the week so I'm not always around to respond to Phab comments. I can take a look now though.
Jan 8 2017
Thanks. Could you give an example of a file you've tried to translate, and the translations you've used? That way I can test safe in the knowledge I won't create any unnecessary uploads.
Dec 23 2016
Okay, the tool now seems to work for me following https://github.com/MW-Peachy/Peachy/pull/113 . Let me know if not though.
Thanks for looking into this. The http(s) issue should be fixed in https://github.com/Jarry1250/labs-svgtranslate/commit/5f56f1bc442e0591e9373641784ee68a05047152 . 'Cannot send session cookie - headers already sent' errors are the natural consequence of other error output nixing the proper flow controls. I'll look into the other bugs now.
Dec 21 2016
HTML of error message in case helpful:
<div class="oo-ui-window-frame" style="transition: all 0.25s ease 0s; width: 300px; height: 106px;"><div tabindex="0"></div><div class="oo-ui-window-content oo-ui-dialog-content oo-ui-messageDialog-content oo-ui-window-content-setup oo-ui-window-content-ready" tabindex="0"><div class="oo-ui-window-head"></div><div class="oo-ui-window-body" style="bottom: 44px;"><div class="oo-ui-messageDialog-container oo-ui-layout oo-ui-panelLayout oo-ui-panelLayout-scrollable oo-ui-panelLayout-expanded" style=""><div class="oo-ui-messageDialog-text oo-ui-layout oo-ui-panelLayout oo-ui-panelLayout-padded"><span id="oojsui-1" class="oo-ui-widget oo-ui-widget-enabled oo-ui-labelElement-label oo-ui-labelWidget oo-ui-messageDialog-title" aria-disabled="false"></span><span class="oo-ui-messageDialog-message oo-ui-widget oo-ui-widget-enabled oo-ui-labelElement-label oo-ui-labelWidget oo-ui-labelElement oo-ui-messageDialog-message-verbose" aria-disabled="false">"http"</span></div></div></div><div class="oo-ui-window-foot"><div class="oo-ui-messageDialog-actions oo-ui-messageDialog-actions-horizontal"><div class="oo-ui-widget oo-ui-widget-enabled oo-ui-buttonElement oo-ui-buttonElement-frameless oo-ui-labelElement oo-ui-flaggedElement-safe oo-ui-buttonWidget oo-ui-actionWidget" aria-disabled="false"><a class="oo-ui-buttonElement-button" role="button" tabindex="0" aria-disabled="false" rel="nofollow"><span class="oo-ui-iconElement-icon"></span><span class="oo-ui-labelElement-label">Cancel</span><span class="oo-ui-indicatorElement-indicator"></span></a></div><div class="oo-ui-widget oo-ui-widget-enabled oo-ui-buttonElement oo-ui-buttonElement-frameless oo-ui-labelElement oo-ui-flaggedElement-primary oo-ui-buttonWidget oo-ui-actionWidget" aria-disabled="false"><a class="oo-ui-buttonElement-button" role="button" tabindex="0" aria-disabled="false" rel="nofollow"><span class="oo-ui-iconElement-icon"></span><span class="oo-ui-labelElement-label">OK</span><span class="oo-ui-indicatorElement-indicator"></span></a></div></div></div></div><div tabindex="0"></div></div>
Dec 20 2016
Nov 25 2016
Nov 16 2016
Jun 25 2016
Okay, hopefully LivingBot is fixed now... let's see.
jarry1250
Hi. I'm really surprised that my bot (LivingBot) is still failing this. Is there any way to get more diagnostic info?
Oct 3 2015
Agreed. We'd also have to think about what the "expected behaviour" would be: at the moment I can fix the language of just the SVG, without fiddling around with anything else. I suspect that continuing something akin to that would be desirable.
Still reproducible by me. Can someone check if there's something weird about the way my LDAP account is(n't) set up?
Aug 20 2015
Aug 11 2015
Krinkle: is the plan to use testing to make sure this definitely is a perf benefit?
Aug 5 2015
It would be useful to test their performance programmatically over a larger sample (say, 1000 random PNGs and 1000 random JPGs), I think. In particular, I'd worry - for example - that GM is better for large PNGs but *worse* for smaller PNGs. I think for Wikimedia wikis we'd also be interested in RAM usage, wouldn't we?
Aug 2 2015
Aug 1 2015
Jun 29 2015
May 29 2015
I think the traditional answer to this question is that disk space is cheap, and the one off bandwidth cost is not vast -- but perhaps you disagree.
May 26 2015
Mar 30 2015
@Aklapper Could you add a new project, Tool-Labs-tools-svgtranslate ? I think you need special perms to do that, and apparently I can't add this to a project until it exists :/
This is about http://tools.wmflabs.org/svgtranslate/ .
Mar 23 2015
Hmm? This is just from the regular login page accessible from the top right of https://phabricator.wikimedia.org/ . So https.
FWIW I can still reproduce this (just did):