[00:00] jml: and we don't allocate karma for packages [00:00] thumper, ahh ok. [00:00] jml: so at least three separate problems [00:00] thumper, where does the allocator live? [00:00] thumper, I'd be interested to figure out why I missed it. [00:00] we are failing due to revision that are in project branches and package branches [00:00] and the package branch is found first [00:00] so being skipped [00:00] now we are skipping 100 at a time [00:01] and selecting the same 100 every select [00:01] lp.code.scripts [00:01] thumper, I guess I mean, where was it a year ago :) [00:01] jml: probably scripts [00:01] * thumper shrugs [00:03] jml: branch just got an is_junk attribute [00:03] :( [00:03] jml: frowny for what? [00:03] thumper, I think it's better to say why you care if it's junk. [00:04] jml: I say where it is being checked [00:05] jml: but instead of checking either that the target is the owner, or checking product and distroseries [00:05] thumper, yeah, but you could give it a name in code, separating the fact about whether it belongs to a project from how we count karma. [00:05] thumper, certainly it's a step up from that. [00:05] thumper, why not check if the target provides karma for revisions? [00:05] mmm... [00:06] it's what we already do for MPs etc. [00:07] jml: heh [00:07] jml: BranchTarget already has assignKarma [00:08] although [00:08] ... [00:08] nm [00:41] :( [00:43] thumper, wassup? [00:43] test_karmaDateForFutureRevisions passes, but for the wrong reasons [00:44] the revision karma stuff is a bit of a mess [00:45] thumper, it's good to spot it though, and then also to have the opportunity to fix it there & then :) [00:45] yeah [00:45] all this fixing to make the karma revision script run successfully again [00:54] thumper: karma for yak shaving? [00:54] ✁☹ [00:54] I'd say that's a yes then.. :-) === chris|| is now known as chris| [01:40] * jml is off to lunch & errands. [01:52] phew [01:52] I think that is the revision karma issue dealt to [01:52] mwhudson: feel like a review? [01:52] thumper: sure [01:52] * thumper pushing now [02:03] mwhudson: proposed, email arriving soon [02:13] thumper: looking now [03:21] mwhudson: thanks for the review [03:21] mwhudson: I've just finished clearing the code import queue [03:21] mwhudson: there were a lot of imports that needed tweaking [03:22] probably 75% of them [03:22] https -> http [03:22] and missing /trunk [03:22] and bad certs [03:22] invalid locations [03:32] thumper: yeah :( [03:49] wow, the failure mode of the multi-line editor isn't very good [04:13] * thumper afk - bbl [04:17] * mwhudson eods [04:25] * jml errands [07:49] hi adiroiban! did you manage to get through the delegates stuff? :-) [07:54] Hi folks! I have a question: I'm looking for the latest translation tarball for cupsys for Hardy on launchpadlibrarian. According to the api it's this one: https://launchpadlibrarian.net/34788059/cupsys_1.3.7-1ubuntu3.6_amd64_translations.tar.gz , but it seems to have been garbage-collected. Isn't the latest version to be kept around? Could someone help me to find out what happened here? [07:55] The upload was on 2009-11-09, btw. [07:55] ArneGoetje: looks like the soyuz folks aren't here yet :( [07:55] jtv: thanks... will try again later [08:04] ArneGoetje: I think I know what the problem is. [08:04] Those files weren't unembargoed. [08:04] So they're still sitting on the restricted librarian. [08:04] wgrant: 'unembargoed'? [08:04] You could ask a member of the security team to get it for you, if you need it quickly. [08:05] ArneGoetje: Security uploads are uploaded to a private PPA first. [08:05] They build there. [08:05] Then they are copied into RELEASE-security in the public Ubuntu archive, and their files are made public. [08:05] (private PPA files are normally stored in a special librarian instance, not accessible to the public) [08:05] I'm checking the code now, but I suspect that custom uploads (like translations tarballs) are not moved across. [08:06] wgrant: aha... so, they should appear whenever the cupsys package hist hardy-security? [08:06] s/hist/hit [08:06] ArneGoetje: *should*, yes. But they haven't, because of this bug. [08:06] wgrant: bug? [08:10] ArneGoetje: Normal sources and binaries are moved from the restricted to the public librarian when a package is copied from the security P3A. But custom upload files are not. This is a bug, which I am filing now. [08:12] ArneGoetje: Also, those tarballs aren't expired at all yet -- even really old ones should still be there somewhere. [08:13] wgrant: got it. Thanks. [08:18] Bug #503258 [08:18] Bug #503258: Custom upload file privacy not updated [08:18] It'll take some refactoring to fix. [08:26] g'night all [08:57] Morning [09:07] oh, hi mrevell, hi henninge! [09:07] hi jtv! [09:15] good morning [09:19] Good morning henninge and adeuring [09:19] hello jtv [09:19] hi al-maisan! [09:19] Hallo al-maisan und adeuring! ;) [09:19] hi henninge! [09:29] jtv: I saw Francis' approach went into a completely different direction than just picking a permission. What did you end up with? [10:35] hi al-maisan! [10:35] hello jtv! [10:35] henninge: creating a new object [10:36] henninge: instead of making IProduct, IProject & IDistribution inherit from IHasTranslationGroup, we'd have an adapter to give access to the translation group reference & access model: IHasTranslationGroup(ubuntu).translationgroup [10:37] henninge: the object that the adapter produces delegates its two attributes to its context, so it's basically a 3-line class. [10:37] and then for IHasTranslationGroup we can have Edit permissions [10:38] jtv: cool, I want to do something like that to add "is_admin" etc. attributes to persons without blowing up the IPerson interface even further. [10:38] but I am not sure the blowing up is really an issue here. [10:39] well, we have ITranslationsPerson now [10:39] (gah, fsck still not done) [10:39] jtv: where, has it landed? [10:40] henninge: ages ago, no? [10:40] jtv: oh, I was not aware of it. Lemme look what it is. [10:40] lp.translations.interfaces.translationsperson.ITranslationsPerson [10:41] just "the Translations aspects of Person" [10:41] ...and also done as an adapter. [10:41] jtv: ah, cool [11:10] Morning, all. === mpt_ is now known as mpt [11:19] hi deryck [11:20] bigjools: ArneGoetje couldn't find a particular package's translations tarball (in hardy, I think) that we think should be in the librarian. Can you help? [11:20] jtv: TranslationsPerson doesn't do the delegation you describe for IHasTranslationGroup. Do you have an example for that? [11:21] henninge: no, these two things are completely unrelated (apart from the adapters) [11:21] henninge: TranslationsPerson is "the Translations aspects of Person." [11:21] jtv: not right now, can I get back to you later [11:21] jtv, bigjools: Bug #503258 [11:21] Bug #503258: Custom upload file privacy not updated [11:21] henninge: IHasTranslationGroup is the part where we discussed design with Francis. [11:21] bigjools: thanks [11:22] jtv: I am aware of that. [11:22] wgrant: groan :( [11:22] bigjools: Yeah, it's not a really easy fix. [11:22] henninge: oh, I misunderstood then... what was the connection supposed to be? [11:22] wgrant: why do you say that? [11:23] jtv: when you say "delegates", I understand that that the object the adapter produces has all the attributes of the original object plus the IHasTranslationGroup attributes, right? [11:23] ArneGoetje: see wgrant's note... bug 503258 may be related to your problem [11:23] Bug #503258: Custom upload file privacy not updated [11:24] henninge: ah! no, the object provides only IHasTranslationGroup (with those 2 attrs) [11:24] it implements _those_ by delegating to its context—either Distribution or Product or Project. [11:24] jtv: ok, so it is a normal adapter [11:24] I see [11:25] bigjools: Things will need to be shuffled around, since the code that does the privacy updating only knows about the [SB]PPH. [11:25] So it's not hard, just not as trivial as it would seem from the description. [11:25] right [11:26] * bigjools hopes the phone line holds up to the snow here [11:27] wgrant: what is the manifestation of this problem? [11:28] the publisher will still work fine [11:28] bigjools: Translation tarballs for security updates are inaccessible, which makes ArneGoetje sad. [11:28] inaccessible by what means? [11:28] bigjools: The URLs exposed through the API and +queue. [11:28] oh, this is the thing we did recently [11:29] the new custom type that only sits in the libraria [11:29] n [11:29] No, no. [11:29] This is boring old raw-translations that has been around for years. [11:29] But it also affects the new raw-translations-static, yes. [11:29] raw-translations will be in the archive [11:30] In a processed form, yes. [11:30] er, it doesn't do any processing? [11:30] Don't they go into rosetta, which then produces langpacks? [11:31] the only place that won't be able to see them is the UI [11:31] scripts will be fine [11:31] but anything that is uploaded is placed in the archive verbatim [11:32] Custom uploads aren't. [11:33] DDTP/dist-upgrader/d-i are extracted, normal translations are sent to rosetta, and static translations just live in the librarian. [11:34] I'm not sure for what purpose a raw-translations tarball is useful, but raw-translations-static is certainly useful, and regardless this is a bug. [11:35] I still don't understand where the problem is [11:36] basically because I don't know much about translations [11:37] It's a bug regardless of whether there is a use for the translations tarballs. https://edge.launchpad.net/ubuntu/hardy/+queue?queue_state=3&queue_text=redhat-cluster&start=90, expand the bottom upload, and look at the URLs produced for the translations tarballs. === matsubara-afk is now known as matsubara [12:34] noodles775: Since you seem to be amassing quite a collection of corrupt builds, do you have any idea what happened to the single build on https://edge.launchpad.net/~mudlet-makers/+archive/ppa/+builds?build_state=building? [12:35] * noodles775 looks [12:39] wgrant: nope - but it looks dangerous (thinks it's building but doesn't have a builder associated with it's buildq entry.) [12:40] The state looks similar to bug 499421 (for which we haven't yet determined the cause) [12:40] Bug #499421: Build farm grinds to a halt with inconsistent build [12:40] noodles775: Right, that's why I brought it up. [12:40] It's all rather broken :( [12:41] I'm guessing that it's date_started is still null (hence not causing the bf to collapse). [12:41] Yes, it is... we had some large branches go in last cycle which didn't get enough dogfooding, I think. [12:42] It has a date_first_dispatched, but it doesn't look like the Job is accessible through the API. [12:44] Nope. I'm looking through retryDepWaiting atm (for bug 499421 - as it seems to be a commonality for those examples of corrupt builds). [12:44] Bug #499421: Build farm grinds to a halt with inconsistent build [12:45] erm, 499095, that would be. [12:48] noodles775: It doesn't look like any of those three depwaited. [12:48] Do you have evidence that they did? [12:49] wgrant: the two builders listed on the build page (one is from build.builder, the other from buildqueue.builder). [12:49] * noodles775 rechecks *when* build.builder is set. [12:50] * wgrant is really not a fan of this data model. [12:52] The buildqueue entry is only temporary, the build records which builder *built* the package as a permanent record. And yes, it'd be unreal to have the time to refactor a lot of this. [12:52] Yep. [13:02] noodles775: I find it suspicious that it looks like they all ended up GIVENBACK. [13:02] And the response for a GIVENBACK build isn't particularly sane. [13:03] Although it does set the status properly :( [13:03] Oh. [13:03] Maybe not. [13:03] Hmm. Two statuses == confusing. [13:08] wgrant: the raw-translation tarballs are useful for us Ubuntu Translation Coordinators to figure out why certain templates and .po files have not been imported into Rosetta. Instead of rebuilding the package from source and stripping out the translations by ourselves, we just need to download the raw-translation tarball and get everything like Rosetta sees it. [13:08] bigjools: ^^ [13:08] wgrant: Yeah, we're definitely not setting the job's status properly (afaics), but I hadn't noticed the GIVENBACK - I'll look more closely after lunch (ping me if you find anything more - or add a comment on the bug, thanks!) [13:08] noodles775: I'm poking around to work out how this new job stuff works (or doesn't). [13:09] great. === mrevell is now known as mrevell-lunch [14:10] HELP: I need help with a branch. I am exposing an wsop parameter over the API, except that my tests show that it does not work--the arguments are ignored. [14:18] * al-maisan wonders what an "wsop parameter" is..? === mrevell-lunch is now known as mrevell === mrevell changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 1 of 10.01 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes [14:40] EdwinGrubbs: skype? [14:40] sinzui: it's on. can you see me now? [14:41] EdwinGrubbs: I do see you === carlos_ is now known as carlos [14:53] jtv: TestTranslationsImport.test_handle_serious_error and test_handle_unexpected_exception are leaving a dirty environment-- they're causing errorlog.globalErrorUtility to be reconfigured. === matsubara is now known as matsubara-lunch [14:55] abentley: sorry for the trouble... looking it up now, but will have to go soon [14:55] jtv: I'm motivated to fix it, but I'd like your idea of the best fix. [14:55] jtv: What [14:56] jtv: What's happening is the tests are calling main() on a script. [14:56] abentley: isn't that the right one to invoke? [14:56] jtv: And scripts, because they expect to run in an empty environment, set the error handling up. [14:57] ah, I thought that was all nicely isolated in self.logger [14:58] jtv: You thought the test runner would be resetting the error handling? [14:59] abentley: no, I thought the script's error handling setup wouldn't mess with global state. :-( [14:59] jtv: I think it's reasonable to expect scripts to mess with global state. But we could patch this one by just doing addCleanup. [15:00] jtv: I usually run scripts in a subprocess to better mimic the conditions they'll run in. [15:00] abentley: yes, but I do minimize that because it's incredibly expensive. [15:01] I once sped up the test suite by several minutes just by reducing the number of script runs in one test. [15:01] jtv: So I think our options are: 1. run in a subprocess, 2. addCleanup, 3. run something other than main, 4. take the error handling setup out of main [15:02] abentley: is the setup really done in main though? [15:02] as opposed to the LaunchpadScript constructor? [15:02] jtv: po_import.py:142 [15:05] abentley: ahhhh, _that_ [15:05] the oops logging [15:06] would it be terribly evil to add a "kill switch" that suppresses it in tests? [15:06] similar to test_args [15:08] jtv: I could live with that, but I think we can probably stick it into the standard setup. [15:10] abentley: for all scripts, you mean? I guess we could just reuse the script name we pass to the LaunchpadScript ctor anyway... [15:11] jtv: No, I mean that the import script could reimplement LaunchpadScript.run to set up the oops handling first. [15:12] oic === salgado is now known as salgado-lunch [15:12] abentley: maybe there is already some appropriate callback in LaunchpadScript to stick this in? [15:13] jtv: There doesn't seem to be a setUp/tearDown pair, if that's what you're thinking. [15:13] well we wouldn't even need a teardown if we can elide it altogether [15:14] something similar to _init_zca and _init_db [15:15] do you think anybody would do a run() in-process from a test? If not, run() could also just initialize this regardless [15:15] jtv: My reading is that there's no setUp -- LaunchpadScript.run serves that purpose. [15:16] jtv: I think that run() from a test would fail horribly, because it would leave a very dirty environment. [15:16] jtv: I think it's fine to do it always in run. [15:17] abentley: iirc I copied all this from one of your scripts in the first place, so that script might be affected as well :-) [15:18] jtv: With the difference that I didn't *expect* calling main() to work :-) [15:19] abentley: with this change, future generations will look at _your_ tests and ask "wtf didn't he just call main()?" :-P [15:23] jtv: I don't think so. I have about two integration tests, and the rest are unit tests. [15:31] jtv: is this ok to change the browse/configure.zcml in this way http://paste.ubuntu.com/351825/ ? [15:31] i don't know where to plug the adapters and delegates in the current LP setup [15:32] adiroiban: a separate IProductTranslationPolicy..? [15:32] jtv: i'm lost [15:33] if I will leave IProduct, how can I check the special permission with launchpad.Edit? [15:34] ahh [15:34] unfortunately right now I'm way too tired to think about new problems! [15:34] jtv: ok. np. we can talk tomorrow morning [15:35] the adapter part is easy: you basically say in zcml that the class is the factory for the objects—search for "adapter" [15:35] yes, talk tomorrow... but definitely thanks for working on this! [15:35] np [15:36] the adapters should go in lp/translations/adapters.py ? [15:36] bigjools, hello :) happy new year [15:36] there is no adapters.py for translations [15:37] Ursinha: Happy new year! === beuno is now known as beuno-lunch [15:37] bigjools, :) [15:37] bigjools, well, I have one oops... :) [15:37] bigjools, https://edge.launchpad.net/~mudlet-makers/+archive/ppa/+build/1376913 is oopsing, seems to be bad data [15:37] doesn't surprise me [15:38] jtv: let's leave this for tomorrow [15:38] noodles775: ^^ [15:38] bigjools, https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1462F51 [15:38] adiroiban: thanks for understanding :-) === jtv is now known as jtv-zzz [15:39] bigjools: yes, I saw it earlier (wgrant pointed it out), it's another building build without a bq.builder. [15:39] ok thanks [15:39] henninge: can you take a quick look at bug 340664 (screenshots) and tell me is this is how the bug should be fixed ? [15:39] Bug #340664: Add administration page for all POTemplates in ProductSeries or DistroSeries [15:39] adiroiban: looking [15:41] adiroiban: it is possible that this book was overlooked when implementing +templates. [15:42] abentley: gotta go now... thanks for cleaning up my mess, and repeated apologies for making it! [15:42] henninge: i don't know the story (history) behind +templates [15:42] jtv-zzz: no problem. [15:43] I just saw this is a high priority bug [15:43] and tried to nail it [15:43] adiroiban: cool, so you'll just have to add more columns to the table, right? [15:44] I added the one that can we seen in the screenshot [15:44] adding columns is easy... [15:44] ;) [15:44] bigjools, noodles775, should I open a bug for that oops or there's one already? [15:44] making +templates not die in Ubuntu is the hard part [15:44] but I assume this is another bug [15:45] Ursinha: I haven't seen a bug for it yet, so that would be great. Thanks. [15:45] adiroiban: well, I tried to fix that before but I guess it needs some more work. [15:46] Ursinha, noodles775: wait, we have plenty already? [15:46] adiroiban: anyway, for this but I am just not sure if Priority is really used much. Do you know if people actually use it? Why did you putit to the front? [15:46] s/but/bug/ [15:46] bigjools, not really, I saw one in jan 1st === deryck is now known as deryck[lunch] [15:47] sinzui: you're missing a "d" for created_after and created_before. [15:47] what I mean is, we already have bugs covering this issue [15:47] bigjools: for that situation? I haven't seen one? (ie. the bq.builder is empty, buildstate is BUILDING but it's not causing 449421 as the date_started (i'm guessing here) is still null). [15:48] * sinzui plants hand in face [15:48] EdwinGrubbs: Thank you for pointing my incompetence. [15:48] henninge: in my current state I shouldn't comment on bugs, but credits cleanup completed 2009-12-24... if there is still a problem, then that is indeed a new bug [15:48] bigjools: But maybe it's an older issue? - I haven't looked further than the 2 current bad build data bugs. [15:49] * henninge whispers in jtv-zzz's ear, so not to wake him but to appear in his dreams: [15:49] Why hasn't edge updated in several week? [15:49] I'll watch it... [15:49] noodles775: ok let's check the prod data to see what state it's in [15:50] henninge: :) [15:50] oh how cute, he smiles in his sleep ! [15:51] :) [15:54] * sinzui suspects that mrevell is trying to get more karma then sinzui [15:54] sinzui, haha, you've discovered my plan :) [15:55] mrevell: you can win the karma race by fixing the status and priority of the hundreds of old blueprints that claim to be High and inprogress === matsubara-lunch is now known as matsubara [16:11] where would I find the tests for ./scripts/ftpmaster-tools/sync-source.py ? [16:18] james_w: hahahaha [16:19] thought so [16:21] sinzui: Did you request / start an update for edge? It's become awfully slow for me. [16:22] henninge: no. I was asking why edge is more than a week old [16:22] * sinzui cannot do QA testing [16:23] sinzui: while you are not QAing, do you have a few minute for a pre-imp conversation? [16:23] henninge: yes [16:24] sinzui: cool [16:25] sinzui: I'd like to implement this: http://paste.ubuntu.com/351849/ as an adapter on IPerson. [16:26] sinzui: The adapter the adapted object would be passed to the checkAuthenticated methods in security.py as the user paramter (instead of an IPerson). [16:27] henninge: I like your proposal [16:28] Does it need to be extended to support private bugs and branches? [16:29] sinzui: I don't understand. [16:30] ? [16:31] sinzui: I don't understand? [16:31] henninge: Access control to a private object may require tests like: isBugSupervisor(obj), isBugSubscriber(), isBranchSubscriber() [16:32] sinzui: oh, it can be extended for other needs, I don't mind that. [16:33] henninge_: I image that this class would be near ILaunchpadCelebrity [16:33] sinzui: OTOH the person object remains accessible through the picon attribute [16:34] sinzui: yes, I am not sure if it is really part of registry of foundations. [16:34] s/of/or/ [16:34] s/picon/person/ [16:35] how did that word get inthere ... ;) [16:35] henninge_: this object crosses boundaries. We do not want lp/registry person to know about celebrities which is the lp/app. === beuno-lunch is now known as beuno [16:36] henninge_: My real concern is not where the code is, but that we need this object synced with LaunchapdCelebrity [16:36] sinzui: I see. I was going to put that in the tests. [16:36] sinzui: whenever a Person celebrity is added or removed from LPCelebrity, the test fails. [16:37] henninge_: I this PersonMembership is too ambiguous. This class is a security helper for celebrities [16:37] sinzui: "PersonCelebrityHelpers" ? [16:39] sinzui: some automatic relationship to LPCelebrities could be possible, too. [16:39] I think IPersonCelebrity will do [16:39] sinzui: ok, I am fine with that. [16:40] sinzui: although the methods in the interface don't deal with celebrities at all. [16:40] I cannot think how to test that a property added to ILaunchapdCelebrity has a counterpart in IPersonCelebrity [16:41] sinzui: there is PersonCelebrityDescriptor that counts Person celebrities in a class attribute. [16:41] henninge_: okay [16:41] lists them, even. === henninge_ is now known as henninge [16:46] sinzui: I'll file a foundations bug about it, I think. [16:46] henninge: the methods are fine for the name, but a better name might be IPersonRoles. [16:46] good one! [16:47] regarding bug #385517 does this require a (to be) updated version of launchpadlib or can it be used with the current version? [16:47] Bug #385517: launchpadlib users made to authenticate unnecessarily [16:47] sinzui: but wait, weren't there plans for "roles" in Launchpad? [16:47] henninge: I has proposed IRole in the past as a way to mange predefined roles in launchpad, and as a way to let users create arbitrary roles. They include owner and driver, but might also include designer [16:48] sinzui: oh, so this is going in a very similar direction. [16:48] yes [16:49] sinzui: I am glad you like it. I'll put it in a bug. It should not be too hard to implement. (Famous last words) [16:50] Do you have an immediate use? [16:50] sinzui: I want to get rid of the permission_helpers.py file that I introduced two branches ago before others start accumilating stuff in there ... ;) [16:51] accumulate? [16:51] ah [16:51] so this really is a tech-debt thing === salgado-lunch is now known as salgado === deryck[lunch] is now known as deryck [17:06] sinzui: cheers, it's bug 503454 [17:06] Bug #503454: Make checks for celebrity persons and roles easier [17:13] henninge: I tagged the bug with tech-debt to give it more justification to work on now [17:13] sinzui: thanks, I'll be quick ;) [17:39] is there no way to tell shhh.py to get out of the way? [17:40] ah, I can tell make not to use it [17:41] I'm getting a sh: apr-1-config: not found error when I run rocketfuel-get, anybody know what can I do to fix it? (pastebin: http://pastebin.ubuntu.com/351886/) [17:43] matsubara: you probably need to install libapr1-dev [17:57] james_w, installing libapr1-dev solved the problem. thanks! [17:57] np [18:01] night all [18:25] abentley, hi [18:25] rockstar: Hi [18:25] Have you ever had problems calling create_branch_and_tree twice in the same test? [18:26] rockstar: I don't think so. [18:26] abentley, I'm seeing where it tries to create the tree on top of the already created tree. [18:27] rockstar: Are you specifying a tree location? [18:28] abentley, no, and looking at the code, I 'spose I should. :) [18:28] rockstar: I think that would resolve this problem. [18:29] rockstar: Maybe we should use pseudo-random tree names instead of '.' by default? [18:29] abentley, yeah. I expected it to create its own dir to put the tree in. Maybe we ought to modify it to do that. [18:29] abentley, great minds think alike? [18:29] (and then I play catch up?) [18:31] rockstar: Yeah. I think I was apeing the Bazaar testing methodology too closely when I did that. [18:32] rockstar: doing that now may break a lot of tests, but I suppose we can rewrite them easily enough. [18:32] abentley, hm, maybe I should re-think that approach then, and just make my test pass. [18:33] rockstar: rewriting those tests would mean supplying an explicit '.' [18:34] abentley, yeah. :) [18:35] abentley, I'm just trying to minimize the changes I make in this branch. [18:35] rockstar, abentley, are you aware that +code-import-list is oopsing? [18:35] Ursinha, I am now. [18:35] https://code.edge.launchpad.net/+code-import-list [18:35] Ursinha, eep. [18:37] rockstar, care to take a look? [18:37] Ursinha, I think I have a good idea. [18:38] Ursinha, is there a bug filed? [18:39] rockstar, there is now: bug 503479 [18:39] Bug #503479: +code-import-list OOPSing with AssertionError [18:55] * rockstar locates food [19:51] good morning [20:08]