[00:36] <wgrant> sinzui: Did you typo your MUA's display name?
[00:36] <wgrant> You've lost your capital "c"
[00:40] <wgrant> sinzui: Nice presentation.
[00:57] <poolie> wgrant: ?
[00:57] <poolie> i filed https://bugs.launchpad.net/launchpad/+bug/812597
[00:57] <_mup_> Bug #812597: gina imports from debian arrive too slowly <gina> <udd> <Launchpad itself:Triaged> < https://launchpad.net/bugs/812597 >
[00:59] <wgrant> poolie: It would only be 7 hours if Debian decided to shift their publishing schedule to right after gina runs.
[00:59] <wgrant> They still only publish every 6 hours, AFAIK.
[01:00] <poolie> i see
[01:00] <poolie> and we're pretty sure we're in sync with that?
[01:00] <StevenK> It requires checking
[01:00] <wgrant> The current schedule was devised to run just after they published.
[01:00] <wgrant> But they like to change.
[01:00] <wgrant> Without telling anybody.
[01:13] <persia> Doesn't Debian have a push-mirror feature for some mirrors that runs right after publication?  Could one host a mirror, and then use post-mirroring hooks to call gina at the right times?
[01:14] <StevenK> wgrant: The amount of QA to do makes me sad.
[01:58] <huwshimi> hmm... is there any way to test emails on qa staging?
[01:59] <lifeless> yes
[01:59] <lifeless> for in you need losa to run the script by hand
[01:59] <lifeless> for out you also need to run the relevant script by hand
[02:00] <lifeless> but then you can access the shared mailbox to see what was sent out
[02:02] <wgrant> sinzui: Anything to watch out for in oneiric atm?
[02:02] <lifeless>  dev/run, ecryptfs were fragile recently, may not be totally sorted yet
[02:02] <lifeless> wgrant: what presentation ?
[02:03] <wgrant> lifeless: sinzui's velocity presentation from the Prague epic.
[02:03] <lifeless> ah yes
[02:03] <lifeless> +1
[02:03] <wgrant> I use LUKS rather than ecryptfs, because it's flaky and slow.
[02:04] <huwshimi> lifeless: Ok, I would like to get a notification of a tag change from a bug. What scripts do I need to run? Is there a wiki page for this?
[03:12] <wgrant> StevenK: QA!
[03:12] <StevenK> wgrant: I have a better idea. LUNCH!
[03:12] <wgrant> I was just doing a pre-lunch QA check myself.
[03:12] <StevenK> I shall update mawson now. And then break for lunch.
[03:13] <wgrant> Thanks.
[03:13] <wgrant> Huh.
[03:13] <wgrant> Julian used one of Job's YAGNI columns.
[03:13] <StevenK> Indeed
[03:14] <lifeless> which one ?
[03:14] <StevenK> requester
[03:39] <wgrant> Hm.
[03:39] <wgrant> Has someone decided to show the battery indicator at all times in oneiric? :(
[03:39]  * wgrant blames thumper.
[03:39] <thumper> heh
[03:39] <thumper> wgrant: not me though
[03:39] <thumper> but at least I have a battery indicator now
[03:39] <wgrant> Bah.
[03:49] <wallyworld> thumper: global menus fixed yet?
[03:49] <thumper> nah mate
[03:50]  * wallyworld sad
[03:55] <wgrant> wallyworld: Hm, we have a picker regression.
[03:55] <wallyworld> ?
[03:55] <wgrant> https://qastaging.launchpad.net/launchpad/+filebug, the "Assign to" picker has quotes around the text.
[03:55] <wgrant> Not there on prod.
[03:56] <LPCIBot> Yippie, build fixed!
[03:56] <LPCIBot> Project db-devel build #731: FIXED in 5 hr 31 min: https://lpci.wedontsleep.org/job/db-devel/731/
[03:56] <wgrant> Normal bug assignee pickers are OK.
[03:56] <wallyworld> https://code.launchpad.net/~wallyworld/launchpad/picker-displays-null-812253/+merge/68318 should fix it
[03:56] <StevenK> wgrant: How do you suggest I QA r13455?
[03:57] <wgrant> StevenK: Reject a delayed copy.
[03:57] <wgrant> wallyworld: Ah, great.
[03:57] <StevenK> That means I need to create one
[03:57] <wgrant> StevenK: Easy enough to do.
[03:57] <StevenK> And delayed copies make me cry.
[03:57] <wgrant> Yes
[03:58] <StevenK> wgrant: So copy something from the soyuz-team P3A to somewhere else?
[03:58] <wgrant> StevenK: Something that's not already public, yes.
[03:58]  * StevenK digs
[03:59] <wgrant> Why is syndaemon enabled by default :/
[03:59] <wgrant> How stupid.
[04:08] <StevenK> Delayed copy of launchpad-dependencies - 0.39 (source)
[04:09] <StevenK> Good enough
[04:11] <StevenK> wgrant: But I can't find that delayed copy using queue?
[04:14] <LPCIBot> Yippie, build fixed!
[04:14] <LPCIBot> Project devel build #898: FIXED in 5 hr 34 min: https://lpci.wedontsleep.org/job/devel/898/
[04:17] <wgrant> StevenK: You'll have to get the ID manually, I guess.
[04:17] <wgrant> Hopefully that will work.
[04:22] <StevenK> wgrant: scripts/ftpmaster-tools/queue reject -s hardy -Q accepted 2752292 worked fine
[04:22] <StevenK> Running: "info 2752292"
[04:22] <StevenK> Item 2752292 is in queue REJECTED
[04:28] <wgrant> Great.
[04:28] <wgrant> qa-ok, I s'pose.
[04:28] <StevenK> Already done
[04:31]  * StevenK kicks bigjools for the fun that is r13459
[04:31] <wgrant> StevenK: It is flagged.
[04:32] <StevenK> Then what's left?
[04:35] <wgrant> lifeless: LXC works fairly well in oneiric.
[04:35] <wgrant> With most of those bugs fixed.
[04:35] <wgrant> StevenK: Check that the methods don't work, I guess.
[04:39] <StevenK> wgrant: For r13459?
[04:40] <wgrant> Yes.
[04:41] <StevenK> And lib/lp/soyuz/interfaces/archive.py contains the generic exception ForbiddenByFeatureFlag.
[04:42] <StevenK> Fail.
[04:42] <wgrant> Did somebody break the JS build again?
[04:42] <StevenK> Oh?
[04:43] <wgrant> Ah, no, I just killed buildout in a bad place.
[04:46] <lifeless> wgrant: I'm hoping my sudo bug is fixed
[04:48] <wgrant> lifeless: Not sure.
[04:52] <wgrant> StevenK: Erm.
[04:53] <StevenK> wgrant: Hm?
[04:53] <wgrant> StevenK: [DOGFOOD] [PPA stevenk] [ubuntu/hardy] launchpad-dependencies 0.39 (Rejected)
[04:53] <wgrant> There was a blamer.
[04:53] <wgrant> Or SPR creator, possibly.
[04:53] <wgrant> flacoste:
[04:53] <StevenK> That is the creator
[04:54] <StevenK> wgrant: Neither copyPackage{,s} appears in the API on dogfood for devel :-(
[04:56] <wgrant> StevenK: You'll probably need to force it to rebuild the WADL
[04:56] <wgrant> StevenK: But this is to be tested on qastaging.
[04:56] <StevenK> Oh, easy fixed
[05:00] <StevenK> wgrant: On qas, I get a 403 calling IArchive.copyPackage()
[05:01] <wgrant> Good.
[05:02] <StevenK> Ah yes, the exception is 403
[05:02] <StevenK> Shall I qa-ok it?
[05:08] <wgrant> StevenK: Might as well.
[05:17] <StevenK> GAVIN!
[05:18] <StevenK> (The 3 branches linked to bug 809786)
[05:18] <_mup_> Bug #809786: Need to filter by package-set on DistroSeries:+localpackagediffs <derivation> <qa-needstesting> <ui> <Launchpad itself:Fix Committed by allenap> < https://launchpad.net/bugs/809786 >
[05:18] <StevenK> 518 lines, 4720 lines, and 2878
[06:12] <StevenK> Curious.
[06:19] <wgrant> StevenK: Hm?
[06:20] <StevenK> wgrant: I finally got +localpackagediffs to load, but I can't tell what Gavin changed/fixed
[06:20] <wgrant> StevenK: It was pure refactoring that's landed so far, AFAICT.
[06:20] <StevenK> All 6000 lines of it
[06:24] <StevenK> wgrant: So qa-untestable?
[06:25] <wgrant> Probably.
[06:25] <StevenK> wgrant: So the only thing left is Danilo's revision of doom
[07:48] <adeuring> good morning
[07:50] <jam> morning all
[07:50] <jam> I'm trying to understand an LP api timing. I could have sworn I was doing the same request last week, and it was returning in 100-200ms.
[07:50] <jtv> hi jam, hi adeuring!
[07:50] <jam> But this week it is more like 700-1000ms
[07:50] <jam> hey jtv
[07:50] <jam> is there any way to debug these sort of things?
[07:50] <adeuring> hi jtv
[07:51] <wgrant> jam: What sort of request?
[07:51] <jtv> Can we use ++profile++ on API requests?
[07:51] <wgrant> jam: 100-200ms is rather quick for LP.
[07:51] <wgrant> jtv: Possibly... ++oops++ doesn't work, since it only executes when the template renders.
[07:51] <jam> wgrant: getPublishedSources
[07:52] <wgrant> jam: Let's see.
[07:52] <wgrant> Everything should be faster this week :(
[07:52] <jtv> That's on Archive?
[07:52] <wgrant> Could be distroseries.
[07:52] <wgrant> Or distribution.
[07:52] <wgrant> I guess.
[07:52] <allenap> StevenK: Thanks for looking at the changes to +localpackagediffs. As long as it loads, it's fine. The changes so far are almost all moves and shakes.
[07:53] <StevenK> allenap: GAVIN! *Scary* branches! RARGH!
[07:53] <StevenK> allenap: But yes, it at least loads
[07:53] <jam> wgrant: https://api.launchpad.net/1.0/debian/+archive/primary?distro_series=%2Fdebian%2Fsid&exact_match=true&pocket=Release&source_name=%22bzr%22&status=Pending&ws.op=getPublishedSources&ws.size=1
[07:54] <jam> Archive
[07:54] <jtv> Yuck.  "clauses.append("SourcePackageName.name LIKE '%%%%' || %s || '%%%%'" % quote_like(name))"
[07:54] <wgrant> But this is exact_match.
[07:54] <wgrant> So that should be skipped.
[07:54] <wgrant> (it also shouldn't exist at all, but such is Soyuz)
[07:54] <jtv> Do we actually know we're looking at the archive code, actually?
[07:55] <wgrant> Yes.
[07:55] <wgrant> debian/+archive/primary
[07:56] <wgrant> jam: Render time is just about identical compared to 1.5 weeks ago.
[07:56] <wgrant> jam: Do you have any hard data to support the slowdown?
[07:57] <jtv> The only recent direct change in that piece of code was in June, where it looks like multi-name matching was introduced.  But that should barely touch the exact-match code path.
[07:58] <jtv> Unless the thing gets passed some kind of placeholder that acts like a string but isn't of type str or unicode, but I don't really know whether that's possible or whether it would work if it was.
[08:01] <wgrant> AND SourcePackageName.name = E'bzr' AND
[08:01] <mrevell> Good morning
[08:01] <wgrant> From using that URL locally.
[08:01] <bigjools> morning al
[08:01] <bigjools> l
[08:03] <jam> wgrant: I know I did timing tests last week, and had some perf tests.
[08:03] <jam> but no, I don't have very hard data.
[08:05] <jam> wgrant: take that back, I have my .bzr.log
[08:05] <jam> from today: 6.778  LatestPublication.get_latest_version took 1.524s
[08:05] <wgrant> Oh, this is for the checking if the branch is up to date thing?
[08:05] <jam> from last week: 7.974  LatestPublication.get_latest_version took 0.214s
[08:05] <jam> wgrant: yep
[08:05] <wgrant> Have you moved to Australia lately?
[08:05] <jam> so the ones I was testing before is "ubuntu/natty/bzr"
[08:06] <wgrant> Oh.
[08:06] <wgrant> That's a bit different :)
[08:06] <jam> but that is still slow
[08:06] <jam> 700ms orso
[08:06] <wgrant> :(
[08:06] <stub> jtv: Storm contains a Like operator that might spell that better if you are coding nearby.
[08:06] <jam> just tested now 939ms
[08:06] <jtv> stub: I'm not, but that's part of what made me nauseous.
[08:07] <jtv> It's even easier than Like; IIRC you can use the regular str methods such as startswith.
[08:07] <jtv> There's one for "contains" as well.
[08:07] <StevenK> I recently used .contains()
[08:07] <jam> wgrant: with bzr.dev tip, you can run this script: http://paste.ubuntu.com/647087/
[08:07] <stub> even better
[08:07] <wgrant> wgrant@carob:~$ time curl -H 'Authorization: there is none' 'https://api.launchpad.net/1.0/debian/+archive/primary?distro_series=%2Fdebian%2Fsid&exact_match=true&pocket=Release&source_name=%22bzr%22&status=Pending&ws.op=getPublishedSources&ws.size=1' -s -o /dev/null
[08:07] <wgrant> real	0m0.253s
[08:08] <jam> (python latest_version.py ubuntu natty bzr)
[08:08] <jtv> Someone went to the trouble of coding up a hybrid storm/sqlobject method so that they could write up that horrible LIKE clause.
[08:08] <StevenK> jtv: Can you point out the method so we can have it shot?
[08:09] <wgrant> jam: So, it takes around 250ms from the DC.
[08:09] <jtv> StevenK: Archive.getPublishedSources
[08:09] <wgrant> jam: For natty it's down around 150ms, as expected.
[08:09] <wgrant> Since there's a lot less data.
[08:09] <bigjools> StevenK: please don't shoot that one
[08:09] <wgrant> (this isn't exactly optimised)
[08:10] <StevenK> It deserves it.
[08:10] <jam> wgrant: I'm seeing 600ms in "_ssl.sslwrap" is that the SSL handshake ?
[08:10] <wgrant> jam: I assume so.
[08:10] <jam> so that is very different from last week, I believe
[08:11] <wgrant> Sure your connection latency doesn't suck?
[08:11] <jam> wgrant: I'm in Netherlands
[08:11] <jam> ping says 36ms
[08:11] <wgrant> How long does the curl I listed above take?
[08:12] <jam> 321ms I believe
[08:12] <wgrant> And then try a couple of times without the Authorization header.
[08:12] <wgrant> (the presence of even an invalid one gets it past Squid)
[08:13] <jam> wgrant: but that is because curl fails immediately with "SSL FAILED"
[08:13] <jtv> morning bigjools!
[08:13] <wgrant> Helpful.
[08:13] <bigjools> hello jtv
[08:13] <jtv> jam: want to meet up later this week?
[08:13] <jam> but I can pass -s, I guess
[08:13] <jam> I still don't get any output to tell if it is working
[08:14] <wgrant> jam: Well, probably better to make it work rather than ignoring the error...
[08:14] <jam> :)
[08:14] <jam> I wasn't sure what -s did
[08:15] <jam> apparently it is --quiet not "--ignore-certificate"
[08:15] <jam> wgrant: with -k instead of -s, I get 892ms
[08:15] <wgrant> I get no cert error locally or on carob.
[08:15] <jam> wgrant: launchpad isn't in my cacerts
[08:15] <jam> -k works fine for testing
[08:15] <wgrant> Mine are stock Natty.
[08:17] <jam> so, still the same time for a successful request, about 900ms, which could be 600ms in ssl handshaking
[08:17] <jam> which is definitely slower than last week
[08:17] <jam> I don't know why
[08:18] <jam> is there a graph/monitoring of ssl stuff?
[08:20] <wgrant> Internally it's fine.
[08:23] <jam> wgrant: right, so from devpad, I see 148ms
[08:24] <wgrant> 900ms from 150ms away
[08:24] <wgrant> So 650ms overhead, which is about four ways...
[08:24] <jam> wgrant: I'm 38ms away by "ping"
[08:24] <jam> so 17 round tirps
[08:24] <jam> trips
[08:26] <wgrant> Odd.
[08:26] <wgrant> Still, fine in and next to the DC.
[08:26] <wgrant> So I am tempted to blame your machine/connection.
[08:27] <wgrant> .nl hasn't imposed a Great Firewall lately? :)
[08:33] <wgrant> :(
[08:33] <wgrant> zope.app.testing fixed their Referer default.
[08:34] <wgrant> So 350 or so tests fail with OffsiteFormPost errors.
[08:47] <jam> vila: can you try the query from France?
[08:47] <vila> otm
[08:47] <jam> time curl -k 'https://api.launchpad.net/1.0/debian/+archive/primary?distro_series=%2Fdebian%2Fsid&exact_match=true&pocket=Release&source_name=%22bzr%22&status=Pending&ws.op=getPublishedSources&ws.size=1' -o test.txt
[08:48] <rvba> jam: real	0m0.532s
[08:48] <rvba> (from Paris)
[08:49] <wgrant> rvba: Is that after a couple of tries?
[08:49] <rvba> real	[0m0.362s - 0m0.532s]
[08:49] <rvba> wgrant: that's the range I get
[08:50] <rvba> After a couple of tries: real	0m0.344s
[08:50] <wgrant> That's a bit better.
[08:51] <jam> wgrant: of course *right* now it just dropped to 300ms, but now curl varies from 300-953ms
[08:52] <jam> and it still is taking 700+ from python
[08:53] <jam> which still doesn't get close to the 150ms from last week
[08:55] <wgrant> Was this on the same machine in the same environment?
[08:55] <jam> yes
[08:55] <jam> actually, the only difference offhand is that now I'm on a wired connection to my router, while last week I was on wireless
[08:56] <jam> I guess it was 200ms last week, which is close to 300.
[08:56] <jam> the variability is surprising
[08:56] <jam> and last week was python, not curl
[08:56] <wgrant> I get 50ms from squid.
[08:57] <wgrant> Which sucks, but it's always within 1ms.
[08:57] <jam> what do you mean by "from squid" ?
[08:57] <StevenK> We have a proxy in front of the appservers
[09:00] <jam> StevenK: sure, but is he saying bypassing the squid proxy, the appservers respond in 50ms
[09:00] <jam> or from the squid machine
[09:00] <jam> or he gets 50ms making a request to squid without an appserver
[09:00] <StevenK> No, he is saying that squid replies in 50
[09:00] <wgrant> 50ms to get the copy that squid has cached.
[09:00] <wgrant> ie. after requesting a few times without Authorization
[09:03] <jam> wgrant: my requests also were without auth, but you're saying from where to squid?
[09:03] <wgrant> carob to squid
[09:03] <wgrant> Via the usual HTTPS frontends
[09:04] <wgrant> wgrant@carob:~$ time curl 'https://api.launchpad.net/1.0/ubuntu/+archive/primary?distro_series=%2Fubuntu%2Fnatty&exact_match=true&pocket=Release&source_name=%22bzr%22&status=Pending&ws.op=getPublishedSources&ws.size=1' -s -o /dev/null
[09:04] <wgrant> real	0m0.050s
[09:04] <wgrant> (Debian is, unsurprisingly, identical)
[09:05] <jam> sure. Though that just dropped as well
[09:05] <jam> it was 150ms for me when I first reported devpad numbers
[09:05] <jam> even running a couple of timse
[09:05] <jam> times
[09:06] <jam> wgrant: so I still think there is something that is slowing queries down, that magically disappeared in the last hour
[09:08] <jam> eg, we're missing some monitoring somewhere that would tell us something is going on for people actually getting a much slower launchpad
[09:09] <wgrant> Even in front of squid?
[09:09] <jam> wgrant: I ran the same query, and it was 150ms from devpad to api.launchpad.net
[09:10] <wgrant> Hmm.
[09:10] <jam> I think I managed to provoke squid to skipping just now, and I got 400ms
[09:10] <jam> (that was to debian, though)
[09:11] <jam> but I'm playing with setting Authorization, and I'm getting 50ms
[09:11] <vila> jam: first try: 1.355s real, then 0.249s, 0.199s, 0.194s, 0.189s , 0.198s
[09:11] <jam> so it sounds like squid doesn't actually pay attention to it.
[09:11] <jam> vila: right, so those sound like cached and uncached responses.
[09:11] <vila> further tries stabilize at 0.200s
[09:11] <jam> and arguably we should be really counting the uncached values as our user-experience.
[09:11] <jam> we might need to put this behind a flag
[09:13] <jam> vila: I couldn't figure out what you meant by OTM, on-the-mumble?
[09:13] <vila> jam: yeah :)
[09:13] <wgrant> jam: Apache is configured to send anything with Authorization or Cookie straight to haproxy, not squid, AFAIK.
[09:13] <jam> wgrant: tell that to my curl results :)
[09:14] <jam> though I could be typing something wrong
[09:14] <jam> ah, Authentication not Authorization
[09:14] <jam> my bad
[09:15] <jam> right, that does bypass it
[09:15] <jam> that's 479ms stabilizing to 230ms on carob bypassing squid requesting debian urls
[09:15] <jam> which is hopefully worst-case in DC times
[09:16] <jml>  I clicked "Build now" on https://code.launchpad.net/~testing-cabal/+recipe/testtools-daily and get what looks to be a JS alert saying "Server error, please contact an administrator"
[09:16] <jml> what's going on?
[09:21] <jam> wgrant: ok, this is weird. curl is going to 91.189.89.224, but python is going to 91.189.89.225
[09:21] <jam> and *that* seems to be the difference in timings
[09:22] <jam> it is "banana" vs "nutmeg"
[09:22] <StevenK> Yes, they are two frontends
[09:22] <jam> StevenK: any idea why banana would be 300ms slower than nutmeg?
[09:24] <wgrant> Both 50ms cached...
[09:25] <wgrant> And both 200-250ms uncached.
[09:28] <lifeless> stub: hi
[09:29] <stub> lifeless: hi
[09:29] <lifeless> stub: I thought I'd touch base on 'kick connections out and keep em out' implementation choices
[09:34] <bigjools> anyone got any ideas on where to look to investigate why an api method I added is not available over the wire to dogfood?  It's in dogfood's WADL but launchpadlib  says "'Entry' object has no attribute ...."
[09:35] <jam> wgrant: how do you get curl to target a server?
[09:35] <jam> can you just do the IP address, or are they vhosts?
[09:36] <jam> (I get ACCESS DENIED going to the IP address.)
[09:36] <wgrant> jam: They're vhosts on special IP addresses.
[09:36] <wgrant> time curl -H 'Authorization: blah' -H 'Host: api.launchpad.net' 'https://91.189.89.225/1.0/debian/+archive/primary?distro_series=%2Fdebian%2Fsid&exact_match=true&pocket=Release&source_name=%22bzr%22&status=Pending&ws.op=getPublishedSources&ws.size=1' -k -o /dev/null
[09:39] <jam> wgrant: thanks. So bypassing SQUID going to ubuntu/natty I get a reliable 470-530ms to either server (nutmeg or banana)
[09:41] <jam> and without Authorization, I get 330-360 from curl
[09:41] <jam> so something about python is provoking something
[09:46] <stub> lifeless: I think we are shutting down pgbouncer, which kills all the connections with 'connection terminated unexpectedly' exceptions and future connection attempts will timeout as nothing is listening. The 'suspend' and 'pause' don't terminate the active connections and ignore the 'fail if unable to login in this many seconds' parameter.
[09:46] <lifeless> stub: ok
[09:47] <lifeless> stub: So we'll need the test fixture to be able to shut down and bring back the one config; I'll add that into a 0.2 tomorrow if noone else gets to it
[09:47] <gmb> lifeless: I don't know if you'll get chance, until your tomorrow, but I've replied to your review of https://code.launchpad.net/~gmb/launchpad/bug-491886/+merge/68174.
[09:48] <stub> lifeless: We want a pgbouncer test fixture?
[09:48] <lifeless> stub: we have one
[09:48] <lifeless> stub: the project I put together on Monday
[09:48] <lifeless> stub: so we can test this well - we don't need the whole test suite to use pgbouncer, just the tests for interrupt & reconnect detection
[09:50] <stub> Right. We used to have some disconnection/reconnection tests that used a simple twisted proxy, but this moved to Storm. We don't need to use pgbouncer if we don't want - as far as PG clients are concerned, they just have a socket.
[09:50] <lifeless> stub: its pretty quick to bring up, and the code is written
[09:51] <lifeless> stub: I suspect we only need 3-4 tests per daemon
[09:53] <bigjools> lifeless: any chance you can help me debug a webservice problem on dogfood please?
[09:54] <bigjools> I know it's rather late for you
[09:54] <lifeless> sure
[09:54] <lifeless> sec
[09:54] <lifeless> gmb: reviewed
[09:54] <lifeless> gmb: generally, I'm happy for any other reviewer to do a follow up once you consider (and action or reject) my suggestions
[09:55] <gmb> lifeless: Thanks, and duly noted for the future.
[09:55] <lifeless> gmb: I don't think you need to consider the review pinned to me (unless I specifcally say I want that)
[09:55] <gmb> Okiedoke.
[09:55] <lifeless> gmb: I think the try:except: looks a lot simpler :)
[09:55] <lifeless> bigjools: whats up ?
[09:56] <gmb> lifeless: Agreed. I was trying to avoid the transaction.abort() but simplicity beats I-don't-want-to-have-to-deal-with-transactions.
[09:56] <bigjools> lifeless: I added IArchive.copyPackage to the API. It's on DF's wadl/+apidoc but launchpadlib can't see it :/
[09:56] <lifeless> bigjools: delete your lp lib cached
[09:56] <StevenK> bigjools: Remove your cached WADL?
[09:56] <bigjools> GAH
[09:56] <bigjools> this old chestnut
[09:57] <bigjools> why why why
[09:57] <lifeless> if it works, file a bug
[09:57] <lifeless> I would -so- like to nuke the use of WADL, but I'm old school.
[09:57] <bigjools> anything with XML in it reeks of shit
[09:58] <StevenK> It lends itself so well to ridicule, though. "qas is WADLing"
[09:58] <lifeless> gmb: oh, and the linty stuff I don't care about really, I mentioned it for completeness
[09:59] <bigjools> yeah that worked.  thanks lifeless
[09:59] <lifeless> bigjools: file a bug ?
[09:59] <bigjools> yeah doing so
[10:00] <lifeless> \o/
[10:00] <bigjools> but on where
[10:00] <lifeless> launchpadlib
[10:00] <lifeless> its the thing choosing to use wadllib etc; and its the thing we need a versioned dep on to ensure a newer wadllib if thats how we fix it
[10:03] <cjwatson> could somebody help me land https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations-schema?
[10:04] <bigjools> lifeless: bug 812799
[10:04] <_mup_> Bug #812799: Local cache not updated when it should be <launchpadlib :New> < https://launchpad.net/bugs/812799 >
[10:04] <lifeless> bigjools: triage it ! :)
[10:04] <lifeless> [I suggest high]
[10:04] <bigjools> lifeless: jeez, gimme time to fart first
[10:04] <lifeless> bigjools: well, you're old and all, I don't know I have *that* much time to wait :P
[10:05] <lifeless> bigjools: [seriously, when you linked it I figured that meant you'd done all you intended to on it]
[10:05] <bigjools> lifeless: my arthritic fingers at my old age don't work as quick as that :)
[10:08] <stub> lifeless: pgbouncer might help test suite race conditions tearing down/creating databases
[10:08] <bigjools> awesome, feature flags are case-sensitive
[10:08] <stub> mmm... probably not. its more pg tripping over its own feet and waiting for its internals to catch up rather than inbound connections
[10:08] <lifeless> stub: if it could force only one connection at a time to template1
[10:09] <stub> lifeless: it could do that...
[10:09] <lifeless> stub: anyhow, my patch for that seem to work, and we're looking at lxc for parallel in the short-medium term anyhow, now.
[10:09] <lifeless> because there are so many similar glitches in our stack at the moment
[10:09] <lifeless> [e.g. launchpadlib test cache dir]
[10:16] <jml> cjwatson: sure.
[10:22]  * wgrant curses Python
[10:23] <wgrant> Don't make backwards incompatible changes in 2.7 without a non-monkeypatch way to restore the old behaviour.
[10:23] <StevenK> wgrant: Hm?
[10:23] <wgrant> The default continuation whitespace character in generated email headers changed from tab to space.
[10:24] <wgrant> And this is set in an _method of a class.
[10:24] <wgrant> So it's not really overridable.
[10:24] <jml> Yeah, python-devel seems to hate backwards compatibility
[10:24] <jml> Hmm.
[10:24] <wgrant> Ah, mercurial indeed fix it by monkeypatching.
[10:24] <jml> It turns out I'm not able to land branches any more, because I'm not allowed to edit commit messages on merge proposals for Launchpad.
[10:25] <wgrant> Yeah, the emeritus stuff isn't really set up yet.
[10:25] <wgrant> Most people are still in ~launchpad.
[10:25] <wgrant> Want me to land it instead?
[10:26] <jml> wgrant: sure. here's the line I'm using:
[10:26] <jml> ./utilities/ec2 land https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations-schema/+merge/67992 --commit-text="Add include_long_descriptions column to DistroSeries to enable future work separating long descriptions out of Packages file" --no-qa
[10:27] <jml> wgrant: I would like my commit access back too please
[10:31] <wgrant> :(
[10:33] <cjwatson> shall I set the commit message in the MP?
[10:33] <wgrant> It's done.
[10:33] <wgrant> ec2 is almost running.
[10:34] <cjwatson> thanks
[10:34] <jml> cjwatson: even if it were set, I would need privileges to edit it, since our landing tools push some metadata onto it.
[10:34]  * cjwatson nods
[10:36] <wgrant> Down to 12 2.7 test failures, plus two tests that hang.
[10:36] <wgrant> Nearly there.
[10:38] <jml> \o/
[10:38] <jml> wgrant: so the plan is to switch to 2.7 ahead of the next LTS?
[10:38] <wgrant> jml: Yes.
[10:39] <jml> that'd be nice
[10:39] <wgrant> We have a Lucid backport already, I believe.
[10:39] <wgrant> OK, down to gratuitous difflib formatting changes plus XML-RPC rewrite.
[10:39] <wgrant> Yay
[10:40] <wgrant> danilos: Does the zero-width space fix the slight underline you get on hover in WebKit?
[11:14] <jml> lifeless: does fixtures have a way of combining two fixtures?
[11:23] <jam> wgrant: to add love to this investigation, if I do 2 api requests back-to-back in the same process, the first takes 700ms, the second 200ms. something seems really wonky about ssl.sslwrap
[11:23] <jam> maybe it caches host identities or something
[11:26] <nigelb> oh yay, is loggerhead down?
[11:27]  * nigelb moves to the correct chanel
[11:33] <wgrant> jam: Hmm.
[11:33] <wgrant> jam: It's possibly also doing OCSP or something slow like that.
[11:39] <lifeless> jml: yes, useFixture, or the hypothetical graph stuff we've talked about vis-a-vis replacing testresources
[11:40] <lifeless> jml: re emeritus - yes, its not setup yet; you didnt have to leave ~launchpad :P.... anyhow, getting it setup means moving stuff that references launchpad directly to reference role teams, and I don't know how long the piece of string is yet.
[11:56] <bigjools> woo, timeouts creating an MP
[11:59] <wgrant> bigjools: The branch scanner is slow, as it has to insert like 70000 branchrevisions.
[11:59] <wgrant> That keeps things locked for a while.
[11:59] <bigjools> what did someone just do?
[12:00] <gary_poster> personally, I was typing.
[12:00] <bigjools> badumtish!
[12:00] <gary_poster> :-)
[12:01] <bigjools> StevenK's humour has been rubbing off on gary_poster
[12:01] <gary_poster> heh
[12:01] <bigjools> I say humour in the loosest sense
[12:01] <gary_poster> yeh yeah yeah
[12:01] <bigjools> that reflects more on him than you though :)
[12:01] <gary_poster> :-)
[12:03] <wgrant> gary_poster: Hi.
[12:03] <gary_poster> hey wgrant.
[12:06] <wgrant> gary_poster: Our XMLRPCTestTransport is broken in Python 2.7. getresponse now takes a buffering kwarg, and it's not trivially obvious to me how to make our stuff work with 2.7. I noticed that there's zope.app.testing.xmlrpc.ZopeTestTransport which does a similar thing in a different, 2.7-compatible way. But compared to ours, it doesn't send a Host header or preserve the original interaction.
[12:06] <wgrant> I presuuuume we probably want to rebase our stuff around ZopeTestTransport.
[12:06] <wgrant> But was wondering if you had any ideas.
[12:06] <wgrant> Given your Zopey foundationsness.
[12:06] <gary_poster> heh
[12:13] <gary_poster> wgrant, in the abstract, I no longer feel that there's a huge win to trying to coordinate with the Zope community, given its ever-vanishing existence/relevance.  Maybe that's unfair.
[12:13] <gary_poster> In any case, I'm in favor of a relatively attractive path of least resistance, whatever that is.  If it would be relatively easy to make the Zope version do what we want, benji and I still have commit and release privs.
[12:14] <gary_poster> That could potentially get us in one of the "update the Zope world" situations, but if there has been as little activity there as I believe, that might be a non-problem.
[12:14] <gary_poster> I'm afraid I don't have anything to offer other than that ATM, though if you'd like me to dig in a bit to understand the problem you describe and have a more concrete opinion on a way forward, I'm happy to.
[12:15] <wgrant> I'm happy to dig myself, was just wondering if you had any immediate insights.
[12:15] <gary_poster> 'fraid not. :-/
[12:17] <wgrant> Thanks anyway.
[12:17] <gary_poster> np
[12:17] <wgrant> Shouldn't be too hard to sort something out.
[12:17] <gary_poster> agreed
[12:22] <wgrant> bigjools: :( that needs to be advertised everywhere
[12:22] <bigjools> wgrant: ?
[12:23] <wgrant> bigjools: I'd not seen that matcher before, and it seems useful in an awful lot of tests.
[12:23] <bigjools> yes, it freakin rocks
[12:23] <bigjools> seriously, read the matcher docs
[12:34] <danilos> wgrant, yes (regarding zero-width space)
[12:35] <wgrant> danilos: Great!
[12:38] <jkakar> bigjools: +1000. :)
[12:38] <jkakar> testtools in general is super awesome.
[13:07] <deryck> Morning, everyone.
[13:15] <jtv> hi deryck
[13:35] <bigjools> jkakar: yes!
[13:38] <jtv> gmb: could I trouble you for review of an oversized refactoring?  https://code.launchpad.net/~jtv/launchpad/pre-788078/+merge/68374
[13:47] <gary_poster> Hey deryck.  You know I'm excited, so please just forgive me :-) but where is the thunderdome JS test stuff?  Have you started actually writing tests with it, and are you reasonably pleased with it?  (I am reminded because I'm writing some JS in a module w/out tests)
[13:48] <deryck> gary_poster, I have sadly not got very far with it.  I had one other remaining thunderdome bit which has taken all my attention....
[13:48] <deryck> gary_poster, a branch for fixing bug heat.
[13:48] <deryck> sorry :(
[13:48] <gary_poster> deryck, oh :-( .  understood.  I am about to finish a bugfix branch myself, so maybe I'll race you for the last bit? :-)
[13:49] <gary_poster> deryck, if you really want to do it, that's ok.  I got to play on it quite a bit
[13:50] <deryck> gary_poster, ok :)  I hope to either resolve the heat work or turn to the js stuff while waiting on more info on the heat work today. But I'll see how it goes.
[13:50] <gary_poster> :-) k cool
[13:50] <deryck> gary_poster, but I'll keep you better informed on my progress, too. :)
[13:50] <gary_poster> :-) thanks for humoring me
[13:52] <deryck> np!
[13:58] <henninge> How do I get the dev server to not use launchpad.js but the single js files?
[13:59] <gary_poster> henninge, afaik there is no way.  when people talk about that stuff they are talking about running YUI tests.  If you discover differently, I would *love* to know too :-)
[14:00] <wgrant> That ability was removed once we stopped using the bundled up YUI thing.
[14:00] <wgrant> Because it ended up making 400 requests to the local appserver on each page load, which took a couple of minutes.
[14:00] <gary_poster> oof
[14:00] <henninge> Ah, but my memory was not wrong.
[14:00] <wgrant> henninge: I know 'make jsbuild' isn't perfect, but it should be pretty fast.
[14:00] <wgrant> No need for appserver restarts or anything.
[14:00] <wgrant> Plus you should be doing TDD ;)
[14:01] <henninge> wgrant: no, it's about debugging the js file in the browser
[14:01] <henninge> lots of scrolling and searching in launchpad.js
[14:01] <wgrant> henninge: The Launchpad bits should be unminified.
[14:01] <wgrant> But yeah.
[14:01] <gary_poster> my concern with it is that neither chrome debug tools nor firebug handles the large file well
[14:01] <wgrant> henninge: You can't debug in the testrunner?
[14:01] <gary_poster> trying to set breakpoints sucks in that case
[14:02] <henninge> hm, could try that
[14:02] <gary_poster> wgrant we have lots of legacy JS code without tests
[14:02] <wgrant> gary_poster: Indeed :(
[14:02] <gary_poster> henninge both firebug and chrome debug let you search for a string
[14:02] <gary_poster> that's what I use
[14:02] <gary_poster> I find navigation not too bad
[14:03] <henninge> me, too
[14:03] <gary_poster> the debugger bugs are the killer
[14:03] <gary_poster> for me
[14:04] <henninge> would be cool if the file had comments with the originial file name whereever that file starts
[14:04] <henninge> wgrant: where is the code that creates launchpad.js?
[14:05] <wgrant> lp.scripts.utilities.js.jsmin
[14:05] <henninge> thanks
[14:05] <wgrant> Well.
[14:05] <wgrant> That minifies it.
[14:05] <wgrant> But the input to that is just cat run over all the files.
[14:06] <henninge> and the combining?
[14:06] <wgrant> cat :)
[14:06] <henninge> ah
[14:06] <henninge> ;)
[14:06] <wgrant> That's all in Makefile.
[14:07] <wgrant> rm lib/canonical/launchpad/icing/build/launchpad.js; make jsbuild
[14:07] <wgrant> Watch your screen and sob.
[14:07] <gmb> jtv: Sure, I'll take a look at that branch for you.
[14:07] <jtv> great, thanks
[14:09]  * henninge sobs
[14:10]  * StevenK sees that henninge is following wgrant's instructions
[14:10] <henninge> yup, always
[14:55] <cjwatson> wgrant: whee, thanks
[14:56] <cjwatson> (there's still multiarch-translations proper, but need to wait for a lucid-updates landing and sort out PPA bits first)
[15:12] <gmb> jtv-afk: r=me on the kilobranch. Nice work.
[15:23] <nigelb> Hi, how do I update my branch? My devel branch is getting a rocketfuel-get.
[15:24] <nigelb> *my feature branch
[15:47] <jml> nigelb: you merge devel (or stable) into it
[15:47] <nigelb> ok, doing that now.
[15:54] <jml> nigelb: you need to commit after merging
[15:54] <jml> nigelb: pretty important that you do that.
[15:55] <nigelb> jml: oh, ok!
[15:55] <nigelb> did windmill get nuked?
[15:55] <jml> nigelb: yes.
[15:55] <jml> nigelb: at the rally
[15:56] <nigelb> that explains the conflict.
[16:05] <nigelb> where is the ideal place to put a utility function (sorting)
[16:06] <mhall119> quick question, can I query the launchpad api using a user SSO identity URL yet, or is it still just username?
[16:21] <jml> nigelb: lp.services.utils
[16:21] <jml> nigelb: tests in lp.services.tests.test_utils
[16:22] <nigelb> jml: thanks again. Where is everyone today? :)
[16:22] <jml> nigelb: no idea.
[16:23] <bigjools> jml: "byEquality" - it just gets betterer and betterer :)
[16:23] <jml> bigjools: heh
[16:23] <bigjools> nigelb: I guess we must be busy hacking or something
[16:24] <bigjools> jml: have you got anything to do with Murdoch taking a pie to the face?
[16:24] <jml> bigjools: sadly no.
[16:24] <nigelb> lol
[16:25] <nigelb> I wonder if I should agree to take a pie to the face.
[16:25] <nigelb> For fixing all critical bugs before uds-p
[16:25]  * jml has a side bet for UDS-P. It involves drinking.
[16:26] <nigelb> jml: In that case I'll hear that one out :D
[16:26] <nigelb> UDS-P should of course be written as UDS :-P
[16:27] <jml> :)
[16:31] <nigelb> er, I'd like some help.
[16:33] <nigelb> How would I generalize the sort in this http://paste.ubuntu.com/647431/
[16:33] <nigelb> I want to avoid the bit where I'm doing the lower() and move it to a common function.
[16:33] <nigelb> But I'm not sure how to make it generic enough to be used everywhere
[16:34] <jml> nigelb: I don't think it's worth generalizing, tbh.
[16:34] <jml> nigelb: hmm.
[16:34] <jml> If you had to...
[16:34] <nigelb> jml: That's what I've been told to do. https://code.launchpad.net/~nigelbabu/launchpad/spec-sub-sort/+merge/63315
[16:34] <jml> def case_insensitive_sort(xs):
[16:35] <jml>     return sorted(xs, key=lambda x: x.lower())
[16:36] <nigelb> So, the only bit I'd avoid would be the lower() thingy.
[16:36] <jml> well, yeah
[16:37] <nigelb> I guess jtv could help throw some insight on whether that's enough. He helped with the initial review.
[16:37] <nigelb> jtv: ping
[16:38] <jml> nigelb: I don't have the willpower to read through that whole discussion...
[16:38] <jml> nigelb: you could also try this:
[16:38] <jml> def sort_for_display(things_to_display):
[16:38] <nigelb> jml: Now you know why it took me this long to do this :)
[16:39] <jml>   return sorted(things_to_display, key=lambda x: x.displayname.lower())
[16:39] <jml> or even
[16:39] <jml> def sort_for_display(things_to_display, display_attribute='displayname'):
[16:39] <jml>   return sorted(things_to_display, key=lambda x: getattr(x, display_attribute).lower())
[16:40] <nigelb> ok, ^ sounds like what's probably generic enough.
[16:40] <jml> nigelb: yeah, you've got some fairly blocky reviews
[16:41] <nigelb> It was hard to get out of that pit of demotivation I fell into after this.
[16:41] <jml> nigelb: well, basically, the thing is that as long as there's a *name* for what you are trying to do, the exact level of abstraction doesn't matter.
[16:41] <jml> because it'll probably change as we get it better anyway
[16:41] <jml> (and the name in this case is the function)
[16:42] <jml> nigelb: *nod* I know what you mean
[16:42] <nigelb> jml: I was trying to use this function in different use cases and I couldn't abstract it will.
[16:42] <jml> nigelb: ahh, ok.
[16:43] <nigelb> *well
[16:44] <nigelb> jml: I had to take some time off Lp dev before I could get myself back :)
[16:44]  * nigelb is now back :D
[16:46] <nigelb> jml: in that above function, should x also be a parameter to the function?
[16:46] <nigelb> *shouldn't
[16:46] <jml> nigelb: no. it's the argument to the key function.
[16:47] <jml> nigelb: please bear in mind that I typed it out into my IRC client, and thus am missing my usual crutches and so I've probably made a NameError or SyntaxError
[16:47] <nigelb> I'm testing it on python shell first
[16:48] <jml> good idea
[17:09] <nigelb> gmb: are you EOD-ing or was the topic stale?
[17:11] <nigelb> Ouch, my launchpad.dev isn't working. Is anyone around to help me figure out how to get it working?
[17:13] <nigelb> I guess I'll be back tomorrow.
[18:18] <deryck> sinzui, ping
[18:19] <sinzui> deryck, otp
[18:20] <deryck> sinzui, ok, just a question about a bug when you have a moment.
[19:25] <sinzui> hi deryck
[19:26] <deryck> hi sinzui.  Was only wanting to ask you about bug 812790 since you guys are working on stuff related to people, pickers, etc.
[19:26] <_mup_> Bug #812790: strange "no such person" popup on user-relative branch url <Launchpad itself:Triaged> < https://launchpad.net/bugs/812790 >
[19:26] <deryck> sinzui, not sure if that bug is at all related, but it seems fixed on qastaging.  So wondering if the bug should be closed?
[19:26] <deryck> or I can't repro on qastaging anyway.
[19:27] <sinzui> We have landed a few fixes in the last 24 hours
[19:28] <sinzui> I do not see anything that specifically fixes it though
[19:29] <deryck> sinzui, ok, thanks.  I'll leave as is then until we have more info.
[19:57] <lifeless> morning
[20:01] <jelmer> hi lifeless
[20:05] <lifeless> hi jelmer
[20:05] <lifeless> gary_poster: hi
[20:05] <gary_poster> hey lifeless
[20:05] <lifeless> gary_poster: that UNION -> OR may be performance sensitive; am just reviewing.
[20:05] <gary_poster> (on call(
[20:06] <lifeless> yah, no worries, just giving you a headsup
[20:06] <gary_poster> lifeless, wondered about that bu seemed unlikely.  I can just revert that part.  k
[20:21] <gary_poster> lifeless, that user_ids_affected_with_dupes code (UNION -> OR) has never been changed since it was originally written.  Tempted to revert anyway.  Thoughts?
[20:22] <lifeless> gary_poster: reverting would be conservative and make qa easier
[20:22] <lifeless> gary_poster: thats about it :)
[20:22] <gary_poster> lifeless, k, agree, will do, thx.
[20:24] <gary_poster> lifeless, "in the client side js, the limit of checking whether the task was
[20:24] <gary_poster> new seems unnecessary - isn't it reasonable to just cross check
[20:24] <gary_poster> regardless?" :
[20:24] <gary_poster> Since we don't do this generically (yet) I thought it would be surprising to update other tasks in response to saying "me too" because people might confuse coincidence with consequence.  I'd be fine if we always kept statuses up-to-date with long-poll later, for instance; then we would not need this "something happened" code path at all.
[20:24] <gary_poster> For now, though, I stand by my call there.
[20:25] <lifeless> its up to you
[20:25] <lifeless> there are a couple of bugs I can point you at :)
[20:25] <lifeless> where we suffer inflight collisions [particularly on the non-ajax forms] due to stale statuses
[20:25] <gary_poster> sure
[20:25] <gary_poster> but that's not what this is about
[20:25] <lifeless> I do see your point
[20:25] <lifeless> uhm
[20:26] <lifeless> perhaps huw can suggest some way [in the future] for us to show 'updated by you' and 'updated by $other'
[20:26] <lifeless> gary_poster: e.g. standing by your call is fine.
[20:26] <gary_poster> cool lifeless, thanks
[20:27] <lifeless> gary_poster: it was only a thought in the first place; perhaps I wasn't clear enough about that.
[20:27] <gary_poster> lifeless, sure.  if you didn't want us to respond to them, though, why express them? ;-)
[20:28] <lifeless> well, I do like responses :)
[20:28] <lifeless> I suspect I should eat before I fail-at-communication-more
[20:28] <gary_poster> well, and they are good thoughts that merit a response.  so...
[20:28] <gary_poster> lol
[20:30] <lifeless> I don't know entirely what I meant from 'it was only' .. on.
[20:30] <lifeless> -> food
[20:30] <gary_poster> :-)
[20:44] <lifeless> wgrant: lxc in oneiric may be better, but check out bug 802985
[20:44] <_mup_> Bug #802985: [lucid] /var/lib/dpkg/tmp.ci/preinst: 399: arithmetic expression: expecting EOF: "3.0-0-generic" <lucid> <patch> <debootstrap (Ubuntu):Triaged> <eglibc (Ubuntu):Invalid> <debootstrap (Ubuntu Lucid):Invalid> <eglibc (Ubuntu Lucid):Triaged> <debootstrap (Ubuntu Maverick):Invalid> <eglibc (Ubuntu Maverick):Triaged> <debootstrap (Ubuntu Natty):Invalid> <eglibc (Ubuntu Natty):Triaged> <debootstrap (Ubuntu Hardy):Invalid> <eglibc (Ubunt
[20:45] <gary_poster> lifeless, do you recommend bothering with lxc for LP right now?  I've been considering it, but the page you and William have maintained makes it look pretty...fragile.
[20:45] <lifeless> gary_poster: I have a few thoughts
[20:45] <lifeless> I don't think that right now the incremental learning for the team is all that great from someone just running a single test suite under it
[20:45] <gary_poster> (just a vm is my other option, and what I have do noe)
[20:45] <gary_poster> now
[20:46] <lifeless> I think its good to be familiar with lxc though, because I think its got legs
[20:46] <gary_poster> sure
[20:46] <gary_poster> I hope so
[20:46] <lifeless> and we're likely to want to implement parallel testing on top of it
[20:46] <gary_poster> makes sense
[20:46] <lifeless> the page does cover a bunch of detail today, but automation is improving, especially if using oneiric or the lxc ppa
[20:47] <gary_poster> was going to try oneiric, but I've spent my OS configuration budget for the month.  August, maybe. :-)
[20:48] <lifeless> heh, i hear you!
[20:48] <lifeless> I've just made a KVM oneiric instance
[20:48] <lifeless> to kick the tires on lxc and ensemble a bit
[20:49] <gary_poster> cool, yeah, I made a vm too
[20:49] <gary_poster> but lxc on a vm seemed a curiosity and a good way to explore lxc, more than a practical approach. :-)
[20:50] <gary_poster> although it would still give some benefits, I suppose
[20:50] <lifeless> so lxc is a moving target
[20:51] <lifeless> the container rules and capabilities are changing fast enough that 6 months can easily get bug fixes relevant to us.
[20:52] <gary_poster> yeah, makes sense
[20:52] <lifeless> anyhow, if you want to do any of the following, lxc +1:
[20:52] <lifeless>  - parallel test
[20:52] <lifeless>  - test with different / new dependency stacks
[20:52] <lifeless>  - run more than one lp up at a time [e.g. to play with federation]
[20:53] <lifeless> or if you have any memory pressure issues on your machine (e.g. during bin/test)
[20:53] <lifeless> it shouldn't be too bumpy a ride - it will either be easy, or totally impossible :>
[20:53] <gary_poster> lol
[20:53] <gary_poster> ok cool
[20:53] <gary_poster> might give it a try soon then
[20:53] <gary_poster> thanks lifeless :-)
[20:54] <lifeless> np :)
[20:57] <lifeless> wallyworld: wow, early up?
[21:04] <lifeless> jelmer: hi
[21:04] <lifeless> jelmer: why do you think bug 628323 is a subunit package bug ?
[21:06] <jelmer> lifeless: see max's comment
[21:06] <lifeless> I don't have that
[21:07] <lifeless> what did he sya ?
[21:07] <maxb> someone talking about me? :-)
[21:07] <jelmer> lifeless: "This FTBFS is the result of the python-subunit package not being
[21:07] <jelmer> properly built for all current Python versions"
[21:07] <lifeless> I don't follow.
[21:08] <lifeless> does it need a no change rebuild because the set of supported python packages has finally changed in debian ?
[21:08] <lifeless> s/packages/versions/
[21:08] <maxb> Is that bug number wrong, or private?
[21:08] <lifeless> its in Debian
[21:13] <jelmer> lifeless: it has already had the no-change rebuild, I'vconfirmed 0.0.6-2 was only built for 2.6, 0.0.6-3 was built for 2.6 and 2.7
[21:14] <lifeless> I'm not sure what to conclude from that :)
[21:14] <lifeless> I have to pop out to see the midwife, be back in <= 90m
[21:14] <jelmer> according to the logs the bug was filed with 0.0.6-2 installed
[21:14] <jelmer> so I'm going to indicate that in the bts
[21:15] <jelmer> lifeless: ok. I hope all is well
[21:15] <lifeless> just routine meeting
[21:22] <wgrant> lifeless: Hah, nice.
[21:22] <wgrant> lifeless: Oddly, lxc debootstrapped it fine for me.
[21:34] <wgrant> wallyworld: Hi
[21:34] <wallyworld> hi
[21:35] <wallyworld> lifeless: sorry, didn't see your ping. irc notifications in unity aren't as good as i'd like so i often miss them
[21:36] <wallyworld> wgrant: what can i do you for?
[21:36] <wgrant> wallyworld: Was just going to tell you that the "true"/"false" thing was a real bug, but I see you've fixed it already.
[21:37] <wgrant> (not sure why it can't be in the main JSON dict, though)
[21:37] <wgrant> Nice simple test, too.
[21:38] <wallyworld> wgrant: yes. i reverted that tales snippet. it's all a mess. today i plan to do some more yak shaving. there's 2 ways of getting a picker (via create or addpickerpatcher) and you get different results depending on which one is used :-(
[21:38] <wgrant> wallyworld: Yeah.
[21:38] <wgrant> Still, we are getting better.
[21:38] <wgrant> Slowly.
[21:38] <wallyworld> plus the config vs json_config issue
[21:39] <wallyworld> at first i didn't see why there was the need to hack in those booleans in the tales
[21:39] <wallyworld> all pretty ugly
[21:39] <wgrant> But fixable :)
[21:41] <wallyworld> i added 2 tests to the yui test case - one for the textfield plugin and one for the extra message. the textfield plugin refactoring from the tales was good because it enabled the yui test to check the proper code path
[21:41] <wallyworld> whereas before the test wired it up manually
[21:42] <wgrant> i only see one new test, but I guess you adapted an existing one to test the whole thing?
[21:43] <wallyworld> wgrant: yes - i modified an existing test and added some extra setup guff to support it
[21:43] <wgrant> The best kind of new test.
[21:43] <wallyworld> the modifed test is the one i was referring to above when i said it's now a better test
[21:43] <wgrant> Yup
[22:12] <LPCIBot> Project devel build #900: FAILURE in 5 hr 33 min: https://lpci.wedontsleep.org/job/devel/900/
[22:30] <jelmer> I'm getting exceptions starting RabbitMQ during the testsuite; is that a common issue?
[22:31] <wgrant> jelmer: Shouldn't be any more. Is your hostname configured correctly?
[22:31] <jelmer> 'hostname -f' returns 'localhost6', so I guess not..
[22:32] <wgrant> That could be a problem.
[22:32] <wgrant> It should be mostly immune to that now, but maybe IPv6 combined with dodgy hostname is doing bad things.
[22:42] <jelmer> hmm, that doesn't seem to work either
[22:42] <jelmer> I'll have a look tomorrow
[23:04] <wgrant> sinzui: We can hear you and each other.
[23:04] <wgrant> Can you hear us?
[23:04] <sinzui> no.
[23:04] <wgrant> That is suboptimal.
[23:14] <poolie> it would be cool if launchpad could show a per-pillar view like this for the hottest bugs: http://mail.google.com/support/bin/static.py?page=suggestions.cs
[23:36] <wgrant> lifeless: Hi
[23:37] <lifeless> hi
[23:40] <wgrant> lifeless: The malone.advanced-subscriptions.enabled, malone.advanced-structural-subscriptions.enabled, code.recipes_enabled flags are on by default and have been removed from the code. Can we remove the rules?
[23:40] <lifeless> of course
[23:40] <wgrant> Thanks.
[23:45] <poolie> hi wgrant, lifeless