[09:02:24] LeslieCarr: In case you haven't noticed, OPEN [AMS-IX #65916] Line cards reload on SARA -> Amsterdam router will see some link flaps on it's Ams-ix connection. [09:12:59] * jeremyb reads multichill|work's ticket :) [09:14:15] * jeremyb grumbles why can't they use UTC? :) [09:14:41] maint starts in 20 secs... [09:17:43] oh, you got a new domain? surfsara now [09:18:47] i guess ganglia just has the clusters and not the particular CPUs in question here [09:23:36] ok, consolidated some tickets [09:24:13] 65576 is also coming up soon @ sara (RT 5696) [09:27:31] sleep? maybe? we'll see. bbl [09:40:57] jeremyb: SARA is the old name of the company, it started two new companies: SARA BV and Vancis BV. SARA merged with SURF foundation and SARA BV was renamed to SURFsara. Datacenter is Vancis, HPC is SURFsara. Complicated :P [10:21:32] Hi, we have a page at Commons that we cannot edit properly anymore: https://commons.wikimedia.org/wiki/User:CommonsDelinker/commands [10:22:19] rillke: mh? What do you mean with "cannot edit properly anymore"? [10:22:19] Pressing "edit" often shows a server timeout. We suspect it's because its long history. What can we do to resolve the issue? [10:22:56] https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard#Extremely_slow_performance_to_open_edit_interface_of_COM:CDC [10:23:16] Error message is "HTTP 504: Gateway Timeout." [10:23:55] number of edits: 90,588 [10:24:11] And should we regularly archive the history to avoid this issue in future? [10:24:11] legoktm: That really shouldn't matter [10:24:25] right, i don't see why that would cause timeouts [10:24:43] rillke: I've seen pages with 600k+ edits which work like a charm, this shouldn't be an issue [10:25:01] and I can't reproduce it either... [10:25:11] Today, I just ran into this issue again. Once you have edited it one time, it usually works snappy. [10:26:12] or more precisely, once, you got the edit text box [10:26:39] The edit box loads fine for me both logged in and out, but I don't dare to do a test edit [10:27:35] hoo: I seems works as soon as someone manually opened the edit mode for a while [10:27:46] Usually this page is only processed via API [10:29:13] that certainly shouldn't happen and I never saw this happen, you might want to search bugzilla and open a bug if there's none yet [10:36:05] hoo: http://toolserver.org/~delinker/delinker.txt [10:36:13] HTTPError: 504 Gateway Time-out [10:36:39] rillke: Lädt sofort und schnell [10:37:21] Ich meinte das Log des Delinkers [10:37:27] Ja [10:38:22] ortelius.toolserver.org ist etwas langsam, aber funktioniert auch [10:38:30] sehe keine Probleme :/ [10:39:51] As the trains aren't following my schedule I have to head of for now, will be back in maybe 2 or 3 hours [10:40:26] thank you [13:19:59] hello, I can't log into wikimedia commons using wikipedia credentials? is there something wrong with my account? thanks [13:25:55] Vyker: what is your username? [13:26:34] Base-w username is Vyker [13:26:56] Vyker: seems that you have no SUL [13:27:14] take a look on preferences in your home enwiki [13:27:35] there should be some stuff about it's creation [13:28:01] Global account status: Unconfirmed [13:28:01] This project site has not been confirmed as belonging to the global account [13:28:07] that? [13:28:27] seems that yes [13:28:56] Vyker: [13:29:06] Is the password for unified account the same as my login? [13:29:50] https://meta.wikimedia.org/wiki/Special:CentralAuth/Vyker when you create it it would be same as your enwiki pass [13:29:54] Vyker: [13:30:19] better https://en.wikipedia.org/wiki/Special:CentralAuth/Vyker [13:31:59] So i clicked on "manage your global account" and it asks for me to enter my password, i used the same password as I did to login but it says incorrect password [13:33:08] I just changed my password, in case there is a sync issue, and now the brand new password still does not allow the migrating of the global account [13:33:46] This account has not yet been migrated to the unified account. If the global account is yours too, you can merge this account if you type the global account password: [13:34:47] i usurped the original vyker account in July 2012 - there should be no other accounts with this username, but it won't let me unify. What can i do? [13:35:14] hmm [13:35:50] rillke: [13:36:01] hoo: [13:36:02] legoktm: [13:37:14] tl;dr can someone summarize? [13:37:38] Base-w: i'm pretty sure none of these people are knowledgeable of centralauth (and neither am i) :( [13:37:51] Base-w: Vyker: ask csteipp or anomie, maybe? (or just file a bug) [13:38:11] hoo: tl;dr allegedly ;) centralauth won't let Vyker unify his account [13:38:26] MatmaRex, how do i file a bug? [13:38:36] !newbug [13:38:37] You can start a new Bugzilla report at https://bugzilla.wikimedia.org/enter_bug.cgi [13:38:40] MatmaRex: I did quite a lot with CA earlier this year... [13:38:56] Vyker: What's your user name? Vyker? [13:39:03] hoo: oh, i didn't know. [13:39:05] what's interesting is the CentralAuth shows the Vyker username contributing 0 edits, but I have plenty of edits on en.wiki [13:39:10] hoo, yes Vyker [13:39:16] https://en.wikipedia.org/wiki/Special:CentralAuth/Vyker [13:39:52] https://en.wikipedia.org/wiki/User:Vyker <-- this is me. [13:39:54] MatmaRex Vyker hoo: Hmm. So it seems there is a global account for Vyker, but no local accounts are attached to it. Possibly whichever accounts were attached got renamed out from under it? [13:40:05] anomie: Sounds possible [13:40:12] Vyker: Can you login into the enwiki account? [13:40:14] I usurped Vyker last year. I used to be Vyker-Temp [13:40:28] anomie: [15:34] i usurped the original vyker account in July 2012 [13:40:37] (ah, too slow. :P) [13:40:58] I was the original Vyker, I just couldnt prove it with a change of email and password, so i waited until i could usurp it [13:41:14] Vyker: Can you login on the English Wikipedia? [13:41:32] Yes, i can. works fine. Preferences show the open to "manage global account" [13:41:40] but when I enter the password it requires, it says wrong passwor [13:41:49] Vyker: I suspect the answer is to go to [[meta:Steward requests/SUL requests]], explain the situation, and see if they'll delete that global account so you can usurp that too. [13:42:49] I'm not sure I understand what that means? how do I meta:steward request? what is SUL? [13:43:14] Vyker: https://meta.wikimedia.org/wiki/Steward_requests/SUL_requests. "SUL" is "Single user login", another name for what CentralAuth does [13:43:15] Vyker: Forget that, just try it again now :) [13:43:23] anomie: Just deleted the global account [13:43:39] Vyker: Or you can get hoo to do it for you q: [13:43:51] Yes, it worked :) [13:43:52] Login unification complete! [13:43:52] You can now log in to any wiki site of the Wikimedia Foundation without creating a new account [13:44:01] \o/ [13:44:34] thanks for your help :) i can now upload to commons for the Momuments prize :) [13:45:05] :)) [13:46:43] hoo: now you'll be my go-to guy for centralauth mind-benders. you've brought it on yourself. :D [13:47:07] :D Still better than AbuseFilter [13:47:57] heh [13:50:47] done https://commons.wikimedia.org/wiki/File:Syon_House.jpg :) Thanks for making it possible for me to contribute hoo :) [13:50:55] Lets hope I win [13:51:33] heh, you're welcome :) Always glad to help [14:58:38] multichill|work: hrmmmm. i'm not sure if i understand entirely. also, you need some work on enwiki. https://en.wikipedia.org/wiki/Stichting_Academisch_Rekencentrum_Amsterdam doesn't mention /surf/ at all. :-) [14:59:04] [[viacom]] says '''The current Viacom was created on December 31, 2005, as a spinoff from CBS Corporation, which changed its name from Viacom to CBS at the same time.''' as a comparison :) [14:59:04] jeremyb: Completely outdated [14:59:42] multichill|work: hence "you need some work on enwiki" :) [14:59:54] https://en.wikipedia.org/w/index.php?title=Stichting_Academisch_Rekencentrum_Amsterdam&action=history <- 145.100.6.x , that's the workstation lan :P [15:00:18] Conflict of interest [15:00:33] that's almost 4 years ago? [15:00:52] i was going to complain that it wasn't ipv6. but we didn't have it that long ago [15:02:22] svick, I don't know if parent1234 told you but he can't make the meetings now unless they are 4 hours earlier, cause of work. [15:02:41] I dunno if that time would be a drag for you. I don't care, since I'd be working anyways. [15:03:13] apergos: hello [15:03:27] it's not a big problem for me [15:04:47] ok, I'll leet him know [15:04:54] and cc you too [15:06:56] done [15:07:09] if there's a problem now at least you will get the reply email [15:07:17] ok [15:07:29] so, over the weekend, i discovered and fixed some memory leaks in my code (they didn't cause problems on smaller wikis) [15:07:51] ahhh [15:07:54] excellent [15:08:08] and i also discovered a significant problem with the way i'm using zdelta and ordering revisions [15:08:19] let's hear it [15:08:43] when i'm writing a dump, i read the XML, which seems to be ordered by timestamp [15:09:05] but when i'm reading a dump, i read the revisions ordered by revision id, as you suggested [15:09:17] well it's not always ordered by timesamp [15:09:19] *timestamp [15:09:46] right, but it's certainly not ordered by revision id, which is the important point now [15:09:52] mm hmm [15:10:30] but the problem is that zdelta work based on the "last" few revisions [15:10:52] and that can be very different for writing and for reading [15:11:28] well what does 'last' mean? it means the last ones inserted [15:11:35] a solution would be to recird which revisions should be used to decompress [15:11:41] *record [15:12:37] well, the details about what last means are up to me, but generally it has to be something that you can access during both compression and decompression [15:12:50] sure [15:13:14] but what I mean is, you want it to be (I assume) the ones last inserted, i.e. that you saw over the last few incremental dumps [15:13:49] or would have seen if you were running them (given we aren't running them yet) [15:14:12] i'm not talking about multiple dumps, this is problem even with a single dump [15:15:01] if you did them all by timestamp I guess you would hit the same problem unless [15:15:31] unless i can be sure that the XML dumps are ordered by timestamp [15:16:02] unless this gets agreed on here https://bugzilla.wikimedia.org/show_bug.cgi?id=27112 and patched and deployed [15:16:17] right [15:16:41] though in the end, i think this doesn't matter, because it looks like LZMA with groups is better than zdelta [15:16:45] I think here we expect the rev id to be monotonically incr in the prefetch [15:17:10] so we would need to order by rev id most likely in order not to break the current dumps [15:18:06] well, with prefetch, you can always just get it from the DB, that slows you down, but this doesn't happen often, so it's not by much [15:19:05] it doesn't happen often but having code in one place assume 'by timestamp' while code in another part orders by rev_id contradicting thta, would never get by code review :-P [15:19:16] i can do something similar by retrieving a revision that's not among the last; except it depends on other revision, which depends on yet another, … [15:19:23] right [15:19:39] uh huh [15:20:06] and i can work around that by not making the delta chains too long; except that makes the compression ratio even worse [15:20:21] so i think LZMA with groups is the better option [15:21:00] cool [15:21:38] for twriki, LZMA with groups is 2.32 GB, and zdelta is 3.06 GB (it's striked over in the table because of the problem i was just describing) [15:21:45] ah [15:22:08] well lzma is better [15:22:14] I guess speed will be the next thing [15:22:23] especially for applying incrementals [15:23:16] I was interested to see that the breakdown of metadata and comressed texts for tr wiki is roughly half and half [15:23:21] yeah, when i was creating the trwiki dumps, i didn't measure the time (mostly because i was doing them partially in parallel, so the measurements would be far from accurate) [15:23:36] but i did notice that zdelta was faster than LZMA [15:24:38] right, i want to look at that more closely, to see how much are comments and how much users [15:25:08] (especially users could be optimized by adding an index, so that the user name is not repeated) [15:25:57] right [15:26:50] but since time is running out, i want to focus now on properly implementing compression, things like deleting a revision don't work right now [15:28:15] yeouch [15:28:27] yes, get everything working even if clunkily [15:29:01] exactly [15:31:39] can you think of anything that belongs to the “everything working” category that's not done yet? [15:31:59] maybe progress reporting when reading from XML [15:33:52] lemme look at my list anyways [15:35:22] nope, nothing tht has to be done before end of gsoc [15:35:42] making sure we can recover if it dies or is shot in the middle, is something for afterwards [15:35:55] (though it is a requirement, for and run that would talk longer than 1 day) [15:35:57] ok, great [15:35:58] the prolems with the translate extension on meta are already known? [15:36:15] Steinsplitter: don't know but I'm in a meeting... [15:36:31] okay. later :-) [15:36:37] apergos: hmm, i think that would be hard to do [15:36:43] uh oh [15:37:14] is that even necessary? i don't think anything beyond creating first incremental dumps will take more than a day [15:37:21] we'll find out [15:39:10] and the only relatively simple way to implement that that i can think of would be to process n pages, copy the whole dump somewhere else and then continuing [15:39:36] which would be quite slow, if the whole dump is tens of GBs [15:39:50] yes, that approach is untenable [15:40:27] you do it in page order though, so if we could have it tell us the last complete page updated was X [15:40:56] we could start by processing the next pageid, writing over what is there already [15:41:40] well, that would mean i would have to write each change to an index immediately (or at least once per page) [15:41:50] which i think would mean lots of additional seeking [15:42:01] how often do you write now? [15:42:23] very rarely [15:42:54] well is that once every 1k pages? once every 100k? [15:43:16] i'm not sure exactly [15:44:16] because a margin of very few thousand pages is fine, of every 100k is not awesome, of millions is definitely out [15:44:27] anyways it doesn't have to be solved right now, just something to think about [15:44:46] i'm quite sure it would be okay to write all indexes every 1k pages [15:44:58] that would be just fine for restarts [15:45:08] right now for the big wikis we are happy to lose 12 hours or a day [15:45:19] just not a week or two weeks [15:46:15] i would have to make sure that i write indexes only every those 1k pages (or whatever), otherwise they would be in an inconsistent state [15:46:41] right [15:47:04] i think that right now, i'm writing some nodes to the disk when i split a node, but i think i don't have to do that [15:47:19] ok, that could work, i think [15:47:25] sweet [15:47:51] one problem is low-level deletions [15:48:22] for example, when i add some revision ids to a page object, i delete it and save it to a new place [15:48:29] sure [15:48:34] and then most likely overwrite the old one with other data [15:49:06] so if you restart, you get the overwritten data where you expect the original page [15:49:28] that'll be fun [15:49:38] and bear in mind someone can shoot your process at any point [15:49:47] it's happened to me... [15:50:33] yeah, i know [15:53:06] i guess the filesystem on the server isn't something that supports copy-on-write, right? (i realize that's not likely, i guess only Sun's ZFS supports that) [15:53:22] you shouldn't make assumptions about the filesystem [15:53:30] right [15:53:51] we could run xfs today, ext3 tomorrow, btrfs the next day, no use building that sort of thing in [15:54:12] also zfs tore my heart out and put it through the shredder but that's another story [15:55:28] mmmmm zfs [15:55:29] :) [15:55:54] hmm, i think i have a solution: when i delete some object, i won't overwrite it until the next checkpoint [15:56:19] that way, i think i can be sure that after a restart, all the data is still there [15:57:00] it would waste some space, but probably not much [15:57:01] that could work [15:58:17] anyway, i think it doesn't make much sense to deal with that in detail now [16:00:15] ok, so i'll work making compression using LZMA with groups work correly and i can't think of anything else [16:01:01] ok [16:01:10] looking forward to it [16:01:38] see you tomorrow, 4 hours earlier [16:01:43] so we can try for 4 hours earlier [16:01:59] if parent1111 doesn't show up, well he wouldn't have shown up later either [16:02:12] see ya tomorrow [16:02:21] ok [16:19:08] Hello, I am having trouble connecting with a bot to the Swedish Chapter wiki: se.wikimedia.org [16:19:27] I am getting the error pywikibot.exceptions.Error: Family wikimediachapter does not exist [16:21:02] Ainali: have you created the family file? [16:21:23] I have a wikimedia_family.py [16:22:14] I tried renaming it to wikimediachapter_family.py but that did not help [16:22:17] why are you using wikimediachapter then [16:22:48] In my config.py I have: family = 'wikimedia' [16:23:13] so it seems wikimediachapter comes from somewhere unknown [16:27:01] hmm.. in my wikimedia_family.py it says self.name = 'wikimediachapter' [16:27:54] but renaming that does not help either, I get the same error [18:06:19] Any shell user available to recover the password of the first user of it.wiki? [18:10:18] Nemo_bis: Why? [18:11:18] reedy are you there? and if so, can I msg you please? [18:11:27] About? [18:11:38] I have a question about SecurePoll [18:11:50] Reedy: User:Gianfranco lost his password on it.wikt and it.quote https://it.wikipedia.org/w/index.php?title=Discussioni_utente%3ASpinoziano&diff=61172251&oldid=61156901 [18:12:06] No email set? [18:12:08] (those two accounts are unattached) [18:12:17] nope [18:12:38] :/ [18:13:25] (ok, technically he's user #187 but he's our "little father") [18:14:08] He's logged in [18:14:14] Can't he set an email and then use it to reset? [18:14:42] Reedy: logged in where? [18:15:01] That edit was made logged in as his account? [18:15:05] he needs the password reset on it.quote and it.wikt, or the two accounts attached to the global one [18:15:12] yes [18:15:16] Oh [18:15:19] (the global one) [18:16:14] Reedy: we can talk here, but I just wanted to make sure I haven't just emailed you the same thing [18:17:32] (as in, I wanted to see if you are the same person as the recipient of the email or not) [18:34:50] It looks like en-wiki Featured Pictures is going to go over to new-style galleries [18:35:17] That'll be, I think, the most prominent use of them to date. [18:35:20] neat [18:36:05] whee [18:36:29] When I was settign up the test, I had to tweak the heights parameter to give more space for the captions, but, other than that, it was easy. [18:37:10] (At default sizes, som of the lengthier captions were taking up huge amounts of vertical space. [18:37:29] If attached to a narrower photo [18:37:45] That might be worth including in the documentation. [18:38:25] As it's very easy to fix if you know what you're doing. =) [18:41:18] Lessee... copy-paste from my Signpost article, because GOD Help:Gallery tag is out of date now... [18:42:11] Am I right in thinking "widths" does nothing if not in "traditional" mode? [18:42:16] (or nolines) [18:44:18] AdamCuerden: i think you are [18:44:32] AdamCuerden: i vaguely recall this being said somewhere [18:44:49] bawolff would know if he hadn't left [18:44:51] @seen bawolff [18:44:52] MatmaRex: Last time I saw bawolff they were quitting the network with reason: Ping timeout: 256 seconds N/A at 9/9/2013 6:37:40 PM (7m11s ago) [19:06:57] https://en.wikipedia.org/wiki/Help:Gallery_tag [19:07:00] There [19:07:43] How's that look? [19:07:59] Think that's the first documentation we've got of the new modes. =) [19:16:03] Reedy: so, is it possible? [19:16:09] Dunno [19:16:15] Can we prove it's definitely his accounts? [19:16:48] for it.quote he said so [19:17:49] from the it.wikt contribs it's rather obvious [19:20:09] and we have two identical edits at the same time here https://it.wikiquote.org/w/index.php?title=Speciale:Ripristina&target=Incipit%2FDa+Wikipedia%2FL-P×tamp=20070526150037&diff=prev and https://it.wikipedia.org/w/index.php?title=Santa_Lucia&diff=prev&oldid=8947460 [19:22:14] ah no, that's imported so it doesn't count :) [20:55:34] manybubbles: ping [21:20:36] can anybody tell me what contents is being served by http (not https) in https://vo.wiktionary.org/wiki/Lingl%C3%A4n ? [21:20:52] Firefox is complaining about it and I'm afraid it may be some local JS [21:21:58] malafaya: i'm not seeing any non-secure resources [21:22:35] iirc clicking on the lock icon next to the URL should specify which resources are non-secure [21:24:26] the lock icon gives me the certificate info [21:24:38] if i click in "More info", i see no http [21:24:43] just https: and data: [21:29:46] IE also warns be about unsecure contents [21:30:04] malafaya: Firebug extension might be useful [21:30:18] "willl tell you how your elements are loading and which aren't going through the ssl layer." [21:31:35] malafaya: i don't see any when logged out [21:31:44] ah, or this ? http://www.whynopadlock.com/ likes it as well [21:31:51] "All 56 items called securely!" [21:32:07] i am logged in. i don't know if it makes a difference [21:32:48] malafaya: well, let's see [21:32:59] it does make a difference [21:33:35] malafaya: doesn't for me. it's gotta be some gadget you have enabled or something [21:34:03] oh, good guess. i was just looking in my local JS [21:34:05] let's see [21:34:09] heh, there's only one [21:34:38] malafaya: yeah, it's hotcat [21:34:45] oh.. i love hotcat [21:34:51] it loads http://commons.wikimedia.org/w/index.php?title=MediaWiki:Gadget-HotCat.js&action=raw&ctype=text/javascript&smaxage=21600&maxage=86400 [21:34:58] lessie… [21:35:30] malafaya: make the link in https://vo.wiktionary.org/wiki/Sitanuns:Gadget-HotCat.js protocol-relative and it'll be all good [21:35:53] malafaya: just remove "http:" in first link and the entire if(){} section [21:36:40] should be ok now [21:37:18] thanks for you hints! :D [21:37:35] i was locked on JS scripts and didn't think of gadgets [21:38:08] :) [21:53:32] Reedy could you please update the cached special pages? [21:53:53] Shouldn't it get done automatically at some point? [21:56:30] class { misc::maintenance::update_special_pages: enabled => false } [21:56:42] what is that point at this time? [21:57:04] eh. on hume: class { misc::maintenance::update_special_pages: enabled => true } [21:57:33] reedy@ubuntu64-web-esxi:~/git/operations/puppet$ grep update_special_pages manifests/site.pp [21:57:33] class { misc::maintenance::update_special_pages: enabled => true } [21:57:33] class { misc::maintenance::update_special_pages: enabled => false } [21:57:33] Last update 24th August [21:57:34] monthday => "*/3", hour => 5, minute => 0, [21:57:39] malafaya: [21:57:44] every 3 days [21:58:05] Last update 24th August [21:58:12] The point of the enabled => false is to make sure it gets disabled by puppet so we don't have to clean up after it [21:58:15] was the config changed recently? [21:58:15] ./manifests/misc/maintenance.pp [21:59:22] Not really [21:59:40] so why hasnt it been running? [21:59:48] i thought it had been disabled for some reason [22:00:36] thus me asking you to update it manually [22:04:46] bug:53227 also states that [22:05:08] as i recall, 24/08 was when you ran it manually [22:05:30] the bug says it doesn't update since 13/08 (if you exclude 24/08) [22:08:10] malafaya: i'll run it .. [22:08:24] !log running update-special-pages on hume [22:08:27] Logged the message, Master [22:08:47] mutante, any clue why it shouldn't run with cron but does manually? [22:09:27] It needs moving from hume really [22:09:33] not yet, i'm running it as apache , like the cron does