Fri, Jan 19
Fri, Jan 12
Tue, Jan 9
@jrbs ... just chasing this up
Mon, Jan 8
Running now ...
Dec 22 2017
Thanks @Tgr ... I think I can see how to implement it, might be back to you with questions
Dec 21 2017
Did investigation, created 2 more subtasks. Closing
As far as I can tell this bug has 2 separate parts, so I've created 2 separate sub-tickets
As this seems to be an issue with the backlink cache I'm removing the 'multimedia' tag
Dec 19 2017
Dec 18 2017
Dec 14 2017
Also ... did User:Magog_the_Ogre/PD_ineligible/2017_April_7-10 exist on enwiki once? Or has it always been a commons-only page?
Dec 13 2017
sometimes Wikimedia doesn't properly update pages to point to the new Commons URL
@santhosh in the code you've linked the ULS's $menu member is accessed from the definition of CompactInterlanguageList.prototype.createSelector. I added the proxy method because I wanted to avoid accessing that member from my UploadWizard code. I'm happy to access $menu directly instead if you and @Nikerabbit think it's ok to do so
Dec 12 2017
Ok it's not very urgent, so I've put in on the page for the week of Jan 8
Is that ok @jcrespo ? Is a one-liner still ok for a job that will probably take a week (or longer)?
Dec 11 2017
Ok. It won't take less than an hour though, it'll take days
Dec 6 2017
@jcrespo you mean just add a line like this? https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20171206T1600
Dec 5 2017
Resolving so, thanks @brion
Awesome, thanks v much @Dzahn
Dec 4 2017
Nov 30 2017
Nov 29 2017
Nov 28 2017
@matthiasmullie I seem to remember that the reason you wanted to fix this was it caused some kind of bug - it looked liked you'd be able to upload a file that has the same name as a file on a remote repo, but at the last minute you get blocked ... something like that anyway. I can't remember for sure, can you remind me so I can take a look at it?
@Gilles @fgiunchedi I think I've done all I can from a dev perspective on this now - someone on the ops side will have to run the refreshFileHeaders.php script on production with the --refreshContentType argument against the appropriate files. Is there something I need to do to make that happen?
oops didn't mean to close it until you replied ...
@Nikerabbit this ok for you now?
Nov 27 2017
Added a change to refreshFileHeaders.php into the patch so that it can be used to repair the Content-Type header in swift (by reconstructing it from img_major_mime and img_minor_mime in the database)
Nov 24 2017
Nov 22 2017
Just an example of this from earlier than Nov 1, see
Did some investigation on this, but didn't manage to reproduce it. Using @matmarex 's query above (on quarry) I found there are 17 examples of this since August 1 2017 on commons, out of 2.1M uploads logged
@My-wiki-photos ok - it's scheduled for deployment to test.wikipedia.org on Tuesday and then should be on commons the following Thursday. If you spot any problems with it let me know
Nov 21 2017
Should go live on production commons on Thursday Nov 30
@My-wiki-photos this is now fixed on beta see https://en.wikipedia.beta.wmflabs.org/wiki/Main_Page if you'd like to check it
Ok ... so I can see nothing there that suggests I should revert this. Passing it over for QA if that's ok with you @Bawolff
Nov 20 2017
The patch prevents new bad data being written, but I'm not sure how to go about fixing the existing bad data.
@aaron I tested post_as_copy = false on my local VM (updated it in /etc/swift/proxy-server.conf) and it works ok ... can't be 100% sure I'm doing it correctly though
Actually - I tried sending 'Content-Type:' and it results in swift not updating the content type (equivalent to not sending the header) but this behaviour isn't documented as far as I can see (https://developer.openstack.org/api-ref/object-store/index.html) so I guess it's best not to rely on it
@Tgr here's the script I used
Nov 16 2017
Is it possible to avoid libcurl adding that header automatically?
@jrbs there's a patch in for this but it looks to me like it's been fixed already, I can't reproduce the bug on production
There's some kind of issue with uploading files to testwiki with my account, but when I try and uploaded a file that already exists on commons get the warning on the first page of UploadWizard and can ignore it and proceed, which AFAICS means this ticket is resolved. Closing
Oops, closed the wrong ticket
Looks good to me, closing
@matthiasmullie looks good to me, closing
The docblock for Language::isValidBuiltInCode() says "Returns true if a language code is of a valid form for the purposes of internal customisation of MediaWiki", which suggests to me that it's not an appropriate test for a language code from a non-MW source.
Nov 15 2017
The problem was likely caused by the maintenance script refreshFileHeaders.php being run for T175689, which would have caused the stored Content-Type header in swift to be overwritten with 'application/x-www-form-urlencoded' for all refreshed files
Nov 7 2017
Oct 27 2017
Just make sure that Mediawiki generates only lowercase lang parameters consistently if that's what's desirable and that's enough, imho
Oct 26 2017
The langtags "zh-Hans", "zh-hans", and "ZH-HANS" comply with BCP-47, are unambiguous, and are identical under BCP-47. They must be treated the same.
Oct 25 2017
you're on some mission to preserve the case of the SVG langtags.