| LPCIBot | Project db-devel build #551: STILL FAILING in 5 hr 28 min: https://lpci.wedontsleep.org/job/db-devel/551/ | 01:27 |
|---|---|---|
| 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:23 |
| wgrant | Yeah :( | 02:27 |
| lifeless | his only comment on lp | 03:02 |
| lifeless | poor dude, going to be annoyed noone replies ... | 03:03 |
| 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:09 |
| lifeless | StevenK: cool | 05:44 |
| 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:20 |
| wgrant | May back it out tomorrow. | 09:21 |
| wgrant | If lifeless doesn't kill me. | 09:21 |
| 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:22 |
| * StevenK tries to figure out how to run bzr-pqm tests. | 09:41 | |
| lifeless | wgrant: whats the fail ? | 10:01 |
| nigelb | launchpad people --> YOU ALL ROCK :) | 10:01 |
| 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:02 |
| === nigelb is now known as Guest58084 | ||
| === Guest58084 is now known as nigelb | ||
| 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:19 |
| lifeless | [locally, I mean] | 10:20 |
| lifeless | if that works, its buildbot specific in most probability | 10:21 |
| === nigelb is now known as Guest53049 | ||
| === Guest53049 is now known as nigelb | ||
| wgrant | lifeless: it breaks here. | 11:05 |
| wgrant | Let me try again, though. | 11:05 |
| 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:15 |
| wgrant | NCommander: "packages"? "creating"? | 12:16 |
| NCommander | wgrant: fake packages via the testing API | 12:17 |
| wgrant | What kind of packages? For what purpose? | 12:18 |
| NCommander | wgrant: for the archive any/all skew | 12:18 |
| NCommander | brb | 12:18 |
| wgrant | NCommander: Source? Binary? | 12:26 |
| 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:30 |
| NCommander | http://paste.ubuntu.com/607760/ | 12:31 |
| 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:32 |
| 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:33 |
| wgrant | https://dev.launchpad.net/Soyuz/TechnicalDetails | 12:34 |
| wgrant | You shouldn't have to go near PackageUpload* | 12:35 |
| 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:37 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| * NCommander writes the fake binary bit | 12:43 | |
| 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:08 |
| 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:09 |
| wgrant | And finds publications in the same series and archive at the other end. | 13:10 |
| 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:12 |
| 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:13 | |
| 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:14 |
| 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:17 |
| wgrant | NCommander: Are you calling makeDistroArchSeries manually? | 13:18 |
| StevenK | NCommander: distroseries.nominatedarchindep = | 13:18 |
| NCommander | yes | 13:18 |
| wgrant | What StevenK said. | 13:18 |
| StevenK | If you aren't making a distroseries, you can fetch it by distroarchseries.distroseries | 13:19 |
| NCommander | Unauthorized: (<DistroSeries u'lucid'>, 'nominatedarchindep', 'launchpad.Moderate') | 13:22 |
| NCommander | Something tells me I can't just set that property directly | 13:22 |
| wgrant | Ah. Use removeSecurityProxy | 13:23 |
| StevenK | I've been able to in tests ... | 13:35 |
| wgrant | StevenK: In ZopelessLayer, maybe. | 13:35 |
| StevenK | Ah, yes | 13:48 |
| 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? | 13:49 |
| 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:42 |
| 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 ... | 14:51 |
| StevenK | NCommander: Now that I've thought about it -- why? | 15:04 |
| 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:05 |
| 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:06 |
| StevenK | NCommander: No, but we have the option to. | 15:08 |
| StevenK | NCommander: However, yes, the BPR.depends field is to be trusted. | 15:08 |
| NCommander | k | 15:09 |
| 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:01 |
| * NCommander feels that STP sets up a lot of this ... | 16:02 | |
| === 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 | ||
| 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:39 |
| maxb | Hrm. What could cause a commented bug not to appear in a user's commented bugs page? | 20:52 |
| 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 > | 20:53 |
| lifeless | wgrant: hi | 21:23 |
| lifeless | wgrant: interesting | 21:23 |
| cjohnston | hey lifeless | 21:24 |
| lifeless | maxb: wow, I'm blind now :) | 21:24 |
| lifeless | cjohnston: hi | 21:26 |
| 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:27 |
| lifeless | there is a denormalised field in there | 21:28 |
| lifeless | wgrant: rabbit test passes for me (but I haven't merged up with trunk yet) | 22:56 |
| === cinerama_ is now known as cinerama | ||
| lifeless | wgrant: who should get ppa build notifications (see bug 782924) | 23:41 |
| _mup_ | Bug #782924: Send e-mail notification when PPA builds are finished <Launchpad itself:Incomplete> < https://launchpad.net/bugs/782924 > | 23:42 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!