[00:47] <lifeless> ok, going quiet to get code written
[01:09] <SpamapS> awesome.. bzr branch of lp:launchpad ... 10 minutes and counting
[01:09] <SpamapS> 271502kB  1130kB/s | Fetching revisions:Inserting stream:Done 1297115/1297115
[01:11] <wgrant> Only 10 minutes? Not bad.
[01:11] <SpamapS> still not done ;)
[01:11] <wgrant> It's nearly done.
[01:12] <wgrant> Here it takes like 2 hours.
[01:12] <SpamapS> 28952 clint     20   0  777m 693m 3820 R  100 17.6   9:49.48 bzr
[01:13] <wgrant> LP's history is not small, and bzr 2a fetch is not fast :(
[01:15] <SpamapS> well 12 minutes wasn't so bad
[01:15] <SpamapS> $ du -hs
[01:15] <SpamapS> 298M	.
[01:15] <wgrant> That's remarkably good.
[01:15] <SpamapS> considering.. :)
[01:15] <wgrant> Are you in the DC or something?
[01:16] <SpamapS> No, I have a 12Mbit downstream tho
[01:16]  * SpamapS hugs his cable
[01:16] <wgrant> I have 20Mbps downstream, but can't get more than 180KB/s from most parts of the DC :/
[01:16] <wgrant> Except to canonistack, where I can saturate my connection.
[01:17] <wgrant> Just to confuse things.
[01:17] <SpamapS> Oh I was definitely saturating the 12Mbit
[01:17] <SpamapS> Some days I can't get 512kbit
[01:18] <SpamapS> but today has been really fast
[01:18]  * SpamapS now begins the task fo figuring out how to populate an unbuilt distroseries via the API.
[01:19] <wgrant> You want to create a new charms series, I guess?
[01:19] <wgrant> What do you want to populate?
[01:20] <cjwatson> Phew.  germinate 2.1 released, MP updated, IMO all good bar the shouting now.
[01:20] <wgrant> Shouting?
[01:21] <cjwatson> About three times the speed of the current implementation, on mawson anyway.
[01:21] <cjwatson> http://dictionary.cambridge.org/dictionary/british/all-over-bar-the-shouting
[01:22] <wgrant> Ah.
[01:23] <cjwatson> Although it wouldn't surprise me if somebody wanted to shout at me about some bits of the test code. :-)
[01:24] <poolie> wgrant, i think there is something odd in the network
[01:24] <poolie> when we measured a while ago we saw substantially faster downloads from another dc machine than from lp itself
[01:24] <poolie> which is a bit perverse
[01:26] <wgrant> poolie: I have an RT ticket open.
[01:26] <wgrant> I was going to blame Optus until I saw that I could download at full speed through the same route up to the DC, except to Canonistack.
[01:26] <wgrant> So unless they're throttling some Canonical /24s and not others, when I've never had any evidence that they're throttling specific ranges at all..
[01:28] <poolie> we've measured the same effect from the US
[01:29] <wgrant> Huh
[01:29] <wgrant> I've seen some slowness from elsewhere.
[01:29] <wgrant> But never as slow as I see.
[03:51] <jtv> wgrant: any chance you could help this user?  https://answers.launchpad.net/launchpad/+question/181066
[03:52] <wgrant> jtv: Could you ask them to retry?
[03:52] <jtv> I can, yes.  Do they need to bump their version number?
[03:52] <wgrant> As you may be aware, the last 14 hours have been roughly disastrous.
[03:52] <wgrant> No.
[03:52] <jtv> 14 hours?  I heard there have been problems, but wow.
[03:53] <wgrant> It's all been fixed for a couple of hours.
[04:20] <wgrant> huwshimi: Could you QA https://launchpad.net/bugs/894535?
[04:20] <_mup_> Bug #894535: Bug listing arrows appear to be backwards <bug-columns> <qa-needstesting> <Launchpad itself:Fix Committed by huwshimi> < https://launchpad.net/bugs/894535 >
[04:26] <huwshimi> wgrant: Done
[04:26] <wgrant> huwshimi: Thanks.
[05:01] <lifeless> poolie: is your new bug a dup of 894535?
[05:02] <poolie> about the order?
[05:02] <poolie> no i'm talking about the horizontal order
[05:02] <poolie> i would expect the headings to be in the same order as the data cells :)
[05:10] <lifeless> ah, there is a different 89* bug about that
[05:16] <wgrant> Mmm, unused portlets.
[05:16]  * wgrant destroys.
[05:31] <lifeless> right, time to EOD.
[05:31]  * lifeless EODs
[05:32] <wgrant> Night lifeless.
[06:37] <huwshimi> The new https://bugs.launchpad.net/launchpad is a welcome change
[06:37] <wgrant> Yep
[06:38] <wgrant> One of the most annoying pages in LP has finally met its demise :)
[06:39] <huwshimi> :D
[06:40] <wgrant> Unfortunately the new listings leave me disappointed when I click on a bug, and the old BugTask:+index kicks me in the face.
[06:40] <wgrant> With the old status/importance styles etc.
[06:41] <SpamapS> wgrant: to answer your earlier question.. I want to populate the 'charm' distro's new series, 'precise' with all the branches from 'oneiric'
[06:41] <wgrant> SpamapS: there's branch-distro.py to do that server-side, but it might not do exactly what you want.
[06:41] <wgrant> Depending on how you want branches to behave between series.
[06:42] <SpamapS> well I'm thinking that I want them to just be their own thing..
[06:42] <SpamapS> I will write a script which auto-proposes merges when the branches diverge..
[06:43] <SpamapS> Most changes to the 'precise' charms will be useful in the 'oneiric' charms.. but I think we're going to have to just manage them as branches.
[06:43] <SpamapS> auto backporting won't work without something like tarmac verifying that the new charm works on the old OS
[06:44] <SpamapS> wgrant: so if I read branch-distro.py's underlying code right.. it just copies all the branches from one series to the next. That sounds like what I want.
[06:44] <wgrant> SpamapS: Heh, sort of.
[06:44] <wgrant> Effectively, yes.
[06:44] <wgrant> But it moves the branches to the new series, then creates fresh ones in the old series, stacked on the new series.
[06:44] <SpamapS> I get that the old branch becomes stacked on the new one.
[06:45] <wgrant> To the user it just appears that they've been copied, right.
[06:46] <SpamapS> If our workflow becomes   commit to old branch, merge from old branch to new branch.. I don't see that as being problematic.
[06:46] <wgrant> I think branch-distro would work for you.
[06:46] <SpamapS> so I just need a LOSA to run that for me?
[06:47] <wgrant> Once you're that's what you want, yep.
[06:47] <wgrant> Once you're *sure*
[06:47] <SpamapS> I kind of want to have them try it on staging and see what it looks like. ;)
[06:47] <wgrant> staging doesn't have the branches on-disk, so that won't work.
[06:47] <huwshimi> Hmm.. that new bugs index was not rolled out under a feature flag
[06:47] <micahg> wgrant: I still see the bug listing arrows backwards, I did a forced refresh as well
[06:48] <wgrant> micahg: Can I see a screenshot?
[06:48] <SpamapS> wgrant: the one thing I'm concerned about is I'm not ready for the dev-focus to be changed to the new series.
[06:48] <micahg> sure
[06:48] <wgrant> huwshimi: No. Is that a problem?
[06:49] <huwshimi> wgrant: I just expected it to be part of the new bugs listing beta.  It's basically just expanding the listing and changing the default sort order.
[06:49] <wgrant> Which AFAICT nobody liked anyway.
[06:50] <wgrant> I will be surprised if we hear a single person complaining.
[06:50] <SpamapS> wgrant: also I can't "initialize" the series because this is an unpublished distro.
[06:51] <SpamapS> wgrant: I'm guessing that there's another script which will do that.
[06:51] <wgrant> SpamapS: Right, it doesn't make sense to initialise an unpublished distribution.
[06:51] <huwshimi> wgrant: I guess
[06:51] <wgrant> Initialisation copies the packages.
[06:51] <huwshimi> wgrant: I guess it's not like everyone reads the blog anyway
[06:51] <SpamapS> OH
[06:51] <huwshimi> wgrant: Still I would have thought it's big enough change for people to wonder why things are different
[06:52] <wgrant> huwshimi: Mmm, we don't normally blog about this sort of thing.
[06:52] <micahg> wgrant: http://people.ubuntu.com/~micahg/bug_listings.png
[06:52] <wgrant> Or we'd have a very, very noisy blog.
[06:52] <wgrant> micahg: That's correct.
[06:52] <wgrant> micahg: Check Nautilus, for example.
[06:52] <SpamapS> wgrant: so when I'm ready.. how would I change https://launchpad.net/charm/precise to the active dev series?
[06:52] <wgrant> The arrow points in the direction of increasing value.
[06:52] <wgrant> SpamapS: That probably requires a Launchpad dev/admin.
[06:52] <micahg> wgrant: that's how it was before :P, that's why I filed the bug
[06:53] <wgrant> To change the status.
[06:53] <SpamapS> ahh
[06:53] <huwshimi> wgrant: Don't we? We blog about a lot of trivial changes
[06:53] <wgrant> eg. I tend to do it for Ubuntu.
[06:53] <wgrant> huwshimi: Recently, yeah.
[06:53] <wgrant> micahg: Do you have an example of an application doing it the other way?"
[06:53] <micahg> Increasing usually mean in ascending order
[06:54] <wgrant> micahg: Right. Critical > High, so Critical should appear higher than High when the arrow is pointing up.
[06:54] <micahg> no
[06:54] <micahg> ascending importance should mean critical last
[06:54] <huwshimi> micahg: Increasing in statuses means going from undecided > Critical
[06:54] <micahg> right
[06:54] <wgrant> micahg: Sure, but arrow pointing up is descending, not ascending.
[06:55] <micahg> huh?
[06:55]  * wgrant points at Nautilus and probably everything else.
[06:55] <micahg> is everything upside down on the other side of the world?
[06:55] <wgrant> Thunderbird as well.
[06:55]  * micahg goes hunting for proof
[06:55] <huwshimi> micahg: The arrow follows the content on the page
[06:56] <micahg> gah, still seems counterintuitive, idk why I never caught it in thunderbird before
[06:56] <huwshimi> micahg: Ordering by bug number might help you to visualise it
[06:56] <micahg> no
[06:56] <wgrant> It does seem somewhat counterintuitive.
[06:57] <wgrant> But it's how everything else seems to do it.
[06:57]  * micahg translates the arrow to ascending/descending which is probably the issue
[06:57] <wgrant> Exactly.
[06:57]  * micahg checks HIG
[06:57] <SpamapS> arrows are a terrible way to denote sort order..
[06:57] <SpamapS> .oO would be better
[06:58] <SpamapS> arrows imply direction, but not origin
[06:58] <huwshimi> micahg: bug #1 is at the top of the page down to #100 at the bottom so the arrow is pointing down, when #1 is at the bottom of the page and #100 is at the top the arrow points up. Both of these follow the direction of the content
[06:58] <_mup_> Bug #1: Microsoft has a majority market share <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Invalid by ramvi> <GenOS:In Progress by gen-os> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Prog
[06:59] <huwshimi> _mup_: Shhh
[06:59] <micahg> huwshimi: right, that's what I take issue with :)
[07:00] <wgrant> micahg: Which browser are you using? Your fonts are ugly and misaligned.
[07:00] <micahg> firefox 9 beta
[07:01] <wgrant> Hm, does it have any subpixel rendering at all?
[07:01] <micahg> wgrant:  it should, but I might not have my display configured properly
[07:02] <micahg> huwshimi: wgrant: the HIG in 6.14.1 seems to agree with what you've done, so I'll resign myself to being confused: http://developer.gnome.org/hig-book/3.0/controls-lists.html.en#controls-lists-sortable
[07:02] <micahg> GNOME HIG that is
[07:02] <wgrant> I was confused initially, don't worry :)
[07:02] <wgrant> Probably because I mostly use sortable columns in Thunderbird, which defaults to the *bottom* of the list.
[07:03] <micahg> right, I'm just used to ignoring the arrows in thunderbird I guess
[07:03] <micahg> since I sort once and forget it
[07:03]  * micahg seems to agree with gnome 305277
[07:04]  * micahg guesses mup isn't ubottu :)
[07:04] <micahg> https://bugzilla.gnome.org/show_bug.cgi?id=305277
[07:05] <huwshimi> micahg: When you reported the bug there was actually a bug which meant the direction of the arrows was not consistent for ascending or descending which probably didn't help
[07:06] <micahg> huwshimi: that's not why I filed the bug though :), I guess I didn't notice that since it was counterintuitive to begin with
[07:08] <huwshimi> micahg: The Code was supposed to be in the opposite direction of what it is now (so, apart from the bug, it was originally in the directions your bug report wanted them to be)
[07:12] <bkerensa> :D
[08:53] <adeuring> good morning
[11:12] <jtv> cjwatson: hope you don't mind the piecemeal review style.  I was also on call for other things today, so this was a way to mitigate risk of distraction.
[11:20] <cjwatson> jtv: that's fine, I'm just trying to keep up. :-)
[11:20] <jtv> :)
[11:20] <cjwatson> jtv: hope in turn you don't mind lots of piecemeal commits to fix things
[11:20] <jtv> I see you already restructured runGerminate.
[11:20] <jtv> No, that's fine.
[11:21] <jtv> It makes it a bit harder to follow but turnaround's fair play.  Plus, it's fun to see the changes happening!
[11:21] <cjwatson> Still in progress on that.  I'm trying to sort out the inner body first and then figure out how/whether it should be split up further.
[11:23] <cjwatson> The closure question is a bit difficult.  I'm trying to balance clarity there against having methods with too many arguments.  The functional programmer in me likes closures, but they don't seem to result in awfully clear Python sometimes.
[11:24] <jtv> ISWYM.  It's a tough tradeoff.  In a functional language you don't have assignments to worry about.
[11:25] <jtv> And a class is probably overkill.
[11:25] <cjwatson> I actually want curried functions for composeOutputPath, really ...
[11:25] <jtv> Yeah.  :)
[11:26] <jtv> ISTR there being a bind() in the python standard library somewhere, but have always been too lazy to look it up.
[11:26] <cjwatson> So I'll simplify everything else and see how it looks.
[11:26] <wgrant> functools.partial?
[11:26] <jtv> That'd have to be it.
[11:27] <cjwatson> Interesting, quite a few callers in LP already.  I'll look up house idioms.
[11:27] <wgrant> It's very handy.
[11:27] <jtv> BTW, unrelated tip, for makeSeedStructure in the tests: instead of “if seed_name in seed_inherit:” you could probably have a single code path with seed_inherit.get(seed_name, [])
[11:29] <jtv> Neat!  test_name_is_consistent & test_name_is_unique_for_each_distro
[11:30] <cjwatson> .get> oh yes.
[11:30] <cjwatson> Can't claim credit for that; that was stolen from test_generate_contents_files.
[11:31] <jtv> It did sound familiar.  I think I wrote that.  :)
[11:31] <cjwatson> Nice to know you like your own code. ;-)
[11:41] <jtv> cjwatson: I must admit that, knowing that, my comment about the high quality of the branch seems a bit self-serving in retrospect.  :)
[11:45] <cjwatson> Heh.  I mostly just used it to fill out an initial skeleton; I'm still unfamiliar enough with Launchpad that cargo-culting is a good strategy to get me started.
[11:45] <rick_h_> morning
[11:56] <jtv> cjwatson: I guess most of the test_germinate_output_task tests could be unit tests for an extracted “calculate output task” method.  It would save a lot of setup.  But it's useful of course to have at least one test that does do all of that and tests the integration of a larger scope of the code.
[12:05]  * jtv watches the code break into smaller parts
[12:08] <cjwatson> jtv: Yep, that's more or less what I did
[12:11] <cjwatson> jtv: Oh, I think the reason I wrote makeSeedStructure that way was that I didn't want the trailing space in the no-inheritance case; that meant that I could just do a straight file comparison with the output.
[12:11] <cjwatson> jtv: It got a bit twisty when I tried to use .get.
[12:12] <cjwatson> ("%s: %s" % (seed_name, seed_inherit.get(seed_name, []))).strip() or something
[12:22] <jtv> cjwatson: Or just treat the "%s:" % seed_name as one of the elements of the list, I guess.
[12:23] <jtv> " ".join(["%s:" % seed_name] + seed_inherit.get(seed_name, [])) ?
[12:23] <jtv> Also a bit involved, I must admit.
[12:40] <cjwatson> jtv: on open(path).read(), Julian criticised a previous branch of mine where I did that in tests and asked me to use 'with' instead
[12:40] <cjwatson> jtv: https://code.launchpad.net/~cjwatson/launchpad/i18n-index/+merge/78618
[12:40]  * jtv reads
[12:41] <bigjools> "critiqued" :)
[12:41] <cjwatson> well, OK :-)
[12:41] <rick_h_> context managers ftw
[12:42] <jtv> Don't file handles get GC'd?
[12:42] <rick_h_> eventually, context manager make sure it happens on exit
[12:42] <rick_h_> well, exit of the block you use it with
[12:42] <jtv> In this case, “eventually” is fine AFAICT.
[12:42] <rick_h_> good habits and all that
[12:43] <jtv> If you neglect to do it while writing, python will generally punish you very quickly.
[12:44] <cjwatson> I don't hugely mind either way in this case, but it does seem odd to be told to change A to B by one reviewer and B to A by another, so maybe some consistency would help. :-)
[12:44] <cjwatson> (I agree there doesn't seem a desperate rush to close the handle, but whatever)
[12:45] <bigjools> it's not the tardy GC as such, it's the open file
[12:46] <jtv> But doesn't the GC also close the file?
[12:46] <bigjools> yes - but when?
[12:47] <jtv> Soon enough, evidently.
[12:47] <cjwatson> You might imagine a situation where tests churn through file handles fairly quickly and the GC doesn't get round to dealing with them until you run out of file handles.
[12:47] <cjwatson> Whether that actually happens in practice I don't know.
[12:47] <bigjools> ARGH fucking cached WADL
[12:48] <cjwatson> The system limit is typically large but not enormous.
[12:49] <jtv> Python might even detect the situation and do an extra GC.
[12:49] <soren> cpython closes it (pretty much) immediately, but other Python implementations (notably pypy) might take a while.
[12:49] <bigjools> it's better to be explicit IME
[12:49] <wgrant> Everything other than CPython is unreliable.
[12:50] <wgrant> You're meant to close explicitly.
[12:50] <wgrant> (and it's just so easy to do it with context managers nowadays)
[12:50] <soren> And, for clarity, that is *fine*.
[12:50] <soren> The Python spec doesn't say anything about this.
[12:50] <wgrant> Sure.
[12:50] <jtv> Crazy cat.  I just let you _in_.
[12:51] <soren> So it's up to the implementation to make this decision.
[12:51] <wgrant> Well, "Python spec"
[12:51] <wgrant> lol
[12:51] <soren> *g*
[12:51] <soren> fsvo
[12:51] <jelmer> wgrant: The only spec I trust is written in C :P
[12:51] <wgrant> Heh
[12:52] <rick_h_> but haven't you heard, pypy is fast :)
[12:52] <wgrant> Anyway, Jython, IronPython, PyPy all have more sane GC processes than CPython. I suspect all alternate implementations do.
[12:52] <wgrant> And considering how PyPy will hopefully rule the world in a couple of years...
[12:52] <jtv> That takes me back to my JVM programming days.  "You caught us.  No it doesn't really work like the spec says.   How would I get at them? Normally I'd expect to just look at the db, but this is on production
[12:54] <jtv> In some languages(*) python already means trouser snake.  There's instances of Python websites being censored because automated translation software says they could have naughty things on them.
[12:54] <jtv> rick_h_: put together a query, ask an admin to run it against a production slave?
[12:54] <wgrant> rick_h_: Oh, you are looking at that NoCanonicalUrl bug, aren't you...
[12:54] <wgrant> Not a good thing to start on :)
[12:54] <rick_h_> wgrant: yes
[12:54] <rick_h_> heh, well originally we thought it was something where I could see how iMessage was used
[12:55] <wgrant> bwahahah
[12:55] <wgrant> Several people have looked at that and failed, IIRC>
[12:55] <rick_h_> wgrant: but now I'm stuck digging at how half the url, lazr restful, and all that works
[12:55] <wgrant> Yeah...
[12:55] <rick_h_> wgrant: ok, well now I don't feel bad I didn't just *figure* it out yesterday afternoon
[12:56] <wgrant> I think we may be getting a raw Message out where we're meant to have a BugMessage. But it's been a good year since I last looked.
[12:56] <rick_h_> ok, but this is good, I'll finally poke at the database and maybe figure out how to generate a query to be run
[12:56] <rick_h_> that'll be fun
[12:56] <rick_h_> wgrant: yea, the thing I notice is that the failing one has a patch on it
[12:56] <wgrant> You'll most likely fail, but you'll learn lots about our infrastructure :)
[12:56] <rick_h_> wgrant: so I'm wondering if somehow the patch has a url/path getting generated?
[12:57] <rick_h_> wgrant: yea, I guess the goal is for me to learn parts of the system and I can do that in failure. But man I hate failing...
[12:58] <rick_h_> but my goodness is this whole url generating stuff convoluted. It's interesting to work on a project where I can't just download the prod db and fire in debug code/debugger steps
[13:03] <wgrant> Hmm.
[13:03] <wgrant> I think I know what it probably is.
[13:03] <jtv> cjwatson: you have been reviewed.  I'm off for food now, before I start hunting for those crickets that I'm hearing like the cat does!
[13:03] <wgrant> rick_h_: The message probably has a parent that isn't a comment on the bug.
[13:04] <rick_h_> wgrant: yea, that's what I was kind of curious about. I see the stuff that iterates through the url looking for more parts to generate and curious how this comment differs from the one before/after which work
[13:04] <cjwatson> jtv-afk: Yay, thank you.  I'll go hassle folks about the deployment steps ...
[13:05] <wgrant> rick_h_: So, I can confirm that in this case the exception is generated about comment #11's parent message. And that parent message is not a comment on the bug.
[13:05] <wgrant> Not a comment on any bug, in fact.
[13:05] <wgrant> THat might help you reproduce it locally.;
[13:06] <cjwatson> jtv-afk: I found a way to write makeSeedStructure that avoids multiple paths without being too twisty, I think.
[13:07] <rick_h_> wgrant: ok, interesting. thanks
[13:07] <rick_h_> wgrant: hmm, when I check each comment's parent attrib via the api I get None for all of the comments
[13:08] <rick_h_> wgrant: different "parent"s?
[13:08] <wgrant> rick_h_: That's the only message on the bug with a parent.
[13:08] <wgrant> Only comments that were emailed in have parents.
[13:09] <rick_h_> wgrant: how did you see it had a parent?
[13:09] <wgrant> I'm magical.
[13:09] <wgrant> And have access to dogfood's DB.
[13:09] <wgrant> Which is a 2.5-month-old snapshot of prod.
[13:09] <rick_h_> wgrant: strage that the api says it has no parent, but the db says so
[13:10] <nigelb> I always knew wgrant was magical :D
[13:10] <wgrant> rick_h_: Hm? The API doesn't say it has no parent. It crashes when trying to say that it *does* have a parent.
[13:10] <wgrant> AFAICT
[13:10] <rick_h_> wgrant: right, but if I launchpad.bugs[805938] and print parent for m in bug.messages I get None for all, including 11
[13:11] <wgrant> rick_h_: Ahh
[13:11] <wgrant> That's different.
[13:11] <wgrant> Evilly different.
[13:11] <rick_h_> wgrant: hmm, actually I show (via that api stuff) that comment 7 has a parent of comment 6
[13:11] <wgrant> That uses a special property (Bug._indexed_messages or something) to precache the parents.
[13:12] <wgrant> rick_h_: Bah, yeah, you're right, I missed one.
[13:12] <rick_h_> wgrant: ah, ok I saw that stuff somewhere
[13:12] <wgrant> 7's parent is 6, 11's parent is some other random message somewhere.
[13:12] <wgrant> Not on any bug.
[13:12] <rick_h_> wgrant: when it tries a couple of methods to generate the CanonicalUrlData it tries the cache and then if that fails generates one I think
[13:12] <wgrant> Possibly on a mailing list or something.
[13:23] <wgrant> rick_h_: Aha
[13:23] <rick_h_> wgrant: more magic kicking in?
[13:23] <wgrant> rick_h_: The problem is indeed what I said, and it's in _indexed_messages.
[13:24] <wgrant> No more magic, no.
[13:24] <wgrant>                 if parent is not None:
[13:24] <wgrant>                     # If there is an IndexedMessage available as parent, use
[13:25] <wgrant>                     # that to reduce on-demand parent lookups.
[13:25] <wgrant>                     parent = message_by_id.get(parent.id, parent)
[13:26] <wgrant> So, if the parent is a comment on the same bug, it will replace the BugComment's parent Message with the corresponding BugComment.
[13:26] <wgrant> BugComments have URLs.
[13:26] <wgrant> But if the parent is *not* a comment on the same bug, the parent will remain as a Message, which has no URL.
[13:26] <wgrant> boom.
[13:26] <rick_h_> wgrant: right, gotcha
[13:27] <rick_h_> wgrant: ok, that makes sense since I could find no way to build a url to a message (was looking at that vs trying to hit the db quuery)
[13:27] <wgrant> Best way to solve this is probably just to say the parent is None in that case. Since messages don't have URLs.
[13:27] <wgrant> Since they may be referenced in many places.
[13:27] <wgrant> eg. I can send one email to 200 bugs, it will be stored as one Message.
[13:27] <rick_h_> wgrant: orly, interesting
[13:28] <wgrant> At least that's how it's meant to work -- if the content and message-id are the same, it's meant to only store one copy.
[13:28] <rick_h_> yea, I see that it stores the email id in the row
[13:28] <rick_h_> so a Message can be either an email or form entered text?
[13:28] <wgrant> Right.
[13:29] <wgrant> In the case of an email, we parse In-Reply-To, look up the corresponding Message, and link it up with Message.parent.
[13:30] <rick_h_> now could the parent be something else that *does* have a url?
[13:30] <rick_h_> or is the parent always another message? and if it's a message it's either a bug/url-able or  an email (which is not urlable)
[13:30] <wgrant> The parent is always another Message.
[13:30] <rick_h_> and excuse my indicision on if url-able is hyphenated or not :)
[13:30] <wgrant> URLable? :)
[13:32] <benji> rick_h_: it's urlificable, obviously
[13:32]  * wgrant should sleep.
[13:32]  * rick_h_ smacks head
[13:34] <wgrant> rick_h_: https://bugs.launchpad.net/launchpad/+bug/901124 and https://bugs.launchpad.net/launchpad/+bug/901122 have generated several complaints today -- the new bug listings cause pretty much constant timeouts on large Ubuntu bug searches. Can someone from your squad look at these pretty urgently?
[13:34] <_mup_> Bug #901124: New bug listings get length of collection twice <bug-columns> <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901124 >
[13:34] <_mup_> Bug #901122: New bug listings need to preload more attributes <bug-columns> <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901122 >
[13:34] <rick_h_> wgrant: I'll bring them up at our stand up in an hour
[13:34] <wgrant> Thanks.
[13:42] <mrevell> matsubara, Are you able to, easily, calculate the median len of a bug title? If not, I'll use your data to calculate one.
[13:43] <matsubara> mrevell, I can give it a shot. My SQL knowledge isn't that great
[13:43]  * matsubara looks for postgresql docs
[13:44] <mrevell> matsubara, Oh, hey, I was just going to pop the data in a spreadsheet and then organise it into columns. Don't worry, I'll just do it.
[13:44] <rick_h_> http://plusplus.wordpress.com/2009/11/18/finding-median-with-postgresql/
[13:44] <rick_h_> matsubara: ^
[13:44] <matsubara> mrevell, ok
[13:44] <matsubara> rick_h_, thanks!
[14:34] <rick_h_> deryck:  https://bugs.launchpad.net/launchpad/+bug/901124 and   https://bugs.launchpad.net/launchpad/+bug/901122
[14:34] <_mup_> Bug #901124: New bug listings get length of collection twice <bug-columns> <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901124 >
[14:34] <_mup_> Bug #901122: New bug listings need to preload more attributes <bug-columns> <regression> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901122 >
[15:45] <lifeless> stub: hey
[15:45] <adeuring> abentley: there are some differences between the names of display flags like "show_last_updated" and related sort parameters, like date_last_updated, while other names "relate better", for example "show_assignee" (display flag) and "assignee" (sort parameter), where one can simply add/remove the prefix "show_". Would something explode if I change the flags in templates/buglisting.mustache and in BugListingConfigUtil.field_display_names so
[15:46] <lifeless> flacoste: apologies for the TL meeting; will be getting a CT scan of my sinuses
[15:46] <flacoste> lifeless: ok, sleep weel in the mean time :-)
[15:46] <lifeless> flacoste: EBABY :P
[15:46] <flacoste> gary_poster: since you are hosting ^^^
[15:46] <abentley> adeuring: You cut off at "and in BugListingConfigUtil.field_display_names so"
[15:46] <lifeless> flacoste: 0446 now, had alarm set for 0550 to get up anyhow, as its a bit of a drive
[15:47] <adeuring> abentley: ...so that all "show_" names match corresponding sort options?
[15:48] <abentley> adeuring: Nothing will explode, however, I think that we should try to make our internal names match the external names.
[15:48] <abentley> "Last updated" is the text we're currently using.
[15:49] <adeuring> abentley: I see your point-- but "correlating" the sort buttons and the "show_.*" flags is in this case a bit messy...
[15:50] <adeuring> abentley: and "show_id"  does not match "Bug number" that well ;)
[15:50] <adeuring> (in a very literal sense...)
[15:52] <abentley> Is it a matter of the sort buttons or of the terminology used by orderby?
[15:52] <jcsackett> sinzui: got a few moments to chat?
[15:55] <adeuring> abentley: the code that shows/hides the sort buttons needs to have an idea about the relation between  sort parameter names (fixed)  and the field to display. I am curtrently  "translating" for example betwwen "bug_heat" (display flag "show_bug_heat") and the sort option "heat". That's ugly and error prone
[15:55] <lifeless> allenap: you say to see the bug report for details, but the bug report says 'we should talk' :P
[15:55] <allenap> lifeless: I wonder if I linked to the wrong bug :-/
[15:57] <abentley> adeuring: But it also seems like you're reluctant to change the name of the sort option "heat".  I am guessing you are reluctant because it's used directly by orderby.  Is that right?
[15:57] <lifeless> allenap: https://bugs.launchpad.net/storm/+bug/887240
[15:57] <_mup_> Bug #887240: test_terminated_backend test failure <Storm:New> < https://launchpad.net/bugs/887240 >
[15:57] <allenap> lifeless: Yes, I did, and my branch name is all wrong.
[15:58] <allenap> lifeless: https://bugs.launchpad.net/psycopg/+bug/900702 is the correct bug.
[15:58] <_mup_> Bug #900702: pgbouncer error in test suite, psycopg went psycotic <psycopg:New> <Storm:Triaged by allenap> < https://launchpad.net/bugs/900702 >
[15:58] <allenap> Sorry.
[15:58] <adeuring> abentley: yes, that would affect quite old code in the class BugTask, for example, including the need to have aliases for old sort names. People may have bookmakrek URLs with "?orderby=heat"
[15:59] <stub> lifeless: yo
[15:59] <lifeless> stub: categorising patches
[16:00] <lifeless> stub: I think adding a suffix would do it simply enough - patch-2011-44-0-concurrent.sql
[16:00] <lifeless> (meaning all nodes no xact)
[16:00] <lifeless> options being std, direct, concurrent
[16:01] <stub> lifeless: Or subdirs or something like that - yer.
[16:01] <lifeless> stub: then the upgrade can do all ordered patches from $ next to apply up to the first type change.
[16:01] <lifeless> stub: how does that sound?
[16:02] <abentley> adeuring: That's what I thought.
[16:03] <bigjools> lifeless: enjoying being a parent then? :)
[16:03] <lifeless> bigjools: very much
[16:03] <lifeless> bigjools: just not every second of:P
[16:03] <bigjools> :D
[16:05] <abentley> adeuring: if you want to change it so that our new values match the legacy orderby values, that will work.  I think if I was doing it, I'd just translate the new values into the legacy values when emitting orderbybar:sort
[16:06] <lifeless> allenap: so yes, looks like you linked the wrong bug, and/or they are dupes
[16:07] <stub> lifeless: Sure. One thing to ponder - originally we picked numbers and applied sequentially because we wanted to ensure patch 1 applied before patch 2 in case there was a dependency. By applying a subset of patches (those that can be applied by the currently selected process), we lose that a bit. Should the patch type be considered the first part of the patch number?
[16:07] <stub> oic. up to the first type change.
[16:07] <adeuring> abentley: there is at least one more translation necessary: When the "currently active sort button" is highlighted at page render time. That's possible, and probably not as ugly as my current implementation, but I don't like it that much nevertheless
[16:07] <stub> yer, that would work and sidesteps my issue. Or non-issue, as dependencies are extremely rare in practice.
[16:07] <allenap> lifeless: I'll remove the bit in 900702 that refers to test_terminated_backend. It keeps confusing me.
[16:08] <allenap> I'd like to treat them as separate problems.
[16:09] <lifeless> stub: they do happen though, actually quite a bit more now because of the 'split patches into bits to reduce downtime' effort
[16:09] <lifeless> stub: so I think its good to keep that ordered protection
[16:09] <stub> k
[16:09] <lifeless> stub: we can have a --all mode which loops repeatedly doing the upgrades type by type (still in order)
[16:09] <lifeless> e.g. 4 std's, 2 concurrents, 1 direct, 2 stds etc
[16:10] <abentley> adeuring: yes, I can see how your solution would be simpler, then.
[16:10] <adeuring> abentley: ok, so'll go that route
[16:14] <deryck> adeuring, the bug you're doing on the kanban is bug 898200 which abentley marked a dupe of bug 295214, presumably because your fix will fix that old outstanding issue...
[16:14] <_mup_> Bug #898200: Can't sort bug list by customized fields <bug-columns> <Launchpad itself:Triaged> < https://launchpad.net/bugs/898200 >
[16:14] <_mup_> Bug #295214: match input and column headers searching bugs related to.... <bug-columns> <confusing-ui> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/295214 >
[16:15] <deryck> adeuring, so I'll just fix up the card and the bug assignment, if you have no objections.
[16:16] <adeuring> deryck: ok
[16:27] <lifeless> allenap: so are we saying we are unsafe to run with psycopg2.4 ?
[16:27] <bac> hi flacoste, the daily build into the ~launchpad PPA for python-launchpadlib is now working.  can we talk about whether an SRU is needed or not?
[16:27] <lifeless> allenap: disabling the test seems to mean folk won't get warning that the entire disconnect codepath is unusable
[16:28] <allenap> lifeless: Only if pgbouncer is killed unceremoniously, then we get a "psycotic" error.
[16:28] <allenap> lifeless: Yeah, that's a fair point.
[16:29] <flacoste> bac: on the phone, will ping you afterward
[16:29] <lifeless> allenap: I'm not sure what to do about it, but it seems like a Big Red Light to me :)
[16:29] <bac> flacoste: ok.  will disappear in 20 minutes for lunch.
[16:30] <allenap> lifeless: There's a demand for a clean build. If a test is known to fail then it's not worth running it. A skip is added, so users running the test suite will get a message about it.
[16:30] <flacoste> bac: ok, I'll grab you when i come back from lunch then
[16:30] <lifeless> allenap: a clean build is important too :)
[16:30] <lifeless> allenap: like I say, I'm not sure what to do about it, just raising it for consideration
[16:33] <allenap> lifeless: Okay. If we ensure the tests are run with trial I could instead add a .todo attribute to the test method to mark it as an expected failure.
[16:36] <lifeless> allenap: testtools/unittest2 also have xfail
[16:38] <allenap> lifeless: Storm seems to be avoiding testtools. I guess I could change that.
[16:38] <lifeless> +1
[16:38] <lifeless> <- not biased AT ALL
[16:38] <allenap> Spin up the yak shearers.
[16:39] <allenap> :)
[16:40] <allenap> Sometimes I dream that I'm back playing Quake, online from my college room, but weapon 1 is shears and I'm facing an undead yak horde.
[16:41] <lifeless> \o/
[16:41] <deryck> rick_h_, looking at your mp… a minor thing:  we spell "function (node) {" as "function(node) {" without the space.
[16:41] <lifeless> allenap: I've been yak shaving for ~ 4 month straight now ;)
[16:41] <rick_h_> deryck: sorry, thought I find/replaced all those
[16:41] <allenap> Hehe :)
[16:42] <deryck> rick_h_, I'm please to see you've cut down on your newline obsession too :)
[16:42] <lifeless> allenap: gpgverifyd -> needs oops -> oops-* -> needs console -> oops-tools -> needs scriptactivity -> needs slony db migrations -> lazr-postgresql
[16:42] <rick_h_> deryck: with monumental effort!
[16:42] <lifeless> allenap: I am going to party -so- hard when I unwind this yak shaving chain
[16:42] <deryck> rick_h_, those a minor, niceties, though. I'm working through the functionality now.
[16:43] <allenap> lifeless: Wow :)
[16:43] <lifeless> allenap: all in the name of having a demo microservice to point at!
[16:43] <allenap> lifeless: It'll be worth it in the end.
[16:44] <lifeless> totally
[16:44] <lifeless> and the bits done so far are working very well, if I do say so myself
[16:47] <rick_h_> deryck: hey, ? regarding running tests. I'm trying to run the test_bug_messages.py and I'm getting http://paste.mitechie.com/show/465/
[16:47] <rick_h_> deryck: am I trying to run this wrong then?
[16:51] <deryck> rick_h_, try spelling it:  ./bin/test -cvt test_bug_messages
[16:51] <rick_h_> deryck: ah thanks, that seems to be doing something a bit better
[16:57] <abentley> rick_h_: -t matches the test-id.  You can also match on module names.  I don't know if there's a way to match file paths.
[16:58] <rick_h_> abentley: thanks, yea I originally started with test.py and the .py seems to be what got me off wrong
[17:01] <allenap> lifeless: I say so too, they're tip top.
[17:05] <lifeless> allenap: thanks!
[17:07] <rick_h_> allenap: sorry, wrong channel
[17:07] <bigjools> lifeless: where's the wiki page on using feature flags?  I am full of fail today
[17:07] <rick_h_> allenap: skype/mumble work for you? Might be a bit easier
[17:07] <allenap> rick_h_: Skype's good, I'm gavinpanella.
[17:08] <lifeless> dev.
[17:08] <allenap> rick_h_: What's the bug #?
[17:08] <rick_h_> allenap: ok added, let me know if you don't see something in a sec
[17:08] <rick_h_> https://bugs.launchpad.net/launchpad/+bug/808952 allenap
[17:08] <_mup_> Bug #808952: NoCanonicalUrl using api to fetch bug comments <api> <oops> <Launchpad itself:Triaged by rharding> < https://launchpad.net/bugs/808952 >
[17:08] <bigjools> abentley: I match files with "bin/test -cvv <file>"
[17:08] <allenap> rick_h_: Ring when you're ready.
[17:09] <abentley> bigjools: I thought that only worked on module names.  It works on full file paths?
[17:09] <bigjools> abentley: for file paths you need to use.a.dot.path IIRC
[17:10] <bigjools> it works on files if not file paths as I said, at least
[17:10] <abentley> bigjools: That's what I meant by "You can also match on module names."
[17:10] <bigjools> ah I missed that
[17:10] <bigjools> these dark nights screw with my head it seems
[17:12] <sinzui> jcsackett, I do. Sorry about the delay, my house is flooding
[17:12] <jcsackett> sinzui: no worries, a flooding house sort of takes priority. :-P
[17:20] <lifeless> later y'all
[17:28] <abentley> deryck: BugListingConfigUtil.setCookie() with no parameters doesn't clear the cookie for me, because it's not passing the "path" option to Y.Cookie.remove.  However, I can't reproduce this issue in a test.
[17:29] <deryck> abentley, I thought remove only took the name of the cookie, i.e. in a foo:bar cookie, simply passing in "foo" as an argument.
[17:29] <deryck> which is what I thought I did.
[17:30] <abentley> deryck: No, you have to pass in the same options as you used to create the cookie (except Date, because deleting a cookie means setting expiry to the UNIX epoch)
[17:30] <deryck> abentley, not according to the yui3 cookie docs I just checked.  unless our version is out of sync with the latest docs.
[17:31] <abentley> deryck: "A cookie created with specific options can only be deleted by specifying the same options" -> http://yuilibrary.com/yui/docs/cookie/
[17:32] <deryck> abentley, ah, ok.  sorry.  but the test does pass without specifying the options?  but it doesn't actually work?
[17:33] <abentley> deryck: Yes, the test does pass, and I can see the cookie value changes when the test simulates a reset.
[17:33] <abentley> deryck: changes to "", which I assume is "no cookie".
[17:34] <deryck> abentley, essentially, yes.  but it would be better to delete the cookie entirely.
[17:35] <deryck> abentley, so is the question "how do I test I've removed the cookie properly?"
[17:35] <abentley> deryck: Actually, it looks like get Y.Cookie.get(this.cookie_name)) returns null if the cookie is not defined.
[17:35] <deryck> abentley, yes, that would have been my suggestion.  Sorry, I didn't follow what you were asking initially.
[17:36] <deryck> Assert.isNull(Y.Cookie.get('foo'))
[17:37] <abentley> deryck: neither did I :-)
[17:38] <deryck> abentley, heh. no worries then :)
[17:39] <bigjools> abentley: can I bug you for a sec please, trying to write a new test for a merge proposal template change and failing miserably!   https://pastebin.canonical.com/56859/
[17:40] <abentley> bigjools: looking
[17:43] <abentley> bigjools: I don't know if we've ever executed the view in our tests before.  It looks like that gives us a traversal problem.
[17:44] <bigjools> yeah I've had this before in other parts of the code base
[17:44] <bigjools> the other option is to edit a story test....eek
[17:44] <abentley> bigjools: Have you considered using getViewBrowser?
[17:45] <bigjools> I havent', how does that change things?
[17:46] <abentley> bigjools: That will use the proper infrastructure to initialize the and execute the view, then give you a Browser whose .contents will be the result.
[17:46] <bigjools> worth a shot, let's see
[17:48] <abentley> bigjools: see test_conversation for an example.
[17:48] <bigjools> gotcha
[17:52] <bigjools> abentley: test passing, thanks!
[17:53] <abentley> bigjools: np.
[17:55] <bigjools> I should look in lp/code more often, there's some testing gems in there
[17:57] <bigjools> can't create MPs when the branch scanner is looking at your branch it seems :(
[18:20] <deryck> rick_h_, so just looking at the code, I have no serious concerns.  Just a few stylistic comments I can add to the MP.  I'll mark it approved, but would like you to make the changes I post, unless you have strong concerns about anything I suggest...
[18:20] <deryck> rick_h_, however, trying it locally manually, I see a bug, I think.
[18:21] <rick_h_> deryck: sure thing on the style changes
[18:21] <deryck> rick_h_, if I add a really long description to a bug, and then go into edit mode again to update it, the text area shrinks to a smaller default size, and then expands again to expected size after the first change.
[18:21] <deryck> I say "default" size because it changes to that same smaller size when I enter edit mode each time.
[18:22] <rick_h_> deryck: looking
[18:29] <rick_h_> deryck: hmm, it looks as if the old code manually set a width on the textarea that I missed and I'm not setting. So it flows father out.
[18:29] <bac> hi flacoste
[18:29] <rick_h_> deryck: I'll look at the original code and see if I can find what I missed
[18:29] <flacoste> hi bac
[18:29] <deryck> rick_h_, ok.  and for me, it's excpetionallyy short.  but I used a *huge* description to test.
[18:29] <flacoste> bac: so SRU or not
[18:30] <bac> flacoste: yep.
[18:30] <flacoste> why wouldn't want to SRU?
[18:30] <bac> flacoste: the number of affected users is pretty tiny.
[18:30] <rick_h_> deryck: I'm not following? I think what you're saying is that the textarea extends out past where the originall div that showed the content is?
[18:30] <rick_h_> deryck: or do you mean something else?
[18:31] <bac> flacoste: and a lot of the stuff rolled into the current version of lplib may not make it past the SRU guards, so we'd have to cherry pick the change.  it looks like a lot of effort for not much gain, IMO.
[18:31] <deryck> rick_h_, no.  the text I added runs 50-60 lines long in the browser window.  I'm using a 1024 or 1180 size window.  when I enter edit mode, the size of the text area is only 20-30 lines long until I make my first edit...
[18:31] <deryck> rick_h_, then it expands to the 60 or so lines as before.
[18:32] <rick_h_> deryck: oh ok, that's different then.
[18:33] <flacoste> bac: how do you know the number of affected users is tiny?
[18:33] <rick_h_> deryck: ah ok, I can reproduce that. Thanks
[18:33] <flacoste> most people who writes lplib script regularly have been affected by the issue
[18:33] <flacoste> at least, that's the impression i got
[18:33] <flacoste> i've encountered it
[18:33] <flacoste> poolie did
[18:33] <flacoste> james_w did
[18:33] <flacoste> jml did
[18:33] <deryck> rick_h_, cool
[18:34] <bac> flacoste: i got the impression, perhaps from talking to steve, that he was the main person affect.  that could be wrong.
[18:35] <flacoste> bac: ok, let's not request a SRU at this time, if they want to do one, they know where to get it
[18:35] <flacoste> the fact that there is a PPA to get the latest version makes it easier anyway
[18:35] <james_w> this is storing the wrong thing in the keyring?
[18:35] <flacoste> james_w: yep
[18:35] <bac> flacoste: ok.  that was my thought
[18:35] <lifeless> I've missed the chat obviously ;) - we should request a new release into precise
[18:36] <lifeless> once Ubuntu has *that*, the SRU process becomes largely internal.
[18:36] <lifeless> (to Ubuntu)
[18:36] <flacoste> lifeless: wow, they have WIFI in CT scan in New Zealand!
[18:36] <bac> lifeless: 1.9.11 has been packaged into sid and wheezy
[18:36] <lifeless> flacoste: I'm using my phone as an AP
[18:36] <lifeless> bac: sweet
[18:36] <james_w> I haven't hit that
[18:37] <flacoste> lifeless: doesn't that interfere with the machinery? ;-)
[18:37] <lifeless> bac: I haven't checked freeze dates recently, but thats probably sufficient
[18:37] <flacoste> james_w: ah, my mistake then
[18:37] <deryck> rick_h_, I think I'll mark this needs fixing after all, not to be a jerk about it. but just to be able to take a look again once it's fixed.
[18:37] <deryck> rick_h_, and I'll add my other notes now.
[18:37] <lifeless> flacoste: I'm not in the same room as the machinery at the moment :)
[18:37] <james_w> but I've seen some complaints so I think it's worth SRUing
[18:37] <rick_h_> deryck: no definitely, thanks
[18:38] <flacoste> bac: what's in lucid?
[18:38] <bac> flacoste: 1.6.0
[18:38] <lifeless> flacoste: I doubt it would handle voip, but the phone does a decent job of basic connectivity
[18:38] <flacoste> bac: but if i recall, the problems started with natty
[18:39] <flacoste> bac: what's in natty?
[18:39] <flacoste> and oneiric
[18:40] <lifeless> flacoste: rmadison is your friend
[18:40] <bac> 1.9.7 and 1.9.8
[18:40] <flacoste> lifeless: yes, bac privmsg me the rmadison output
[18:40] <lifeless> $ rmadison python-launchpadlib
[18:40] <lifeless> python-launchpadlib | 1.6.0-0ubuntu1 |         lucid | source, all
[18:40] <lifeless> python-launchpadlib |    1.6.1-1 |      maverick | source, all
[18:40] <lifeless> python-launchpadlib | 1.9.7-0ubuntu2 |         natty | source, all
[18:40] <lifeless> python-launchpadlib |    1.9.8-2 |       oneiric | source, all
[18:40] <lifeless> python-launchpadlib |    1.9.9-2 |       precise | source, all
[18:40] <lifeless> :P bah
[18:41] <lifeless> whats the new tag again
[18:41] <lifeless> selfinflicted?
[18:42] <lifeless> (for bug 901332)
[18:42] <_mup_> Bug #901332: AttributeError: 'SourcePackage' object has no attribute 'personHasDriverRights'  nominating a bug <bugs> <disclosure> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/901332 >
[18:44] <flacoste> lifeless: fallout
[18:44] <flacoste> if regression isn't appropriate
[18:45] <flacoste> bac: so everything after 1.9.8 is bug fixes and doc tweak really
[18:45] <lifeless> flacoste: its both
[18:45] <lifeless> flacoste: the use case used to work
[18:45] <flacoste> how can it be both
[18:45] <flacoste> so it's a regression
[18:45] <lifeless> flacoste: now it doesn't
[18:45] <flacoste> not a fallout
[18:45] <lifeless> flacoste: the cause of it breaking is feature work
[18:45] <flacoste> regression
[18:45] <lifeless> flacoste: ok, so fallout is strictly 'something new that crashes' ?
[18:45] <flacoste> yep
[18:45] <flacoste> to get what isn't covered from regression
[18:45] <bac> flacoste: and a script addition
[18:46] <flacoste> right, but that shouldn't be a problem
[18:46] <lifeless> flacoste: yeah, brain is a bit messed up from EBABY start at 4am.
[18:46] <lifeless> flacoste: thanks
[18:46] <sinzui> flacoste, I marked it fallout
[18:46] <sinzui> I landed it as a pre-req for feature work
[18:47] <lifeless> sinzui: its broken previously working nominations though
[18:47] <lifeless> sinzui: doesn't that make it a regression ?
[18:48] <sinzui> It can be both. I treat regressions (and fallout) as top priority kanban cards
[18:49] <lifeless> sinzui: So francis wants tags to partition new criticals, so we can assess the sources.
[18:49] <lifeless> sinzui: I don't think it can be both under that constraint - and as it affects existing users/use cases, I don't understand why it isn't a regression
[18:50] <sinzui> okay I will switch to regression
[19:08] <abentley> deryck: It appears that Y.Cookie._setDoc({cookie: ""}); prevents Y.Cookie.remove() from working properly, because the browser does the actual deletion, not JavaScript.
[19:09] <deryck> abentley, ah, ok. that's needed for cookie testing in chromium though.
[19:13] <bac> so flacoste did we come to a conclusion?
[19:14] <flacoste> bac: let it lie for now, unless Ubuntu wants a SRU
[19:14] <flacoste> which i'll check with them
[19:14] <bac> flacoste: ok
[19:14] <abentley> deryck: test_form_reset_removes_cookie is currently broken.  I guess I'll fix it on FF by doing Y.Cookie._setDoc(Y.config.doc)
[19:14] <bac> flacoste: shall i mark those bugs as fix released?
[19:14] <bac> i guess so since they are released *somewhere*
[19:15] <deryck> abentley, on TL call now, but first reaction is that should work.
[19:15] <deryck> abentley, I don't recall why I didn't do that.  I knew about that approach.
[19:17] <flacoste> bac: yep
[19:52] <poolie> sladen, hi, do you have any advice on https://code.launchpad.net/~mbp/launchpad/714831-beta-font/+merge/84716
[19:53] <poolie> actually that should be https://code.launchpad.net/~mbp/launchpad/714381-beta-font/+merge/84716
[20:07] <bkerensa> flacoste: You available?
[20:07] <abentley> deryck: I'm the sole OCR and don't want to self-review.  Could you look at https://code.launchpad.net/~abentley/launchpad/fix-reset-to-default/+merge/84833 ?
[20:07] <flacoste> hi bkerensa
[20:08] <flacoste> bkerensa: if you want to talk about the new custom bugs listing, talking to deryck or mrevell (now offline) is probably better
[20:08] <bkerensa> flacoste: Hi looking for someone to talk to on the LP Team about the new bug listings and any work your doing over the next couple weeks
[20:08] <bkerensa> ahh ok
[20:08] <bkerensa> :D
[20:08] <bkerensa> deryck it is then :)
[20:08] <deryck> hi bkerensa
[20:08] <bkerensa> hi
[20:08] <bkerensa> deryck: ^ :)
[20:09] <deryck> abentley, can you ask around for someone? I've been busy all day and still need to spend some time on this timeout stuff.
[20:09] <abentley> deryck: sure.
[20:09] <deryck> abentley, or else I can get it here when I get some bandwidth
[20:10] <deryck> abentley, ok, thanks!
[20:10] <deryck> bkerensa, do you have specific questions, or just want me to give you a run down of where we're at and what's going on?
[20:13] <bkerensa> deryck: Just  brief run down so I can put it in the Devel News :)
[20:14] <deryck> bkerensa, ok. so we're fixing a few outstanding known issues this week.  issues both that we knew about going into beta and issues discovered in beta...
[20:15] <deryck> bkerensa, we've got a little UI polish on going to -- the order by options should match the items displayed and we'll have a nicer loading indicator.
[20:15] <deryck> bkerensa, the "bug-columns" tag on launchpad's bugs is a good one to watch for activity around this feature.
[20:15] <deryck> bkerensa, there's some work going on to fix timeouts from the new data, too.
[20:16] <deryck> bkerensa, I think that's about it.
[20:16] <bkerensa> deryck: ok thanks :D
[20:17] <deryck> np
[20:45] <abentley> bac: Any chance you could do a reivew?  I'm OCR today and don't want to self-review.
[20:46] <bac> abentley: sure, in a bit.  MP?
[20:46] <abentley> bac: https://code.launchpad.net/~abentley/launchpad/fix-reset-to-default Thanks.
[20:53] <abentley> bac: abort.  jcsackett took it.
[20:54] <bac> abentley: ok
[20:54] <flacoste> bac: bryce (who escalated the bug) would like SRU for natty and oneiric
[20:54] <flacoste> bac: he's willing to help out with those
[20:54] <bac> flacoste: i just saw that
[20:54] <flacoste> i'll tell you'll be in contact
[20:54] <flacoste> tell him
[20:55] <bac> flacoste: ok
[20:55] <bac> poolie had request it too.
[20:58] <jelmer_> :q
[21:07] <lifeless> ok, time to run for next medical thing. Ciao.
[21:31] <poolie> bac, i'm happy to answer questions etc about the sru process
[21:31] <poolie> it can tend to get stuck
[21:31] <bac> poolie: thanks!
[21:42] <sinzui> abentley, do you have time for a short review https://code.launchpad.net/~sinzui/launchpad/nomminate-driver-permissions-1/+merge/84850
[21:43] <abentley> sinzui: sure.
[21:43] <abentley> sinzui: "SourcePackage does implement all of the IHasDrivers interface." Does or does not?
[21:43] <sinzui> abentley, reload the page
[21:46] <abentley> sinzui: r=me.
[21:46] <sinzui> thank you very much
[21:46] <abentley> sinzui: np


