[00:03] gary_poster: testrepository is up [00:07] Huh [00:07] Native postgres synchronous replication can be opt-in at the transaction level. Didn't realise that. [00:10] wgrant: as in 'how much risk to take' ? [00:13] lifeless: Yeah. You can say that a particular commit should or should not wait for replicas. [00:13] I assumed it was all-or-nothing. [01:15] wgrant: O HAI, Mr. OCR [01:19] wgrant: https://code.launchpad.net/~stevenk/launchpad/information_type-notification-flag/+merge/105014 [01:26] StevenK: I don't appreciate your lies. === wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: wgrant | Firefighting: - | Critical bugs: 3.47*10^2 [01:27] Which lie in particular? [01:28] The one about me being OCR === mpt_ is now known as mpt [02:47] * wallyworld_ sighs. 18 minutes and still no mp diff [03:37] wallyworld_: what happened to using rabbitmq for that? [03:38] nigelb: ? [03:38] for what? [03:38] wasn't there something to use it for diff generation? [03:39] yes. the branch first needs to be scanned [03:39] and that job is timing out [03:40] there's something in the branch it doesn't like [03:40] ah. [06:01] wgrant: I had a test failure, so I've made sure the notifications respect the flag no matter the setting of the UI flag: http://pastebin.ubuntu.com/975101/ [06:19] StevenK: LGTM === jtv1 is now known as jtv === jtv1 is now known as jtv === almaisan-away is now known as al-maisan [07:55] good morning === al-maisan is now known as almaisan-away [10:49] benji: I don't mean to seem ungrateful for your fantastic reviews, but would you mind having one more look at this one? I made some changes that didn't quite make sense as a separate branch. https://code.launchpad.net/~jtv/launchpad/bug-994650-scrub-pofiletranslator/+merge/104866 [10:50] (Look for “Late-breaking change:”) [10:50] jtv: Why experimental loop? [10:51] StevenK: isn't that appropriate? [10:51] I still need to test it on staging. [10:51] jtv: If you're not going to land it until you've tested it on staging, then I would recommend you add it to the 'normal' loop. [10:52] Oh. OK. [10:52] If you're still worried, you can control execution with a feature flag. [10:52] (Have we passed bug 1 million yet?) [10:52] <_mup_> Bug #1: Microsoft has a majority market share The workitems tunable loop does that. [10:52] No mup, not what I meant. [10:52] bug 1000000 [10:52] Yeah, I added feature flag support a few months back, so it's probably easier now to use that than --experimental [10:53] Because if it isn't broken, you would need a subsequent landing and $LOTSOF hours to get it working on prod. [10:53] With a feature flag you just set the feature flag. [10:53] Well I don't think there's too much point to landing this unless I know the garbo job can do a decent job first anyway… [10:53] Then shift it and get the webops to run garbo-daily with -vv goodness [10:54] Shift? [10:55] jtv: Sorry. What I mean is move it from experimental, and then have the webops run garbo-daily by hand with -vv. [10:55] webops, would you be available to try that now? [10:55] (I've already pushed the branch) [10:56] jtv, sure [10:56] Let me check that I've really pushed it to all the right branches... [10:57] gnuoy: I guess the change where POFileTranslator.latest_message is allowed to be null is still in place? [10:57] it is [10:57] Great. Then if you would, please merge lp:~jtv/launchpad/combined-async-pofiletranslator and run garbo-daily with -vv! [10:57] wgrant: you EOD? updating OCR === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: rick_h | Firefighting: - | Critical bugs: 3.47*10^2 [11:02] rick_h_: Ah, yeah, a few hours ago, sorry. [11:02] wgrant: np, just didn't want to delete you unnecessarily [11:17] jml: Hi, are you around? [11:20] jml: Your QA is now blocking everything, and achuni seems perfectly aligned to avoid my timezone. [11:25] jml: If I hear nothing by my morning I'll revert both -- I guess retrying after UDS would work better. [11:32] jtv: if you could still use a review, I can do it here in a bit [11:33] benji: wonderful, thanks. I'd feel more confident. The actual code is the same, but it's all moved, mostly towards the left-hand margin. Methods are now functions. [11:37] jtv: cool, I'll look at it in the next half hour or so [11:37] Thanks. I won't be here for too much longer, unfortunately, but I may be able to check back in later. [11:38] wgrant: achuni was trying to find someone at UDS to ask about that. [11:39] jcsackett: morning, around for ? [11:39] wgrant: afaik, we're ready to QA it, it's just that the QA person was in London (public holiday yesterday) [11:40] wgrant: I'll chase it up now. When you say both, what's the other branch? (I'm only aware of jml's one branch?) [11:46] noodles775: Ah, forgot about the public holiday. [11:46] wgrant: yeah, so did I when I did the developer QA and handed over. [11:46] noodles775: jml has a second branch which doesn't have special QA requirements, but it renames Archive.commercial [11:47] So a straight revert of the first branch won't work, as code it removes relies on .commercial [11:47] wgrant: can you point me at the second branch so I can make sure it was on staging.lp.net when I QA'd the first one? Thanks! [11:48] http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/15209 [11:48] db-devel r11573 [11:49] wgrant: excellent, that's what staging was running when I QAd. [11:49] noodles775: (sorry, wasn't aware you were a SCA QA victim these days, or I would have pinged you directly) [11:49] Great. [11:54] wgrant: no problem - I just wanted to make sure our QA person would be able to do their QA straight away. I should have put my notes on the bug rather than email, just added them now. [12:03] noodles775: Thanks, those emails clarify everything. [12:10] wgrant: np [12:49] abentley: hi. what do i need to do to have celery run correctly for lp.dev? i have code where tests using CeleryLayer work but I want lp.dev to run the jobs also. i have added the jobs to jobs.celery.enabled_classes [12:51] wallyworld: You would run bin/celeryd --config lp.services.job.celeryconfig [12:51] abentley: ah, i ran celeryd but didn;t know the correct config arg. thanks [12:52] abentley: should we make that part of make run now? [12:52] wallyworld: no, we're still working on getting it ready for production use. [12:53] abentley: ok. np. i have a new job which remove subscriptions for inaccessible bugs and branches which is celery only. when do we think lp.net will support that? [12:54] wallyworld: I hope we can do it this week. [12:54] \o/ sounds good. thanks [12:57] abentley: It's in use and working on qas/staging? [12:58] StevenK: btw memtest86+ ran a few passes and no errors. but still lots of crashes :-( bollocks and all that [12:58] StevenK: We're using it to do branch scans on staging only, and because fast lane/slow lane is only partially implemented, I cannot recommend using that setup in production. [13:00] wallyworld: Hmmm. [13:01] yeah :-( [13:01] very frustrating [13:01] the only change i can se is adding the new memory [13:02] might have to revert to the old to see if things improve [13:03] Morning, everyone. [13:04] deryck: Morning. [13:04] wallyworld: Try folding@home to see if that dies horribly? [13:05] StevenK: what do you mean? [13:06] wallyworld: folding@home is an application you can run to do protein folding for the project. Extremly CPU intensive. [13:06] wallyworld: It's not packaged, but they have Linux binaries for download [13:08] StevenK: ok. i will look at that. right now, i am writing some code and it's not too bad so will not look a gift horse in the mouth. will do as much as i can while the sun shines [13:08] Heh [13:08] wallyworld: Sounds better than what I'm doing. [13:08] what you doing? [13:10] wallyworld: Installing Windows. [13:10] StevenK: WTF? hahahahahaha. why? [13:10] galaxy s2? [13:10] wallyworld: Steam [13:11] StevenK: can't wait for the linux port? :-P [13:12] wallyworld: Well, the Linux port is only likely to bring Source games. [13:12] At least in the short term. [13:12] yeah i know, just trolling [13:12] rick_h_: around now. [13:13] wallyworld: It's better than what I heard before which was Valve going "Linux? HTF do you spell that?" [13:13] lol [13:14] jcsackett: ok, I did your review, wasn't sure on a couple of points so tried to note my assumptions, have 10min to do a call if you need now [13:15] jcsackett: or if you need to chat we can do so after out stand up [13:15] rick_h_: ping me after your standup, i'm reading your comments now. [13:15] jcsackett: ok, will do === matsubara-afk is now known as matsubara [14:24] jcsackett: ping [14:25] rick_h_: pong. [14:25] jcsackett: howdy, quick hangout? [14:25] rick_h_: yup. lemme go grab some coffee real quick and i'll be on g+ in a minute. [14:26] k [14:49] jcsackett: just one heads up on the visible thing, you need to rely on that css class, but you have to implement it http://yuilibrary.com/yui/docs/widget/#attributes see the 'visible' notes there [14:49] jcsackett: you can see we implemented it in the indicator-core.css file === cjwatson_ is now known as cjwatson === matsubara is now known as matsubara-lunch === salgado is now known as salgado-lunch [17:15] rick_h_: one for your list-o-reviews: https://code.launchpad.net/~benji/launchpad/bug-994694/+merge/105090 [17:17] benji: k, on call will grab it shortly [17:17] rick_h_: perfect === matsubara-lunch is now known as matsubara [17:30] benji: r=me [17:33] czajkowski: Where y'at? [17:34] rick_h_, I award you a gold star ★ for demolishing doc/bugtask.txt [17:34] gmb: ballroom G [17:35] rick_h_: Also, if what sinzui just said is true, I owe you beer. [17:37] My cat is bring me her toy so that I can throw it. I have never had a cat that behaves like a dog [17:41] sinzui: strange thins happen with you :) [17:43] gmb: huh? [17:43] rick_h_, I have a long-running hate-hate relationship with doc/bugtask.txt [17:43] sinzui: oh, well it's not done yet...deryck is making sure I didn't fubar it yet [17:44] gmb: no freaking kidding...thank the LoC policy for making me do it to submit my bugfix [17:44] and deryck for being awesome and accepting the abnormal giant pita review for me [17:48] rick_h_, I doubt that, though there is a small chance that the new tests duplicate the tests in lib/lp/bugs/model/tests/test_bugtask.py [17:48] sinzui: there is no bugtask, that's why they were in bugtaskset. I couldn't find a clean line to split bugtaskset/bugtask very well [17:48] well I didn't think there was one, I shouldn't make blanket statments [17:49] oh yea...so there is stuff there :/ [17:50] crap, totally missed that because the files aren't test_XXX when I did my searches [17:50] *sigh* [17:50] I think there is overlap with conjoined bugtasks. I see your tests and the existing tests both check that attributes are synced for example [17:51] cool. [17:52] ...and window manager fail. [17:52] doh?! [17:52] jcsackett: awesome not liking you? [17:52] rick_h_: awesome and focus-follows-mouse playing together poorly. [17:52] hmm, focus follows my mouse, is that a special setting? [17:53] rick_h_, I totally missed the whole module. for a year! [17:53] rick_h_: no, no special setting. awesome is supposed to do focus-follows-mouse automatically. and now it's not. [17:54] and i don't know why. :-p [17:54] ugh, sucky. wfm but that won't help [17:54] rick_h_: contemplating hopping back to the dark side and going with xmonad. [17:54] yea, buddy moved there and is happy [17:55] if awesome breaks for me that's where I'm heading nexet === salgado-lunch is now known as salgado === Ursinha` is now known as Ursinha === Ursinha is now known as Guest66718 === Guest66718 is now known as Ursula === Ursula is now known as Ursinha [18:26] gary_poster: hi there, any news on the testtools/subunit/testrepository releases goodness? [18:26] lifeless, well, progress: [18:29] I have copied over the testing cabals packages over to yellow's ppa (since that's what we currently use for buildbot integration). I established locally that the Python 3 build issue still stands, but I think you already knew that. I am trying to gather some information to file two weird bugs (one of which might have a chance of being fixed by those three packages) and then I was planning on taking today's buildbo [18:29] t master down and installing the new packages and giving them a spin there. So, I should have something for you be my EoD [18:29] ok cool [18:29] jelmer: hi thar [18:30] jelmer: did you see my ping about the python3 issue gary_poster refers to above, above ? [18:33] Laney: lib/lp/bugs/browser/tests/test_bugtask.py [18:34] allenap: hey, did you still want to talk? I didn't see the threatened email :) [18:37] cjohnston: aloha [18:37] howdy [18:38] StevenK: you about ? [18:48] Could I have a DB patch number for bug 990219? The substantive change is "ALTER TABLE Packageset ADD COLUMN score INTEGER DEFAULT 0 NOT NULL;" [18:48] <_mup_> Bug #990219: Reprioritize package build scores based on packageset

