| lifeless | ok, going quiet to get code written | 00:47 |
|---|---|---|
| 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:09 |
| wgrant | Only 10 minutes? Not bad. | 01:11 |
| SpamapS | still not done ;) | 01:11 |
| wgrant | It's nearly done. | 01:11 |
| 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:12 |
| wgrant | LP's history is not small, and bzr 2a fetch is not fast :( | 01:13 |
| 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:15 |
| 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:16 |
| 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:17 |
| 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:18 | |
| wgrant | You want to create a new charms series, I guess? | 01:19 |
| wgrant | What do you want to populate? | 01:19 |
| cjwatson | Phew. germinate 2.1 released, MP updated, IMO all good bar the shouting now. | 01:20 |
| wgrant | Shouting? | 01:20 |
| 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:21 |
| wgrant | Ah. | 01:22 |
| cjwatson | Although it wouldn't surprise me if somebody wanted to shout at me about some bits of the test code. :-) | 01:23 |
| 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:24 |
| 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:26 |
| poolie | we've measured the same effect from the US | 01:28 |
| wgrant | Huh | 01:29 |
| wgrant | I've seen some slowness from elsewhere. | 01:29 |
| wgrant | But never as slow as I see. | 01:29 |
| === jtv is now known as jtv-eat | ||
| === jtv-eat is now known as jtv | ||
| === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugtasks: 3*10^2 | ||
| jtv | wgrant: any chance you could help this user? https://answers.launchpad.net/launchpad/+question/181066 | 03:51 |
| 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:52 |
| wgrant | It's all been fixed for a couple of hours. | 03:53 |
| 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:20 |
| huwshimi | wgrant: Done | 04:26 |
| wgrant | huwshimi: Thanks. | 04:26 |
| lifeless | poolie: is your new bug a dup of 894535? | 05:01 |
| 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:02 |
| lifeless | ah, there is a different 89* bug about that | 05:10 |
| wgrant | Mmm, unused portlets. | 05:16 |
| * wgrant destroys. | 05:16 | |
| lifeless | right, time to EOD. | 05:31 |
| * lifeless EODs | 05:31 | |
| wgrant | Night lifeless. | 05:32 |
| === jtv1 is now known as jtv-eat | ||
| huwshimi | The new https://bugs.launchpad.net/launchpad is a welcome change | 06:37 |
| wgrant | Yep | 06:37 |
| wgrant | One of the most annoying pages in LP has finally met its demise :) | 06:38 |
| huwshimi | :D | 06:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| wgrant | To the user it just appears that they've been copied, right. | 06:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| huwshimi | wgrant: I just expected it to be part of the new bugs listing beta. It's a fairly big change, I guess someone will blog about it later or something | 06:49 |
| wgrant | huwshimi: It's not a huge change. It's basically just expanding the listing and changing the default sort order. | 06:49 |
| wgrant | Which AFAICT nobody liked anyway. | 06:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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:58 |
| huwshimi | _mup_: Shhh | 06:59 |
| micahg | huwshimi: right, that's what I take issue with :) | 06:59 |
| wgrant | micahg: Which browser are you using? Your fonts are ugly and misaligned. | 07:00 |
| micahg | firefox 9 beta | 07:00 |
| 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:01 |
| 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:02 |
| 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:03 | |
| * micahg guesses mup isn't ubottu :) | 07:04 | |
| micahg | https://bugzilla.gnome.org/show_bug.cgi?id=305277 | 07:04 |
| 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:05 |
| 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:06 |
| 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:08 |
| bkerensa | :D | 07:12 |
| === almaisan-away is now known as al-maisan | ||
| === jtv-eat is now known as jtv | ||
| adeuring | good morning | 08:53 |
| === al-maisan is now known as almaisan-away | ||
| 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:12 |
| 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:20 |
| 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:21 |
| 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:23 |
| jtv | ISWYM. It's a tough tradeoff. In a functional language you don't have assignments to worry about. | 11:24 |
| jtv | And a class is probably overkill. | 11:25 |
| cjwatson | I actually want curried functions for composeOutputPath, really ... | 11:25 |
| jtv | Yeah. :) | 11:25 |
| 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:26 |
| 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:27 |
| jtv | Neat! test_name_is_consistent & test_name_is_unique_for_each_distro | 11:29 |
| cjwatson | .get> oh yes. | 11:30 |
| cjwatson | Can't claim credit for that; that was stolen from test_generate_contents_files. | 11:30 |
| jtv | It did sound familiar. I think I wrote that. :) | 11:31 |
| cjwatson | Nice to know you like your own code. ;-) | 11:31 |
| 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:41 |
| 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:45 |
| 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. | 11:56 |
| * jtv watches the code break into smaller parts | 12:05 | |
| === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2 | ||
| cjwatson | jtv: Yep, that's more or less what I did | 12:08 |
| 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:11 |
| cjwatson | ("%s: %s" % (seed_name, seed_inherit.get(seed_name, []))).strip() or something | 12:12 |
| jtv | cjwatson: Or just treat the "%s:" % seed_name as one of the elements of the list, I guess. | 12:22 |
| jtv | " ".join(["%s:" % seed_name] + seed_inherit.get(seed_name, [])) ? | 12:23 |
| jtv | Also a bit involved, I must admit. | 12:23 |
| 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:40 | |
| bigjools | "critiqued" :) | 12:41 |
| cjwatson | well, OK :-) | 12:41 |
| rick_h_ | context managers ftw | 12:41 |
| 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:42 |
| jtv | If you neglect to do it while writing, python will generally punish you very quickly. | 12:43 |
| 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:44 |
| bigjools | it's not the tardy GC as such, it's the open file | 12:45 |
| jtv | But doesn't the GC also close the file? | 12:46 |
| bigjools | yes - but when? | 12:46 |
| 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:47 |
| cjwatson | The system limit is typically large but not enormous. | 12:48 |
| 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:49 |
| 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:50 |
| 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:51 |
| 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. But we have a solution for that: we call our code the spec, and not the thing we publish as the spec." | 12:52 |
| bigjools | I want to make a new Python interpreter and call it TrouserSnake | 12:53 |
| jtv | Him and his dirty mind. | 12:53 |
| rick_h_ | so debugging question for you all, if I had a pair of ids for Message objects, and I wanted to "see" them to find out wtf they were and maybe compare how they were different. How would I get at them? Normally I'd expect to just look at the db, but this is on production | 12:53 |
| 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:54 |
| 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:55 |
| 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:56 |
| 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:57 |
| 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 | 12:58 |
| 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:03 |
| === jtv is now known as jtv-afk | ||
| 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:04 |
| 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:05 |
| cjwatson | jtv-afk: I found a way to write makeSeedStructure that avoids multiple paths without being too twisty, I think. | 13:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:23 |
| 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:24 |
| wgrant | # that to reduce on-demand parent lookups. | 13:25 |
| wgrant | parent = message_by_id.get(parent.id, parent) | 13:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| benji | rick_h_: it's urlificable, obviously | 13:32 |
| * wgrant should sleep. | 13:32 | |
| * rick_h_ smacks head | 13:32 | |
| 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:34 |
| 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:42 |
| matsubara | mrevell, I can give it a shot. My SQL knowledge isn't that great | 13:43 |
| * matsubara looks for postgresql docs | 13:43 | |
| 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! | 13:44 |
| === matsubara is now known as matsubara-lunch | ||
| 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 > | 14:34 |
| === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: abentley | Critical bugtasks: 3*10^2 | ||
| === matsubara-lunch is now known as matsubara | ||
| 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:45 |
| 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:46 |
| adeuring | abentley: ...so that all "show_" names match corresponding sort options? | 15:47 |
| 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:48 |
| adeuring | abentley: I see your point-- but "correlating" the sort buttons and the "show_.*" flags is in this case a bit messy... | 15:49 |
| adeuring | abentley: and "show_id" does not match "Bug number" that well ;) | 15:50 |
| adeuring | (in a very literal sense...) | 15:50 |
| 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:52 |
| 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:55 |
| 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:57 |
| 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:58 |
| stub | lifeless: yo | 15:59 |
| lifeless | stub: categorising patches | 15:59 |
| 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:00 |
| 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:01 |
| abentley | adeuring: That's what I thought. | 16:02 |
| 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:03 |
| 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:05 |
| lifeless | allenap: so yes, looks like you linked the wrong bug, and/or they are dupes | 16:06 |
| 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:07 |
| allenap | I'd like to treat them as separate problems. | 16:08 |
| 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:09 |
| abentley | adeuring: yes, I can see how your solution would be simpler, then. | 16:10 |
| adeuring | abentley: ok, so'll go that route | 16:10 |
| 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:14 |
| deryck | adeuring, so I'll just fix up the card and the bug assignment, if you have no objections. | 16:15 |
| adeuring | deryck: ok | 16:16 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:33 |
| === salgado is now known as salgado-lunch | ||
| lifeless | allenap: testtools/unittest2 also have xfail | 16:36 |
| 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:38 |
| allenap | :) | 16:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| lifeless | totally | 16:44 |
| lifeless | and the bits done so far are working very well, if I do say so myself | 16:44 |
| 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:47 |
| 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:51 |
| 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:57 |
| rick_h_ | abentley: thanks, yea I originally started with test.py and the .py seems to be what got me off wrong | 16:58 |
| allenap | lifeless: I say so too, they're tip top. | 17:01 |
| lifeless | allenap: thanks! | 17:05 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:12 |
| lifeless | later y'all | 17:20 |
| 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:28 |
| 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:29 |
| 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:30 |
| abentley | deryck: "A cookie created with specific options can only be deleted by specifying the same options" -> http://yuilibrary.com/yui/docs/cookie/ | 17:31 |
| deryck | abentley, ah, ok. sorry. but the test does pass without specifying the options? but it doesn't actually work? | 17:32 |
| 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:33 |
| deryck | abentley, essentially, yes. but it would be better to delete the cookie entirely. | 17:34 |
| 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:35 |
| deryck | Assert.isNull(Y.Cookie.get('foo')) | 17:36 |
| abentley | deryck: neither did I :-) | 17:37 |
| deryck | abentley, heh. no worries then :) | 17:38 |
| 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:39 |
| abentley | bigjools: looking | 17:40 |
| 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:43 |
| 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:44 |
| bigjools | I havent', how does that change things? | 17:45 |
| 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:46 |
| abentley | bigjools: see test_conversation for an example. | 17:48 |
| bigjools | gotcha | 17:48 |
| bigjools | abentley: test passing, thanks! | 17:52 |
| abentley | bigjools: np. | 17:53 |
| bigjools | I should look in lp/code more often, there's some testing gems in there | 17:55 |
| bigjools | can't create MPs when the branch scanner is looking at your branch it seems :( | 17:57 |
| === salgado-lunch is now known as salgado | ||
| 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:20 |
| 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:21 |
| rick_h_ | deryck: looking | 18:22 |
| 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:29 |
| 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:30 |
| 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:31 |
| rick_h_ | deryck: oh ok, that's different then. | 18:32 |
| 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:33 |
| bac | flacoste: i got the impression, perhaps from talking to steve, that he was the main person affect. that could be wrong. | 18:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| flacoste | bac: what's in natty? | 18:39 |
| flacoste | and oneiric | 18:39 |
| 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:40 |
| lifeless | whats the new tag again | 18:41 |
| lifeless | selfinflicted? | 18:41 |
| 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:42 |
| flacoste | lifeless: fallout | 18:44 |
| flacoste | if regression isn't appropriate | 18:44 |
| 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:45 |
| 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:46 |
| lifeless | sinzui: its broken previously working nominations though | 18:47 |
| lifeless | sinzui: doesn't that make it a regression ? | 18:47 |
| sinzui | It can be both. I treat regressions (and fallout) as top priority kanban cards | 18:48 |
| 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:49 |
| sinzui | okay I will switch to regression | 18:50 |
| 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:08 |
| deryck | abentley, ah, ok. that's needed for cookie testing in chromium though. | 19:09 |
| bac | so flacoste did we come to a conclusion? | 19:13 |
| 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:14 |
| 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:15 |
| flacoste | bac: yep | 19:17 |
| poolie | sladen, hi, do you have any advice on https://code.launchpad.net/~mbp/launchpad/714831-beta-font/+merge/84716 | 19:52 |
| poolie | actually that should be https://code.launchpad.net/~mbp/launchpad/714381-beta-font/+merge/84716 | 19:53 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| bkerensa | deryck: Just brief run down so I can put it in the Devel News :) | 20:13 |
| 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:14 |
| 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:15 |
| deryck | bkerensa, I think that's about it. | 20:16 |
| bkerensa | deryck: ok thanks :D | 20:16 |
| deryck | np | 20:17 |
| === matsubara is now known as matsubara-afk | ||
| abentley | bac: Any chance you could do a reivew? I'm OCR today and don't want to self-review. | 20:45 |
| bac | abentley: sure, in a bit. MP? | 20:46 |
| abentley | bac: https://code.launchpad.net/~abentley/launchpad/fix-reset-to-default Thanks. | 20:46 |
| abentley | bac: abort. jcsackett took it. | 20:53 |
| 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:54 |
| bac | flacoste: ok | 20:55 |
| bac | poolie had request it too. | 20:55 |
| jelmer_ | :q | 20:58 |
| lifeless | ok, time to run for next medical thing. Ciao. | 21:07 |
| 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:31 |
| sinzui | abentley, do you have time for a short review https://code.launchpad.net/~sinzui/launchpad/nomminate-driver-permissions-1/+merge/84850 | 21:42 |
| 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:43 |
| abentley | sinzui: r=me. | 21:46 |
| sinzui | thank you very much | 21:46 |
| === abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugtasks: 3*10^2 | ||
| abentley | sinzui: np | 21:46 |
| === jelmer_ is now known as jelmer | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
