[02:57] <wgrant> lifeless: Upgrading from fixtures 0.3.10 to 0.3.11 generates some garbage. Any ideas why?
[02:58] <wgrant> Tests generated new (2) garbage:
[02:58] <wgrant> [<io.TextIOWrapper object at 0x12781bec>, <io.BytesIO object at 0x1185392c>]
[02:58] <StevenK> wgrant: You've really been on an upgrade kick ...
[02:59] <wgrant> StevenK: Well, we're 3-4 years behind on most things
[02:59] <wgrant> Last week we upgraded Zope and YUI, this week I'm upgrading everything else.
[02:59] <StevenK> We weren't that far behind on YUI
[02:59] <StevenK> Maybe we need to downgrade to 2 or something
[06:43] <StevenK> containing_div_node.addClass('yui3-skin-sam');
[06:43] <StevenK> Which doesn't help
[06:43] <StevenK> Calendar, you're beginning to annoy me
[07:03] <lifeless> wgrant: garbage?
[07:13] <wgrant> lifeless: gc.garbage that remains after a gc.collect()
[07:13] <wgrant> Presumably due to reference cycles
[07:13] <lifeless> I don't know why that isn't collected, TextIOWrapper -> BytesIO is a one way ref.
[07:14] <wgrant> Yeah, that's what it looks like :/
[07:14] <wgrant> Maybe the TextIOWrapper is referenced elsewhere
[07:15] <wgrant> But then it shouldn't be garbage
[07:16] <czajkowski> Gooooooood morning
[07:17] <wgrant> Morning czajkowski
[07:29] <lifeless> wgrant: so the Q is can you reproduce it.
[07:29] <lifeless> Gnight.
[07:32] <wgrant> lifeless: It's easy to reproduce as part of a particular LP test, but I was going to check if you knew anything before isolating.
[07:32] <wgrant> Will do so
[07:34] <czajkowski> cjwatson: when you're about can you give me a shout please, I seem to have broken something on my machine and in need of your assitance, for this I shall send you cake and biscuits :)
[08:28] <cjwatson> czajkowski: Hi
[08:29] <cjwatson> wgrant: So, I think I ended up not using fmt:link here because an earlier version rendered a link for primary archives as well (and I've reverted to that version per your feedback) and there's no link implementation for Archives other than PPAs
[08:30] <cjwatson> wgrant: And as a result the TAL ended up being annoyingly cumbersome with fmt:link, rather than simpler as it's meant to be
[08:30] <wgrant> cjwatson: Oh, it just leaves primary archives unlinked?
[08:30] <wgrant> And copy archives too?
[08:31] <czajkowski> cjwatson: shall move to kernel and fill you in there
[08:31] <czajkowski> or is foundation better?
[08:31] <cjwatson> czajkowski: What's it about?
[08:31] <cjwatson> There's no foundations channel, intentionally
[08:31] <czajkowski> ahh
[08:31] <cjwatson> And I'm not a kernel developer, so I doubt that's appropriate :)
[08:31] <czajkowski> cjwatson: on start up this morning I'm http://ubuntuone.com/1REKSBU0jU7XITkpfBK0RQ
[08:32] <cjwatson> wgrant: Trying to use fmt:link on a primary archive raises NotImplementedError
[08:32] <wgrant> cjwatson: Well that's a bit crap.
[08:32] <cjwatson> wgrant: Maybe I should add a generic link implementation for archives that does <a class="sprite distribution" etc>?
[08:32] <wgrant> Yet easily fixed, and it probably makes sense
[08:32] <wgrant> Yeah
[08:33] <wgrant> Copy archives should probably use the PPA icon, but primary/partner can use the distro one
[08:33] <cjwatson> And we can use that for all other archives, and probably delete some insane TAL elsewhere
[08:33] <wgrant> They could even link directly to the distro
[08:33] <cjwatson> czajkowski: Nothing wrong with that - you might get the menu when you don't normally if a previous boot failed
[08:34] <cjwatson> But just press Enter and carry on
[08:34] <czajkowski> cjwatson: aye I did then I went to ubuntu advanced and moved down to recovery kernel. but no matter how many reboots I still up at that screen :/
[08:34] <cjwatson> recovery kernel won't count as a successful boot
[08:35] <cjwatson> the point of this is to show the menu when people seem to be having trouble
[08:36] <cjwatson> now, if you see it after a non-recovery boot, that's a bit odd and we can investigate in #ubuntu-devel
[08:37] <czajkowski> ahhhh
[08:37] <czajkowski> cheers cjwatson  :)
[08:45] <cjwatson> wgrant: Do <adapter /> directives in lib/lp/app/browser/configure.zcml magically pick the closest match somehow, or do I need to take inheritance into account?
[08:46] <cjwatson> Also, I happened to notice that https://bazaar.launchpad.net/~launchpad/+junk/dbpatches/view/head:/allocated.txt seems to be missing 2209-43-0
[08:47] <wgrant> cjwatson: It should pick the closest adapter
[08:48] <wgrant> So an IPPA adapter will override one for IArchive for PPAs
[08:51] <cjwatson> OK.  Though, hmm, I wonder how "closest" is defined given that IPPA is only done by alsoProvides
[08:52] <wgrant> Oh, true
[08:52] <wgrant> That's a good question...
[08:52] <cjwatson> Maybe it'd be clearer to turn PPAFormatterAPI into ArchiveFormatterAPI and do the checks explicitly
[08:53] <wgrant> Quite likely.
[09:03] <cjwatson> wgrant: Copy archive icon - using the PPA icon would be inconsistent with ArchiveImageDisplayAPI.icon ("ArchivePurpose.COPY: '/@@/distribution'").  Do you want that changed?
[09:08] <wgrant> cjwatson: I'd forgotten there was precedent, so go with that.
[10:03] <cjwatson> wgrant: Is there any precedent anywhere for what to do when trying to render a copy from an inaccessible private PPA?  The current version is 'Sync from <tal:archive content="source_archive/displayname" />, ...'; if I do the naïve thing and replace that with 'Sync from <a tal:replace="structure source_archive/fmt:link" />, ...', I end up with "Sync from , ..." in the output which is less than ideal
[10:22] <cjwatson> I guess something like SourcePublishingRecordView.linkify_source_archive
[10:43] <wgrant> cjwatson: For private teams we say <redacted>, IIRC
[10:43] <wgrant> Should probably do a similar thing here.
[10:43] <cjwatson> At the moment I think we must show the archive displayname
[10:44] <cjwatson> But I suppose arguably that's wrong
[10:45] <cjwatson> Perhaps also "Building private job" as precedent
[10:45] <wgrant> Yeah, maybe
[10:45] <cjwatson> So it's tempting to say "Sync from private archive"
[10:46] <wgrant> Indeed
[11:06] <cjwatson> wgrant: OK, would you mind re-reviewing https://code.launchpad.net/~cjwatson/launchpad/queue-copy-archive-links/+merge/159250 ?  I know you approved already, but the changes are fairly substantial.
[11:07] <cjwatson> I suspect I'll have some doctest damage, which I'll let EC2 catch
[11:19] <wgrant> cjwatson: That looks fine. Thanks.
[11:25] <cjwatson> Now, I wonder why my EC2 setup is busted ... http://paste.ubuntu.com/5715669/
[11:37] <wgrant> cjwatson: Seems to be a change in python-boto. http://paste.ubuntu.com/5715687/ seems to fix it
[11:37] <cjwatson> Hm, the python-boto package hasn't changed since last May
[11:38] <cjwatson> I wonder if it's an EC2 change tickling an existing bug
[11:38] <wgrant> Could be
[11:38] <wgrant> I use it so infrequently that I didn't bother to do more than hack it to work.
[11:51] <cjwatson> wgrant: Much better, thanks
[16:11] <cjwatson> Grr, these failures didn't show up in ec2, probably because the test runner there apparently hung :-/
[16:12] <cjwatson> Oh well, should be easy enough to fix
[16:48] <cjwatson> https://code.launchpad.net/~cjwatson/launchpad/queue-copy-archive-links-testfix/+merge/159442 - test fixes, could use a review