[10:28:31] Hallo. Is it expected that https://*.wikipedia.beta.wmflabs.org sites don't quite work over https? [10:36:29] aharoni: they should :-D [10:36:46] aharoni: but you have to manually allow the certificate [10:37:14] hashar: i did it, but only text is loaded without any styling. [10:37:30] https://bugzilla.wikimedia.org/show_bug.cgi?id=48501 - [OPS] beta: get SSL certificates [10:37:43] yeah you need to accept the certificate for bits.beta.wmflabs.org as well [10:40:13] hashar: ehhh... maybe, but how do I actually do it? [10:51:45] do what ? [10:52:53] accept the certificate for bits.beta.wmflabs. [10:53:06] Firefox didn't ask me about that. [10:53:13] no idea [10:53:18] I am not using firefox anymore :D [10:53:50] I guess https://bits.beta.wmflabs.org/foo would prompt you to accept the cert [11:04:28] hashar: it worked, but with no wikipedia logo [11:10:17] aharoni: do the same for https://upload.beta.wmflabs.org/ ? :-D [11:12:34] hashar: nice, thanks. now if you could take a loot at #wikimedia-dev... :) [11:13:26] can't connect to my account with Opera (cookies deleted, but no change) [11:14:51] aharoni: ask again there ? :-D [11:44:13] hegesippe: what is the errors you are getting? [11:45:37] from connection screen, I make all necessary, but I still 'seem' ti be not connected on the top of the screen. No problem with Firefox or Chrome. [11:45:52] to be [13:11:02] !ops [13:11:11] yep? [13:11:48] Thehelpfulone: Could you remove the ban on 204.14.77.0/25? See -en-help. [13:12:51] one sec, just checking logs as to why the ban was put in the first place [13:16:32] \o/ [13:16:46] My76Strat: :D [13:16:58] okay looks like it was an ED spammer so I set a +e on My76Strat's cloak -- Jasper_Deng_away when the ED range ban is removed, please can you remove the +e too? [13:17:56] I have noticed on more than one occasion that your username is quite apt. [13:28:49] sorry I forgot I was using my battery and didn't get back in time [13:50:03] My76Strat, thanks :-) [13:50:47] you're welcome [14:05:18] Okay. [14:05:32] I'm discussing with the English Wikipedians and I'm getting a better sense of why the VisualEditor frustrations run high. [14:36:55] Elsie: Just saw this on Simple: [14:36:56] 02:48, 1 August 2013 User account Simplekindaman1976 (talk | changes | block) was created automatically [14:36:56] 02:46, 1 August 2013 User account Simpleman1976 (talk | changes | block) was created automatically [14:37:11] Autocreated accounts but there is no global account for either [14:38:07] Are there conflicts elsewhere? [14:38:23] Auto-SUL only happens when there are no conflicts on other wikis, as I understand it. [14:38:28] Though maybe not. I can't remember. [14:38:43] Bsadowski1: ^^^ [14:39:10] Hmm [15:04:03] @replag [15:04:04] Merlissimo: No replag currently. See also "replag all". [16:18:50] apergos: hello [16:18:57] hello [16:19:23] how are things today? [16:20:49] i've been looking at how the existing scripts (dumpBackup etc.) work and thinking about how to use them and what i need to add [16:21:43] it looks like i can use 1-pass dumpBackup with revision range to get new pages and revisions, that should be simple [16:22:06] the complicated part is deletions and revdeletions [16:22:30] at first i thought i can use the logging dump for that, but it looks like it doesn't have the information i need [16:23:17] well and you can't guarantee it will always be right either [16:23:28] sometimes stuff doesn't get logged properly [16:24:05] well, i have no idea how could i handle that efficiently [16:24:33] i don't want to go though all pages and revisions to make sure they look the same in the DB as in the dump [16:25:21] this is exactly why there is first metadata pass: to get an authoritative list of the pags and revisions as they exist now [16:25:43] (in the existing dumps) [16:26:16] so you think i need to do something like that too? i don't like that [16:26:37] why would something not be logged properly? [16:26:43] because there are bugs [16:26:53] oh [16:27:00] sometimes something is in the log and it didn't happen; other times something happened and didn't get logged [16:27:57] so the thing about asking "what is in the page table?" is that mw uses that in order to display pages, so if it's wrong and there's some page missing, you're still good, because for mw that page is gone [16:28:07] even if there is an orphan text someplace off in th wild [16:28:13] same is true for the revision table [16:31:03] hmm, if this is only about the list of page ids and the list of revision ids, that could be done quite quickly (because i have those in indexes) [16:31:26] well [16:31:37] if a page id is gone now, then the page is considered deleted [16:31:44] so you want to be able to toss those [16:31:53] if a rvision id for a page isn't around, the same is true [16:32:47] undeletes look like new pages; unsuppressed revisions just have the rev id showing up where it wasn't before [16:33:21] ok, that shouldn't be a problem [16:33:27] remember you are using a retrieval mechanism that only shows you public data, (the php scripts) [16:33:32] but if i need to handle cases like “the page with id x was renamed, but the rename wasn't logged”, that would be more complicated [16:33:39] so if something is now public and you didn't have it, you go get it [16:34:13] if something is not in the new list, you toss it from the old dump (if you are merging the new dump into the old one I guess) [16:34:19] so renames look like [16:34:56] before I just spout off let's double check what they look like [16:40:26] well that's unfortunate [16:40:43] Title.php: moveToInternal [16:41:17] the redirect if any will have a new page id of course so you needn't worry about that. but [16:42:19] changes the title, keeps the old page id (unless moving over a redirect I guess) [16:42:25] so then you gotta check for that. meh [16:44:08] and then there's revision deletion; it seems to have enough data in the log, but if i can't rely on that, it would mean i would have to check every revision to make sure it didn't change [16:44:12] I guess you would need to check namespace, title, redirect [16:44:27] because those all get written out in the xml and can conceivably change [16:45:33] the only think you would need to recheck in the revision table is existence of the revid [16:45:58] unless we wind up adding fields to it (e.g. rev_sha1 got added, which meant new retrieval of the row for all of those) [16:46:06] that's not the expensive bit, text is the killer here [16:46:18] e.g. stubs get generated relatively quickly [16:46:39] once in a blue moon rows in the rev table might get altered by hand due to some bug [16:46:56] so we would want to be able to manually specify a full check I suppose [16:47:09] * apergos wonders if brion is actually there or still wakingup [16:47:26] * brion yawns [16:47:37] ah. in that case enjoy your coffee :-D [16:48:20] Svick: this is something you could talk about on the list too [16:50:05] what if someone uses RevisionDelete to hide the text of a revision, but it won't get logged? doesn't that mean revisions have to be checked every time? [16:50:34] if the text is hidden then the revision is hidden with it [16:50:49] there's no mechanism for leaving the revision row around but hiding just the text [16:51:43] what? i thought that's exactly what RevisionDelete does [16:52:06] the revision row is not visible to the public afaik [16:52:58] let's look at the code [16:53:33] ok, then what if someone hides just the comment, that certainly doesn't hide the whole revision [16:54:24] that's true [16:54:59] let's see how that works actually [16:56:31] Revision::DELETED_USER, Revision::DELETED_COMMENT, Revision::DELETED_TEXT [16:56:37] bitfield in rev_deleted [16:56:39] oh joy [16:56:46] so any combo of those can be hidden [16:57:36] yeah [17:02:04] i think this means i will need to get the full stub dump every time and combine that with fetchText [17:02:58] hmm if we guessed that hidden revisions are a small portion of the whole, you could ask for revision ids that have a non zero rev_deleted, and only check those (and the ones you already have recorded, this would mean javing that field in the binary dump too) ... I like it less [17:03:58] ok well stub dumps are already generated as boring old XML, the question is whether that's sufficient for you or whether your job would run faster with a stub in binary format for input [17:08:34] if i'm looking at it right, creating stub dumps for enwiki takes about half a day; that's quite a lot, though it does include compression [17:11:39] 8 hours (with parallel jobs, but those finish in wildly different times, as the split is targeted for the page content dumps) [17:11:55] the recombine eats some cycles of course [17:15:48] compare though dewiki, half a day for stubs, 11 days for page content (excluding recomprssion to 7z) [17:16:01] it will be a little better now that I've split up that job but still [17:18:04] the history job of en wp if done in serial as one job would take something like 90 days [17:18:11] so that's where the time saving needs to be [17:18:28] you mean stub-history? [17:18:40] no, I mean the content history [17:18:45] right [17:19:27] hmm, i think that reading the whole stub dump is a reasonable solution for now; if it turns out to be too slow; we could try switching to the rev_deleted query you suggested later [17:19:48] that wll not be your bottleneck, trust me :-) [17:19:49] though i have no idea how much faster would it be, since i think there isn't an index on rev_deleted [17:19:54] nope [17:19:55] right [17:20:53] the question will be whether you generate binary format stub dumps and use them as input or [17:21:18] if you read old-style gzipped xml stubs [17:21:44] or if you use your reader to supply xml format on stdin from binar format stubs [17:22:01] that decision can be put off for now though [17:22:56] i think there is no reason to use compression here, i can directly read the output from dumpBackup [17:23:20] for the stub you mean, and save it as...? [17:23:58] will it be useful to have binary format for this? will you be able to generate actual 'incrementals' for stubs? [17:24:14] If you can, that's worth doing [17:25:03] Bsadowski1: file a bug about it please [17:26:40] there is no global account but no conflicts, so it seems the global account got lost somewhere (or worse, the local account was automatically created unattached AND with wrong name??) [17:26:55] hmm [17:27:05] if this isn't going to be the bottleneck, then i think binary format doesn't make much sense; it would mean reimplementing parts of my C++ code in PHP (that's certainly doable, i just don't see the reason to do that here) [17:27:20] er no, I sure didn't have that in mind [17:27:38] the only down side is that you won't have incremental stubs but folks will just have to deal with that [17:27:43] oh, then i misunderstood [17:27:49] those are small compared to everything else [17:31:22] i can still have incremental stubs: for every revision on input, i compre it with what's in the dump; if it's the same, i do nothing; if it changed, i update the dumps and add the change to the incremental [17:32:07] ok, so the plan would be to have binary format stubs [17:32:08] cool [17:33:47] oh, now i think i see what you meant: if we use the XML stub, then we could directly use that [17:34:01] *also directly use that [17:34:19] yes, but it doesn't need to be decided now [17:34:30] benchmarks will show whether that's a good or bad idea, later [17:34:47] I'd like to have incremental stubs, even if they aren't the main goal [17:35:45] that's true; i can generate binary stubs no problem; if we decide to not use them, that's basically just a flip of a switch [17:36:14] yep [17:36:52] so I would encourage you to float the question about clever ways to not have to read all the revision rows again, on the lists [17:37:12] maybe nthing will come out of it but you never know [17:40:51] i'll think about that [17:41:39] How did [[User:Ocaasi]] manage to get the API to trick editors into posting messages? [17:41:54] if you don't have anything else, see you tomorrow [17:42:06] nope, this was already two days' worth of meeting :-D [17:42:08] hi dmacks: it's built into a guided tour. it's not a trick, it's just part of the tour. [17:42:09] see you! [17:42:32] dmacks: i'm happy to make that clear in any way that avoids confusion [17:42:55] Ocaasi: I'll be happy to block you if you cause editors to unknowingly post messages. [17:43:12] Especially if they did not opt-in to that sort of service. [17:43:35] dmacks: i'll be happy to inform them up front that as part of the onboarding tour they will send messages using the API [17:43:49] That sounds reasonable. [17:43:51] it will be opt-in, as it should be [17:44:27] dmacks: thanks for your concern. seriously, if you think i can make this more clear, i want to hear about it. i'll go add the opt-in language now, but i'd like you to check it afterwards if you'd like. [17:45:38] Sure. Leave a note at the ANI section (obviously I'm not the only one extremely upset about how it's gotten started). [17:47:07] why on [[WP:Shitfights|ANI]]?:P [17:47:39] MaxSem: because that's where several others have already brought it up. [17:48:41] (once the shit's a flyin', can't get it back off the fan and into the...wherever you store it) [17:51:00] Kww never heard of JS his browser executes? "omg hackerz" [18:04:38] uh https://bugzilla.wikimedia.org/reports.cgi?product=VisualEditor&datasets=UNCONFIRMED&datasets=NEW&datasets=ASSIGNED&datasets=PATCH_TO_REVIEW&datasets=REOPENED [19:10:19] grah, 503 on wmflabs etherpad [19:11:04] ok, back :) [19:14:51] greg-g: I had something to tell you but I can't remember what :( [19:15:09] * hashar suddenly realize he is not helpful [19:15:21] hashar: :) [19:17:34] ah I found out [19:18:34] greg-g: that was regarding Icinga monitoring of labs. You could get in touch with LeslieCarr/mutante to have them look at it. I don't know enough of Icinga to create an instance for beta :/ [19:18:59] * greg-g nods [19:19:00] thanks [19:19:00] ah, we realized that labs nagios is all manual setup [19:20:08] sigh, said so from the beginning [19:20:30] greg-g: wanna try epl.wikimedia.org instead? [19:21:06] mutante: yeah, the wmflabs one was just where my on-going doc I share with robla was/is [19:21:29] mutante: so, what are the next steps for icinga and the beta cluster? https://bugzilla.wikimedia.org/show_bug.cgi?id=51497 [19:22:43] mutante: well there is a script that given some puppet class would apply a specific check [19:22:52] but that is very limited :) [19:23:16] sorry, labs is labs…. [19:24:06] LeslieCarr: not really a legit response for the beta cluster anymore, it is going to be relied upon for testing, as planned :) [19:24:14] labs services are unsupported, except for deployment-prep and tools [19:24:17] greg-g: trying to apply the icinga puppet classes to a labs instance, and not using the private contacts so we dont get pages [19:24:30] tools and deployment-prep are considered "semi-production" [19:24:31] right, deployment-prep/the beta cluster, whatever name we use :) [19:24:40] greg-g: replacing petan's labs nagios setup from scratch [19:24:44] my rough idea was to get advantage of all the checks already existing in production, have them applied on a Icinga instance in beta but with paging disabled (obviously) [19:24:53] mutante: there's no exported resources in labs [19:24:56] mutante: "from scratch" :/ ugh but yeah :( [19:24:59] this way whenever you guys add a check, it is available in beta ;) [19:25:08] so the way we do this in production won't work [19:25:13] * greg-g nods [19:25:49] greg-g: yea, sorry but i predicted this day when we got the manual setup that didnt match prod at all [19:26:04] LeslieCarr: you may have been responding to the etherpad issue, I might have misunderstood, if so, my bad :( [19:27:06] mutante: I guess the question becomes one of time allocation. Ken/Robla agreed that we "need" this, when it happens should be worked out, I guess on your guys' side in conversation with ken/whoever [19:27:49] I'll obviously take what I can get and won't get in the middle of that conversation [19:28:03] was just curious what the next step was, and didn't realize it was as nasty as this [19:28:07] "relied upon" is kind of not-beta [19:28:34] well, it will be, that's the point. We actually do need to rely on a pre-production environment to do testing, otherwise we're kind of amature [19:29:12] brb, going to grab a burrito ;) [19:29:19] (from the 6th floor kitchen) [19:29:27] bbl, got a meeting [19:43:06] btw: didn't mean to imply we *are* amatures, just wanting to be explicit about our goals :) [20:05:10] just weighing in quickly. I pretty much agree with what Greg is saying here, but I'll add what is hopefully some helpful nuance.... [20:05:46] the beta cluster does need monitoring, but how we respond to it can be very different than production [20:05:57] ...and obviously will be [20:06:23] e.g. clearly it's mainly a business-hours only concern [20:07:49] other parts of engineering outside of ops have a much larger role to play in keeping it running [20:11:09] greg-g yeah, etherpad [20:25:59] LeslieCarr: then yeah, labs is labs ;) [20:27:19] * greg-g moves all his "important" etherpads to epl.wikimedia.org [20:27:31] puppet freshness could be CRITICAL on labs *right now* and no one would know [20:32:30] [6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~[6~/win 2 [20:34:11] oops [20:35:52] ori-l: "Service is not scheduled to be checked... " do you happen to know what the current issue is? because it existed and has been fixed in the past [20:36:15] http://icinga.wmflabs.org/cgi-bin/icinga/status.cgi?host=all [20:36:39] gotta ask petan [20:36:44] heh, I was trolling. no idea. [20:37:19] hehe [20:37:55] greg-g: next step there is we're gonna look at importing pads from old etherpad [20:38:49] ori-l: ok:) so,i think it's probably that the snmptrap doesn't get from instances to the host or related [20:39:19] ah yeah, and snmptrapd didn't have an init script so it died after each reboot afair [20:39:43] mutante: oh, so I shouldn't just copy over under the same name? [20:39:49] mutante: re epl. [20:40:29] greg-g: if you take it from ep-lite in labs that's fine, i meant old production etherpad [20:40:43] ahh, k [20:40:56] well, i didn't try the import script yet, i just know there is supposed to be one [20:41:13] so not sure what happens on existing pad names when trying to import over it [20:42:21] * greg-g nods [20:42:24] warn us :) [21:05:11] wmf git, y u so slow [21:05:30] Now I'm waiting for 5 different git commands to finish [21:05:32] ... [21:05:50] gerrit is maybe down [21:06:02] at least stupidly slow [21:06:38] CPU hogging.. people are looking at it while we speak [21:06:58] * greg-g nods [21:10:13] JeroenDeDauw: did you know about 'recheck', fwiw [21:10:22] Leslie restarted gerrit [21:10:38] but it may also help if you comment "recheck" to actually make it check again [21:10:41] now it works again…. mostly [21:26:18] UploadWizard is broken for me in Chrome. [21:26:29] I get to the license step and Next does nothing [21:26:34] no error, no response [21:33:57] no error in console StevenW? [21:34:08] marktraceur, ^ [21:34:28] let me check [21:35:07] StevenW: try adding debug=True in the URL? [21:35:53] Console errors for unknown languages [21:35:55] but nothing else [21:36:01] trying with debug on [21:36:48] "nothing else" might not be relevant :) [21:37:04] what are the exact 'errors for unknown languages'? can you post them here or put them on pastebin (if they're too long) or something? [21:37:39] ULS: Unknown language doi. [21:37:46] ULS: Unknown language fonipa. [21:37:51] Oh. Right. [21:38:08] but no errors in console when a button fails to do anything... weird [21:38:15] Yeah this is bizarre [21:38:44] StevenW: debug=true didn't help? [21:38:49] nope [21:39:02] StevenW: how many images were you trying to upload? [21:39:10] one [21:39:23] screenshot of wikipedia with a custom license [21:39:23] oh. UW does something weird which takes a lot of time usually [21:39:34] probably synchronous ajax or something [21:41:55] StevenW: wfm, and I'm not seeing UW failures in the browser tests on beta commons or test2wiki [21:42:49] He's not in the channel anymore [21:43:54] marktraceur: yep, just missed him [21:44:21] MatmaRex: I don't think we let any of the 'async: false' code in. They're all still in Gerrit, -2'd [21:52:35] YuviPanda: I actually rewrote one of the patches [21:52:39] It's kinna huge now [21:52:41] Sorry [21:52:53] one of the ones containing async: false? [21:52:57] Yup [21:53:05] sure, but I don't think any of them got merged with async: false still in them [21:53:06] Now it uses t3h pr0m1s3s [21:53:14] No, not even close [21:53:19] We'd neeeeever do that probably [21:54:17] Apparently we're OK [22:24:51] bd808: so, you should have received at least 2 emails, one with the user name and one with the initial pass [22:25:27] fyi, when you mail RT you get auto-created accounts, the difference is being a privileged user with more permissions now [22:25:31] same for kenan [22:27:18] mutante: got them. thanks [22:29:08] bd808: regarding the different "queues" in there, if in doubt just use "ops-requests", they can be moved [22:29:54] and the whole dashboard is customizable, note the Edit links in the upper right corners of the default widgets [22:31:07] mutante, what can an auto-created account actually do? [22:31:36] Krenair: read his own tickets, login to web ui, read other tickets in ops-requests if he knows the numbers [22:32:06] ehm.. comment but not resolve or reject [22:32:17] so basically anyone can create tickets and read ops-requests tickets if they have the link? [22:32:22] yes [22:32:51] I didn't know that. I thought the whole thing was approval-only [22:33:09] it's a common misconception, but it's always been like this [22:33:23] well, there is a trick to getting the password [22:33:57] you have to tell RT to mail it to you to login to web ui [22:34:21] So you mail rt@wikimedia.org in a certain way and it creates an account? [22:34:24] but you can always mail to a specific ticket number as well [22:34:43] you mail ops-requests@ [22:35:00] that doesn't open a ticket does it? [22:35:03] it's in the ticket [22:35:08] eh, topic [22:35:13] it does open a new ticket [22:35:56] you can also mail 1234@rt if 1234 is the ticket number [22:36:02] that's the weirdest process [22:36:03] which would append a comment [22:36:26] it's like many other bugtrackers that are semi-open, f.e. just like zendesk of oit [22:36:48] you mail it and it creates a ticket (and a user in the background) [22:37:52] it's also the reason we move some tickets into other queues, where you cant just guess a ticket number, if there is a need for it [22:39:25] arr, need to check out.. cya later [22:41:55] bye