[00:05] <sinzui> wgrant: mumble?
[00:08]  * sinzui wanders off to feed children
[00:17] <wgrant> sinzui: Sorry, here now.
[00:20] <sinzui> Hello wgrant. Do you have time to mumble?
[00:21] <sinzui> wgrant: I also want a review of this script to remove projects without any license: http://pastebin.ubuntu.com/606665/
[00:55] <jtv> Has anyone else seen EC2 fail notfound-traversals.txt spuriously?   http://paste.ubuntu.com/606695/
[00:56] <wgrant> jtv: It was not spurious. I broke trunk for a few hours last night.
[01:10] <wgrant> jtv: How did the moldavian deletion go?
[01:10] <wgrant> Ah, the question is gone. That is a good sign.
[01:10] <wgrant> Thanks.
[01:14] <LPCIBot> Project db-devel build #544: STILL FAILING in 5 hr 30 min: https://lpci.wedontsleep.org/job/db-devel/544/
[01:18] <lifeless> -> airport to pick up family; bbiab
[01:44] <jtv> wgrant: broke trunk, eh?  well done!  I was getting nervous because my branch failed twice with different test failures.
[01:50] <wgrant> lifeless: rabbit failed lucid_db_lp
[01:54] <LPCIBot> Project windmill-db-devel build #273: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/273/
[01:56] <LPCIBot> Project devel build #713: STILL FAILING in 5 hr 34 min: https://lpci.wedontsleep.org/job/devel/713/
[02:23] <LPCIBot> Project windmill-devel build #75: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/75/
[02:49] <jtv> lifeless, back?
[02:59] <wgrant> Hmm, only 541 timeouts yesterday?
[03:00] <wgrant> I guess UDS might be reducing it a bit... but 50%?
[03:08] <jtv> wgrant: how does it compare to previous UDSes?
[03:09] <LPCIBot> Project windmill-devel build #76: STILL FAILING in 45 min: https://lpci.wedontsleep.org/job/windmill-devel/76/
[03:16] <jtv> wgrant: I see you added a qa-untestable tag to my bug just around the time the tagger was supposed to add a qa-needstesting to it.
[03:17] <jtv> It's actually qa-ok, but I wanted to avoid concurrency issues.
[03:17] <wgrant> jtv: Well, you removed the needstesting tag which upsets qa-tagger.
[03:17] <wgrant> You can't remove QA tags until the revision is deployed.
[03:19] <wgrant> Also, why was the tagger meant to add qa-needstesting?
[03:19] <wgrant> It had already, but you removed it.
[03:20] <wgrant> And the next buildbot run won't finish for half an hour, and then an hour later it will tag the two involved bugs, neither of which are yours.
[03:20] <wgrant> So, I am confuse!
[03:20] <wgrant> But I am also hungry, so I shall lunch to resolve my confusion.
[03:20] <wgrant> Or at least defer it.
[03:21] <jtv> wgrant: the first branch was deployed, and the second was going to be deployed.
[03:21] <jtv> Both on the same bug.
[03:25] <lifeless> jtv: yes
[03:25] <jtv> lifeless: didn't know how far a drive it was etc. :)  Trust all is well.
[03:26] <jtv> I wanted to ask for feed back
[03:26] <lifeless> yup
[03:26] <jtv> *feedback
[03:26] <jtv> about the UI work I'm sketching out for async package syncs.
[03:26] <lifeless> sure, I'll be passing by the keybard for a bit, and once folk are settled, fully here.
[03:27] <jtv> OK, I'll start typing.  :)
[03:27] <jtv> We have a Job for sync'ing packages into a derived distro.
[03:27] <wgrant> jtv: I still don't understand why the qa-needstesting tag was removed. But it seems all OK  now.
[03:28] <jtv> There's a UI that shows differences between a derived distroseries and its parent(s).
[03:28] <jtv> That's where you can request that some of these differences be synchronized, in various ways.
[03:28] <jtv> Some or all of these requests will be asynchronous.
[03:29] <jtv> At first I tried to sketch out a way where the UI remembers "you requested async sync of packages [x, y, z]; these went into jobs {a: [x], b: [y, z]} (one job per source archive, but potentially multiple packages per job)
[03:29] <jtv> "
[03:30] <jtv> But it's costly and awkward and ignores other pending requests.
[03:30] <jtv> If you try to repeat a sync, you get an error.
[03:30] <jtv> (I'm not too enthusiastic about that notion, but there may be good reasons just outside my current field of view).
[03:31] <jtv> I want to break this down into stages that I/we can implement in realistic time: basics first, shiny later.
[03:32] <jtv> My current plan: have the static page always (request or no request) show which of the visible distroseries differences have sync jobs pending.
[03:32] <jtv> (Polling and error reporting come later)
[03:33] <jtv> Since it makes no sense to repeat a pending sync request, I was thinking to _replace_ the checkbox next to a difference that's waiting to be synced away with a little watch as used elsewhere.
[03:33] <wgrant> Is that feasible in the current model?
[03:34] <jtv> I don't know.
[03:34] <wgrant> (it's the right thing to do, but I don't think it's efficiently doable without a separate jo)
[03:34] <wgrant> +b
[03:34] <jtv> I think you're talking about finding out which jobs are pending.  I'm talking about the UI.
[03:35] <wgrant> We unfortunately already have a model to work within, and that needs to influence the UI decisions :(
[03:35] <jtv> Yes yes yes I know.  But there is _some_ specificity to the search and I'm assured the queue won't be very large.
[03:35] <wgrant> It will fairly often have thousands of packages.
[03:36] <wgrant> But not terribly many jobs, perhaps.
[03:36] <jtv> Packages aren't where the cost is.
[03:36] <jtv> Other ways to find this out quickly lead to extra client/server interactions, which I expect to be much more costly.
[03:38] <jtv> We know which jobs and which destination archive we're interested in when we render the page, and that helps; no need to send an API request from the client after rendering, listing the packages you're interested in.
[03:39] <jtv> It may also be slightly jarring to have your view changed too long after the page has rendered, possibly with consequences for the placement of widgets you're about to click on.
[03:40] <lifeless> so
[03:40] <lifeless> with queues, in general, we shouldn't assume we can tell whats in the queue
[03:40] <lifeless> this is a rabbit limitation AIUI, and though we don't use rabbit today, I'm leery of depending on things we know it doesn't know
[03:41] <jtv> Sensible, but I have a feeling that a lot will go overboard when we do that anyway.
[03:42] <jtv> Most of the wait, for one.
[03:42] <lifeless> well
[03:42] <lifeless> the latency is 60 seconds for a job runner
[03:42] <lifeless> nevertheless
[03:42] <lifeless> lets talk concurrency for a second
[03:42] <lifeless> two users may both submit a request to sync overlapping packages at the same time
[03:43] <lifeless> unless we are -very- careful in our model, we won't trigger unique constraints
[03:43] <lifeless> not sanely
[03:43] <lifeless> I think if someone wants package version X synced from A to B
[03:43] <lifeless> and its queued twice
[03:43] <lifeless> shrug
[03:43] <lifeless> let the second sync say 'noop, DONE'
[03:43] <lifeless> IMNSHO
[03:43] <jtv> Sure, but...
[03:44] <lifeless> in other words, make syncing an idempotent operation
[03:44] <jtv> shrug
[03:44] <jtv> Been over that for about as much as I feel we need to right now.
[03:44] <wgrant> It's not quite that simple.
[03:44] <lifeless> jtv: ok
[03:44] <wgrant> Because binaries are fun.
[03:44] <jtv> I'm saying it doesn't make much sense to request a repeated sync; not that I want to avoid it at all costs.
[03:45] <jtv> I was just thinking it might be a minimally invasive, yet effective way of expressing the situation: don't bother requesting a sync here, it's already pending.
[03:47] <lifeless> so, internet fail
[03:48] <jtv> Thank you, Natty, for leaving a loophole that gives me access to the "reconnect" button on my chat client that you think I don't want to access ever.
[03:49] <lifeless> :>
[03:50] <jtv> To repeat then:
[03:50] <jtv> In the current pre-rabbit situation, this way of doing it has the advantage of making the first step in providing async visibility very easy to implement.
[03:52] <jtv> The main questions for that are, I think: (1) does this display help the user at all?  (Actually I'd also want some kind of "sync pending" notice in there, obviously) and (2) does it form any kind of usable basis for the later steps (tracking progress, reporting errors) if we should decide to drop the jobs and use rabbit instead?
[03:53] <jtv> If we later find that it becomes too difficult to mark pending syncs in the static page, we can always drop that bit.  But I would hope that unless and until that happens, the work will have helped us move closer to a "nice" UI.
[03:55] <jtv> Trying to do a "nice" UI right away would probably involve making the whole sync request Ajaxy to track the jobs it created (if any), which goes at the cost of getting the first bit of visibility into pending requests usable later than with this approach.
[03:56] <lifeless> I'm agnostic here
[03:56] <lifeless> I can see merits in both approachs
[03:56] <lifeless> I agree that they are to some degree at cross purposes
[03:56] <lifeless> I think from an adminny perspective we want to know about things stuck in the queue
[03:56] <lifeless> and to be able to fix (e.g. in the current code do a cancel) them
[03:58] <jtv> Well if a job fails, it fails.
[03:59] <jtv> If it's stuck, the whole queue is stuck.
[03:59] <jtv> (Which should show up as oopses, I guess, though my UI would also show it as an increasing amount of pending differences in the display)
[04:00] <jtv> We'd lose that advantage with rabbit I guess, but maybe at that point we'd just accept having to replace that visibility with something as a cost of moving ahead, and my current idea will have served its purpose as a stepping stone.
[04:02] <jtv> I hate being under the weather on a holiday.
[04:02] <lifeless> its a holiday?
[04:02] <jtv> Well my girlfriend says it is.
[04:03] <jtv> Can't find it online, but here you're never sure about those things.
[04:03] <jtv> We do have something different next week, but my web searches put it at up to 3 different days this year, at a length of either 1 or 2 days.
[04:03] <jtv> Nondeterministic calendars are a great job-security scheme for religious establishments.
[04:03] <thumper> I think Thailand has more holidays than any other place I know
[04:04] <jtv> I try not even to register the slightly iffy ones ("government holiday" etc.) but when you get right down to it, there's a vast sea of iffy holidays.
[04:05] <jtv> I believe in rare cases the official word comes down literally the day before.
[04:05] <jtv> Not to mention curfews and such.
[04:11] <lifeless> bah
[04:11] <lifeless> where is that bug about the 404 for pages depending on vhost
[04:14] <jtv> Damn, can't search for "404"!
[04:14] <jtv> bug 422960?
[04:14] <_mup_> Bug #422960: appear to be failing to record oops for all +translate HTTP 503 errors <canonical-losa-lp> <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/422960 >
[04:15] <jtv> bug 626878?
[04:15] <_mup_> Bug #626878: pages only on subdomains cause user confusion (e.g. launchpad.net/project/+activereviews is a 404) <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/626878 >
[04:15] <jtv> bug 574697?
[04:15] <_mup_> Bug #574697: Launchpad strips incoming TE header <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/574697 >
[04:20] <lifeless> #626878:
[04:20] <lifeless> thanks
[04:20] <_mup_> Bug #626878: pages only on subdomains cause user confusion (e.g. launchpad.net/project/+activereviews is a 404) <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/626878 >
[04:21] <jtv> Used google with site:
[04:22] <lifeless> 'None' is a subscriber to this bug apparently
[04:23] <wgrant> lifeless: I think your Chromium is bad :(
[04:23] <lifeless> wgrant: probably; how so?
[04:24] <wgrant> Well, BjornT is not None.
[04:24] <lifeless> wgrant: different bugs
[04:24] <wgrant> And the recipe owner picker works for everybody else.
[04:24] <lifeless> bug 735972
[04:24] <_mup_> Bug #735972: Person:+related-software timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/735972 >
[04:25] <wgrant> (can I close that picker bug now?)
[04:25] <lifeless> wgrant: give me a chance to dup
[04:25] <lifeless> it takes a while to reopen 70 or so tabs
[04:25] <lifeless> so I've been being productive in the meantime
[04:26] <wgrant> Heh
[04:26] <lifeless> openid soooooo slow
[04:26] <lifeless> (well, our sso is)
[04:30] <lifeless> oh man +related-software has lots of room to improve
[04:42] <lifeless> ughhhh
[04:42] <lifeless> I can't find this darn bug
[04:42] <lifeless> the one about bzr push not being able to create a spn
[04:43] <wgrant> Bug #386596
[04:43] <_mup_> Bug #386596: pushing to a packaging branch can't create a new package <codehosting-ssh> <lp-code> <package-branches> <Launchpad itself:Triaged> < https://launchpad.net/bugs/386596 >
[04:43] <lifeless> hth
[04:43] <lifeless> thanks
[04:43] <wgrant> Found using Launchpad's search, even.
[04:44]  * wgrant stabs asuka.
[04:44] <wgrant> Update faster.
[04:44] <lifeless> thanks!
[04:44]  * lifeless escalates
[05:17] <lifeless> whats a sensible fs for an archive mirror?
[06:25] <lifeless> stub: so, yo
[06:26] <stub> lifeless: yo
[06:26] <lifeless> shall we try skynet?
[06:27] <stub> I'm going to boot my laptop to try and narrow down issues - there is some other weirdness happening with that network card and natty.
[06:27] <lifeless> ok
[07:08] <LPCIBot> Project devel build #714: STILL FAILING in 5 hr 11 min: https://lpci.wedontsleep.org/job/devel/714/
[07:14] <StevenK> Is that more rabbit failure?
[07:14] <StevenK> Why, yes, it is.
[07:18] <wgrant> StevenK: That happened on lucid_db_lp earlier.
[07:20] <StevenK> I've come to the conclusion that rabbit sucks, and I can't get it to start on the Jenkins build slaves. Not sure why that afflicts buildbot.
[07:22] <wgrant> lifeless: "Ubuntu currently has a problem with things that haven't built yet being unable to have bugs filed on them"
[07:22] <wgrant> Huh?
[07:22] <wgrant> It's got nothing to do with builds.
[07:24] <lifeless> StevenK: https://bugs.launchpad.net/launchpad/+bug/655385/comments/14
[07:24] <_mup_> Bug #655385: Allow bug status change from Triaged only for bug supervisor <accesscontrol> <acl> <bugs> <lp-bugs> <Launchpad itself:Opinion> < https://launchpad.net/bugs/655385 >
[07:24] <lifeless> bah
[07:24] <lifeless> stub: https://bugs.launchpad.net/launchpad/+bug/655385/comments/14
[07:24] <_mup_> Bug #655385: Allow bug status change from Triaged only for bug supervisor <accesscontrol> <acl> <bugs> <lp-bugs> <Launchpad itself:Opinion> < https://launchpad.net/bugs/655385 >
[07:24] <lifeless> wgrant: orly?
[07:24] <lifeless> wgrant: whats it got to do with?
[07:24] <wgrant> lifeless: It's all source-based.
[07:24] <wgrant> Doesn't go near binaries.
[07:24] <lifeless> wgrant: source publication then ?
[07:24] <wgrant> Yes.
[07:24] <lifeless> fine :>
[07:29] <lifeless> wgrant: so i didn't say builds in that bug
[07:29] <wgrant> Ubuntu currently has a problem with things that haven't built yet being unable to have bugs filed on them
[07:29] <lifeless> wgrant: I said 'published packages', what was wrong with that ?
[07:30] <wgrant> "things that haven't built yet"
[07:30] <lifeless> ah, fixorating
[07:30] <lifeless> thanks
[07:38] <LPCIBot> Project db-devel build #545: STILL FAILING in 5 hr 44 min: https://lpci.wedontsleep.org/job/db-devel/545/
[08:14] <wgrant> Curse you, lifeless! Escalating bugs :(
[08:14] <wgrant> Still, 215 criticals.
[08:15] <wgrant> Well, plus loggerhead, but we don't talk about him any more.
[08:15] <jml> 241
[08:15] <jml> launchpad-project
[08:15] <wgrant> Hm. I see 237.
[08:15] <wgrant> Are there private bugs I cannot see? :(
[08:15] <wgrant> lpstatus also sees 10-15 more than I can.
[08:16] <jml> I see 234 now
[08:16] <jml> yeah, lpstats counts by category
[08:16] <wgrant> Still 237 for me.
[08:17] <wgrant> Ah, so if something is in more than one category it will show it twice?
[08:17] <jml> http://paste.ubuntu.com/606803/
[08:17] <jml> wgrant: exactly
[08:17] <wgrant> :(
[08:17] <jml> (space bar broken, slow typing)
[08:17] <wgrant> jml: Is that anonymous?
[08:17] <wgrant> I know of two private bugs, maybe there is a third.
[08:18] <jml> wgrant: it's not anonymous
[08:19] <LPCIBot> Project windmill-db-devel build #274: STILL FAILING in 1 hr 10 min: https://lpci.wedontsleep.org/job/windmill-db-devel/274/
[08:19] <wgrant> Then why do I see 237 at https://bugs.launchpad.net/launchpad-project/+bugs?field.importance=Critical :(
[08:19] <jml> hmm
[08:19] <wgrant> Possibly multi-task bugs.
[08:19] <jml> I see that too
[08:19] <jml> and 234 on the portlet
[08:19] <wgrant> Indeed.
[08:20] <wgrant> Possibly 237 tasks, 234 bugs.
[08:20] <jml> yeah, makes sense
[08:21] <jml> http://pastebin.ubuntu.com/606805/
[08:21] <wgrant> Anyhow, minor progress.
[08:21] <jml> that's my script
[08:21] <wgrant> We may finally be getting somewhere.
[08:21] <wgrant> Thanks.
[08:21] <jml> wgrant: -44 is awesome
[08:21] <wgrant> I also have four or five other fixes in review.
[08:21] <wgrant> So we nearly made it to 50 for the week.
[08:21] <jml> also, for pie purposes, I'm not counting newly escalated bugs
[08:21] <wgrant> Ah, excellent.
[08:22] <wgrant> They always seemed a bit disenheartening.
[08:22] <lifeless> wgrant: sorry
[08:48] <adeuring> good morning
[08:54] <wgrant> Hmm, isn't hardy desktop EOL'd now?
[08:54] <wgrant> Yes, yesterday.
[08:54] <wgrant> ubuntu-mozilla-daily still builds for it :(
[08:54] <wgrant> And keeps lpia alive.
[08:54] <wgrant> Damn you lpia, damn you!
[08:55] <StevenK> It was announced?
[08:55] <wgrant> A month ago.
[08:55] <StevenK> I think I have a little more hate for lpia than you :-P
[08:56] <wgrant> At least I didn't mention Hildon.
[08:56] <wgrant> Because that would just be mean.
[08:56] <StevenK> HULK SMASH
[09:00] <mrevell> Hello
[09:00] <StevenK> allenap: Morning! Can you look at https://code.launchpad.net/~stevenk/launchpad/generic-overrides/+merge/60730 again?
[09:01] <StevenK> allenap: I think I've addressed your concerns, and have even written you a note.
[09:07] <allenap> Morning StevenK, sure I'll look at that now.
[09:08] <wgrant> Bah.
[09:08] <StevenK> wgrant?
[09:08] <wgrant> allenap, jtv: Your packagecopyjob changes have conflicted in stable->db-devel.
[09:08] <wgrant> Could be a bit of a mess.
[09:08] <jtv> Thanks for the notice.
[09:08] <wgrant> StevenK: I'm reasonably happy with your branch now.
[09:09] <jtv> What does tradition dictate?  Gloves or no gloves?
[09:09] <allenap> wgrant: Woohoo. Okay, I'll look in a minute, thanks for letting me know.
[09:10] <jtv> allenap: I'm checking it out right now
[09:10] <allenap> jtv: Awesome.
[09:10] <StevenK> Which gives allenap more time to read my horrible diffs.
[09:11] <wgrant> Bah, there's no functools.compose.
[09:11] <wgrant> How stupid.
[09:11] <jtv> I haven't had to deal with this in the current devel/db-devel configuration... can I still branch off db-devel, merge in devel, resolve conflicts, and land into db-devel?
[09:11] <wgrant> jtv: Merge in *stable*.
[09:11] <wgrant> jtv: But yes.
[09:11] <jtv> ahhh
[09:11] <wgrant> Otherwise you'll preempt buildbot.
[09:11] <wgrant> And make us all sad.
[09:11] <jtv> Hmmm conflicts don't look very bad from here.
[09:11] <wgrant> There is an apparent argument reordering.
[09:12] <jtv> Oh that
[09:12] <wgrant> The visible conflict is easily resolvable.
[09:12] <wgrant> But there may be deeper things.
[09:12] <wgrant> The change suggests that arguments have changed.
[09:12] <wgrant> Or that there may be additional IPackageCopyJobSource callsites.
[09:12] <wgrant> When it's now IPlainPackageCopyJobSource, and in a different module.
[09:12] <jtv> I switched two params around in the interface to make them match the implementation order.
[09:13] <jtv> Should have fairly minimal impact but oh, the trouble I had once with this kind of inconsistent parameter ordering between interface and model...
[09:15] <wgrant> StevenK: Hm, why do you eager load BPN and SPN?
[09:16] <wgrant> StevenK: Given that you get the IDs from the objects, you presumably have them already.
[09:16] <StevenK> "lol"
[09:17] <StevenK> I can just return the source object directly
[09:17] <jtv> Oh blast I may lose connectivity.
[09:17] <wgrant> I also question the way you are given archtags and return DASes, but that may possibly be reasonable.
[09:18] <StevenK> wgrant: Because FromExistingOverridePolicy does it too
[09:18] <wgrant> But you wrote that as well, so you can't reason against it :P
[09:18] <StevenK> Oh, clearly
[09:20] <StevenK> Sigh. Now calculateSourceOverrides() for UnknownOverridePolicy is 2 lines.
[09:21] <wgrant> Why so many?
[09:21] <wgrant> Oh, for default_component?
[09:21] <StevenK> Yes
[09:22] <wgrant> cronscripts/foaf-update-karma-cache.py upsets me.
[09:23] <StevenK> +4, -16. I am an idiot
[09:23] <wgrant> adeuring: Hi!
[09:23] <adeuring> hi wgrant!
[09:23] <StevenK> Oh look, an OCR. *pounce*
[09:23] <wgrant> adeuring: https://code.launchpad.net/~wgrant/launchpad/bug-307269/+merge/60721 and https://code.launchpad.net/~wgrant/launchpad/bug-449561/+merge/60729 both need a review, if you could.
[09:24] <adeuring> wgrant: sure
[09:24] <StevenK> allenap: Are you blind yet? I have yet more changes, but I can hold off if you wish
[09:24] <allenap> StevenK: I've just approved it.
[09:25] <StevenK> allenap: Just glance at http://pastebin.ubuntu.com/606829/ then?
[09:27] <allenap> StevenK: Haha, oh yes :) +1
[09:27] <jtv> allenap: few questions about the jobs!  I guess the version in source_packages would correspond to the parent_source_version in the DSD?
[09:28]  * StevenK attempts to not swear about himself or wgrant in the commit message
[09:28] <allenap> jtv: Yes, I think so, but I'll check.
[09:28] <wgrant> StevenK: I didn't write those!
[09:28] <wgrant> Much of the rest, sure...
[09:28] <jtv> allenap: it's also not always clear to me which lists of source-packages tuples are (name, version) and which have the third entry.
[09:29] <StevenK> wgrant: But you pointed it out, so pffft
[09:29] <wgrant> Ah, I see.
[09:29] <allenap> jtv: Yes, I should probably land a branch to remove the ambiguity.
[09:30] <jtv> Heh... you may want to give my existing conflict branch time to settle.  :)
[09:30] <jtv> Any idea what time jools's demo is?
[09:30] <allenap> jtv: Yes, parent_source_version.
[09:30] <jtv> Thanks.
[09:31] <allenap> No, no idea.
[09:31] <jtv> May be useful to be at the ready just prior & during.  ;-)
[09:31] <jtv> Argh!  Natty, stop switching my desktops around!
[09:32] <StevenK> jtv: I was planning on denying everything.
[09:32] <jtv> Good start.
[09:32] <jtv> But you don't know how crafty he is.  He may lead with "Steve implemented this great feature here..."

[09:33] <allenap> wgrant: Btw, what would functools.compose do?
[09:34] <wgrant> allenap: functools.compose(f, g) would basically do lambda *args, **kwargs: f(g(*args, **kwargs))
[09:34] <wgrant> But it was vetoed.
[09:34] <wgrant> Because you can do it with a lambda.
[09:35] <wgrant> Despite the fact that you can do functools.partial even more cleanly with a lambda.
[09:36] <allenap> wgrant: Yes, odd decision.
[09:38] <adeuring> wgrant: one MPP approved.
[09:58] <adeuring> wgrant: your other MP looks good too. just one question: Bug 449561 says not only that anonymous users get the edit icon for the assignee, but also that anon users have the option to use "mark as duplicate". What about this problem? And did you check for other possible edit options presented to anon users, as mentioned in the bug report?
[09:58] <_mup_> Bug #449561: Bug task assignee picker shown to unauthenticated users <api> <lp-bugs> <oops> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/449561 >
[09:59] <wgrant> adeuring: That was fixed at some indeterminable time in the past.
[09:59] <wgrant> adeuring: I can't see any other unguarded JS picker activations on the page.
[09:59] <adeuring> wgrant: ah. cool. so, r=me
[09:59] <wgrant> adeuring: Thanks!
[10:44] <poolie> francis just said he thought question comments were added to the api and curtis blogged about this
[10:44] <poolie> but that doesn't seem to be true...
[10:46] <jml> which bit?
[10:46] <jml> did sinzui not blog?
[10:46] <jml> or are they not in the API?
[10:48] <poolie> both
[10:49] <poolie> neither seems to have happened
[10:49] <poolie> but i might just be missing it
[10:51] <wgrant> jtv: How goes the conflict? My inbox is upset with it.
[10:51] <wgrant> I can have a look if you're busy/gone.
[10:55] <stub> I'm just looking at it
[10:55] <stub> wgrant: Or have you beat me?
[10:55] <jtv> I've had my fix reviewed.
[10:56] <poolie> jml, well, https://bugs.launchpad.net/launchpad/+bug/782093 it can be duped if appropriate
[10:56] <_mup_> Bug #782093: question/answer comments not available in api <api> <questions> <Launchpad itself:Triaged> < https://launchpad.net/bugs/782093 >
[10:57] <lifeless> poolie: https://launchpad.net/+apidoc/devel.html#question
[10:57] <stub> jtv: The merge conflict or something else?
[10:57] <jtv> stub: the merge conflict.
[10:57]  * stub uncommits and leaves it to jtv
[10:58] <lifeless> poolie: ah, the questions collection isn't exposed.
[10:58] <lifeless> its controllable, but not exposed.
[10:58] <lifeless> questions are exposed
[10:58] <wgrant> The collection is exposed but not iterable.
[10:58] <lifeless> and the spam control knob is exposed
[10:59] <lifeless> wgrant: https://launchpad.net/+apidoc/devel.html#question has no comments_link
[10:59] <lifeless> wgrant: is that what you mean ?
[10:59] <wgrant> Oh, you said questions collection.
[10:59] <wgrant> The comments collection isn't, no.
[10:59] <lifeless> questions comment collection, I meant
[10:59] <wgrant> Right.
[11:11] <poolie> lifeless: right, the comments
[11:11] <poolie> i thought you closed a bug about this the other day
[11:11] <poolie> but perhaps we were confused baout the comments vs the questions
[11:11] <poolie> anyhow, it would be nice for ISD but is not urgent
[11:11] <wgrant> What does ISD want them for?
[11:11] <wgrant> I thought they had other solutions for RnR.
[11:12] <poolie> apparently they get questions across a lot of projects and they want to summarize them
[11:12] <wgrant> Ahh, so something more sensible this time :)
[11:12] <wgrant> They shouldn't be too difficult to export.
[11:12] <wgrant> Just no point if nobody was going to use them.
[11:15] <poolie> lifeless: in https://bugs.launchpad.net/launchpad/+bug/373078/comments/6 aaron says 'Needs fixing is meant to mean "This is approved but I'd like you to fix X"
[11:15] <_mup_> Bug #373078: code review merge status and docs need clarity, particularly for 'tweak' cases <code-review> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/373078 >
[11:15] <poolie> it's a shame launchpad's own use of them isn't consistent with that

[11:15] <wgrant> I thought Approve with comments meant that :/
[11:15] <poolie> but perhaps that will get fixed
[11:15] <poolie> it seems quite ambiguous and inconsistent across projects
[11:16] <poolie> anyhow i shall try to remember that in future
[11:16] <jtv> Do I land conflict fixes with release-critical then?
[11:17] <wgrant> jtv: No.
[11:17] <wgrant> Does it want it?
[11:17] <wgrant> I '[rs=wgrant][no-qa] Whatever'
[11:17] <jtv> Seems to, yes.
[11:17] <wgrant> I think you are probably misreading it.
[11:17] <jtv> Could well be.
[11:17] <jtv> I hate those messages.
[11:17] <wgrant> It will probably accept release-critical=, but does not require it.
[11:18] <wgrant> What was your commit message?
[11:18] <jtv> And I also hate $#%@ unity hiding my windows from me.
[11:18] <jtv> Hang on
[11:19] <jtv> Manual submission notes: your submission message needs at least one of [r=...] [rs=...] or [release-critical=...] AND at least one of
[11:19] <jtv> Ah, it was the other one that's missing.
[11:19] <jtv> no-qa.
[11:19] <wgrant> Right.
[11:19] <jtv> The next attempt failed for yet other reasons.
[11:19] <wgrant> Even more confusingly, testfix is exempt from no-qa
[11:19] <lifeless> poolie: the labels are a bit arbitrary
[11:19] <lifeless> poolie: aside from that may /mean/, I think a label with 'needs' in it does not communicate 'should' or 'might'
[11:20] <lifeless> poolie: thanks for trying to remember in future
[11:21] <jtv> Well, that seems to be in.
[11:22] <poolie> well, i'm not an authoritative reviewer so semantically i can't say "must" anyhow
[11:22] <poolie> i guess it means "please consider this before merging"
[11:23] <lifeless> mmm, you're in the review team, so the ui shows you as authoritative
[11:23] <lifeless> even if it showed you as community, it seems a courtesy not to send conflicting signals ;)
[11:26] <lifeless> poolie: how has uds been?
[11:29] <poolie> sorry, i just set the status the way i would in bzr
[11:29] <poolie> just wanted to save him needing to hmake a second submission
[11:29] <poolie> good
[11:29] <poolie> sneezy
[11:29] <poolie> ubuflu is in fine form
[11:31] <lifeless> heh, I'm very glad I'm not there then ;)
[11:33] <poolie> interesting session right now about python versions
[11:33] <poolie> mm
[11:33] <jtv> I've been doing this work for too long.  My first reaction to the word "sneezy" was "oh they're planning Ubuntu releases up to S."
[11:33] <poolie> it seems like a lot of things are internal teem meetings
[11:34] <lifeless> poolie: you got me curious, doc/developers/code-review.txt doesn't say how bzr uses votes
[11:34] <lifeless> and points at https://help.launchpad.net/Code/Review
[11:34] <lifeless> anyhow, enough of that
[11:34] <lifeless> 10:30 on friday :)
[11:35] <poolie> the informational or seminar type sessions are not clearly distinguished which means some of them turn out to be less interesting thatn you might think
[11:35] <poolie> up until wednesday the schedule churned a great deal
[11:35] <poolie> it was crazy
[11:35] <poolie> apparently the scheduler in a couple of cases thought it would be clever to schedule things into sessions that had already passed
[11:35] <poolie> look at all that wasted space last monday!
[11:36] <poolie> have a good weekend
[12:53] <LPCIBot> Project windmill-devel build #77: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/77/
[12:56] <LPCIBot> Project db-devel build #546: STILL FAILING in 5 hr 17 min: https://lpci.wedontsleep.org/job/db-devel/546/
[13:26] <gmb> adeuring: Could you take a look at https://code.launchpad.net/~gmb/launchpad/bug-777783/+merge/60910 for me?
[13:32] <adeuring> gmb: sure
[13:32] <gmb> Thanks
[13:33] <wgrant> gmb: Hi.
[13:33] <gmb> wgrant: Wotcher.
[13:34] <wgrant> gmb: I'm gardening our various queues, and noticed that you have two approved, unlanded branches from about 6 months ago.
[13:34] <gmb> Orly?
[13:34] <gmb> wgrant: I'll take a look, thanks for the heads-up
[13:34] <wgrant> First section of https://code.launchpad.net/launchpad/+activereviews
[13:35] <gmb> wgrant: I've marked them both merged (I think they were subsumed by other branches, IIRC). Thanks again.
[13:35] <wgrant> Thanks!
[13:38] <wgrant> jelmer: https://code.launchpad.net/~jelmer/launchpad/publisher-use-debian-2/+merge/45011 appears to have been approved just days prior to your defection to bzr -- should I try to land it, or do you recall why it didn't?
[13:43] <jelmer> wgrant: feel free to land it
[13:43] <jelmer> wgrant, I didn't because I was worried I wasn't going to be able to deal with any fallout
[13:48] <adeuring> gmb: r=me
[13:49] <wgrant> jelmer: Ah, sure. I'll throw it at ec2.
[13:49] <wgrant> Thanks.
[13:50] <sinzui> poolie: jml: I have not made questions usable over the API yet. That is probably 2 branches away from being complete. jcsackett landed feature to hide question comments.
[13:52] <wgrant> sinzui: Hi. I was wondering if you could have a look at the tests in https://code.launchpad.net/~wgrant/launchpad/bug-449561/+merge/60729
[13:53] <sinzui> okay
[14:00] <sinzui> wgrant: I am a little apprehensive about the "client.waits.sleep(milliseconds=1000)" line. Is there an element that we could use "client.waits.forElement" instead?
[14:01] <wgrant> sinzui: That was my question.
[14:01] <wgrant> sinzui: I am checking for the absence of an element that is created asynchronously after page load.
[14:01] <wgrant> I don't know if there is some post-load event that I can hook into.
[14:02] <LPCIBot> Project windmill-db-devel build #275: STILL FAILING in 1 hr 8 min: https://lpci.wedontsleep.org/job/windmill-db-devel/275/
[14:02] <wgrant> sinzui: This is why I waited for you/deryck.
[14:02] <wgrant> 'cause I don't really know how to avoid it.
[14:04] <sinzui> wgrant: can't you use  forElement(HIDDEN_ASSIGN_BUTTON)? forElement is an assert
[14:04] <wgrant> sinzui: That
[14:04] <wgrant> That's how the button is in the HTMl.
[14:04] <wgrant> The JS hook changes it.
[14:05] <wgrant> I am asserting that it does not execute.
[14:12] <sinzui> wgrant: We should at least use lp.testing.windmill.constants.SLEEP so that the test is consistent with other tests
[14:14] <wgrant> I had hoped to catch a deryck of some variety today, but that seems unlikely at this point :(
[14:14] <gmb> adeuring: Thanks for the review.
[14:15] <sinzui> derycks now come in variety packs? I would like a green one please
[14:15] <wgrant> https://lpbuildbot.canonical.com/builders/lucid_lp/builds/942/steps/shell_6/logs/summary is interesting.
[14:16] <wgrant> Is something pruning /tmp a bit aggressively?
[14:16] <wgrant> Both rabbit and lp-serve complain about similar things.
[14:17] <sinzui> wgrant: deryck is listed as on leave in canonicaladmin
[14:18] <wgrant> This is unfortunate.
[14:18] <wgrant> I guess it will have to wait until next week.
[14:18] <sinzui> How can bac be off twice on the same day. If he is time traveling, I would advice not meeting himself. That always causes embarrassment.
[14:22] <sinzui> wgrant: I don't think you need to wait given the large number of SLEEPs I see in windmill tests. Use the constant. That would be my only requirement to land.
[14:23] <wgrant> sinzui: Thanks. I know deryck hates it when people use sleep, but I don't see a clear way around it here.
[14:48] <LPCIBot> Project windmill-devel build #78: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/78/
[14:55] <bigjools> man, LP is fast.
[14:59] <LPCIBot> Project devel build #715: STILL FAILING in 5 hr 30 min: https://lpci.wedontsleep.org/job/devel/715/
[14:59] <StevenK> bigjools: You're not being sarcastic
[14:59] <StevenK> ?
[14:59] <bigjools> StevenK: a first for me, I know
[15:15] <benji> jcsackett: the new comment hide/unhide functionality is nice.  I wonder if we should make the hidden comments collapsed or something so they aren't quite so visible to those of us blessed with the ability to see them.
[15:17] <wgrant> I also think the "Mark as spam" button should probably turn into an icon somewhere near the comment number. But those are just tweaks -- I'm really glad I can remove my scripts now :)
[15:20] <jcsackett> benji: that's a good idea.
[15:21] <jcsackett> wgrant: basically you mean move it from the footer to the header?
[15:21] <wgrant> jcsackett: And make it smaller.
[15:21] <wgrant> It currently stands out a lot.
[15:22] <wgrant> Possibly it should be an edit icon next to the number that brings up the AJAX boolean picker.
[15:22] <wgrant> Like the one used for affects-me-too.
[15:23] <jcsackett> wgrant: not sure about the latter, i'm not a huge fan of multiclick steps for simple actions. but that's a personal preference.
[15:23] <jcsackett> you may be right that it fits lp's flow better that way.
[15:23] <wgrant> Yeah, fair point.
[15:23] <wgrant> It may be OK to just move it to the header.
[15:23] <wgrant> But it's a bit obtrusive at the momnet.
[15:23] <jcsackett> wgrant: yeah, it's a little on the big side now.
[15:24]  * jcsackett makes note to file bugs on both those points.
[15:24] <wgrant> Thanks for all your work on this.
[15:24] <benji> Is the yellow background on "hidden" comments like the one on https://bugs.launchpad.net/launchpad/+bug/1234 common?  It kind of makes the spam stand out, which is ironic. :)
[15:24] <_mup_> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <lp-foundations> <Launchpad itself:Fix Released by debonzi> < https://launchpad.net/bugs/1234 >
[15:24] <wgrant> I'm not sure why a highlight was chosen :/
[15:27] <jcsackett> benji, wgrant: i'm not sure about that either, but the hidden comment style was already established, and i didn't want to mess with css much at the time.
[15:27] <benji> sensible
[15:27] <jcsackett> i think it should be within a branch of work to turn the hidden comment style into a collapsible tho.
[15:28] <jcsackett> bac referred to the style as "eye-gouging" which isn't too far off the mark.:-P
[15:28] <benji> lol
[15:28] <wgrant> Heh
[15:28] <wgrant> Maybe it's there to convince us to stop the spam from arriving in the first place :)
[15:28] <benji> good motivation indeed
[15:28] <jcsackett> i like that theory. it's not ugly, it's "motivational"
[15:28] <jcsackett> :-P
[15:29]  * benji is good at creating "motivational" UI.
[15:29]  * jcsackett laughs.
[15:30] <benji> I guess that gives whole new meaning to "motivational speaker".
[15:30] <jcsackett> by this standard, that would be someone throwing things at you from the stage until you made something of yourself, right? :-P
[15:31] <benji> I think it would be a very unattractive person speaking to you.  I might now qualify to be a motivational speaker.
[15:35] <LPCIBot> Project windmill-devel build #79: STILL FAILING in 47 min: https://lpci.wedontsleep.org/job/windmill-devel/79/
[15:41] <poolie> hi sinzui
[15:42] <poolie> i wasn't trying to rush you
[15:42] <poolie> it was just something that selene raised in a session here at UDS
[15:47] <sinzui> poolie. Okay. I have not announced answers of the API because it is clearly not usable. When I can use it for my projects, and  I will blog about it
[15:49] <jcsackett> sinzui: are you, or do you know, a good person to grab for help on a blueprints question in #launchpad?
[15:51] <sinzui> No is a good person since no-one who wrote it or uses it works on Lp
[15:51] <sinzui> jcsackett: I will see if I can help
[15:54] <poolie> sinzui, i was misinformed and thought they were public
[15:54] <poolie> anyhow, she thanks you for adding them
[15:55] <sinzui> poolie: I think many people misunderstood what was exported to allow admins to hide comments. It was a single method on question, not the actual objects
[16:01] <poolie> yes i misunderstood that
[16:01] <poolie> well,
[16:03] <poolie> i think it's reasonable to want it regardless of your work
[16:03] <poolie> you don't have to do it right now
[16:29] <jcsackett> wgrant, benji, poolie: just wanted to let you know the various feedback has been captured as filed bugs.
[16:30] <benji> great! thanks
[16:30] <jcsackett> poolie: come to think of it, i *think* you provided feedback, i may have mixed up emails. :-P
[16:38] <ToyKeeper> poolie: Thanks for getting that bug in the queue...
[16:40] <ToyKeeper> sinzui: Not trying to rush you; I just mentioned it in a session today and poolie wanted to help.  :)
[16:41] <ToyKeeper> (I'm very happy that questions are being added and I don't have to do it myself!)
[16:42] <sinzui> I am waiting the QA the change that allows me to add and remove my teams as answer contacts. I am starting the branch that lets you search for question in a couple hours
[16:43] <ToyKeeper> My goal is to generate a list of open questions for a given team's projects, without having to check each one manually.
[16:44] <ToyKeeper> ... just making it easier to do support for dozens of projects.
[16:44] <sinzui> ToyKeeper: then we are in  agreement. That is the actual test I am writing. When the test is complete, then I can blog that I have something useful
[16:44] <ToyKeeper> Cool.  :)
[18:18] <LPCIBot> Project db-devel build #547: STILL FAILING in 5 hr 21 min: https://lpci.wedontsleep.org/job/db-devel/547/
[18:24] <jcsackett> sinzui: could you, if you get the time, look at https://code.launchpad.net/~jcsackett/launchpad/apocalyptic-messages-0/+merge/60953?
[18:24] <jcsackett> it's somewhat terrifying, but all mechanical, i believe, and you have a lot of experience with the apocalypse.
[18:42] <sinzui> jcsackett: I am reviewing it now
[18:51] <sinzui> jcsackett: 1. line 1008 shows the addition of the services.message package. I think that list is alphabetical.
[18:53] <sinzui> jcsackett: 2. You create a doc/ dir and moved tests there, but I do not see the test_doc.py that loads the the doctests. I was expecting something like lp.services.mail.tests.test_doc.py
[18:54] <sinzui> jcsackett: did you forget to commit test_doc?
[18:54] <jcsackett> sinzui: i think i may have.
[18:54] <jcsackett> one sec.
[18:55] <jcsackett> sinzui: yup, forgot the all important 'bzr add'.
[18:55] <jcsackett> it's pushed up now.
[18:55]  * sinzui waits
[18:56] <jcsackett> sorry about that, sinzui.
[19:01] <sinzui> jcsackett: message.txt does not look special. It does not have a special setup, teardown or layer. Did you try the generic test_doc.py that is used in mail. I think it will work
[19:01] <jcsackett> sinzui: i don't think so, i just cribbed it from one of the services modules. i'll try out mail's version.
[19:02] <sinzui> also, that test may play DatabaseFunctionalLayer. The layer it is using starts the librarian, which may not be needed
[19:02]  * sinzui reads the test
[19:02] <jcsackett> sinzui: the layer is what it originally had in canonical; that said it may very well work with something else and i'm happy to change it.
[19:03] <sinzui> Almost everything in canonical.launchpad runs on the wrong layer. Always question why a test runs on the LaunchpadFunctionalLayer
[19:06] <poolie> thanks jcsackett, that's a good feature to have
[19:06] <poolie> i'm sure it will save time
[19:25] <jcsackett> thanks, poolie.
[19:25] <jcsackett> sinzui: got it.
[19:25] <sinzui> faboo
[19:25] <jcsackett> Sickn3ss
[19:26] <jcsackett> freaking unity lock up....
[19:27] <LPCIBot> Project windmill-devel build #80: STILL FAILING in 1 hr 9 min: https://lpci.wedontsleep.org/job/windmill-devel/80/
[19:33] <jcsackett> sinzui: the test needs the librarian; it's doing uploads on msgs. i changed the layer and get all sort of upload errors.
[19:34] <sinzui> okay
[19:34] <sinzui> but it does not need a special setup/teardown does it?
[19:34] <jcsackett> nope.
[19:35] <jcsackett> cribbing the test_doc in mail works fine but for the layer.
[19:37] <sinzui> great. r=me the land with that test
[19:39] <jcsackett> sinzui: cool, thanks.
[19:41]  * jcsackett ssh's to reboot his dev machine. again.
[20:17] <LPCIBot> Project windmill-db-devel build #276: STILL FAILING in 49 min: https://lpci.wedontsleep.org/job/windmill-db-devel/276/
[20:26] <LPCIBot> Project devel build #716: STILL FAILING in 5 hr 27 min: https://lpci.wedontsleep.org/job/devel/716/
[21:03] <LPCIBot> Project windmill-devel build #81: STILL FAILING in 46 min: https://lpci.wedontsleep.org/job/windmill-devel/81/
[22:07] <jcsackett> sinzui: i have enabled thumb-click drag on ubuntu on my macbook.
[22:07] <sinzui> \o/
[22:08] <jcsackett> sinzui: follow the instructions here, even tho it is not for the 5-1 macbook.
[22:08] <jcsackett> https://help.ubuntu.com/community/MacBookPro7-1/Maverick#Touchpad
[22:08]  * sinzui reads
[22:09] <jcsackett> you will then need to muck about with sensitivity/acceleration some in the mouse settings.
[22:09] <jcsackett> b/c it becomes VERY speedy moving the cursor around.