[00:57:22] If anyone has any idea how to fix this problem, let me know. I have short urls working, but one of the problems is that I cannot get non-www links to redirect to www [00:57:55] for example http://domain.com/wiki/Article, wont redirect to http://www.domain.com/wiki/Article [02:40:05] Are there any restrictions on what characters can appear in an interwiki or namespace prefix? [02:58:45] GPHemsley: yes [03:09:46] has anyone been able redirect all non-www links to www with mediawiki? [03:09:54] I am tearing my hair out about this [04:04:57] such redirects would be done using your httpd configuration ;-) [07:23:58] Sob. http://p.defau.lt/?xNhS4GHivOAjCuVGKtjAWg [07:27:54] in Manual:Developing_extensions it says to disable caching by setting $wgMainCacheType = CACHE_NONE and $wgCacheDirectory = false [07:28:06] can someone tell where these variables are located [07:28:07] > [07:28:11] ? [07:29:25] bendev711: in your LocalSettings.php file [07:31:06] legoktm thanks :) [07:31:23] feel free to add a link from the manual :) [07:31:46] Argh, those 8160 lines were not enough, more fatals still [07:32:47] ok [13:08:28] hi all, what would be the easiest way to put a box around some text. I would like to put "exercises" in boxes, underneath some text. If possible I would like some image on the left (f.e. a warning sign) for the students to understand this is a box they have to pay attention to. [13:13:16] sqarzz: do

...your text here...

[13:14:11] Oh, I didn't notice the warning sign thing. Well, it's just more HTML/CSS. [13:14:46] You could do

...your text here...

