[01:27] <LPCIBot> Project db-devel build #551: STILL FAILING in 5 hr 28 min: https://lpci.wedontsleep.org/job/db-devel/551/
[02:23] <lifeless> zomg
[02:23] <lifeless> who comments on bug 4, really?
[02:23] <_mup_> Bug #4: Importing finished po doesn't change progressbar <lp-translations> <Launchpad itself:Fix Released by carlos> <Ubuntu:Invalid> < https://launchpad.net/bugs/4 >
[02:27] <wgrant> Yeah :(
[03:02] <lifeless> his only comment on lp
[03:03] <lifeless> poor dude, going to be annoyed noone replies ...
[05:09] <StevenK> lifeless: Re https://code.launchpad.net/~stevenk/launchpad/karma-store/+merge/60987 , I wasn't comfortable enough to self-review -- however, since you like the change, I'll do so and toss it at ec2.
[05:44] <lifeless> StevenK: cool
[09:20] <StevenK> And rabbit fails on ec2.
[09:20]  * StevenK lp-land's the branch
[09:20] <wgrant> StevenK: We're in testfix.
[09:20] <wgrant> Also because of rabbit.
[09:20] <StevenK> Oh, for the love of!
[09:20] <wgrant> Failed twice on lucid_db_lp, I haven't bothered to try again.
[09:21] <wgrant> May back it out tomorrow.
[09:21] <wgrant> If lifeless doesn't kill me.
[09:22] <StevenK> Personally, I think that's a wise decision -- it's broken on buildbot, ec2 and jenkins.
[09:22]  * StevenK grumbles at lp-land
[09:22] <StevenK> Stop adding [r=..] when the commit message already has them!
[09:41]  * StevenK tries to figure out how to run bzr-pqm tests.
[10:01] <lifeless> wgrant: whats the fail ?
[10:01] <nigelb> launchpad people --> YOU ALL ROCK :)
[10:02] <nigelb> I would have said this earlier, but my IRC wasn't very stable
[10:02] <nigelb> Awesome work on reducing timeouts and fixing bug subscriptions :)
[10:19] <wgrant> lifeless: It fails to start, apparently.
[10:19] <wgrant> lifeless: See the last $FORGOTTEN failures.
[10:19] <lifeless> grah
[10:19] <lifeless> wgrant: possibly regressed
[10:19] <wgrant> Possibly.
[10:19] <lifeless> before backing out, run the unit test layer - if that fails its reproducable
[10:20] <lifeless> [locally, I mean]
[10:21] <lifeless> if that works, its buildbot specific in most probability
[11:05] <wgrant> lifeless: it breaks here.
[11:05] <wgrant> Let me try again, though.
[12:15] <NCommander> morning all
[12:15] <NCommander> wgrant: I did some work on LP on my flight ot the US, but I'm a bit confused which API is the current perfered one for creating packages (
[12:16] <wgrant> NCommander: "packages"? "creating"?
[12:17] <NCommander> wgrant: fake packages via the testing API
[12:18] <wgrant> What kind of packages? For what purpose?
[12:18] <NCommander> wgrant: for the archive any/all skew
[12:18] <NCommander> brb
[12:26] <wgrant> NCommander: Source? Binary?
[12:30] <NCommander> wgrant: both, but I have only gotten as far as source
[12:30] <NCommander> my code is currently using makeSourcePackagePublishingHistory from the factory and setting the status directly to published.
[12:31] <NCommander> http://paste.ubuntu.com/607760/
[12:32] <wgrant> NCommander: I'm not sure that setting dsc_binaries will do anything at all, but that looks reasonable so far.
[12:32] <NCommander> wgrant: yeah, I'm just finding it a bit hard to figure this out, most of the test cases use the older Soyuz testing code it seems, and I'm coming up short on finding documentation :-/
[12:33] <wgrant> You really need to know how our model is structured. Do you know it?
[12:33] <NCommander> wgrant: to an extent, but there are significant gaps in places. I didn't see a useful diagram on the wiki when I looked
[12:34] <wgrant> https://dev.launchpad.net/Soyuz/TechnicalDetails
[12:35] <wgrant> You shouldn't have to go near PackageUpload*
[12:37] <NCommander> I agree I should be able to avoid going near PackageUpload (I just need to create some dummy packages via the testing API). The trick I haven't figure is how to run the publisher. I'd like to avoid it if ipossible, but since we'r edealing with a corner case that needs to be processed when a package is superseded, I think its needed for the test case
[12:37] <wgrant> You probably should run the publisher's full domination step, yes.
[12:37] <wgrant> Grep for B_dominate
[12:38] <wgrant> Don't bother with the other steps.
[12:38] <wgrant> Step A is just setting everything to Published, C is index generation, D is Release generation.
[12:38] <wgrant> So only B is relevant to you.
[12:39] <NCommander> Right. that will caused packages to go from PENDING->PUBLISHED, and the previous published packages to go to SUPERSEDED, right?
[12:39] <wgrant> A does PENDING->PUBLISHED.
[12:39] <wgrant> B does PUBLISHED->SUPERSEDED
[12:39] <wgrant> A also writes the package files to disk, so you want to avoid it if possible.
[12:40] <NCommander> so for a brief peroid, both the old package, and the new package are published
[12:40] <wgrant> That's right.
[12:40] <wgrant> It is rather odd.
[12:40] <NCommander> Ok, so then I can just create the new binaries with SUPERSEDED
[12:40] <wgrant> PUBLISHED, you mean?
[12:40] <NCommander> I was under the impression things would break if I had multiple packages set in the PUBLISHED state
[12:40] <NCommander> er
[12:40] <NCommander> yeah
[12:40] <NCommander> sorry, my caffiene level is only starting to reach critical mass
[12:40] <wgrant> Stuff shouldn't break.
[12:41] <wgrant> Heh.
[12:41] <wgrant> Are you also jetlagged?
[12:41] <wgrant> I presume so.
[12:41] <NCommander> wgrant: I'm still in transit
[12:41] <wgrant> Ah!
[12:41] <wgrant> That is unfortunate.
[12:41]  * NCommander had a 22 hour layover in NYC
[12:41] <NCommander> I'm now on my way to SFO, then another hop to PDX
[12:42] <wgrant> 22h domestic layover‽
[12:42] <NCommander> international->domestic
[12:42] <NCommander> Dropped in to see my mom
[12:42] <wgrant> Ah, I see.
[12:43]  * NCommander writes the fake binary bit
[13:08] <NCommander> wgrant: it seems to me that BPPHs are not (directly) linked to their SPPH. As such, I'm confused on how LP tied source and binaries together
[13:09] <wgrant> NCommander: Yeah, they're not directly linked because they can be overridden etc. separately.
[13:09] <wgrant> NCommander: So it goes through the BPB and SPR.
[13:10] <wgrant> And finds publications in the same series and archive at the other end.
[13:12] <NCommander> wgrant: makes sense in an odd sorta way. Reading on that page you linked me and a few comments, I get the impression SUPERSEDED packages are still published until they are removed (either by archive admin or automated processes)
[13:13] <wgrant> NCommander: They are removed from the indices immediately. The files are not removed until they are unreferenced and process-death-row is run.
[13:13] <wgrant> NCommander: The indices are generation from all publications with status PUBLISHED.
[13:13] <NCommander> Ah. and the difference between SUPERSEDED and PUBLISHED becomes clear
[13:13] <NCommander> Thanks
[13:13]  * NCommander vaguely wonders if we need a SUPERSEDED_BUT_STILL_PUBLISHED state :-)
[13:13]  * NCommander ducks
[13:14] <wgrant> There is some argument that we should include superseded packages in the indices until they are removed.
[13:14] <wgrant> That is easy to do, and possibly beneficial for a couple of reasons.
[13:14] <wgrant> But it would require much thought.
[13:14] <NCommander> plus it makes this trivial to solve
[13:14] <wgrant> Right.
[13:14] <wgrant> Well, not trivial.
[13:14] <NCommander> well, mor estraightforward
[13:14] <wgrant> But much easier: you just have to prevent judgeSuperseded from setting scheduleddeletiondate for the binaries that you want to keep.
[13:17] <NCommander> wgrant: ugh, I just realized that since I need to make BPBs to tie my sources together, I also need to desginate the arch-all architecture. I didn't see an obvious way to do that (or will it magicially get set to 'i386')
[13:18] <wgrant> NCommander: Are you calling makeDistroArchSeries manually?
[13:18] <StevenK> NCommander: distroseries.nominatedarchindep =
[13:18] <NCommander> yes
[13:18] <wgrant> What StevenK said.
[13:19] <StevenK> If you aren't making a distroseries, you can fetch it by distroarchseries.distroseries
[13:22] <NCommander> Unauthorized: (<DistroSeries u'lucid'>, 'nominatedarchindep', 'launchpad.Moderate')
[13:22] <NCommander> Something tells me I can't just set that property directly
[13:23] <wgrant> Ah. Use removeSecurityProxy
[13:35] <StevenK> I've been able to in tests ...
[13:35] <wgrant> StevenK: In ZopelessLayer, maybe.
[13:48] <StevenK> Ah, yes
[13:49] <StevenK> NCommander: The other thing you can do is fetch the admin from IPersonSet and run that as the admin
[13:49] <NCommander> StevenK: is there a preference in test cases?
[14:42] <StevenK> NCommander: I personally prefer logging in as a admin, since I find removeSecurityProxy distateful, but not really -- as you see fit -- but your reviewer might prefer you don't use it.
[14:51] <NCommander> StevenK, wgrant: as a thought, can we trust the depends field in a BPR on a way to determine if a package is skewed? it would also pave the way to keep development releases in an always installable state ...
[15:04] <StevenK> NCommander: Now that I've thought about it -- why?
[15:05] <StevenK> NCommander: And I think it's dangerous -- think about the case of a transition. If we can't remove the binaries of a package since it would make the archive uninstallable, how are we able to proceed?
[15:06] <NCommander> StevenK: it was an idea that simply occured to me since I've always liked the 'always-installable' aspect of Debian testing. As for transitions, we don't remove NBS'ed binaries until the transition is complete anyway
[15:08] <StevenK> NCommander: No, but we have the option to.
[15:08] <StevenK> NCommander: However, yes, the BPR.depends field is to be trusted.
[15:09] <NCommander> k
[16:01] <NCommander> What's the proper way to get self.logger to exist? A lot of tests use it, but I don't see an obvious way to make it be defined
[16:02]  * NCommander feels that STP sets up a lot of this ...
[20:39] <cjohnston> jml: bug 255024 - if you remember we talked about that.. I've pushed a fix and just wanted to get your opinion.. And I'll take anyone elses opinion as well
[20:39] <_mup_> Bug #255024: "Participation essential" is "Required" when subscribing <lp-blueprints> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/255024 >
[20:52] <maxb> Hrm. What could cause a commented bug not to appear in a user's commented bugs page?
[20:53] <maxb> Case in point is the spam comment in https://bugs.launchpad.net/ubuntu/+source/radeontool/+bug/601539
[20:53] <_mup_> Bug #601539: Please sync radeontool 1.6.1-1 (main) from Debian unstable (main). <workflow> <radeontool (Ubuntu):Fix Released> < https://launchpad.net/bugs/601539 >
[21:23] <lifeless> wgrant: hi
[21:23] <lifeless> wgrant: interesting
[21:24] <cjohnston> hey lifeless
[21:24] <lifeless> maxb: wow, I'm blind now :)
[21:26] <lifeless> cjohnston: hi
[21:27] <lifeless> maxb: if message.owner is not them, though that would on the face of it not make much sense
[21:27] <lifeless> or their message index is nonzero
[21:28] <lifeless> there is a denormalised field in there
[22:56] <lifeless> wgrant: rabbit test passes for me (but I haven't merged up with trunk yet)
[23:41] <lifeless> wgrant: who should get ppa build notifications (see bug 782924)
[23:42] <_mup_> Bug #782924: Send e-mail notification when PPA builds are finished <Launchpad itself:Incomplete> < https://launchpad.net/bugs/782924 >