=== matsubara is now known as matsubara-afk
[00:23] <StevenK> Hm. How to fix the qa-tagger since I forgot rollback tags
[00:23] <StevenK> (But it wasn't really a rollback)
[00:25] <StevenK> Is it fixed-commit-<rev> or good-commit-<rev>?
[00:27] <lifeless> you'll need to track it by hand
[00:27] <lifeless> I don't think anyone has landed a tag based fixup into qa-tagger
[00:27] <lifeless> there is a bug noting that this problem occurs
[00:34] <StevenK> Bah
[00:34] <StevenK> Last Modified: 2009-07-19 ago
[00:35] <lifeless> ?
[00:35] <StevenK> IE, it needs more fixing :-(
=== lifeless changed the topic of #launchpad-dev to: Performance Tuesday | top - 14:12:21 up 2 min,  3 users,  load average: 0.50, 0.57, 0.25
[00:36] <lifeless>  https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 204 - 0:[######=_]:256
[00:37] <StevenK> Fail
=== StevenK changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 204 - 0:[######=_]:256
[00:38] <lifeless> StevenK: oh, your branch? failed again ?
[00:39] <StevenK> lifeless: It doesn't OOPS, it just looks wrong
[00:39] <lifeless> StevenK: if so the  thing to do at this point is roll it all back
[00:39] <lifeless> unblock the queue so you can spend as much time on it as you want
[00:39] <StevenK> lifeless: I can fix it in the same amount of time
[00:40] <lifeless> StevenK: its about 30 seconds to land a bulk rollback; you can't do a test run etc in that much time
[00:41] <StevenK> lifeless: Even for 3 seperate revisions?
[00:42] <lifeless> StevenK: ok, so maybe a couple of minutes
[00:43] <lifeless> StevenK: do you know *exactly* what is wrong?
[00:43] <StevenK> Yes
[00:44] <lifeless> ok, well its your call. But we have considerable data now showing that rolling forward is usually harder than anyone thinks it will be :)
[00:47] <StevenK> I will self-review, it's +2,-1
[00:48] <StevenK> lifeless: I suppose this is what I get for doing the original fix last night while jetlagged.
[00:49] <lifeless> \o/
[00:49] <lifeless> probably
[00:50]  * StevenK is *still* waiting for bzr push :-/
[00:58] <StevenK> lifeless: So I should put a --rollback in this landing?
[00:58] <lifeless> yes
[00:59] <lifeless> multiple I guess :)
[01:01] <StevenK> lp-land doesn't support multiple
[01:02] <lifeless> do one
[01:02] <lifeless> and then copy the [] bits for the other
[01:28] <StevenK> lifeless: Is the parallel job on Jenkins safe to enable?
[01:28] <lifeless> StevenK: only one way to find out
[01:28] <lifeless> StevenK: we're not problem free, but knowing whether its happy or not is good
[01:29] <StevenK> Re-enabled, build scheduled.
[02:33] <StevenK> lifeless: Uh, your parallel run is barfing horribly
[02:35] <lifeless> win
[02:35] <StevenK> That must be some defintion of win I'm not previously aware of
[02:36] <lifeless> its a form of sarcasm
[02:37] <StevenK> Well, duh
[02:37] <StevenK> Replying to sarcasm with deadpan humour on IRC so *works*
[02:38] <lifeless> :)
[02:43] <LPCIBot> Project parallel-test build #84: STILL FAILING in 1 hr 1 min: https://lpci.wedontsleep.org/job/parallel-test/84/
[02:57] <LPCIBot> Project devel build #861: STILL FAILING in 5 hr 39 min: https://lpci.wedontsleep.org/job/devel/861/
[04:00] <lifeless> flacoste: perhaps you should put yourself into https://launchpad.net/~launchpad-strategist for the moment?
[05:05] <wgrant> Hmmm, rabbitfixture has stopped working for me.
[05:15] <StevenK> lifeless: O hai -- do you know what oops.pt is used for?
[05:15] <wgrant> StevenK: I've just QAd it.
[05:15] <StevenK> Ah, excellent.
[05:15] <wgrant> OK, crisis time.
[05:16] <StevenK> How, out of interest?
[05:16] <wgrant> Made +initseries OOPS.
[05:16] <StevenK> Like that's hard. :-P
[05:16] <lifeless> StevenK: its used to show OOPSes
[05:17] <lifeless> StevenK: the change to make it use the base template is a little questionable, because it makes OOPS rendering more able to fail, but its probably ok.
[05:17]  * StevenK sighs at how fragile window focus in Natty is.
[05:21] <michaelh1> Hi there.  I'm geting a HTTP 500 Internal Server Error using launchpadlib when fetching the gcc-linaro project.  OOPS is  OOPS-2012M179
[05:21] <StevenK> It's known.
[05:21] <StevenK> We're working on it right now.
[05:22] <michaelh1> Ta
[05:30] <wgrant> michaelh1: Should be working now.
[05:31] <michaelh1> wgrant: ta.
[05:32] <wgrant> michaelh1: It turns out that 32-bit serial IDs on high-volume OAuth tables are not a really good idea.
[05:34] <michaelh1> But 32 bits should be enough for anyone?
[05:34] <michaelh1> :)
[05:36] <lifeless> not with 4M inc() a day
[06:28] <wgrant> lifeless: Still about?
[06:31] <LPCIBot> Project db-devel build #696: FAILURE in 5 hr 34 min: https://lpci.wedontsleep.org/job/db-devel/696/
[07:34] <adeuring> good morning
[07:42] <LPCIBot> Project devel build #862: STILL FAILING in 5 hr 44 min: https://lpci.wedontsleep.org/job/devel/862/
[07:55] <bigjools> Does the bug email header info differentiate between indirect and direct subscription?
[08:10] <mrevell> Hello!
[08:13] <bigjools> morning mrevell
[08:54] <jtv> gmb: are you reviewing today?  Here's a simple one: https://code.launchpad.net/~jtv/launchpad/bug-798297/+merge/66816
[08:55] <gmb> jtv: Okay; will look at it presently.
[08:55] <jtv> great, thanks
[08:57] <jtv> gmb: argh, I gave you the wrong one!
[08:57] <jtv> bigjools:  picked that one up and forgot to mark it.
[08:57] <gmb> Haven't looked yet, so that's okay.
[08:57] <jtv> I meant this one: https://code.launchpad.net/~jtv/launchpad/bug-802840/+merge/66775
[08:57] <bigjools> I claimed it!
[08:57] <jtv> Oh, sorry.  Your pheromones must be weak, or it may have rained.
[08:58] <bigjools> you need to learn to reload your own browser
[08:58] <jtv> I've started to count on the frequent reboots to do that for me.
[08:58] <jtv> It's like Ajax, only simpler.
[08:58] <bigjools> that doesn't help
[08:58] <bigjools> FF loads the page as it was!
[08:58] <bigjools> when it restores, I mean
[08:59] <jtv> cache ftw
=== gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 204 - 0:[######=_]:256
[09:18] <gmb> jtv: Lazy reviewer alert: Those tests could do with some leading comments. I know you've tried to make the test names meaningful and descriptive, but it still took me several seconds to parse them, and I'm fundamentally lazy.
[09:18] <jtv> gmb: leading comments… isn't that where the opposing attorney objects and the judge tells me to behave?
[09:18]  * jtv edits
[09:19] <gmb> jtv: Maybe, but I'm the one wielding the loving gavel of approval here...
[09:19] <jtv> Crystal.
[09:21] <lifeless> wgrant: hi
[09:21] <lifeless> wgrant: jus tback from parenting class
[09:21] <lifeless> though I think its 'make the class faint class' atm
[09:21] <nigelb> hehe
[09:21] <jtv> I do so hope this is leading up to a spanking for wgrant
[09:25]  * bigjools reaches for brain bleach
[09:25] <jtv> gmb: comments pushed
[09:26] <gmb> jtv: Right. I've already approved it.
[09:26] <jtv> Ta!
[09:26]  * gmb reads backscroll.
[09:26] <gmb> bigjools: When you're done with the brainbleach, I need to wash my mind's eye with it.
[09:27] <bigjools> be my guest
[09:27] <jtv> gmb: was my branch that bad?
[09:28] <gmb> jtv: Your branch was a soothing balm. Your ability to conjure up mental images, though...
[09:28] <jtv> I knew that, I just enjoy watching you bring yourself to say it.
=== almaisan-away is now known as al-maisan
[09:37] <rvba> gmb: Hi ... and thanks for reviewing my branch!
[09:37] <rvba> bigjools: I'll land it then (https://code.launchpad.net/~rvb/launchpad/bug-805547/+merge/66861)
[09:37] <gmb> rvba: Hi, and no problem :). (I like reviewing the small branches first; it gives me the impetus to deal with the larger ones)
[09:38] <bigjools> rvba: I think your test is wrong
[09:38] <bigjools> the source is not in two parents
[09:39] <bigjools> the problem was that sources for unrelated packagesets were being copied
[09:39] <rvba> bigjools: self.setupParent creates a few packages.
[09:39] <rvba> And then 'udev' is created in each parent.
[09:39] <rvba> I then create two packagesets (one in each parent).
[09:40] <rvba> test1.addSources('udev')
[09:40] <rvba> test2.addSources('udev')
[09:40] <rvba> This should add 'udev' to each packageset in each parent.
[09:40] <rvba> bigjools: don't you think?
[09:40] <bigjools> yeah, I think that is the wrong approach
[09:41] <bigjools> the test should check that a package in a packageset for distroseries "A" is not copied when inheriting from distroseries "B"
[09:41] <rvba> I think I understood the error you got differently then ...
[09:42] <rvba> (and I might be wrong)
[09:42] <bigjools> I think your fix is ok
[09:42] <bigjools> btw, "if spns == []"
[09:42] <bigjools> len(spns) == 0 ?
[09:43] <rvba> I can change that If you prefer.
[09:43] <rvba> *If you prefer it that way
[09:43] <bigjools> it seems better style but what do I know :)_
[09:44] <rvba> :)
[09:44] <bigjools> just reading your test again
[09:44] <rvba> A1 (packageset p1 with source s1) + A2 (packageset p2 with source s1 [same source name]) => init (packageset p1)
[09:44] <rvba> This is what I'm testing.
[09:46] <rvba> Until now, when we copied from the second parent, we decided to copy the source s1 also (because we did not very that p1 was in A2) ... and this is wrong.
[09:47] <bigjools> the problem was that all sources in all packagesets were getting copied for every iteration through the parent series
[09:47] <bigjools> rather than just the sources in the packagesets for the parent series being considered
[09:47] <rvba> exactly.
[09:48] <rvba> My test test_copying_packagesets_multiple_parents_same_source triggered the problem (before the fix).
[09:48] <bigjools> you comment at the top of the test is confusing me a bit: "# If a source with the same packagename is included in two parents ..."
[09:48] <bigjools> that's got nothing to do with the problem
[09:48] <bigjools> that's good to hear at least :)
[09:49] <rvba> I would not go this far ... but it's not very precise indeed. :)
[09:49] <rvba> Let me rephrase that.
[09:49] <bigjools> I would have expected a test to check whether a source in p2 is not copied when initialising from s1
[09:50] <bigjools> does that make sense?
[09:50] <rvba> Yes.
[09:51] <bigjools> rvba: it's hard to see if that's being tested in your new test
[09:52] <rvba> Well, the real test is that the initialisation happens.
[09:52] <bigjools> that's a smoke test, not a unit test
[09:53] <rvba> And that the correct package has been copied, proof that the the initialisation was successful ...
[09:53] <rvba> Here is you unit test :)
[09:53] <rvba> your*
[09:53] <bigjools> well if it works then ok
[09:54] <rvba> bigjools: but ok, I get your point, I'll refactor the test a bit, and the comment.
[09:54] <bigjools> I am just saying that I was confused :)
[09:54] <rvba> And this is sign that there is a problem with the test :) ... it should not be confusing
[09:55] <bigjools> splitting it up into different sections with comments would help :)
[09:55] <rvba> bigjools: ok
[10:56] <allenap> gmb: Got one for you if you're interested. https://code.launchpad.net/~allenap/launchpad/lp-app-longpoll/+merge/66872
[10:56] <gmb> allenap: Sure
[10:56] <allenap> gmb: Thanks dude.
[11:07] <gmb> allenap: Wherefore this:
[11:07] <gmb> 98	+    #adapts(Interface, Interface)
[11:07] <gmb> 99	+    #implements(ILongPollEvent)
[11:07] <gmb> ?
[11:08] <allenap> gmb: It's a hint for people who are writing a concrete subclass.
[11:08] <gmb> allenap: Ah, cool. That's what I thought; just wanted to check.
[11:08] <allenap> I'll add a comment to that effect.
[11:14] <allenap> gmb: I have to go out now, unexpectedly, but I'll be back later. That okay?
[11:14] <gmb> allenap: That's fine. It's looking good so far anyway.
[11:15] <allenap> Thanks.
=== matsubara-afk is now known as matsubara
[12:01] <jml> lifeless: I guess you didn't get around to looking at the testtools gassy-failures branch.
[12:01] <jml> lifeless: I'll probably merge it tomorrow if I don't hear from you.
[12:01] <lifeless> sorry I didn't.
[12:01] <lifeless> kk
[12:01] <jml> lifeless: no worries. I'm not blocked on it, just minimizing inventory.
[12:08] <LPCIBot> Project db-devel build #697: STILL FAILING in 5 hr 36 min: https://lpci.wedontsleep.org/job/db-devel/697/
[12:34] <StevenK> Is anyone in Europe/US doing a deployment request? r13371 is (finally) deployable.
[12:35] <StevenK> Er, that should be "Does anyone in Europe/US feel like doing a deployment request?" :-/
[13:37] <LPCIBot> Project devel build #863: STILL FAILING in 5 hr 55 min: https://lpci.wedontsleep.org/job/devel/863/
=== al-maisan is now known as almaisan-away
=== almaisan-away is now known as al-maisan
[14:16] <deryck> Hi, all.
[14:18] <flacoste> hi deryck, happy anniversary
[14:18] <deryck> Thanks, flacoste!
[14:19] <flacoste> bigjools: do copy rebuilds have an entry in *pph?
[14:19] <bigjools> flacoste: yes
[14:19] <flacoste> bigjools: and where is the 'upload' date recorded? would it be datecreated on spph?
[14:20] <bigjools> flacoste: no, the original SPR
[14:20] <bigjools> datecreated on the copy SPPH is when it was copied
[14:20] <flacoste> so spph.sourcepackagerelease.dateuploaded?
[14:21] <bigjools> yes, that's when the package was *first* uploaded
[14:21] <flacoste> no, i'm interested in when the 'rebuild request' was issued
[14:21] <flacoste> so that would be spph.datecreated, right?
[14:21] <bigjools> flacoste: none of the above :)  Archive.date_created
[14:21] <flacoste> interesting!
[14:22] <flacoste> each rebuild have their own archive!
[14:22] <flacoste> convenient
[14:22] <bigjools> flacoste: the SPPH datecreated is nearly right but they are not all the same
[14:22] <bigjools> yes, we can only rebuild in separate archives
[14:22] <flacoste> ok, i think i have all i need to do some interesting data analysis
[14:22] <flacoste> thanks
[14:22] <bigjools> great
[14:22] <bigjools> np
[14:35] <gary_poster> deryck: quick good news: Friday night I hacked a bit and got the per-test runtime for the YUI/appserver tests down from 4 seconds to .7 seconds.  I think that's much more palatable.
[14:35] <deryck> gary_poster, yes, that sounds nice!
[14:35] <deryck> gary_poster, now that we're back home, are you finishing off that work?  Or flacoste?
[14:36] <gary_poster> deryck, I was going to do it, but *very* happy to share if anyone else wants to take it. :-)
[14:36] <gary_poster> but I was just about to work on that now
[14:37] <deryck> gary_poster, ok, cool.  I'm happy to take any part of it that you can pass to me.
[14:38] <gary_poster> deryck, cool.  How about I work on this till Wed; if there's stuff left to get it landed I pass it to you.  Sound ok?  (I *might* ask off for Thurs and Fri, so that would make even more sense in that scenario)
[14:38] <deryck> gary_poster, sounds perfect to me.
[14:38] <flacoste> bigjools: populate-archive creates the archive as disabled "to allow requestor to tweak build dependencies", how do they turn it enabled to allow builds to proceed?
[14:38] <deryck> gary_poster, also, my squad will do interrupt duties this week, since we should have had them last week.
[14:38] <bigjools> flacoste: in the +admin/+edit page for the archive
[14:38] <gary_poster> awesome thanks deryck
[14:39] <deryck> np
[14:39] <bigjools> flacoste: we need to do some cleanup in this area to remove these old archives when they're done with as they take up a lot of DB and librarian space.
[14:39] <flacoste> bigjools: no builds will be queued until they do that right? do we record the date they enabled the archive? or we can infer it from the date on the spph?
[14:40] <flacoste> bigjools: the fact that they are all in the DB currently is very useful for my analysis :-), but i agree that it might not be "feature" we want to support
[14:42] <deryck> abentley, since I came in late today, let's reschedule our call tomorrow or the next day.  Cool?
[14:42] <bigjools> flacoste: builds are queued as soon as the source is copied, it's just that the buildd-manager ignores builds in disabled archives
[14:42] <abentley> deryck: sure.
[14:43] <deryck> abentley, thanks!
=== al-maisan is now known as almaisan-away
[14:43] <bigjools> flacoste: not sure how we can get hold of date enabled.
=== adeuring1 is now known as adeuring
[14:48] <flacoste> bigjools: what about packagecopyrequest.date_started?
[14:48] <bigjools> flacoste: that's pretty much the same thing as the archive.date_created
[14:49] <bigjools> PCR is the job that sets up the (disabled) copy archive
[14:49] <bigjools> flacoste: I am guessing that you want to see how long it takes to rebuild?
[14:50] <flacoste> bigjools: yes, i'm trying to assess the impact of changing rebuild priority
[14:50] <bigjools> flacoste: your best bet is to add up all the build durations on the builds themselves
[14:50] <bigjools> I did something similar in the lag graph
[14:50] <flacoste> bigjools: we don't throw away builds?
[14:50] <bigjools> no
[14:51] <bigjools> and if we did, build records are not the same as the build results :)
[14:52] <flacoste> bigjools: is it just me or date_completed on packagecopyrequest is bogus?
[14:52] <bigjools> flacoste: I don't know, are you bogus?
[14:52] <flacoste> it depends ;-)
[14:52]  * bigjools gets coat
[14:53] <flacoste> avg(date_completed - date_started) = 01:04:36.777614
[14:53] <bigjools> I've not looked at it in a while, so not sure
[14:53] <bigjools> that seems reasonable if it's 1h?
[14:53] <bigjools> the job takes a while to build the archive up
[14:53] <flacoste> that would 1d 4
[14:53] <bigjools> ah not 1d :)
[14:53] <flacoste> err
[14:54] <flacoste> no you are right 1:03
[14:54] <flacoste> 1h
[14:54] <flacoste> ok, so date_completed is when all the package records have been copied
[14:54] <flacoste> not when the rebuild is finished
[14:54] <bigjools> yep
[14:54] <flacoste> so it was me :-)
[14:54] <bigjools> also it creates builds in the requested arches
[15:00] <flacoste> bigjools: all time?
[15:02] <bigjools> flacoste: yeah
[15:05] <bigjools> flacoste: pulseaudio is an utter crock of shit!
[15:06] <flacoste> i'm sorry to hear that it's causing you so much trouble
[15:08] <bigjools> skype is refusing to use my headset
[15:08] <flacoste> even though it's selected in the sound control panel?
[15:09] <flacoste> bigjools: do you want to try voip?
[15:09] <bigjools> flacoste: if the next "fix" doesn't work then yes
[15:13] <flacoste> bigjools: i'm at extension 7356
[15:13] <bigjools> flacoste: that doesn't work either :/
[15:14] <bigjools> why does this have to be so hard to get right ...
[15:15] <flacoste> i wonder everytime...
[15:30] <Beret> can you delete tags in LP?
[15:32] <jml> no.
=== salgado is now known as salgado-lunch
[15:37] <Beret> thx
[15:38] <jml> (also, more evidence for combining #launchpad & #launchpad-dev)
[15:38] <nigelb> jml: why? :(
[15:39] <nigelb> I quite like the distinction. When I'm working on LP per se I'd ask here, else ask there
[16:19] <jml> nigelb: because people ask user questions in here, and because #launchpad is less tracked by developers than #launchpad-dev
[16:19] <jml> nigelb: also, entia non sunt multiplicanda praeter necessitatem
[16:19] <nigelb> jml: less-tracked. I thought CHR was supposed to solve that. merging the channel might cause chatter merging in with work
[16:20] <jml> nigelb: meh, there's little harm in that. many IRC channels deal with it just fine
[16:20] <nigelb> Since the chatter in launchpad is low enough, it might be a good idea
[16:21] <nigelb> jml: You got the spelling right there. I salute you sir :)
[16:21]  * nigelb had to use google translate
[16:21] <jml> hah.
[16:21] <jml> it used to be in the #divmod topic when I hung out there
=== gmb changed the topic of #launchpad-dev to: Performance Tuesday | https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 204 - 0:[######=_]:256
=== deryck is now known as deryck[lunch]
[16:52] <timrc> Using STAGING_SERVICE_ROOT for http://pastebin.ubuntu.com/638486/, if I go to the Adminster web-view for that PPA, I do not see ARM Processors checked under Enabled Restricted families -- am I doing something wrong?
[16:57] <bigjools> timrc: your paste doesn't show which PPA
[16:57] <bigjools> so I suspect yes you are doing something wrong :)
=== beuno is now known as beuno-lunch
[16:58] <timrc> bigjools, it's a private ppa, https://launchpad.net/~oem-archive/+archive/test1
[16:59] <bigjools> timrc: I see the box ticked on staging
[16:59] <timrc> bigjools, lol ;) that would be my problem
[16:59] <timrc> bigjools, I was looking at the production web-view
[16:59] <bigjools> timrc: yes :)
[17:01]  * timrc hangs his head in shame as he walks to the kabob food stand
=== almaisan-away is now known as al-maisan
=== deryck[lunch] is now known as deryck
=== salgado-lunch is now known as salgado
[17:25]  * bigjools considers making setup an alias for setUp in testtools to save a wasted half hour
[17:28] <jml> flacoste: hi
[17:38] <flacoste> hi jml
[17:38] <jml> flacoste: I sent an email instead.
[17:38]  * jml has to go, sorry
[17:38] <flacoste> np
=== sidnei is now known as sidnei-away
[17:46] <LPCIBot> Project db-devel build #698: STILL FAILING in 5 hr 37 min: https://lpci.wedontsleep.org/job/db-devel/698/
=== al-maisan is now known as almaisan-away
[17:55] <bigjools> good night all
=== beuno-lunch is now known as beuno
[18:32] <dobey> why would launchpad not think a person is a member of a team that person is a member of?
[19:04] <dobey> so Entry.__eq__ in launchpadlib seems to be broken
[19:19] <dobey> hello?
[19:19] <dobey> why would the http_etag be different, on the same person resource?
[19:20] <dobey> one being a reference from launchpad.people[username] and the other being a reference got through membership listing on a team
[19:20] <beuno> private team?
[19:21] <dobey> nope
[19:21]  * beuno gives up
[19:21] <dobey> i don't think it's specific to the team
[19:22] <dobey> i tried another team, and it has the same wrong etag :(
[19:26] <LPCIBot> Project devel build #864: STILL FAILING in 5 hr 48 min: https://lpci.wedontsleep.org/job/devel/864/
[19:31]  * dobey wonders where to file the bug at least
[19:31] <dobey> i guess in launchpad itself as it seems like it is a server issue, ignoring the question of whether restfulclient should even use etag as a comparison inside __eq__
=== matsubara is now known as matsubara-afk
[19:52] <lifeless> moin
[19:52] <lifeless> dobey: file a bug please
[19:58] <dobey> right, i was about to :)
[20:12] <dobey> bug #806163
[20:12] <_mup_> Bug #806163: Different http_etag for same resource? <Launchpad itself:New> < https://launchpad.net/bugs/806163 >
[20:53] <lifeless> jcsackett: is bug 806179 affecting staging/qastaging/prod ?
[20:53] <_mup_> Bug #806179: PersonPickers broken from bad passed in config <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/806179 >
[20:54] <jcsackett> lifeless: one sec, i'll check; i found it in .dev while reviewing an MP.
[20:54] <jcsackett> a guess would say yes.
[20:54] <lifeless> jcsackett: does it cause test failures?
[20:54] <lifeless> jcsackett: if it doesn't, the bug should be critical, and the landing that brought it in marked qa-bad
[20:55] <jcsackett> lifeless: it doesn't--it's actually a result of some bad piping that until recently there wasn't any good way to test. i believe some of the YUI/appserver stuff people worked on during the epic will fix that issue.
[20:55] <lifeless> right, but we can't deploy with it broken :)
[20:55] <lifeless> well, we *could*, but we shouldn't.
[20:56] <jcsackett> lifeless: it doesn't cause test failures, rather. it does appear on qastaging.
[20:56] <lifeless> ok
[20:56] <lifeless> so, lets find the bad rev, mark *its* bug as qa-bad, and escalate this new bug.
[20:56] <lifeless> do you need a hand with any of that ?
[20:57] <jcsackett> lifeless: don't think i should.
[20:57] <lifeless> coolio
[20:57] <lifeless> I'll be back in 15 or so
[20:57] <lifeless> if you change your mind :)
[20:57] <lifeless> allenap: btw, why can't rabbit in dev mode still use an ephemeral port ?
[20:59] <allenap> lifeless: I was following the lead of other services... which I assumed didn't have ephemeral ports.
[20:59] <lifeless> allenap: they don't, but its a bug :)
[21:00] <lifeless> allenap: or at least, I think it is: you can't run up more than one instance in dev mode, stale processes make things break, sadness all around
[21:01] <allenap> lifeless: Right. I guess the problem is going to be telling processes outside of `make run` (or whatever) about which port its running on. You've done something with that in RabbitMQLayer, so I could do the same.
[21:01] <allenap> s/its/it's/
[21:02] <lifeless> allenap: yeah. For instance, have the txlongpoll take a host:port on its command line for the rabbit to talk to
[21:03] <jcsackett> could someone take a look athttps://code.launchpad.net/~jcsackett/launchpad/button-configs-break-pickers/+merge/66946 for me? it's a short one.
[21:03] <allenap> lifeless: It does, afaik, but I'm thinking of things like running jobs that want to use Rabbit. How do I get the configuration to them? (Use the RabbitMQLayer stuff?)
[21:04] <lifeless> allenap: export a LP_CONFIG
[21:04] <jcsackett> lifeless: only question i do have is what we do with the qa-bad bug once the fixing branch lands--mark both bugs as qa-ok? (assuming the fix works out).
[21:04] <lifeless> jcsackett: the fixing branch should be landed with --rollback=12345
[21:04] <lifeless> jcsackett: it doesn't matter if you're rolling forward or back, thats the option to use.
[21:05] <allenap> lifeless: Okay, I don't really get how that solves the problem.
[21:05] <jcsackett> lifeless: ah. i'll keep that in mind. didn't realize that wasn't actually rollback specific.
[21:05] <lifeless> jcsackett: the bad-commit-12345 marker must *stay* on the bug
[21:05] <lifeless> jcsackett: that tells qa tagger to lock the rev 12345 and the rollback-of-12345 together
[21:05] <jcsackett> lifeless: ah, so i should put in a bad-commit and a qa-bad? or does the bad-commit get added automatically with rollback?
[21:05] <lifeless> jcsackett: the qa-bad becomes qa-good once we're all sorted.
[21:05] <lifeless> bad-commit-12345 is added by hand
[21:05] <jcsackett> dig.
[21:06] <lifeless> allenap: oh, by creating an ephemeral config on disk, inheriting from 'development', when you export LP_CONFIG=..., all the worker processes etc will read from it
[21:06] <lifeless> allenap: this is what BaseLayer does, for instance.
[21:08] <allenap> lifeless: Ah, okay. However, what do we do when someone spools up rabbit using `make run` then runs a job via cronscripts/run_jobs.py? Do we have to set LP_CONFIG manually then?
[21:08] <allenap> There is some convenience to having the librarian on a known port.
[21:09] <lifeless> allenap: I'd report back the config to use
[21:09] <lifeless> uhm
[21:09] <lifeless> whats the convenience ?
[21:10] <lifeless> allenap: anyhow, its a thought
[21:10] <lifeless> theres obviously a -big- stack of things that would need to be migrated, but I don't think everything needs to change at once.
[21:10] <lifeless> stub: hola!
[21:10] <stub> YO
[21:11]  * stub turns down the volume
[21:11] <stub> yo
[21:11] <allenap> lifeless: Okay, I'll try with an ephemeral port, but as this is only a developer convenience (afaict) it might end up being less convenient.
[21:12] <allenap> On that note, night all.
=== salgado is now known as salgado-afk
[23:20] <LPCIBot> Project db-devel build #699: STILL FAILING in 5 hr 34 min: https://lpci.wedontsleep.org/job/db-devel/699/