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