[02:33] <Ursinha> hello launchpad
[02:33] <StevenK> Ursinha: Hi! How was your flight?
[02:33] <spm> heya Ursinha
[02:33] <Ursinha> StevenK, was nice, it was delayed 50 minutes but I got home at last :)
[02:33] <Ursinha> and yours?
[02:33] <Ursinha> spm, hey :)
[02:33] <StevenK> Ursinha: Both of mine were okay, apart from the food.
[02:33] <Ursinha> ah, food
[02:33] <Ursinha> StevenK, I'm not taking food into account :P
[02:44] <huwshimi> Ursinha: Well to take it into account, first you actually have to classify it as food.
[02:44] <Ursinha> hahahahaa
[02:44] <Ursinha> huwshimi, good point
[02:46] <StevenK> huwshimi: Haha. How were your flights?
[02:47] <huwshimi> StevenK: Better than on the way to Dallas. My flight into Sydney was even 30 min early.
[02:49] <huwshimi> StevenK: How about you?
[02:50] <StevenK> Transisting via SFO is annoying, since the walk from domestic to international should be measured in kilometres.
[02:50] <huwshimi> StevenK: Ouch.
[02:50] <StevenK> However, both flights were on time, fairly smooth. The only let down was food on the SFO-SYD leg.
[02:59] <jorjoso> hello people¡¡
[02:59] <Ursinha> I'm glad you're all home and fine :) I'll try to sleep to minimize jet lag
[02:59] <Ursinha> :)
[02:59] <huwshimi> Ursinha-afk: Night
[03:01] <jorjoso> I would like to  create a background for ubuntu narwhal do you know the deadline ?
[03:01] <lifeless> no idea; I suggest asking in an Ubuntu channel
[03:02] <lifeless> perhaps #ubuntu-devel or #ubuntu-desktop
[03:03] <jorjoso> lifeless: thankyou
[03:04] <huwshimi> jorjoso: I believe the date is something like the 13th of March. But if you ask in #ubuntu-devel or #ubuntu-desktop someone might be able to tell you for certain
[03:04] <jorjoso> thanks
[03:04] <jorjoso> :D
[04:22]  * wgrant wanders in.
[04:23] <huwshimi> wgrant: Afternoon
[04:24] <wgrant> First leg late, second leg bumpy. Yay, I love airlines.
[04:25] <spm> better bumpy than a short sharp crash.
[04:25] <wgrant> It wasn't an A380 this time, so I was safe.
[04:25] <spm> heh
[04:31] <StevenK> My flight wasn't an A380. I was hopeful.
[04:31] <wgrant> You didn't check beforehand?
[04:32] <StevenK> I did -- when I booked it :_)
[04:32] <wgrant> I think QF12 (LAX->SYD, not long before mine) was an A380.
[04:33] <StevenK> I suspect all of the SFO flights won't be A380s
[05:01] <wgrant> huwshimi: Is the plan still to have you on the green squad call?
[05:04] <huwshimi> wgrant: Erm, possibly. Does Curtis lead that team?
[05:06] <wgrant> huwshimi: That's the one.
[05:06] <wgrant> me/curtis/jcsackett
[05:06] <huwshimi> wgrant: Yeah I think I'm supposed to be a part of those calls, but I haven't heard any details yet.
[05:07] <wgrant> huwshimi: We've scheduled them for around 9am AEDT, for now.
[05:07] <huwshimi> wgrant: ah ok
[05:08] <wgrant> Which is a bit of an improvement from my previous 20:30 call :/
[05:08] <wgrant> StevenK: When's yours now?
[05:08] <huwshimi> wgrant: yeah that would have been horrible
[05:09] <StevenK> wgrant: 8am
[05:10] <wgrant> StevenK: Ah, not too bad.
[05:13] <spm> shockingly mine was just adjusted from 7am to 9am. it's horrible I tell you.
[05:16] <huwshimi> We have a public holiday on Wednesday right?
[05:16] <wgrant> Yup.
[05:16] <wgrant> Have you applied for it?
[05:16] <wgrant> If not... you'd better hope canonicaladmin unbreaks!
[05:16] <huwshimi> wgrant: No-one told me I needed to apply for it :)
[05:17] <StevenK> They can be put in afterwards, HR prefers if they're done before.
[05:17] <wgrant> You need to enter leave on canonicaladmin.com, I believe.
[05:17] <huwshimi> Ah right
[05:17] <wgrant> Is is at the moment, however, less than up.
[05:20] <huwshimi> wgrant: Would be funny to miss out on a public holiday because a website wasn't working.
[06:15] <poolie> hi wgrant, huwshimi
[06:16] <wgrant> Evening poolie.
[06:16] <huwshimi> poolie: Hey there.
[06:47]  * huwshimi is heading off... to sleep
[09:03] <mrevell> Good morning
[10:51] <jml> good morning
[12:00] <deryck> Morning, all.
[12:34] <adeuring> good morning
[13:12] <leonardr> i have a question for anyone interested in launchpad bugs
[13:12] <leonardr> my web_link code generally gives the results i would expect, but the web_link for a bug watch has a hostname of launchpad.dev, not bugs.launchpad.dev
[13:12] <leonardr> is that expected/okay?
[13:13] <leonardr> i see that either url works, i'm just wondering what's correct and if this is a problem i should look into
[13:16]  * jml doesn't know
[13:16] <deryck> leonardr, as you say, either should work.  But the bugs domain would be the correct one.
[13:17] <leonardr> deryck, do you want to help me figure this out?
[13:18] <deryck> leonardr, not really :-)  I'm sooooo done with bugs. ;)
[13:18]  * deryck is kidding
[13:18] <leonardr> deryck: give me a minute to re-learn what i wrote last week, and i'll explain it to you
[13:18] <deryck> leonardr, sure, that works
[13:19] <leonardr> the lazr.restful branch is https://code.launchpad.net/~leonardr/lazr.restful/web-link/+merge/46992
[13:19]  * deryck looks
[13:26] <deryck> leonardr, is it just for a bug watch that the bugs domain is omitted?  I assume other resources are in the correct domain?
[13:28] <leonardr> deryck: yes, for a bug you get bugs.launchpad.dev
[13:28] <deryck> leonardr, and paste me an example url of the watch, please.
[13:28] <leonardr> deryck: to explain the branch briefly, we look for a registered function capable of converting a web service request into a website request
[13:29] <leonardr> web_link: u'http://launchpad.dev/bugs/1/+watch/2'
[13:29] <_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
[13:29] <leonardr> as it happens, launchpad has defined such a function already, for the librarian
[13:30] <leonardr> as you can see in https://code.launchpad.net/~leonardr/launchpad/web-link/+merge/47258 once it's scanned
[13:32] <leonardr> we are using absoluteURL to generate the url to the object, passing in the object + the fake website request
[13:34] <deryck> ok, just looking over a few things here
[13:40] <deryck> leonardr, so this seems to me it's on the lp side, not lazr.restful that this is going wrong, yes?
[13:41] <leonardr> deryck: i agree
[13:42] <deryck> I'm wondering if we just need a "rootsite" attribute in the zcml for bug watches.  i.e. if it's just omission of this, not by design, that we have both urls for watches.
[13:42] <leonardr> deryck: i think that's the piece i was looking for
[13:42] <leonardr>         <browser:url
[13:42] <leonardr>             for="lp.bugs.interfaces.bugwatch.IBugWatch"
[13:42] <leonardr>             path_expression="string:+watch/${id}"
[13:42] <leonardr>             attribute_to_parent="bug"/>
[13:42] <leonardr> lib/lp/bugs/browser/configure.zcml
[13:43] <leonardr> of course, fixing that might cause all sorts of other test failures
[13:43] <leonardr> i'll fix the other stuff first and come back to this
[13:43] <deryck> leonardr, http://pastebin.ubuntu.com/557658/
[13:43] <deryck> leonardr, and yeah, just see what sorts of failures we get in tests.
[13:44] <deryck> leonardr, grep turns up on test using the non-bugs url.  xx-bugwatch-comments.txt
[13:45] <leonardr> all right, thanks for your help
[13:45] <deryck> np
[13:47] <leonardr> deryck: same problem with CVE, actually
[14:00] <deryck> abentley, adeuring, henninge -- stand up in mumble now, if we all remembered and are here. :)
[14:00] <adeuring> ok
[14:00] <abentley> deryck, ack
[14:00] <henninge> deryck: I am here but have to see if mumble likes me
[14:03] <deryck> henninge, ok, we have an orange room now
[14:09] <leonardr> ok, here's another problem--not sure who can help, but i'll spell it out
[14:10] <leonardr> the HWDB resources have a web_link and they shouldn't
[14:12] <leonardr> if the attempt to navigate to the HWDB web_link raised an exception, i could deal with that easily
[14:13] <leonardr> but it gives me a url that's not really present
[14:13] <leonardr> i'm going to leave it alone for now, but the current solutions i have in my head are ugly, so i would like some help
[14:16] <jml> sinzui: we're down to talk today. Do you still want to?
[14:16] <leonardr> adeuring, cr3 says you're the one to talk to about this
[14:17] <sinzui> jml: I do not have anything for today...but we are keeping this slot right?
[14:17] <jml> sinzui: I'm happy to if you think it will help you.
[14:18] <adeuring> leonardr: can you explain the the problem a bit? What is the wrong link?
[14:18] <sinzui> jml: I want to keep it.
[14:18] <jml> sinzui: cool. consider it kept, but cancelled for today
[14:18] <leonardr> adeuring: sure.
[14:18] <jml> sinzui: btw, can you please send Huw details about your team's standup?
[14:18] <leonardr> if you GET http://api.launchpad.dev/beta/+hwdb, you get back a response including this:
[14:18] <leonardr> web_link: u'http://launchpad.dev/+hwdb'
[14:19] <leonardr> which would be accurate if the hwdb were published on the website, but it's not
[14:19] <adeuring> ah, I see. The problem is that we don't want the HWDB to be publicly avaiable
[14:20] <leonardr> adeuring: yes, but i'm not sure how to determine that ahead of time
[14:21] <leonardr> i think the best solution would be to have the traversal code raise an exception unless the request is a web service request?
[14:22] <adeuring> leonardr: sounds reasonable. The other option would be to raise Unauthorzied for users who are not in the group "hwb-team" or somesuch
[14:23] <adeuring> erm, hwdb-team
[14:23] <leonardr> adeuring: i don't understand. would that url work if i were in the right group?
[14:23] <adeuring> leonardr: at least formally. OTOH, the is no real content to show on the web.
[14:24] <adeuring> so, raising an exception for any non-webservice requests is probably more reasonable
[14:25] <leonardr> adeuring: do you know where to put that code? i have no idea except maybe there's a traversal method somewhere in services/hwdb
[14:26] <leonardr> adeuring: just out of curiosity, what about a link like http://launchpad.dev/+hwdb/+driver/10 ? would that nominally work on the website?
[14:26] <adeuring> leonardr: no, the HWDB is only exposed via the webservice
[14:27] <leonardr> adeuring: in that case, we should definitely raise an exception during traversal
[14:27] <adeuring> leonardr: right. regarding the right place for the exception: I have no real clue. Maybe gary_poster has a suggestion?
[14:27]  * gary_poster reads back
[14:28]  * gary_poster wonders how far to read back
[14:28] <adeuring> gary_poster: ca 10 minutes
[14:28] <leonardr> gary: to 9:12
[14:28] <gary_poster> ok thanks
[14:29] <leonardr> i guess i'm thinking that we should *traverse* the url after it's generated and see if it raises an exception. but there must be a better way
[14:29] <leonardr> fwiw, my alternative is to add a lazr.restful declaration @no_web_link and apply it to the hwdb resources. but that feels like duplication of information
[14:33] <gary_poster> leonardr: making sure I understand.  You want to have lazr.restful know a quick way to determine whether a given url (hwdb in this case) will fail.  You don't really want this to happen when someone clicks on the url--that's too late.  You want to never render it.  Traversal is not a natural place for this in the current scheme of things, because we don't traverse urls when we generate them.  Do I understand prop
[14:33] <leonardr> gary: yes
[14:33] <leonardr> i was initially surprised that we could generate urls that wouldn't work, but now i understand that the code is different
[14:34] <gary_poster> OK.  using traversal would be expensive and unpleasant.  Can we look at what is generating URLs instead, and make that complain?
[14:35] <leonardr> gary: we can sure try
[14:36] <gary_poster> leonardr: ok.  Would you like me to dig into that code briefly, or do you want to do it and report back?
[14:36] <gary_poster> If you want me to dig, you'll need to get me started
[14:36] <leonardr> gary: i'm going to look up one thing and maybe we can go from there
[14:36] <gary_poster> ok cool
[14:36] <leonardr> this would be lib/lp/hardwaredb/browser/configure.zcml
[14:36] <leonardr>     <browser:url
[14:36] <leonardr>         for="lp.hardwaredb.interfaces.hwdb.IHWDBApplication"
[14:36] <leonardr>         path_expression="string:+hwdb"
[14:36] <leonardr>         parent_utility="canonical.launchpad.webapp.interfaces.ILaunchpadRoot"/>
[14:37] <leonardr> what's the code that runs that? the zope IAbsoluteURL implementation?
[14:37] <cr3> leonardr: my concern with raising an exception is that the hwdb still gets published in the wadl, I would much prefer to have a way to extend the wadl dynamically for other selfish reasons :)
[14:38] <leonardr> cr3: you make a good point. ideally the web_link would show up in the wadl definition for other resources but not for the hwdb
[14:39] <leonardr> that implies we need some way of knowing that hwdb resources don't have web_link, without access to any particular hwdb resource
[14:39] <leonardr> that argues for @no_web_link
[14:39] <leonardr> gary, before you go hunting, what do you think of that? -^
[14:41] <gary_poster> leonardr: it makes sense to me, tbh.  It's not ideal that you have to make the same logical declaration twice, but I think other frameworks also require separate configuration of url generation and url parsing.
[14:41] <leonardr> all right, i will land my existing lazr.restful branch and then add no_web_link
[14:42] <gary_poster> cool
[14:42] <leonardr> i'll just skim the test failures to see if there are any other obvious problems
[14:45] <tiagoscd> hey
[14:45] <tiagoscd> i would like to get more informations about ReportingAPI (https://dev.launchpad.net/Translations/Specs/ReportingAPI)
[14:46] <danilos> tiagoscd, hey-hey, welcome to the right place (fwiw, I might be the right person to help out about that topic, but development discussions usually happen here)
[14:46] <tiagoscd> David tell me that I can found help here
[14:46] <tiagoscd> ok danilos
[14:48] <danilos> tiagoscd, so, the story there is quite complicated, and I am not sure where it's well written down (if anywhere)
[14:49] <tiagoscd> when I try to access the page https://blueprints.launchpad.net/rosetta/+spec/translations-reporting-api, that are divulgated in dev.launchpad.net, i got the "Page not found" error
[14:49] <tiagoscd> so, where I can found the currently source code?
[14:50] <leonardr> ok, the only other problem i see is that the web_link for a wiki_name keeps the api vhost. probably we can fix that at the same time as the bug watch and CVE.
[14:53] <danilos> tiagoscd, well, it's all in LP tree... however, the problem is that it'd be ugly to expose the existing LP API because it's broken... we have implemented new ITranslateLanguage interface which is much nicer and we'd want to export that instead of IRosettaStats, but one would first have to switch DistroSeriesLanguage and POFile to use it
[14:54] <danilos> tiagoscd, see also bug 583979 and bug 583934
[14:54] <danilos> tiagoscd, discarded branch from Adi on https://code.launchpad.net/~adiroiban/launchpad/bug-583934/+merge/26965 might help you get a better understanding about how it all works
[14:54] <dpm> tiagoscd, just for reference, the link to the blueprint is https://blueprints.launchpad.net/ubuntu/+spec/community-m-launchpad-translations-reporting-api - I've updated the wiki page that had the broken link (I'll leave Danilo take it from there)
[14:56] <tiagoscd> danilos, i'll take a look,
[14:56] <tiagoscd> dpm, thanks for the link
[14:57] <salgado> sinzui, should a product's driver be the default release manager (called driver in the code) of a series?
[14:58] <sinzui> salgado: no. We do not want to auto-populate that value. Th user who creates the series should be the release manager (consider the experimental series case), or the project owner should set it
[14:59] <sinzui> salgado: we expect the release manager to be a smaller group of people than project drivers
[14:59] <lifeless> morning
[15:00] <sinzui> lifeless: where are you?
[15:00] <salgado> sinzui, that makes sense.  I asked because people seemed to be expecting that and got surprised when being product driver didn't give them RM rights
[15:00] <lifeless> at home
[15:00] <lifeless> its 4am
[15:01]  * lifeless is feeling the jetlag 
[15:01] <sinzui> lifeless: :(
[15:01] <bigjools> good morning all
[15:01] <sinzui> salgado: so the user registered a series and did not get RM?
[15:02] <lifeless> sinzui: it could be worse; I'm reasonably alert, just at a whacky time of day
[15:02] <bac> morning bigjools
[15:02] <bigjools> Hello Bradders
[15:02] <lifeless> hi bigjools
[15:02] <bigjools> hey jetlagged man
[15:02] <bac> bigjools: how's austin?
[15:02] <salgado> sinzui, I'm not sure who registered the series (can't seem to find that information), but the user was a driver of the product and was expecting to be able to create milestones
[15:03] <bigjools> bac: Sunny and not cold.  \o/
[15:03] <bac> bonus!
[15:03] <lifeless> allenap: hi; how would we qa Bug 227334 ?
[15:03] <_mup_> Bug #227334: checkwatches should raise a BugTrackerConnectError when Mantis doesn't set a return path <bugwatch> <lp-bugs> <oops> <qa-needstesting> <story-reliable-bug-syncing> <trivial> <Launchpad itself:Fix Committed by allenap> < https://launchpad.net/bugs/227334 >
[15:03] <bigjools> indeed
[15:03] <sinzui> salgado: understood.
[15:07] <bigjools> lifeless: are you staying up or heading back to bed?
[15:07] <lifeless> bigjools: staying up
[15:07] <lifeless> bigjools: I'm terrible at getting back to sleep once awake
[15:08] <bigjools> lifeless: ah ok, I am going to take a look at https://bugs.launchpad.net/launchpad/+bug/618395 later, I might need to grab you for ideas.
[15:08] <_mup_> Bug #618395: DistroArchSeries:+index timing out ~ 7% of the time <lp-soyuz> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/618395 >
[15:08] <bigjools> it's a general search issue
[15:08] <bigjools> using LIKE on a binarypackagename causes a seq scan :(
[15:09] <lifeless> orly?!
[15:09] <lifeless> :P
[15:09]  * bigjools 's sarcasm alarm goes off
[15:09] <lifeless> I'd be delighted to help
[15:10] <lifeless> I'm not going to pay much attention to work until a more reasonable time, but I'll drop my the laptop every 10-15 and check for pings
[15:10] <bigjools> lifeless: I'll probably ping you in a couple of hours then
[15:10] <lifeless> cool
[15:10] <bigjools> thx
[15:15] <bac> sinzui: you're still my manager according to canonicaladmin.  you mind signing my expense report for dallas?
[15:15] <sinzui> okay
[15:15] <bac> thx
[15:20] <sinzui> bac: I do not see the request.
[15:21] <bac> sinzui: doing it now.  i wanted to confirm you were ok with it before i entered
[15:22] <bigjools> sinzui: what bugs are your guys working on?  I am a one man band until Wednesday, where I become 2 and then 3 on Thursday.  We should co-ordinate a bit.
[15:23] <sinzui> bigjools: http://launchpad.leankitkanban.com/Boards/Show/14028609
[15:23] <jcsackett> bigjools: i think everyone on sinzui's team (all three of us) are just grabbing whichever critical grabs our eye.
[15:23] <bigjools> yeah that's what I was going to do :)
[15:23] <bigjools> makes it important that we set in-progress
[15:23]  * jcsackett nods. i agree.
[15:23] <sinzui> bigjools: I will take bug 700724 in an hour
[15:23] <_mup_> Bug #700724: Subscription policy inherited from parent team member <disclosure> <teams> <Launchpad itself:Triaged> < https://launchpad.net/bugs/700724 >
[15:24] <bigjools> sinzui: I think maybe we need a maintenance kanban board instead of 2 sqauds' ones.
[15:24] <sinzui> bigjools: since there are so many bugs in critical, it is not possible to know what jumps the queue. The bug I am taking is actually the most important bug to take next.
[15:25] <bigjools> sinzui: yeah we just need to whittle them down, it will be random until there's a sensible number of them left.
[15:27] <sinzui> bigjools: lifeless directed us to prefer bugs in the appearing in the current oops reports. I think we need to assign the bug when we get it ready-to-code so someone else does not duplicate the work
[15:27] <bac> sinzui: and there is another for ec2 expenses
[15:28] <bigjools> sinzui: the oops reports include everything - I presume you mean the top timeouts
[15:28] <bigjools> I agree anyway
[15:28] <sinzui> Looking at the critical bugs, I think some have not appeared in months or years.
[15:30] <bigjools> yes, I invalidated some
[15:32] <tiagoscd> which IDE do you recommend to develop in Launchpad?
[15:33] <bigjools> most of us use vim/emacs in a terminal
[15:34] <lifeless> sinzui: bigjools: any critical bug is a good one to do :); I agree about in-progress mattering. The ready-to-code angle - I tend to flesh out bugs in the description etc such that the knowledge is captured, perhaps that is sufficient?
[15:35] <bigjools> lifeless: yeah, I think writing the investigation details in the bug is critical
[15:35] <tiagoscd> hmm, nice
[15:36] <jcsackett> lifeless, bigjools: critical, and a good indication that someone else might be getting started (without setting in-progress). i know if i see notes from the last day or so from someone, i'm going to ask if they're working on it.
[15:36] <sinzui> lifeless: Not every engineer can read the conversation and come to the sam conclusion. The engineer needs to be familiar with the area of code
[15:45] <mars> interesting: http://initd.org/psycopg/articles/2011/01/24/psycopg2-porting-python-3-report/
 another of our dependencies now on python 3
[15:46] <lifeless> sinzui: thats true
[15:47] <lifeless> sinzui: otoh I think if it needs that much context, perhaps set it in-progress when you realise that even if the investigation isn't complete
[15:47] <lifeless> ?
[15:50] <sinzui> lifeless: I do that a lot.
[15:50] <lifeless> seems like we're in vigorous agreement ;)
[15:51] <lifeless> sinzui: a thought on the team membership thing
[15:51] <lifeless> sinzui: perhaps we need two separate knobs
[15:53] <lifeless> 'direct membership is restricted/moderated/open' and 'prevent teams which are members (directly or indirectly) from being open'
[15:54] <lifeless> with a note on the second one that this is required if assets with significant privileges are wanted
[15:54] <lifeless> sinzui: I've no idea if this is a jetlagged toenail smoking thing, or a good idea.
[15:55] <sinzui> lifeless: That sounds like feature development
[15:55] <sinzui> And I think that will be harder to convey to users
[15:58] <sinzui> Since we are supporting a handful of teams, I think we should look for an expedient solution. Add ing a nob to control permission probably requires reinventing team participation and inTeam()
[15:58] <lifeless> sinzui: The conveyance to users is the primary thing
[15:58] <lifeless> sinzui: in terms of size of development, it could go either way
[15:59] <lifeless> hmmm, and we don't want the cross product anyway
[15:59] <lifeless> so if we did use a separate knob we'd need to constrain the settings too
[16:00] <sinzui> I see a nob as extensive work to clean up a lot of cases. Adding an enum and setting a handful of team to use id nice because little code is needed to support the case
[16:00] <abentley> lifeless, it appears that the landing you rolled back was due to an unrelated intermittent failure.  I plan to land it again.  Cool?
[16:08] <abentley> abel, translation-fixing2 etc. depend on translation-fixing, but translation-fixing was rolled back, so don't land them until I've re-landed translation-fixing.
[16:09] <abentley> abel, I expect to re-land translation-fixing today.
[16:12] <jml> jelmer: which version of bzr-builder did you say you needed on the slaves?
[16:18] <jelmer> jml: trunk tip and a newer bzr
[16:19] <jml> jelmer: yikes.
[16:20] <jml> jelmer: so we need a release first, basically.
[16:20] <jml> jelmer: this is to get quilt3 support, right?
[16:21] <lifeless> abentley: cool
[16:22] <jelmer> jml: it's for two things
[16:22] <lifeless> abentley: it would be great if you could also file a critical bug about the intermittent failure
[16:22] <jelmer> jml: For quilt3 support you'd just need bzr-builder trunk
[16:22] <jelmer> jml: To fix most of the memory issues that the buildds are running into you need bzr-builder trunk and a newer bzr
[16:23] <jelmer> jml: Do you mean a release of bzr ?
[16:26] <jml> jelmer: I mean a release of bzr-builder.
[16:27]  * jelmer wasn't aware bzr-builder had releases :-)
[16:27] <jml> oh.
[16:27] <jml> interesting.
[16:27] <jml> it has releases
[16:27] <jml> 0.6, for example.
[16:28] <jelmer> jml: what is necessary in particular, a tarball?
[16:28] <jml> jelmer: I don't know. I was going to ask lamont once you told me what you needed :)
[16:28] <jelmer> heh, ok
[16:28] <jml> jelmer: but perhaps I can cut out the middle-man :)
[16:29] <abentley> lifeless, filed: https://bugs.launchpad.net/launchpad/+bug/706992
[16:29] <_mup_> Bug #706992: intermittant test failures: test_404 test_oldurl <Launchpad itself:Triaged> < https://launchpad.net/bugs/706992 >
[16:29] <lifeless> abentley: thank you
[16:31] <jml> jelmer: could you please file RTs for what you need and point lamont at them, CCing me?
[16:41] <bigjools> lifeless: hi
[16:43] <lifeless> hi
[16:43] <bigjools> lifeless: https://lp-oops.canonical.com/oops.py/?oopsid=1846A1401
[16:44] <bigjools> the top long query is the batchnav's count, but it's issuing it three times (one is coming from the view code which I can eliminate)
[16:44] <bigjools> wtf
[16:44] <jelmer> jml: ok
[16:46] <lifeless> mmm lp-oops is on a go-slow for me
[16:46] <lifeless> am in now
[16:46] <lifeless> just
[16:46] <bigjools> yeah it's very slow
[16:47] <lifeless> ok, so lets see
[16:48] <lifeless> 2.5 seconds doing an ilike count
[16:48] <lifeless> 1.9 getting the batch hits
[16:48] <bigjools> lifeless: repeated 4 times, 3 of which are from batchnav
[16:48] <lifeless> wth
[16:48] <bigjools> yes
[16:48] <bigjools> I've re-created it locally
[16:50] <lifeless> so, if its coming from batch navigator 4 times
[16:50] <lifeless> and the hits 3 times
[16:50] <bigjools> no
[16:50] <bigjools> one is from the view code
[16:50] <lifeless> ah
[16:51] <bigjools> I was going to make the template use batch/total instead of re-calculating it in the view
[16:51] <lifeless> hah
[16:51] <lifeless> so I don't know if you noticed
[16:51] <bigjools> but then I saw the three queries from the nav
[16:51] <lifeless> this is the query - '%%'
[16:51] <bigjools> yeah, blank
[16:51] <lifeless> postgres doesn't optimise that out
[16:51] <bigjools> \o/
[16:55] <jml> jelmer: thanks.
[16:55] <jml> isn't '%%' literal '%'?
[16:56] <bigjools> BinaryPackageName.name ILIKE '%' || '' || '%'
[16:57] <bigjools> the query is issued when it calls "return len(results)" at the bottom of _Batch._get_length()
[16:57] <bigjools> rather than the cached .listlength
[16:57] <bigjools> lifeless: ^
[16:58] <bigjools> which means the _Batch object is getting re-instantiated
[16:59] <lifeless> bigjools: thats a good thing to fix
[16:59] <lifeless> uhm
[16:59] <lifeless> perhaps a pdb statement in the constructor and get the backtrace for each instance locally?
[17:00] <bigjools> I have the backtrace alreayd
[17:00] <bigjools> LP_DEBUG_SQL_EXTRA ftw
[17:00] <lifeless> on staging
[17:00] <lifeless>  54249
[17:00] <lifeless> (1 row)
[17:00] <lifeless> Time: 7986.742 ms
[17:00] <lifeless> vs
[17:00] <lifeless>  54249
[17:00] <lifeless> (1 row)
[17:00] <lifeless> Time: 2156.876 ms
[17:00] <lifeless> removing the ftq and ilike when the query is for ''
[17:01] <bigjools> yes that's one thing to do but we can do better
[17:01] <lifeless> agreed
[17:01] <lifeless> I was just checking that the optimisation was significant, in case of my memory failing :)
[17:01] <bigjools> :)
[17:01] <lifeless> bigjools: so where is it being instantiated?
[17:01] <bigjools> I am looking right now
[17:01] <bigjools> somewhere in zope
[17:02] <bigjools> tell a lie
[17:04] <lifeless> I'm going to go cook some breakfast
[17:04] <lifeless> back with you soon
[17:05] <bigjools> ok
[17:05] <bigjools> this rabbit hole is very twisty
[17:10] <jml> g'night all. be around tomorrow.
[17:11]  * bigjools headdesks
[17:16] <lifeless> jml: night
[17:16] <lifeless> bigjools: ?
[17:16] <bigjools> lifeless: see lib/lp/soyuz/browser/packagesearch.py and tell me what's wrong with the batchnav property
[17:17] <bigjools> given that the template uses that property 3 times
[17:17] <lifeless> hmmm
[17:17] <lifeless> haven't opened it yet
[17:17] <lifeless> but I imagine not cached
[17:17] <bigjools> :)
[17:20] <lifeless> sounds like two easy fixes then
[17:32] <abentley> lifeless, fsvo "Tuesday".
[17:34] <lifeless> abentley: the joys of a spherical earth
[17:47] <lifeless> sinzui: are you familiar with defaultdict ?
[17:48] <sinzui> lifeless: to initialise a dict with a sensible value to make code easier to type and read?
[17:49] <lifeless> yes
[17:49] <sinzui> we do not use in in Lp very often
[17:49] <sinzui> We should
[17:51] <sinzui> lifeless: pause a moment if you have a message for me...just broke my keyboard or window manager
[17:51]  * sinzui hopes a reboot will fix this
[17:51]  * sinzui hopes someone see this
[17:52]  * beuno does not see that
[17:53] <leonardr> henninge or abentley, i'd like a review of https://code.launchpad.net/~leonardr/lazr.restful/publish_web_link/+merge/47280
[17:54] <henninge> leonardr: looking
[17:56] <lifeless> hmm
[17:56] <lifeless> flacoste: random idea; do we have a graph of open timeout bugs?
[17:56] <jcsackett> ooo. that would be nice.
[17:57] <bigjools> burndown?
[17:57] <lifeless> yeah
[17:57] <bigjools> did you look at lpstats?
[17:57] <lifeless> even without a trend line it would be a useful eyeball thing
[17:57] <lifeless> I was last week,
[17:57] <lifeless> IIRC there was a todo to set one up.
[17:58] <lifeless> nothing with 'timeout' in the graphs
[17:58] <lifeless> and the only oops ones are the frequency graphs like https://lpstats.canonical.com/graphs/OopsLpnetHourly/
[17:58] <lifeless> which seems borked
[17:59] <lifeless> ah, works on monthly
[18:18] <lifeless> sinzui: hi
[18:19] <lifeless> sinzui: is your machine happier ?
[18:19] <lifeless> bigjools: you might find the analysis in bug 706200 interesting
[18:19] <_mup_> Bug #706200: Archive:EntryResource:getPublishedBinaries timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/706200 >
[18:20] <jcsackett> leonardr: hi, have a sec to talk about webservice_error ?
[18:25] <salgado> lifeless, I'm getting http://paste.ubuntu.com/557770/ when running lp-propose.  have you seen anything like this before?  I've granted full access to bzr, btw
[18:25] <leonardr> jcsackett, sure
[18:26] <jcsackett> leonardr: i'm trying to get one exception to work across the webservice. in the past, i just add to add the webservice_error thing to it, and all was well.
[18:26] <jcsackett> i'm encountering a situation now where in tests it is still returning a 500 error code, rather than the appropriate webservice_error.
[18:26] <lifeless> NotFound: Object: <canonical.launchpad.systemhomes.WebServiceApplication object at 0x7b377d0>, name: u'1.0'
[18:26] <lifeless> salgado: ^ thats a little concerning :)
[18:27] <jcsackett> leonardr: relevant code bits for above: https://pastebin.canonical.com/42220/
[18:27] <jcsackett> i'm not sure if i'm missing something in my setup that i did in the past, or if there's some edge case thing cropping up here i'm unaware of.
[18:27] <lifeless> leonardr: ^ perhaps you could eyeball salgado's backtrace. As I read it we've managed to turn off the 1.0 API, but surely thats not correct.
[18:28] <lifeless> salgado: we get an OOPS
[18:30] <leonardr> salgado, lifeless: what's the host here? it's not edge, is it?
[18:30] <salgado> I don't know; just ran bzr lp-propose
[18:31] <leonardr> the stacktrace says it's production
[18:32] <leonardr> when i hit api.launchpad.net/1.0 in my browser i get some json
[18:33] <leonardr> salgado: please add import httplib2\nhttplib2.debuglevel = 1 to the beginning of the script you're running
[18:33] <leonardr> let's see what request it's making
[18:33] <bigjools> lifeless: totally not surprised, debversion_sort_key is horrendously slow
[18:34] <lifeless> bigjools: 2ms per call
[18:34] <lifeless> bigjools: but the killer is doing it on huge data sets
[18:34] <bigjools> exactly
[18:34] <bigjools> 2ms is not quick when you think about it
[18:34] <lifeless> :)
[18:35] <leonardr> jcsackett: look at a stacktrace to see where the CannotDeleteBranch is raised
[18:35] <lifeless> bigjools: bah, bad math. 0.5ms per
[18:35] <lifeless> still not brilliant
[18:35] <bigjools> compared to pulling data out of a column, no :)
[18:36] <salgado> leonardr, https://pastebin.canonical.com/42223/
[18:36] <salgado> authorizing now
[18:36] <lifeless> be better to let the thing be ordered directly from an index
[18:36] <bigjools> now, why is ec2 test telling me I don't have an ssh agent when I certainly do
[18:36] <lifeless> that way it wouldn't ned to materialise everything
[18:36] <sinzui> lifeless: Store.flush() did not, and still does not work...
[18:36] <jcsackett> leonardr: the stacktrace passed back when the 500 is raised in the test shows it's in the destroySelf method in the paste i sent you.
[18:36] <lifeless> sinzui: what are the symptoms
[18:36] <jcsackett> leoanrdr: i'm doublechecking again, but pretty sure that's what i saw.
[18:37] <leonardr> salgado: that's not the request that's failing. maybe there are two scripts running?
[18:37] <sinzui> lifeless: mailinglistset is not use Store.of(self), it is using getUtility(IStoreSelector).get(MAIN_STORE, SLAVE_FLAVOR)
[18:37] <salgado> leonardr, this is the one that fails: https://pastebin.canonical.com/42224/
[18:37] <leonardr> you also shouldn't be getting that request if you've already authorized the app
[18:37] <sinzui> I think we are not using the store we think we are
[18:37] <lifeless> sinzui: ah!
[18:37] <salgado> leonardr, looks like it's failing to get the authorization
[18:37] <leonardr> salgado: GET /beta/1.0/
[18:37] <leonardr> that's the problem
[18:37] <lifeless> sinzui: so I'm ok with doing a commit if we need to, but I don't understand why we'd need to
[18:38] <salgado> lifeless, ^
[18:38] <leonardr> probably there's some code somewhere that hardcodes /beta/ or http://api.launchpad.net/beta/
[18:38] <lifeless> salgado: thats pretty bong :>
[18:38] <sinzui> lifeless: I want to change the store to self because the ml object uses self. I do not think there is a legitimate readon to do what it dies
[18:38] <lifeless> salgado: time to file a bug
[18:38] <lifeless> sinzui: agreed
[18:38] <flacoste> lifeless: i have an open task for me to set that up
[18:38] <flacoste> lifeless: as well as one for OOPS and for regression
[18:38] <lifeless> flacoste: +4000 on doing it
[18:38] <sinzui> s/dies/does/
[18:39] <leonardr> jcsackett: can i see the whole stack trace?
[18:40] <jcsackett> leonardr: https://pastebin.canonical.com/42226/
[18:42] <jcsackett> so, i see breakreferences in there, but not sure why that would make the webservice_error magic break.
[18:44] <salgado> lifeless, bug 707075
[18:44] <_mup_> Bug #707075: lp-propose fails with a 404 error <Bazaar:New> < https://launchpad.net/bugs/707075 >
[18:45] <lifeless> sinzui: quick UI comment - https://launchpad.net/ubuntu/+source/linux - doesn't say what the big list at the top is
[18:46] <lifeless> sinzui: is there any reason we wouldn't explain whats there a little?
[18:51] <sinzui> lifeless: That is a pathological case. That *is* the description of what the source is
[18:51] <sinzui> lifeless: we are making the description from the binary package decriptions...just like packages.ubuntu.com
[18:51] <lifeless> perhaps a
[18:52] <lifeless> 'Package description:' header?
[18:52] <sinzui> I am not sure what to do heere
[18:52] <sinzui> We do not do there else where. We give the name then just show the description
[18:52] <lifeless> ok
[18:52] <lifeless> so I'll file a bug
[18:52] <lifeless> I don't know what to do either.
[18:53] <sinzui> I should not make an exception for this case. We need to think about how to make sane descriptions
[18:53] <lifeless> yes
[18:53] <lifeless> its not a description
[18:53] <lifeless> its a collection of binary package->description tuples
[18:53] <sinzui> This is too long an not informative
[18:53] <lifeless> descriptions require prose
[18:56] <lifeless> sinzui: bug 707081 FYI
[18:56] <_mup_> Bug #707081: source package homepage descriptions can be confusing <Launchpad itself:Triaged> < https://launchpad.net/bugs/707081 >
[18:57] <sinzui> yeah. this is not much better: http://packages.ubuntu.com/source/natty/linux
[18:57]  * sinzui wonders is software center offer something better
[19:01] <lifeless> sc works on binary packages
[19:02] <lifeless> one at a time, and only shows applications not plumbing
[19:02] <sinzui> I see the MailingList object use IMasterStore(<self|class>) in a few methods, but in other Lp examples, those calls are in static or class methods
[19:02] <lifeless> -> it has an easier domain
[19:04] <lifeless> bigjools: I'm very glad I bother to file that depwait bug :)
[19:04] <bigjools> lifeless: why?
[19:04] <bigjools> I would have seen the reports and checked :)
[19:05] <lifeless> ;)
[19:05] <jcsackett> leonardr: any thoughts re: my stacktrace on webservice_error stuff?
[19:11] <leonardr> jcsackett: i'm looking at it, i'll have to come back after lunch
[19:11] <jcsackett> leonardr: ah, dig.
[19:12] <jcsackett> thanks.
[19:22] <bac> hi sinzui
[19:23] <sinzui> hi bac
[19:23] <bac> sinzui: hey, in product-indext.pt there is a LP.use for lp.registry.pillar....which doesn't appear to exist
[19:24]  * sinzui looks
[19:24] <bac> sinzui: thanks
[19:24] <bac> sinzui: i'm trying to add new JS stuff to that template but would like to see it load cleanly before i pollute it
[19:25] <sinzui> OH!
[19:25] <sinzui> bac: yes, deryck's recent changes make that BAD code
[19:25] <bac> i'm unsure what is meant to be collapsible
[19:26] <sinzui> bac: huw fixed the license widget by updating a similar line
[19:27] <sinzui> bac: huwshimi changed LPS.use to YUI().use which creates a separate instance. We do not always want to create a new instance though
[19:29] <sinzui> jcsackett: where did you register lp.registry.pillar
[19:30] <bac> sinzui: the string 'lp.registry.pillar' exists nowhere else in the code base but that template.
[19:31] <sinzui> bac: I understand that. I did not write it. I think jcsackett did
[19:31] <bac> ok
[19:31] <jcsackett> sinzui, bac: i think you can safely move that. it predates when all the consolidation happened and was cargo culted.
[19:36] <bac> jcsackett, sinzui: that JS is bad but doesn't seem to be doing any harm.  can it wait to land with the branch i'm working on...which may be a while?
[19:36] <bac> "it" is the removal of the lp.registry.pillar stuff
[19:37] <jcsackett> bac, sinzui: when did that JS become bad?
[19:37] <jcsackett> the collapsible bit that i created (seemingly ages ago) seems to work when i'm looking at it.
[19:37] <bac> jcsackett: it is bad b/c lp.registry.pillar does not exist.
[19:37] <bac> jcsackett:  load launchpad.dev/firefox in a browser and look at the error console
[19:38] <bac> jcsackett: what is supposed to be collapsing?
[19:39] <jcsackett> bac: there's a collapsible on the configuration links for projects you can set usage enums on.
[19:40] <jcsackett> so that once you've configured everything, they default to hidden.
[19:40]  * jcsackett is looking for relevant bug.
[19:42] <bac> jcsackett: ok, i wasn't logged in so i didn't see that part and had forgotten about it
[19:43] <bac> jcsackett: but, the collapsible stuff from lp.registry.pillar does not exist and thus has no bearing
[19:43] <jcsackett> bac: dig. so yes, i remember adding that in the JS, but it got whacked at some point. my $.20 is that it can wait till you land this branch.
[19:43] <bac> your twenty cents, huh?  had best listen!
[19:44]  * jcsackett laughs.
[19:44] <jcsackett> bit of a typo there, yes. :-P
[19:44] <bac> when dumb stores advertice 0.50￠ can you hold them to it?
[19:46] <jcsackett> probably not. :-p
[19:46] <jcsackett> if only because they ultimately control the transaction, and tell you go to get bent.
[19:49] <jcsackett> henninge, abentley (or anyone else) can i get a look at https://code.launchpad.net/~jcsackett/launchpad/i-hate-storm-base-storm-705197/+merge/47269?
[19:50] <abentley> jcsackett, sure, looking.
[19:50] <jcsackett> abentley: thanks.
[19:51] <abentley> jcsackett, does your lint header mean there was no lint?
[19:52] <jcsackett> abentley: no, it means i apparently didn't save after adding lint. one sec.
[19:55] <jcsackett> abentley: mp updated.
[19:55] <abentley> jcsackett, thanks.
[19:56] <abentley> jcsackett, r=me.
[19:56] <jcsackett> abentley: thanks.
[20:05] <james_w> the help for lp.net/launchpad's +filebug should probably be updated
[20:05] <james_w> it talks about other projects
[20:06] <deryck> james_w, wiki help page?
[20:07] <deryck> or bug reporting guidelines?
[20:07] <james_w> the latter
[20:07] <james_w> "This is the main Launchpad bug queue, if you don't know which component of Launchpad you found the bug, this is the right place to file it."
[20:07] <deryck> ah, right
[20:08] <james_w> I guess it's still somewhat true with lazr.* etc.
[20:08] <deryck> gary_poster, I think you tried to do this ^^ and couldn't.  and I was going to use you as my test that it wouldn't OOPS now. :-)
[20:08] <deryck> gary_poster, re: updating bug reporting guidelines
[20:08] <gary_poster> deryck: right! ok, I'll try
[20:09] <deryck> gary_poster, thanks1
[20:09] <henninge> leonardr: done. Sorry for the delay.
[20:09] <leonardr> henninge: thanks
[20:11] <gary_poster> deryck: success.  I didn't receive a confirmation notification of the change--it just redirected me to the main project bug page--but it worked.  So, QA OK as far as that bug is concerned. :-)
[20:11] <deryck> gary_poster, excellent.  thanks.
[20:12] <gary_poster> james_w: Now, "This is the Launchpad bug queue. Please include the exact URL of a page where you had the problem..."  Thank you for reminding us
[20:13] <james_w> np
[20:14] <bigjools> gary_poster: do you know if I need to do anything special to generate an OOPS when logging an error in a test?
[20:14] <abentley> henninge, you are still OCR?
[20:14] <leonardr> jcsackett: is this existing code that stopped working, or new code?
[20:15] <jcsackett> leonardr: the addition of webservice and the tests are new.
[20:15] <henninge> abentley: yes, or did we already chaange it?
[20:15] <leonardr> jcsackett: can you point me to some place in launchpad where you do something similar but it works?
[20:15] <henninge> abentley: I am west of you this and next week, remember?
[20:15] <gary_poster> bigjools: the error reporting utility needs to be alerted of the error somehow.  The Zope publisher usually is responsible for this.  If you are outside of the publishing loop, you need to get the utility and call...whatever the method is.  We have a subclass in the tree you can look at; I'll help dig it up if you like.
[20:15] <abentley> henninge, no, I forgot.
[20:16] <jcsackett> leonardr: as far as exporting an error by using webservice_error? yeah, one sec.
[20:16] <henninge> np ;)
[20:16] <abentley> bac, ping
[20:16] <bigjools> gary_poster: I thought the logger did all that?
[20:16] <bac> hi abentley
[20:16] <bigjools> this is in a script, sorry if that wasn't clear
[20:16] <gary_poster> bigjools: what logger?  The Python logger?  If so, no.
[20:17] <abentley> henninge and I are OCR on Monday, and we are now in the same squad.  We'd like to change schedules so that we aren't OCR on the same day.
[20:17] <gary_poster> I think the error reporting utility is responsible for the log, IIRC
[20:17] <bac> abentley: ok.  let me look at the schedule
[20:17] <gary_poster> errors in the log, that is
[20:17] <bigjools> yeah, the python logger.  I am testing for a new oops after using logger.error() and there isn't one.
[20:17] <gary_poster> nope
[20:18] <gary_poster> won't work
[20:18] <gary_poster> you need to tickle the error reporting utility
[20:18] <bigjools> where does it like to be tickled?
[20:18] <bac> abentley: would you like to move to wednesday?
[20:18] <bigjools> I don't want to make it wee
[20:18] <abentley> bac, sure.
[20:18] <gary_poster> lol
[20:19] <bigjools> or point me at an example :)
[20:19] <abentley> bac, starting next week?
[20:19] <bac> abentley: ok, i'll move you as i've got the wiki page open
[20:19] <bac> abentley: sure
[20:19] <gary_poster> bigjools: bzr grep IErrorReportingUtility shows you some usages...lib/canonical/launchpad/webapp/errorlog.py has our subclass ... still looking about
[20:19] <abentley> bac, thanks!
[20:20] <henninge> bac, abentley: thanks
[20:20] <gary_poster> bigjools: .raising, looks like
[20:20] <gary_poster> def raising(self, info, request=None, now=None):
[20:20] <leonardr> jcsackett: i think there might be a bug such that the normal error view lookup doesn't happen on a DELETE request
[20:20] <lifeless> gary_poster: how do you feel about including a 'and if you saw an OOPS please include the OOPS number' in those guidelines?
[20:21] <gary_poster> where info is output of sys.exc_info()
[20:21] <gary_poster> humina?
[20:21] <gary_poster> (==nonsense syllable)
[20:21] <gary_poster> which guidelines?
[20:21] <lifeless> gary_poster: stub added logging->oops glue
[20:21] <bigjools> gary_poster: I'm confused - I thought the logger auto-oopsed on level > info
[20:21] <lifeless> it does
[20:21] <lifeless> in scripts
[20:21] <bigjools> but not in tests?
[20:22] <gary_poster> I was not aware he did it that way
[20:22] <lifeless> a test per se doesn't know if its a) a script or b) for the webapp
[20:22] <gary_poster> cool
[20:22] <bigjools> ok - meh
[20:22] <gary_poster> bigjools: the webapp still does stuff the way I said, I expect
[20:22] <bigjools> right, makes sense
[20:22] <lifeless> gary_poster: see %(asctime)s %(levelname)-7s %(message)s'
[20:22] <lifeless> ./lib/canonical/launchpad/scripts/logger.py
[20:22] <gary_poster> lifeless: oh! I got your original question now
[20:22] <lifeless> bah, the second line :)
[20:23] <gary_poster> yeah, good idea to ask for an oops
[20:23] <jcsackett> leonardr: so that prevents the webservice_error stuff from happening? b/c the code path raising the exception is clearly happening.
[20:23] <gary_poster> I'll add it
[20:23] <bigjools> lifeless: in that case, do you have any suggestions on how to test this change to not crash but to log and oops?
[20:23] <lifeless> bigjools: sure, is the code a) script only, b) both, c) webapp
[20:23] <jcsackett> leonardr: an example of this working is with the JoinNotAllowed error in lp.registry.errors, tested in lp.registry.tests.test_team_webservice.
[20:23] <lifeless> I've sligtly different suggestions for each
[20:23] <jcsackett> i can throw together a paste, if you like.
[20:23] <bigjools> lifeless: there's a unit test for the method that's used in the script
[20:23] <leonardr> jcsackett: look in lazr.restful src/lazr/restful/_resource.py, ReadWriteResource.__call__
[20:24] <gary_poster> lifeless: it is already there: "If the bug you found generated an OOPS id, please include it here as well."
[20:24] <leonardr> that's the code that catches exceptions
[20:24] <leonardr> that's the code that should be running
[20:24] <jcsackett> leonardr: looking now.
[20:24] <lifeless> gary_poster: sweet
[20:24] <bigjools> lifeless: this is the change so far but the test isn't working http://pastebin.ubuntu.com/557822/
[20:24] <lifeless> gary_poster: I was going off th econversation here only
[20:24] <leonardr> i suggest you put a breakpoint in that 'except' clause and see how it's being handled
[20:24] <gary_poster> understood, np
[20:25] <lifeless> bigjools: I would be inclined to:
[20:25] <lifeless>  - put the logging call at the point where we loop
[20:26] <lifeless>  - change the AssertionError to a custom exception (eg. UnparsableDependencies)
[20:26] <bigjools> did you not look at the diff? :)(
[20:26] <lifeless> bigjools: the test then can be direct (doesn't care about oopses), and the loop should be in the script specific code which has a test helper that wires it all up
[20:26] <bigjools> but go on
[20:26] <lifeless> bigjools: I am looking at it
[20:26] <lifeless> bigjools: perhaps I'm confused
[20:27] <bigjools> I really, really hate this auto-oops logging thing
[20:28] <lifeless> bigjools: clearly I'm confused
[20:29] <bigjools> lifeless: I don't really understand what you mean about script-specific code.  This is a very straightforward unit test.  Sure, we can test that it throws a custom exception but that doesn't test that we've logged an oops.  I suspect that I need to Popen the script, which is nasty.
[20:29] <lifeless> bigjools: you don't
[20:29] <lifeless> hang a sec and I'll dig up the test infrastructure
[20:30] <bigjools> ok, thanks
[20:30] <lifeless> what I mean by script specific code is this:
[20:30] <lifeless>  - code in the webapp can assume some stuff, like transactions-around-requests, auto-oops creation etc
[20:30] <lifeless>  - code in scripts cannot assume that stuff - it doesn't have a proper request context, so everything related to that (including the webapp adapter) becomes tricky
[20:31] <bigjools> ok. this, I know. :)
[20:32] <lifeless> so code that is shared between them needs to communicate (probably via exceptions) up to a layer which is script only
[20:32] <lifeless> otherwise we'll log to the log file and *not* generate an OOPS in the webapp
[20:32] <bigjools> this method is only ever called from a script
[20:32] <lifeless> I've looked a bit now and it looks to me like retryDepWaiting is script specific
[20:33] <lifeless> one sec ELOCAL
[20:33] <bigjools> updateDependencies you mean
[20:33]  * bigjools also brb, biological emergency
[20:36] <lifeless> bigjools: no, I mean retryDepWaiting
[20:36] <lifeless> which calls updateDependencies
[20:36] <bigjools> ok
[20:37] <lifeless> however
[20:37] <lifeless> both appear script only
[20:37] <lifeless> so - its a huge shrug and whatever looks cleanest to you
[20:37] <lifeless> anyhow
[20:37] <lifeless> lets answer your question
[20:38] <lifeless> rev 11637 added the feature
[20:41] <lifeless> bigjools: ok, so anything that calls (in process) LaunchpadScript as a whole thing will add an OopsHandler to logging on the fly
[20:41] <lifeless> bigjools: I can see two options
[20:42] <lifeless> bigjools: just check for an error level log message
[20:42] <lifeless> bigjools: or install OopsHandler manually and then check for an oops
[20:43] <lifeless> bigjools: personally, if I was making the change, I'd change the raised exception and catch it in retryDepWaiting:
[20:43] <lifeless> try:
[20:43] <lifeless>     build.updateDependencies()
[20:43] <lifeless> except <.>:
[20:43] <lifeless>     continue
[20:44] <lifeless> bigjools: just looking at it it seems tricky to actually skip it otherwise
[20:44] <bigjools> yeha
[20:47] <jcsackett> sinzui: did we decide 5 or 5:30 EST for group mumble?
[20:49] <sinzui> jcsackett: 5:30 EST
[20:49] <jcsackett> cool. thanks.
[20:53] <poolie> hi jc, sinzui
[20:54] <sinzui> a stealth greeting
[20:54] <sinzui> hi poolie
[20:57] <lifeless> sinzui: hey, disabled users 404 right ?
[20:58] <lifeless> so bug 283830 is perhaps obsolete ?
[20:58] <_mup_> Bug #283830: Don't allow crawlers to index the top-level user pages on lp subdomains if the user is deactivated <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/283830 >
[20:58] <poolie> hi lifeless
[20:58] <lifeless> hi poolie
[20:58] <sinzui> lifeless: It is still legit
[20:58] <poolie> lifeless, i tried out a twisted client along the lines of my rfc, and i liked it
[20:59]  * sinzui saw that some pages are still being indexed
[20:59] <lifeless> flacoste: should we make official bugtags for all LEP's ?
[20:59] <lifeless> flacoste: e.g. issuetracker
[21:00] <flacoste> lifeless: in the sense of making the existing bug tags official?
[21:00] <lifeless> flacoste: yeah, so they autocomplete.
[21:00] <lifeless> flacoste: only 'official' bug tags autocomplete
[21:00] <flacoste> lifeless: i think it's a good idea
[21:01] <poolie> hi flacoste
[21:01] <flacoste> hi poolie
[21:01] <poolie> i think we normally catch up in 90m,; i'm ready whenever you are
[21:02] <flacoste> poolie: i thought we were skipping this week, as i didn't thought you'd be around
[21:02] <flacoste> poolie: but i could do a call in 60 minutes
[21:02] <poolie> just a brief call could be good
[21:03] <flacoste> poolie: i have to watch over the babies while Amelie picks up Jules in 30 minutes, it's -21C over here, so she's not getting them out
[21:04] <poolie> wow
[21:04] <flacoste> and that's after the sun warmed things up
[21:05] <flacoste> it was -27C this morning
[21:05] <flacoste> been years since it wasn't so cold
[21:05] <flacoste> we usually never cross -23
[21:05] <flacoste> and that's real temperature
[21:05] <thumper> high of 23C here today
[21:05] <flacoste> not inflated with wind factor and such bs
[21:06] <flacoste> thumper: want to trade place?
[21:06] <thumper> flacoste: nope
[21:06] <lifeless> flacoste: I need to take Lynne to the hospital today; I think we're all caught up though. So perhaps we skip today?
[21:06] <poolie> 35C here yesterday when i was walking around
[21:06] <flacoste> lifeless: yep, that was the plan
[21:06] <poolie> felt weird after last week
[21:13] <poolie> are recipes still in beta? https://help.launchpad.net/Packaging/SourceBuilds/GettingStarted says they are
[21:13] <poolie> s//closed beta
[21:14] <lifeless> yes
[21:15] <lifeless> erm
[21:15] <lifeless> I don't think it was ever /closed/
[21:15] <lifeless> its a beta and folk can participate
[21:16] <poolie> but you don't need to be in a special team?
[21:16] <poolie> then i'll edit it
[21:16] <lifeless> you do have to be in the special team
[21:16] <lifeless> thats how you participate
[21:17] <poolie> ah, but it's an open team
[21:18] <lifeless> and the main beta team is in it
[21:30] <thumper> StevenK: https://bugs.launchpad.net/launchpad/+bug/683798
[21:30] <_mup_> Bug #683798: Recipes for merged team still showing up in +recipes page <404> <lp-code> <recipe> <Launchpad itself:Triaged> < https://launchpad.net/bugs/683798 >
[21:33] <thumper> StevenK: mumble is being crackful
[21:35] <thumper> StevenK: https://bugs.launchpad.net/launchpad/+bug/669288
[21:35] <_mup_> Bug #669288: person merge code needs to handle colliding recipes <lp-code> <recipe> <Launchpad itself:Triaged> < https://launchpad.net/bugs/669288 >
[21:36] <StevenK> thumper: Oh, awesome
[21:36] <StevenK> thumper: And yes
[21:36] <thumper> StevenK: you get to kill two bugs with one branch
[21:36] <StevenK> Right
[21:36] <thumper> StevenK: I've left mumble
[21:37] <thumper> nothing as frustrating as not being able to hear properly
[22:16] <wgrant> Morning.
[22:17] <Ursinha> wgrant, morning
[22:18] <jml> huwshimi: https://bugs.launchpad.net/launchpad/+bug/325982
[22:18] <_mup_> Bug #325982: Search URL is long and hard to paste <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/325982 >
[22:20] <wallyworld> morning
[22:21] <wgrant> Morning wallyworld.
[22:21] <wgrant> You got home OK?
[22:22] <wallyworld> wgrant: yeah, to find a 10000 jobs waiting for me to to, like mowing the lawn etc.
[22:22] <wgrant> Heh.
[22:22] <wallyworld> wgrant: i missed the shared shuttle cause there was a shooting on the DART and the train was delayed
[22:22] <wallyworld> there were cops everywhere
[22:23] <wallyworld> not on mt train but further up the line or so i was told
[22:24] <wgrant> wallyworld: Ah, you were out somewhere on the DART?
[22:25] <wallyworld> wgrant: went with stub and jtv to a Fry's to see if there were any Kindles for jtv. rather large but uninspiring store. prices no better than here
[22:25] <wgrant> Ahh :(
[22:25] <wallyworld> there were about 6 different Ubuntu books on the shelf though :-)
[22:25] <wallyworld> we got photos :-)
[22:29] <sinzui> wgrant: mumble in Launchpad/Green
[22:30] <wgrant> sinzui: Give me a sec.
[23:03] <wallyworld> thumper: ping
[23:03] <thumper> wallyworld: hi
[23:04] <wallyworld> can you give me a clue as to what broke that required the show related branches rollback?
[23:04] <thumper> wallyworld: yeah, but I'm starving
[23:04] <thumper> wasting away to nothing
[23:04]  * thumper needs food badly
[23:04] <wallyworld> :-)
[23:05] <thumper> wallyworld: skype or mumble?
[23:05] <wallyworld> ping me when you're fat again
[23:05] <wallyworld> thumper: mumble when you have eaten
[23:05] <thumper> wallyworld: lets do it now
[23:05] <wallyworld> thumper: ok
[23:17] <lifeless> back
[23:33] <wgrant> maxb: Hi.