[00:27] <wgrant> jcsackett: Around?
[00:28] <wgrant> lifeless: Hi.
[00:28] <lifeless> hola
[00:29] <wgrant> lifeless: Given the utterly disastrous state of QA over the past few days, I am tempted to revert the bad picker fixes.
[00:31] <lifeless> did jons branch fail ?
[00:31] <lifeless> I agree we despearately need to get stable
[00:31] <StevenK> Jon's branch hasn't even been reviewed
[00:32] <wgrant> Jon's branch is not reviewed, not ec2'd, and not necessarily going to work, and we've already got three rollbacks in the queue.
[00:32] <StevenK> And 3 more revs to QA
[00:32] <wgrant> A fourth to get us back to a reasonable state cannot hurt.
[00:32]  * StevenK finds his rope.
[00:33] <wgrant> And it's not even easy QA.
[00:37] <lifeless> I like rollbacks :)
[00:40] <wgrant> Ooh, it still reverts cleanly.
[00:40]  * wgrant reverts cleanly.
[00:41] <StevenK> wgrant: Are you going to self-review it?
[00:41] <wgrant> Yes.
[00:45] <wgrant> It is done.
[00:51] <lifeless> wgrant: hi; rabbit
[00:51] <lifeless> wgrant: did you have some success ?
[00:51] <wgrant> Not really.
[00:51] <lifeless> with it in vms specifically
[00:51] <lifeless> k
[00:52] <wgrant> I suspect I just need to poke /etc/hosts harder.
[00:53] <lifeless> I'm really disappointed with rabbit ease-of-use in this area
[00:54] <wgrant> Indeed. It's entirely unnecessary, too.
[00:54] <wgrant> Yay, create-lxc-aufs still works.
[00:57] <wgrant> OK, got it working.
[00:57] <wgrant> 127.0.0.1 localhost lucid-lp-temp-aufs-7YHq
[00:57] <wgrant> Doesn't work
[00:57] <wgrant> 127.0.0.1 localhost
[00:57] <wgrant> 127.0.1.1 lucid-lp-temp-aufs-7YHq
[00:57] <wgrant> Does
[00:58] <lifeless> butwhy
[00:58] <wgrant> Because it is hideous and likes to resolve its name both ways :)
[00:58] <timrc> wgrant, hey, cody-somerville said you rang
[00:58] <wgrant> It's like kerberos, except worse.
[00:58] <lifeless> wgrant: what do you mean?
[00:59] <wgrant> Hmm, I wonder if it's our fixture, actually.
[01:00] <lifeless> well, u1 had the same ugly
[01:00] <lifeless> and we got our fixture's core from u1
[01:00] <lifeless> but I'd like to understand what you mean
[01:00] <lifeless> does it manually parse /etc/hosts ?
[01:00] <lifeless> or is it binding to 127.0.1.1 for some bizarre reason?
[01:00] <wgrant> NAFAIK
[01:00] <wgrant> Need to experiment.
[01:01] <lifeless> my lxc doesn't have 127.0.1.1 in 'ip addr'
[01:01] <wgrant> It's not going to.
[01:01] <wgrant> It's 127.0.0.0/8
[01:01] <lifeless>     inet 127.0.0.1/8 scope host lo
[01:01] <wgrant> Well, that.
[01:01] <lifeless> the /8 only affects routing
[01:01] <wgrant> Yes...
[01:01] <wgrant> And it will resolve your hostname.
[01:02] <lifeless> 127.0.1.1 isn't usable unless the address is added somewhere
[01:02] <wgrant> Yes it is.
[01:02] <lifeless> or something daft is going on
[01:02] <wgrant> ping 127.99.99.99
[01:03] <wgrant> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
[01:03] <wgrant>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
[01:03] <wgrant>     inet 127.0.0.1/8 scope host lo
[01:03] <wgrant>     inet6 ::1/128 scope host
[01:03] <wgrant>        valid_lft forever preferred_lft forever
[01:03] <wgrant> 127.0.0.1/8 is on the interface.
[01:03] <wgrant> Hmm.
[01:04] <wgrant> Anyway.
[01:04] <wgrant> lo takes the whole /8
[01:04] <wgrant> Always has.
[01:04] <wgrant> And rabbit or the fixture somehow need to be able to resolve it both ways.
[01:07] <lifeless> hah
[01:08] <lifeless> searching for lo address gets a cee lo news clip ;P
[01:08] <wgrant> Heh
[01:09] <lifeless> I'm not sure lo always bound to all the the 127 addresses, but meh
[01:10] <lifeless> wgrant: whats odd/confusing is why it *wants* 127.0.1.1
[01:10] <wgrant> 127.0.1.1 has been in the default installation forever.
[01:10] <lifeless> wgrant: e.g. why its not happy with 127.0.0.1
[01:10] <lifeless> wgrant: no, it hasn't
[01:10] <wgrant> lifeless: 127.0.0.1 reverse resolves to localhost first.
[01:10] <lifeless> wgrant: feisty/etch brought it in.
[01:11] <lifeless> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=316099
[01:11] <lifeless> ah, so its whinging because it gets a different name back ?
[01:12] <wgrant> I presume so.
[01:12] <wgrant> It's possibly the fixture being crap.
[01:12] <StevenK> *However*, Feisty only added 127.0.1.1 on new installs
[01:16] <wgrant> Not even 12000 OOPSes from yesterday's amusement.
[01:16] <wgrant> How boring.
[01:17] <LPCIBot> Project devel build #865: STILL FAILING in 5 hr 50 min: https://lpci.wedontsleep.org/job/devel/865/
[01:24] <mwhudson> totally irrelevant, but apparently the 127.0.0.1/8 thing is different on os x
[02:12] <wgrant> lifeless: Hi.
[02:14] <wgrant> lifeless: The problem goes away if we pass fq_nodename instead of just nodename in as RABBITMQ_NODENAME.
[02:15] <wgrant> lifeless: rabbitmq will use nodename@hostname if it's specified, otherwise it will do a reverse lookup to guess hostname.
[02:15] <StevenK> So it's a very small patch?
[02:15] <wgrant> That's how the system one works: /usr/lib/rabbitmq/bin/rabbitmq-env constructs rabbit@hostname
[02:15] <wgrant> Yes.
[02:15] <wgrant> Three characters.
[02:19] <wgrant> I think rabbitfixture also leaks tmpdirs.
[02:19] <wgrant> Need to check that out.
[02:19] <StevenK> Heh
[02:20] <wgrant> Like, my laptop had several thousand by the end of last week.
[02:21] <poolie> hi StevenK, wgrant, lifeless
[02:21] <StevenK> O hai!
[02:21] <wgrant> Hi poolie.
[02:29] <wgrant> Mm, doesn't seem to leak normally.
[02:29] <wgrant> I guess I just killed it too aggressively.
[02:29] <StevenK> A thousand times or more
[02:39] <lifeless> poolie: hi
[02:39] <lifeless> wgrant: cool
[03:08] <StevenK> Orsum. bzrlib.lockable_files._LockWarner is now affecting ~1,500 tests on Jenkins
[03:12] <spiv> Upgrade your bzrlib :P
[03:14] <StevenK> spiv: That's with bzr 2.3.3-0~bazaar1~lucid2
[03:15] <spiv> StevenK: The relevant change landed on trunk about a week ago
[03:15] <lifeless> I think I'm blind
[03:16] <lifeless> spiv: we run releases in lp though
[03:16] <StevenK> I don't think I want to run LP tests against bzr trunk :-)
[03:16] <lifeless> spiv: so I think 'release 2.4 please'
[03:16] <lifeless> spiv: is a prerequisite
[03:16] <wgrant> We often run betas.
[03:16] <lifeless> the more bzrlib changes things the less I think that that is a good idea
[03:17] <lifeless> what I mean is that the old one-line-of-releases, each month is as stable as possible, deprecations are always graceful : well that was more amenable to using recent developments.
[03:17] <lifeless> its now harder to upgrade bzrlibs
[03:18] <lifeless> and we can't be as confident about e.g. wire level support issues till the final release in the series
[03:19] <lifeless> I'm not saying this is a problem per se
[03:19] <lifeless> but its a consequence of the changed policies
[03:19] <lifeless> zope.testing tests make my eyes bleed
[03:20] <wgrant> What are you doing to it?
[03:20] <lifeless> see my last comment in https://code.launchpad.net/~lifeless/launchpad/storylayers/+merge/66738
[03:20] <lifeless> I am teaching it that if it gets a test with no layer, it should not do layer per-test teardown and setup, regardless of whatever layers are setup.
[03:21] <lifeless> its that
[03:21] <wgrant> Hah
[03:21] <lifeless> or I can insert an adapting TestResult
[03:21] <lifeless> between the DocFileTests in a StoryPageTestCase and the zope.testing runner
[03:22] <lifeless> but the adapter would need to merge all the failures in all the elements of the story
[03:22] <lifeless> I think this is probably a lesser evil
[03:22] <lifeless> anyhow, we have 6 failures in our fork already
[03:22] <lifeless> and no idea if they are bitrot, changes, or what have you
[03:22] <lifeless> so I'm going to close my eyes and JFDI
[03:31] <benonsoftware> Question: What exactly is the Launchpad Community dev team? https://edge.launchpad.net/~launchpad-dev
[03:31] <lifeless> its a mailing list
[03:31] <benonsoftware> Just a list?
[03:31] <lifeless> you are welcome to join if you want to discuss the development of launchpad
[03:32] <benonsoftware> I'm alreaady a member on it.
[03:33] <poolie> lifeless, it would be nice if there was some clearer "what is this team for" concept
[03:34] <poolie> some of them you're welcome to join if you're just interested; some are only for trusted peolpe
[03:34] <poolie> perhaps they shouldn't all be presented as teams
[03:34] <benonsoftware> if it just a list they should just have a list section
[03:35] <poolie> there is a section about it being a list
[03:35] <poolie> biab
[03:37] <benonsoftware> What does biab mean?
[03:38] <lifeless> 'Back In A Bit'
[03:51] <StevenK> spiv: Out of interest, can you link me the fix for that?
[03:52] <spiv> StevenK: http://bazaar.launchpad.net/~bzr-pqm/bzr/bzr.dev/revision/6002
[03:53] <StevenK> spiv: That sounds like a good plan.
[03:54] <spiv> Yep.
[03:54] <wgrant> Probably makes the GC a bit happier.
[03:55] <spiv> Hmm, probably not so much.  I doubt our lock objects were participating in reference cycles.
[03:57] <lifeless> I suspect we have bugs causing us to see the warnings
[03:58] <spiv> Probably.
[03:59] <lifeless> ok, so this route isn't going to work
[03:59] <lifeless> I'll do a big-arse adapter instead.
[04:00] <spiv> To adapt it to a smaller arse?
[04:01] <lifeless> if only
[04:01] <lifeless> this is z.testing
[04:23]  * StevenK attempts to QA stuff
[04:27] <StevenK> wgrant: Can haz blessing to update DF?
[04:28] <wgrant> StevenK: doit
[04:29] <StevenK> wgrant: I think bug 740208 shouldn't be to bad to QA
[04:29] <StevenK> It's not very clear from the code if it's an e-mail that's in a title or something
[04:30] <wgrant> I checked it for descriptions earlier.
[04:30] <wgrant> It seems to be OK.
[04:30] <wgrant> But eeeh.
[04:30] <StevenK> Heh
[04:38] <lifeless> biab
[04:54] <StevenK> wgrant: So it looks fine, you're just nervous about it?
[04:56] <wgrant> StevenK: Yes.
[04:56] <wgrant> Also considering tracking down whoever decided that erlang extensions should automatically download their dependencies from git/hg.
[04:57] <wgrant> blink
[04:57] <wgrant> My eyes
[04:57] <StevenK> Haha
[04:58] <StevenK> wgrant: Do you think it's fine to deploy if we keep on an eye on it, or not?
[04:58] <wgrant> StevenK: I think it's OK.
[04:58] <wgrant> git clone http://github.com/mochi/mochiweb.git
[04:58] <wgrant> Check out the 'rebar' file.
[04:58] <wgrant> rebar seems to be some kind of extension build system.
[04:58] <wgrant> But look at what the file is.
[05:00] <StevenK> I'd rather not touch a git repo :-P
[05:00] <StevenK> wgrant: And we can probably deploy jtv's change, since it's FF'd
[05:00] <StevenK> rvba's change is running glaciall^Won mawson
[05:01] <mwhudson> wgrant: it looks lovely in github's browser, that file
[05:01] <StevenK> mwhudson: URL?
[05:01] <LPCIBot> Project db-devel build #700: STILL FAILING in 5 hr 40 min: https://lpci.wedontsleep.org/job/db-devel/700/
[05:01] <mwhudson> StevenK: https://github.com/mochi/mochiweb/blob/master/rebar
[05:01] <mwhudson> 'blob' has rarely been more appropriate
[05:02] <StevenK> Right. Now to review my lunch.
[05:02] <ajmitch> that blob looks like a .zip file
[05:02] <wgrant> It is.
[05:02] <mwhudson> it's something erlang related isn't it?
[05:02] <wgrant> What else...
[05:04] <StevenK> wgrant: So, the IDSJ runner just finished on mawson. It looks like it got past the problematic bit, so I'll qa-ok it, but there's another bug there.
[05:04]  * StevenK files it
[05:06] <wgrant> StevenK: k
[05:10] <StevenK> Firefox, how you annoy me
[05:10] <StevenK> Who broke click handling between Firefox 4 and 5, seriously?
[05:11] <StevenK> We are probably deployable in 2 hours
[05:14] <wgrant> zomg
[05:14] <wgrant> Almost there.
[05:32] <wgrant> Bah, bzr-hg fail.
[05:32] <StevenK> Hm?
[05:32] <lifeless> qa?
[05:33] <StevenK> Ha
[05:33] <StevenK> When r13376 hits qas, we can deploy 42 revisions
[05:35] <wgrant> bzr-hg fails to work with rabbitmq-mochiweb.
[05:35] <wgrant> It works with the rest :(
[05:35] <poolie> file a bug, please?
[05:35] <poolie> or, find one?
[05:36] <poolie> which branch?
[05:37] <wgrant> http://hg.rabbitmq.com/rabbitmq-mochiweb/
[05:37] <wgrant> Can't branch it directly.
[05:37] <wgrant> But if I try to branch a clone, it does a bit and then:
[05:37] <wgrant> bzr: ERROR: An inconsistent delta was supplied involving '<unknown>', 'hg:test'
[05:37] <wgrant> reason: Parent is not present in resulting inventory.
[05:43] <StevenK> Right, buildbot done, waiting for qas
[05:44] <StevenK> wgrant: I have prepared a bug list, too
[05:44] <wgrant> Excellent.
[05:44] <StevenK> 42 revisions, 28 bugs
[05:46] <wgrant> Less excellent.
[05:49] <poolie> wgrant, this rings a bell
[05:50] <poolie> wgrant, https://bugs.launchpad.net/bzr-hg/+bug/513368
[05:50] <_mup_> Bug #513368: inconsistent delta during fetch <code-import> <Bazaar Hg Plugin:Triaged> <Launchpad itself:Triaged> < https://launchpad.net/bugs/513368 >
[05:50] <wgrant> poolie: Thanks.
[05:57]  * StevenK whimpers at qastaging
[05:58] <StevenK> How did you miss 13376?! HOW?
[06:01] <wgrant> buildbot-poller being slow, maybe?
[06:03] <StevenK> wgrant: But surely it pulls from stable?
[06:04] <StevenK> But, perhaps
[06:04] <lifeless> it does
[06:05] <lifeless> but perhaps you've forgotten the 30 minute build of the tree on carob
[06:07] <StevenK> Why does stable need to build on carob?
[06:07] <StevenK> Since the first thing qas is run buildouyt
[06:07] <StevenK> *buildout
[06:09] <wgrant> StevenK: buildbot-poller pushes stable.
[06:09] <wgrant> StevenK: So buildbot completing is not enough to update stable.
[06:10] <wgrant> You have to hope that buildbot-poller sees it finish in a timely manner.
[06:10] <StevenK> Right, so moving to Jenkins might actually solve this -- since my plan is that when devel builds successfully it will push to stable/db-devel as the last step
[06:11] <wgrant> Jenkins shouldn't have permission to do that, I don't think.
[06:11] <wgrant> But maybe.
[06:11] <StevenK> Well, Jenkins tell tarmac to do it
[06:11] <StevenK> Handwave
[06:12] <StevenK> Utterly kill buildbot-poller
[06:16] <wgrant> 3/4 deps packaged...
[06:17] <wgrant> All of which originally grabbed $VCS checkouts of all of their dependencies
[06:17] <wgrant> WTF
[07:09] <LPCIBot> Project devel build #866: STILL FAILING in 5 hr 52 min: https://lpci.wedontsleep.org/job/devel/866/
[07:13] <wgrant> Ahah
[07:13] <wgrant> Packaged rabbitmq-management stack working.
[07:25] <poolie> nice
[07:25] <poolie> good night all
[07:26] <wgrant> Night.
[07:40] <bigjools> morning
[07:40] <wgrant> Morning bigjools.
[07:44] <bigjools> wgrant: did you see the QueueInconsistentStateError oops?
[07:45] <wgrant> bigjools: Yes, I identified the bug and Steve got the PU rejected.
[07:45] <bigjools> wgrant: good.  is it a new bug?
[07:46] <bigjools> looked like it was PPA though
[07:46] <wgrant> bigjools: Yes. OEM copied a package into a new PPA before it was private (the setup script hadn't called lp_save()), which triggered a delayed copy. It was then rerun with lp_save() added, so it was made private and recopied directly.
[07:47] <wgrant> The delayed copy processed a couple of minutes later, but the direct copy had already been done.
[07:47] <bigjools> awesome :/
[07:47] <wgrant> Yay
[07:47] <bigjools> the story is ....
[07:47] <bigjools> delayed copies need to die
[07:48] <wgrant> Yes
[07:49] <wgrant> In other news, I've packaged rabbitmq-management. It's a plugin that provides an HTTP API which will allow the test suite to quickly reset rabbit.
[07:49] <wgrant> So we can have test isolation.
[07:49] <wgrant> Which will be nice.
[07:49] <bigjools> splendid
[08:04] <allenap> Morning all.
[08:05] <bigjools> o/
[08:08] <mrevell> Hi
[08:09] <rvba> lifeless: Hi, I modified the code you rejected earlier today to throw a new exception with an additional message instead of using "print" (https://code.launchpad.net/~rvb/launchpad/rabbit-error-plugins/+merge/67000) ... if you think it's still clunky, I'll just forget about it but allenap and I though it would be nice to get a warning about potentially conflicting rabbit plugins.
[08:10] <adeuring> good morning
[08:10] <lifeless> rvba: I think there is a better way to tackle this; I will describe it in the proposal
[08:10] <wgrant> rvba: We're going to depend on rabbitmq-management soon, so I'll be working out how to run multiple instances tomorrow, hopefully.
[08:10] <wgrant> But there may be others.
[08:11] <rvba> lifeless: ok thanks.
[08:11] <StevenK> rvba: O hai. I QA'd your change, but hit https://bugs.launchpad.net/launchpad/+bug/806307
[08:11] <_mup_> Bug #806307: IDS has no access for DistributionSourcePackage <derivation> <Launchpad itself:Triaged> < https://launchpad.net/bugs/806307 >
[08:11] <rvba> wgrant: I suppose the 'conflict' is caused by multiple rabbit instances trying to use the very same port.
[08:12] <wgrant> rvba: Right, I need to work out how to configure that.
[08:12] <wgrant> Not sure if we can do it through an envvar like with the AMQP listener.
[08:12] <wgrant> rvba: Are you running natty?
[08:13] <rvba> wgrant: yes.
[08:13] <wgrant> Not sure if I want to backport natty's rabbitmq 2.3.1 to everywhere, or take 2.5.0 from oneiric.
[08:13] <wgrant> 2.5.0 has some major plugin build system changes.
[08:13] <wgrant> 2.3.1 has everything we need.
[08:14] <lifeless> rvba: done
[08:14] <lifeless> wgrant: think CATS
[08:14] <lifeless> s/S//
[08:15] <wgrant> I forget how to check what's there.
[08:15] <wgrant> Is there a madison around somewhere?
[08:15] <lifeless> presumably apt-cache search on carob
[08:15] <wgrant> Or must I FTP internally?
[08:15] <wgrant> carob only sees stock lucid rabbitmq-server.
[08:15] <rvba> lifeless: thanks ... I have used getDetails too ;) ... I guess I'll wait to see what wgrant does about this problem, if he manages to fix this in a generic fashion, the additional warning will be useless.
[08:15] <wgrant> Perhaps it's in some other pocket.
[08:16]  * StevenK kills parallel-test and disables the job again
[08:16] <StevenK> Running for 26 hours makes me SAD
[08:16] <lifeless> StevenK: sob, thanks.
[08:16] <LPCIBot> Project parallel-test build #85: ABORTED in 1 day 2 hr: https://lpci.wedontsleep.org/job/parallel-test/85/
[08:16] <lifeless> StevenK: any evidence of how it failed/
[08:16] <rvba> StevenK: it's a good sign that the initialisation started. Thanks for QAing my change.
[08:17] <LPCIBot> Project parallel-test build #86: ABORTED in 29 sec: https://lpci.wedontsleep.org/job/parallel-test/86/
[08:17] <LPCIBot> * Launchpad Patch Queue Manager: [r=wgrant][rollback=13334] Revert r13334 due to bug #806179.
[08:17] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][no-qa] New lp.app.longpoll package.
[08:17] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][bug=805547] Fix packageset's copy in initialise_distroseries.
[08:17] <_mup_> Bug #806179: PersonPickers broken from bad passed in config <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/806179 >
[08:17] <LPCIBot> * Launchpad Patch Queue Manager: [r=deryck][bug=740208] obfuscated email addresses for anonymous
[08:17] <LPCIBot> webservice requests
[08:17] <LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][bug=802840] Ignore None component/section on sync upload
[08:17] <LPCIBot> source override.
[08:17] <LPCIBot> * Launchpad Patch Queue Manager: [r=stevenk][rollback=13356] Rollback revision 13356.
[08:17] <StevenK> Bah, sorry.
[08:17]  * StevenK smacks LPCIBot.
[08:17] <wgrant> lifeless: Possibly interesting is that one of my parallel LXC workers hangs most times.
[08:18] <wgrant> lifeless: Only one.
[08:18] <lifeless> wgrant: fun
[08:18] <wgrant> lifeless: And the whole suite passes if not run with --parallel
[08:18] <lifeless> wgrant: you're doing aufs isolation right ?
[08:18] <wgrant> lifeless: This is with aufs, yes.
[08:18] <lifeless> wgrant: that jenkins job isn't, so its much more fragile
[08:19] <wgrant> Sure.
[08:19] <wgrant> rvba: You installed rabbitmq-management by grabbing the .ez files from the website and installing them manually?
[08:20] <rvba> wgrant: Yes.
[08:21] <rvba> Installing=moving the files to /usr/lib/rabbitmq/lib/rabbitmq_server-version/plugins
[08:24] <wgrant> Yeah.
[08:35] <wgrant> rvba: How is your JS branch going?
[08:36] <rvba> wgrant: the generic part is up for review. https://code.launchpad.net/~rvb/launchpad/lp-app-longpoll-js/+merge/66936
[08:36] <wgrant> Ah, excellent.
[08:36] <rvba> The remaining parts (that I shall address after the DD work is finished) are:
[08:37] <rvba> - fix up a service for the async frontend
[08:37] <rvba> - use the generic stuff in the MP page (this will be just cleaning up the prototype that we've done in Dublin)
[08:44] <wgrant> lifeless: Only 2.2.0 is in lucid-cat-landscape. That's just new enough that I can probably get this plugin stack backported to it. But natty's 2.3.1 backports to lucid fine without even a rebuild, and I'm not sure if 2.2.0 will work for us.
[08:44] <wgrant> I guess I should test.
[08:51] <jtv> Anyone mind if I kick dogfood?  bigjools, StevenK, wgrant?
[08:51] <wgrant> Not I
[08:51] <bigjools> jtv: are you updating it?
[08:51] <jtv> Yes
[08:52] <bigjools> cool, was gonna do that anyway
[08:52] <StevenK> I updated it a few hours ago
[08:52] <StevenK> So you may not need to
[08:52] <bigjools> jtv: remember which user you're supposed to use ;)
[08:52] <jtv> I made doing it right easier than doing it wrong, remember?
[08:52] <lifeless> jtv: hi
[08:52] <jtv> hi lifeless — saw your note, thanks for that.
[08:52] <lifeless> jtv: I'd love to know what I missed
[08:53] <lifeless> jtv: (I'm assuming you tried that and it didn't work...)
[08:53] <jtv> Oh, no.  My query was just a quick scribble on a late-night train.  :)
[08:54] <lifeless> I have an observation about postgresql - if there is an ORDER BY matching an index, pg will almost exclusively use it
[08:54] <jtv> Which makes a lot of sense.
[08:54] <lifeless> so if you order by id with a date constraint, it will use the primary key index
[08:55] <jtv> Yes, I was simply too focused on getting to the id side of things when I wrote that version.
[08:55] <lifeless> jtv: I think the heuristic is too strong, but I haven't had the time to dig into what/why is going on
[08:55] <jtv> Well... it can save you some very painful plan nodes such as hash joins.
[08:55] <lifeless> jtv: anyhow, it means that I now have a spinal reflex: to force an index, order by it
[10:43] <LPCIBot> Project db-devel build #701: STILL FAILING in 5 hr 41 min: https://lpci.wedontsleep.org/job/db-devel/701/
[11:23] <jtv> lifeless: I think I just remembered why I wrote that query the way I did… it performs reasonably for reasonable inputs even without the new index.  The simpler version is abysmal without the index no matter what the input is.  I think I'll land it my way in devel and then do it your way in db-devel after adding the index.
[11:25] <jtv> No, that wasn't it.  :(
[11:27] <jtv> It's been said so many times: if only the statistics would recognize monotonic columns.  :(
[11:28] <bigjools> jtv: fancy doing a review?
[11:29] <jtv> bigjools: if it's not too big
[11:29] <bigjools> ~280 lines
[11:29] <bigjools> but a lot of refactoring
[11:30] <bigjools> https://code.launchpad.net/~julian-edwards/launchpad/set-previous-series-bug-805913/+merge/66942
[11:30]  * jtv has at it
[11:30] <bigjools> jtv: the previous_series stuff that I mentioned earlier
[11:30] <bigjools> ta
[11:30] <jtv> ah yes
[11:30] <lifeless> jtv: we can add the index live
[11:30] <jtv> oh that'd be great
[11:31] <jtv> do we have a Procedure for that yet?
[11:31] <lifeless> jtv: land it on devel with a non -0 patch number
[11:31] <bigjools> lifeless: slony copes with index changes now?
[11:31] <lifeless> normal review (stub + me for db, launchpad-reviewers for the code changes), and stub or a losa can create the index live at any point
[11:31] <jtv> So the -0 patches go out as db-devel rollouts?
[11:32] <lifeless> yeah
[11:32] <spiv> danilos: I see https://code.launchpad.net/~danilo/launchpad/expander-anim isn't proposed for merging yet... what's the delay?  https://code.launchpad.net/~spiv/launchpad/bmp-inline-diffs/+merge/66634 depends on it.
[11:32] <lifeless> so the plan is to make -0 verboten
[11:32] <spiv> danilos: I'd like to get my shiny diffs landed :)
[11:32] <lifeless> jtv: https://dev.launchpad.net/Database/LivePatching
[11:32] <danilos> spiv, I'll be getting it landed today, some tests missing still
[11:32] <jtv> lifeless: ta
[11:32] <lifeless> bigjools: slony doesn't see the index
[11:32] <spiv> danilos: woo!
[11:32] <lifeless> bigjools: what we do is CREATE INDEX CONCURRENTLY on all the replicates
[11:32] <lifeless> s/tes/s/
[11:33] <spiv> Cool, I'll nag people to review mine tomorrow then.
[11:33] <bigjools> ah ok
[11:33] <lifeless> master first if its an index that can fail (e.g. UNIQUE), then the readonly replicas
[11:33] <stub> bigjools: Slony doesn't care about indexes. it does care about constraints, which are sometimes tied up with the indexes.
[11:33]  * lifeless hands over to stub
[11:33] <lifeless> I get up in 6 hours :(
[11:34] <bigjools> furry muff
[11:34] <lifeless> jtv: anyhow, moral of the story is the index can be made live right now if needed.
[11:34] <jtv> great news
[11:34] <lifeless> halt()
[11:34] <bigjools> lifeless: night, see you at 6am :)
[11:35] <bigjools> unless you meant move the meeting TODAY?
[11:35] <lifeless> bigjools: that would be wonderful but I left the suggestion too late I think :)
[11:35]  * lifeless puts hand to forehead, palm out
[11:44] <danilos> spiv, also, fwiw, you can land your branch without depending on mine, and mine will seamlessly provide nice animations for you when it lands :)
[11:47] <spiv> danilos: well, mine merged from yours, so I can't easily land it without landing yours too :)
[12:57] <LPCIBot> Project devel build #867: STILL FAILING in 5 hr 47 min: https://lpci.wedontsleep.org/job/devel/867/
[13:06] <deryck> Morning, all.
[13:07] <abentley> deryck: Morning.
[13:07] <bigjools> +N  dist/rabbitfixture-0.2.1.tar.gz
[13:07] <bigjools> +N  dist/rabbitfixture-0.3.tar.gz
[13:07] <bigjools> :(
[13:12] <jcsackett> morning, all.
[13:12] <jcsackett> wgrant: you still up, by any chance?
[13:12] <deryck> Morning, jcsackett
[13:16] <jtv> bigjools: some problems with your branch I'm afraid.
[13:16] <jtv> See MP.
[13:17] <bigjools> jtv: music to my shell-like
[13:17] <jtv> sorry
[13:17] <jtv> Not tufted?
[13:18] <bigjools> jtv: I don't understand your comment
[13:18] <jtv> Archer ref.  Think ocelot.
[13:18] <wgrant> jcsackett: Hi
[13:19] <bigjools> jtv: not that one, the one in the MP
[13:19] <wgrant> allenap: Do you have any more changes to rabbitfixture planned?
[13:19] <jtv> bigjools: which comment?  I've been a little distracted by something or other wrong with my innards, so I may be talking nonsense.
[13:19] <jcsackett> wgrant: hi. i see you pinged me last night--was it just about the rollbacks, or something else?
[13:20] <bigjools> jtv: "you seem to test for the presence of a release date as an implicit side effect of SQL comparison semantics for nulls"
[13:20] <allenap> wgrant: No, none yet. What have you got planned?
[13:20] <bigjools> jtv: also you didn't read my blurb properly
[13:20] <jtv> bigjools: oh, that one.  Well, you seem to rely on "DistroSeries.date_released < foo" to filter out DistroSeries whose date_released is null.
[13:20] <jtv> Ah.
[13:20] <wgrant> jcsackett: Just the rollback.
[13:20] <bigjools> else you'd not have made the second comment :)
[13:20] <jcsackett> wgrant: dig.
[13:21] <wgrant> allenap: A trivial change to make it more robust against suboptimal /etc/hosts configs, and a more involved and as-yet unwritten one to use rabbitmq-management for cheap reset.
[13:21] <bigjools> jtv: self.context.series[0] is correct, see the "addendum"
[13:21] <allenap> wgrant: Tip top.
[13:23] <bigjools> jtv: ok so I need an extra "Not(DistroSeries.datereleased is None)" clause?
[13:23] <wgrant> != None!
[13:23] <bigjools> whatever
[13:23] <wgrant> Storm can't override is.
[13:23] <wgrant> So that will, er, not do what you want.
[13:24] <bigjools> I hate Storm
[13:24] <jtv> In Storm you say != None.
[13:24] <bigjools> I am going to start writing store.execute everywhere
[13:24] <bigjools> sigh
[13:26] <al-maisan> bigjools: :)
[13:26] <bigjools> al-maisan: yes, something you can appreciate :)
[13:27] <al-maisan> well, I had moments when I thought the same :)
[13:28] <bigjools> hehe, I don't hate it really, but there are some weird bits
[13:28] <al-maisan> like with every tool in existence
[13:31] <deryck> abentley, ping for new standup time.
[13:34] <bigjools> jtv: http://pastebin.ubuntu.com/638897/
[13:34] <matsubara> anyone that could help me out with a test failure I got (https://pastebin.canonical.com/49400/) for this branch: https://code.launchpad.net/~matsubara/launchpad/39605-bugtask-tooltip/+merge/66928?
[13:34] <matsubara> I'm not sure how to keep the query count under the limit
[13:42] <stub> matsubara: I'm seeing a number of Person rows being retrieved one at a time. Pulling them in a batch will shave off some queries.
[13:43] <stub> matsubara: Similarly BugActivity, Milestone and BugWatch
[13:44] <matsubara> stub, hmm this is probably the for loop iterating on activities.order_by(Desc('datechanged')), right?
[13:44] <stub> Maybe some code traversing attributes causing late loading of database objects? Pull them into the cache earlier.
[13:44] <stub> matsubara: I don't know. I just skimmed the SQL log looking for repeated stuff.
[13:45] <matsubara> stub, how can I pull everything I need on a single query?
[13:48] <jtv> stub o/
[13:48] <stub> person_ids = [activity.personID for activity in activities if activity.target == targetname]
[13:48] <stub> store.find(Person, Person.id.is_in(person_ids)
[13:48] <stub> matsubara: That might do it
[13:48] <stub> jtv: o/
[13:49] <jtv> stub: just wrote a "lightweight patch" for the schema, but find that "make schema" breaks because of a CREATE INDEX CONCURRENTLY.  Should I do it conventionally (non-concurrently) in the patch?
[13:49] <jtv> Ah, I think I see that in the documentation now.
[13:49] <matsubara> thanks stub, I'll give it a try
[13:49] <stub> jtv: Don't put the concurrently in there. I add it in when applying stuff manually
[13:49] <jtv> It's a bit difficult to make out what's relevant for development and what for deployment.
[13:49] <wgrant> stub, matsubara: There's a helper for that: load_related.
[13:50] <stub> jtv: Just a normal patch ending with something other than -0. I do the rest.
[13:50] <matsubara> wgrant, cool. I'll look for it
[13:50] <wgrant> matsubara: However, the important thing is not to do this in a single query, but in a constant number of queries.
[13:50] <wgrant> matsubara: Which means that you're going to need to calculate it outside BugTask.
[13:50] <wgrant> So the page doesn't scale by number of tasks.
[13:51] <jtv> stub: I don't see any other traces of lightweight patches in devel, of self-assigned revision numbers.  Am I doing it wrong or am I getting a "first post" on both?
[13:51] <matsubara> wgrant, are there some examples of how that's done somewhere else?
[13:52] <stub> patch-2208-76-1.sql
[13:52] <wgrant> matsubara: There should be a fair bit of it in BugTaskVie
[13:52] <wgrant> +w
[13:53] <stub> or any other of the non -0 patches in the tree...
[13:54] <jtv> stub: I don't see any in devel though — I thought lifeless said it could land in devel.
[13:54] <stub> db-devel
[13:54] <stub> I don't think they can land in devel yet
[13:54] <jtv> argh
[13:54] <wgrant> stub: Didn't you fix the hook?
[13:54] <jtv> Maybe we should just try.
[13:54] <stub> Did I?
[13:54] <wgrant> You certainly asked a LOSA to do it a few weeks back...
[13:55] <stub> I must be running low on drugs
[13:55] <wgrant> Or maybe you only got hold of the config file.
[13:56] <wgrant> https://rt.admin.canonical.com//Ticket/Display.html?id=44724
[13:56] <stub> It must have been terribly exciting. I vaguely recall getting pqm tweaked a while a go but don't recall what the change wass
[13:56] <wgrant> Status: resolved
[14:00] <stub> So yeah, what my frontal lobe extension said.
[14:02] <jtv> stub: can I have db review?  https://code.launchpad.net/~jtv/launchpad/index-798297/+merge/67046
[14:03] <stub> jtv: message__datecreated__idx is preferred naming
[14:03] <jtv> stub: thanks & sorry
[14:03] <jtv> fixing
[14:04] <jtv> stub: done
[14:05] <stub> jtv: So the basic reason we need this is that ORDER BY id DESC sucks when filtering the date range?
[14:06] <jtv> stub: not quite — but it is one of those correlated-columns problems.
[14:06] <jtv> I'm trying to find the oldest Message before a particular timestamp.
[14:07] <stub> Oldest message in what context?
[14:07] <jtv> Sorry, newest.
[14:07] <stub> DistroSeriesDifferenceComments
[14:07] <jtv> I use the id of the newest older-than-X Message to filter the message FKs on DSDComment.
[14:08] <jtv> bigjools: no test for what happens when distroseries.datereleased is null?
[14:08] <bigjools> jtv: look again
[14:09] <bigjools> I inserted an extra series, it is not returned
[14:09] <stub> jtv: The id of the newest older-than-X message will either be max(id) or NULL
[14:09] <jtv> stub: yes, the code is prepared for that
[14:10] <jtv> bigjools: argh, that's hard to see!  Implicit is better than explicit etc.
[14:10] <bigjools> jtv: how explicit do you want?!  It tests that only stuff with datereleased is returned
[14:11] <stub> jtv: I'm just wondering then why you can't do max(id) and throw away the result if it is younger than the cuttoff.
[14:11] <jtv> bigjools: which is the one that isn't returned based on this — ds3 or ds4?
[14:12] <jtv> stub: You mean max(id) WHERE datecreated < foo?
[14:12] <bigjools> jtv: I don't think you understand what is going on here
[14:12] <jtv> Probably not.  Sorry.
[14:12] <stub> jtv: no, max(id). and if the corresponding datecreated is too young replace it with NULL
[14:12] <bigjools> jtv: I shall add more comments and then it will become clear, this is my fault
[14:14] <jtv> bigjools: no need to go all mea culpa.  :)  But I think it would be better to split these issues up into separate tests.
[14:14] <jtv> Translations experience involves repeated headaches and nightmares caused by single-run, multiple-data tests.
[14:14] <bigjools> jtv: I don't think that will help, it will be the exact same tests over and over
[14:14] <jtv> Almost.
[14:14] <jtv> Right?
[14:15] <jtv> stub: I'm afraid I don't follow…
[14:15] <bigjools> in fact they'll be slightly less useful as they won't test real world data
[14:16] <jtv> DistroSeries relationships aren't that intricate, are they?  I would think what the factory spits out is good enough to test for this.
[14:16] <bigjools> it is not
[14:16] <bigjools> the factory is naive
[14:16] <bigjools> on top of this, pulseaudio is pissing me about
[14:17] <jtv> It likes that.
[14:17] <bigjools> what's the ui thing that configs it?
[14:17] <bigjools> I am stuck with output going to speakers even when a headset is plugged in
[14:18] <jtv> Err… KDE Sound Preferences?
[14:18]  * jtv is blatantly bluffing
[14:19] <stub> 'the id of the newest older-than-X message' == message = store.find(Message, ...).order_by(Desc(id)).first(); if message.date_created < X: message = None
[14:19] <jtv> Me, I just shout a lot and hope some neighbour will call the other and say "please tell your friend to be quiet, he keeps shouting PLEASE RESTART DOGFOOD like some crazy person."
[14:19] <jml> bigjools: it's sound preferences in normal Ubuntu. 'pavucontrol' is the one provided by pulseaudio itself.
[14:19] <stub> c/</>
[14:20] <stub> now I'm confused.
[14:20] <bigjools> jml: thanks, I'll try it
[14:20] <jtv> stub: I suspect that I wasn't clear enough in explaining.
[14:20] <jcsackett> is anyone available to review https://code.launchpad.net/~jcsackett/launchpad/button-configs-break-pickers/+merge/67047?
[14:21] <jcsackett> i am happy to review something in exchange. :-)
[14:21] <stub> My antihistamines more likely. Too much grass here.
[14:22] <bigjools> jml: unfortunately no luck.  There is something else somewhere that tells PA what devices to use IIRC
[14:22] <nigelb> bigjools: skype?
[14:23] <bigjools> nigelb: no, as soon as it detects PA it won't use anything else
[14:23] <bigjools> and now phonon won't show me anything else
[14:23] <bigjools> this is infuriating
[14:23] <nigelb> bigjools: see if you can find dtchen in ubuntu-devel, he probably knows more about sound than almost most of us
[14:23] <jtv> stub: I think you're querying for the newest Message, or None if that one is too new.  I'm looking for the newest Message that is older than a specific date.
[14:23] <jml> bigjools: pavucontrol normally does that on the Playback & Recording tabs. I find it hard to believe that Kubuntu shipped without an equivalent
[14:23] <bigjools> nigelb: thanks
[14:24] <stub> jtv: Right, so we need the index. yes.
[14:24] <bigjools> jml: gah, you have to be *in a call" for the option to appear in pavucontrol
[14:24] <jtv> (Since DSDComments are a new thing, I was tempted to hard-code a cutoff number as a shortcut :-)
[14:24] <jtv> What the zark is pavu?
[14:25] <bigjools> kubuntu does it differently
[14:25]  * jtv is amazed
[14:25] <jml> bigjools: that sucks. I reckon it would be worthwhile seeking out whatever the KDE equivalent of Gnome Sound Preferences is
[14:25]  * deryck switches work locations, back soon
[14:25] <jml> bigjools: because Sound Preferences actually works in natty.
[14:25] <bigjools> jml: it's the config for phonon - it has a preferential list of devices to use in different scenarios (comms, multimedia, games etc) but they all got replaced by just "pulseaudio
[14:25] <bigjools> :/
[14:26] <bigjools> so it's a lot better than pavucontrol - when it ****ing works!
[14:26] <jml> bigjools: is phonon the central sound control for kde?
[14:26] <bigjools> yes
[14:26] <jml> bigjools: ahh.
[14:26] <bigjools> I need a phonon expert I think
[14:26] <jml> bigjools: see, the gnome sound preferences now (afaict) actually configures pa, and everything uses pa, so it's all win.
[14:27] <jml> bigjools: *nod*
[14:27] <nigelb> jml: When do you make the switch out of LP?
[14:27] <bigjools> the phonon config is supposed to show all the pulse devices too
[14:27] <jml> nigelb: already done
[14:28] <nigelb> jml: Ah! Nice :)
[14:28] <jml> bigjools: so it's buggy?
[14:28] <bigjools> and of course, the next call goes back to the speakers
[14:29] <bigjools> fuck sake
[14:29] <nigelb> This sounds like the time my mic took input from my speaker.
[14:29] <bigjools> jml: well it might be - it was all fine a couple of days ago :/
[14:43] <benji> I need to prepare.  How about I call you in about 5 minutes?  Skype?
[14:43] <flacoste> benji: sure
[14:44] <benji> flacoste: what is your skype user name?
[14:44] <flacoste> benji: fjlacoste
[15:00] <danilos> spiv, to be able to get my branches landed, I had to remove some bits that are in your branches as well (eg. the branch.revisionexpander.js stuff); expect conflicts soon :)
[15:00] <jcsackett> abentley: have room in your queue for https://code.launchpad.net/~jcsackett/launchpad/button-configs-break-pickers/+merge/67047?
[15:00] <abentley> jcsackett: sure.
[15:00] <jcsackett> thanks.
[15:05] <jtv> danilos: getting more fallout from that Google bug we discussed.  It's like half of India is trying to create mail accounts for me.
[15:06] <jtv> (I know, half of India is a lot of people but… ever break a spammer's mailbox and see their ability to send email crumble to dust?)
[15:20] <abentley> deryck: I am looking into https://code.launchpad.net/~matsubara/launchpad/39605-bugtask-tooltip/+merge/66928 and BugActivity scares the hell out of me.
[15:20] <matsubara> abentley,thanks for looking that merge proposal but adeuring already reviewed it
[15:21] <deryck> abentley, yeah, it can be a bit hairy.
[15:21] <matsubara> it wouldn't hurt to have some additional feedback though :-)
[15:21] <deryck> abentley, not to mention, it's such a pain to get any useful info from it.
[15:22] <abentley> matsubara: why did adeuring review it?
[15:23] <adeuring> abentley: matsubara asked me :)
[15:23] <matsubara> abentley, I asked him on #launchpad. I looked at the topic and saw his name there and thought he was the OCR
[15:23] <abentley> matsubara: ah.  No, I am.
[15:24] <matsubara> by the time I noticed that, adeuring already had done the review
[15:24] <abentley> matsubara: adeuring's review looks similar to what I was in the middle of writing.
[15:24] <matsubara> cool. I'm working on the changes
[15:26] <abentley> matsubara: This is what I was going to propose: http://pastebin.ubuntu.com/638927/
[15:31] <abentley> matsubara: Actually, ISTM that you should just grab all bug activities and find the latest for a given whatchanged string.  You can answer all information about what changed then without further queries.
[15:31] <abentley> matsubara: Since I assume you care about all bug tasks on that bug.
[15:32] <matsubara> yep
[15:34] <danilos> jtv, yay google ;)
[15:37] <abentley> jcsackett: Was "hacro" a deliberate combination of "macro" and "hack"?
[15:38] <jcsackett> abentley: as i don't remember ever typing that, i would say it's more likely a typo. but if you like it, we can pretend it was intentional. :-P
[15:38] <jcsackett> abentley: i think it's probably best that i fix that comment, though. :-)
[15:40] <abentley> jcsackett: also the "a a".
[15:40] <jcsackett> abentley: indeed.
[15:45] <abentley> jcsackett: bzr gannotate shows that the unused mailing_list is hysterical raisins.
[15:53] <abentley> jcsackett: I'm not very comfortable with having "true" and "false" as Python member variables.  Seems like that would be hard to use in Python code.
[15:54] <abentley> jcsackett: I would think you could calculate the whole config server-side and then simplejson.dumps it.
[15:59] <jcsackett> abentley: i suppose you could--this branch is just a quick fix to get the other personpicker stuff fixed quickly. bug 799847 concerns redoing the form-macros stuff so we just put important things in JSONCache and then don't need to do any view/js passing.
[15:59] <_mup_> Bug #799847: form-picker-macros should not do a bunch of manual js assembly <person-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/799847 >
[16:00] <jcsackett> at which point the simplejson.dump would also be unnecessary.
[16:01] <abentley> jcsackett: I don't really understand how you'd use the jsoncache that way.  Would you have one JSONCACHE entry per picker?
[16:02] <adeuring> abentley: your paste is roughly what I had in mind :) But I would remove a given attribute from the set "attributes" once it is found and terminate the loop when the set "attributes" becomes empty
[16:03] <jcsackett> hm. crap, that's actually fair point. benji suggested it once upon a time, but we were looking at a case with only one picker on the page.
[16:03] <jcsackett> still, i think cleaner form-macro stuff is more in scope for that bug (which i'll be addressing sometime shortly).
[16:03] <jcsackett> in my mind, your suggestion (or other implementations) fall in there.
[16:03] <abentley> jcsackett: Okay, fair enough.
[16:04] <jcsackett> abentley: i may well be pinging you to pick your brain for preimp on that bug, if you're game for it.
[16:04] <abentley> jcsackett: sure.
[16:04] <jcsackett> cool.
[16:07] <abentley> jcsackett: This should have tests, though.  I don't think I can approve it without tests that would fail if the Python True and False were used.
[16:08] <jcsackett> abentley: sure, though i'm not sure how to test this without using windmill or something to do app-server + yui.
[16:08] <jcsackett> abentley: and to my knowledge, we don't have the new implementation for those tests in place yet, do we?
[16:09] <abentley> jcsackett: You should be able to render it and check for the strings, no?
[16:09]  * jcsackett headdesks.
[16:09] <jcsackett> yeah, actually, i can just do a view test.
[16:09] <jcsackett> abentley: i will do that. i'm not sure why i was thinking only YUI stuff. :-P
[16:11] <abentley> jcsackett: At 192 of the full diff, it says "instead if" but should say "instead of".
[16:11] <jcsackett> abentley: ack.
[16:12] <abentley> jcsackett: Your XXX should also follow https://dev.launchpad.net/PolicyandProcess/XXXPolicy (currently it lacks a bug)
[16:12] <jcsackett> abentley: so it does.
[16:12] <jcsackett> i'll fix that as well.
[16:13] <jcsackett> in the YUI knowledge sharing thing right now, so changes won't be made until after that.
[16:13] <abentley> Thanks.  Ping me again when it's updated, and I'm sure we can wrap it quickly.
[16:13] <jcsackett> abentley: sounds good, thanks. :-)
[16:26] <LPCIBot> Project db-devel build #702: STILL FAILING in 5 hr 43 min: https://lpci.wedontsleep.org/job/db-devel/702/
[18:06] <cr3> hi folks, has anyone tried building launchpad on oneiric? I'm wondering if you also get this error, probably because of spriteutils: IOError: decoder zip not available
[18:33] <deryck> cr3, I know sinzui runs on oneiric.  I don't know if he had that issues.
[18:33] <deryck> cr3, unfortunately, he's not around this week.
[18:42] <jcsackett> abentley: i have had time to circle back to this mornings review and fix the branch: https://code.launchpad.net/~jcsackett/launchpad/button-configs-break-pickers/+merge/67047
[18:44] <abentley> jcsackett: ACK.
[18:47] <abentley> jcsackett: r=me
[18:47] <jcsackett> abentley: thanks!
[18:48] <jcsackett> lifeless: ping.
[18:49] <lifeless> hi?
[18:50] <jcsackett> hi, lifeless. i've got a question about how to go about landing my fix branch regarding bug 801388 and bug 806179. yesterday you told me to land with rollback, but wgrant already rolled back that branch.
[18:50] <_mup_> Bug #801388: some person pickers show "assign me"/"remove assignee" when that makes no sense <bad-commit-13334> <disclosure> <person-picker> <qa-bad> <ui> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/801388 >
[18:50] <_mup_> Bug #806179: PersonPickers broken from bad passed in config <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/806179 >
[18:51] <jcsackett> so now my branch includes the fixes that wallyworld put in--should i just link it to both bugs and land normally?
[18:51] <lifeless> jcsackett: right, so you can just land normally once you've bypassed the merge.
[18:51] <lifeless> yes
[18:51] <jcsackett> do i need to remove the qa-bad tag on 801388, or will qatagger handle all of that later?
[18:52] <lifeless> we've deployed past it, and its ok (so aren't rolling back)
[18:52] <lifeless> so you can drop the bad-commit tag if you want
[18:52] <jcsackett> ok. thanks.
[18:52] <lifeless> qatagger will replace the qa-bad tag when it sees the commit
[18:52] <lifeless> you can drop it by hand too if you want, but its not needed
[18:52] <cr3> deryck: I finally managed to reproduce on oneiric server but it worked fine on oneiric desktop, strange
[19:20] <lifeless> cr3: missing dep in the brand new world of onei?
[19:21] <abentley> jcsackett: I don't understand the purpose of https://code.launchpad.net/~jcsackett/lpreview-body/body-callback-template/+merge/66125
[19:21] <cr3> lifeless: seems hairier than that, installing ubuntu-desktop didn't solve the problem but I could've sworn spriteutils worked when I installed a fresh desktop
[19:22] <jcsackett> abentley: it may not be a great piece of code--it was my first stab at plugin code. in short, it was to allow a means of specifying a different template for merge proposals than the one that's hardcoded currently.
[19:22] <abentley> jcsackett: Right, but why?
[19:22] <jcsackett> for example, i prefer reST style headers, so i've put together a template that does that.
[19:23] <abentley> jcsackett: We have a standard template that's supposed to be used, and that's what it provides.  If we change to reST headers, then we should update it to use that all the time.
[19:24] <jcsackett> abentley: fair point. i didn't realize the current format was mandated, given many people use different ones. (e.g. sinzui uses one that specifies his rules for a completed branch).
[19:24] <abentley> jcsackett: it may be honoured more in breach than observance, but yes, that's the standard.
[19:25] <jcsackett> abentley: dig. than obviously the merge proposal should not be accepted. :-)
[19:25] <jcsackett> s/than/then/
[19:28] <abentley> jcsackett: thanks.  Rejected.
[19:53] <jcsackett> is there a clear demo of using the expander widget in lp.app.javascript anywhere? i can't find anything that uses it...
[19:53] <jcsackett> but i suspect my grep fu is week.
[19:53] <jcsackett> s/week/weak/
[20:04] <dobey> deryck: boo. my bug is not low. :(
[20:05] <deryck> dobey, then go fix it. We're open source. ;)
[20:06] <deryck> dobey, Seriously, though, I'm sorry this disappoints you. We have way more bugs then we'll ever fix and until this happens more frequently or causes more problems I doubt it will be more than a low bug.
[20:06] <dobey> deryck: if this was the matrix, and i could inject all the knowledge of the launchpad source directly into my skull, i totally would :)
[20:06] <deryck> dobey, fair enough :)
[20:07] <dobey> deryck: well, it actually breaks a feature in tarmac, and therefore blocks branch landing :(
[20:07] <deryck> dobey, sounds like a bug in tarmac to me ;)
[20:08] <dobey> how is launchpad returning bad data, a bug in tarmac?
[20:08] <deryck> dobey, that was largely a joke.
[20:08] <deryck> dobey, though I'm not clear why a person etag matters for landing branches.
[20:09] <dobey> jokes don't work on irc, unless it's "that's what she said" :)
[20:09] <deryck> heh
[20:09] <deryck> dobey, why does tarmac care about the etag?  is it changing something about a person and needs to verify before landing a branch?
[20:10] <dobey> deryck: because we check that people have signed the contributor agreement, via team membership, where cla is required. and lazr.restfulclient checks the etag in its Entry.__eq__ override
[20:10] <dobey> deryck: no, we're not changing the person at all. my bot user doesn't have those privs :)
[20:11] <dobey> but the eq compares self_link, http_etag, and an internal dirty dictionary, and etag being different causes it to fail
[20:11] <dobey> since apparently the person != the person
[20:12] <deryck> dobey, so tarmac code is not referencing the two versions of people, lazr.restfulclient is checking the team member against the person collection for you?
[20:12] <lifeless> dobey: perhaps you could include your sample code?
[20:12] <dobey> well, in tarmac we're getting both objects and just doing ==
[20:14] <dobey> https://bugs.launchpad.net/launchpad/+bug/806163/comments/3
[20:14] <_mup_> Bug #806163: Different http_etag for same person resource when accessed via people collection or team object <api> <Launchpad itself:Triaged> < https://launchpad.net/bugs/806163 >
[20:15] <dobey> the subteam == person there is failing, when it shouldn't be, because of the etag issue
[20:16] <deryck> dobey, so check on ID, not object.  bug in tarmac. ;)
[20:16] <dobey> huh?
[20:21] <deryck> dobey, again a partial joke.  just check on something unique for each user, like self_link or id (if we expose that) rather than doing an object to object comparison.
[20:22] <dobey> well, yes, i could work around it, and have temporarily. but workarounds suck
[20:24] <dobey> but users' accounts being broken is, i think, a more important issue. i'm surprised more people aren't hitting this or similar situations on LP
[20:24] <dobey> although, i don't know why exactly we haven't had an issue until now
[21:08] <wgrant> Morning all.
[21:09] <deryck> Later on, everyone.
[21:14] <LPCIBot> Project devel build #868: STILL FAILING in 6 hr 12 min: https://lpci.wedontsleep.org/job/devel/868/
[21:56] <jcsackett> later, all.
[22:33] <nhandler> Not sure how many people are subscribed to debian-derivatives@lists.debian.org, but there was just some discussion about possibly getting lintian to be run against ubuntu packages in Launchpad. I just thought it was worth noting here in case anyone with more experience is interested in getting involved in the discussion (although it will probably get brought to your attention soon enough)