[01:27] Project db-devel build #551: STILL FAILING in 5 hr 28 min: https://lpci.wedontsleep.org/job/db-devel/551/ [02:23] zomg [02:23] who comments on bug 4, really? [02:23] <_mup_> Bug #4: Importing finished po doesn't change progressbar < https://launchpad.net/bugs/4 > [02:27] Yeah :( [03:02] his only comment on lp [03:03] poor dude, going to be annoyed noone replies ... [05:09] 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] StevenK: cool [09:20] And rabbit fails on ec2. [09:20] * StevenK lp-land's the branch [09:20] StevenK: We're in testfix. [09:20] Also because of rabbit. [09:20] Oh, for the love of! [09:20] Failed twice on lucid_db_lp, I haven't bothered to try again. [09:21] May back it out tomorrow. [09:21] If lifeless doesn't kill me. [09:22] 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] 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] wgrant: whats the fail ? [10:01] launchpad people --> YOU ALL ROCK :) [10:02] I would have said this earlier, but my IRC wasn't very stable [10:02] Awesome work on reducing timeouts and fixing bug subscriptions :) === nigelb is now known as Guest58084 === Guest58084 is now known as nigelb [10:19] lifeless: It fails to start, apparently. [10:19] lifeless: See the last $FORGOTTEN failures. [10:19] grah [10:19] wgrant: possibly regressed [10:19] Possibly. [10:19] before backing out, run the unit test layer - if that fails its reproducable [10:20] [locally, I mean] [10:21] if that works, its buildbot specific in most probability === nigelb is now known as Guest53049 === Guest53049 is now known as nigelb [11:05] lifeless: it breaks here. [11:05] Let me try again, though. [12:15] morning all [12:15] 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] NCommander: "packages"? "creating"? [12:17] wgrant: fake packages via the testing API [12:18] What kind of packages? For what purpose? [12:18] wgrant: for the archive any/all skew [12:18] brb [12:26] NCommander: Source? Binary? [12:30] wgrant: both, but I have only gotten as far as source [12:30] my code is currently using makeSourcePackagePublishingHistory from the factory and setting the status directly to published. [12:31] http://paste.ubuntu.com/607760/ [12:32] NCommander: I'm not sure that setting dsc_binaries will do anything at all, but that looks reasonable so far. [12:32] 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] You really need to know how our model is structured. Do you know it? [12:33] 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] https://dev.launchpad.net/Soyuz/TechnicalDetails [12:35] You shouldn't have to go near PackageUpload* [12:37] 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] You probably should run the publisher's full domination step, yes. [12:37] Grep for B_dominate [12:38] Don't bother with the other steps. [12:38] Step A is just setting everything to Published, C is index generation, D is Release generation. [12:38] So only B is relevant to you. [12:39] Right. that will caused packages to go from PENDING->PUBLISHED, and the previous published packages to go to SUPERSEDED, right? [12:39] A does PENDING->PUBLISHED. [12:39] B does PUBLISHED->SUPERSEDED [12:39] A also writes the package files to disk, so you want to avoid it if possible. [12:40] so for a brief peroid, both the old package, and the new package are published [12:40] That's right. [12:40] It is rather odd. [12:40] Ok, so then I can just create the new binaries with SUPERSEDED [12:40] PUBLISHED, you mean? [12:40] I was under the impression things would break if I had multiple packages set in the PUBLISHED state [12:40] er [12:40] yeah [12:40] sorry, my caffiene level is only starting to reach critical mass [12:40] Stuff shouldn't break. [12:41] Heh. [12:41] Are you also jetlagged? [12:41] I presume so. [12:41] wgrant: I'm still in transit [12:41] Ah! [12:41] That is unfortunate. [12:41] * NCommander had a 22 hour layover in NYC [12:41] I'm now on my way to SFO, then another hop to PDX [12:42] 22h domestic layover‽ [12:42] international->domestic [12:42] Dropped in to see my mom [12:42] Ah, I see. [12:43] * NCommander writes the fake binary bit [13:08] 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] NCommander: Yeah, they're not directly linked because they can be overridden etc. separately. [13:09] NCommander: So it goes through the BPB and SPR. [13:10] And finds publications in the same series and archive at the other end. [13:12] 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] 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] NCommander: The indices are generation from all publications with status PUBLISHED. [13:13] Ah. and the difference between SUPERSEDED and PUBLISHED becomes clear [13:13] Thanks [13:13] * NCommander vaguely wonders if we need a SUPERSEDED_BUT_STILL_PUBLISHED state :-) [13:13] * NCommander ducks [13:14] There is some argument that we should include superseded packages in the indices until they are removed. [13:14] That is easy to do, and possibly beneficial for a couple of reasons. [13:14] But it would require much thought. [13:14] plus it makes this trivial to solve [13:14] Right. [13:14] Well, not trivial. [13:14] well, mor estraightforward [13:14] But much easier: you just have to prevent judgeSuperseded from setting scheduleddeletiondate for the binaries that you want to keep. [13:17] 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] NCommander: Are you calling makeDistroArchSeries manually? [13:18] NCommander: distroseries.nominatedarchindep = [13:18] yes [13:18] What StevenK said. [13:19] If you aren't making a distroseries, you can fetch it by distroarchseries.distroseries [13:22] Unauthorized: (, 'nominatedarchindep', 'launchpad.Moderate') [13:22] Something tells me I can't just set that property directly [13:23] Ah. Use removeSecurityProxy [13:35] I've been able to in tests ... [13:35] StevenK: In ZopelessLayer, maybe. [13:48] Ah, yes [13:49] NCommander: The other thing you can do is fetch the admin from IPersonSet and run that as the admin [13:49] StevenK: is there a preference in test cases? [14:42] 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] 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] NCommander: Now that I've thought about it -- why? [15:05] 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] 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] NCommander: No, but we have the option to. [15:08] NCommander: However, yes, the BPR.depends field is to be trusted. [15:09] k [16:01] 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 ... === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away === almaisan-away is now known as al-maisan === al-maisan is now known as almaisan-away [20:39] 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 < https://launchpad.net/bugs/255024 > [20:52] Hrm. What could cause a commented bug not to appear in a user's commented bugs page? [20:53] 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). < https://launchpad.net/bugs/601539 > [21:23] wgrant: hi [21:23] wgrant: interesting [21:24] hey lifeless [21:24] maxb: wow, I'm blind now :) [21:26] cjohnston: hi [21:27] maxb: if message.owner is not them, though that would on the face of it not make much sense [21:27] or their message index is nonzero [21:28] there is a denormalised field in there [22:56] wgrant: rabbit test passes for me (but I haven't merged up with trunk yet) === cinerama_ is now known as cinerama [23:41] wgrant: who should get ppa build notifications (see bug 782924) [23:42] <_mup_> Bug #782924: Send e-mail notification when PPA builds are finished < https://launchpad.net/bugs/782924 >