[03:06:59] New patchset: Krinkle; "Zuul status page: Default to 0 instead of ?" [integration/docroot] (master) - https://gerrit.wikimedia.org/r/58045 [03:13:20] New review: Krinkle; "OMG NEED MOAR DRAMA" [mediawiki/tools/release] (master) - https://gerrit.wikimedia.org/r/58037 [03:13:31] Change merged: Krinkle; [integration/docroot] (master) - https://gerrit.wikimedia.org/r/58045 [03:16:22] New patchset: Krinkle; "Gitignore: Add doc/VisualEditor, update integration/coverage" [integration/docroot] (master) - https://gerrit.wikimedia.org/r/58046 [03:16:35] Change merged: Krinkle; [integration/docroot] (master) - https://gerrit.wikimedia.org/r/58046 [03:17:39] Reedy: You don't happen to know how to fix the gerrit/zuul breakage? [03:18:06] I mean, I'm sure you've noticed the lack of pre-merge, testing, merging and post-merge events. [03:18:27] https://bugzilla.wikimedia.org/show_bug.cgi?id=46917 [03:18:59] Hi Ryan_Lane [03:34:47] Krinkle: howdy. what's up? [03:35:02] Ryan_Lane: Just wondering about the gerrit/zuul breakage [03:35:22] I haven't really been involved in it [03:35:37] it's due to one of the recent upgrades, though [03:35:38] We really need to do something about that, ideally before noon monday. [03:35:55] Because its damaging productivity, obviously [03:36:05] https://bugzilla.wikimedia.org/show_bug.cgi?id=46917 [03:36:07] well, I doubt there's much I can do about it [03:37:15] Chad or Christian need to look into it [03:37:19] it's code related [04:33:39] Ryan_Lane: Who did the upgrade? Is reverting an option? [04:34:00] all mentioned in the email [04:34:02] and no [04:34:56] wait [04:35:05] it's mentioned directly in the bug that you posted in [04:55:11] Ryan_Lane: Ah, I see [04:55:30] Ryan_Lane: So, in that case, unless that gerrit change gets merged upstream, we should merge it in our fork, right ? [04:56:10] I'm not sure how close we are to upstream, even if we wait for upstream to merge it, would we fast-forward our fork or cherry-pick it? If the latter, we can just cherry-pick it now (it wouldn't make a difference) [05:10:21] New patchset: Krinkle; "Minor design corrections: Shorten transition and use @2x pixel ratio logo" [integration/docroot] (master) - https://gerrit.wikimedia.org/r/58048 [05:10:43] Change merged: Krinkle; [integration/docroot] (master) - https://gerrit.wikimedia.org/r/58048 [07:44:15] qchris: morning :-D [07:44:21] qchris: had a short night I guess? :( [07:44:25] Morning hashar [07:44:31] :-) [07:44:57] Coming home fram a trip to Germany I was quite baffled to have such show stoppers in my inbox ;-) [07:45:23] I guess so [07:46:12] I am going to send a new gerrit.war to chad so we do not have to wait to get the change merged upstream [07:46:31] Do you think we could restart zuul to get jenkins back to do work for us? [07:46:50] well whenever stream-events is blocked, it is blocked for good [07:47:00] have to restart Gerrit :-( [07:47:20] if you connect with your own account to Gerrit, you will notice that new connection does not receive any event either :( [07:47:21] I thought I read something about deactivated in Jenkins [07:47:57] !log restarting Zuul for demo purposes :-) [07:48:53] ahh 10 minutes timeout, nice [07:49:22] (So the Jenkin's deactivated "Gerrit Trigger" Plugin is not zuul?) [07:49:34] oh yeah scuse me [07:49:48] so we used a Java plugin that connect to Gerrit known as "Gerrit Trigger plugin" [07:50:09] I have phased out that plugin in favor of Zuul which is a python daemon installed on the jenkins box [07:50:18] Ah. Ok. [07:50:21] it does a ssh to manganese and run "gerrit stream-events" [07:50:31] then it pause() and waits for JSON events [07:50:44] I will update the bug report :-] [07:50:50] i read zuul's gerrit.py but did not know how it's hooked into Jenkins. [07:51:17] So I'll go and ask ops to restart gerrit [08:09:15] New patchset: QChris; "DO NOT SUBMIT" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58059 [08:13:13] New review: QChris; "Recheck" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58059 [08:17:04] New review: QChris; "Recheck" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58059 [08:19:32] New review: QChris; "recheck" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58059 [08:20:15] New review: QChris; "recheck" [integration/zuul-config] (master) C: -1; - https://gerrit.wikimedia.org/r/58059 [08:24:05] New review: QChris; "recheck" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58059 [08:28:51] New review: QChris; "recheck" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58059 [08:31:41] New review: QChris; "recheck" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58059 [08:35:55] New review: QChris; "recheck" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58059 [08:40:08] New review: QChris; "recheck" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58059 [08:47:55] New review: QChris; "recheck" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58059 [08:49:23] New patchset: Zfilipin; "Updated Ruby gems" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/58061 [09:02:50] Change abandoned: QChris; "Pinging gerrit has been moved to separate repository:" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/58059 [10:37:25] New review: Hashar; "oops. Good catch!" [integration/jenkins] (master) - https://gerrit.wikimedia.org/r/57851 [11:26:08] New patchset: Hashar; "Run tests for DataValues" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/57711 [11:28:55] Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/57711 [11:54:38] Can gerrit please be more reliable? It's really, really, really annoying. [11:54:59] ^demon: My 'keep gerrit alive' ping just failed. Are you just upgrading gerrit? [11:55:44] <^demon> Yeah, I was pulling in your patch to disable the timeouts. [11:55:51] Great. [11:57:35] <^demon> Ok, back with 2.6-rc0-154-gfcdb34b [11:57:40] <^demon> Which is your patch cherry picked onto master. [13:31:32] ^demon, I think you said you wouldn't be using patched gerrit versions... [13:43:07] Platonides: that's what he said on the bug too [14:09:58] bah re [14:26:06] Project _debug-browsertests-template build #107: NOW UNSTABLE in 10 min: https://wmf.ci.cloudbees.com/job/_debug-browsertests-template/107/ [15:02:17] New review: Cmcmahon; "use bundle() for parallel tests" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/57836 [15:02:17] Change merged: Cmcmahon; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/57836 [15:06:16] New patchset: Zfilipin; "last scenario check that moved pages are actually OK" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/57644 [15:07:02] New patchset: Zfilipin; "last scenario check that moved pages are actually OK" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/57644 [15:07:35] New review: Zfilipin; "Merged after applying changes from https://gerrit.wikimedia.org/r/#/c/57747/1" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/57644 [15:07:36] Change merged: Zfilipin; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/57644 [15:07:56] Change abandoned: Zfilipin; "Merged at https://gerrit.wikimedia.org/r/#/c/57644/" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/57747 [15:44:06] <^d> Platonides: Generally I'd like to avoid it, but we've got a major regression and I can't wait for upstream to drag their feet. [15:44:24] <^d> There's no schema changes here, so we can easily swap over to whatever ends up going to master. [17:09:10] New patchset: Zfilipin; "Disabled tests that fail in Internet Expolorer" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/58099 [17:10:33] New review: Cmcmahon; "docs update" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/57724 [17:10:33] Change merged: Cmcmahon; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/57724 [17:11:52] New review: Cmcmahon; "hygiene" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/57837 [17:11:52] Change merged: Cmcmahon; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/57837 [17:12:10] New review: Cmcmahon; "maintenance" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/58061 [17:12:10] Change merged: Cmcmahon; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/58061 [17:13:43] New review: Cmcmahon; "disable UW scenario for IE 8 and below until bogus failure is fixed" [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/58099 [17:13:56] New review: Cmcmahon; "disable UW scenario for IE 8 and below until bogus failure is fixed" [qa/browsertests] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/58099 [17:13:57] Change merged: Cmcmahon; [qa/browsertests] (master) - https://gerrit.wikimedia.org/r/58099 [17:57:28] jdlrobson: I put in a new fix for the 'Contact Us' footer link (since just removing it on-wiki was rejected): https://gerrit.wikimedia.org/r/#/c/57649 [18:05:26] When testing the OAI repos with lsearchd on my VM I'm getting 401 errors; what do I need to enable proper authorization ? [18:05:57] Server returned HTTP response code: 401 for URL: http://ua.wikimedia.org/w/index.php?title=Special:OAIRepository&verb=ListRecords&metadataPrefix=mediawiki&from=2001-01-01 [18:12:47] xyzram: It's got it's own auth stuff [18:13:40] xyzram: You've got access to fenari, right? [18:13:55] Reedy: yes [18:14:02] sql aawiki [18:14:05] use oai; [18:14:11] Project _debug-MobileFrontend-template build #5: FAILURE in 4 min 5 sec: https://wmf.ci.cloudbees.com/job/_debug-MobileFrontend-template/5/ [18:14:12] * jrobson: Regression: Stop low res main menu icon from 404ing due to move [18:14:12] * zeljko.filipin: Added option to run mobile frontend tests at en.m.wikipedia.beta.wmflabs.org [18:14:13] * jrobson: Urgent fix: Provide greater expect-ations (fix breaking tests) [18:14:13] * zeljko.filipin: It is useful to sometimes debug problems in Firefox [18:14:14] * maxsem.wiki: Remove disable_zoom now that it's unused [18:14:14] * jrobson: Bug 41519: Only request token when clicking the star [18:14:15] * jrobson: Story 400: Deal with first time user upload [18:14:15] * jrobson: Remove tumbleweed code for WLM banner [18:14:16] * jrobson: Minor QUnit test fixes [18:14:16] * jrobson: Rename jsEnabled class to client-js to be consistent with desktop [18:14:17] * l10n-bot: Localisation updates from http://translatewiki.net. [18:14:17] * jrobson: Go more ResourceLoader native for head scripts and styles [18:14:18] * l10n-bot: Localisation updates from http://translatewiki.net. [18:14:18] * maxsem.wiki: rm unused variables [18:14:19] * jgonera: Add missing dependency [18:14:19] * jrobson: Use embed the correct way, fix Nokia N95s [18:14:20] * arichards: Change diff colors after design input [Alpha] [18:14:31] * jgonera: Don't add more than one photo upload button [18:14:31] * maxsem.wiki: WIP: Avoid SkinMobile-specific functions and properties [18:14:32] select * from oaiuser; [18:14:32] * jrobson: Bring watch star css/html markup closer to desktop [18:14:32] * arichards: Un-skip MobileContextTest::testUpdateDesktopUrlHost [18:14:33] * l10n-bot: Localisation updates from http://translatewiki.net. [18:14:33] * zeljko.filipin: Run parallel_tests with bundle exec [18:14:34] * zeljko.filipin: Escaped all regular expressions [18:14:34] * l10n-bot: Localisation updates from http://translatewiki.net. [18:14:35] * l10n-bot: Localisation updates from http://translatewiki.net. [18:14:35] * zeljko.filipin: Updated Ruby gems [18:14:36] ... [18:15:11] Reedy: https://gerrit.wikimedia.org/r/#/c/58118/1 [18:15:16] xyzram: You can insert yourself a row into that table [18:15:24] the password is just md5 hashed [18:18:36] Yippie, build fixed! [18:18:37] Project _debug-MobileFrontend-template build #6: FIXED in 2 min 50 sec: https://wmf.ci.cloudbees.com/job/_debug-MobileFrontend-template/6/ [18:18:41] AaronSchulz: Why is one of the != 0 outside the brackets, while the other is inside? [18:20:17] heh, it doesn't matter, I guess I can pick one style [18:22:41] Project _debug-MobileFrontend-template build #7: FAILURE in 35 sec: https://wmf.ci.cloudbees.com/job/_debug-MobileFrontend-template/7/ [18:29:14] ^demon: I cannot push to a new gerrit repo without getting a timeout error... any idea how to workaround? [18:29:34] <^demon> Arggghhhh [18:29:44] hehe. yeah. [18:29:58] I have the code on github if it's easier to do a pull [18:30:00] <^demon> I hate mina sshd. [18:30:46] This is definitely a one-time thing... for me ;) sorry it's your life. [18:35:09] <^demon> Prolly related to https://bugzilla.wikimedia.org/show_bug.cgi?id=47004 [18:35:17] <^demon> And more mina 0.6.0 woes. [18:35:29] <^demon> qchris: We're getting reports of timeouts :\ [18:35:45] ^demon: well, I'm pushing a 97M repo [18:35:54] ^demon: I just found another problem with mina sshd ... it's timeouts as well [18:36:04] Harr :-( [18:36:09] <^demon> awight: Well, we shouldn't have any timeouts right now. [18:36:17] nice, i'll try again [18:36:30] <^demon> Shouldn't as in 0 means no timeout. [18:36:39] <^demon> But we're obviously *having* them :) [18:36:42] <^demon> *:( [18:36:48] ^demon: mina sshd timeouts if there is only traffic in one direction :-( [18:36:57] (eventhough timeout is set to 0) [18:37:15] <^demon> Blah. [18:37:29] <^demon> Can we downgrade to 0.5.x, or do we *need* 0.6.x? [18:37:45] No, we do not need 0.6.x [18:37:47] <^demon> I saw upping to 0.7.x creates its own problems. [18:37:53] well no rush, i'm happy to be test monkey if you need [18:38:02] upstream bumped it to 0.6.x to get better maven integration IIRC [18:38:20] <^demon> Meh, I could care less about that. [18:38:31] <^demon> I want a stable build :) [18:38:35] If it's a timeout for push, just push in parts. That should do the trick [18:38:37] ^demon: timed out again [18:39:05] awight: Are you pushing using git or pushing using mina sshd client? [18:39:08] qchris: I was trying to set that up. Unfortunately, you have to push a branch. So I'd have to do bad things to my repo [18:39:16] qchris: "git push gerrit" [18:39:19] Reedy: ok, I see the oaiuser table; md5 hash any old password and add it to that table ? [18:39:36] awight: ok. Timeout is roughly 10 minutes? [18:39:37] Yup, looks to be [18:39:38] array( [18:39:38] 'ou_name' => $username, [18:39:38] 'ou_password_hash' => md5( $password ), [18:39:38] ), [18:39:51] qchris: I think it's about 120 sec [18:40:28] Oh ... that looks like a default timeout... [18:40:29] And fix the Java side to send that md5, right ? [18:43:54] ^demon: the upstream fix is missing a '/1000' [18:44:10] <^demon> Upstream in gerrit, or upstream in mina? [18:44:17] upstream in gerrit [18:44:33] <^demon> Ah, I thought it was in ms, not seconds. [18:44:41] I'll prepare a new war file and send it to you ... but compiling takes ~15mins for me [18:44:52] <^demon> Just push the patch and I can build in like 5. [18:44:57] Yes but mina parses it as int, so it overflows. [18:45:07] Ok. [18:45:25] qchris: I'm squeezing my repo through with "git push gerrit master~200:refs/sandbox/adamw/tmp1" [18:45:26] <^demon> SSD + 16G ram = faster gwt compile stage :) [18:46:07] nasty. Let me know if I can still help test timeout fixes later today, though. [18:49:10] ^demon: Sorry, I misread the direction. Let's increase the idle time through gerrit config [18:49:29] <^demon> Can do that too. [18:49:55] Ok. Choose something <24 days [18:50:03] Otherwise we'll overrun again [18:52:26] <^demon> So, something like 2160000? [18:52:32] <^demon> (25d) [18:53:21] No. Smaller than 24 days [18:54:14] ^demon: like 864000 (10 days) [18:54:24] <^demon> Oh, misread that. [18:58:00] sumanah, http://www.google-melange.com/gsoc/org/google/gsoc2013/wikimedia !!! [18:58:04] hello [18:58:19] * qchris waives at hashar [18:58:20] qgil: :) [18:58:36] sumanah, and our usual silly problems: I guess "Wikimedia" is fine. But what logo? WMF? MediaWiki?> [18:58:48] WMF is what we usually do. [18:58:55] sumanah, ok [18:59:02] That's good because it allows non-MediaWiki projects e.g. OpenStack work [18:59:07] well, "allows" is strong [18:59:28] sumanah, ok [18:59:54] it is more accommodating in the case of non-MediaWiki projects [19:05:07] <^demon> hashar: e46c39d0 git-upload-pack '/mediawiki/core' (jenkins-bot) - why is jenkins fetching stuff rather than doing it from the gallium copy? [19:05:58] ^demon: some jobs do [19:06:06] ^demon: I haven't migrated all of them to use the local copy [19:06:10] <^demon> Ah ok. [19:06:13] <^demon> Just wondering :) [19:06:20] <^demon> Not too bad since we did gc on it. [19:25:17] Does MW using SQLite use a table or index prefix? [19:26:09] MaxSem: ^ [19:28:51] Reedy, table prefix should work however it's pointless with sqlite cause you can create as mny db files as you want [19:28:57] Sure [19:29:30] never really checked though - for that precise reason:) [19:29:56] It's not a big deal, just poking mediawiki-bugzilla stuff [19:30:15] Reedy: so, is https://gerrit.wikimedia.org/r/#/c/58118/ ok? [19:30:30] ^demon: just checked, there are only a few jobs referencing gerrit.wikimedia.org (list at http://dpaste.com/1051476/ ) [19:30:44] ^demon: they are mostly jobs maintained manually. [19:31:10] <^demon> Gotcha. [19:31:14] <^demon> That's fine. [19:32:00] ^demon: I am still wondering why gerrit did not pick a meaningful idle timeout on it's own. It work's perfectly fine, if I compile locally ... the version we are currently running is just some upstream master with the patch applied? [19:32:44] <^demon> Yeah, it was 78515ea29b53ce38aa5afb265ac4648933548da0 with your patch cherry picked. [19:33:22] Ok, thanks. OpenJDK 6? [19:33:35] <^demon> Yeah. [19:33:50] I forgot to connect on IRC this afternoon to talk about the stream-events issue [19:34:00] Hrm. That leaves me puzzled. [19:34:01] but I guess you guys have all the informations needed don't you? [19:34:08] <^demon> hashar: Well, I think we've got a decent workaround in place for now. [19:34:15] hashar: Yes. We sorted it out more or less. [19:34:27] note that whenever `stream-events` is broken for Zuul, it is broken for any new connection as well. [19:34:50] yeah I have noticed the workaround. That buy you some time 8) [19:35:01] <^demon> 10 days ;-) [19:35:11] :-D [19:36:51] awight: Did you manage to push your repo? If not, ^demon increased the idle time, so you could try again. [19:38:54] and I am hopeless on that :( [19:38:56] err [19:38:58] helpless [19:43:52] <^demon> hashar: I'll be explaining everything in our meeting in roughly an hour. [19:47:30] awight: apparently one of your change to CentralNotice might have an issue. http://en.wikipedia.beta.wmflabs.org/wiki/Special:SpecialPages shows a stacktrace. bug is https://bugzilla.wikimedia.org/show_bug.cgi?id=47015 [19:53:57] ^demon: https://gerrit.wikimedia.org/r/#/c/58118/ [19:57:04] <^demon> qchris: Um, I wasn't on openjdk-6. I used the wrong java install. [19:57:15] <^demon> http://p.defau.lt/?uh5Ed62ro42UBM6F2_ILEQ [19:57:49] <^demon> Sorry. [19:58:08] Ok. I'll try to reproduce with that jdk. Let's see if the problem show up with it :-) [19:58:12] Thanks [19:59:49] <^demon> It hasn't so fast. [19:59:59] <^demon> The timeout + your patch seems to be fine so far. [20:13:58] Project browsertests-linux-firefox build #251: UNSTABLE in 12 min: https://wmf.ci.cloudbees.com/job/browsertests-linux-firefox/251/ [20:13:59] * zeljko.filipin: Updated readme file [20:13:59] * zeljko.filipin: Run parallel_tests with bundle exec [20:14:00] * zeljko.filipin: Escaped all regular expressions [20:14:00] * zeljko.filipin: Updated Ruby gems [20:14:01] * gerrit: last scenario check that moved pages are actually OK [20:14:01] * zeljko.filipin: Disabled tests that fail in Internet Expolorer [20:14:20] Reedy: I was wondering why git pull showed so much on fenari...then I realized I was in 1.21wmf1 [20:14:29] jdlrobson: did you see my message about the footer link? [20:15:31] Project browsertests-linux-chrome build #268: UNSTABLE in 14 min: https://wmf.ci.cloudbees.com/job/browsertests-linux-chrome/268/ [20:15:32] * zeljko.filipin: Updated readme file [20:15:32] * zeljko.filipin: Run parallel_tests with bundle exec [20:15:32] * zeljko.filipin: Escaped all regular expressions [20:15:33] * zeljko.filipin: Updated Ruby gems [20:15:33] * gerrit: last scenario check that moved pages are actually OK [20:15:34] * zeljko.filipin: Disabled tests that fail in Internet Expolorer [20:17:44] tfinc: you seen Jon? [20:24:33] hey kaldari [20:24:37] howdy [20:24:54] I have a small review to poke you about [20:25:00] https://gerrit.wikimedia.org/r/#/c/57649/ [20:25:52] yeh saw this. Let me check the bug i'm not familiar with the proble [20:26:40] so kaldari a little confused.. what's broken (i currently see a contact us link..) [20:26:51] ah to remove the hack [20:26:54] yep [20:27:22] this is the (hopefully) final solution to your complaint on the talk page [20:28:31] <^demon> qchris: So, what do you think is the ideal solution to the timeout problem? [20:28:44] <^demon> Keep the timeout high, or make stream-events not go idle? [20:29:12] The ideal solution will be to upgrade mina sshd to 0.9.0-SNAPSHOT. I found more problems there :-( [20:29:33] Then we can have a timeout of 0 again [20:29:36] kaldari: suchhh an old discussion of mine :D [20:29:51] kaldari: doesn't seem to work for me.. i'm still seeing 4 links in footer [20:30:09] Reedy: mediawiki-config has jenkins right? [20:30:18] <^demon> qchris: Timeout of 0 for just stream events? [20:30:39] jdlrobson: you put it in your LocalSettings and removed the db check? Might have to clear some caches as well [20:30:40] For all connections, as provious gerrit versions had [20:30:55] kaldari: yehhhh [20:30:56] mm [20:31:04] <^demon> qchris: Gotcha. [20:31:04] ^demon: Would you prefer timeout >0 for interactive users? [20:31:17] jdlrobson: Oh yeah... [20:31:31] you have to have the local messages in your local-wiki for it to work [20:31:48] MediaWiki:contact and MediaWiki:contact-url I think [20:31:56] they already exist on en.wiki [20:32:02] otherwise nothing is displayed [20:32:06] <^demon> qchris: Well, for interactive it makes to have at least *some* timeout, but should be high enough to keep people from being interrupted. [20:33:09] ^demon: I see. [20:33:56] <^demon> Anyway, non-broken behavior is the best plan :) [20:34:02] <^demon> Whatever timeout we end up setting. [20:34:20] kaldari: how do i set the message? [20:34:24] :-)) [20:35:20] jdlrobson: go to "MediaWiki:Contact" in your local wiki and create the page with the content "Contact us" [20:35:44] then go to MediaWiki:Contact-url and create the page with a random URL [20:36:09] qchris: no, it's still timing out. Actually, it's very strange because I've pushed all the references in small batches, now it's timing out on zero objects! [20:36:34] awight: again after ~2 minutes? [20:36:38] kaldari: o_O [20:36:44] "git push gerrit master:refs/sandbox/adamw/tmp1" but when i push master:master, it dies [20:36:54] qchris: yeah i think it's still 2 minutes. lemme time it [20:37:25] If it's roughly 2 minutes it's ok (so I know how long I have to wait when trying to reproduce) [20:37:40] awight: No need for exact timing. [20:38:02] sure. Yeah I don't know what to say about the master:master fail. [20:38:20] It's the "remote: Processing changes:" step which has been timing out [20:39:07] qchris: yep, 2 minutes [20:39:17] awight: Could you upload the logs or console output somewhere? [20:40:55] e.g.: http://p.defau.lt/new.html [20:41:24] qchris: http://pastie.org/7375741 [20:41:32] awight: Thanks [20:43:44] awight: Is this the output for the timeout? [20:44:04] awight: Looks like "internal error" [20:45:40] yes... [20:45:52] comes from remote, though [20:46:22] <^demon> I've got nothing in the error_log for that repo. [20:46:26] But it looks unrelated to our timeout problems. :-) [20:46:43] supposedly origin/master is already in sync with local master, compounding the mystery. [20:46:51] The repo is still empty for me. [20:47:02] Maybe I corrupted the state when the push timed out? [20:47:38] Is origin == gerrit? Or did you clone from somewhere else? [20:47:51] (Corruption should not happen too easily) [20:48:25] Your log hints that your 'gerrit' is the name of the remote (not origin) [20:49:37] awight: When I clone from the repo url, and run 'git remote -v' I get the following output: [20:49:39] http://p.defau.lt/?ta1dRT3b9j9iIFbbvnd6dw [20:51:48] awight: How did you get the repository on your machine? [20:53:32] Krinkle: I had to revert some javascript change that has been force merged and broke JSDuck :( [20:53:32] Project en.m.wikipedia.org-MobileFrontend-linux-firefox build #1: UNSTABLE in 4 min 13 sec: https://wmf.ci.cloudbees.com/job/en.m.wikipedia.org-MobileFrontend-linux-firefox/1/ [20:53:52] Krinkle: bug is https://bugzilla.wikimedia.org/47018 [20:54:04] qchris: If you don't have a gerrit remote, run git review -s [20:54:13] (Runs the git review setup steps) [20:54:17] Krinkle: revert was https://gerrit.wikimedia.org/r/#/c/58131/ and Roan fixed it (hopefully) with https://gerrit.wikimedia.org/r/#/c/58134/ [20:57:22] RoanKattouw: Thanks. I misread what awight wanted to do :-) [20:59:16] qchris: yeah, what Roan said. But, I started with a repo which I'd created on my local machine (using "commit --allow-empty"), unrelated to the current gerrit repo. Then "git remote add origin https://gerrit.mw..." and finally, git review -s [21:04:22] hashar: Yeah, I read the bug report already with the links. [21:04:29] hashar: new zuul portal :) [21:04:46] Krinkle: yeah noticed that. Kudos :] [21:05:02] Krinkle: I guess jeblair in #openstack-infra will be interested. [21:06:12] Hm.. I so I guess I'll say: We ripped off your status page and then pimped it up? The design was pretty good already (though not suitable for us because it is openstack portal style, not bootstrap or wmf), but the js code was bad. [21:06:12] Krinkle: I love how you used background colors on job status, makes it easier to see. [21:07:04] Anyway, no point in making accusations, it wasn't ours to deal with. [21:07:09] I'll let him know. [21:07:26] Krinkle: or you could say: Hello I am the JavaScript guru @ wikimedia, I have slightly improved your JS hack for Zuul, here is the improvement :-] [21:07:45] code is in ssh://review.openstack.org:29418/openstack-infra/config.git ./modules/openstack_project/files/zuul/status.js [21:07:48] jeblair? Where Have I heard that before [21:07:50] (and ./modules/openstack_project/files/zuul/status.html ) [21:08:20] he is the maintainer of Zuul :] [21:08:32] No, that's not it. I've seen that name elsewhere. [21:15:16] awight: Sorry. [21:15:47] awight: You need to rebase your commits on the remote master [21:15:55] no problem. [21:15:57] greg-g: robla: we have lost SF [21:16:11] hashar: the big quake arrived? [21:16:12] qchris: although, the process i used worked fine for the other repos [21:16:20] Nemo_bis: I hope not :-] [21:16:21] awight: Your initial "empty commit" does not match the remotes initial empty commit [21:16:30] Nemo_bis: just the conf call (for now) [21:16:32] I merged in the "empty" and things are fine locally... [21:16:46] awight: Did you also get an "initial empty commit" in gerrit for them? [21:16:49] Nemo_bis: they are safe :-] [21:17:08] hashar: yay [21:17:14] qchris: yeah, merged that into my own and things are cool. apparently the --allow-empty facilitates that [21:18:15] awight: :-) yous that works locally, but gerrit denies such merge commits if you do not have special permissions [21:18:21] hehe [21:18:48] * awight aims at the cardboard box holding gerrit up :p [21:18:54] awight: To properly rebase, you can use something like [21:19:02] git rebase --onto remotes/gerrit/master 9add9032fb063ddb1b1c031b269c80cf73dbab6b 11ff45c604d84a8685b92bca63962ed44514a124 [21:19:08] got it, thanks! [21:19:21] awaight (assuming remotes/gerrit/master is what you fetched from gerrit) [21:19:54] awight: then you can push the head to gerrit and you should be done. [21:33:41] <^demon> RoanKattouw: Grrrr. [21:33:45] <^demon> https://gerrit.wikimedia.org/r/#/c/58221/ [21:34:08] hashar: So how did we fix zuul? Or did we just do another restart that'll make it fail the next 10 minute gap? [21:34:22] https://bugzilla.wikimedia.org/show_bug.cgi?id=46917 [21:34:29] <^demon> We upped the timeout. [21:34:36] Ah, the patch was merged in our fork. [21:34:37] great [21:34:38] <^demon> Since max timeouts are broken in mina sshd. [21:34:42] yeah [21:34:47] Krinkle: yeah the issue is on Gerrit side [21:34:57] <^demon> Stupid mina. [21:34:58] somehow when the ssh timeout is raised, stream-events is broken even for new connections [21:35:19] also the ssh timeout message should probably be a JSON message :-] [21:35:57] <^demon> Krinkle: Actually we lowered the timeout, since the upper timeout would overflow ;-) [21:36:11] <^demon> But upped it from the hardcoded default it was falling back to on failure. [21:36:32] <^demon> 10d should suffice to find a better solution. [21:40:12] Arrrgh [21:40:18] git-review unfixed the "git fetch gerrit" thing [21:40:47] qchris: jfyi I still got a timeout, but I eventually succeeded in sending batches of c. 100 patchsets. [21:41:38] * qchris bangs his head against the table [21:41:46] New patchset: Krinkle; "Zuul status page: Add space before changeid." [integration/docroot] (master) - https://gerrit.wikimedia.org/r/58224 [21:41:47] awight: still timeouts? [21:42:04] awight: Do you have logs / console output? [21:42:10] Change merged: Krinkle; [integration/docroot] (master) - https://gerrit.wikimedia.org/r/58224 [21:43:12] qchris: http://pastie.org/7376506 [21:44:13] awight: thanks [21:55:23] ^demon: Given awights error messages, I guess it was unfortunate timing, that his problems occurred on the day that we were fighting mina sshd timeouts [21:55:32] ^demon: It seems the problem there was [21:55:36] https://gerrit.wikimedia.org/r/Documentation/config-gerrit.html#receive.timeout [21:55:43] ^demon: and not mina sshd. [21:55:51] <^demon> Hmm. [21:56:03] Should we increase that timeout? [21:56:33] (The timeout nicely fits the error messages, and also the 2minutes period match) [21:56:38] <^demon> Yeah. I don't wanna put it too high, since someone could try to upload a ton of junk data. [21:57:10] Yes, that's obviously true. [21:57:28] But when importing a repo, it can be a problem as we saw today :-( [22:01:21] <^demon> Indeed. [22:04:42] hashar: What do you expect it will take to get doxygen 1.8? [22:05:36] hashar: Ubuntu setting it on 1.7 and 1.8 on wheezy is probably just default procedure (minimal amount of a time for an upgrade to be in a channel before it is promoted), seems arbitrary when compared to the actual changelog. [22:05:51] It isn't something we should live by to the extreme. Good for packages where we don't care the version of. [22:06:00] BUt in this case we do. [22:06:31] hashar: Do you know if it has been done before? (promoting a package from wheezy to squeeze in our repo only?) [22:06:55] (or whatever the procedure is for getting that package) [22:08:27] ^demon: did you update 1.21wmf12? [22:08:34] for core [22:08:42] <^demon> 1.21wmf12 already had master of MWSearch [22:08:45] otherwise there won't be the PC callback class so it won't do anything for those wikis [22:08:50] <^demon> Oh, that. [22:08:51] <^demon> Whoops. [22:09:06] luckily you have the extension b/c so the site is not broken now [22:09:07] <^demon> On it [22:12:56] <^demon> AaronSchulz: Done. Thanks for reminding. [22:13:02] <^demon> I totally forgot that bit. [22:31:07] Krinkle: oxygen could be back ported. I am not going to handle that though :-] [22:31:34] Krinkle: takes too much time to backport a package. Just try out in a labs instance having Doxygen 1.7.x and see if it looks fine :-) [22:31:48] I know it won't [22:31:53] Krinkle: you could even run Doxygen from gallium [22:32:12] I can't understand why you would ask me that given that I said on the gerrit change I'm fixing bugs that couldn't be fixed before. [22:32:18] ? [22:32:22] potentially we might be able to build our own package http://packages.ubuntu.com/search?keywords=doxygen [22:32:28] run doxygen from gallium is what we do. [22:32:36] yeah and it has 1.7.3 [22:32:44] you updated the doxyfile for 1.8.x [22:32:47] I know [22:32:48] which might cause troubles. [22:32:51] I know [22:32:53] I am merely warning about it [22:32:55] Did you read what I wrote [22:33:04] I replied on gerrit [22:33:13] if you test your patch using Doxygen 1.7 and that works, then it works for me :-] [22:33:22] hashar: doxygen 1.8 is already packaged by ubuntu in wheezy. [22:33:22] I am just playing the paranoid due ;D [22:33:44] anyway bed time, sorry [22:33:57] As I said for almost 10 times now, testing with doxygen 1.7 futile as I said I am using 1.8 features. [22:34:14] and there is no 1.7 way to do what I'm doing because they are things that 1.8 fixes. [22:34:21] so we can't get your change in unless we upgrade Doxygen on gallium. [22:34:22] 1.7 is basically broken, always has been. [22:34:41] Yes, that's what I said: "Wait for upgrade to 1.8 in production" [22:34:44] on gerrit. [22:35:09] haven't read that yet :-] [22:35:11] will reply tomorrow [22:35:12] hashar: Define "backport" package. The package is already on debian, just in a different channel. Is it hard to import that into our channel? [22:35:16] too late, need to sleep now sorry [22:35:22] k [22:35:37]