- but that's probably not a good idea unless it's an actual warning. [13:29:22] sqarzz: Well, if you put warning signs aside every exercise, they'll get accustomed to it :) [13:29:53] Maybe you could stick a red border around unfinished exercises, and green around finished ones. [13:30:06] Hi, I've got a problem with a page's Translation, one part stays in the original language while it is translated http://wiki.ribesg.fr/NPlugins/Player/NCuboid/fr (See question box at the bottom) [13:30:45] I've got this small icon in the translation thing http://img.ctrlv.in/img/14/07/28/53d650782726e.jpg [13:30:59] I have no idea what it means, just that it refuses to show it it seems [13:32:54] Ribesg: Is there a tooltip when you hover over it? [13:33:54] Nevermind it's fixed [13:34:01] marktraceur, no there was no tooltip [13:34:18] There was a
in the original text, it was
in the translated text [13:34:21] It somehow refused it [13:34:34] I removed it in the original text and translated it again, now it works [13:34:36] Weird. [13:35:40] Ah. [13:48:10] Ribesg: hello, it would probably be useful if you filed a request for a tooltip [13:48:41] that icon means the translation has to be updated; recent versions of Translate remove the translation entirely if it's outdates (unless the translation administrator tells it not to) [13:49:09] ._. [13:49:19] It doesn't miss a tooltip, this icon is a bug [13:49:35] Something broke somewhere because of a
[13:53:11] Ribesg: the icon itself is not a bug, it's a part of the interface [13:53:14] Thx for the suggestion marktraceur [13:53:38] Nemo_bis, but there was no reason for it to be there [13:53:57] anyone an idea how i could make a table row have the full width of the page, independent of the inputted text [13:54:24] {|class="wikitable" style="width:100px;" align="right [13:54:28] Ribesg: yes there was: the source text was changed http://wiki.ribesg.fr/index.php?title=NPlugins/Player/NCuboid/fr&diff=422&oldid=419 and the translation admin marked the new version for translation, invalidating translations [13:54:35] this was what i tried [13:55:13] 100% [13:55:27] Nemo_bis, this was done AFTER the screenshot [13:56:11] Nemo_bis, both original & translated pages modification was done after the screenshot. The page was freshly entirely translated just before the screenshot. [13:56:28] what screenshot? [13:56:42] I've got this small icon in the translation thing http://img.ctrlv.in/img/14/07/28/53d650782726e.jpg [13:57:12] I don't see how that disproves what I said [13:58:53] - I marked the source page for translation [13:59:00] - I translated everything [13:59:18] - This icon stayed there and this part wasn't translated on the translated page [13:59:31] Where is the reason for this icon to pop up [14:00:14] I'm sorry but the wiki tells a different story: http://wiki.ribesg.fr/Special:Contributions/Ribesg http://wiki.ribesg.fr/Special:Log/Ribesg [14:00:53] Which, SURPRISE SURPRISE, is what I said [14:01:02] Where [14:01:29] After translating, you did http://wiki.ribesg.fr/index.php?title=NPlugins/Player/NCuboid&diff=prev&oldid=420 then you marked for translation [14:01:34] the bot removed the outdated translation [14:01:54] Nemo_bis, Again, this action was made AFTER that screenshot [14:01:55] you translated again http://wiki.ribesg.fr/index.php?title=Translations:NPlugins/Player/NCuboid/46/fr&diff=prev&oldid=423 and the up to date translation was reapplied http://wiki.ribesg.fr/index.php?title=NPlugins/Player/NCuboid/fr&diff=prev&oldid=424 [14:02:14] The screenshot is irrelevant, these are the facts logged [14:02:40] ._. [14:07:21] - I modified the source page, removing all the translation tags [14:07:21] - I marked the source page for translation [14:07:21] - I translated everything [14:07:21] - I looked at the translated page, the box at the end wasn't translated [14:07:22] - This icon stayed there and this part wasn't translated on the translated page [14:07:23] - I modifier the source page, removing the
[14:07:24] - I translated this part again, just removing the
, too [14:07:26] - The icon disappeared and the part is now translated [14:07:57] Now if you refuse to trust me because of logs not logging every single movement of my mouse, that's your problem, I don't care [14:08:51] This is already more understandable :) [14:09:08] Almost ready as bug report, only missing links to diffs and logs [14:27:47] Does anyone know how to redirect all non-www mediawiki links to www? I tried everything and I couldn't get it working [14:35:45] Castile: Hi, you mean that your wiki is on www.example.org but mediawiki links to example.org? [14:36:01] * marktraceur subtly places http://no-www.org on the table [14:37:34] marktraceur: basically, but other way around [14:37:41] I prefer the www vs the non-www [14:37:58] I just dont want any links for non-www to work, I want them to redirect to www. [14:38:18] Castile: Well, that sounds like a web server config thing - what web server do you use? [14:38:51] Just the standard, Apache, MySQL, PHP [14:39:12] All the links work, but I just can't force one over the other [14:40:05] Castile: OK. You probably have a virtual host for WWW, right? [14:40:23] I am 99% sure, but yes [14:40:54] Castile: https://httpd.apache.org/docs/2.4/rewrite/remapping.html#canonicalurl will probably help :) [14:40:57] I remember seeing it in there [14:41:18] Er, no. [14:41:22] Castile: https://httpd.apache.org/docs/2.4/rewrite/remapping.html#canonicalhost is better. [15:25:29] What can this be? Notice: Undefined variable: wgResourceModules in /srv/vagrant/mediawiki/extensions/SkelJS/SkelJS.hooks.php on line 57 [15:27:04] No global statement, Nemo_bis? [15:27:12] Henk van Hal [15:27:13] Henk van Hal [15:27:13] Henk van Hal [15:27:13] Henk van Hal [15:27:13] Henk van Hal [15:27:18] !ops [15:27:32] Ta QueenOfFrance [15:28:10] marktraceur: heh, I feared something more evil and didn't check, let's see [15:37:16] Nemo_bis: Any luck? [15:44:04] yeah that's it [15:44:28] but there are several other extensions giving me this problem, I thought it was my config's fault ;) [15:46:04] Huh. [17:02:20] jsahleen: Hi and welcome! [17:32:48] Mithrandir: hiya [17:48:29] hi! I'm having some trouble with special characters which I don't see mentioned on the documentation. I have a list of definitions (using " ; ") but when I use a colon in the definition, it jumps to the text [17:49:18] I just created an example on the mediawiki sandbox https://www.mediawiki.org/wiki/Project:Sandbox [17:49:38] so, how can I escape ":" in definition lists? [17:49:58] carandraug: probably with : [17:50:28] you can escape most things with it [17:51:13] MatmaRex, ah! That makes sense. Yes, I remember now. Thank you [17:51:20] Hmm, there was a XiRoN in here earlier. [17:51:57] Mis-read that is Xirzon. :-) [17:58:48] hi, i am trying to commit a few changes for a bug using https but its showing me authentication error ( http://pastebin.com/51ERCrtj ), can anyine help? (also, i used both http password and my a/c pwd but no luck) [18:00:52] ds406: I don't think we ever push with https [18:00:59] ds406: Can you set up an SSH key and use that instead? [18:01:27] its not allowed on my network and tunneling doesnt solve it either [18:02:05] marktraceur: and https is said allowed here : https://www.mediawiki.org/wiki/Gerrit/Tutorial [18:02:40] You'll probably need to use the Gerrit Patch Uploader. [18:02:41] Hm. [18:02:42] Or equivalent. [18:02:45] marktraceur: i mean push using https is possible [18:02:45] !patchuploader [18:02:51] !patch [18:02:51] For information on using *.patch files, see . To contribute a patch to MediaWiki, see https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Submit_your_changes . [18:02:52] It's probably *possible* though. [18:03:46] Carmela: Do you mean uploading the patch at bug list description in bugzilla? [18:04:10] Carmela: oo sorry you said gerrit... [18:05:38] I mean https://tools.wmflabs.org/gerrit-patch-uploader/ [18:06:39] yeah i was going to confirm this one only, thanks i am looking into it right now.. [18:11:50] ds406: I would also strongly suggest not using whatever network you're on, or filing a bug with the admin of it :) [18:13:46] marktraceur: so, are you saying i should try and find some way to ssh my way to upload the patches only..? sorry i couldnt follow you there.. [18:14:49] You don't need to, but I feel it's preferable :) [18:16:37] marktraceur: ok, i will try to find some solution there, but my options are limited right now... [18:18:43] Have you generated/used the right http password? [18:18:44] https://gerrit.wikimedia.org/r/#/settings/http-password [18:19:07] Reedy: Yeah, I used that password... [18:19:23] after generating from the gerrit account [18:20:23] Rihgt [18:20:26] *Right [18:20:42] But per marktraceur I've no idea if anyone ever got it to work [18:21:13] oh fhocutt there seems to be 1 more note at the end of https://www.mediawiki.org/wiki/Talk:Evaluating_and_Improving_MediaWiki_web_API_client_libraries#WikiTeam_requirements for you to reply to [18:21:57] thanks sumanah [18:23:07] Reedy: Carmela suggested me patch uploader , so I think i can go with it now, I hope it works and does not mess up things for others... [18:23:23] It works pretty well [18:23:36] I have pasted the 'git diff' of the unstaged changes in the patch text area, will that be ok? [18:24:22] i did not use the upload thing there [18:25:44] I don't think git diff is sufficient [18:27:27] So, what else should i put in there..? it says git diff is one of the allowed patch format [18:27:37] Reedy: ^^ [18:27:45] so it does... [18:27:48] Try it, and see :) [18:27:57] At worst, someone can abandon the patchset [18:28:02] Or you can upload a new changeset [18:33:18] Reedy: You were right git diff aint enough... It didnt work, cant figure out why from the error log.. [18:33:27] sumanah: sup? [18:33:28] git diff should indeed be sufficient [18:33:33] :o [18:34:04] ds406: normally it should work with commit message + attached git diff [18:34:25] Hey Mithrandir - I wanted to run an idea past you re fhocutt's work and specifically re learning to diagnose Java bugs better [18:34:34] Vogone: I pasted the output from git diff [18:35:00] ds406: better do "git diff > somefile" and attach somefile [18:35:17] Mithrandir: basically I heard from Merlijn that it can be a bit frustrating with Java to understand what causes a bug, because there are so many layers you have to backtrace through [18:35:21] Vogone: ok i'll try doing that... [18:35:41] so the first thing I thought of, re: learning to do that better, was: take working code, introduce a bug, watch what breaks and look at the trace [18:36:09] Mithrandir: but if you have better ideas about how to learn to debug Java (which I assume fhocutt will need to do as she starts writing new code) I welcome your thoughts [18:36:58] ds406: and don't forget to select the right project, but I guess you've already done that in your previous attempt :) [18:37:24] Vogone: yeah, its right one. [18:54:25] ds406, Vogone: There's a command called git format-patch [18:54:38] Which lets you format commits in a diff-like format that can then be imported back into git [18:55:25] hmm [18:56:18] Vogone: It still giving me some different error ( ** Bad day for me, should have worked in a go **) heres the pastebin : http://pastebin.com/8A6YjbpS [18:58:17] ds406: Have you read the error? [18:58:37] It would seem the email you have on your mediawiki account isn't the same as the one on your gerrit account [18:58:59] Reedy: It is actually.. [18:59:16] ds406: what did you paste to the "Author" field in the patch uploader? [19:00:55] Vogone: my email address [19:01:06] ds406_: wrong format then [19:01:29] "user " [19:01:51] so an example would be: X-man [19:03:30] Thanks a bunch Vogone , it worked now (stupid mistake by me..) [19:03:39] :) [19:14:13] MatmaRex: I appreciate the email you just sent to wikitech-l [19:15:02] :) [19:19:29] MatmaRex: +1 [19:28:06] MatmaRex: +1 (although I didn't read yet) [19:30:07] https://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg77228.html (in case someone wants the link) [19:30:17] +1 btw :) [20:08:35] he folks. I can't seem to find how to substitute a template in VE. [20:10:02] MartijnH: Like {{#subst}} ? [20:10:10] Er, subst: [20:10:19] * marktraceur doubts that exists. [20:10:28] like {{subst:mycooltemplate|param1|param2}} [20:10:32] MartijnH: you can't without cheating [20:10:44] oh ok [20:10:50] adding a template named "subst:mycooltemplate" might work [20:11:16] do you know if there is a bug filed yet, or should I try to search and/or file? [20:11:18] (but the UI will be wonky) [20:11:19] That would be fantastic. [20:11:30] you're probably not supposed to do this "by design" [20:11:37] !bug :visualed subst [20:11:37] https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=%3avisualed+subst [20:11:56] there is a bug ^ :) https://bugzilla.wikimedia.org/show_bug.cgi?id=49904 [20:12:05] yup [20:12:17] thanks, I'll see if I have anything to add, or if that's complete as is [20:12:39] MartijnH: you can also insert raw wikitext, but this is very well-hidden, see https://bugzilla.wikimedia.org/show_bug.cgi?id=51899 [20:12:54] (and will also cause the UI to go all wonky) [20:13:27] I don't mind excercising the code a little :) [20:16:11] between that bug and 66281 it seems complete [21:04:42] fhocutt: https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2014-07-23/News_and_notes I think you might find the news item about the GLAM-Wiki toolset interesting [21:05:40] oh, interesting [21:05:58] code https://git.wikimedia.org/blob/mediawiki%2Fextensions%2FGWToolset/f8ee075f3e13b7e089ce4ece38b10506643b75d9/README [21:06:03] er, https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FGWToolset [21:06:17] ty! [21:06:22] more info: https://www.mediawiki.org/wiki/Extension:GWToolset [21:06:34] DanielK_WMDE_: hey, thanks for those wikitech-l emails [21:08:05] fhocutt: it doesn't just upload files using the general MediaWiki web API -- https://www.mediawiki.org/wiki/Extension:GWToolset/Technical_Design makes it look like it is doing something more integrated into MediaWiki - multichill would know more [21:08:24] anyway, thought you might want to see it [21:09:01] huh, interesting [21:09:04] ty! [21:09:11] sure! [21:09:20] fhocutt: how is the Javaning? [21:09:23] Javening? [21:09:26] Java'ing [21:09:33] Javening, I think [21:10:04] slow, not so much because of difficulty but because of focus [21:12:17] looking at pywikipedia-l right now [21:16:32] fhocutt: ok, so, I am about to write up the thing for Merlijn. I'm gonna try to do it in the next 5-10 min [21:16:34] will cc you [21:16:44] sounds good [21:16:48] fhocutt: if you want to make a bit of a game of it, you could also try to wrap up your thing by then, then move on [21:18:00] I will at least work on it solidly while you're writing up [21:18:05] :) [21:31:49] fhocutt / sumanah : What problem are you trying to solve? [21:31:58] multichill: Hey there! no problem in particular [21:32:11] multichill: just making sure my understanding is correct [21:32:46] sumanah: https://commons.wikimedia.org/wiki/Commons:GLAMwiki_Toolset is probably a better place to read [21:33:04] multichill: fhocutt is my intern Frances Hocutt, who's working on https://www.mediawiki.org/wiki/Evaluating_and_Improving_MediaWiki_web_API_client_libraries - I just pointed her at the new Signpost piece about the Toolset launch [21:33:25] just because there's an intersection between "people who want to use the web API client libraries" and "people who want to use GW-Toolset" [21:33:28] * sumanah reads [21:33:38] multichill: btw how are you, and how are things going? [21:33:42] GLamwiki toolset isn't api based [21:34:12] It's an extension. It uses the jobqueue to do the actual work. [21:34:23] Just packing up. Flying to London tomorrow [21:35:08] multichill: yeah, that's what I thought once I saw all the stuff in the docs about jobs, hence my statement "it doesn't just upload files using the general MediaWiki web API -- https://www.mediawiki.org/wiki/Extension:GWToolset/Technical_Design makes it look like it is doing something more integrated into MediaWiki" :) [21:35:35] multichill: so it could very well be the case that the new https://www.mediawiki.org/wiki/Data_%26_Developer_Hub should point to the toolset for some customers [21:35:56] multichill: hope you have a great time at Wikimania :) [21:36:01] Yes. Aaron just happened to have fixed it so https://commons.wikimedia.org/wiki/Special:ListFiles is full of new uploads :-D [21:36:02] thanks for confirming [21:36:33] you must be proud multichill - I know how long you & colleagues have worked on this [21:37:06] It's still quite rough on the edges, but people are using it. Today we had a workshop with some museums. [21:37:34] :) [21:37:55] sumanah: I love the collection manager of the Rijksmuseum: Why do you have those crappy images with wrong colors of our paintings and not our high res versions? [21:38:13] lol, that's excellent [21:38:29] multichill: and now you can say "you can fix it, here" :) [21:38:29] nice [21:38:38] That's what the talk page of https://commons.wikimedia.org/wiki/User_talk:Rijksmuseum_Collection_Information is about. It's in Dutch, but you can see the different versions [21:39:10] Only 48 hours left to help http://tracker.archiveteam.org/yahoovoices/ [21:39:11] cooooooool [21:39:43] Currently their masterpieces collection is being uploaded. https://commons.wikimedia.org/wiki/Category:Paintings_in_the_Rijksmuseum_Amsterdam is filling up :-) [21:40:40] this is wonderful [21:41:15] multichill: you and your colleagues have helped us get closer to achieving the Wikimedia mission - thank you so much [21:41:59] You're welcome! :-) [21:45:59] multichill: That is cool though, in the last 50 uploads, all but 3 were gwtoolset (When I looked just now) [21:46:31] A lot of these uploads got stuck for several days. This might cause a bit of extra load ;-) [21:47:11] heh! [21:47:45] multichill: Well the image scalers haven't exploded for months now ;) [21:49:09] (On a serious note, code was changed since last time gwtoolset blew up the image scalers, and stuff should be able to handle the load now) [21:50:56] :) [21:51:05] greg-g does know that this is happening right? ;-) [21:51:54] gilles is mostly the person who's on point for this, him and tgr [21:52:03] I'll just trust what they say, after they talk with Ops [21:52:15] (I think, this is re GWToolset uploads, right?) [21:52:24] * bawolff assures everyone that was a joke. Everything should probably be fine [21:52:33] * greg-g ignores [21:52:34] ;) [21:54:16] sweet [21:55:57] greg-g: these are jpeg uploads, and not even particularly huge ones [21:56:08] I don't think we ever had problems with those [21:56:26] I was just thinking of the sheer number of jobs in the queue [21:56:34] tgr: Well actually Fae's doing tiffs (but more reasonably sized one) currently as well [21:56:35] but as bawolff said we should be fine [21:57:13] Job queue regularly has more than a million things in it, so that will probably be fine [21:57:16] yeah, but he has been doing that for months [21:57:31] does not seem to cause problems [21:57:36] nm me! [21:57:52] as for queue, GWToolset self-limits to 1000 jobs IIRC [21:59:11] Now a whole batch of large tiffs [21:59:32] We're now on the 24th, so 4 more days of uploads coming in [22:01:09] multichill: Still in the 20 MB range, as opposed to the 200 mb range [22:01:58] Also, we don't do silly things with huge tiff files like we used to (e.g. Download, throw away, download again, throw away again) [22:03:26] Good night [22:03:32] night! [22:06:18] multichill: Hmm, this one looks wrong: https://commons.wikimedia.org/wiki/File:Charles_Ferdinand_Pahud_%281803-73%29._Gouverneur-generaal_%281855-61%29_Rijksmuseum_SK-A-3804.jpeg [22:06:39] I noticed some empty pages too. [22:06:47] But for some other day [22:07:22] bawolff: ideas? https://translatewiki.net/wiki/Thread:Support/About_MediaWiki:Upload_source_file/en [22:09:05] Umm, where does MediaWiki:Upload_source_file come from? [22:09:13] That's not a core message [22:10:20] umm nevermind [22:10:29] I was grepping with spaces instead of underscores [22:10:33] :) [22:14:45] Nemo_bis: Hmm, I'm not opposed. Although both seem equally clear to me [22:15:26] mediawiki:upload_source_url would also have to be changed [22:16:29] saying "your chosen, valid, publicly accessible URL" sounds kind of weird though [22:20:08] bawolff: whatever you think ok [22:25:54] lol a7839a0f6e45bb5402bf096cae360b16b41389ae [22:26:15] !gerrit a7839a0f6e45bb5402bf096cae360b16b41389ae [22:26:15] https://gerrit.wikimedia.org/r/#q,a7839a0f6e45bb5402bf096cae360b16b41389ae,n,z [22:26:50] how do you get that url from the gerrit interface? [22:27:12] gerrit is a black box of mystery to me [22:27:36] I think you can put arbitrary commit hashes in the search box, and it will just work (unless the commit hash is from svn days) [22:27:52] it is [22:27:53] that one didn't (and another one from earlier today, which is why i ask) [22:28:38] https://www.google.com/cse?cx=010768530259486146519%3Atwowe4zclqy would work, if only we kept indexing :) [22:29:04] So I take it, whatever a7839a0f6e45b is, its not a commit to mediawiki/core ? [22:29:49] UploadBlacklist [22:30:08] Sorry for the havoc, didn't think before pasting ;) [22:49:17] Wait, so did someone link the commit? [22:51:39] Why is the UploadWizard repository so large? [22:52:30] At over 30MB, I hope it includes some kinky uploads. [22:54:56] .git directory is 37MB. [22:55:34] Carmela: but but, git.wikimedia.org's url syntax is soo impossible [22:55:39] git show much more fun [22:55:55] Carmela: try git gc --aggressive -- might just be inefficiently packing. [22:55:59] inefficiently packed [22:56:27] valhallasw`cloud: That executes only on my local copy? [22:56:30] https://git.wikimedia.org/commit/mediawiki%2Fextensions%2FUploadBlacklist.git/a7839a0f6e45bb54 for reference [22:56:36] Carmela: yes [22:56:41] It's .git/info/pack or something that's huge. [22:57:35] Carmela: yes, that's the repository history [22:57:42] Right. [22:57:51] Just wondering how it seems to have ballooned. [22:58:05] I'm running aggressive garbage collection now. [22:58:37] Hmm, mines bigger (at 85 MB) for some reason [22:58:54] How do a bunch of PHP files get to be 85MB? [22:59:11] UW had a lot of JS [22:59:17] stuff added, removed [22:59:31] test frameworks [22:59:40] 2639 commits [23:00:39] My mediawiki clone is 474 mb. I wouldn't expect up wiz to be 20% of the size of core [23:01:33] Garbage collection seems to be really fucking my computer up. [23:03:58] (my core .git is 330 MB) [23:04:14] Carmela: git is going to consume a lot of memory during this [23:04:27] core GCs can go over a gigabyte for me, IIRC [23:13:18] Jesus fucking Christ that's an evil command. [23:13:40] valhallasw`cloud: git gc seems to just use all the available memory on the system? [23:13:49] I deadlocked for like 15 minutes. [23:13:56] And it's still running. [23:14:01] Carmela: it uses as much memory as it needs to. :> [23:14:24] That's some brilliant shit. [23:14:24] Carmela: you know what the best part is? git will sometimes randomly run it by itself if it decides your repo needs to be repacked [23:14:35] Okay, so it finally finished. [23:14:38] so… gc your repos manually from time to time [23:14:41] real: 17m14.984s [23:14:49] unless you want it to happen when you run git status someday [23:14:52] I cloned this repo a few minutes ago. [23:14:57] This isn't my fault. [23:15:05] Carmela: that is gerrit's / jgit's fault. [23:15:20] Okay, .git is now 6.8MB. [23:15:32] or ^d's if the server-side repack cron is dead again or something. [23:15:35] For mediawiki-extensions-UploadWizard. [23:15:38] Yeah, something is fucked. [23:15:41] I'll file a bug. [23:16:13] Also, uh, someone should fix "git gc --aggressive" to not break the world... [23:16:15] sounds like the regular snafu to me… [23:16:41] Carmela: no, you need more ram :> [23:16:50] I think I have like 8GB. [23:17:04] then it shouldn't break nothing [23:17:08] or maybe you need more cores [23:17:12] I'm not sure I need to devote all of it to garbage collecting some random Git repository. [23:17:30] git gc can take some argument to limit the number of threads it runs, iirc [23:17:37] Yeah, could be all kinds of stupidity. Git version, OS version, some interaction between the two... [23:17:46] It said it was using up to four threads. [23:18:58] Carmela: afaik, it literally needs to loads the entire repo history in the memory, construct a huge-ass graph, walk it, then recompress everything – that can take a bit of effort [23:19:15] and you hardly ever need to run it [23:19:38] Sure, I'd just rather it take longer and use less memory rather than consuming all the available memory and slowing everything down. [23:19:57] And/or use less memory. [23:20:02] <^d> MatmaRex: cron could very well be broken [23:20:21] ^d: Does the cronjob use --aggressive? [23:20:27] <^d> No. [23:20:37] <^d> It doesn't use `git gc` [23:20:42] <^d> demon@ytterbium:/var/lib/gerrit2/review_site/git/mediawiki/extensions/UploadWizard.git$ du -sh . [23:20:43] <^d> 66M . [23:21:21] What does the cronjob do? [23:21:26] <^d> should run gerrit gc --all [23:21:29] <^d> demon@ytterbium:/var/lib/gerrit2/review_site/git/mediawiki/extensions/UploadWizard.git$ du -sh . [23:21:29] <^d> 50M . [23:21:32] <^d> After repack ^ [23:21:36] Hrm. [23:22:05] does the repo have some massive long-running branches or something? [23:22:27] <^d> ssh -p 29418 localhost gerrit gc --all > /dev/null 2>&1 [23:22:38] Heh. [23:23:00] (no, it doesn't. it has a ton of branches but the longest has ten commits off master.) [23:24:52] <^d> Could be history. [23:25:42] A fresh clone of UploadWizard + git gc --aggressive had the .git directory go from 37MB to 6.8MB. [23:25:55] Silly, silly. [23:26:47] <^d> There's more refs in gerrit than what you clone. [23:26:54] <^d> refs/changes/* could be huge. [23:27:29] <^d> Heh, it's mostly history of UploadWizard.i18n.php that's taking up history. [23:27:31] <^d> No surprise. [23:27:36] Yeah, maybe I just don't understand Git very well. [23:27:44] But the whole thing seems a bit silly. [23:27:50] ^d: uploadwizard has had some very long-running changesets, but come on [23:28:05] <^d> Doesn't matter about length, it's about size of objects and how well they compress. [23:28:12] Also, I was looking at UploadWizard when I wanted to be looking at UploadBlacklist. [23:28:14] ^d: also, Carmela claims the size carries over after a clone, which obviously (or so i hope) doesn't copy all that crap [23:28:16] :-( [23:28:29] <^d> It doesn't. [23:28:51] Cloning UW requires well over 30MB. [23:29:13] That seems kinda silly to me, but shrug. [23:30:34] <^d> Yes, that's not gerrit's fault really. I have to fetch 14.25 MiB from github and end up with a 19MB clone. [23:30:40] <^d> Which can be repacked to 6.something, sure. [23:31:17] <^d> git gc --aggressive is roughly `git repack -a -d -f --depth=250 --window=250` [23:31:29] <^d> Which is super aggressive, sure. But not what you end up with in normal operations. [23:31:47] <^d> http://metalinguist.wordpress.com/2007/12/06/the-woes-of-git-gc-aggressive-and-how-git-deltas-work/ explains it well. [23:32:30] <^d> We probably have some really messy packs because of the conversion from svn. [23:32:38] <^d> Newer pure git repos probably behave better. [23:33:41] My guess was that someone uploaded some UploadWizard campaign source files to the repo. [23:33:49] <^d> Possible. [23:33:53] There is/was a giant dancing flower. [23:34:03] To represent Commons uploads, I guess. [23:34:23] <^d> most binary files don't delta well, obviously. [23:34:38] <^d> Large binaries are particularly problematic. [23:34:42] Sure. [23:40:07] Carmela: huh, this is fascinating, i can reproduce `git gc --aggressive` eating all of the available memory in the UploadWizard repository [23:40:25]