< https://launchpad.net/bugs/990219 > [18:49] let me just check the size of the table [18:49] Wow, shiny extra text on bug status changes [18:50] isnt it though cjwatson [18:50] takes up my whole screen almost [18:51] lifeless: I think it's fairly tiny [18:52] 2209-18-0 [18:52] Thanks [18:52] cjwatson: it is, but anything with a default has to be special cased. [18:52] because its a table rewrite to apply it. [18:53] Right, I guessed [18:53] It'll be fast enough? [18:53] yeah [18:53] 150 rows [18:53] doubt you could measure the difference [18:53] its likely a single page :) [18:58] lifeless, I have a mildly interesting subunit story for you. Briefly, the subunit stream in buildbot stopped processing tests in one run after about 3000 tests. After investigation, it turns out that processing stopped right before this test: http://pastebin.ubuntu.com/976408/ . Clearly this is a problem in the stream: the "No handlers...\n" log message polluted the line and subunit did not recover. A question f [18:58] or me (and you if you want) is whether we can get those log messages out of the stream. A question more squarely for you is if subunit could be more robust in the face of this kind of mess. We're in heuristic land, but AIUI subunit already has a bit of mess-cleaning code in it already. Thoughts? [18:58] That was brief for an email, but not so brief for IRC. :-) oh well [18:58] :P [18:59] so, this is a recurring problem [18:59] it is for us, but rare [18:59] this is #2 in all of my runs [18:59] subunit users encounter it from time to time [18:59] uhm [18:59] I'll skip the backstory for now [18:59] :-) k [19:00] the short answer is: either stop things spewing to stdout at random times (e.g. during __del__ handlers triggered during full gc mid-stream-command-output) [19:00] or move the stream to write to !stdout [19:00] or move sys.stdout to !stdout [19:00] right [19:01] I don't think you can reliably resync the stream; I haven't tried very hard to do so though [19:01] moving the steam to !stdout seems the easiest to make robust [19:01] though still not trivial [19:01] moving the stream to !stdout has the downside that 'test.py | subunit-thing' becomes harder to construct [19:01] right [19:02] moving sys.stdout to be e.g. stderr will preserve messages sent to it, keep the pipe construction easy, and should be robust - few if any modules will take a reference to sys.stdout implicitly [19:02] yeah, I was thinking along those lines [19:02] so bin/test --subunit could do the switch [19:03] and we'd only ( :-/ ) have to mess with our zope.testing fork [19:03] shouldn't need to mess with z.testing for this [19:03] well, maybe [19:03] no? [19:03] I forget where the exact bits are buried. [19:04] the subunit flag is processed there I think [19:04] if we have to, we should let the pipe to write to be customised in the API, so that we don't have to fiddle again later. [19:04] erm [19:04] pipe to write to isn't hte thing being customised. [19:04] I claim 0704. [19:04] heh [19:05] so yeah, we probably want to add an option or something though, rather than just changing the behaviour fullstop. [19:05] You don't think that --subunit itself is enough of a flag? if it isn't, then this would be a ./bin/test --subunit --do-not-make-the-subunit-stream-broken [19:06] gary_poster: the No handlers...\n thing is probably due to an object with a __del__ method calling into logging [19:06] makes sense, but I'd really rather not have to have the squad find all possible cases of this [19:06] I'm with you there [19:06] I'm suggesting an API option, ./test.py does command line processing already [19:07] API where? [19:07] one sec [19:07] np [19:09] lib/lp/services/testing/parallel.py uses subunit.run directly [19:09] but I think we can delete that module entirely now [19:09] digging [19:10] rick_h_: ping [19:10] gary_poster: I guess on testrunner.run [19:11] gary_poster: the zope.testing API is one I find a bit hard to reason about [19:11] gary_poster: (zope.testing.testrunner.run) [19:12] lifeless, ok cool. So...we still expose this through a command line though. Do you agree that the commandline --subunit flag will automatically switch to stdout to stderr? [19:12] gary_poster: ultimately, its up to you whether its unconditional or an optional [19:12] ok [19:12] lifeless: I'm about to send that email. I was lacking wind-in-sails last week. I can't stay around here long enough to have a discussion, but hopefully later in the week. [19:12] * gary_poster hopes that the change won't cause too many nasty bugs [19:13] gary_poster: what I was mainly thinking was that being able to switch this behaviour off easily would be a good thing for e.g. dealing with a module that does silly buggers with sys.stdout [19:13] in test runs [19:13] where 'easily' could mean 'edit bin/test' [19:13] ah ok [19:13] or it could mean 'set an env variable' [19:13] or 'pass an option' [19:13] oh, I was with you then not with you :-P [19:13] allenap: ok [19:13] if I had a silly sys.stdout test... [19:14] one that breaks if sys.stdout==sys.stderr, for instance. [19:14] right [19:14] you'd want to be able to switch things around to find out whats going on [19:14] then I would still need that test to pass within a fill test run [19:14] without editing the contents of an egg [19:14] full [19:14] sure, this may be a YAGNI [19:14] * lifeless is happy to wear the paranoid hat [19:15] gary_poster: which is why I say its up to you :) - just trying to articulate the reasons I was proposing it be an option [19:15] ok, so a full implementation of that direction, combined with my belief that --subunit should default to the "non-intermittently-broken" version, would yield... [19:15] tl;dr - an API with side effects that might be a problem is easier to poke at and play with if the side effects are controllable [19:16] --subunit makes stdout ==stderr [19:16] gmb, hey :) [19:17] --disable-stdout-switch disables that (I don't like negative flags usually either, but sometimes incilinations fight), and [19:17] gmb, I'm looking at the bugactivity interface, and I see it references a bug using a BugField. Do I need to create a BlueprintField as well? What is that for? [19:17] the ability to temporarily turn off the stderr/stdout switch for a single test? So that tests can be allowed to be silly? Of course, every test that does this allows another chink in the armor [19:18] I wouldn't bother with one-test support [19:18] the log messages might slip in at that time [19:18] yeah [19:18] the way I see the switch being used would be: [19:18] someone has a problem [19:18] you just have to fix the test [19:18] they are told 'toggle this and try the test' [19:18] if that works, they dig in to fix the test [19:18] +1 [19:18] if it doesn't, we know its something else. [19:18] OK, cool thanks lifeless. I'll go back to filing bugs. :-) [19:18] anytime [19:32] is the blueprint name an unique field? like a bug number? [19:33] Ursinha: I don't believe so [19:34] I believe you can have the same name on different projects [19:34] but I'm not 100% [19:35] sinzui: \o/ [19:36] cjohnston, yes, you can have that in different projects, just checked on staging... [19:36] cjohnston, thanks :) [19:37] Ursinha: we had issues with Summit with same named BPs, that's why we require the cycle letter to be in BPs [19:37] cjohnston, makes sense [21:04] gmb: ping === wilx_ is now known as wilx [21:37] Given an SPPH, how do I get to a page like https://launchpad.net/ubuntu/+source/geg/1.0.2-6build1 (what are these called?) in a unit test? [21:38] an object whose canonical_url is that I suppose I mean === salgado is now known as salgado-afk [21:40] That should do it [21:40] its an SSPH [21:40] bah [21:40] SPPH [21:41] lifeless: thought so, but "ComponentLookupError: (( …" [21:42] should this work? I'm using create_initialized_view here [21:42] IIRC you need a layer/site there [21:43] hrm [22:01] cjwatson: do you want me to listen in on the archive-admin session ? [22:02] cjohnston: gmb is doing headshots so may not be on irc [22:02] cjohnston: better to drop him a mail [22:03] Laney, lifeless: That's a DSPR [22:04] Not an SPPHJ [22:04] Bah, SPPH [22:04] SPPHs don't exist in the traversal hierarchy [22:05] sinzui: my laptop died totally last night. i'm on one of the kid's but mumble is refusing to play nicely as it does at times [22:06] wallyworld_, hangout? [22:06] I will take that answer as no [22:06] sinzui: we can try. i have never logged into google+ before [22:07] noodles775, jml: I see no QA, and no news in 8 hours. I'll revert and we can retry in a less awkward week. [22:07] wallyworld__, then I can assume you do not have the google app on your phone [22:07] sinzui: i have a dumb phone [22:07] it makes phone calls [22:07] and nothing else [22:07] wallyworld__: What's mumble not doing? [22:08] I haven't had a single problem with it in >6months [22:08] wgrant: i starts, says it connects, and then consumes 100% cpu [22:09] wgrant: so how can I get at that? [22:09] wallyworld__, maybe it is killing the sound server [22:09] wgrant: lets try #ca-internal first [22:09] sinzui: maybe. this issue used to happen a lot but of late it's been good [22:09] Ah, so that's where they lurk. [22:10] Laney: spph.meta_sourcepackagerelease [22:11] ta [22:14] wallyworld__, does that computer have skype or the googletalk plugin? [22:14] sinzui: yes, skype is available [22:15] and also plugin i think [22:16] sinzui: skype is open now [22:16] wallyworld__, wgrant, StevenK. I will try to remember how to conference call on skype [22:24] wallyworld__, The skype app does not appear to support conference calls :( [22:25] sinzui: i'm sure one time i had a conference call using skype, let me see if i can find out how [22:26] wallyworld__, The desktop app does. I do not have it anymore. I never had it on this computer actually [22:41] I am looking at this review: https://code.launchpad.net/~vorlon/launchpad/lp.994110/+merge/105078 I don't see anything in the file that is mentioned that would be effected by the code change.. Could someone give me a little bit of help please? [22:44] cjohnston: rick_h_ is the on call reviewer [22:45] cjohnston: Have you run the test? [22:45] cjohnston: It returns 2 specs instead of 1, presumably because of the new relaxed filtering. [22:46] czajkowski: I pinged him hours ago.. wgrant, no.. I don't have it setup to be able to run tests.. I was trying to figure out the problem though. [22:46] lifeless: sorry, too late :-) [22:47] cjohnston: http://paste.ubuntu.com/976901/ is the failure [22:47] lifeless: there wasn't too much extra, I'll integrate it into the wiki page [22:47] (I didn't look into IRC until the end of the session ...) [22:47] thanks wgrant [22:48] czajkowski: heh, sorry EOD I missed updating that [22:48] cjohnston: running the test, it just failed when I did a broad sweep of tests for that stuff [22:49] rick_h_: thanks.. wgrant pasted it for me.. [22:49] cjohnston: https://pastebin.canonical.com/65709/ ah behind sorry [22:49] * cjohnston == ~not-canonical === rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: 3.47*10^2 [22:50] cjohnston: ah sorry [22:50] np [22:50] cjohnston: Have you considered following https://dev.launchpad.net/Running/LXC to non-invasively get LP running locally? [22:50] wgrant: work out for you? [22:50] sorry, meant wgrant 's past work out then? [22:50] rick_h_: yes, it gave me the errors [22:51] wgrant: I was trying not to get that deep into this bug on the LP side :-) [22:51] hehe [22:51] Ah, right, you're just on the summit side [22:51] wgrant: I will probably bring this up on Thursday in the Clinic if slangasek doesn't get to it before that [22:52] cjohnston: Sure. It's very easy to fix. [22:53] I'm not familiar enough with testing to do it on my own. :-) [23:16] gary_poster: Another idea [23:16] gary_poster: make the replacement sys.stdout grab a traceback and report the object triggering the write [23:17] e.g. a wrapper around sys.stderr with a custom write() + writelines() methods [23:17] afk for a bit