[02:21] <maxb> wgrant: I don't have ~launchpad/ppa but given it has nothing published for karmic, that shouldn't matter
[02:21] <maxb> meh
[02:22] <maxb> oh well, I can either treat this as cause to dig into the code, or I can treat those as known failures regradless and start trying to get some of my extant changes landed
[02:22] <wgrant> maxb: I have the ~launchpad/ppa's jaunty enabled.
[02:23] <wgrant> maxb: Let's see what I have installed from there...
[02:23] <maxb> hmm
[02:33] <maxb> lxml and setuptools updates, it looks like
[02:47] <wgrant> maxb: Something like that. It's hard to tell what's from which PPA.
[02:47] <wgrant> After activating those PPAs, I upgraded, installed python2.4 and python-celementtree, and built LP.
[02:47] <wgrant> And it all magically worked.
[02:47] <poolie> hello wgrant
[02:47] <wgrant> Hi poolie.
[02:48] <wgrant> poolie: That's a strange hostname for you...
[02:50] <poolie> mm
[02:50] <poolie> i'm at coscup.org
[02:50] <poolie> in Taipei
[02:51] <wgrant> poolie: Ahh.
[06:19] <wgrant> Nice new footer.
[11:23] <wgrant> Is launchpad-buildd still part of RF? The version there is rather old. I'm wondering because it doesn't work properly with karmic as a host, and it'd be best to fix a non-obsolete version...
[12:46] <cprov-afk> wgrant: yes, it is (lib/canonical/buildd).  It probably doesn't work for karmic as it is, I have a patch from Adam.
[13:03] <wgrant> cprov-afk: Right, I know it's there, but from what I've seen there have been a few changes in production since the version in LP.
[13:04] <cprov-afk> wgrant: yes, 3 new versions IIRC. I'm pushing a branch, so you can check.
[13:07] <cprov-afk> wgrant: lp:~cprov/launchpad/lp-buildd-karmic
[13:07] <wgrant> cprov-afk: Ah, excellent. Thanks.
[13:07] <wgrant> Everything else is now working perfectly on karmic.
[13:08] <cprov-afk> wgrant: re. bug #413922, it does render correctly (somehow), right ?
[13:08] <mup> Bug #413922: "supported version of Ubuntu" link on ArchiveActivateView broken <Soyuz:In Progress by cprov> <https://launchpad.net/bugs/413922>
[13:08] <cprov-afk> wgrant: it's just a misleading TAL instruction.
[13:09] <wgrant> cprov-afk: It renders a link to something like '/~person/<a href="https://launchpad.net/ubuntu>Ubuntu</a>'.
[13:09] <wgrant> So no, it doesn't work.
[13:09] <wgrant> edge is really out of date -- it was broken in the 3.0 migration.
[13:10] <cprov-afk> wgrant: oh, f.. yes, edge is old.
[13:10] <wgrant> Really old.
[13:11] <cprov-afk> wgrant: ha, staging is up.
[13:12] <wgrant> Barely..
[13:12] <wgrant> The problem is indeed visible there.
[13:12] <cprov-afk> wgrant: right ... works for this specific prob.
[13:13] <wgrant> Along with a conflict between the 2.0 and 3.0 styles, which should be fixed once person-ppas is 3.0ised.
[13:24]  * cprov hides somewhere.
[13:25] <wgrant> I suspect this new lp-buildd will fail in a similarly obscure way, but let's see...
[13:40] <wgrant> cprov: Ah, interesting. That fixed the particularly confusing problem, although it still doesn't quite work without a patch.
[13:41] <wgrant> (dpkg-source's output changed recently. Debian's sbuild was patched to no longer parse its output 18 months ago, but this sbuild seems muuuch older than that.)
[13:45] <maxb> Why does the dev setup use two different IP addresses? It appears to just be in support of running bazaar.launchpad.dev on a separate IP - why is that?
[13:47] <wgrant> maxb: the bazaar vhost is completely different from the others.
[13:47] <wgrant> But it still needs SSL.
[13:47] <wgrant> And SSL doesn't do multiple vhosts on one IP address.
[13:47] <wgrant> (unless you use SNI, which Ubuntu doesn't support yet)
[13:49] <maxb> Why does the bazaar vhost need SSL?
[13:49] <maxb> http://bazaar.launchpad.net/ seems perfectly happy to talk to me
[13:49] <wgrant> Because it does in production, to protect cookies.
[13:49] <maxb> Oh, loggerheading of private branches?
[13:49] <wgrant> (for private codebrowse)
[13:49] <wgrant> Right.
[13:50]  * maxb is attempting to make
[13:50] <maxb> oops
[13:50]  * maxb is attempting to make dev.lp.net/Running/RemoteAccess saner, and would be happy to drop the requirement for multiple IPs
[13:50] <wgrant> Maybe in a release or two.
[13:51] <maxb> Well, dev.lp.net/Running/RemoteAccess is a bit of a hack anyway :-)
[13:51] <wgrant> Indeed.
[13:52] <wgrant> maxb: Still no luck with getting tests to pass?
[13:52] <maxb> Nope, I think it's dig-into-the-code time
[13:52] <wgrant> Damn.
[13:55] <maxb> I just need to decide whether I do that now, or just ignore those two tests and press on with landing some of the py2.5 changes I've already accumulated
[13:56] <maxb> Switching topics: Is there a statement from Canonical explaining its rationale in choice of license for Launchpad icing/images?
[13:57] <wgrant> kfogel might have mentioned it in a comment on a blog post, but I don't recall anything official.
[13:57] <wgrant> Although it's pretty obvious why.
[13:57] <maxb> Well, there's multiple aspects and it's not entirely obvious.
[13:58] <wgrant> That's true. I can think of two big ones.
[13:59] <maxb> For example, I'd love to use Malone for both non-profit private projects, and attempt to convince my company to use it.
[13:59] <maxb> Neither of those are ever going to be revenue stream for Canonical, nor damage Launchpad's cohesive one-place-for-OSS position
[14:00] <wgrant> The second could be a revenue stream, if companies get on the ooh-cloudy bandwagon.
[14:00] <maxb> If I can't do those, it would be nice to know why exactly :-)
[14:00] <maxb> My company will never buy into putting its bugtracking info on a 3rd party server