[15:22] <abu> hi
[15:29] <Guest36> can someone pls help me with this issue: i have installed lubuntu on my mate-ubuntu, and works great.. but when i reboot the system sometimes the system brings lxde instead of lubluntu how can i fix this. i want alwasy to bring on the first place lubuntu
[15:30] <Guest36> for an example, when i logout i have alwasy see: lubuntu, openbox and lxde
[15:35] <Guest36> or.. if i can not remove lxde for some reason, how can i run always lubuntu only?


[18:36] <pavlushka> o/
[18:50] <pavlushka> .tell farhan hi
[18:50] <u-la-la> pavlushka: I'll pass that on when farhan is around.


[05:36] <luna_> any new episode later today?
[05:40] <amurray> luna_: yep - just editing it now :)
[05:47] <luna_> alrighty
[05:53] <luna_> cool will listen to it when i update the Ubuntu servers at work on Monday


[02:08] <mal41> Am I being daft or does "device_aliases" as documented in the disk_setup module just not exist? The only place in the code base where "device_aliases" appears is in the documentation for that module, never - seemingly - in actual code.
[02:09] <mal41> "disk_aliases" seems to exist, but that only applies to dscfg, not user-land config.
[02:09] <mal41> I feel like I've been gaslit by documentation /o\
[15:42] <rharper> mal41: device_aliases is a but under documented as to where the alias comes from;  from what i know, various clouds provide a 'block-device-mapping' in their metadata, Ec2, OpenStack,  (Azure sort of does but differently);  in the ec2 metadata, the block-device-mapping provides an 'ephemeral' alias to whatever block device name is associated (say /dev/sdb);  so the alias in disk_setup is used to refer abstractly to "whatever
[15:42] <rharper> device calls itself 'ephemeral' according to this clouds metadata";  for ec2 and OpenStack, theres no on-disk configuration (like in /etc or something) which shows this mapping;  On Azure, there are some /dev/disk/cloud/* symlinks pointing to different disk types (azure_root, azure_resource, azure_datadisk);
[16:11] <paride> blackboxsw_, it seems that travis didn't pick up https://github.com/canonical/cloud-init/pull/942
[16:12] <paride> I can't see it here https://travis-ci.com/github/canonical/cloud-init/pull_requests
[16:12] <blackboxsw_> paride: yeah I was just checking that to make sure we we have credits to run jobs
[16:12] <blackboxsw_> and there are no warning banners there about inability to build jobs
[16:12] <blackboxsw_> ... as happened in the past
[16:13] <blackboxsw_> I also see that PR #941  did get run a couple of hours before https://app.travis-ci.com/github/canonical/cloud-init/requests
[16:14] <blackboxsw_> well ubottu, those links are not so helpful
[16:17] <blackboxsw_> paride: WDYT about closing and re-opening the PR?
[16:18] <blackboxsw_> it doesn't seem like the build request was received for some reason
[16:18] <paride> blackboxsw_, sure
[16:20] <paride> blackboxsw_, https://github.com/canonical/cloud-init/pull/943/
[16:22] <paride> it doesn't seem to be working :(
[16:24] <blackboxsw_> yeah, I'm trying to remember if we've hit this before... checking settings on the project
[16:34] <mal41> rharper The disk aliases from the metadata side you describe seem to use the key "disk_aliases" (https://github.com/canonical/cloud-init/blob/main/cloudinit/sources/DataSourceAzure.py#L740). In contrast the "device_aliases" as documented (https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_disk_setup.py#L19-L23) suggests the user
[16:34] <mal41> (rather than the datasource) can provide their own. As far as I can see there is no code to support this.
[16:35] <paride> blackboxsw_, https://github.com/canonical/cloud-init/pull/941 is also not getting a travis run
[16:35] <paride> it got one but it's not getting re-run after the force-push
[16:45] <rharper> mal41:  you're right; it's not implemented, what does work is using aliases provided by block-device-mapping from metadata service ;   if you have time, please file a bug so we can remove that ;
[16:50] <mal41> rharper Thanks, appreciate the sanity check. It would have been a nice feature to have, so I may see how much work it would be to support it as documented and file either a bug or PR accordingly. Thanks again for your help. :D
[16:55] <rharper> mal41: sure ;  one challenge with user-supplied values is not being able to control the platform ...  I suppose in some scenarios (non-cloud) one might say {'ssd-disk1': /dev/disk/by-id/*SERIAL*}  or something like that to id the drive (and allow udev to handle the mapping to the kernel device name (sda, xvda, etc ... )
[17:03] <mal41> I believe it's udev rules that map the devices in some of the clouds (at least in Azure), and as this would only be a convenience mapping I wouldn't expect any functional difference to explicitly referencing the mapped value everywhere the mapping would be checked.
[17:13] <blackboxsw_> paride: hrm was able to trigger main building in travis, but still not seeing PR updates
[17:20] <blackboxsw_> #startmeeting cloud-init bi-weekly office-hours
[17:20] <meetingology> Meeting started at 17:20:28 UTC.  The chair is blackboxsw_.  Information about MeetBot at https://wiki.ubuntu.com/meetingology
[17:20] <meetingology> Available commands: action, commands, idea, info, link, nick
[17:22] <rharper> mal41: right, udev rules do the mapping (for azure, not sure if any other clouds are doing udev rule mapping as well); I guess I don't understand the use-case you have;
[17:23] <blackboxsw_> community-notice: Hi cloud-init folks. Bi-weekly office hours meeting has begun. We keep this time slot available to encourage designated periods of time where at least one  upstream cloud-init committer is available with eyes on the channel for any discussions about bugs, features, feature-requests and general support. Any cloud-init discussions are welcomed..
[17:23] <blackboxsw_> #chair rharper
[17:23] <meetingology> Current chairs: blackboxsw_, rharper
[17:24] <blackboxsw_> heya.... since you are around too :)
[17:25] <rharper> =)
[17:25] <blackboxsw_> the goal of the meeting time is an informal "meeting" where any questions and discussions can potentially gain broader audience... and anyone blocked can be unblocked whether it's for PR reviews, feature-work or general bug discussion.
[17:26] <blackboxsw_> anyhow. I've said my piece, we generally also put up high-level discourse post for out-of-band readers that might want to keep up to date on recent commits/changes in cloud-init
[17:26] <blackboxsw_> #link https://discourse.ubuntu.com/t/cloud-init-status-07-13-2021/23257
[17:27] <mal41> rharper Aside from being able to change a device in a single place, it would also be possible to define things like disk_setup and mounts once using aliases, and then have device_aliases overridden by a more instance specific secondary config. In my that would certainly reduce the amount of duplication between otherwise very similar configs which
[17:27] <mal41> is one of the reasons I started looking at it.
[17:27] <mal41> *in my case
[17:27] <blackboxsw_> note: upcoming upstream release is coming in august and we hope to get post-boot hotplug support into that release.
[17:35] <blackboxsw_> rharper: mal41, so that I understand the discussion, is the "bug" that you suggest filing to remove/correct docs on  https://github.com/canonical/cloud-init/blob/main/cloudinit/config/cc_disk_setup.py#L19-L23  to avoid claiming support for device_aliases?
[17:41] <mal41> I would prefer that the bug be to implement that feature as documented - if I understand correctly it seems achievable via couple of small modifications to cc_disk_detup and cc_mounts.
[17:41] <blackboxsw_> paride dunno what happened with Travis CI, but it appears "unstuck" after I ran the CRON CI run on main and is now building the PR941 https://travis-ci.com/github/canonical/cloud-init/builds/232639556. So we might expect a run from your PR shortly and we can merge it
[17:42] <mal41> But if it needs to be a low hanging fruit thing, then yes, removing the actively misleading documentation would be good until such time that a PR is ready and acceptable (of which part could be to revert any doc removal actioned in the interim).
[17:43] <blackboxsw_> mal41: I think it sounds like a reasonable feature request bug if you can state the use-case you are looking for. I don't think we would be averse to adding such a feature, just a question of priortizing it. We certainly can help shepherd in PRs that interested folks submit on this ;)
[17:44] <blackboxsw_> so either way, additional context on your use case in a but would help establish some level of priority and also give us something to point at as others may be looking for the same feature from userdata.
[17:46] <rharper> mal41: right, I understand the usefulness of the aliases, I meant more practically, how does one on a given platform actually predict (or configure) that a specific block device (/dev/sda) is the disk that you really want to call 'my-data-drive' as an alias ;  and note that /dev/sdX and friends are unstable across reboots/kernels/platform changes (some providers may be stable, but it's not guaranteed);
[17:50] <mal41> Hmm, I don't think this solves (and doesn't seek to solve) that issue - {"device_aliases": {"abc": "/dev/sdb"}, "disk_setup": {"abc": { ...cfg ...} } would suffer the only the same issue as with { "disk_setup": {"/dev/sdb": { ...cfg ...} } currently.
[18:15] <mal41> blackboxsw_ Apologies, I missed your question; the use it would be in my case would be better readability in the config, a single point of definition for devices referenced in disk_setup and mounts, and following from that the ability to override the aliases from a secondary config without needing to completely redefine those sections. The primary
[18:15] <mal41> case for the latter is when moving long-lived disks and instances between hardware in the cloud. i.e. Modify secondary config on OS disk ahead of time. Stop the instance, dettach/reattach disks to match new expectation in secondary config. Start the instance and have cloud-init understand the new disk devices and treat them appropriately without
[18:15] <mal41> the need to change the config that was baked into the instance at original provisioning time.
[18:17] <mal41> I'm certainly not oblivious to that probably being a very rare case, it's just one of those born of the stuff landing on my desk. :P
[18:35] <mal41> I slapped together this very ugly draft just to confirm I'm on the right lines, if you have a moment to give it a glance. It needs tests, real world testing, and clean up, but hopefully it's a not-insane start, ;)  https://github.com/canonical/cloud-init/compare/main...mal:device-aliases?expand=1
[18:35] <blackboxsw_> heh, understood the "stuff on my desk".  Yeah, I'm trying to wrap my head around how the detatch/reattach migration migration would work from cloud-nit perspective.
[18:36] <blackboxsw_> I'm trying to understand what you mean by ". Modify secondary config on OS disk ahead of time" llike supplementary #cloud-config userdata?
[18:39] <mal41> Yeah, so at the moment in this scenario I write out a smaller config affecting those areas I need to update, then modify the systemd service file to add the "--file /etc/cloud/override.yml" flag to the init call. Then when the system comes back after being stopped, it sees the instance ID has changed (as it's now on different cloud hardware) and
[18:39] <mal41> runs cloud-init but with the modifications injected by the on disk config.
[18:40] <blackboxsw_> hrm, so both "source storage machine" with orig long-lived disks and "target new storage target machine" would have been deployed with the same storage mount aliases and config expectations, and the migration process would be to detach orig disks for source machine, attach to target machine and launch target machine where the config is properly adapted and mount .
[18:43] <mal41> In a sane world yes, but when you're handed VMs that have persistent data on their OS disk which can't be mounted on the new instance, then you start seeing the lovely idea of using a new properly configured instance slowly drift out of the window. :(
[18:43] <mal41> "Can we just move the data?" "Not at this time." ¬_____¬
[18:56] <blackboxsw_> please correct me on my understanding (now that I've looked over your diff) ....
[18:56] <blackboxsw_> mal41: ok, so simply, for "migration reasons" you want to be able to simply support the documented device_aliases config dict as variable replacement values across both cc_disk_setup and cc_mount config modules to avoid repetition in user-data definitions because in your case you generally know what those alias to device path mappings will be on the "new" system
[19:11] <blackboxsw_> I put that question simply so you can correct me; but I was wondering if YAML anchors and aliases themselves would work for the case of defining repeated path cases within the mounts module in the absence of this feature.    That said, looking over your diff I get the context a bit and your desire to use device_aliases config keys in both mounts and cc_disk_setup.
[19:12] <blackboxsw_> In both of those patch cases, I'd prefer seeing something that'd fallback to the originally behavior if the key wasn't present in device_aliases.
[19:14] <blackboxsw_> what you have written for disk_setup seems to do that.... first a lookup in device_aliases cfg (if unset we can just make that an empty dict {}) and we can avoid the if/else handling.
[19:17] <blackboxsw_> but.... yeah, a good example #cloud-config that you expect you'd use would help clarify your desired flow.
[19:19] <blackboxsw_> ok, let's wrap up office hours for today. Thanks all for the discussions, we can continue device_aliases discussions as needed or as a PR or bug is created for ongoing discusssion. As always, drop in with any questions you might have. Thanks again
[19:19] <blackboxsw_> #endmeeting
[19:19] <meetingology> Meeting ended at 19:19:39 UTC.  Minutes at https://new.ubottu.com/meetingology/logs/cloud-init/2021/cloud-init.2021-07-13-17.20.moin.txt
[19:20] <blackboxsw_> In testing that udev hotplug network branch on rocky linux I found some issues with SELinux blocking the ability of systemd units from creating FIFO queues
[19:21] <blackboxsw_> I'll probably put up something, but we might have to sort the SELinux needs there if our current hotplug approach is going to work in SELinux controlled environments
[19:45] <mal41> Thanks blackboxsw_, I'll do another pass or two over that diff and test and clean it up a bit and can go from there. :)
[20:18] <blackboxsw_> +1 thx mal41


[01:32] <mup> PR snapd#10105 closed: ci: set the accept-existing-contributors parameter for the cla-check action <Skip spread> <Created by jhenstridge> <Merged by jhenstridge> <https://github.com/snapcore/snapd/pull/10105>
[07:13] <pstolowski> hey
[12:44] <mup> PR snapd#10108 opened: spread: tentative workaround for arch failure caused by apparent libc upgrade <⚠ Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/10108>
[12:48] <pstolowski> ijohnson[m][m]: hey, u there?
[12:59] <ijohnson> hey pstolowski
[12:59] <pstolowski> hey ijohnson
[12:59] <pstolowski> ijohnson: i've a fix for arch issue
[13:00] <pstolowski> but we may not be able to land :/
[13:00] <ijohnson> Ah that's unfortunate
[13:00] <ijohnson> Should we do SU?
[13:00] <pstolowski> i mean due to review capacity
[13:00] <pstolowski> we can, a quick one
[13:34] <mup> PR snapd#10109 opened: interfaces/builtin/gpio_test.go: actually test the generated gpio apparmor <Simple 😃> <Skip spread> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10109>
[13:36] <ijohnson> pstolowski: I approved the arch pr, are there any other pr's you need reviews on today that I could do?
[13:36] <ijohnson> (I have plenty to do otherwise, just curious if I could help unblock you on this quiet day today :-) )
[13:37] <pstolowski> ijohnson: thanks; not really, i just need happy travis now ;)
[13:37] <ijohnson> haha yeah makes sense
[14:00] <pstolowski> ijohnson: the tension of arch linux tests still running on that PR is unbearable
[14:06] <ijohnson> pstolowski: well the fact that it's still running is a good sign, it would have failed immediately if it didn't work :-)
[14:28] <pstolowski> ijohnson: it failed on 6 tests on arch :(
[14:28] <pstolowski> everything is terrible today
[14:28] <ijohnson> it is friday after all
[14:31] <pstolowski> ijohnson: one test has an easy fix, it seems arch now needs to follow debian-sid and new fedoras
[14:32] <pstolowski> others are not obvious
[14:32] <pstolowski> aah
[14:32] <pstolowski> cgroupv2 is not supported
[14:34] <ijohnson> so arch is now cgroupsv2 too ?
[14:35] <pstolowski> it seems judging from the warning message in snapctl-is-connected test
[14:35] <pstolowski> i'm disabling arch in these tests now
[14:38] <pstolowski> updated the PR, let's see
[16:25] <mup> PR snapd#10110 opened: interfaces/builtin: introduce dsp-control interface <⛔ Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/10110>


[08:30] <JamesTait> Good morning all, happy Chocolate Pudding Day! :-D
[22:51] <seifpic> Hello, I have been using ubuntu one for a couple of days now and I have been able to publish files through the web application. However I just uploaded a 57.1MB file and there is no publish option under the more menu
[22:52] <seifpic> The file is a zipped folder which I have been deleting and reuploading each time I update it
[23:01] <seifpic> Any idea?
[23:08] <seifpic> nothing?