#launchpad-dev 2009-09-21
<thumper> mwhudson: bzr builder is offline, so not running at all
<mwhudson> thumper: not surprised
<mwhudson> thumper: it's a bit borked at the moment anyway because of api versioning issues :/
<thumper> yeah
<wgrant> What does PQM's closure mean? Only RC submissions are accepted?
<mwhudson> wgrant: yes
<mwhudson> we should start a sweepstake on how many of those there will be for this release
<spm> mwhudson: entries < 15, will be ignored
<mwhudson> spm: after a fit of laughter?
<spm> mwhudson: I didn't feel it politic or diplomatic to go so far as to state *that*. But. Well. Yes. ;-)
 * wgrant thinks that bug #244145 is lying.
<mup> Bug #244145: process-death-row script chokes on rebuild archives <derivation> <Soyuz:Triaged by al-maisan> <https://launchpad.net/bugs/244145>
<wgrant> process-death-row doesn't actually fail because of that in production, does it?
<ajmitch> mwhudson: are you suggesting that there are still a few bugs to be fixed?
<mwhudson> ajmitch: there are always bugs to fix, i hope we're not going to try to run out before thursday :)
<wgrant> ajmitch: Never. 3.0 is perfect already. Or something.
<ajmitch> wgrant: great to hear
 * mwhudson afk for lunch & errands
<poolie> https://help.launchpad.net/API/launchpadlib claims you must be in the beta team to use apis
<poolie> is that really still true?
<wgrant> poolie: No.
<wgrant> poolie: There was a discussion on the ML about it this morning.
<poolie> so i'll just take it out..?
<wgrant> poolie: If you are so privileged.
<poolie> not really, i just have a sense of entitlement ;-)
<wgrant> It's a question of whether Moin thinks you are appropriately privileged.
<wgrant> Most are not.
<poolie> wgrant: really, which ml? i can't see it in my mail
<poolie> and i thought i at least received all the lp mail
<poolie> though not the reviews
<wgrant> poolie: A launchpad-dev email from 3:07 AEST today.
<wgrant> "[Launchpad-dev] https://dev.launchpad.net/API "Authenticated Access Only" needs rationale"
<poolie> oh, sorry
<poolie> mismatched replies, i thought you were talking about the restriction to beta team members
<wgrant> I was. My memory was just fault and conflated the two issues.
<wgrant> ... +y
<wgrant> So there was no discussion. Sorry.
<wgrant> However, the production configs from July confirm that there was no restriction in place.
<wgrant> And as it's now available on lpnet too, I doubt it's restricted there either.
<poolie> surely you should have access to that wiki page?
<wgrant> Ah, /API/launchpadlib isn't restricted, just /API.
<poolie> ok, thanks
<poolie> wgrant: so are you (wgrant) really not allowed to update this page?
<wgrant> poolie: I cannot edit /API.
<wgrant> #acl AdminGroup:read,write All:read
<poolie> that seems wrong to me, probably unintentionally
<poolie> but i guess we should ask karl or mrevell
 * thumper wants cake
<thumper> spm: when is the edge rollout?
<thumper> spm: and when is the staging rollout?
<thumper> :(
<thumper> ...
 * thumper thinks
 * thumper takes it to the mailing list
<spm> thumper: edge, in about 1.5 hours, or on request :-)
<spm> thumper: staging restores were borked over the w/e, but one is currently underway as we speak
<thumper> spm: thanks
 * mwhudson eods
<spm> night mwhudson
<stub> spm: This staging restore will fail too since it will be using an older backup - its needs a backup made after my fix to the production data (made about an hour ago).
<spm> bugger
<spm> poolie: you've mentioned better LP is down posting type stuff before. is this kinda - as a generic framework/idea - what you had in mind? http://advisories.internode.on.net/item/6562/
<poolie> spm, well, that would be nice, but i was thinking of something cheaper to start with
<poolie> spm, what I suggest we do today, if lp is down at the moment, is just tweet it
<spm> as well as tag the IRC topics in the obvious places - which is what we currently do, perhaps not as perfectly as we'd like...
<wgrant> The current IRC notifications are pretty good. I think the biggest problem ATM is getting *SAs to notice issues.
<lifeless> and the first 3 blog posts are  AWOL
<wgrant> lifeless: They're not normally published until release.
<wgrant> Although the fourth blog post's text is borked.
<spm> wgrant: what do you mean: getting *sas to notice issues? that could be takena  few ways, and it's unclear which you mean.
<wgrant> spm: Often issues (particularly one or two hung appservers) will persist for a couple of hours before somebody sufficiently empowered notices.
<spm> stub: seeing as the staging restore is going to fail; are there any issues with simply pulling a kill -9 ( >:) ) on pg_restore and friends?
<spm> wgrant: it's been my experience that we'll know about a hung app server within 5-10 minutes (which is still too slow granted...); it's only a longer period when it happens outside core hours. ?
<wgrant> spm: Yes. Weekend, mainly.
<wgrant> +s
<wgrant> SA TZ coverage is otherwise pretty good nowadays.
<spm> heh. it'd want to be; barring illness/hols etc. we now have LOSA 24x5.mumble-somthing coverage
<wgrant> Really?
<spm> monday morning to sat morning - AEST time; yah.
<wgrant> Hmm.
<wgrant> I thought there was an AU->US hole.
<spm> not as of last week
<spm> which is why you may have notcied I start later, and finish later :-)
<wgrant> Ah.
<wgrant> But weekends can still go disastrously.
<spm> Murphys law. they always will.
<spm> the hung app server woe is being tackled on two fronts
<wgrant> Of course, things will always go wrong. But they shouldn't stay wrong for soooo looong.
<spm> 1. the relevant bug(s) are being fixed
<spm> 2. better LB in front of same to take busted systems out of rotation. atm the "dumb" LB sees a responsive port 80; it doesn't know that the server behind same has gone to gaga land
<wgrant> Yes. Hate hate hate Pound.
<lifeless> 'squid' :P
<lifeless> yahoo use squid and some other one for this
<lifeless> depending on what group
 * spm ignores the accurate interjection from the gallery... ;-)
<wgrant> It would be really nice if placeholder projects were editable by everybody or at least some team larger than ~admins.
<spm> my 2c, vaguely disinterested observer opinion on that issue? It's changing to allow that, slowly.
<spm> actually - not that vaguely disinterested, cuase it'd be one less taks thrown at us to do minor changes/edits for....
<stub> Anyone recall where requests for launchpad-developer-dependencies modifications get filed?
<stub> spm: You can kill 'em.
<spm> sweet, ta.
<henninge> Morning!
<noodles775> mwhudson: I've got an approved branch here ready to land that updates two blueprint pages to 3.0 - is pqm still open?
<noodles775> mwhudson: I'd just submit it, but I remember someone mentioning once that we shouldn't even if it's open after the deadline?
<noodles775> Morning henninge
<henninge> Hey noodles775!
<mwhudson> noodles775: no
<mwhudson> (it's not open)
<mwhudson> afaik
<noodles775> ok, thanks mwhudson
<henninge> noodles775: I could imagine that you'd get r-c quite easily for changes like that ...
<henninge> or not?
<spm> hey henninge, noodles775
<noodles775> Hi spm :)
<henninge> Hi spm!
<henninge> Oh, still a lot of unconverted blueprint pages ...
<noodles775> henninge: yes, I'd assume so. BjornT ? Do you know whether rc's are being granted for blueprint conversions?
<noodles775> https://code.edge.launchpad.net/~michael.nelson/launchpad/sprint-index-and-attend-3.0/+merge/12044
<henninge> noodles775: what is that wiki page for blueprint work?
<noodles775> henninge: https://dev.launchpad.net/VersionThreeDotO/BlueprintsConversion
<henninge> cheers
<BjornT> noodles775: no, i don't know, but i'd also assume so.
<henninge> Do I need to add "release-critical" to testfixes, too?
<stub> henninge: Instead of having UTF-8 doctests, you might want to use u'somestring'.encode('doctest') which gives an ascii readable representation
<stub> >>> print u'hello\N{TRADE MARK SIGN}'.encode('doctest')
<stub> hello\N{TRADE MARK SIGN}
<henninge> stub: thanks!
<beuno> henninge, hi
<beuno> re: bug 433824
<mup> Bug #433824: Top featured project selection on Launchpad home page <Launchpad Foundations:New> <https://launchpad.net/bugs/433824>
<beuno> project of the day I think is great
<henninge> beuno: Hi!
<henninge> beuno: Cool, I will implement that today, then.
<thumper> beuno: hi, you in London?
<henninge> stub, jml: the test is passing for me locally ...
<henninge> ?
<henninge> without a fix, I mean
<beuno> thumper, hi
<beuno> yes
<beuno> henninge, awesome
<beuno> thanks for picking that up
<henninge> stub, jml: mwhudson already fixed that, forgot to check first ...
<henninge> beuno: I was actually wondering about it when doing the page but forgot ...
<henninge> beuno: you are aware that the home page has landed?
<beuno> henninge, I am!
<beuno> I spy on progress daily
<henninge> ;-)
<beuno> I'm back to work today
<henninge> cool
<mrevell> Morning
<mrevell> jml: blimey, didn't think you'd be online
<wgrant> Why does the new project bugs page show the bugtask ID?
<intellectronica> wgrant: stupid mistake on my part. fix already reviewed, i hope i'll get to merge it as release-critical, since it's pretty awful
<intellectronica> https://bugs.edge.launchpad.net/malone/+bug/433857
<mup> Bug #433857: Summary in bugs homepage hot bug lists uses the wrong field <ui> <Launchpad Bugs:In Progress by intellectronica> <https://launchpad.net/bugs/433857>
<deryck> Morning, all.
<intellectronica> hi deryck
<wgrant> intellectronica: Ah, great.
<wgrant> Also, why are the columns in the bugtask index's table all the same width? Status/Importance are unnecessarily wide, and cause target names to wrap for me on eg. https://bugs.edge.launchpad.net/launchpad-foundations/+bug/401043
<mup> Bug #401043: speed up deployment of changelogs <Launchpad Foundations:Invalid> <Soyuz:Invalid> <Ubuntu:Confirmed for mvo> <https://launchpad.net/bugs/401043>
<allenap> BjornT: You've been doing some windmill stuff recently. Do you know if this is related to your changes? http://paste.ubuntu.com/275155/
<wgrant> allenap: Bug 432665
<mup> Bug #432665: 'make iharness' is broken <Launchpad Foundations:New> <https://launchpad.net/bugs/432665>
<allenap> wgrant: Top, thanks :)
<intellectronica> wgrant: because if you let them be variable width the table changes when you edit a field inline and that's a bit weird
<BjornT> allenap: well, i added the import. but it looks like 'make iharness' doesn't set up the right python path
<allenap> BjornT: Ah, okay, probably a buildout thing then.
<wgrant> intellectronica: Well, yes, but they're currently like twice the width they need to be for me.
<intellectronica> wgrant: yeah, i guess you're right, we can keep the width fixed per column but give them different proportions
<intellectronica> wgrant: care to file a bug?
<wgrant> intellectronica: Doing so.
<intellectronica> lovely, thanks
<BjornT> allenap: yeah. for now, 'make harness' seems to work at least.
<allenap> BjornT: Okay, thanks.
<wgrant> Is there a good reason for the 'download' class on the attachment <li>s? It causes sprite issues, and everything seems OK if I drop it.
<wgrant> cprov: Thanks for fixing the copy archive OOPS. I would have, but I was hoping there would be a more elegant way to do it (ie. some way of expressing conjunction in TALES).
<cprov> wgrant: there isn't, we could create a view property but it isn't any clearer than using TALES
<wgrant> cprov: There's another related OOPS that I can't reproduce locally, and didn't get a number for. Is it easy to look it up given a URL and time?
<cprov> wgrant: I'm not sure, but I can try
<wgrant> cprov: It was a POST by cjwatson to https://api.edge.launchpad.net/beta/ubuntu/+archive/test-rebuild-20090909 at around 0740UTC on the 19th.
<wgrant> (it was a newComponentUploader API request to give us privileges to retry builds in the test rebuild)
<bigjools> morning cprov
<cprov> bigjools: morning
<bigjools> just the man, I was going to ask you about that CP to fix the "email already in use" errors, since wgrant was seeing some related errors still
<wgrant> bigjools: It wasn't I that brought it up, but yes, they are still around.
<cprov> wgrant: was the fix for newComponentUploader() API in edge by that time ?
<wgrant> I think it should have been rolled out a night or two before. But that should have been an Unauthorized, shouldn't it? Plus cjwatson is in ~techboard, so should have had permission anyway.
<cprov> wgrant: yes, that's right
<cprov> wgrant: I could not find any oops for the rebuild archive on 19th and 20th reports
<wgrant> cprov: Hmm. http://pastebin.ubuntu.com/275170/
<cprov> wgrant: just a case of trying again, I guess ... make sure you pass 'main' component and catch launchpadlib.errors.HTTPError (print exc.content)
<wgrant> cprov: I guess so.
<cprov> wgrant: the other components ought to be the problem
<wgrant> cprov: Really? I was able to add permissions for all components on a rebuild archive locally without trouble.
* bac changed the topic of #launchpad-dev to:  This is Launchpad Development Channel | Week 4 of 3.0 | PQM is closed - Release manager is bac - contact for release-critical | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | 3.0 goal is to convert all templates: http://people.canonical.com/~beuno/conversions.html
<cprov> wgrant: nah, it's a COPY
<wgrant> intellectronica: lp:~intellectronica/launchpad/hot-bugs-summary appears to contain a fix for the summary, but it still uses bugtask/id rather than bugtask/bug/id. Is that the branch you were talking about?
<intellectronica> wgrant: oh, thanks for pointing that out. yes, that was the branch i was talking about
<wgrant> cprov: Well, newComponentUploader works fine now. How odd.
<wgrant> cprov: What's the purpose of the restriction of copy archive retries to the owner? Why shouldn't people mentioned in ArchivePermissions be able to?
<wgrant> In fact, it seems like the PPA/COPY special case could just be eliminated without any change in behaviour except respecting ArchivePermissions.
<cprov> wgrant: PPA and COPY archive permissions don't necessarily match the 'ubuntu' way of doing things
<wgrant> cprov: But if there are explicit ArchivePermissions, it seems like they should be obeyed...
<cprov> wgrant: yes, we could tie build-retry to upload rights
<cprov> wgrant: but before exploring more APs in PPA and COPY we need an UI, otherwise it will be very confusing to use it.
<wgrant> cprov: Perhaps, but by removing four lines from c.l.security, we immediately get much more functional rebuild archives.
<cprov> wgrant: which 4 lines ?
<wgrant> cprov: The is_ppa/is_copy special case in EditBuildRecord.checkAuthenticated. The PPA case is already properly handled by Archive.canUpload.
<wgrant> I presume there's a reason it's special-cased, but I cannot see one.
<cprov> wgrant: there is no *reason*, it was done like that just for safety, I guess
<cprov> wgrant: restrictive is safer than permissive.
<wgrant> cprov: Of course.
<cprov> wgrant: and of course you are right, we can audit the code a bit and open up actions on rebuild archives to uploaders
<danilo-afk> jtv: hey
<danilos> jtv: https://translations.edge.launchpad.net/ubuntu/jaunty/+source/findutils/
<bac> hi salgado
<salgado> hi bac!
<henninge> danilos, jtv: https://translations.edge.launchpad.net/ubuntu/jaunty/+source/findutils/+pots/findutils
<bac> salgado: good morning.  i wanted to confirm our new QA rules.  just one tester and not the owner, right?
<bac> salgado: we've got a lot of QA to do...
<salgado> bac, I thought it was two testers and not the owner, but I really don't know where I got that from
<bac> salgado: i thought we were trying to streamline.  we should decide at our standup
<salgado> bac, do we have custom rules for every team?  or is this LP-wide?
<danilos> henninge, jtv: https://bugs.edge.launchpad.net/rosetta/+bugs?field.tag=import-queue
<salgado> matsubara, do we have LP-wide rules for QA?
<bac> salgado: i thought curtis said we were outliers and the new rule was to bring us in line with everyone else
<matsubara> salgado, not yet
<matsubara> salgado, francis will draft up QA plan for LP
<salgado> cool
<salgado> bac, that rule sounds good to me, then.  let's go with it
<bac> salgado: yeah, let's talk about it in 45 minutes
<wgrant> What do contributors need to do about QA?
<bac> wgrant: can you edit the wiki?
<bac> Ursinha: do you have access to the email from staging?  i'm looking for a registration email for QA
<wgrant> bac: It seems I can edit the test plans, yes.
<bac> wgrant: how 'bout i ask during our meeting and get back to you.  personally, if you want to do some QA i'd think it would be very welcome.
<bac> matsubara: ping
<danilos> salgado: hi
<salgado> hi danilos
<danilos> salgado: I was wondering about something for the breadcrumbs
<danilos> salgado: I know it's not possible today, but would it be worth thinking about the use case of https://translations.edge.launchpad.net/ubuntu/jaunty/+source/findutils/
<danilos> salgado: i.e. the final breadcrumb (for ISourcePackage) can't be on rootsite="translations", but I'd like the breadcrumb to be there
<salgado> danilos, shouldn't the breadcrumbs there be 'Ubuntu > 9.04 > findutils > findutils translations"?
<matsubara> hi bac
<bac> hi matsubara.  1) do you have access to the staging outbox?  i'm looking for a registration email for QA.  2) have we talked about community contributors doing QA?  wgrant was curious.
<danilos> salgado: I don't want them to be that
<danilos> salgado: basically, because it doesn't make sense for people to traverse into a sourcepackage to get translations
<intellectronica> wgrant: what we usually do is we put our nick next to changes we want to test in the test plan (to make sure nobody is working on them in parallel)
<intellectronica> wgrant: one thing we try not to do, is test ones own code
<bac> matsubara: brb
<matsubara> bac, 1) yes, I'll look that up for you 2) not yet.
<danilos> salgado: in general, this might be a moot point since we'll be totally restructuring the traversal (to go through language first, and not even mention the source package), but I am wondering if this might be an actual good use case
<danilos> salgado: so, once we change the basic translations traversal, we can make it be 'Ubuntu > 9.04 > findutils > Translations', but before than, we want to enable people to go back to Ubuntu 9.04 translations page because that's a more likely starting point
<danilos> s/than/that/
<intellectronica> wgrant: other than that there isn't anything too sophisticated about the qa process. if at any time you feel like helping with some testing it will be great. i think it always helps when you got a fresh set of eyes when trying to discover defects
<salgado> danilos, that should be doable if we turn breadcrumbs into multi adapters (like views) so that you can specify a custom breadcrumb adapter for source packages on the translations layer.  it's something that would make sense and would be relatively easy to implement, I think
<allenap> intellectronica: On that note, I just marked a product picker branch of yours as ??. The functionality works, but it causes the status, importance and assignee pickers to stop working because the bugtask is now at a different URL (at least, that's my guess).
<intellectronica> allenap: aha! is there a bug?
<allenap> intellectronica: I haven't filed one, but I shall look for or file one now.
<intellectronica> allenap: and i think that's a BAD, not a ??
<allenap> intellectronica: I was on the fence. It works after all ;)
<intellectronica> allenap: well, i'm split too, in the sense that it's definitely a bug, but maybe not one worth fixing for r-c
<intellectronica> so if you file a bug i can at least have a look what it would mean to fix it and we can decide then
<allenap> intellectronica: Agreed.
<jml> hi
<noodles775> Welcome jml :)
<jml> noodles775, thanks :)
<mrevell> jml: welcome to the top
<danilos> salgado: in general, I'd like us to hold out on that until we have something of a real use case; what I have right now is a case which I want to get rid of anyway (i.e. I'd need it to have a nicer work around for the bad traversal, but it'd still be just a workaround), but perhaps I should file a bug about it for the future?
<jml> mrevell, heh heh
<salgado> danilos, please do
<jml> mrevell, thanks.
<danilos> salgado: bug 433997
<mup> Bug #433997: Breadcrumbs should allow links to be on different vhosts <Launchpad Foundations:New> <https://launchpad.net/bugs/433997>
<salgado> thanks danilos
<jml> so, what's up in Launchpad land?
<beuno> salgado, any news on killing icons from breadcrumbs?
<salgado> beuno, done already.  do you see them anywhere?
<beuno> salgado, ah!  not anymore
<beuno> salgado, thanks
<salgado> beuno, np
<salgado> barry, so, the bug is in fmt:pagetitle
<salgado>         return SEPARATOR.join(
<salgado>             breadcrumb.text for breadcrumb
<salgado>             in reversed(hierarchy_view.items))
 * barry remembers that code
<salgado> the text of breadcrumbs may come from a view's .page_title, which in turn may be instances of zope.i18nmessageid.message.Message
<barry> salgado: shouldn't .text be a property that guarantees a unicode?
<salgado> barry, so, when we do the join() there, we end up joining the Message objects without expanding
<salgado> barry, I guess so
<salgado> that hasn't been a problem in the past because zpt knows how to deal with Message objects properly
<salgado> another option would be to have fmt:pagetitle pass the Message objects to the template, as it's handled properly there
<barry> salgado: the only other choice i think is to unicode(breadcrumb.text) in that .join() but it seems like it's better to let the IBreadcrumb do it (since there may be other things it needs to do to turn it into a usable unicode)
<salgado> barry, I think you misunderstood me.  the problem is this: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/433991
<mup> Bug #433991: Reverse breadcrumb titles don't expand zope.i18nmessageid.message.Message strings <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/433991>
<salgado> most likely I wasn't clear. ;)
<barry> salgado: right, by unicode(breadcrumb.text) i meant "do whatever you have to turn what breadcrumb.text gives you into a unicode" ;)  sorry for the short hand.  i'm just not sure that the .join() code can always do the right thing.  so that's why i think the contract for IBreadcrumb.text should be "returns a unicode".  or is that insane?
<salgado> barry, it is unicode already; just not expanded: u'Ask a question about ${context}'
<salgado> or, actually, .text may return a Message object
<salgado> ok, scratch that.  I see what you mean now
<barry> salgado: yeah.  does that make sense?
<salgado> barry, I think it does, but that means we'd have to deal with Message objects at two different levels.  whereas if we change fmt:pagetitle to not join the breadcrumbs (leaving that for the template), we won't have to bother as the template deals with it properly
<jml> this is so exciting, see Americans in their native timezone
<barry> salgado: i see the problem.
<barry> salgado: i don't think i want to do the join in base-layout.pt.  what if fmt:pagetitle called a simple template to do the join?
<salgado> barry, wfm, but I'm kinda concerned that having IBreadcrumb.text sometimes return Message objects (that need special casing) might cause all sorts of headaches
<salgado> it might be better to do what you suggested, having IBreadcrumb deal with Message objects and return unicode
<barry> salgado: i agree with that.  am i right that we only see the problem in the titles though because the in-page breadcrumbs get converted properly by their template?
<salgado> but I'm not sure that'd work from a translations POV
<salgado> barry, yes, that's correct
<salgado> barry, do you know how these Message objects would get translated in IBreadcrumb?
 * salgado knows absolutely nothing about translations
<barry> salgado: i used to know, but it's been a looongggg time :(
<salgado> barry, gary_poster knows, I'm sure
<barry> salgado: so i definitely think that IBreadcrumb.text returning Message objects is crazy
<salgado> gary_poster, around?
<gary_poster> barry, salgado, yes reading backlog
<gary_poster> salgado: not sure what the question is.  I think it would make sense for IBreadcrumb to do the translations.  It has the request and the Message, which should be all it needs.  It has its own substitution mechanics (not %), so you'll have to make sure you get that right if that's pertinent.
<allenap> BjornT: I'm QAing the FD_CLOEXEC fix you did. Do you know why libuuid forks a process? I'm interested, but I'm also trying to figure out how to confirm it (or justify not bothering).
<salgado> gary_poster, we'd have to use get_current_browser_request(), as the IBreadcrumb adapter is not a multi one.  but I guess that's still what makes the most sense
<gary_poster> salgado: oh ok.  cool.
<BjornT> allenap: it's the way it's compiled in ubuntu. i don't know the exact reasons. you can confirm it by running tests in the BugsWindmillLayer, and make sure that libuuid doesn't own port 9025
<barry> salgado: that doesn't bother me too much
<allenap> BjornT: Okay, thanks, I'll do that.
<dobey> so what's the best way to get the list of bugs that are "assigned to me" with launchpadlib?
<jml> dobey, good question!
<jml> dobey, I don't know, but I'd love to know the answer.
<dobey> yeah, i don't see an obvious path to it, looking at api docs
<jml> given that basically everyone on the bugs team is awake right now...
<jml> *hint hint*
<dobey> (even a non-trivial path)
<jml> ... I would hope that you'd get an answer fairly quickly :)
<barry> noodles775: i'm sorry i couldn't get to your follow up over the weekend.  i'm going to look at it now though
<noodles775> barry: great thanks - intellectronica already approved it, but I was keen for you to take a look at the bug + fix that I did (as our earlier work-around had some problems).
<barry> noodles775: cool.  thanks intellectronica
<beuno> bigjools, hi, have you any news on the lazr-js sprint
<bigjools> beuno: nope :/  still stuck on location
<bigjools> I will chase once more ...
<dobey> jml: the answer i got the other day was that it is non-trivial :)
<dobey> jml: i don't know that anyone has actually done it in practice with launchpadlib yet
<barry> noodles775: did you fix for bug 433852 land, or is it in ec2/pqm?
<mup> Bug #433852: Breadcrumbs display for IHasMajorHeading views <Launchpad Foundations:In Progress by michael.nelson> <https://launchpad.net/bugs/433852>
<noodles775> barry: no, I've included it in this branch for the sprint index and attend pages, so feel free to request changes :)
<barry> noodles775: the posted diff looks fine. i was only going to quibble about a few minor style things :)
<barry> noodles775: actually better than fine; thanks for fixing this!
<noodles775> np!
<salgado> gary_poster, I can't seem to find much info about translating Message objects other than a translate method in talinterpreter.py.  can you point me somewhere to learn how to do it?
<gary_poster> salgado: yeah, as soon as I find t. ;-) one sec
<barry> noodles775: two small suggestions:
<barry> noodles775: move the import of removeSecurityProxy to the module globals
<noodles775> barry: ah ok, I left it there because that's where salgado had it - wasn't sure if there was a reason.
<barry> noodles775: probably just convenience.  it can't cause circular imports (which would be the only reason to do an import in a method)
<barry> noodles775: in display_breadcrumbs, it might be nicer to split the return line up; something like:
<salgado> barry, noodles775, we used to keep removeSecurityProxy imports local because we don't want its usage to spread
<barry> has_major_heading = IMajorHeading.providedBy(self._context_view)
<barry> return len(self.items) > 1 and not has_major_heading
<noodles775> barry: ok, done.
<barry> noodles775: also, though less important, maybe s/_context_view/_naked_context_view/
<barry> "_naked" being a common convention for naming unwrapped thingies
<barry> salgado: cool.
<bigjools> barry: I prefer "undressed" :)
<barry> bigjools: isn't there some cute and quaint british saying that would be appropriate (or maybe *in*appropriate) here? :)
<bigjools> barry: would it end in -monger? :)
<barry> bigjools: starkers? :)
<bigjools> barry: something like that :)
<gary_poster> salgado: I have not found great docs either.  The pertinent package is zope.i18n.  You want to use zope.i18n.translate.  simple usage is translate(msg, context=request).  You probably don't need to worry with the mapping, but it is used to replace $name stuff.
<salgado> gary_poster, cool, will check that out.  the mapping is exactly what I need, though: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/433991
<mup> Bug #433991: Reverse breadcrumb titles don't expand zope.i18nmessageid.message.Message strings <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/433991>
<barry> noodles775: do you need any further approval for your branch?  bac needs to know
<noodles775> barry, bac: nope - I'm just about to do the recommended style changes you had, but nothing else is changing.
<gary_poster> salgado: oh ok.  is it a known set of possible $names that you have to interpolate?
<barry> noodles775: do you have a branch with all your changes pushed?  i'd like to take a look.  it probably makes sense too to land it thorugh ec2 just to make sure there aren't any unintended consequences
<noodles775> barry: yes, there's no way I'd land it without ec2test :), I'll just make your changes and then push them (it's all in the branch on the MP).
<barry> noodles775: :)
<dobey> what's the resolution in pixels that the new lp web ui stuff is being targetted for?
<barry> noodles775: cool, thanks
<salgado> gary_poster, not really, but my code will get a Message object that should have a mapping already, so I was hoping I wouldn't have to worry about it.  maybe that's what you meant?
<gary_poster> salgado: ah, no, it's not, but that is much better, good.  (you can also pass an explicit mapping; I forgot that Messages can and should typically/ideally have their own mapping.
<salgado> gary_poster, cool, thanks a lot for the help
<gary_poster> np
<deryck> dobey, jml -- use searchTasks and pass the assignee as launchpad.me.
<dobey> deryck: searchtasks on what?
<deryck> dobey, there is one on project, distribution, milestone, and a few other places, so I guess that is context dependent a bit.  To find all of your bugs on lp, maybe that's not so easy with the API.
<dobey> deryck: exactly. i can't do it on person, which is what it would be most useful for, to me
<jml> isn't there a top-level bugs collection?
<noodles775> barry: All changes are in lp:~michael.nelson/launchpad/sprint-index-and-attend-3.0 (except I didn't move the removeSecurityProxy as suggested above).
<dobey> jml: yes. if you want to loop through ever bug on lp, i guess it's useful
<dobey> jml: but it doesn't seem to have a searchTasks()
<barry> noodles775: +1; i'll grab the branch after the ui call
<jml> dobey, it would seem a natural place for one.
<deryck> jml, yes, there is a bug set, but it doesn't have searchTasks.  it should, or at least a way to search for assigned bugs.  dobey, would you open a bug against malone for this?
<dobey> sure
<deryck> dobey, thanks!
<barry> bac: i've got bug 434072
<mup> Bug #434072: Convert specifications-index to UI 3.0 <story-ui-3> <Launchpad Registry:Triaged by barry> <https://launchpad.net/bugs/434072>
<bac> barry: cool
<jml> kfogel, hi.
<beuno> bigjools, any reason why the creation info, etc, is on a portlet: https://edge.launchpad.net/ubuntu/+source/gnome-panel
<beuno> instead of on the top right, like in everywhere else?
<bigjools> beuno: it was considered to be package activity
<beuno> bigjools, I'm not super convinced, it feels off
<bigjools> the information is top left
<bigjools> I'm pretty sure you sanctioned it :)
<beuno> yeah, I'm wrong a few times a week
<beuno> maybe that was one of them...
<bigjools> I think it's fine
<kfogel> jml: hey!  Made it over ok?
<jml> kfogel, I did :)
<kfogel> jml: whew :-)
<bac> henninge: hold off on landing until we get the devel/db-devel sorted out
<henninge> bac: uh oh ...
<bac> henninge: too fast!  :)
<henninge> bac: ah, got another failure ;)
<bac> henninge: you have run this branch against ec2?
<henninge> bac: all good
<henninge> bac: no, already did
<bac> henninge: ok.
<bac> hi EdwinGrubbs
<barry> bac: shouldn't "Foo Bar" in https://launchpad.dev/~name16 be an H1?
<bac> intellectronica, EdwinGrubbs: i'm seeing an ajax red error box when i try to change a bug task 'affects'.  is this a known issue?
<barry> noodles775: afaict, your branch looks fine from ui perspective
<EdwinGrubbs> bac: I don't know about that. I could research that later today if necessary.
<noodles775> barry: great. Any other issues from a non-ui-perspective or shall I request the RC? :)
<intellectronica> bac: not really, more info please: what's in the red error box?
<noodles775> Thanks!
<bac> intellectronica, EdwinGrubbs:  http://people.canonical.com/~bac/ajaxerror.png
<bac> intellectronica, EdwinGrubbs: the change actually happened but that error box was displayed
<bac> the entry on the page did not refresh to show the change
<intellectronica> bac: is that safari?
<bac> intellectronica: indeed it is.  i haven't tried it in FF yet.  could you do that?
<intellectronica> i have a feeling that this may be a compatability issue
<intellectronica> it works fine in ff
<barry> noodles775: none that i could see. rc-away!
<noodles775> great thanks!
<intellectronica> bac: i can reproduce with chromium, so i guess it's yet another webkit compatibility problem
<bac> intellectronica: ok.  could you open a bug?
<intellectronica> bac: yes
<bac> thanks
<intellectronica> bac: https://bugs.edge.launchpad.net/malone/+bug/434093
<mup> Bug #434093: Inline bugtask product editing doesn't work in WebKit -based browsers <Launchpad Bugs:New> <https://launchpad.net/bugs/434093>
<intellectronica> bac: also, can i please get r-c for https://code.edge.launchpad.net/~intellectronica/launchpad/hot-bugs-summary/+merge/12150 ?
<bac> bigjools, deryck, barry: we've got three unassigned template conversions for blueprints that are rollout blockers.  can your team take another?  https://dev.launchpad.net/CurrentRolloutBlockers
<bigjools> bac: yes, I'll take one
<bac> bigjools: sweet.  please claim it and move to in progress
<bigjools> which is easiest? :)
<bac> intellectronica: done
<intellectronica> bac: thanks
<bac> gah, i wondered why i couldn't change status for MPs.  didn't see the action had moved over there --->
<deryck> bac, allenap can take one of those. ^^
<intellectronica> yeah, i spent good 10m this morning hunting for the button :)
<bac> intellectronica: please add that bug to CRB if you haven't
<bac> deryck: great!
<bac> barry: can you see if salgado or EdwinGrubbs can take one?
<salgado> I sure can
<barry> EdwinGrubbs: can you take one and then we can fight over the third?
<EdwinGrubbs> barry: I'm CHR today, so I don't think I can get to it until later today. Which one is it?
<barry> EdwinGrubbs: okay.  i might be able to get to it
<barry> first, lunch..
<bac> salgado: thanks!  barry, i think they are all claimed now
<salgado> bac, barry, do I need to update the wiki page or something?
<bac> salgado, deryck, bigjools: we may have over-assigned the items on https://dev.launchpad.net/CurrentRolloutBlockers.  can y'all coordinate among yourselves, claim the bugs, and update the wiki page?
<bigjools> bac: I've not claimed anything yet
<bigjools> I have now
<bac> henninge, intellectronica, noodles775: you are free to land with RC on devel now.
<henninge> bac: really? cool.
<flacoste> EdwinGrubbs: bug 434058 has the last unowned blueprints templates
<mup> Bug #434058: Convert specification-linkbug, -edit, and specificationtarget-assignments to UI 3.0 <story-ui-3> <Launchpad Blueprints:New> <https://launchpad.net/bugs/434058>
<EdwinGrubbs> flacoste: ok, I'll take it.
* flacoste changed the topic of #launchpad-dev to:  This is Launchpad Development Channel | Week 4 of 3.0 | PQM is closed - Release manager is bac - contact for release-critical | https://dev.launchpad.net/CurrentRolloutBlockers | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes |
<dobey> hrmm. i am not liking some of these layout changes on edge :-/
<jml> dobey, I'd love to hear about it
<jml> but not on IRC right now, since my brain is a little fungus-y atm
<dobey> heh
<dobey> jml: 'mark as duplicate' on bugs, and 'change status' on merge proposals, are the 2 that are sticking me in the side right now :)
<dobey> hmm, and i'm slightly unsure if my API request should be filed against malone or not
<jml> dobey, I'd file it against malone
 * jml is going
<dobey> well i guess i need to file 2 bugs... one for searchTasks on bugs, and one for searchTasks on person/team
<barry> bac: specifications-index.pt conversion is mp'd for review.  are there any other pages that need conversion?
<bac> EdwinGrubbs: i see you've grabbed bug 434058.  are you going to be able to work on it today?
<mup> Bug #434058: Convert specification-linkbug, -edit, and specificationtarget-assignments to UI 3.0 <story-ui-3> <Launchpad Blueprints:New for edwin-grubbs> <https://launchpad.net/bugs/434058>
<bac> EdwinGrubbs: if not, perhaps barry would like it
<barry> bac: only after your rc for https://code.edge.launchpad.net/~barry/launchpad/434072-spec-index/+merge/12175 :)
<EdwinGrubbs> bac, barry: it will be at least a couple of hours before I can start on it, so you're welcome to it.
<bac> barry: blackmail?
<barry> bac: bacmail
<barry> bac: i'll take it
<bac> barry: great.  will you update the bug and CRB?
<barry> bac: yep
<bac> barry: you're so much more efficient now with your new 4 core machine
<barry> bac: oh man, tell me about it!
<ScriptRipper> kiko: ping
<bac> hi rockstar
<rockstar> bac, hi.
<bac> rockstar:  hey i see you worked on two answers templates.  do you know if anyone is doing question-index.pt
<rockstar> bac, question-index should be done.
<bac> rockstar: ok, i was going by http://people.canonical.com/~beuno/conversions.html
<rockstar> bac, oh, wait, is that the applicationhome one?
<bac> yeah
<rockstar> bac, I wasn't sure if that needed to be ported, but I can give it a shot.
<rockstar> bac, I also have one more code template that needs to move and be ported.
<bac> rockstar: that'd be nice if you could.  would you mind opening a bug and listing it on https://dev.launchpad.net/CurrentRolloutBlockers
<bac> rockstar: ok.  your code work comes first so let someone know if the other needs attention.
<rockstar> bac, well, technically, code is responsible for answers, so they both need to be done.
<bac> rockstar: really?  cool.
<gary_poster> wgrant: ping?
<barry> bac ping
<bac> rockstar: remember to land your next changes on devel, not db-devel
<bac> hi barry
<rockstar> bac, cool.
<gary_poster> deryck: hi.  I reviewed and landed a branch from wgrant this cycle that moved subscription security into the model.  Returning to the branch, it looks like this is about bug subscriptions.  May I add this to the bugs QA list for 3.0.0?  (commit info: r9371 "[r=gary][ui=none] (wgrant) Move structural subscription security to the model, rather than the view.")
<deryck> gary_poster, yup, that will be fine.
<gary_poster> deryck: thank you!
<deryck> gary_poster, np!
<flacoste> gary_poster, barry: do you know if i can use pkg_resources.resource_string('my.package', 'templates/file.txt') ?
<flacoste> where templates is not a python package
<gary_poster> I do not now
<gary_poster> know
<bac> deryck, bigjools, barry, rockstar: how is QA going for your team?
<bac> gary_poster: ^^
<bac> matsubara, Ursinha: any thoughts from you about QA?
<gary_poster> bac: There's a lot for Stuart to do.  I'm about to write him about it.  That's about it.
<barry> bac: i need to talk about https://blueprints.launchpad.dev/firefox/+assignments  i don't think this is a mechanical change
<barry> flacoste: i've never tried that
 * bac looks
<deryck> bac, slower than I'd like.  We made good progress earlier, but now we
<deryck> bac, we're all working on fixes
<bac> deryck: and QA begets more fixes...
<rockstar> bac, we're getting through it, but with staging down, we're kinda blocked on many things.
<barry> bac: i think we're probably not doing much qa right now.  EdwinGrubbs is ocr, salgado and i are working on bugs, your the rm, and curtis is on a sprint
 * barry is trying to remember the magic incantation for landing an rc
<matsubara> bac, I'll take care of https://dev.launchpad.net/LaunchpadTestPlan/3.0 and talk the contributors about the items there
<bac> barry: look at henning's landing
<bac> for the RC magic
<Ursinha> thanks matsubara
<bac> matsubara: is there a page with links to all of the team pages
<bac> matsubara: and thanks for taking that on
<matsubara> bac, https://dev.launchpad.net/QATeam/TestPlans
<barry> bac: my thinking on bug 434058 is to split specificationstarget-assignment into a separate bug, get the mechanicals reviewed and landed, and then come back to +assignments
<mup> Bug #434058: Convert specification-linkbug, -edit, and specificationtarget-assignments to UI 3.0 <story-ui-3> <Launchpad Blueprints:In Progress by barry> <https://launchpad.net/bugs/434058>
<barry> bac: i have the other two templates already converted.  they were mechanical and easy
<bac> barry: cool.  sorry i've been distracted on another chat
<barry> bac: no worries.  okay, i'll file a separate bug for -assignment
<bac> barry:  looking at +assignments now
<bac> barry: your concern is the portlets?
<bac> barry: splitting the bug is a fine idea
<bac> barry: i just lumped them together crudely
<barry> bac: yep, the portlets
<bac> barry: let's talk about the design later.
<barry> bac: okay.  let me get this one into review and then you can ping me when you're ready to chat
 * rockstar finds fud
<dobey> rockstar: now all you need is ge
<bigjools> bac: it's fine
<bac> bigjools: thanks
<bac> bigjools: i see you've only got 14 in NEEDSTESTING.  that's great.
<bac> bigjools: would you mind if i assign https://bugs.edge.launchpad.net/blueprint/+bug/434195 to noodles775
<mup> Bug #434195: Convert specificationstarget-assignements to UI 3.0 <story-ui-3> <Launchpad Blueprints:Triaged> <https://launchpad.net/bugs/434195>
<bac> danilos: how is your team's QA going?
<bigjools> bac: can you ask him tomorrow when he's working, but it's probably ok
<bigjools> bac: yeah we have some items in 2.8 as well :)
<danilos> bac: it's fine though TestPlans page do not reflect it very well; also, fyi, I've just added two items to current rollout blockers (we are not yet sure they are blockers, but I'll have to spend some time investigating tomorrow to decide if they are but would rather have them on the page)
<bac> bigjools: i can.  i thought you might have an understanding of his workload.  i'll assign it to him and he can dump it if too busy
<bac> danilos: thanks
<bigjools> bac: well his workload is full-ish, that's why I said to ask to see if he wants to take it on
<bac> bigjools: i don't want it to idle between euro day start and my day start.
<bac> bigjools: i'll email him and ask him to try to find another owner if he cannot do it.  otherwise i'll deal with it tomorrow a.m.
<bigjools> ok
<bigjools> I am 50% through the ones I took earlier, BTW
<bigjools> talking of which, barry, halp
<flacoste> bac, bigjools: danilos was willing to do some blueprints conversion
<danilos> flacoste: I'll have to see about that tomorrow morning though (with these two bugs now, they might take some time off); simple templates are fine though
<danilos> anyway, /me wanders off
<barry> bigjools: wassup?!
<barry> bac: we remove stuff from BlueprintsConversion once we land the code?
<bigjools> barry: you da headings man - I gotz me some heading probz.  I have a label on my view and it appears above the breadcrumbs and also above a form on the page, how do you fix that?
<barry> bac: and CurrentRolloutBlockers?
<barry> bigjools: you've check that there's no heading slot filled on your template?
<barry> bigjools: and no extraneous h1/h2 before the <form>?
<bigjools> barry: there is not
<bigjools> there is not
<barry> dang
<barry> bigjools: you should not be getting two headers <wink>
<barry> bigjools: can you push the branch and give me a lp.dev url to look at?
<bigjools> ok one sec
<bigjools> lol, bzr diff > utilities/paste doesn't work does it :)
<bigjools> barry: http://pastebin.ubuntu.com/275460/
<bigjools> apply that
<bigjools> and visit https://blueprints.launchpad.dev/ubuntu/+spec/media-integrity-check/+requestfeedback
<barry> bigjools: no, it's bzr diff | utilities/paste :)
<barry> bigjools: k, sec.  i haven't finish something up
<bigjools> barry: the view inherts from zope's AddView, I wonder if that would bugger it
<barry> bigjools: yikes!  switch that to LFV or LV
<bigjools> :)
<bigjools> blueprints suck
<barry> bigjools: can you just bzr rm them all?
<bigjools> barry: LFV doesn't make any difference and cocks up my form labels
<barry> crap
<barry> bigjools: okay, i'll look once this mp is in
<bac> barry: i didn't even know about the BlueprintsConversion page
<bac> barry: keep them on CRB but move to the appropropriate section
<barry> bac: neither did i until flacoste pinged me about it
<barry> bac: done
<bigjools> he did email about it :)
<barry> ;)
<barry> bigjools: okay, mp sent.  let me check out your branch
<bigjools> coolio thanks
<flacoste> bigjools: AddForm, aaargh, i thought salgado had got rid of all of those
<barry> flacoste: could that be messing up bigjools pages?
<salgado> flacoste, only SQLObject*Form
<barry> bigjools: okay, i see the double "Request feedback on specification"
<flacoste> barry: probably, since i'm pretty sure your infrastructure doesn't cover addform
<barry> flacoste: i'm nearly certain it doesn
<barry> er, doesn't
<bigjools> so is there an equivalent that I can use on this page?
<bigjools> that will work with your heading infra?
<barry> bigjools: it's gotta be LaunchpadFormView
<bigjools> barry: ok
<barry> bigjools: but yeah, i see that doesn't help a whole lot :/
<bigjools> barry: s/addform/form/ in the template?
<barry> bigjools: take a look at the configure.zcml entry for that page.  i'm think simplify and convert it to a browser:page will help you there
<bigjools> barry: arghhhhhh
<bigjools> barry: I see the label in the zcml now!
<barry> bigjools:  yeah.  kill all this old shit!
<barry> bac: can i get an rc for https://code.edge.launchpad.net/~barry/launchpad/434058-specs/+merge/12183
<bigjools> barry: I wish I knew what I were doing to be able to do that
<barry> bac: okay, i am going to start on qa now
<bac> barry: \o/
<salgado> barry, will you start with the ones at the top?
<barry> bac, salgado: at the top of this: https://dev.launchpad.net/RegistryTeam/RegistryTestPlans/3.0 ?
<salgado> barry, yep, just wondering if I should start from the bottom so that we don't duplicate work/conflict
<barry> salgado: good point.  we also have 2.2.8 stuff to qa don't we?
<barry> salgado: maybe one of us should take 2.2.8 and one should take 3.0?
<salgado> good point
<barry> salgado: you choose.  i'll take the other
<salgado> barry, I can take 3.0 as I've already done a few there
<barry> salgado: +1.  i'll start on 2.2.8
<rockstar> sinzui, what was your mechanical process for moving three column layouts to 3.0?
<sinzui> rockstar: I do not understand. I do not recall what a 3 column layout looks like
<rockstar> sinzui, answers.launchpad.net
<bac> salgado, barry: i've just been picking them randomly from the middle of the wiki page
<sinzui> rockstar: ahh, that is freeform
<sinzui> rockstar: I think you are at liberty to invent. I would copy code or bugs.
<bac> salgado, barry: i meant on the 3.0 page
<rockstar> sinzui, roger.
<sinzui> code is way to exciting for answers
<bac> sinzui: i like your mugshot on LP.  is that new?
<sinzui> bac: The new ui exposed my old logo from two years ago
<bac> ah
<sinzui> I was thinking of updating it using my daughter's tablet to draw
<bac> that'll surprise some people
<bac> look, it's me back when i had hair
<barry> salgado: do you have a qa plan for bug 290681?  i didn't see a branch or mp cover letter for it
<mup> Bug #290681: Superteams are not properly carried over when merging teams <Launchpad Registry:Fix Committed by salgado> <https://launchpad.net/bugs/290681>
<salgado> barry, that's pretty tricky to reproduce, but if the fix wasn't good, we'd have gotten some warnings from the monitoring scripts about inconsistent memberships/participations.  I'd say just mark that as ??
<barry> salgado: good point, thanks
<bac> salgado: ping me when you aren't editing the 3.0 test plan
<salgado> bac, just finished
<bac> sinzui: a lot of the bugs you fixed don't have related branches, which makes finding the MP with QA plan hard.
<sinzui> bac: yeah, I realised I fixed them after the branch landed.
<bac> sinzui: ah, i see.
<sinzui> bac: That is not just me. I have been adding everyone's name to a trvial or UI bug that was closed by a branch they landed
<bac> ah...
<bac> i wonder if there is a good way to find the MP based on the rev number... i doubt it
<sinzui> hmm
<sinzui> The bugs are almost always related to the landing of the branch that updated the page.
<sinzui> portlets are not, and salgado and I landed a few branches that fixed portlets
<sinzui> bac: I worry more about unwanted timeouts caused by trivial UI changes.
<bac> sinzui: maybe it is best to work from the MP backwards...
<sinzui> bac: I had to remove bug tags from the milestone page a few days after landing that. QA was fine, the oops report was not
<bac> sinzui: right.  those will be hard to casually find
<sinzui> bac: salgado: I worry about the number of queries on the project page. We show all milestones, which is not just expensive, they are not important. I think we should only show the last 5-7, but am not sure a simple limit in the template will improve the number of queries.
 * sinzui shrugs
<flacoste> barry: how do i use with in 2.5?
<barry> flacoste: you need an object that supports the "context manager" protocol, but let's say you want to use an open file object in a with statement (files support the protocol)
<barry> with open(foo, 'w') as fp:
<flacoste> ah, ok, open, not file(
<barry>     print >> foo, 'wussup'
<barry> flacoste: right! file ctor is deprecated :)
<barry> er, that should have been: print >> fp, 'wussup'
<flacoste> testplan.py:253: Warning: 'with' will become a reserved keyword in Python 2.6
<flacoste> barry: why do i get the above warning^^^
<flacoste> barry: do I need a from __future__ ?
<barry> flacoste: in py2.5, yes
<barry> from __future__ import with_statement
<flacoste> ah, ok
<flacoste> thanks
<barry> in 2.6, no :)
<barry> np!
<mwhudson> good morning
<bac> hi mwhudson
<bac> salgado: do you have a team that will show the issue for https://bugs.edge.launchpad.net/launchpad-registry/+bug/423080
<mup> Bug #423080: Team "Maintained Packages" link has incorrect capitalisation and location <trivial> <Launchpad Registry:Fix Committed by salgado> <https://launchpad.net/bugs/423080>
<salgado> bac, not really, just looked at a dozen teams that I'd expect to have that but none of them do
<bac> yeah, and wgrant's screenshot doesn't give context
 * bac wonders if we can conjure wgrant by mentioning wgrant several times.
<bac> salgado: so does that mean we picked bad teams or the link has been killed?
<salgado> bac, I think we're just picking bad teams -- the link is conditional
<salgado> bac, it is the same you see on a person's page, though
<salgado> https://edge.launchpad.net/~salgado
<rockstar> thumper, we should do that standup thing that we do sometimes.
<bac> salgado: yeah, that's perfect then
<EdwinGrubbs> salgado: ping
<salgado> hi EdwinGrubbs
 * bac relocates.  bbiab.
<EdwinGrubbs> salgado: is it possible to remove a sourcepackage from a distro? https://answers.edge.launchpad.net/launchpad/+question/83436
<salgado> EdwinGrubbs, I don't think so.  cprov should be able to tell for sure
<EdwinGrubbs> cprov: can I assign you that question and another one on ppas?
<bigjools> EdwinGrubbs: I will answer it
<EdwinGrubbs> bigjools: thanks
<bigjools> EdwinGrubbs: actually - he's asking about upstream links, not the package itself
<EdwinGrubbs> bigjools: ok, who can answer that?
<bigjools> EdwinGrubbs: it's a registry question - and I don't know how the link can be removed
<bigjools> there's an upstream link but the package doesn't exist in Debian
<EdwinGrubbs> bigjools: can you look at this ppa question?  https://answers.edge.launchpad.net/launchpad/+question/83441
<bigjools> Debian experimental that is
<bigjools> EdwinGrubbs: yes
<awilkins> Hello, is it intentional that LP only runs on 64-bit machines (I'm referring to the 64-bit libraries that have been checked into the source tree)
<rockstar> awilkins, example?
<awilkins> _lsprof.so gives you an ImportError on 32-bit machines with an ELFCLASS64
<rockstar> awilkins, make clean and then make build again.
<awilkins> rockstar: I did that. The problem with that library was resolved by removing the checked-out one and linking the python 2.5 (32-bit) version of it bu there are more libraries like it
<rockstar> awilkins, file a bug.  It used to run fine on 32-bit systems.
<awilkins> rockstar: I think it's because they are not in the python 2.4 distribution
<awilkins> rockstar: Just in the process :-)
<maxb> Hrm, before you file a bug, let's make sure it's not just your system that's broken.
<maxb> I certainly didn't have these problems running LP on i386
<awilkins> The file has been there for some time, according to it's changelog
<awilkins> Introduced into devel at 6535
<maxb> Which file exactly are you talking about?
<awilkins> lib/_lsprof.so
<maxb> awilkins: I think you'll find that's a symlink :-)
<awilkins> Aha.
 * awilkins does a make clean on lsprof
<bigjools> barry: still around?
<awilkins> maxb: This is probably because I did a recursive copy from another drive...
<maxb> mystery solved.
<barry> bigjools: yep
<maxb> bigjools: Are you handling Q 83441 or shall I answer it?
<bigjools> barry: I am in the middle of converting that page to use LFV, but one of the fields that I specify in field_names doesn't show the input box, just the label.  Any ideas?
<awilkins> maxb: Needs a "make uberclean"  :-)
<bigjools> maxb: go for it, I am in form hell...
<barry> bigjools: weirdness.  can't think of anything... :(
<barry> bigjools: but if you want another pair of eyes, let me know
<bigjools> barry: yes please!
<bigjools> http://pastebin.ubuntu.com/275523/
 * barry looks
<bigjools> barry: the widget was not specified in the original form zcml, I wonder if LPV needs one?
<barry> bigjools: which field?
<bigjools> barry: "reviewer"
<bigjools> barry: I see the label, the description and its title but no input box... it's bizarre
<barry> bigjools: reviewer is in ISpecificationFeedback?
<bigjools> yes
<barry> how weird!
<bigjools> flacoste: any ideas?
<barry> bigjools: will that diff apply to devel?
<bigjools> barry: I bloody hope so
<barry> bigjools: :) i mean, it's the diff of your entire branch?
<bigjools> barry: no, but the only other commit is for a different page
<flacoste> bigjools: i don't think you need the HiddenUserWidget anymore
<bigjools> flacoste: yeah you're probably right :)
<flacoste> bigjools: you can replace that with self.user
<bigjools> I am blindly copying the original form for the moment
<barry> bigjools: still rf-getting
<flacoste> bigjools: i think it's because the field is readonly in the interface
<bigjools> flacoste: ah
<flacoste> bigjools: i think it's fine for the model, but the UI it's sure not
<bigjools> flacoste: is it safe to make readonly=False?
<flacoste> bigjools: here, yes
<barry> flacoste: you're talking about the widget bigjools doesn't see?
<flacoste> bigjools: when we export it over API, it won't
<flacoste> bigjools: but this whole feature should be removed anyway
<bigjools> flacoste: yeah, we can worry about that later
<flacoste> bigjools: or re-implemented properly
 * bigjools is just doing mechanical changes ... :)
<barry> bigjools: demo url?
<bigjools> barry: no matter, flacoste has figured it out!
<bigjools> barry: thanks anyway :)
<barry> bigjools: coolio
<bigjools> I love these 10 minute jobs that turn into an all-night hacking session!
<maxb> "love", as in "hate" :-)
<thumper> beuno: ping
 * bigjools looks for matchsticks to prop eyelids open
<thumper> flacoste: do you have a few minutes to talk about your email reply to my authorisation in the model code?
<flacoste> thumper: a little later, yes, i was going afk for dinner, be back later to speak to the other side
<EdwinGrubbs> barry, bac: did you need any help converting templates?
<thumper> flacoste: eta?
<bac> EdwinGrubbs: all are assigned right now
<bac> EdwinGrubbs: we need major QA-ness
<EdwinGrubbs> ok
<flacoste> thumper: 2-3 hours?
<thumper> flacoste: hmm, I'll be out then
<bac> EdwinGrubbs: try to pick items to QA that affect "major" pages
<bac> EdwinGrubbs: and don't forget we have stuff on the 2.2.8 page too!  :(
<flacoste> thumper: ok, let's do this now then
<barry> bac, EdwinGrubbs i'm working my way through the 2.2.8 page
<bac> barry:  cool.  as above, try to hit the big pages first
<barry> bac: k
<mwhudson> ffs
<mwhudson> why can i never remember how to drive R
<thumper> bac: ping
<thumper> mwhudson: drive R ?
<mwhudson> thumper: the data analysis package
<thumper> ah
 * barry -> fude
<thumper> rockstar: ping
<rockstar> thumper, pong
<thumper> rockstar: call?
<rockstar> thumper, sure, but I can't guarantee the life of my voice.
<thumper> ok
<wgrant> bac, salgado-afk: That fix is good. The link is now at the top - see https://edge.launchpad.net/~ubuntu-dev
<thumper> rockstar: https://code.edge.launchpad.net/~mysql/mysql-server/mysql-6.0-bugteam
<bac> thanks wgrant
<thumper> bac: ping again
<bac> hi thumper.  sorry i missed your earlier one
<thumper> bac: skype?
<wgrant> Argh.
<wgrant> Who reintroduced the mega-portlet on Ubuntu bug pages?
<wgrant> The tags portlet now shows *every single tag* again.
#launchpad-dev 2009-09-22
<bac> https://code.edge.launchpad.net/~launchpad-pqm/launchpad/db-devel
<bac> matsubara-afk:  OOPS-1360EA2293
<thumper> rockstar: you have an rc in principle for the branch-index page
<mwhudson> thumper: wanna review a ec2 related branch?
<mwhudson> i guess there's no real point in trying to land it r-c but may as well get it ready to go
<thumper> mwhudson: ok
<wgrant> If there's a branch-index branch going on, does somebody want to fix the capitalisation of 'Branch Pending Merges' while they're at it?
<thumper> rockstar: why do the main answers pages still have the old layout?
<thumper> wgrant: tell rockstar :)
<wgrant> rockstar: You might want to s/Branch Pending Merges/Branch pending merges/ on branch-index, if you're working on it.
<mwhudson> thumper: https://code.launchpad.net/~mwhudson/launchpad/no-more-devpad-ssh/+merge/12200
 * mwhudson thinks a little about building new ec2 images from scratch
<bac> thumper: rockstar landed question-index.pt today
<micahg> I like the tag cloud on the bug pages
<rockstar> bac, thumper, correction.  I landed questions-index.pt today.  question-index.pt landed two weeks ago.
<rockstar> wgrant, I'm just going to fix that title to say something like "Branch merges" because "Pending" may not always apply (like if they are rejected or merged)
<wgrant> rockstar: Even better.
<flacoste> bac: you might like http://people.canonical.com/~flacoste/test-plan-report-3.0.html
<bac> go registry!
<bac> flacoste: we did pretty good today, considering they were all NT at the beginning
<flacoste> bac: that's only the 3.0 milestones, i'm graphing the 2.2.8 now
<flacoste> this moin surge protection is slowing me down
<bac> i bet.  your page title needs some interpolation!
<mwhudson> flacoste: the <title> is missing a %
<flacoste> fixed
<mwhudson> hnngh
<mwhudson> launchpad-developer-dependencies is uninstallable on hardy :(
<wgrant> What's broken about it?
<mwhudson>   launchpad-developer-dependencies: Depends: launchpad-dependencies (= 0.50hardy1) but it is not going to be installed
<mwhudson>                                     Depends: postgresql-autodoc but it is not installable
<wgrant> Why won't launchpad-dependencies be installed?
<mwhudson>   launchpad-dependencies: Depends: python-profiler but it is not installable
<mwhudson> hm
<wgrant> That's in multiverse.
<mwhudson> ah
<wgrant> And so's postgresql-autodoc.
<mwhudson> wgrant: i'm working towards a public ec2 image fwiw
<wgrant> mwhudson: Great!
 * lifeless questions whether python-profiler is relevant
<stub> postgresql-autodoc can be dropped if you want - I'm the only person who ever runs the obscure script that uses it.
<wgrant> lifeless: cProfile seems to be installed by default, but not profile itself.
<stub> Please add memcached if you are messing with dependencies though
<lifeless> wgrant: so cProfile used to be nonfree
<lifeless> then it got rewritten from scratch (lsprof)
<lifeless> and the old module became a compatability shim, oh in python2.5 I think
<lifeless> or was it 2.4
<wgrant> Ahh.
 * mwhudson afk for a bit
<stub> mwhudson: I need memcached in dev-dependencies and ec2test,pqm and staging updated before I can land one of my branches.
<lifeless> stub: what are we memaching?
<wgrant> What's being cached?
<stub> Nothing yet - infrastructure is being landed so we can start making use of it.
<lifeless> wgrant: ah 2.5
<lifeless> http://osdir.com/ml/python.ipython.devel/2006-11/msg00058.html [weak evidence, but first I found digging to remind myself]
<stub> or will be landed once we are out of rc mode.
 * MTecknology and that's not all folkes! A resolution is coming near you. Come one, come all, let us not destroy each other but embrase our brothers (or just kill them).
<MTecknology> It's ot - but saying it makes me happy
<MTecknology> lifeless: ^
<MTecknology> lifeless: after 2hr.. he's picking up his kid and doing some thinking on the way - w/e he decides will be it
<beuno> noodles775, hi
<beuno> I woke up today, and the text on all popup overlays is centered
<beuno> do you know what could of happened?
<noodles775> Hi beuno ... really? Nope - haven't touched form overlay stuff for ages...
 * noodles775 looks
<wgrant> All? Some of them have been centered for a couple of months.
<thumper> beuno: I filed a few ui bugs for you to take a look at
<noodles775> beuno: afaics, there's a tex-align: center being set on the actual body el as a default alignment by yui css grids - disabling it certainly affects the alignment in the overlays, but I don't see how this could have changed recently?
<noodles775> beuno: do you have a specific example I could look at?
<noodles775> (one that you're positive changed in the last few days?)
<noodles775> jtv: have you started on the specificationtarget-assignments conversion? If not, let me know and I'll take a look (there was a bug assigned to me, but if you've started that's fine).
<jtv> noodles775: it's waiting for review, so...  ;-)
<noodles775> jtv: nice! I'll assign the bug to you then :)
<jtv> noodles775: this is not one of those "oh and we'll clean up the pagetests and prepare for 4.0 as well" bugs, is it?
<jtv> noodles775: want to review it?
<noodles775> jtv: heh, no, it's just a bug for the 3-0 conversion. And sure, I'll look at it now...
<jtv> thanks
<jtv> hi henninge!
<henninge> hey jtv!
<jml> hello
<henninge> Good Morning jml! ;)
<bigjools> morning all
<mrevell> Buon giorno
<bigjools> mrevell: si
<thumper> bigjools: morning
<beuno> noodles775, sure, look at the status changer in bugs
<beuno> thumper, I saw, thanks
<bigjools> eyup thumper
<thumper> bigjools: I'm not sure I understood your email
<bigjools> thumper: it was a flying pig moment
<bigjools> thumper: we can talk about it next week
<thumper> ok
<noodles775> beuno: so I'm guessing it's related to the update of that page to 3-0. It now uses css resets, which sets the default text-align on the body to center. I'd say we just need to set it to left in overlay/assets/skins/sam/.yui-pretty-overlay, but haven't tested it.
<noodles775> beuno: I'd do it now, but doing a few other 3-0-related things... if it's not done later I'll take a look.
<henninge> noodles775: Hi! Can you help me with a blueprints conversion?
<beuno> noodles775, ok, thanks
<beuno> we need to fix this before rollout
<beuno> I'll file a critical bug and assign it to 3.0
<noodles775> henninge: sure - actually I wanted to ask you what you're doing with the menu for the hasspecs.
<henninge> noodles775: that is exactly my problem !
<henninge> I just don't know
<noodles775> henninge: so, for a similar page (sprint index), I converted the applicationmenu to a navigationmenu and used it for the global actions - would that work here?
<jml> anyone know what's going on here: https://lpbuildbot.canonical.com/builders/db_lp/builds/111/steps/shell_7/logs/summary ?
<henninge> noodles775: so global actions is what goes in the side bar?
<noodles775> henninge: yes.
<noodles775> henninge: http://people.canonical.com/~michaeln/tmp/sprint-index-before.png
<noodles775> http://people.canonical.com/~michaeln/tmp/sprint-index-after.png
<henninge> noodles775: that sounds good and fairly easy to do
<henninge> cool, screen shots ...
<henninge> jml: salgado submitted a fix for that yesterday
<henninge> jml: so now the substitution actually works, as you can see ... ;)
<beuno> intellectronica, hi
<beuno> gmb, hi
<gmb> beuno: Howdy.
<henninge> noodles775: yes, that looks cool
<beuno> gmb, how are you today?
<intellectronica> hi beuno
<beuno> intellectronica, hello hello
<henninge> noodles775: the hasspecification also has a "latest blueprints" portlet.
<gmb> beuno: I've only just started... ask me again in a few hours ;). You?
<beuno> I'm super great. Back from 2 weeks vacations, in the "sunny" London office
<henninge> noodles775: I was about to throw it out but if I keep the side bar anyway ...
<beuno> intellectronica, gmb, I was wondering what the plan was for the bugtask table
<noodles775> henninge: yes, I was looking at jtv's MP right now, which shares lots of commonality.
<henninge> noodles775: do portlets work the same way - before and after?
<beuno> it looks squished: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/434519
<mup> Bug #434519: Text in overlay is now centered <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/434519>
<henninge> noodles775: so, what does converting to NavigationMenu include? Just use a different base class?
<noodles775> henninge: yep, scroll down to the original diff at https://code.edge.launchpad.net/~michael.nelson/launchpad/sprint-index-and-attend-3.0/+merge/12044 to see the changes for the menu and the portlet.
 * henninge looks
<intellectronica> beuno: for 3.0 we have a few small bugs to fix, but that's it really. i think changing the width of the columns is something we should do
<intellectronica> gmb: any chance you may have the time to look at that? i already have a pretty tight plan for today
<gmb> intellectronica: Sure thing.
<intellectronica> gmb: you rock
<jml> henninge, ahh, ok.
<gmb> And gibber, but let's not go into that in a public channel.
<intellectronica> why, now that we're developing in the open i think it's only appropriate that we all bring our personal perversions into the professional arena
<mwhudson> henninge: are you sure about that the reason for the failure in build 111?
<mwhudson> looks like some db-devel / devel integration problem
<henninge> mwhudson: maybe salgado landed his fix on db-devel? There was some confusion about that yesterday.
 * henninge looks for the branch
<henninge> the mp says "merged into devel"
<henninge> https://code.edge.launchpad.net/~salgado/launchpad/bug-433991/+merge/12170
<henninge> can that information be trusted ?
<mwhudson> yes
<mwhudson> but that's not entirely the point i guess
<mwhudson> do the tests fail in db-devel?
<mwhudson> i started to run them about three minutes ago :(
<mwhudson> there are definitely test failures on db-devel
<mwhudson> so someone, maybe even me, needs to Do Something
<noodles775> mwhudson, henninge: As I understood the discussion yesterday, rockstar landed some answers pages on db-devel because he thought salgado had landed his branch there, but salgado hadn't.
<mwhudson> noodles775: that would fit
<noodles775> Which might mean that one solution would be to revert that landing on db-devel and land it on devel?
<mwhudson> seems a bit extreme, it's just 4 page tests right?
<noodles775> Not sure - haven't checked. The other benefit would be that the conversions chart would include his updated templates.
<noodles775> But sure, if there's an easier option...
<mwhudson>      >>> print owner_browser.title
<mwhudson> -    FAQs for $displayname : Questions for Mozilla Firefox : Mozilla Firefox
<mwhudson> +    FAQs for Mozilla Firefox : Questions for Mozilla Firefox : Mozilla Firefox
<mwhudson> is a diff segment that is 95% full of fail :(
<BjornT> noodles775: the easiest option would be to fix the pagetests, no? it looks like they are testing for the wrong title at the moment.
 * mwhudson is fixing them fwiw
<noodles775> BjornT: yes - I just read the actual failure.
<noodles775> I'd assumed it was the reverse.
<mwhudson> noodles775, BjornT, et al: https://pastebin.canonical.com/22364/ <- fix for test failures
<mwhudson> review pls
<noodles775> mwhudson: r=me
<mwhudson> i guess i need a release-critical too?
 * mwhudson tries without
<noodles775> for a test-fix? hrm - there was a discussion about that yesterday... I think henninge asked that question?
<mwhudson> so ftr, for a testfix you don't need a release-critical
<gmb> mwhudson: Does that mean that we can sneak r-c branches in using [testfix] too? "Oh, I was just pre-empting a failure that was going to happen if $new_feature didn't land"
<noodles775> lol
<mwhudson> gmb: only if you can get an r-c and break tests with it first, i think
<mwhudson> ~launchapd, defeating process for fun and profit since 2008
<gmb> Not *too* hard with UI work...
<jml> :)
<jml> how up-to-date is http://people.canonical.com/~beuno/conversions.html?
<mwhudson> jml: it updates every hour, but some conversions have only been done in db-devel
<mwhudson> in particular, i think answers is fully converted in db-devel
<jml> mwhudson, so the conversions page is pointed at devel?
<jml> beuno, would it be hard to change the script to point to db-devel?
<mwhudson> jml: yes
<mwhudson> aiui
<jml> mwhudson, well that makes sense.
<beuno> jml, every 15 minutes I think
<beuno> jml, I can change it to db-devel in about 2 minutes
<jml> beuno, that'd be great, thanks.
<deryck> Hi, all.
<jml> deryck, hello
<beuno> jml, updated to db-devel: http://people.canonical.com/~beuno/conversions.html
<danilo-afk> jtv, henninge: hi guys, you've got any news on the bzr imports problem for me?
<jml> beuno, thanks.
<henninge> danilo-afk: no, sorry
<jtv> danilos: nope
<jtv> I prodded aaron, is about all
<danilos> henninge: how's the blueprints page conversion going? will you have time to look into this? (I am considering making a blocker for rollout, which means that it might become a critical bug for us)
<henninge> danilos: got it figured out now but I have not started on fixing tests yet ...
<henninge> danilos: why is that a roll-out blocker? It has nothing to do with code being rolled out ...
<jtv> danilos: as per the reviewer's suggestion, henning is merging my branch into his to save time.
<jtv> And to improve coordination.
<henninge> danilos: yes, that too
<danilos> henninge: because we don't want to roll out broken features
<danilos> jtv: what branch is that?
<henninge> danilos: which feature?
<jtv> danilos: I took a blueprint conversion as well
<danilos> henninge: bzr import
<henninge> danilos: but that has been rolled out long time ago - broken as it is now ...
<danilos> jtv: ok, cool... however, with the increase in timeouts (yes, they are all on search) and bzr imports problem, we've got two pretty critical issues
<danilos> henninge: right, I see what you mean, since we haven't realised that it was broken for a long time, we should not worry about fixing it ;)
<henninge> danilos: no, but it does not *really* matter if it takes a day longer or not.
<henninge> danilos: and we are not talking about *fixing* it, are we?
<danilos> jtv: will you have time to investigate the problem a bit further today/tomorrow?
<danilos> henninge: yes, we are talking about fixing it; what you were supposed to do is work around it, and that's as urgent as anything else
<henninge> danilos: we are talking about the short-term solution removing jobs.
<henninge> ok, ok ...
<danilos> henninge: have you at least commented on the question to let the guy know what's going on
<henninge> um, I thought jtv did that ...
<jtv> danilos: if you like, yes.  For now I mainly made sure that Code was aware that this is a serious and rising problem.
<jtv> henninge: I thought you were going to look at a one-off query to kill the ghosts of old jobs that we have now.
<danilos> jtv: right, at this point, it's probably a more serious problem for us; I trust you with reading others' generic code and being able to fix it :)
<henninge> jtv: yes, I am. But this blueprint thing got in the way ...
<jtv> danilos: I'm flattered. :)  May not be as effective of course (nor as much fun) as kicking Code people.
<jtv> But hey, it's a problem for us so either way is fine for me.
<jtv> danilos: want to swap problems?
<henninge> danilos, jtv: let me just do the merge and then I'll put the tests off till I have that query set up
<mwhudson> jtv: fwiw, i'm not sure i'm aware what your current problem is
<danilos> jtv: if you can kick Code people into doing it before 3.0, that'd work as well :)
<danilos> henninge: thanks
<jtv> mwhudson: hi!  The problem is those BranchJobs that stay in Waiting or Busy etc. states forever.
<danilos> jtv: swap problems as in? (I ain't letting you have the DB query issue, it looks simpler :)
<jtv> danilos: heh, no not that one.  :)
<henninge> jtv: did you merge salgados fix into your branch?
<henninge> jtv: or: Why is that in your branch?
<jtv> My problem is that I've got a class with two conflicting Navigation classes, through different interfaces, and I'm looking for a _clean_ way to sort out the mess.
<jtv> henninge: no, I didn't merge salgado's fix.
<henninge> jtv: hm, probably need to update devel ...
<jtv> henninge: in fact I can't say for sure what fix you're talking about; the only one I'm really aware of went in Friday.
<henninge> jtv: nm, it's gone now ...
<jtv> danilos: no particular hurry with my problem, but if you happen to be familiar with the problem, it's the last real problem I have with custom language codes.
<danilos> mwhudson, jtv: bug 434192
<mup> Bug #434192: bzr imports are sometimes stuck in 'running' state <Launchpad Translations:Triaged by jtv> <https://launchpad.net/bugs/434192>
<danilos> jtv: should I look at the branch?
<danilos> jtv: or just, please, tell me more :)
<jtv> mwhudson: it's actually a more generic problem that happens to have become visible to us.
<jtv> danilos: with pleasure.  :)  I have an interface IHasCustomLanguageCodes that applies to Products and DistributionSourcePackages.
<jtv> It has a Navigation class so it can traverse "+customcode/foo" (where "foo" is a custom language code).
<danilos> jtv: ok
<jtv> This works fine for Product, and is entirely generic.
<jtv> But.
<jtv> DistributionSourcePackage also has a Navigation class of its own, with a generic traverse() that expects a version number.
<jtv> Well, a version.
 * mwhudson doesn't completely understand that report but shouldn't be near the computer by now anyway
<jtv> If those versions are not allowed to begin with + then there is a simple solution: "if name.startswith('+'): call_my_navigation_instead()"
<danilos> jtv: and you can't register a navigation class just for translations facet and/or make that DSP traverse() ignore '+' links?
<jtv> danilos: see?  This is why I'm asking you.  :)
<danilos> jtv: right, that sounds good... how do we do +pots on DSP?
<jtv> danilos: good one... hang on
<danilos> jtv: perhaps it's not +pots, but the forgotten +translations one :)
<jtv> mwhudson: if you query for BranchJobs older than e.g. a week old and check the statuses, you'll see it soon enough.  It seems to be all across the board, possibly just some missing garbage collection when jobs die unexpectedly.
<danilos> jtv: ok, so we don't have that page anymore (it was useless anyway, but would be useful now :)
<jtv> danilos: or at least it would be useful to know how we did it.  :)
<danilos> jtv: yes
<jtv> danilos: working inside the translations facet could do the trick, I guess...  Gotta try that.
<mwhudson> jtv: i see
<jtv> (I didn't find +pots either)
<danilos> jtv: however, there is stuff to look at like https://bugs.edge.launchpad.net/ubuntu/+source/nautilus/+bugs
<jtv> mwhudson: but we really notice this stuff because we do things like check for ongoing jobs, and so there's real work that's not happening because these zombie jobs are in the way.  Probably it happens elsewhere as well but wasn't as visible.
<jtv> danilos: indeed...  It's definitely possible to attach multiple navigation subtrees to one Navigation class; I could probably use that in some way or form to shunt one set of navigations to my own Navigation class.
<danilos> jtv: btw, why would you provide a full navigation class when you can just use "path_expression" in .zcml
<danilos> jtv: using browser:url, of course?
<jtv> danilos: IIRC I needed that _plus_ this.
<jtv> danilos: one for going up, the other for going down the hierarchy.
<danilos> jtv: could be, I get easily confused with this stuff :)
<jtv> danilos: I can't tell you how happy I am to hear that.  Together we'll get through.  :)
<danilos> jtv: I hope you are not going to ask me to hold hands, though
<jtv> hold your own damn hands
<danilos> phew, thank you
<jtv> heheh
<jml> sinzui, I just saw your mp with the registering line
<danilos> jtv: there are so many pages with '+' links under DSP (in registry/browser/configure.zcml) and they don't seem to provide any navigation classes from what I can tell
<jml> sinzui, can you check your patches behaviour with a bug, please
<jml> (rather than just a branch)
<sinzui> jml: sorry: I do not understand
<jtv> danilos: you're on to something there...  There's a list of defaultviews for different layers there, basically like a "switch statement in zcml."  Maybe I can just add mine in there.
<jml> sinzui, your screenshot in the 'QA' section is for a branch page.
<danilos> jtv: don't add it there, add it to translations/browser/configure.zcml
<danilos> jtv: there's no reason to have zcml registration out in registry
<beuno> jml, http://people.canonical.com/~beuno/branch-index2.png
<henninge> jtv: I re-instated the menu on the assignment page as I have converted it to a NavigationMenu.
<henninge> jtv: here is the branch: bzr+ssh://bazaar.launchpad.net/~henninge/launchpad/bug-434055
<henninge> if you want to look at it.
<jml> sinzui, is that clear?
<sinzui> jml: sorry: I am sprinting and really working on something thing else. Are you asking my to write an instruction to visit a branch and verify that the registered information is above the line?
<jml> sinzui, no, that's fine. I'll just download your branch and test myself.
<danilos> beuno: if this is indeed a branch page as I suspect, and that's what we want description to be used for (i.e. "summary" section of our cover letters), perhaps "Propose for merging" should be closer to that, and initial comment when you go to propose for merging should include the description :)
<danilos> beuno: at least imho :)
<bac> hi beuno
<allenap> bac: Hi there. I've got three branches that I'd like to get rc approval to land, including a blueprints template conversion. They are the first three branches on https://code.edge.launchpad.net/~allenap/+activereviews. The second two branches are not blockers but I'd like to land them anyway.
<bac> allenap: please add me as a reviewer and i'll look at them very soon
<allenap> bac: Oh yeah, sorry, I forgot about that :(
<bac> allenap: np
<henninge> jtv: any idea what state the jobs to set to? Cancelled or Failed?
<wgrant> bigjools: Oh dear... I just looked at the queue override stuff. It actually alters the [SB]PR!?
<bac> allenap: rc=bac on the first one.  very nice work.  the other two i'll look at a bit later.
<henninge> jtv: is that of any consequence?
<bigjools> wgrant: unfortunately yes
<allenap> bac: Thanks.
<jtv> henninge: wouldn't expect it... I'm done for now with my other stuff, so I can look a bit closer.
<bigjools> wgrant: the PPA overrides used to do that as well...
<henninge> jtv: nm, there is only failed.
<wgrant> bigjools: Urrrrrgh.
<allenap> bac: Fyi, I'm going to wait for bigjools' branch because we're going to conflict. I won't land until later.
<jtv> henninge: which may mean they get cleaned up periodically, and that is what we want
<henninge> jtv: Canceled is mentioned in the datbase comment string but is not found in the enum.
<bigjools> allenap: nearly done!  I can merge yours and land both at the same time if you like?
<allenap> bigjools: Much appreciated :) lp:~allenap/launchpad/convert-blueprints-bug-434056
<bac> jml:  ping
<jml> bac, pong
<wgrant> bigjools: Apologies for distracting you from 3.0 panic^Wfestivities, but you suggested a link table between DDEBs and their DEBs. Why not just an extra column on BPR used by DDEBs to refer back?
<allenap> bigjools: Basically, for the givefeedback test, the checkbox names have changed from "feedbackrequest" to "name", and there is no longer a FORM_SUBMIT parameter, instead there is a "field.actions.save=Save changes" button parameter. That's it.
<bigjools> wgrant: because it would be nullable and that is evil
<bigjools> (tm)
<bigjools> allenap: I should be safe!
<henninge> jtv: I have no experience using sub-queries. I this correct? https://pastebin.canonical.com/22369/
<wgrant> bigjools: How's that more evil than a link table?
<jtv> henninge: looks good
<jtv> henninge: unnecessary though; you can use FROM with UPDATE.
<lifeless> bigjools: a link table implies M-M yes?
<henninge> jtv: oh
<lifeless> bigjools: if you don't want M-M, a nullable field is a closer model
<jtv> update job set status = 3 from branchjob, job where [...]
<wgrant> lifeless: That's what I thought.
<bigjools> lifeless: M-M ?
<wgrant> many-to-many
<henninge> jtv: like htis? https://pastebin.canonical.com/22370/ (looks weird)
<bigjools> it doesn't imply that at all
<henninge> jtv: or like this https://pastebin.canonical.com/22371/
<bigjools> if the constraints are set up properly
<jtv> henninge: not sure off the top of my head if JOIN works there, but if it works, go for it.  :)
<henninge> ok, let me try.
<jtv> henninge: again off the top of my head, the SET comes before the FROM
<wgrant> bigjools: But you only *need* a link table for many-to-many. How is it less evil than a nullable field?
<bigjools> it's a null reference - that is evil incarnate
<bigjools> as al-maisan will attest, he loves link tables :)
<wgrant> But null references are everywhere.
<bigjools> that doesn't meant it's a good idea to copy bad ideas
<lifeless> bigjools: index constraints to make a link table which is natively M-M into M-1 *add* work to the problem
<maxb> Why is a null reference evil? Surely an unnecessary link table is evil?
<lifeless> bigjools: !citation
 * bigjools sighs
<bigjools> link tables are only M-M if you use non-unique indexes
<bigjools> anyway, I have to finish this 3.0 work, I will talk about this later
<lifeless> heh, I'll be asleep
<lifeless> anyhow, databases are not VM's; they map differently
<lifeless> vive la difference!
<henninge> jtv: this works: https://pastebin.canonical.com/22372/
<stub> Oh... it is the relational model vs. sql model arguments.
 * henninge lunches now
<bac> hi jtv, can you follow up on https://code.edge.launchpad.net/~jtv/launchpad/mechanical-specificationtarget-assignments/+merge/12203
<stub> Time for bed obviously ;)
<jtv> bac: refresh the page?  :)
<jtv> you juuuust missed it
<bac> jtv:  magic!
 * jtv poses as the world's fastest typist
<al-maisan> bigjools: heh :)
<wgrant> stub: Which do you sanction?
<beuno> jml, bug 373341
<mup> Bug #373341: Rename "Code" tab to "Branches" <navigation> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/373341>
<stub> I like nulls. relational purists can bite me.
<al-maisan> wgrant: both approaches have their respective merits .. I believe there was a decision or "design guideline" to prefer link tables to NULLable foreign keys ..
<maxb> What are the respective merits in favour of link tables?
<al-maisan> maxb: your foreign keys always have non-NULL values i.e. actually point to something :)
<maxb> Why is that a merit?
<al-maisan> maxb: a NULLable FK is there whether you make use of it or not. Conversely you only add rows to a link table when you need to i.e. when you have something to refer to.
<wgrant> Why is it a problem that it's always there?
<lifeless> stub: I'm a relational purist, and I like NULL's too
<maxb> Ok, so if your data is such that few rows will have links, the link table can be a size optimization
<lifeless> al-maisan: there was a what-now?!
<bigjools> lifeless: what's a "NULL's too" ? :)
<maxb> However you end up having to do an extra join to figure out whether there is something there or not
<lifeless> bah
<lifeless> bigjools: bite my shiny metal ass ;)
<bigjools> muahahaha :)
<al-maisan> lifeless: I am not sure I got that right but I thought NULLable FKs were deprecated..
<lifeless> al-maisan: that would sadden me
<jml> has the bugs index page for Person been updated?
<lifeless> NULLable FK usage should be a case by case choice, its more expensive to put them in link tables
<lifeless> [per item]
<lifeless> but if you have few items, putting them in the row can have an aggregately high overhead *depending on the DB engine*
<lifeless> I have to admit, I haven't dug deep enough into postgresql to know if it has variable length row storage; I would rather assume it does - most db's end up doing that
<al-maisan> maxb and wgrant, cool down a bit :) when it comes to database schema modeling there is no absolute and conclusively proven superior way of doing things :) modeling decisions are more often than not influenced by taste, preferences, previous experience etc.
<maxb> al-maisan: I'm not heated :-). I just want to understand why some people might dislike nullable FKs
<al-maisan> maxb: great :)
<stub> and beer. never underestimate the impact of beer on schema design.
<al-maisan> I guess it depends on the dba :)
<lifeless> beer & pizza
<bigjools> FTR, I don't dislike nullable FKs, but I like to avoid them
<bigjools> that's just my preference :)
<bigjools> stub: does that mean if we give you beer, you do all our schema design?
<stub> will code sql for beer
<stub> speaking of beer... and tacos...
 * stub buggers off
<sidnei> 1-internal
<henninge> jml: Did you ever find out what was behind that lp_db build failure this morning?
<henninge> jml: I am seeing the same kind of failures in my (devel-based) branch now
<henninge> mrevell: I have linked to this wiki page from thte home page: https://help.launchpad.net/StagingServer
<henninge> mrevell: I had not found any information like this  on the wiki. Do you know of any, that could be moved here?
<mrevell> henninge: We do have a page that covers that. Obviously it's not easily found. Let me dig it out.
<mrevell> henninge: Took me a while to find because it's actually part of another page: https://help.launchpad.net/GetInvolved/BetaTesting
<mrevell> henninge: thanks for creating the StagingServer page, I'll flesh it out.
<jml> henninge, no, I didn't
<jml> flacoste, hi
<flacoste> hi jml!
<flacoste> skype?
<jml> flacoste, yep, loading now.
<gary_poster> BjornT: hey.  I can talk whenever you are ready.
<henninge> mrevell: cheers!
<BjornT> gary_poster: cool, i'll call you in a minute
<gary_poster> BjornT: great
<mrevell> henninge: I imagine it's too late to make the staging server help link a help pop-up in time for 3.0, right?
<henninge> mrevell: how much work is that?
<henninge> mrevell: I am actually not sure how such a pop-up looks like ...
<mrevell> henninge: It's *really* easy. https://dev.launchpad.net/PopUpHelp
<mrevell> henninge: Acutally producing the help pop-up text would take, say, ten minutes. I could prepare a branch now but I suppose it depends if bac think it's rc worthy.
<bac> mrevell: this is for the front page?
<mrevell> bac: Yeah. I think the staging server help link would be less disruptive to potential users if it were one of our spangly help pop-ups, rather than a link to the help wiki.
<bac> mrevell: i would be ok with that if henninge has the time and can knock it out shortly.
<mrevell> bac: I can do it now. It'll take me twenty minutes to produce the branch, so long as I wouldn't be stepping on henninge's toes.
<bac> mrevell: y'all work that out.
<bac> mrevell: +1 in theory
<mrevell> :) let me know henninge
<mrevell> thanks bac
<henninge> mrevell: go ahead, I would probably not be that quick.
 * mrevell engages fingers
<henninge> mrevell: I am not working on the home page any more, so no conflicts possible.
<henninge> mrevell: happy hacking!
<mrevell> cool
<gary_poster> matsubara: sorry was on another call.  you ready now?
<matsubara> gary_poster, yes
<gary_poster> cool
<EdwinGrubbs_> Barry: im stuck in traffic, so it will be another ten minutes before i get home
<barry> EdwinGrubbs_: dang.  traffic sucks ;)  please just follow up to the standup email i just sent.  good luck ;)
<dobey> if i want to file a bug about the 'people/person/team' API, which project should i file that against?
<barry> dobey: launchpad-registry, but it's also okay to file it against launchpad and let our fine qa folks triage it to the right place
<dobey> barry: ok, thanks
<flacoste> jml, i think your tag cloud issue has been identified already: bug 433892
<mup> Bug #433892: Tag cloud useless with many unpopular tags <ubuntu-qa> <ui> <Launchpad Bugs:In Progress by intellectronica> <https://launchpad.net/bugs/433892>
<jml> flacoste, yeah, I thought so :)
<intellectronica> jml, flacoste: i have just asked bac to approve a fix for r-c
<flacoste> jml: the registration infos is not on the list though
<bigjools> noodles775: I think you fixed this? https://bugs.edge.launchpad.net/launchpad/+bug/391208
<mup> Bug #391208: would like to have the cancel redirect on edge. home page <Launchpad itself:New> <https://launchpad.net/bugs/391208>
<noodles775> bigjools: yup... thanks.
<bigjools> or it's a dupe
<matsubara> jamalta, hi, around?
<jamalta> matsubara: yeah, i don't understand why yous aid to drop blueprints
<matsubara> jamalta, because it's not used in that context. there's no category named blueprints AFAICT
<matsubara> jamalta, it's called specs, which is already in the sort dict
<matsubara> jamalta, doing: sort = {'code': 0, 'bugs': 1, 'specs': 2, 'translations': 3, 'answers': 4, 'soyuz': 6} should fix it for good
 * matsubara doesn't know how to count
<matsubara> ort = {'code': 0, 'bugs': 1, 'specs': 2, 'translations': 3, 'answers': 4, 'soyuz': 5}
<jamalta> matsubara: oh! ok, i completely missed that sorry
<jamalta> i think i added blueprints before i realized that there were karmacategories while i was trying to figure out the issue
<jamalta> and then didn't realize that specs was the blueprints tab
<jamalta> i will get that fixed shortly
<jamalta> well it will be a few hours, i'm setting up launchpad all over since this is a different computer :\
<matsubara> jamalta, thanks. let us know in the bug report when you have it ready. unfortunately it won't make the 3.0 release, but can be landed first thing next monday
<matsubara> jamalta, take your time. trunk and db-devel are closed for landings not release critical
<jamalta> matsubara: i saw that on the bug report, it's no big deal.. it's taken me like a month to get this small issue actually done :(
<jamalta> matsubara: thanks for your input and i will update the ticket when the fix is commited
<matsubara> jamalta, well, you probably ended up learning a lot about LP and that's what counts :-)
<matsubara> thank you jamalta
<jml> hey
<jamalta> matsubara: haha yeah, a ton! writing the test for that was a big challenge but very helpful
<matsubara> cool!
<jml> beuno has just come through with a visual design for the home page from our designer guy
<jamalta> so 3.0 is erleasing tomorrow? that's very exciting
<jml> it's pretty simple, and would very much improve the 3.0 release -
<jml> anyone keen to actually implement it?
<barry> salgado, bac, EdwinGrubbs, sinzui i'm going to work on some 3.0 qa.  if you do to, please edit the item when you start to add a "* Tested by:" so we don't duplicate our efforts
<bac> barry: good idea
<gary_poster> bac: lib/canonical/launchpad/templates/sources-list.pt is still not converted.  It's a code template but I didn't get a response from them last week when I tried to get a taker on IRC, and then I didn't follow up. :-(  Should I try to get it in 3.0, or not bother?  (If so, I would try again to get a code guy to do it, and failing that I would try to get a code guy to direct/help me.)
<bac> gary_poster: if you have time please go for it.  if you don't, open a bug and assign it to abentley or rockstar`
<gary_poster> bac: got it thank you.
<rockstar`> gary_poster, bac, that's the branch that I got RC'd yesterday.
<bac> gary_poster: i guess you should open a bug and add it to CRB either way
<rockstar`> Unfortunately, it failed tests.
<bac> rockstar`: win!
<bac> rockstar`: boo
<gary_poster> rockstar: oh ok.  thanks and boo.  let me know if I can help.
<bac> rockstar:  is it on CurrentRolloutBlockers?  if not could you add it
<rockstar> gary_poster, just need to fix the tests and it's in.
<rockstar> bac, sure.
<gary_poster> ok
<kfogel> Hey, https://bugs.edge.launchpad.net/ubuntu/+source/glipper/+bug/432906 is marked as a dup of bug #216155, but (except for the comment at the bottom) it's very hard to see this.  For example, the "this is a dup of..." stuff near the bug title appears to be gone, and the notice on the upper right is not a link (!) to the real bug.
<mup> Bug #432906: glipper crashed with ImportError in <module>() <amd64> <apport-crash> <glipper (Ubuntu):New> <https://launchpad.net/bugs/432906>
<kfogel> Is this a deliberate interface choice?
<james_w> it is a link for me?
<kfogel> james_w: you're on https://bugs.edge.launchpad.net/ubuntu/+source/glipper/+bug/432906 and looking at the "Duplicate of bug #216155" text in the upper right, right beneath "this report is public"?
<mup> Bug #432906: glipper crashed with ImportError in <module>() <amd64> <apport-crash> <glipper (Ubuntu):New> <https://launchpad.net/bugs/432906>
<james_w> yes
<james_w>       <span id="mark-duplicate-text">Duplicate of
<james_w>       <a style="margin-right: 4px" href="/bugs/216155"
<james_w>          id="duplicate-of"
<james_w>          title="glipper crashed with ImportError in &lt;module&gt;()">bug #216155</a>
<kfogel> james_w: they made it public while I was asking this question, it turns out.
<james_w> ah
<james_w> it's not linked if you can't see it
<james_w> that seems a bit wrong to me
<kfogel> right
<james_w> putting (private) or something would help
<kfogel> james_w: the question is very complicated; I'm writing up a summary right now.  Maybe it'll result in a new bug being filed!
<james_w> not being linked doesn't instantly make you think "private!" so you would have to copy and paste the bug number to be told that
<jml> anyone want to make the homepage awesome? we've got a great visual design that we'd love to apply
<beuno> jml, did someone get assgined to the home page prettifyingness?
<jml> beuno, no. :(
<jml> beuno, I asked earlier, but no one responded.
<jml> and I've been on calls so haven't been able to hassle more
<beuno> jml, did you ask noodles775?
<jml> beuno, yes. but sadly it came too late in his day.
<beuno> he's usually the super awesome guy that fixes everything
<beuno> jml, and you're saying that barry should pick that up then?
<jml> beuno, I think that's what I'm saying, yes :P
<beuno> I agree
<beuno> barry would be perfect for that
<beuno> and sinzui even agrees
<beuno> so it's just a matter of him looking at IRC
<beuno> and then it's official
<jml> barry, hi
<barry> jml, beuno hi.  reading scrollback
<beuno> barry, I got a design for the home page
<barry> jml, beuno wasn't someone working on the home page redesign?
<beuno> pretty images
<beuno> barry, yes, henninge
<beuno> he did the layout
<beuno> but now we need it to be pretty
<beuno> and I have an image
<beuno> that needs to be mimicked
<beuno> it's pretty easy
<beuno> like 5 minutes
<beuno> 6 tops
<beuno> in fact, it's in your email
<barry> dude, i will give you 7.  if it goes over that, you owe me big time
<deryck> I get nervous when beuno says "5 minutes" ;)
<jml> haha
<barry> :)
 * beuno goes find a loan to pay back barry all the time he will owe
<matsubara> beuno!
<barry> beuno: y'know.  turning me on to the glomo at that pervian chicken place almost makes up for it
<matsubara> beuno, I marked one of your items as BAD in https://dev.launchpad.net/LaunchpadTestPlan/3.0
<beuno> matsubara!
<beuno> barry, ;)
<beuno> matsubara, I kind of saw that
<beuno> the problem with that bug
<matsubara> beuno, the duplicate icons are still showing up in bug pages
<beuno> is that they revive it everytime something breaks with sprites
<matsubara> ouch
<barry> beuno: speaking of which... i got your image.  i'm going to grab a quick lunch then i'll attack it
<beuno> barry, you are my hero.
<allenap> bigjools: Did you merge my blueprints branch before the test run?
<bigjools> allenap: yes, it just finished and everything passed so I am landing it shortly
<bigjools> oh ballcocks you're editing CRB
<allenap> bigjools: Top, thanks.
<beuno> matsubara, so it fixed problems elsewhere
<beuno> I'm fine with keeping it open
<allenap> bigjools: Nope, not any more.
<beuno> matsubara, if you can point me to a URL where it breaks, so I can fix it later on
<allenap> bigjools: If moin thinks so, break my lock.
<matsubara> beuno, yes, the soyuz pages are ok, but not the bug page. I asked bac if he wants an RC or if we should leave it for .10
<rockstar> intellectronica, ping
<matsubara> beuno, the bug report itself shows the bug (i.e. https://bugs.edge.launchpad.net/launchpad-foundations/+bug/423105 look in the bug attachments portlet :-)
<mup> Bug #423105: Duplicate download icons in many places <Launchpad Foundations:Triaged by beuno> <https://launchpad.net/bugs/423105>
<intellectronica> hi rockstar
<rockstar> intellectronica, so bugs isn't using the "registering" slot for the bug index page that shows "Bug #XXX reported by..."
<rockstar> intellectronica, what template is that?  We're trying to make Code like Bugs since the "registering" slot is ugly.
<intellectronica> rockstar: tell me more about the "registering" slot. i have no idea what it is
<intellectronica> rockstar: ah. bugtask-index.pt
<jml> rockstar, I think it should be the other way around
<bigjools> allenap: who reviewed your branch?
<jml> rockstar, sinzui uploaded a patch today to fix the location of the registering slot
<rockstar> jml, really?  This is a win for me then.
<jml> rockstar, surely if it's doing the right thing, we should make Bugs more like Code
<rockstar> jml, because when it came down to it, thumper trumps rockstar
<jml> rockstar, because now bugs is doing the wrong thing and can't take advantage of an otherwise global fix
<allenap> bigjools: gmb
<bigjools> ta
<rockstar> jml, agreed.
<rockstar> sinzui, has your patch landed?
<sinzui> my patch for what?
<rockstar> sinzui, fixing the registering slot to not be ugly.
<sinzui> rockstar: I am not sure it has been reviewed been reviewed a approved
<sinzui> I am sprinting and ignoring email
<rockstar> sinzui, so you're not going to RC it?
<sinzui> rockstar: I know there is some disappointment that my branch does not fix all bad templates
<sinzui> rockstar: I cannot actively pursue an RC because I do not work for launchpad this week
<rockstar> sinzui, but it's progress though, right?
<rockstar> sinzui, ah, that's not very convenient.
<sinzui> rockstar: I can fix two tests that I know will break for project and projectgroup
<sinzui> bugs is odd
<sinzui> answers is sick
<sinzui> (not in the pleasant modern vulgar usage)
<bac> deryck: can you get someone on bug 423105 -- it is a simple fix
<mup> Bug #423105: Duplicate download icons in many places <Launchpad Foundations:Triaged by beuno> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/423105>
<deryck> bac, I can take it after lunch, unless allenap is looking for something (^^^) and wants it sooner.
<bac> rockstar: can you take sinzui's registering slot fix and shepherd it through?
<allenap> deryck: I'll take it.
<deryck> allenap, thanks!
<jml> bac, actually sinzui might be good to do that.
<jml> sinzui, ^^ ?
<sinzui> bac: rockstar: the devil and his left hand man are telling me I want to work on SSO tonight and Launchpad now
<bac> sinzui: i like those people
<bac> gary_poster: do you have time for a pretty easy fix to achieve breadcrumb consistency?
<jml> rockstar, hey
<sinzui> bac: rockstar: I will timebox an update to fix as many pages as I can to use the slot. Then ask for another review
<gary_poster> bac: lunching now, but after lunch yes
<rockstar> jml, hi
<rockstar> bac, I might be able to.  I've got a Dr's appointment soon.
<bac> gary_poster: cool, i'll write a bug
<jml> rockstar, we were going to talk about the branch page...
<jml> rockstar, but you should see the Dr. :)
<bigjools> the new bugs page seems to wrap comments prematurely
<rockstar> jml, I know I have wireless in the waiting room, so I might be able to chat before the appointment (he usually makes me wait...)
 * rockstar goes to Doctor
<beuno> bac, hi
<beuno> I need an RC
<beuno> for a very very small css tweak
<bac> hi
<beuno> it's been reviewed by jml in person
<beuno> https://pastebin.canonical.com/22398/
<bac> beuno: I trust you know what these tweaks will do.  rc=bac
<beuno> bac, thank you
<jml> beuno, what happened with centered text in overlays?
<beuno> jml, noodles said he would look into it
<beuno> bac, do I need to submit to db-devel?
<jml> beuno, hmm. noodles is gone.
<beuno> yes
<jml> bac, do you know anything about the centered text on overlays issue?
<bac> beuno: no, submit to devel until 2200Z today
<bac> jml: i do not
<salgado> sinzui, can you check my last comment on bug 434349 and tell me if the improvement in the proposed fix is good enough?
<mup> Bug #434349: Distribution series index OOPS <timeout> <Launchpad Registry:In Progress by salgado> <https://launchpad.net/bugs/434349>
<beuno> jml, bug 434519
<mup> Bug #434519: Text in overlay is now centered <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/434519>
<bac> beuno: this page https://dev.launchpad.net/UI has a link to UI/Navigation but it is broken.  do you have the URL for that page?
<beuno> bac, https://wiki.canonical.com/Launchpad/UI/Navigation
<bac> beuno: thanks
<sinzui> salgado: do you think that is enough for 6 weeks? Do you think we should remove the bug status counts from all series and +series until we have a replacement?
<salgado> sinzui, I know it will perform better than that on edge/lpnet, but without knowing how much better it's hard to answer your question.  my gut feeling is that it will be good enough
<jml> beuno, my short term memory has died...
<jml> beuno, centred text and bugs "registered by", right?
<sinzui> bac: I would like  you RC for lp:~sinzui/launchpad/link-watermark The diff is at  http://pastebin.ubuntu.com/275959/
<jml> bac, I've reviewed the code.
<sinzui> salgado: If this is a problem we can easily remove all all status counts. I want to try this because I think it make series easier to understand
<jml> anyone around from Bugs?
<salgado> sinzui, agreed.  I'll submit it for review/r-c then
<beuno> jml, yes
<bac> gary_poster: bug 434746 is the one for your post-lunch consideration
<mup> Bug #434746: Breadcrumbs are inconsistent in UI 3.0 <Launchpad itself:Triaged by gary> <https://launchpad.net/bugs/434746>
<gary_poster> bac, thank you, will do
<bac> gary_poster: the fix is easy.  the test fallout may be eye gouging.
<gary_poster> bac: ah, ok.  /me goes to see when 2200Z is...
<bac> 5:14 from now
<bac> gary_poster: after that you can still land directly to db-devel
<bigjools> allenap: your fix landed in revno 9564
<gary_poster> ah ok. thanks.  will begin after just a few more moments of repose ;-)
<allenap> bigjools: Woohoo, thank you :)
<bigjools> and now, I am ready to expire, good night
<bac> gary_poster: would you add that bug to CRB?
<beuno> mrevell, I've sent you an email of what the LP homepage will look like once barry is finished with it
<mrevell> beuno: Nice :)
<mrevell> beuno: That's a great improvement. I feel I now know where to look.
<gary_poster> bac: absolutely.  URL please?
<bac> https://dev.launchpad.net/CurrentRolloutBlockers
<mrevell> beuno: I do have a question: both in your mock-up and on edge we have a line that says "Projects related to the world's most popular...." and then just a list of normal featured projects. What's going on there?
<beuno> mrevell, that's an unfortunate description for the mysql project on Launchpad
<beuno> mrevell, we probably want to have /mysql-server instead of /mysql as a featured project
<beuno> which has a better description
<mrevell> beuno: Yeah but I don't understand why the feature project's description is coming in there ... I mean, the list of projects below it has nothing to do with MySQL (or whatever the featured project is)
<beuno> mrevell, right, so we have a design problem
<beuno> it's one bug features project
<beuno> and "others"
<mrevell> beuno: want me to file a bug?
<beuno> mrevell, I'd wait for barry to implement his changes, and then, yes
<mrevell> ok, cool
<mrevell> barry: I've just been working on a branch that may clash with your changes. It changes the "What's this?" link in the section about the sandbox to become a pop-up -- https://code.edge.launchpad.net/~matthew.revell/launchpad/home-page-staging-popup-help/+merge/12233
<mrevell> I'm bowing out for dinner. Back later on.
<barry> mrevell-dinner: okay. i'll keep an eye on that
<allenap> bac: I imagine you're very busy, but can you release-critical review two of my branches please? :) I have to go soon, so I need to send them off to ec2. They are: https://code.edge.launchpad.net/~allenap/launchpad/external-bugzilla-3.4-api-bug-434580/+merge/12230 https://code.edge.launchpad.net/~allenap/launchpad/remove-too-many-download-icons-bug-423105/+merge/12237
<bac> allenap: will do so next
<allenap> bac: Thanks.
<salgado> bac, I've added one to your r-c queue too
<bac> salgado: great.  the OOPS fix?
<salgado> bac, yep
<barry> beuno: bug 434761
<mup> Bug #434761: Make the home page pretty <story-ui-3> <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/434761>
<jml> sinzui, how's your "registered by" branch going? what was your time box?
<sinzui> jml: I have product and project fixed.
<sinzui> jml: I have bugtask broken, working on it now
<beuno> barry, awesomeness, thanks
 * barry -> reboot
<deryck> sinzui, jml -- are you guys talking about the slot where "created by" statements go?
<sinzui> deryck: Yes, I am changing it now
<deryck> sinzui, so I don't need to worry about the bug page for this then?
<sinzui> bugtask is the only location I know to change and if it is the only location, I can do this
<deryck> sinzui, yes, it's the only location.  I owe you a big frothy beer next week.  thanks!
<sinzui> deryck: np. I had to fix project and product too
<jml> sinzui, cool! please ping me when you need a review.
<sinzui> bac: I would like  you RC for lp:~sinzui/launchpad/link-watermark The diff is at  http://pastebin.ubuntu.com/275959/
<sinzui> ^ Did I miss your approval or disapproval?
<bac> sinzui: i must've missed the request.  this is the first i've seen it
<bac> sinzui: rc=bac
<sinzui> bac: thanks
<sinzui> beuno:  lp:~sinzui/launchpad/link-watermark
<beuno> jml, can I submit some else's branch with ec2
<beuno> or do i need to push it to my lp namespace
<jml> beuno, you can submit someone else's branch.
<beuno> ok, let's see how true that is
<beuno> thanks jml
<jml> beuno, just make sure your current working directory is an up-to-date branch.
<jml> beuno, I submit wgrant's branches fairly frequently.
<danilos> beuno: people have done it, make sure the submission command is correct by using --dry-run first
<jml> when I get a moment to myself (next long haul flight, perhaps), I'll finish my branch that will land a thing given only its merge proposal.
<jml> beuno, there's a bug for the homepage stuff right
<jml> bac, just added bug 434519 to CRB
<mup> Bug #434519: Text in overlay is now centered <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/434519>
<beuno> jml, beer?
<jml> beuno, I want to make sure the homepage bug is on CRB
<jml> beuno, and I want to make sure sinzui has everything he needs from me
<jml> then beer.
<beuno> sounds like a plan
<jml> beuno, do you know the bug for the homepage?
<jml> sinzui, do you have everything you need from me?
<beuno> jml, bug 434761
<mup> Bug #434761: Make the home page pretty <story-ui-3> <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/434761>
<jml> beuno, thanks.
<beuno> jml, is there any way we can verify our changes tomorrow before the rollout?
<beuno> staging maybe?
<jml> bac, will there be an edge rollout before the production rollout?
<gary_poster> flacoste: at bac's request, I am working on bug 434746.  I decided to start trying to see how breadcrumbs worked by looking at blueprints, arbitrarily.  I'm looking at lib/lp/blueprints/browser/tests/test_breadcrumbs.py in TestHasSpecificationsBreadcrumbOnBlueprintsVHost.test_product.  Right now, that will produce breadcrumbs of "Crumb Tester", "Blueprints for title7".  I was expecting to see "Crumb Tester
<mup> Bug #434746: Breadcrumbs are inconsistent in UI 3.0 <Launchpad itself:Triaged by gary> <https://launchpad.net/bugs/434746>
<gary_poster> (oops) Right now, that will produce breadcrumbs of "Crumb Tester", "Blueprints for title7".  I was expecting to see "Crumb Tester", "Blueprints for Crumb Tester"
<sinzui> jml: deryck: this is the incremental diff for my registering-header branch that makes product, project, and bug task using the registering slot.
<sinzui> http://pastebin.ubuntu.com/275996/
<gary_poster> flacoste: If I had seen that, I would have been comfortable shortening that too "Crumb Tester", "Blueprints", as I understand my task to be.  is that just a funky test?  Should I proceed?  Or is there something more subtle here?
<gary_poster> flacoste: if you don't have a sec I'll try salgado
<bac> jml, beuno: this talk of beer is very demoralizing to those of us hours behind you.
<beuno> bac, by beer we mean "more work"
<gary_poster> lol
<bac> umm, work
<bac> new from Duff
<jml> sinzui, it's good, but you need to keep the bug ID in the bug registering slot
<jml> sinzui, there needs to be a non-hyperlinked bug id on the bugs page for copy-paste winnage.
<sinzui> Other object do not use it. the *1234 is in the breadcrumbs
<gary_poster> salgado: are you around, and do you have any guidance on what I asked above?
<gary_poster> (to flacoste)
<deryck> jml, sinzui -- I don't object to losing the bug number in this time stamp.  but will differ to jml on it.
<sinzui> jml: the last breadcrumb should not be linked. That is what we want to copy and paste
<deryck> sinzui, also, technically we don't have the bits of the activity log in the comments yet, but I'm ok with removing the link, as it will force us to fix the remaining bits when people complain. :)
<jml> if there were another copy-pastable bug number on the page, I'd be fine with losing it
<jml> sinzui, it's linked on edge.
<deryck> *all* the bits of the activity log, I should say.
<jml> sinzui, see https://bugs.edge.launchpad.net/launchpad-registry/+bug/434761
<mup> Bug #434761: Make the home page pretty <story-ui-3> <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/434761>
<sinzui> jml Yes, I did not say edge or launchpad is correct, only that we did plane for this, breadcrumbs are wrong
<bac> gary_poster: allenap is landing a change soon that i noticed did the breadcrumb thing for blueprints
<salgado> gary_poster, I'll check that in a second
<jml> sinzui, ok. but let's not make it wronger.
<sinzui> deryck: What can I see in activity log that I cannot see in comments?
<gary_poster> salgado: thank you
<sinzui> jml I can but "Bug #1234 reported by" in the registering if you say so
<mup> Bug #1234: Gina is an unmaintainable mess of command line options, environment variables and shell scripts <Launchpad Foundations:Fix Released by debonzi> <https://launchpad.net/bugs/1234>
<jml> sinzui, that'd be great thanks.
<deryck> sinzui, I think the description diff for one, if changed.
<sinzui> ah
<gary_poster> bac: ok, thanks.  I guess my question stands generally, but I'll try another app and see if that is clearer, while waiting for the anser.
<gary_poster> answer
<salgado> gary_poster, title7 is the .name and 'Crumb tester' is the .displayname
<deryck> sinzui, there are a couple of other things which I'm blanking on now.  but it's okay to remove the link, I think.
<gary_poster> salgado: oh, so title7 should not really be in breadcrumbs, and change would be fine, right?
<gary_poster> ("Crumb tester", "Blueprints
<gary_poster> "
<gary_poster> )
<sinzui> deryck: is there an esay place to move the link too?
<gary_poster> allenap: poing?
<gary_poster> heh
<gary_poster> ping
<deryck> sinzui, at this point, no.  Which is why I'm cool to drop it.  where does it really belong?  I think that's the tougher question.
<sinzui> okay
<jml> sinzui, deryck: if we drop the link from the breadcrumbs, I'm fine with leaving the bug # out of the registering slot.
<salgado> gary_poster, yep.  you're just changing it to "Crumb Tester" >> "Blueprints"?
<jml> as long as we have to have a copy-pastable bug ID.
<gary_poster> salgado: right
<deryck> jml, ack.  that's cool with me.
<deryck> sinzui, is the link on our team's end, or a global thing?
<salgado> gary_poster, cool.  but did what I say answer your question or is there still something that isn't clear?
<bac> gary_poster: it should just be 'Crumb tester >> Blueprints".  that's what the branch henning (i wrongly said gavin earlier) did
<gary_poster> salgado: yes, that helped, thank you!
<gary_poster> bac: ok thank you
<salgado> np
<sinzui> deryck: The breadcrumbs fix is not your problem. We will fix that in 3.10
<sinzui> okay. We are settled on the registering line, we are dropping the link to Activity log
<bac> gary_poster: here is henninge-afk's MP: https://code.edge.launchpad.net/~henninge/launchpad/bug-434055-combined/+merge/12229
<gary_poster> bac: gotcha thanks.  yeah, that does what I was looking at
<sinzui> beuno: lp:~sinzui/launchpad/registering-header
<flacoste> gary_poster: sorry, i was on the phone
<gary_poster> flacoste: cool np, handled thank you
<salgado> gary_poster, ain't that bug a dupe of bug 434403?
<mup> Bug #434403: breadcrumbs use inconsistent context names <ui> <Launchpad itself:New for beuno> <https://launchpad.net/bugs/434403>
<flacoste> gary_poster: i'd suggest you look at Translations, since they seem to have the "best" breadcrumbs so far
<flacoste> gary_poster: ok, i see that salgado jumped in
<gary_poster> salgado: yes, marking, thanks
<sinzui> bac may I have your RC for http://pastebin.ubuntu.com/276013/ that jml and beuno have looked at
<bac> sinzui: why was the special IE 7 support removed?  is it no longer a problem?
<sinzui> bac: no, 3.0 does not use tab art. we should have removed this a few weeks ago
<salgado> bac, https://bugs.edge.launchpad.net/launchpad/+bug/434234 <-- not nice
<mup> Bug #434234: Timeout rendering downloads page <Launchpad itself:New> <https://launchpad.net/bugs/434234>
<bac> salgado-lunch: gah, first i've seen of that
<salgado-lunch> bac, although that's not really a problem introduced in this release
<salgado-lunch> really out now; back soon
<bac> sinzui: rc=bac.  thanks for the fix
<gary_poster> bac, fwiw, I've seen that one mentioned on the zope list as a reason to not use LP for hosting downloads
<gary_poster> 434234 I mean
<bac> gary_poster: ah, zope has a ton of product releases
<jml> ok. I'm off for the evening.
<gary_poster> yeah
<jml> good luck!
<bac> gary_poster: i think we've tried to address those before
<bac> jml: have a good evening. thanks for your help today.  (and every day)
<jml> bac, thanks for the great RMing.
 * beuno is off as well
<jml> np :)
<bac> gary_poster: another reason to use zope3
<gary_poster> lol
<bac> https://edge.launchpad.net/zope/+download
<bac> "The new Zope 3 component architecture won't crash your download page."
<gary_poster> heh
<bac> gary_poster: https://edge.launchpad.net/zope2/+series  !!!
<bac> it's not very useful but it is soothing
<gary_poster> bac: yeah, that's what they were talking about.  Yes, doctor, I like all the pretty polkadots...
<gary_poster> ...Yes, doctor, I like all the pretty polkadots...
<gary_poster> etc.
<gary_poster> bac: interesting that you can drag the image to see the far reaches
<Ursinha> hi rockstar and abentley
<abentley> Ursinha: hi
<Ursinha> abentley, hi, have you tested the fix for bug 426779, still pending in Code's test plan?
<mup> Bug #426779: Error when sending mail to a code review for source package branch <package-branches> <Launchpad Bazaar Integration:Fix Committed> <https://launchpad.net/bugs/426779>
<abentley> Ursinha: Yes, I thought I'd moved it to OK.
<Ursinha> abentley, I can do that, thanks for the information
<abentley> Ursinha: Cool.
<Ursinha> jml, are you around?
<abentley> Ursinha: jml lives in London now, so he might not be.
<abentley> Ursinha: And since he's no longer on the code team, I think rockstar's doing his testing.
<Ursinha> abentley, this is valuable information as well :)
<Ursinha> but rockstar doesn't love me anymore, he doesn't reply my pings
<Ursinha> :)
<abentley> Ursinha: He has tonsilitis.  Last I spoke with him, he was going to the doctor.
<Ursinha> gee.
<Ursinha> rockstar, hope you get better soon
<Ursinha> thanks abentley
<Ursinha> I guess I'll have to have a late chat with thumper and mwhudson then :)
<rockstar> Ursinha, good timing.  I'm back.
<Ursinha> hey rockstar, how are you?
<rockstar> Ursinha, well, alright given the circumstances.
<Ursinha> rockstar, hope you get better soon... you may want to rest now
<rockstar> Ursinha, re: QA, I'm planning on doing jml's as well, but I have to get an RC in.
<Ursinha> rockstar, the rc is about what?
<rockstar> Ursinha, some changes to the branch-index page.
<Ursinha> rockstar, a bug?
<rockstar> Ursinha, not yet...
<Ursinha> rockstar, just tell me the problem and I can file one :)
<rockstar> Ursinha, there are a few, that's the thing.
<Ursinha> rockstar, only one RC is enough to fix them all?
<rockstar> Ursinha, yeah, they are all little things.
<Ursinha> rockstar, let me give you a start
<Ursinha> rockstar, bug 434830, you can fill in the blanks :)
<mup> Bug #434830: Some changes to the branch-index page needed <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/434830>
<rockstar> Ursinha, thanks.  :)
<Ursinha> rockstar, np :)
<Ursinha> rockstar, so I'll make a note in the test plans saying you'll test the items after getting your rc
<Ursinha> rockstar, thanks :)
<gary_poster> bac, deryck, intellectronica, we are in testfix with a bug in bugs: looks like intellectronica's at first blush https://lpbuildbot.canonical.com/builders/lp/builds/169/steps/shell_7/logs/summary
<bac> gary_poster: you're right that is intellectronica
<bac> 's
<bac> rockstar: rc=bac -> db-devel
<bac> gary_poster: could i ask you to land a [testfix]?  i'll review it
<deryck> bac, gary_poster -- I can work on a fix for intellectronica's branch if no one is on it yet.
<bac> gary_poster: the narrative for that test doesn't even match the output
<bac> deryck: that would be great
<gary_poster> bac: I have to go pick up my son, will be back around 4
<gary_poster> deryck: thank you
<bac> gary_poster: nm
<deryck> will start now
<rockstar> bac, okay, so we closed devel then?  How do I ec2test against db-devel?
<bac> rockstar: dunno!
<gary_poster> rockstar: ./utilities/ec2 test -b launchpad=db-devel
<bac> rockstar: i was going to say "ask gary"
<rockstar> gary_poster, fank you
<gary_poster> heh, np
<bac> gary_poster: i'll shoot an email to the list quoting you
<gary_poster> cool
<bac> rockstar: devel isn't closed yet, but if you submit through ec2 it'll be closed by the time it gets there.  and, please do go via ec2
<gary_poster> bac, rockstar: that tests against db-devel
<rockstar> bac, yeah, I don't even do non-rc branches without ec2 - utter craziness.
<rockstar> gary_poster, does that submit against db-devel as well?
<gary_poster> not sure about submitting, actually, looking (my submit message was hosed anyway so I didn't look)
<bac> gary_poster: so we don't know the complete magic?
<gary_poster> rockstar, bac: according to the helptext, what I said is right:
<gary_poster>   --pqm-submit-location=ARG
<gary_poster>                         The submit location for the pqm submit, if a pqm
<gary_poster>                         message is provided (see --submit-pqm-message).  If
<gary_poster>                         this option is not provided, the script will look for
<gary_poster>                         an explicitly specified launchpad branch using the
<gary_poster>                         -b/--branch option; if that branch was specified and
<gary_poster>                         is owned by the launchpad-pqm user on launchpad, it is
<gary_poster>                         used as the pqm submit location. Otherwise, for local
<gary_poster>                         branches, bzr configuration is consulted; for remote
<gary_poster>                         branches, it is assumed that the submit branch is
<gary_poster>                         bzr+ssh://bazaar.launchpad.net/~launchpad-
<gary_poster>                         pqm/launchpad/devel.
<gary_poster> (sorry)
<bac> cool
<gary_poster> so just -b launchpad=db-devel .  after that IRC faux pas, I will go hide my head in shame and pick up my son :-)
<gary_poster> biab
<rockstar> gary_poster, laughing hurts.  Please don't do that again.
<rockstar> :)
<deryck> bac, for testfix -- http://pastebin.ubuntu.com/276059/
<bac> deryck: why the ...
<bac> aren't  two unofficial ones imporant?
<bac> "aren't the unofficial ones important" i meant
<deryck> bac, nope, I don't think so.  the test is just to demonstrate that all official tags are found in a cloud.
<deryck> bac, but honestly, it
<deryck> it's not completely clear to me.
<deryck> the documentation part I mean.  But as I read it, it's just for official tags.
<bac> yeah but some unofficials are spit out too.  i thought it was supposed to be the top ten unofficial
<bac> deryck: i'd like to see this well tested b/c that code was pretty dense
 * deryck looks closer at the test
<allenap> deryck: I reviewed intellectronica's branch for this, but didn't ask about tests :( The test result at https://lpbuildbot.canonical.com/builders/lp/builds/169/steps/shell_7/logs/summary looks correct.
<bac> allenap: right, all official plus top ten unofficial
<allenap> bac: Yep.
<bac> that's why i don't want it hidden by ellipeseieses
<deryck> bac, allenap -- bac is right, this section that is failing, is just adding 10 official and 10 unofficial tags and printing them from the browser.open read.
<bac> no
<bac> all official plus 10 unofficial
<deryck> bac, I'll undo the elipsssess
<bac> sssweet
<deryck> bac, and yes, what you said about all official vs unofficial.  I'm going to update the doc part to make this clearer.
<bac> deryck: after it all passes locally submit to devel with [testfix][release-critical=bac][r=bac]
 * bac shudders to think of devel closing in [testfix]
<gary_poster> henninge-afk: ping: deryck is working on the testfix
<deryck> bac, updated diff: http://pastebin.ubuntu.com/276064/
<henninge-afk> gary_poster: ah, cool
<gary_poster> henninge: sent it to you in email too for added confirmation ;-)
<henninge> gary_poster: cool
<deryck> henninge, sorry I didn't reply on email as I took it.  Just noticed on IRC here when gary_poster pinged.
<henninge> deryck: I have a branch playing in ec2 that failed on this.
<deryck> bac, gary_poster, henninge -- submitted the fix to pqm just now.
<gary_poster> deryck: awesome thank you very much
<henninge> deryck: cool
<deryck> oh, crap, think I borked the commit message form.
<deryck> too many freakin' brackets
<bac> henninge: if you go through ec2 again be sure to see my email
<henninge> bac: it is almost through, started it 3 hours ago.
 * henninge looks for mail
<bac> henninge: yeah but won't it die?
<henninge> bac: ?
<henninge> bac: no, it will just not submit to pqm
<bac> henninge: oh, i see
<henninge> bac: so, I fix whatever test failed, test that and pqm-submit ... ;-)
 * deryck says "yay!" for the correct number of brackets
<bac> henninge: right
<deryck> gah
<deryck> so maybe not
<deryck> bac, gary_poster -- what am I doing wrong?  Doing:  bzr pqm-submit -m "[testfix][release-critical=bac][r=bac][ui=none] Fix a broken tag cloud test."
<gary_poster> deryck: the email from pqm should tell you what the regex is
<bac> deryck: what's the error
<deryck> gary_poster, bac -- All lines of log output:'Commit message [[testfix][release-critical=bac][r=bac][ui=none] Fix a broken tag\n\tcloud test.] does not match commit_re [(?is)^\\s*\\[testfix\\]\\s*\\[(?:release-critical|rs?=[^\\]]+)\\]]'
<deryck> drop the UI part?
<bac> try it
<bac> gary_poster: couldn't we teach PQM to process it using optparse?
<bac> or something more sane
<henninge> deryck: I feel for you, I had a similar experience yesterday ...
<henninge> but the message looks right to me ...
<gary_poster> deryck, bac: [testfix][release-critical][r=member:bac][ui=none] Fix a broken tag cloud test."
<gary_poster> (not =bac
<gary_poster> )
<gary_poster> for the release-critical
<deryck> ah
<bac> gary_poster: so the regex for testfix is broken/different from normal
<gary_poster> yup, looks like it
<bac> no, i think that is about the same
<bac> flacoste is the master of deciphering these
<gary_poster> bac, well, this message passed when we were not in testfix: "[release-critical=bac][r=allenap][ui=none][bug=433892] in the tags ..."
<flacoste> yes, that should work
<gary_poster> (from bottom of https://lpbuildbot.canonical.com/builders/lp/builds/169)
<gary_poster> flacoste: the problem is that this does not work:
<gary_poster> "[testfix][release-critical=member:bac][r=member:bac][ui=none] Fix a broken tag cloud test."
<gary_poster> flacoste: the regex now shows that it should be [testfix][release-critical][r=member:bac%5D%5Bui=none] Fix a broken tag cloud test."
<gary_poster> bah
<deryck> ok, seems to be running now.  I think I got it.
<bac> deryck: what did you use?
<gary_poster> anyway, the release-critical is the different part, flacoste
<henninge> don't be fooled ...
<deryck> [testfix][release-critical][r=bac][ui=none] Fix a broken tag cloud test.
<deryck> henninge, that's why I wrote "I *think* I got it" :)
<deryck> it's still in the queue, so I assume working.  Still cleaning working directory.
<henninge> :)
<henninge> that means nothing ...
<henninge> I tried 4 times yesterday.
<henninge> Sometimes instant rejection,
<henninge> sometimes not.
<henninge> Or maybe that was when I tried to submit to devel and it wasn't open ...
<deryck> bac, looks like I'm in, but I'll give it another 10 minutes to make sure.  then I must be off for a bit for family stuff.
<mwhudson> good morning
<deryck> morning, mwhudson
<bac> deryck: cool
<barry> bac: ping
<bac> hi barry
<barry> bac: hi.  beuno is not around and i've done about the best i can on the home page given the time constraints.  would you take a look at the screen shots and tell me what you think?
<barry> bac: they are not perfect, but i think it's better than it was
<bac> barry: sure
<barry> bac: http://people.canonical.com/~barry/home1.png and http://people.canonical.com/~barry/home2.png
 * bac happy pandora is playing The Reivers!!
<bac> barry: i don't like the green scroll bar
<barry> bac: for comparison, beuno's mockups are attached to bug 434761
<mup> Bug #434761: Make the home page pretty <story-ui-3> <Launchpad Registry:In Progress by barry> <https://launchpad.net/bugs/434761>
<barry> bac: you dissin' my theme? :)
<barry> bac: that's baby turtle man!
<bac> so the ones you have in the bug are mockups?
<barry> bac: right, they are the ones beuno sent me
<barry> bac: i got close as i could
<bac> barry: and the featured project list is only one column for lp.dev?
<barry> bac: beuno did not have a "logged-in" mockup but i think that's the way it should be
 * barry wishes beuno were still here
<bac> barry: i think it looks much better
<barry> bac: subject to code review is it worth an rc?
<bac> barry: is there any reason you can't land it tomorrow?  <can't believe i'm saying that>
<barry> bac: iow, you want me to wait until tomorrow?
<bac> barry: i'm just saying if you shot it to martin tonight you'd have an answer by the time you woke up
<bac> barry: and with his consent i'd speed an RC approval
<barry> bac: sounds good.  i'll push the branch, get a code review and request martin's ui review.  thanks
<bac> barry: OTOH it is demonstrably an improvement and gets us closer
<barry> bac: you're the rm!  you get to decide :)
<barry> either way is fine with me
<bac> land it tonight! and we can tweak tomorrow
<bac> barry:  see if you can find a code reviewer
<barry> bac: +1, thanks
<bac> np
<thumper> morning
<bac> hi thumper
<thumper> bac: we need to land bzr 2.0 final
<thumper> bac: there are no real code changes
<thumper> bac: what is required is landing the 2.0 tar ball into the dependencies branch
<thumper> bac: then updating versions.cfg
<bac> thumper: hi
<bac> thumper: will there be any operational consequences?
<thumper> bac: should be zero
<bac> thumper: you make it sound like two steps.  is it?
<thumper> bac: the commit to the dependencies is effectively a no-op
<bac> thumper: or two parts of the same branch.
<bac> ok
<thumper> bac: it is bzr add; bzr commit
<bac> thumper: got it.
<bac> thumper: ok.  rc=bac.  will you be doing it within the hour?
<thumper> yes
<thumper> bac: still needs to go through ec2 though right?
<bac> thumper: sure.  so, target it to db-devel
<thumper> ack
<thumper> abentley, rockstar, mwhudson: stand up will be as soon as I submit the bzr 2.0 branch
<mwhudson> thumper: ok
<abentley> thumper: roger
<rockstar> thumper, I can sit in on the standup, but you I can't really participate.  I sent you my notes.
<thumper> rockstar: sure
<thumper> mwhudson: skype?
<mwhudson> thumper: i'm online
<thumper> rockstar: sitting in or out?
<thumper> mwhudson: my skype can't connect to you
<thumper> mwhudson: can you try calling me first?
<mwhudson> thumper: i'll restart
<mwhudson> thumper: see me now?
<rockstar> thumper, I can sit in.
<rockstar> thumper, there isn't
<rockstar> I'd be glad to help you out though, if you'd like.
<EdwinGrubbs> barry, bac, salgado-afk: I just checked and saw that there are 32 NEEDSTESTING for 2.2.8 and 36 NEEDSTESTING for 3.0. That's 17 per person. Are any of the changes higher priority for testing, since I doubt we'll get to them all?
<barry> EdwinGrubbs: i haven't looked in several hours
<bac> EdwinGrubbs: just use your best judgment about which ones might have high impact if BAD
<bac> EdwinGrubbs: or knock down the ones that you can do very quickly
<barry> EdwinGrubbs: i need to take a short break to clear my head, but i will come back to do more qa in a bit
<bac> i'll do some more later
<barry> bac: ec2 is playing the branch
<bac> barry: good
<bac> thumper: add your bzr update branch to https://dev.launchpad.net/CurrentRolloutBlockers
<thumper> bac: ok
<bac> tahnks
<barry> bac: ah shit.  i forgot to go headless.  hopefully my net connection will stay up :/
<bac> wow
<barry> anyway, if not, i'll resubmit
<bac> barry: that's why i use an alias...
<barry> bac: yeah, i have that but not for db-devel ;)
<barry> bac: i'm killing it and restarting. would hate for it to run for 2 hrs and then die
<barry> done
 * barry -> away
<wgrant> The global actions portlet really has a lot of margin...
<EdwinGrubbs> bac, sinzui, barry, salgado-afk: do any of you know if the blueprints/$project/+index and the blueprints/$person/+index pages have been converted in a branch that hasn't made it to edge yet. I thought sinzui had one, but bug 397862 just converts the $person/+specworkload.
<mup> Bug #397862: Move blueprint templates to lp.blueprints <story-apocalypse> <Launchpad Registry:Fix Committed by sinzui> <https://launchpad.net/bugs/397862>
<barry> EdwinGrubbs: http://people.canonical.com/~beuno/conversions.html#blueprints implies they have
<bac> barry, EdwinGrubbs: the unconverted ones have been done and are working their way through
<barry> cool
<mwhudson> flacoste: you there for a quick question?
#launchpad-dev 2009-09-23
<thumper> mwhudson: https://code.staging.launchpad.net/+code-imports/+machines/marambio - what is ment by job reclaimed automatically?
<thumper> mwhudson: the git imports are failing to start even
<thumper> mwhudson: ideas why?
<mwhudson> thumper: reclaimed automatically means that the heartbeat wasn't update for $N minutes
<mwhudson> thumper: no, i can look on the slave though
<mwhudson> thumper: trying with that import is pretty ambitious :)
<mwhudson> i guess it should show the 2a improvements most...
<mwhudson> thumper: it's failing to connect to the database
<mwhudson> thumper: which translates to spm heeeeeeeeeeeeeeeeelp!
<thumper> mwhudson: I was wanting to check the 2a improvements
<thumper> mwhudson: which explains why we aren't getting updates I suppose
<mwhudson> thumper: yeah
<mwhudson> thumper: it's the usual reason for this problem
<thumper> which is?
<mwhudson> thumper: database connection issues
<mwhudson> thumper: sorry, unclear
<thumper> hmm...
<mwhudson> "every import gets reclaimed without any heartbeats" --> "it's probably a connection to the database" issue
<mwhudson> thumper: why the database connection setup has bitrotted i don't know
<mwhudson> thumper: needs a losa
 * thumper looks around for a losa
<mbarnett> thumper: what can i do for you?
<mwhudson> mbarnett: importd@marambio should be able to connect to the staging database as 'codeimportworker'
<mwhudson> mbarnett: it seems it can't
<mwhudson> mbarnett: can you look at the various configs and try and figure out why?
<mbarnett> mwhudson: i can take a look, sure
<mwhudson> mbarnett: thanks
<thumper> mwhudson: I might get you to poke strawberry as we don't seem to be getting any log updates from the running git imports
<thumper> mwhudson: or has the db not been updated yet?
<mwhudson> thumper: same issue i bet
<thumper> mbarnett: can you let us know when you are done?
<thumper> perhaps I'm just too eager
<mbarnett> thumper: yup, looks like it should be working, having a hard time seeing why it is not
<thumper> mwhudson: what do we need to get copied from production to confirm that we aren't going to auto upgrade?
<mbarnett> thumper: will let you know when i figure it out
<mwhudson> thumper: different log message slightly:
<mwhudson> 2009-09-22 23:23:19 ERROR   psycopg2.OperationalError: FATAL:  no pg_hba.conf entry for host "91.189.89.46", user "codeimportworker", database "lpmain_staging", SSL off
<mwhudson> (for strawberry)
<mwhudson> mbarnett: could it be an issue trying to connect to the slave vs the master?
<thumper> mwhudson: we could copy across a working git import, confirm that it isn't getting upgraded
<mwhudson> thumper: yeah
<thumper> mwhudson: then perhaps delete it again to test our git upgrade strategy
<mbarnett> mwhudson: it certainly could be
<mwhudson> thumper: you could copy dulwich and test the fix for rebased imports while you're at it :)
<spm> mwhudson: I saw that.... ^^ :-)
<mwhudson> spm: you can help mbarnett help us if you like!
<spm> provide moral support?
<mwhudson> would you believe that the thing that's stopping me testing my blank ami -> ec2test ami script is keyserver.ubuntu.com being lame?
<lifeless> yes
<lifeless> can you use subkeys.pgp.net?
 * wgrant wonders why people aren't pointed at the pool instead.
<mwhudson> lifeless: probably
<mwhudson> lifeless: that seems to be being lame too though :/
<thumper> wgrant: how do you point at the pool?
<wgrant> thumper: pool.sks-keyservers.net
<thumper> wgrant: ta
<mwhudson> wgrant: thanks
<mwhudson> mbarnett, spm: any progress?
<mbarnett> mwhudson: we are talking through it now
<mwhudson> cool
<thumper> mwhudson: I'm trying to test the upgrade of stacked branches
<thumper> mwhudson: we still have an issue that when it is upgraded we don't remirror don't we
<thumper> mwhudson: actually, can I have a call?
<mwhudson> thumper: yeah, i think so
<mwhudson> thumper: 1 min for call
<mbarnett> mwhudson: care to give it a shot real quick.. just reloaded the configs
<thumper> mbarnett: I'll look at it
<mbarnett> thumper: thanks
<thumper> mbarnett: we may need the current jobs to time out
<thumper> mbarnett: I'll let you know in about 3 minutes
<mbarnett> thumper: kk
<thumper> spm: can you tell me which branches we have copied to staging for bzr testing?
<mwhudson> thumper: call when you want
<thumper> mwhudson: ta
<spm> thumper: the easiest way is to paste the script used: https://pastebin.canonical.com/22435/ mix of bzrtools, drizzle, etc
<mbarnett> thumper: we are closing in on the issue.. hopefully have it resolved very soon
<thumper> spm: the branch rewrite seems bad
<thumper> spm: was apache gracefulled when the rollout happened?
<mwhudson> mbarnett, spm: can one of you graceful apache on tellurium?
<spm> thumper: nope, is now.
<spm> that's always been one weak link in the auto rollouts to staging in particular, is gracefulling apache....
<mbarnett> thumper: mwhudson: we are back in business on marambio
<mwhudson> mbarnett, spm: it now seems that marambio can't upload to the staging librarian
<mwhudson> canonical.librarian.interfaces.UploadFailed: [asuka.canonical.com:58090]: (110, 'Connection timed out')
<mwhudson> mbarnett, spm: fixable?
<spm> mwhudson: only with the magic word
<mwhudson> spm: NOW!!!!
<spm> heh
<spm> mwhudson: while we have attention focused on the import slaves - any preferrred retention for the old worker logs 2-3 weeks?  a  month?
<mwhudson> spm: a month perhaps?
<spm> staging as in - prod is already covered at 3 months from memory.
<spm> cool. ta.
<Ursinha> mwhudson, do you know if it's possible to see a list of branches associated to a bug via lplib? or just to link/unlink?
<mwhudson> Ursinha: no idea i'm afraid
<Ursinha> hehe
<Ursinha> I'd ask rockstar but I guess he's not around
<Ursinha> thanks mwhudson
<mwhudson> Ursinha: bug.linked_branches?
<Ursinha> mwhudson, I see just the inverse, branch.linked_bugs_collection_link
<mwhudson> Ursinha: it's marked as exported in the ui
<Ursinha> at least in the apidocs
<mwhudson>     linked_branches = exported(
<mwhudson>         CollectionField(
<mwhudson>             title=_('MultiJoin of the bugs which are dups of this one'),
<mwhudson>             value_type=Reference(schema=IBranch),
<mwhudson>             readonly=True))
<mwhudson> s/ui/interface/
 * Ursinha tries
<Ursinha> mwhudson, the title is weird
<mwhudson> Ursinha: yes
<thumper> spm: can you let me know when the code import -> librarian issue is fixed?
<spm> thumper: aye. just needing a firewall fix in place
<mwhudson> spm: more generally, how can we make sure that our staging set up doesn't bitrot like this?
<mwhudson> bazaar_branch_store: sftp://supermirror@tellurium/home/supermirror/importd-push-branches
<mwhudson> foreign_tree_store: sftp://supermirror@tellurium/home/supermirror/foreign-trees
<mwhudson> thumper: ^
 * mwhudson lunches
 * thumper lunches
<spm> mwhudson: the librarian ports the staging importds talk to - obviously 58090, but any of the others?
<mwhudson> spm: i don't know which ports the librarian listens on
<mwhudson> spm: all it does is upload log files though, so it's probably just that
<spm> thumper: mwhudson: watching now to verify the fix...
<thumper> kk
<spm> 2009-09-23 01:49:31 INFO    Uploaded logs to librarian https://staging.launchpadlibrarian.net/32141237/tasky-master-log.txt. <== looks good
<thumper> hey got a log file
<thumper> still failing though
<mwhudson> spm: guess what
<thumper> spm: Unable to connect to SSH host tellurium; EOF during negotiation
<mwhudson> spm: marambio needs to be able to connect to tellurium:22
 * spm puts head in hands and cries a little
<thumper> spm: and strawberry
<mwhudson> spm: https://wiki.canonical.com/InformationInfrastructure/OSA/LPHowTo/SetUpCodeImportSlave may be worth reading over?
<spm> RTFM!?!?! never!
<mwhudson> though it doesn't talk about stagin stuff
<spm> an oversight I shall be correcting; never fear.
<spm> mwhudson: tellurium 22? or 922? the trace suggests 922?
<mwhudson> spm: oh right, probably 922 indeed
<spm> kk
<mwhudson> spm: is the 922 specified in ~importd/.ssh/config?
<spm> yes
<mwhudson> ok
<mwhudson> huh, my "build an ami from scratch" script worked
<spm> mwhudson: ok, added that one. lets see what breaks next :-)
<thumper> spm: did you do strawberry as well as marambio?
<mwhudson> spm: is strawberry equally set up as marambio ?
<thumper> mwhudson: snap
<mwhudson> thumper: great minds think alike!
<mwhudson> or fools never differ, spm can choose
 * spm goes away till the hugging session is over
<rockstar> thumper, did we lose "Reviews I CAN do" ?
<spm> thumper: mwhudson: yeah, both are setup at the same time.
<thumper> rockstar: no
<thumper> rockstar: but if there is nothing there, it won't show
<rockstar> thumper, there SHOULD be something there though.
<mwhudson> spm: can strawberry connect to the database though?
<rockstar> thumper, see this: https://edge.launchpad.net/~rockstar/+activereviews
<rockstar> thumper, and then this: https://code.edge.launchpad.net/~laymansterms/entertainer/less-config/+merge/10217
<mwhudson> spm: it looks like it can't
<spm> mwhudson: yeah, can't. that one looks easy. one sec.
<thumper> rockstar: on your personal page, we don't show team reviews you could do
<thumper> rockstar: as there could be *a lot*
<thumper> rockstar: reviews you can do only show on the project page
<rockstar> thumper, *sad face*
<rockstar> thumper, that's a bit inconsistent, methinks.  We should figure out a way to do it.
<spm> mwhudson: that should be ready to roll on strawberry, or find something else busted...
<mwhudson> spm: http://staging.launchpadlibrarian.net/32141238/tasky-master-log.txt
<mwhudson> spm: 1 minute ago, looks like the tellurium access is still crocked?
<spm> pub key. bleh
<lifeless> mwhudson: no comment on my testing post ? :P
<mwhudson> lifeless: nothing specific came to mind
<mwhudson> lifeless: good luck!
 * lifeless snorts
<spm> mwhudson: looks like strawberry is happier, for values of. still busticated elsewhere "Failure: twisted.internet.error.ProcessTerminated: A process has ended with a probable error condition: process ended with exit code 1."
<spm> which I think is the more verbose way of saying, "bus error, core dump" ;-)
<mwhudson> spm: it's still failing to connect to tellurium it seems
<mwhudson> http://staging.launchpadlibrarian.net/32141240/tasky-master-log.txt
<mwhudson> spm: still public key complaints
<spm> ta
<barry> bac: still here?
 * thumper waits for spm to do public key magic
<spm> thumper: the suspense is good for your cardio system. so i believe.
<mwhudson> wgrant: you there?
<wgrant> mwhudson: I am.
 * wgrant guesses.
<mwhudson> wgrant: want to test a public ec2test image?
<wgrant> mwhudson: As I guessed. Sounds good to me.
<mwhudson> wgrant: can you tell me your aws id?
<mwhudson> (that's the 12 digit thing)
 * wgrant finds it.
<mwhudson> (it's not actually public yet :-)
<wgrant> mwhudson: 6030-0208-9181
<mwhudson> wgrant: ok, try ec2 test from bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/ami-from-scratch
<mwhudson> wgrant: oh, and the branch you're testing will need to have bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/no-more-devpad-ssh merged into it
<mwhudson> (ami-from-scratch has had that branch merged into it)
<wgrant> mwhudson: OK. How do I run it over a local branch?
<mwhudson> wgrant: ec2 tests the branch in '.' by default
<wgrant> mwhudson: OK, let's see if it runs...
<mwhudson> hm, i think i'll still be able to log into your instance
<mwhudson> that's not ideal i guess
<wgrant> Possibly not.
<spm> mwhudson: thumper: \o/
<mwhudson> but not very interesting in terms of whether it works or not
<spm> https://code.staging.launchpad.net/~vcs-imports/tasky/master
<thumper> spm: yay
 * thumper tries the kernel
<wgrant> mwhudson: Right. Just don't steal my SSH keys, kthxbye.
<mwhudson> wgrant: ok
<mwhudson> thumper: the branch isn't in the 2a format
<mwhudson> mwh@grond:ami-from-scratch$ bzr info nosmart+lp://staging/~vcs-imports/tasky/master
<mwhudson> Standalone branch (format: 1.14-rich-root or 1.9-rich-root)
<thumper> :(
<mwhudson> yeah
<thumper> spm: when we do staging updates, are the import slaves updated?
<thumper> spm: please say no
<spm> thumper: technically yes, but last night they were no, as the boxes were down at the time. didn't think of that...
<mwhudson> yeah, the code on strawberry looks way out of date
<spm> revno 8458 ?
<spm> miles out of date. I assume that's an implied, pls fix kthx?
<mwhudson> db-stable is 8495
<mwhudson> so yeah, pretty old
<mwhudson> spm: yes pls
<spm> damn I'm good at this anticipation of the bleedin' obvious (and self congratulation, but lets not go there...)
<mwhudson> hm hm
<spm> hahahahahahaha
<wgrant> mwhudson: Instance started...
<mwhudson> wgrant: i think the tests will fail because various things aren't in /etc/hosts
<wgrant> mwhudson: I guess I'll see soon.
<mwhudson> but again, that's not so interesting
<wgrant> update-sourcecode is doing its stuff. It looks like my fix worked.
<mwhudson> if we get as far as running the tests i'll be fairly happy
<wgrant> That was *very* quick, but it looks like it did everything.
<thumper> spm: what about the code base on the scanner / branch type jobs?
<wgrant> It went headless.
<mwhudson> wgrant: \o/
<spm> thumper: they update themselves, and should be fine. verifying...
<spm> thumper: supermirror is 8495, bzrsyncd is same
<thumper> :(
<thumper> spm: I'm looking for the logs and oopses from the staging merge proposal created script
<wgrant> mwhudson: Where does it keep its logs? Those available TTW don't seem to be fully up to date.
<mwhudson> wgrant: modulo pipe buffering i think they should be up to date
<mwhudson> wgrant: i don't know much about that end of things
<wgrant> mwhudson: Yeah, it's just buffering it until it's got enough, by the look of things.
<wgrant> Alright, actually running test_on_merge now.
<wgrant> But I suppose that makes schema...
<mwhudson> yep
<wgrant> /var/launchpad/test/bin/test -vv
<wgrant> It is working.
<mwhudson> yay
<mwhudson> building a new image now, without my keys and with /etc/hosts set up
<mwhudson> will take about an hour
<wgrant> mwhudson: Great! Thanks.
<wgrant> librarian tests fail with "name or service not known", as expected.
<wgrant> Do I just kill the instance?
<spm> thumper: those logs should be over
<thumper> ta
<mwhudson> if i stop making stupid mistakes
<mwhudson> wgrant: it should be killed automatically
<mwhudson> once the tests end
<wgrant> mwhudson: I killed it manually, since lots are - unsurprisingly - failing.
<mwhudson> wgrant: ok
<thumper> :(
<thumper> mwhudson: I can't test the truncating of the bigger diffs, as I can email a 16.9meg diff to the staging inbox
<mwhudson> thumper: ?
<mwhudson> thumper: you mean, large diffs are still being produced?
<thumper> mwhudson: one of the bugs was "complete diff" can never always work
<thumper> mwhudson: this is just a revision diff
<thumper> mwhudson: of a simple commit
<mwhudson> thumper: oh, that bug
<mwhudson> thumper: can probably get an SA to twiddle some MTA config somewhere
<thumper> spm: how often are oopses synced from staging to devpad?
<spm> thumper: 1. same as prod, every 10; and 2. whenever I get asked to do so ;-)
<thumper> spm: I can wait 10 minutes :)
 * spm calls liar liar pants on fire...
<spm> thumper: fwiw, the most recent was about 4 mins ago; so they may have been synced already?
<thumper> spm: it was just after the cut off :)
<spm> Ahh. Murphy. How we love you...
<spm> thumper: synced. all yours.
<thumper> ta
<purserj> hi all, I'm trying to setup the launchpad code on ubuntu jaunty and I've hit an error when running make schema. Specifically I've got errors coming out the wazoo when trying to build _ctypes
<thumper> purserj: have you followed the instructions on the dev wiki?
<wgrant> purserj: There's a bug in rocketfuel-setup at the moment. What happens if you try just 'make'?
<purserj> thumper: yes
<purserj> wgrant: let me try
<purserj> same problem
<purserj> Can't find Python.h or structmember.h
<wgrant> purserj: Ah, that's not the same issue.
<mwhudson> purserj: sounds like python2.4-dev is not installed
<wgrant> purserj: Check your rocketfuel-setup logs. It didn't go at all well.
<wgrant> (perhaps just try to run it again)
<purserj> ah, that's probably it. Jaunty is 2.6 by default isn't it
<wgrant> It is, but rocketfuel-setup will handle it.
<Ursinha> hey mwhudson
<mwhudson> Ursinha: hello
<Ursinha> can I mark your testfix item as ok? the outstanding one in the testplan
<mwhudson> Ursinha: it's just a testfix isn't it?
<Ursinha> mwhudson, well, should be
<mwhudson> Ursinha: yeah, that's an OK or ?? or whatever is appropriate for that sort of change
<Ursinha> mwhudson, ok
<Ursinha> thakns
<Ursinha> thanks
<mwhudson> Ursinha: we would have QAed  # r9512 [r=mwhudson][ui=none] Disable the automatic upgrading of import branches, and fix the import worker to push overwrite the import branch. by now but the staging code import set up was horribly broken :(
<Ursinha> mwhudson, broken because of the fix or broken for other reasons?
<mwhudson> Ursinha: other reasons
<Ursinha> mwhudson, I see
<mwhudson> Ursinha: nearly fixed now, hopefully it'll get tested before rollout...
<Ursinha> mwhudson, is someone fixing it?
<Ursinha>  :)
<mwhudson> Ursinha: spm, but he's at lunch
<Ursinha> mwhudson, that's good
<spm> mwhudson: "was" :-)
<mwhudson> Ursinha: it's all to do with some data centre moving about-ery
<mwhudson> spm: hello again
<spm> just done the importds sync'ing make building right nooo
<Ursinha> hahahaha
<Ursinha> hi spm :)
<spm> insert random commas to have that make sense btw.
<spm> hey Ursinha!
<thumper> spm: hey hey
<mwhudson> Ursinha: how is the 3.0 qa looking?
<mwhudson> spm: when is the rollout?  about 16 hours away?
<spm> thumper: "just done the importds sync'ing make building right nooo" <== iz under way as we speak :-)
<Ursinha> mwhudson, in code's land, very few things pending
<Ursinha> registry has a bunch untested
<spm> mwhudson: something like that. 8am local.
<thumper> spm: ta
<spm> 22:00 utc
<thumper> spm: you're a star!
<mwhudson> spm: thanks
 * mwhudson runs top on strawberry, the better for telling when make build is finished
<spm> mwhudson: amusingly I was just curing the same thing (make build, not top)
<spm> cursing!
<mwhudson> it's fricking slow
<spm> have you had a look at how speedy the edge rollouts are these days?
<mwhudson> spm: i'm aware of a certain amount of frustration in that area
<Ursinha> thumper, have you tested r9345?
 * mwhudson understates
<thumper> Ursinha: which one is that?
<thumper> Ursinha: ah
<thumper> Ursinha: I tried
<spm> mwhudson: yay; 1 down...
<thumper> Ursinha: but the staging email will allow a 16.9 meg email to be sent
<thumper> Ursinha: so it isn't a definitive test
<thumper> Ursinha: I think I'm going to have to ??? that one
<spm> mwhudson: revno 8491 sound about right?
<mwhudson> spm: yeah
<Ursinha> thumper, well, if we can't test because of infrastructure, ?? is the best
 * thumper nods
<lifeless> AssertionError: 'version' can be only used when name is set
<lifeless> echannel
<spm> mwhudson: thumper: importd slaves should be gold
 * thumper pokes the slaves
<purserj> hrm this looks like it's doing more this time round
<thumper> spm: I want to copy the dulwich branch from the production import branch store to the staging import branch store
<thumper> spm: can you do this?
<spm> thumper: codehost mirror as in?
<thumper> spm: no, the import branch store, let me find the details
<spm> oh yes right.
<spm> thumper: is this a perm import/staging or one offski?
<thumper> spm: what?
<thumper> spm: I'm trying to test that we don't auto upgrade
<spm> thumper: as in always import dulwhich to test with, or just this once.
<thumper> spm: and that we have fixed the rebasing problem
<spm> ah sweet
<thumper> spm: just this once
<spm> k
<thumper> spm: actually, I'd need the mirror copy too
<thumper> spm: as part of the issue is in the push --overwrite of the mirror
<spm> oki
<thumper> spm: do you know where these live?
<thumper> spm: or do I have to find locations?
<spm> the 00/00/12/34 ? I can find out
<mwhudson> it's not /-ed though for code imports
<spm>  select id, branch, svn_branch_url, date_last_successful from codeimport where git_repo_url like '%dulwich%' order by branch;" ==> 2738 |  97795 |                | 2009-07-23 12:16:16.257395
<mwhudson> spm: so copy sftp://hoover@escudero/srv/importd/www/00017e03 to sftp://supermirror@tellurium/home/supermirror/importd-push-branches
<mwhudson> and sftp://hoover@escudero/srv/importd/sources/00017e03.db to sftp://supermirror@tellurium/home/supermirror/foreign-trees
<spm> argh. wrong column. (017e03) ta.
 * wgrant is confused about what escudero is doing there. Isn't it a production web server?
<spm> never you mind :-P
<spm> mwhudson: so aprt from the .db, the existing script we use worked fine. that stuff should be there now
<spm> on tellurium as in
<mwhudson> wgrant: shush you
<spm> wgrant: is a ... dmz middle ground in this case, fwiw.
<wgrant> spm: Ahaha.
<mwhudson> er
<mwhudson> where has the review import link gone
<mwhudson> rockstar: ?
<mwhudson> oh, over there
<rockstar> mwhudson, yeah, it moved...
<mwhudson> wgrant: can you try ec2 test again?
<mwhudson> update your ami-from-scratch branch first
<mwhudson> wgrant: it should say "Using machine image version 20"
<wgrant> mwhudson: Updating.
<mwhudson> thanks
<wgrant> No, thank you!
<thumper> mwhudson: rhs
<wgrant> mwhudson: Version 20 it is.
<mwhudson> thumper: yeah, 'find in page' found it :)
<thumper> mwhudson: heh
<mwhudson> https://code.staging.launchpad.net/~vcs-imports/dulwich/trunk <- import successful
<thumper> mwhudson: now blow it away and test 2a ?
<mwhudson> thumper: i guess, i just made https://code.staging.launchpad.net/~vcs-imports/tomboy/trunk for that
<thumper> heh, snap: https://code.staging.launchpad.net/~vcs-imports/clutter/master
<mwhudson> :)
<wgrant> mwhudson: buildout is slooooow, but tests are now running.
<mwhudson> wgrant: you're certainly not wrong there
<mwhudson> wgrant: http://www.netsight.co.uk/junk/xkcd-buildout.png
<wgrant> mwhudson: Hahaha.
<wgrant> Speaking of xkcd...
<mwhudson> thumper: https://code.staging.launchpad.net/~vcs-imports/tomboy/trunk seems to be in 2a format \o/
<mwhudson> i guess there wouldn't be much harm in baking built eggs into the image, really
<lifeless> other than eggs?
<wgrant> mwhudson: It's a bit boring. It looks like it's all working.
<mwhudson> wgrant: if you're running all the tests, it'll be really boring
<wgrant> (\o/)
<mwhudson> wgrant: yeah
<mwhudson> let me see if this image works with the trunk ec2 test
<mwhudson> then i should see about making it public i guess
<thumper> mwhudson: yay
<thumper> mwhudson: which branches do we need to delete to test the 2a replacement of dulwich on staging?
<thumper> mwhudson: is it just the ones on tellurium?
<mwhudson> thumper: yeah
<thumper> spm: can you delete the dulwich branches you recently put on tellurium?
<spm> thumper: sure
<spm> thumper: that should be them all gone
<thumper> ta
<thumper> mwhudson: the kernel import isn't showing a great speedup over 1.9 :(
 * thumper goes to cook dinner
<wgrant> mwhudson: What's special about the ec2test AMIs now?
<thumper> mwhudson: dulwich staging now in 2a, but since no commit, scanner hasn't picked it up
<mwhudson> wgrant: what do you mean?
<wgrant> mwhudson: Judging by what ec2test now does (and the name of branch), it looks like it should basically work on vanilla Ubuntu image.
<wgrant> Yet you needed to create a special one..
<mwhudson> wgrant: mostly that's an optimization, it takes a while to branch launchpad and all the other setup
<mwhudson> wgrant: what i wanted to check was that if i made the launchpad-ec2test20 image public, so everyone used it, that it would work with the ec2 that's in trunk
<mwhudson> wgrant: i can't land the branch yet because of release-critical and all that
<mwhudson> (so far the answer seems to be "yes, but very slowly")
<wgrant> mwhudson: You can't get an RC for something unrelated to the release? Or does buildbot use ec2test?
<mwhudson> wgrant: i haven't tried, to be fair
<mwhudson> i'll ask tomorrow i guess
<wgrant> mwhudson: Anyway, great job! I was wondering if I could convince it to work on a normal AMI for eg. clean Karmic testing, and 2.5 and all that.
<mwhudson> wgrant: i built that image with "./utilities/ec2 update-image --from-scratch --public launchpad-ec2test20 -p -m ami-5346a73a"
<mwhudson> if you specify a karmic ami to -m, you should get something that would let you do that
<wgrant> mwhudson: Oh, didn't realise that script was there too.
<wgrant> mwhudson: Thanks.
<mwhudson> wgrant: note that ec2 picks an ami that's owned by a fixed set of people, you'll need to hack it if you want to use your own
<mwhudson> (or pass it to -m)
<wgrant> mwhudson: Yep.
<mwhudson> i guess the "build image from scratch" could be separated from the "bundle a new ami"
<mwhudson> so you could have a command that took a blank karmic image, slapped launchpad onto it, then ran the tests
<wgrant> Right.
<mwhudson> not today though :)
 * mwhudson eods
<spm> night mwhudson
<jml> hey
<wgrant> Huh. Creating a Karmic AMI failed, although with a dpkg segfault rather than an ec2test bug...
<wgrant> Morning jml.
<jml> wgrant, Good evening :)
<jml> wgrant, how's things?
<wgrant> jml: Pretty good. Currently trying to convince ec2test's update-image to give me a karmic image. Not succeeding.
<wgrant> How's things on the wrong side of the world?
<spm> hey jml!
<jml> wgrant, overcast :)
<wgrant> jml: Better than Sydney, from what I hear.
<jml> thumper, are you aroud?
<jml> n
<beuno> jml, did we get a rollout to edge or staging to check yesterday's changes?
<beuno> (we didn't for edge AFAICS)
<beuno> also, both of Curtis's branches bounced on EC2, so they've not landed
<jml> beuno, I don't know. bac didn't answer when I asked.
<jml> beuno, that sucks. forward me the test failures?
<beuno> jml, sure. I fwd both of them to him last night
<beuno> quite a few tests failed
<jml> hmm
<beuno> jml, sent
<spm> beuno: edge is rolling out as we speak
<jml> nice
<spm> should be done in the next 10 or so
<beuno> spm, thanks
<jml> mischan
<jml> beuno, they look unrelated
<jml> beuno, I'll forward them to sinzui & ask him to confirm
<beuno> jml, sinzui is now here, and says he knows why
<jml> oh good.
<jml> sinzui, hello
<jml> sinzui, beuno says you know why those branches failed -- you right to fix & land them?
<mrevell> Morning all
<beuno> noodles775, hi
<noodles775> hi beuno
<beuno> noodles775, any news on bug 434519
<mup> Bug #434519: Text in overlay is now centered <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/434519>
<noodles775> beuno: no - I didn't have time yesterday, I can take a look now though.
<beuno> noodles775, it would be lovely
<beuno> otherwise, I'll bounce it to someone else, as it's a release blocker
<jml> mrevell, hi
<jml> sinzui, ping
<noodles775> beuno: it wasn't assigned to me... but assigning it now.
<sinzui> hi jml
<jml> sinzui, sorry to hassle, but I didn't get your answer to "<jml> sinzui, beuno says you know why those branches failed -- you right to fix & land them?"
<sinzui> jml: yes, they failed. I am fixing the tests and code now
<jml> sinzui, cool, thanks.
<bigjools> thumper: still there?
<bigjools> sinzui!
<spm> gmb: ref https://bugs.edge.launchpad.net/ubuntu/+source/gdm/+bug/393854 it's been noted that if you unfold the gdm line you get "GNOME Bug Tracker bug #414862 appears not to exist..." is that a checkwatches issue or... ??
<mup> Bug #393854: Update PAM policy to allow password-less logins set up via users-admin <gdm:Confirmed> <gdm (Ubuntu):Confirmed> <https://launchpad.net/bugs/393854>
<mup> Bug #414862: acroread 9: you do not have permission to write to this file <acroread (Ubuntu):New> <https://launchpad.net/bugs/414862>
<mrevell> hi jml
<gmb> spm: It's probably because we had to run checkwatches manually on Monday and it was run once without the http_proxy set, so it got a lot of Connection Refused errors. We can do a run to clear those specific errors later on if needs be.
<spm> gmb: Ahhh. k. ta.
<gmb> spm: Actually, if you can just run `SELECT count(id) from BugWatch WHERE bugtracker = (SELECT id from BugTracker WHERE name = 'gnome-bugs') AND last_error_type = 2;` on production we should be able to see how many watches need fixing.
<spm> sure. one sec.
<spm> gmb: ha. zero. 1 row.
<gmb> spm: Hah. I must've mucked up the query then... try with "last_error_type IS NOT NULL" instead.
<spm> gmb: that looks more scary: 9854
<gmb> Eeek.
<gmb> spm: I'm tempted to leave them be for now. We've got some new Bugzilla stuff landing in 3.0 that should stop gnome-bugs being so damn problematic.
 * spm can forsee a fun morning for mthaddon fixing the root case of the 'eeek' ;-)
<spm> wfm
<gmb> spm: Thanks for pinging me about it though; I'll make sure to take care of it once the new code has landed.
<spm> np
<stub> You can always run checkwatches from edge if you need to
<jml> ok. so what is it that I'm doing today.
 * jml really really wants Launchpad mailing lists to include a permalink to the email in the footer of every email
<jtv> mrevell: just looking at our documentation again and was struck by how pleasant and extensive it is.
<mrevell> jtv: Ah, many thanks
 * jml keeps running out of coffee
<jml> http://people.canonical.com/~beuno/conversions.html says there's only one template left: buglisting-embedded-advanced-search.pt
<purserj> has anyone come aross this before? http://pastebin.ca/1576292
<noodles775> How do I go about updating something in lp-sourcedeps (like lazr-js in this case)? I can't find anything on the wiki?
<jml> purserj, looking
<thumper> bigjools: whazzup?
<thumper> mrevell: ping
<jml> noodles775, ./utilities/update-sourcecode /path/to/lp-sourcedeps/sourcecode
<jml> thumper, hi
<mrevell> hi thu m
<mrevell> er
<mrevell> hi thumper
<thumper> jml: hey, enjoying london?
<bigjools> thumper: having read your oops and ops email you left me wondering how to do a wildcard subscription on the dev wiki
<jml> purserj, you need to get the branch dependencies for Launchpad. ./utilities/rocketfuel-get is your friend.
<thumper> mrevell: got the link for the facebook meetup? I'm wanting to invite some
<purserj> jml:  thanks
<mrevell> thumper sure, just a sec
<jml> thumper, I am! although things are very busy.
<thumper> bigjools: like I said "VersionFourDotO.*"
<BjornT> noodles775: for lazr-js, you submit a branch through pqm to bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/lazr-js/toolchain/
<bigjools> thumper: all I know is that I need to hack the URL with ?action=subscribe, I don't know how to put wildcards in that!
<mrevell> thumper: http://www.facebook.com/event.php?eid=150625398707
<jml> thumper, this is the last time I ever move countries and change to a new job just before a major release and critical week-long meeting.
<thumper> bigjools: you have to do it from the user preferences page
<thumper> bigjools: click on your name on the page
<noodles775> BjornT: yep, and to test my branch locally, I just replace the link in lp-sourcedeps?
<thumper> jml: :)
<bigjools> thumper: user-friendliness FTW
<thumper> bigjools: \o/
<thumper> mrevell: ta
<BjornT> noodles775: yeah
<jml> bigjools, thumper: fwiw, I asked the moin guys if it's possible to get announcements about created pages.
<jml> (without getting announcements about every single change, that is)
<bigjools> jml: ooo that would be nice
<BjornT> noodles775: i'm working on buildoutifying lazr-js, though, so the process will change
<jml> bigjools, thumper: the answer was, "my! what a good idea."
<jml> so I filed a bug... they've changed to use a new event infrastructure recently, so it ought not be too hard for them.
<thumper> I'm off again, just wanting the Monday meet up details for UK friends
<thumper> ttfn
<mrevell> thumper: Phil Nash is gonna be there, btw
<bigjools> mrevell: how many !canonical people are going?
<mrevell> bigjools: Hard to say but it looks like there'll be ten or so
<bigjools> wow
<bigjools> mrevell: I am planning how to smuggle pints in from the pub opposite
<mrevell> bigjools: Yeah, that is a must. I forgot just how, erm, limited the beer range is at The Warwick. This should not put anyone off from coming :)
<bigjools> mrevell: the Warwick has beer?
<mrevell> bigjools: Heh yeah, and at ink cartridge prices
<mrevell> :)
<bigjools> mrevell: the ink would taste better than the slop they sell
<mrevell> But the company will be so worth it so everyone should come
<mrevell> :)
<wgrant> purserj: That's the bug I was talking about earlier. 'make' and 'rocketfuel-setup' again to resume it.
<wgrant> jml: There's a bootstrapping issue with your update-sourcecode rewrite that causes the problem.
<jml> wgrant, what's the issue?
<wgrant> Bug #432830
<mup> Bug #432830: rocketfuel-setup does not work <Launchpad Foundations:New> <https://launchpad.net/bugs/432830>
<jml> thanks.
<purserj> wgrant thanks
<ScriptRipper> kiko: ping
<bac> good morning
<purserj> hrmm, I'm running the sourcedeps get stuff, would it be possible to get an indicator as to the status of this?
<lifeless> purserj: you have one, $ == done
<wgrant> purserj: It should print out the names of the branches as it does them, as long as rocketfuel-setup isn't being sneaky.
<mrevell> bac: Crumbs bac, good morning
<bac> mrevell: crumbs to you to, i think.
<mrevell> :)
<jml> bac, hi
<purserj> hrmm the only print out I've had is a complaint that the shipit bzr repo isn't a branch
<bac> morn jml
<lifeless> jml: so did my testing blog make sense to you?
<jml> bac, a bit early for you, isn't it?
<jml> lifeless, yese.
<purserj> doing an ls -ls in the sourcedeps directory shows me stuff is being added but other wise I can't see it
<wgrant> purserj: You'll get two of those (shipit and canonical-identity-provider). They're normal, because those aren't /really/ part of LP, and are only accessible to Canonical folks.
<bac> jml:  a huge mirror that has hung on the bedroom wall for fifteen years just crashed to the floor.  i took that as my 5:30 wake up call.
<jml> lifeless, I would like to reply to it, but I don't expect to have any time for the next couple of weeks.
<bac> it whacked my laptop closed on the way down but did no damage
<jml> bac, eek.
<lifeless> jml: thats fine, I'll try not to solve world hunger before you get time ;)
<bac> mrevell: thanks for your review response.  did you land it?
<mrevell> bac: No, I left it to run in the test-suite over night and it passed so I'm landing it now.
<bac> mrevell: good deal
<bac> jml: i didn't see your question yesterday about edge and staging.  didn't ignore you on purpose.
<purserj> okay, that seems to have fixed things, now to build
<jml> bac, oh that's fine, I just assumed you were extremely busy :)
<bac> jml: so i see spm said edge has been updated.  do you know about staging?
<jml> bac, nope, I haven't looked yet.
<jml> beuno, ping
<jml> bac, staging seems quite out of date
<bac> jml: ok
<jml> bac, r8488 vs r8495
<purserj> okay next breakage, now looking for CVS.protocol
<lifeless> cscvs
<purserj> tah
<purserj> sorry for the questions, and thanks for the help ladies and gents
<deryck> Morning, all.
<jml> deryck, good morning.
<beuno> jml, hi
<jml> beuno, do you know what happened with the homepage change?
<bigjools> jml: jeez, look what you left behind in Sydney
<lifeless> mars!
<wgrant> None of that down my way, fortunately.
<lifeless> it was surreal
<wgrant> I'm not sure whether to believe some of the photos.
<lifeless> the ones with godzilla are fake
<wgrant> Nah.
<lifeless> I got up, looked out at the office blinds - they were orange
<purserj> and the problem was an empty cscvs directory in sourcecode
<wgrant> purserj: I've only seen that happen when the download gets interrupted.
<purserj> yeah
<purserj> I'm pretty sure that was my fault
<bac> hi bigjools
<bac> bigjools: how is your work for bug 314436 coming?
<mup> Bug #314436: package-diff can generate infinite output <package-diff> <Soyuz:Triaged by julian-edwards> <diffutils (Ubuntu):Confirmed for scott> <https://launchpad.net/bugs/314436>
<bigjools> bac: in the middle of doing it right now
<bac> bigjools: okey doke
<bac> bigjools: big task?
<bigjools> it's a band-aid patch until diffutils is fixed
<bigjools> no, trivial
<bac> great
<bac> bigjools: you know how cprov-afk's def-row work is going?
<bigjools> bac: I won't know until he's around
<bac> bigjools: ok
<bac> jml: what's your question about the home page?  barry had a branch that beuno approved and should've landed on db-devel
<jml> bac, that's basically my question.
<bac> jml:  it looked quite nice
<jml> utilities/branch-flow says its one of the not-yet-tested revisions.
<jml> bac, very pleased to hear that.
<bac> jml:  what is this branch-flow of which you speak?
<jml> bac, run ./utilities/branch-flow from one of your launchpad branches.
<bac> cool
<bac> what does 'untested' mean in this context?
<jml> bac, not landed on db-stable
<bac> ok
<beuno> noodles775, THANK YOU
<beuno> I feel I need to go down to germany and buy you a few beers for all your work in 3.0 UI
<noodles775> beuno: feel free to review the (v. simple) change: https://code.edge.launchpad.net/~michael.nelson/lazr-js/434519-overlay-alignment/+merge/12268
<beuno> noodles775, on it
<noodles775> hmm... not sure why that's a private mp. Let me know if it causes an issue for you.
<beuno> not at all
<beuno> running LP to verify the fix
<beuno> does this need an RC?
<bac> jml;  i'm subscribed to the devel and db-devel branches with the same settings.  i get landing messages for devel but none for db-devel.  any ideas?
<noodles775> beuno: good question, I'm trying to find where we specify which version of lazr-js we use... utilities/sourcedeps.conf just says toolchain?
<jml> bac, good question
<bac> having those would be handy today
<beuno> noodles775, I think the latest always get pulled, but maybe jml knows
<jml> noodles775, beuno: always the latest.
<jml> sourcedeps.conf doesn't have a way to specify revno that I know
<noodles775> beuno: and great that you can verify it - as I've stuffed my local sourcecode deps and currently can't verify it until I find out why.
<beuno> jml, do we need an RC to land it?
 * jml reading...
<jml> beuno, land what exactly?
<beuno> jml, lazr-js
<noodles775> jml: one line extra css rule... see above MP.
<jml> ahhh, I see.
<noodles775> (not that the complexity of the fix is relevant to whether we need RC.)
<jml> whether you need an RC or not is bac's call, I think.
<jml> I'm happy to review the code.
<bac> noodles775: what is the change?
<noodles775> bac: https://code.edge.launchpad.net/~michael.nelson/lazr-js/434519-overlay-alignment/+merge/12268
<noodles775> I'm just waiting for beuno to verify the fix.
<beuno> noodles775, it works fantastically well
<beuno> I've approved
<noodles775> Great.
<bigjools> intel in intrepid, why does thou sucketh so badly
<bac> noodles775: the fix to lazr-js does not need r-c IMO but any config change in LP to use it will
<noodles775> bac: great, apparently we don't need one. Thanks.
<bac> noodles775: or were you saying our config doesn't specify version?
<noodles775> yep, lazr-js=lp:~launchpad-pqm/lazr-js/toolchain/
<bac> noodles775: so lazr-js can change under LP's feet and we'll just happily use the latest?
<noodles775> bac: well, the ~launchpad-pqm/lazr-js/toolchain, yes.
<noodles775> bac: see utilities/sourcedeps.conf
<noodles775> I guess that will change once it's buildbot-ified.
<bac> noodles775: policy-wise that seems odd
<wgrant> bigjools: It's Jaunty that's really terrible, not Intrepid.
<bigjools> wgrant: it's frustrated me so much I forgot which release I was running
<wgrant> bigjools: Karmic is much much better.
<bigjools> I can't run for more than half a day without filling swap
<noodles775> bac: yep - jml or BjornT might know more?
<bigjools> wgrant: I really, really hope so
<wgrant> bigjools: I no longer have to reboot three times a day after swap death.
<wgrant> bigjools: i run for weeks instead!
<wgrant> And it's fast.
<purserj> and we're in, thanks guys
<wgrant> purserj: It's running?
<bigjools> wgrant: hooray, I think I will upgrade tomorrow after 3.0 is done
<purserj> yeah
<bigjools> wgrant: is the suspend bug fixed?  X used to crash on waking up
<wgrant> bigjools: Yep.
<bigjools> I'm sold.
<wgrant> bigjools: It was dieing with Compiz sometimes a few weeks ago, but it works fine now.
<bigjools> wgrant: as long as it doesn't die with plasma :)
<wgrant> bigjools: We can hope.
<wgrant> bigjools: I believe a few codehosting tests have regressed on Karmic, but hopefully ec2test will tell me otherwise in a few minutes...
<bigjools> marvellous
<purserj> now that I've got it running, I have to go and do other stuff, sigh
<bigjools> oh awesome, I got an oops proposing a merge
<gmb> Oops. I broke everything.
<gmb> Ok, fixed it now.
<jml> yay
<jml> hooray for everything
<jml> I'm off to lunch. back later.
<BjornT> bac, noodles775: changes to lazr-js do require release-critical for now, since your changing the version that launchpad is using. this will change when lazr-js is buildoutified, which i'm working on now.
<noodles775> BjornT: OK - bac I just requested an r-c on the mp from you (the branch is on pqm given the previous info.)
<noodles775> Thanks BjornT.
<bac> thanks for the clarification BjornT
<Ursinha> hi noodles775
<noodles775> Hi Ursinha
<Ursinha> noodles775, I'm doing the last minute checkings to the rollout, so I'd like to know if you tested the three pending items in soyuz test plan?
<Ursinha> 3.0 one
<noodles775> Ursinha: I just updated the page...
<Ursinha> noodles775, oh :)
<Ursinha> noodles775, thanks
<Ursinha> noodles775, this item that OK under BAD section was a RCFIXED one? I mean, you got one RC to fix a previous BAD item?
<Ursinha> oh crap, cprov was the next one :)
<Ursinha> hmm
<noodles775> Ursinha: No, i'm just looking at it now... I'll update the status.
<Ursinha> bigjools, hi :)
<Ursinha> thanks noodles775!
 * bigjools hides
<Ursinha> oh, noodles775, so that's a BAD one... is that a blocker for today's rollout?
<Ursinha> bigjools, about the two items in the test plans, have you tested them?
<noodles775> Ursinha: I wouldn't think so, bigjools can you take a look at the comment I added to that item?
<Ursinha> bigjools, please? ^
<bac> hi henninge
<bigjools> Ursinha: not yet
<henninge> Hi bac, in a call atm.
<Ursinha> bigjools, are you planning to? :)
<bigjools> Ursinha: well I had planned to fit it in at some stage, in amongst all the other urgent issues :)
<bac> Ursinha: please add those to CurrentRolloutBlockers
<bigjools> Ursinha: we have 2 more in 2.2.8 as well
<bigjools> but I think they are both ??
<Ursinha> bigjools, yes, I was planning to talk to cprov but he's gone
<bigjools> he'll be back in 20m
<Ursinha> bac, but are they really blockers?
<Ursinha> bigjools, oh, fine, I'll check with him if those are ??
<bigjools> Ursinha: btw one of those items is really allenaps!
<bac> Ursinha: unsure.  reference?
<Ursinha> bac, why did you ask me to add it to CRB then? :)
<Ursinha> bac, https://dev.launchpad.net/SoyuzTestPlan/3.0 , the BAD item
<bac> Ursinha: i mis-read.  i thought you were under the impression they WERE blockers
<Ursinha> bac, ah, no, I was checking with bigjools
<Ursinha> if they're blockers
<Ursinha> bigjools, your pending ones, are they blockers if not working?
<bigjools> Ursinha: ok QA'ed
<Ursinha> bigjools, \o/
<Ursinha> that was easy
<bigjools> Ursinha: actually you can help me, I need to request blueprint feedback to test one of them, can I put your name in?
<Ursinha> bigjools, go for it
<bac> Ursinha: add the one BAD on that page to CRB under 'not a blocker'.  if fixed i'll give it an r-c but we won't block on it
<Ursinha> bac, ok, doing it
<bigjools> Ursinha: ok visit https://blueprints.edge.launchpad.net/soyuz/+spec/native-source-syncing
<bac> Ursinha: what about the icon clobbering in the portlet on https://edge.launchpad.net/sprints/uds-l  ? is that issue filed?
<bigjools> Ursinha: look at the bottom right and click on "give feedback"
<Ursinha> bac, have to check, just woke up and started poking soyuz people like crazy\
<Ursinha> :)
<Ursinha> bigjools, looking
 * bigjools has holes
<Ursinha> lol
<barry> bac: wow! only one unconverted template left
<bac> barry: the bug one?
<bigjools> yeah those bugs slackers eh :)
<barry> bigjools: yep
<bac> not to worry.  deryck is on it.
<Ursinha> bigjools, oh, I guess I didn't get the way that works
<bigjools> Ursinha: do you see the link?
<Ursinha> bigjools, you click on give feedback just to remove the item for your queue?
<Ursinha> bigjools, yes
<bigjools> yep, that's it
<bigjools> tick that QA box
<Ursinha> I did
<bac> noodles775: can you look at the attendees list on https://edge.launchpad.net/sprints/uds-l ?  was it messed up the last time you saw this page?
<Ursinha> and it cleared the queue
<bigjools> :)
<Ursinha> bigjools, is this the desired behavior?
<bigjools> yep
<Ursinha> cool
<noodles775> bac: nope - and the h1 header wasn't there either :/. A change to a base class of the view added a label which has added the second h1 heading, I'm looking at the attendees list now.
<bac> noodles775: thanks
<bigjools> Ursinha: ok both items are marked OK
<bigjools> noodles775: what's bad on yours?
<Ursinha> bigjools, thanks!
<noodles775> bigjools: see the last bullet on the qa item - i noted it there.
<bigjools> noodles775: I followed the link and didn't see a problem
<noodles775> bigjools: the second h1 should not be there... the base class for the view was subsequently updated with a view.label.
<deryck> just bzr lpsend'ed the last template conversion branch for review!
<bigjools> noodles775: ah I see
<bigjools> noodles775: it's not a major hassle I don't think
<noodles775> bigjools: great.
<bigjools> noodles775: although - I only see the additional h1 over the app tabs?
<bigjools> do you mean that the other one should not be there to the left of "registered by ..." ?
<noodles775> bigjools: that's the one that *should* be there, the one below should not.
<noodles775> yes, the one next to 'registered by' should not be there, according to the heading rules.
<bac> barry: does registry have any BADs that need fixing?
<bigjools> noodles775: ok
<bac> hi cprov
<cprov> bac: hi there
<barry> bac: we have two bads in 2.2.8, none in 3.0
<Ursinha> bac, added
<barry> bac: you've already said we won't fix bug 410416 and i think curtis has retargetted 297877 for 3.10
<mup> Bug #410416: Private teams cannot be project owner or driver <Launchpad Registry:Fix Committed by bac> <https://launchpad.net/bugs/410416>
<cprov> bac: the death-row blocker ... I'm on it, seriously this time. I will have a position in 2h or so.
<barry> bac: so i think the answer is "no"
<bac> cprov: great
<barry> bac: or maybe "not at the moment" ;)
<bac> barry: :)
<bac> barry: we owe big thanks to Ursinha for doing a lot of QA last night
<barry> Ursinha: \o/
<Ursinha> :)
<Ursinha> cprov, hi :) can you confirm if the two pending items in soyuz 2.2.8 test plan are '??' ?
<cprov> Ursinha: yes, at this point they are probably ??  because there is no reliable way to QA them
<Ursinha> cprov, oh, I see
<gmb> allenap: Did your externalbugtracker branch land yet?
<henninge> Hey bac, I am off the call.
<bigjools> deryck, beuno: are we going to fix the fixed-width columns in the bugtask table?  It causes unnecessary wrapping.
<bac> henninge: sinzui had a branch last night that moves the registering slot to above the rule.  does that address your concerns?
<henninge> bac: sounds like it. Has it landed?
<bac> henninge: unsure
<deryck> bigjools, yes, we were trying to get it.
<bigjools> cool
<henninge> bac: especially since there are more pages than those two that use it.
<henninge> sprints, too
<bac> henninge: yes, it landed as db r8503
<henninge> bac: I just saw it ;-)
<henninge> bac: now the bugs index page needs to use it ... ;-)
<henninge> thanks, bac
<bac> henninge: thanks for the email.  yeah, the non-conformers will need to be fixed
<Ursinha> hey salgado
<salgado> hi Ursinha
<Ursinha> salgado, have you done QA in your stuff on 2.2.8/3.0 test plans? if not, any of your items can break lp miserably that should be tested for us to be sure?
<salgado> Ursinha, we're not QAing our own items this time
<salgado> let me check if I have something that can cause breakage.  although I'd be really surprised if any of my changes ever broke anything. <wink>
<Ursinha> hehehe
<Ursinha> thanks salgado
<salgado> Ursinha, nothing
<barry> Ursinha, salgado i'm qa'ing 3.0 stuff today too, but other people's stuff
<Ursinha> salgado, anything you could say 'oh, this can't be really tested, so it's a ??' ?
<Ursinha> barry, thanks a lot
<barry> Ursinha, salgado we should coordinate so we don't double-test stuff
<salgado> Ursinha, already did that
<Ursinha> salgado, awesome
<salgado> barry, absolutely.  what was that marker you suggested yesterday?
<barry> salgado: put a "* Tested by ..." on the item when you start.  but that's kind of inconvenient i've found.  do you have a better idea?
<salgado> barry, move it to the OK section without changing its status, before you start QAing an item?
<barry> salgado: good idea
<barry> salgado: let's do that and see how it goes
<salgado> barry, or maybe add a new section with your name and use that as your working-on queue
<barry> salgado: that might work, if that section is near the top of the file.  let me hack on the page a bit and see what works
<barry> salgado: https://dev.launchpad.net/RegistryTeam/RegistryTestPlans/3.0
<salgado> barry, looks good, but it might be a good idea to have sub-sections there for each of us
<barry> salgado: https://dev.launchpad.net/RegistryTeam/RegistryTestPlans/3.0
<bac> allenap: what's the status of bug 423105 ?
<salgado> looks good to me
<mup> Bug #423105: Duplicate download icons in many places <Launchpad Foundations:Triaged by beuno> <Launchpad Bugs:In Progress by allenap> <https://launchpad.net/bugs/423105>
<barry> salgado: cool.  i guess that means we now have to actually do the qa ;)
<barry> salgado: was there a bug for your r9312 branch?
<salgado> barry, bug 434349
<mup> Bug #434349: Distribution series index OOPS <timeout> <Launchpad Registry:Fix Committed by salgado> <https://launchpad.net/bugs/434349>
<salgado> oh, no
<salgado> I thought you were talking about that r-c I landed yesterday
<barry> salgado: "r9312 [r=bac][ui=none] Change Hierarchy view to add an extra breadcrumb for the current page when we're not looking at the context's default view."
<salgado> barry, nope, no bug for that, but if you see a breadcrumb for the current page in, say, /people/+me/+edit, then it works
<salgado> and people would've screamed if it didn't
<barry> salgado: cool
<jml> beuno, we should probably have a tag for post-3.0 ui cleanups
<beuno> jml, do it. Since the crisis, tags have become pretty cheap
<jml> heh.
<stub>     InternalError: attempted to lock invisible tuple
<stub> Cool!
<bac> gary_poster: did your breadcrumbs branch land?  please update CRB
<gary_poster> bac: no, mentioned to you in /msg: ec2test gave me failures.  working on it now.
<bac> ah, now i remember gary_poster
<salgado> bac, new BAD item in Registry/3.0.  no big deal, though
<salgado> bac, https://bugs.edge.launchpad.net/launchpad-registry/+bug/435260
<mup> Bug #435260: IProduct's +packages pages has a ton of links to +distributions <Launchpad Registry:New> <https://launchpad.net/bugs/435260>
<gary_poster> stub: lol, locking an invisible tuple is not something I've tried
 * gmb -> afk for a bit
<stub> gary_poster: So that seems an internal PG error, so there might be some road bumps on the road to Launchpad + PG 8.4
<gary_poster> stub: ah, ok.  good to know. ":-/
<bac> beuno:  you around
<barry> reviewers, beuno, lurkers -> #launchpad-meeting
<bac> gary_poster: what's your branch status?
<gary_poster> bac: I believe I have addressed about 85% of failures.  continuing to do so.  afterwards I will need to rerun the failed tests locally.
<gary_poster> Then I was going to come to you to see if you wanted to review the incremental diff based on the test failures, and to see if you wanted to go directly to pqm with only running the specific tests that had failed before, or if you wanted another full ec2 test run.
<bac> gary_poster: there is no time for a full ec2 run
<bac> PQM closes at our noon
<salgado> barry, how'd I test "r9498 [r=cprov][ui=rs] Make the Programming Languages inline editor a little wider. "?
<barry> salgado: go to any project that you can edit and that has a programming languages defined.  click on the pencil.  if you can still see the languages, it works :)
<salgado> barry, doesn't it have to be wider?
<barry> salgado: it used to be maybe 3 pixels wide
<bac> gary_poster: i feared the simple fix on the breadcrumbs would have lots of test failures.  thanks for working through them.
<gary_poster> bac: pqm closing at noon: ack.
<gary_poster> bac: I was farther along fixing tests that I had guessed.  Just completed, and am preparing to run the tests locally (i.e., make schema for db-devel).
<jml> meh.
<jml> was devel broken ~3.5 hours ago?
<jml> by which I mean db-devel.
<gary_poster> jml: don't know.  buildbot is happy so far
<jml> hmm.
<jml> I submitted an experimental branch and it had failures. I'm not sure they are all mine. They might be. I just don't know.
<gary_poster> jml: not definitive, but you could look for some of the failures in https://lpbuildbot.canonical.com/builders/db_lp/builds/119/steps/shell_7/logs/stdio (in progress) and see if some of them already have results there...
<jml> gary_poster, thanks.
<jml> I kind of wish that ec2 tested ones branch against stable.
<gary_poster> jml: it can, at least, even though that's not the default.  -b launchpad=stable
<gary_poster> (that's supposed to work at least)
<jml> gary_poster, but won't that pqm-submit to stable?
<gary_poster> jml: mm, yes, good point, by default.  you can override that but that starts to get wordy. :-/
<jml> gary_poster, do you think that running tests against stable & landing on devel would make a good default?
<barry> salgado: how can i test bug 423898?
<mup> Bug #423898: Should not rely on Navigation._publishTraverse() to have objects appended to request.traversed_objects <Launchpad Foundations:Fix Committed by salgado> <https://launchpad.net/bugs/423898>
<salgado> barry, that's a ?? one
<barry> salgado: cool, thanks
<salgado> forgot about it
<jml> I mean, that will miss errors due to other branches being landed on devel that have behaviour conflicts with yours that don't cause text conflicts and do cause test failures.
<bac> gary_poster: can you pastebin the tail end of the failure email that shows the tests that failed
<jml> but I'd guess that's quite rare.
<gary_poster> jml: not sure but maybe, agree, agree, in order. ;-)
<jml> gary_poster,  :)
<jml> it's certainly rarer than devel being broken.
<gary_poster> bac: is this what you wanted?  http://paste.ubuntu.com/276436/
<bac> gary_poster: exactly
<gary_poster> bac, ok, success: Ran 417 tests with 0 failures and 0 errors in 1 minutes 56.184 seconds.
<gary_poster> that's of all of the previously failing tests.
<gary_poster> bac: what do you want to do next?  review?  pqm?
<barry> salgado: do you have quick test plans for "r9556 [release-critical=bac][r=henninge][ui=none] Interpolate zope.i18nmessageid.message.Message strings in the text of leaf breadcrumbs so that the fmt:pagetitle formatter doesn't add non-interpolated text to the title." and...
<bac> gary_poster: have you pushed your changes to LP?
<barry> salgado: "r9569 [release-critical=bac][r=sinzui][ui=none] Fix the bug by only displaying bugs/blueprints summary for active milestones on a distro/product series main page."
<bac> gary_poster: create a MP
<bac> gary_poster: see if someone such as salgado can do a code review
<salgado> barry, yes, https://edge.launchpad.net/launchpad/+addquestion doesn't contain ${context} in the title, for the first
<gary_poster> bac: I am in middle of push now.  ok, will do.
<bac> gary_poster: scratch that
<gary_poster> bac: ok
<bac> gary_poster: add the incremental diff to your existing MP
<gary_poster> ok
<bac> gary_poster: i'll review the incremental
<salgado> barry, and https://edge.launchpad.net/ubuntu/jaunty only shows bugs/blueprint summary for the first two milestones
<bac> gary_poster: let me know when the push is done
<barry> salgado: thanks
<gary_poster> bac: push is done
<gary_poster> bac: incremental diff is up, and test command I used is beneath that
<bac> gary_poster: i've got a simple script that parses the failure message and re-runs the failing tests.  i'll publish it.
<gary_poster> bac: https://code.edge.launchpad.net/~gary/launchpad/breadcrumbs/+merge/12246
<gary_poster> bac: oh, cool!
<james_w> how far is http://paste.ubuntu.com/276442/ likely to be from working?
<bac> gary_poster: http://pastebin.ubuntu.com/276444/ -- it even lumps dependent stories together
<gary_poster> james_w: not sure.  leonardr should be back tomorrow.
<gary_poster> bac: nice!  +1 on adding it to utilities
<gary_poster> will meanwhile steal
<jml> yeah
<jml> xx-creating-branches.txt is failing
<gary_poster> how rude of it
<jml> I know. The cheek!
<ursula_> hey jml
<ursula_> weird to have you here this time of the day
<jml> ursula_, hello
<james_w> ok, I'll stop trying to blindly grope for this
<jml> Ursinha, get used to it :)
<Ursinha> jml, :)
<flacoste> bac: next (and probably last) buildbot run will start in 1h23
<jml> Ursinha, are you keeping normal hours now?
<Ursinha> jml, yes
<jml> flacoste, assuming the test failures are fixed by then :)
<bac> flacoste: perfect!
<flacoste> bac: given that the build time is ~3h5 we should be good for the 20:00UTC deadline
<flacoste> jml: test failures, what are you talking about?
<flacoste> we don't have test failures :-)
<jml> hmm.
<jml> so, I think that this branch which changes the "Code" tab to "Branches" is probably too late.
<jml> and xx-build-record.txt
<Ursinha> bac, I've added the MP links for all commits in registry's 2.2.8 test plan, so if you feel like testing... :)
<Ursinha> not all commits, only the NEEDSTESTING ones
<Ursinha> sorry
<bac> Ursinha: that's great.  did you have to do it manually?
<bac> Ursinha: can your script do it in the future?
<bac> salgado, barry, EdwinGrubbs: ^^
<Ursinha> bac, I did, because I couldn't seem to find how to access bug.linked_branches via api
<bac> Ursinha: it may not be exported.  if not we'll add it
<Ursinha> bac, but I'm planning yes to do that via searching on the commit for the branch nick, then, looking in lp for the MP
<Ursinha> (which is how I did it manually)
<Ursinha> so I've linked a bunch of branches to bugs
<Ursinha> yay for karma
<Ursinha> :)
<Ursinha> bigjools, just found one outstanding item from wgrant on Registry test plan, moved to soyuz
<Ursinha> bigjools, can you tell if that's ok?
<Ursinha> bigjools, https://dev.launchpad.net/SoyuzTestPlan/2.2.8
<deryck> the last template conversion has hit pqm.  9 minutes to spare! :)
<jml> heh heh
<jml> I've managed to avoid doing any migrations.
<jml> I'm very impressed & grateful for the work that's been put into it by others.
<deryck> jml, you missed all the fun!
<simon-o> Hi, could someone check the error ID OOPS-1362CEMAIL10? thanks
<bac> The last branch is playing in PQM now.  It is closed afterwards as we prepare to rollout LP 3.0.  Thanks everyone.
<salgado> abentley, can you help simon-o with https://lp-oops.canonical.com/oops.py/?oopsid=1362CEMAIL10 ?
<deryck> barry, ping
<abentley> salgado, simon-o: This is bug #426779 and will be fixed in the 3.0 release
<mup> Bug #426779: Error when sending mail to a code review for source package branch <package-branches> <Launchpad Bazaar Integration:Fix Committed> <https://launchpad.net/bugs/426779>
<james_w> hey simon-o
<simon-o> james_w: hi :)
<bigjools> Ursinha: that item is ok
<Ursinha> gud
<james_w> simon-o: I think I know how you caused that OOPS :-)
<Ursinha> bigjools, there are others untested in 3.0..
<bigjools> Ursinha: and I thought it had already been QA'ed ?
<simon-o> james_w: trying to send a response to the merge proposal :)
<Ursinha> bigjools, it wasn't on soyuz test plan
<Ursinha> bigjools, did you land that?
<bigjools> Ursinha: hmmm I saw it on there previously
<simon-o> james_w: I'll forward the patch upstream in the next few days, that what I wrote
<Ursinha> weirdÂ²
<james_w> simon-o: great, thanks
<Ursinha> bigjools, you're not wrong, it's indeed there
<bigjools> ;)
<Ursinha> bigjools, another thing :)
<simon-o> james_w: thanks for merging
<Ursinha> bigjools, do you know if https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1356A2776 is being caused by bad data?
<james_w> simon-o: oh, I haven't done that yet :-)
<simon-o> james_w: I know, but you will do it soon ;)
<bigjools> Ursinha: no, it's someone hacking a URL
<bigjools> in fact they put the +files stuff in sources.list by the look of it
<bigjools> sigh
<Ursinha> bigjools, I think I've filed one bug asking gently for a 404 instead
<bigjools> Ursinha: the bug is that it doesn't return 404
<Ursinha> :)
<bigjools> yep
<bigjools> Ursinha: it's a foundations bug I think
<Ursinha> bigjools, indeed: bug 403618
<mup> Bug #403618: Launchpad should return a 404 instead of ForbiddenAttibute OOPS <oops> <Launchpad Foundations:New> <https://launchpad.net/bugs/403618>
<bigjools> Ursinha: as usual you're one step ahead of me
<Ursinha> bigjools, haha
<flacoste> bac: buildbot failure :-(
<flacoste> xx-soyuzbuild-record and xx-creating-branches
<bigjools> noodles775 said that the former was broken by the changes to the registration slot, but I've not looked yet
<sinzui> they are broken by the slot.
<flacoste> yeah, Owner is gone from the output
<flacoste> and created... is also gone
<flacoste> anyone on the fix?
<sinzui> I can fix these. I need a break sprinting
<bac> flacoste: sorry was enjoying my chicken tikka
<Ursinha> hi sinzui, do you know how (or if) r9016 can be tested?
<flacoste> bac: actually, i probably need to do something similar, of course, in my case, it will be more like beet leaves masala with rice
<bac> ummm, beet leaves.
<flacoste> bac: sinzui is on the fix
<bac> flacoste: do we kill buildbot and restart it as soon as sinzui's fix is in?
<flacoste> depending on when it gets in and how the next build goes, we might be late for the release or release an earlier revision
<sinzui> I am almost done
<flacoste> bac: it will pick it up automatically
<bac> flacoste: right but do we want to wait for this one to finish?  i guess we should in case there are other surprises
<sinzui> bac: https://pastebin.canonical.com/22467/
<flacoste> bac: buildbot is currently idle and waiting for a new testfix revision
<flacoste> bac: all the missing changes will be tested along
<bac> flacoste: why is it idle?  how come it didn't keep going?
<flacoste> bac: because once it's encounters failures, it waits for a testfix
<bac> ah, it was the previous build that failed.  gotcha
<flacoste> exactly
<Ursinha> hey deryck[lunch], when you return: do you know who's on charge of testing abel's and wgrant's changes that are on bugs' test plan?
<sinzui> bac: flacoste my branch is pushed. are my changes good enough for an RC?
<bac> sinzui: looking
<bac> sinzui: it passed locally?
<sinzui> yes
<bac> rc=bac
<sinzui> I pull db-devel
<flacoste> sinzui: i guess you didn't submit your registration branch through ec2 first?
<sinzui> No,
<sinzui> I wll start using ec2 In October
<flacoste> sinzui: you definitively should!
<bigjools> I don't :)
<sinzui> I an not convinced. I and tim stepped on each other. It will always happen
<bigjools> Tim stepped on me at Allhands
<salgado> barry, did you see my comment/attachment on bug 434761?
<mup> Bug #434761: Make the home page pretty <story-ui-3> <Launchpad Registry:Fix Committed by barry> <https://launchpad.net/bugs/434761>
<flacoste> sinzui: i don't think you stepped on each other, your test run was with two unrelated changes
<flacoste> henninge and bigjools
<flacoste> from
<flacoste> i don't care if people use ec2 or not, i do care that the whole test suite passed with the changes
<flacoste> before merging
<flacoste> anyway, fix is in, i need food
<bigjools> beuno: around?
<sinzui> flacoste: xx-create-branches did not break from my changes. It broke when rockstar "Swapped Product and Owner in branch information"
<flacoste> sinzui: ah, ok, and that landed before you landed yours
<flacoste> sinzui: but after you tested
 * sinzui has another name for gannotate...witness
<flacoste> fair enough
<Ursinha> sinzui, I"m doing QA in one of your landings and doing what's described in the MP it's not having the expected behavior
<flacoste> integration failures happen, that's why we have buildbot
<Ursinha> s/it's/is/
<sinzui> Ursinha: no doubt The rules changes so often over 60 days I have not faith in any instruction I wrote. That I why I stopped working on the header
<bigjools> does anyone have an example URL where the lazr-js overlay text alignment is broken?  I need to q/a noodles775's fix
<bigjools> Ursinha?
<beuno> bigjools, yes. Hi.
<Ursinha> bigjools, oops, don't know
<bigjools> beuno! aha see my question --^%
<sinzui> Ursinha: if you are asking about 9016 (base-layout requries the callsite to pass the <h1> for theheading slot so that the title edit widget works.) My code is gone. Barry re wrote the entire feature and the rules changed substantially.
<noodles775> bigjools: yep, changing a bug status on the bug index.
<sinzui> Ursinha: The problem that branch was solving was to allow bug and project titles to be edited
 * sinzui tries
<bigjools> noodles775: great thanks
<Ursinha> sinzui, oh, right
<beuno> bigjools, bug statuses
<Ursinha> sinzui, I'll move it to ?? and add this comment
<sinzui> Ursinha: I can edit my project https://edge.launchpad.net/gdp, however, I see the cancel and commit buttons *in* th field
<sinzui> Ursinha: The buttons work
<Ursinha> sinzui, but the item I'm QAing is r9026
<rockstar> sinzui, wait, what?
<rockstar> sinzui, I ran my changes through ec2 and there weren't any breakages.
 * sinzui shrugs
<sinzui> Ursinha: we cannot test that without god-like powers
<sinzui> Ursinha: the baltix owner has used the feature since the change
<sinzui> Ursinha: with god-like power, choose the edit hardy on staging. in the version field, enter '8.04 LTS' <- the space and the letters are not valid versions
<Ursinha> sinzui, I've asked god-like powers, and entered +addseries
<Ursinha> and followed the steps you mentioned in the MP
<sinzui> Ursinha: addseries now appears on the distro index page
<Ursinha> sinzui, I see
<Ursinha> sinzui, so, adding 'invalid' in the Version field gives me a "'invalid': Bad upstream version format"
<sinzui> yep that is what a debversio looks like
<Ursinha> sinzui, adding '10.06 LTS' gives a "10.06 LTS is not a valid version"
<sinzui> yes it is not
<Ursinha> and adding '9.06' works and creates the series
<sinzui> 10.6 is good, so is 10.6.10
<Ursinha> sinzui, in the MP it says 9.06 should give an err as well
<sinzui> Ursinha: there was a database oops instead of an error message before
<Ursinha> but it succeeded
<sinzui> Ursinha: I am mistaken that is good
<Ursinha> cool :)
<Ursinha> so it's working, woot
<Ursinha> !
<salgado> sinzui, has bug 416686 actually been fixed?  i see a rather long list of projects on https://edge.launchpad.net/launchpad-project?
<mup> Bug #416686: Project group's project portlet can be too long <story-ui-3> <Launchpad Registry:Fix Committed by sinzui> <https://launchpad.net/bugs/416686>
<sinzui> salgado: yes, all the "latest" portlets are pushed to the left
<salgado> sinzui, oh, ok.  I thought the fix was to limit the number of projects in the portlet
<sinzui> salgado: we have never discussed limiting the the number to projects to display. In fact beuno did not like the suggestion
<sinzui> salgado: gnome is worse because we print milestones that are from 10 years ago
<salgado> ouch
* bac changed the topic of #launchpad-dev to:  This is Launchpad Development Channel | Week 4 of 3.0 | PQM is closed - Release manager is bac - contact for release-critical | https://dev.launchpad.net/CurrentRolloutBlockers | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/ |
<sinzui> bac: The fix is merged
<bac> sinzui: and we're off to the races
<sinzui> I prefer a Night at the Opera
<deryck> Ursinha, sorry, just saw the scrollback....
<deryck> Ursinha, I'll take a look at wgrant's stuff.  we'll have to figure out what to do about abel's if it's all hwdb stuff.
<Ursinha> deryck, I see
<deryck> Ursinha, but I can look soon here at the state of things on the test plans.
<Ursinha> deryck, it would be much appreciated
<deryck> certainly.  will do.
<Ursinha> deryck, thanks :)
<Ursinha-brb> be right back for some food
<barry> has anybody seen this problem recently when trying to do a 'make schema', or more importantly know what to do about it?
<bac> hi rockstar
<bac> barry: which problem would that be?
<barry> * Creating database "launchpad_empty".
<barry> Giving up waiting for connections to template1 to drop.
<barry> 1 connections by postgres to template1
<barry> make[1]: *** [create] Error 10
<barry> make[1]: Leaving directory `/home/barry/projects/launchpad/db-devel/database/schema'
<barry> make: *** [schema] Error 2
<barry>  
<rockstar> bac, hi.
<bac> rockstar: you know much about branch subscriptions?
<barry> bac: ^^ note that's after /etc/init.d/postgresql-8.3 restart
<bac> barry: i've not seen that
<rockstar> bac, yeah, what's up?
<barry> bac: how did you make it go away?
<bac> barry: let me rephrase:  i've not ever seen that
<barry> bac: oh :)
<bac> rockstar: i'm subscribed to devel and db-devel with identical settings.  for devel i get all the landing email.  for db-devel i get nothing.
<rockstar> bac, huh.  That's odd.
<bac> yeah
<rockstar> bac, you're sure it's the same settings?
 * rockstar wonders if there's an oops happening somewhere.
<bac> rockstar: yep
<rockstar> bac, check your spam filters?
<bac> rockstar: don't have any.  i'll looking at my log files on the mail server to see if it they arrive or not
<bac> rockstar: found them!
 * bac needs to garden .procmailrc a little better
<rockstar> bac, hooray!  Not a bug!
<bac> my bug!
<bac> fixed!
<barry> beuno: ping
<beuno> barry, hi
<barry> beuno: hi.  i'm qa'ing bug 434399 and have two questions
<mup> Bug #434399: registering slot is in a terrible place <ui> <Launchpad Foundations:Fix Committed by sinzui> <Launchpad Bugs:Fix Committed> <https://launchpad.net/bugs/434399>
<barry> the first is; i've noticed that the horiz line below the app tabs is gone now.  why?
<beuno> barry, I removed it
<beuno> it... didn't feel right
<barry> really?  it doesn't seem right without it
<beuno> well, it crossed logos
<beuno> so it made them look bad
<barry> beuno: that was definitely a problem.  now though it feels like the watermark/tabs bleed into the body content too much
<barry> beuno: if that crossing of the logos could be fixed, would you want them back, or are you happy they're gone?
<beuno> barry, I'm 50/50 on this
<beuno> if it doesn't cross the logos, I don't care much about it
<barry> beuno: good enough for me (i may play with that then)
<barry> beuno: second question...
<barry> beuno: is the registering slot on this page: https://code.launchpad.dev/~name12/gnome-terminal/scanned where you want it?
<beuno> barry, screenshot?
<sinzui> barry: does the person page use the regstering slot?
<barry> beuno: sure, sec
<rockstar> barry, it's definitely not where I want it.
 * sinzui does not think person or team uses it
<rockstar> barry, thumper and I talked about it, and we wanted it moved, but yesterday it sounded like sinzui was working on that.
<barry> beuno: http://people.canonical.com/~barry/registering.png
<beuno> barry, it's in the right place I think
<barry> rockstar: i'm qa'ing that bug, so that's what i'm trying to figure out
<beuno> where it is everywhere else
<rockstar> barry, that's MUCH better!  Thanks!
<beuno> but
<beuno> of course
<beuno> it shouldn
<bac> rockstar: another code question -- this one about branch visibility.
<beuno> shouldn't break naviation like that...
<rockstar> bac, shoot.
<barry> beuno: not sure what you mean by "break navigation"
<bac> rockstar: i thought projects within a project group inherited the branch visibility settings from the project group
<rockstar> barry, answers is below everything else.
<barry> rockstar: i would like it a lot better with a horizontal line below it :)
<bac> i'm looking at a project group now but see no way to set branch visi
<beuno> barry, it moves answers down
<beuno> "wraps" it
<rockstar> beuno, you and I are seeing the same thing.
<barry> beuno, rockstar oh!  yeah that sucks :)
<sinzui> barry: beuno: These are the only pages that were converted to use registering: http://pastebin.ubuntu.com/276515/
<rockstar> bac, I also thought that's how it worked.  Are you finding that's not the case?
<bac> rockstar: i bet i know what it is
<bac> i think i gave permission for setting branch vis to lp.ProjectReview only on projects not project groups
<barry> sinzui: but i think i have to mark your branch as BAD because of the wrapped tabs
<sinzui> barry: I do not care. I am happy for someone else to fix it
<barry> sinzui: aight
<sinzui> barry: I do not think modified belongs in the registration information. The template passes who and when.
<sinzui> barry: The IRegistration adapter we wanted to use only provides registrant and date.
<barry> sinzui: at worst, s/and/<br>/
<sinzui> barry: I wonder if we dare to insist that the slot be replaced with an IRegistration adapter that the current 10 callsites must provide, and any future object will also write
<barry> sinzui: possibly.  it's something to think about.  10 call sites is not that bad
<sinzui> barry: the pain point was <owner|creator|maintainer|registrant> <dateccreated|date_created|>
<barry> sinzui: heh, it should would be nice to have consistency there
<barry> sinzui: is there a bug or qa plan for "r8507 [release-critical=bac][r=jml][ui=beuno] Make the watermark link to the root context when viewing another context. "
<sinzui> umm
 * sinzui thinks
<sinzui> firefox logo on series and milestones go to firefox. firefox does not link
<barry> sinzui: i got the first part, but i don't understand "firefox does not link"
<sinzui> firefox does not link to itself
<barry> sinzui: got it, thanks
<barry> gary_poster: ping
<gary_poster> barry: back in a sec, that ok?
<barry> gary_poster: yep, not urgent
<gary_poster> cool will ping you
<barry> gary_poster: thanks
<barry> EdwinGrubbs: are you qa'ing 2.2.8 stuff?
<EdwinGrubbs> barry: yes, and so was matsubara
<barry> cool.  i don't want to step on any toes
<gary_poster> barry: ping
<jml> mwhudson, I've just sent a review your way.
<mwhudson> jml: hello
<mwhudson> jml: you might be a little interested in bzr+ssh://bazaar.launchpad.net/~mwhudson/launchpad/ami-from-scratch
<mwhudson> (it's not ready for review yet)
* Chex changed the topic of #launchpad-dev to:  This is Launchpad Development Channel | Week 4 of 3.0 | PQM is closed - Release manager is bac - contact for release-critical | https://dev.launchpad.net/CurrentRolloutBlockers | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/ | Launchpad will be down/in read-only from 22:00 UTC until
* Chex changed the topic of #launchpad-dev to:  This is Launchpad Development Channel | Week 4 of 3.0 | Launchpad will be down/in read-only from 22:00 UTC until 23:00 UTC for a code updatePQM is closed - Release manager is bac - contact for release-critical | https://dev.launchpad.net/CurrentRolloutBlockers | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: ht
* Chex changed the topic of #launchpad-dev to:  This is Launchpad Development Channel | Week 4 of 3.0 | Launchpad will be down/in read-only from 22:00 UTC until 23:00 UTC for a code update | PQM is closed - Release manager is bac - contact for release-critical | https://dev.launchpad.net/CurrentRolloutBlockers | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged:
<EdwinGrubbs> cprov: ping
<gary_poster> yay for buildbot passing!
<thumper> morning
<mrevell> morning thumper
<thumper> mrevell: hey
<mwhudson> the race to revision 10000 is on
<barry> mwhudson: the winner gets 10000 tootsie rolls
<thumper> flacoste: ping
<flacoste> hi thumper
<thumper> flacoste: can we have a chat in 5 or 10m?
<flacoste> thumper: 5 is best, i have a parent meeting at daycare in 30 minutes
<thumper> ok
<barry> thumper, mwhudson, rockstar and now there were 3.  are you guys up for meeting in 45m?
<thumper> yeah
<mwhudson> barry: sure
<barry> cool
<mwhudson> we really should test codehosting in read only mode on staging this cycle
<cprov> EdwinGrubbs: pong
<EdwinGrubbs> cprov: nevermind, I answered my own question
<cprov> EdwinGrubbs: okay
<jml> mwhudson, I'll take a look if I can :)
<jml> mwhudson, thanks for the pointer.
<mwhudson> jml: np
<mwhudson> jml: i would be looking at your branch, but rollout etc :)
<mwhudson> jml: how is london treating you so far?
<jml> mwhudson, understood.
<jml> mwhudson, it's very, very busy.
<mwhudson> yes
<jml> mwhudson, my auto-land branch is obviously not urgent, but I expect a lot of people will find it useful, and it probably won't get much better until people actually use it.
<wgrant> When's the team lead sprint? Next week?
<mwhudson> jml: yes, it's clearly a good idea
<mwhudson> jml: would it be correct to say "gosh, this would all be easier if launchpad used python 2.5" ?
<jml> mwhudson, yes. entirely.
<barry> mwhudson, thumper, rockstar, wgrant, jml (if you want) -> #launchpad-meeting in 2m
<wgrant> mwhudson: Barring a few Karmic EC2 bugs and what appeared to be a broken instance, I was able to create a Karmic AMI and run the test suite on it.
<mwhudson> wgrant: yay!
<wgrant> So everything works, even for contributors. Well done.
<jml> barry, I'll pass.
<barry> jml: no worries
<mwhudson> wgrant: cool, just need to get the branch reviewed & landed and then i can make the image public
<wgrant> Did the bad blog post on the front page get fixed?
<wgrant> (I would check myself, but there is no codehosting)
#launchpad-dev 2009-09-24
<beuno> mrevell, ping?
<mrevell> hi beuno
<beuno> blog posts seem to be coming up, but some can't be accessed, although they are linked?
<beuno> wow, I didn't *really* expect you to be around  :)
<mrevell> beuno: Hi man. No, I didn't expect to be around :) The posts are there but they're not due to be published until 3.0 is released. I don't wanna publish a 3.0 announcement before the 3.0 release :) It just sucks that edge links to broken blog posts. Hopefully next cycle we'll have a real live blog feed there instead.
<beuno> mrevell, but this has already been published: http://blog.launchpad.net/releases/launchpad-3-0-is-here-new-ui-and-more
<beuno> but the links to teh interviews haven't
<mrevell> beuno: Then that's me getting confused by which timezone the blog server is running on :) Being as we're supposed to be released shortly I'll bring forward the interview publication. Thanks for pointing that out.
<beuno> mrevell, thank you
<beuno> and
<beuno> go to bed  :)
<beuno> I'm in an Ubuntu board meeting
<beuno> that's my excuse
<mrevell> beuno: heh :) You don't even have a different timezone to excuse you :)
<wgrant> mrevell: Typo in the first post.
<wgrant> s/weere/were/
<mrevell> wgrant: thanks, fixed
<mrevell> I'm going to lie down for a while, night all
<wgrant> Night mrevell.
<wgrant> So that's what the Technical Architect does. What does the Project Strategist do?
<lifeless> you tell us:P
<lifeless> what does jml do ?
<rockstar> thumper, do you happen to be packing, or is that what tomorrow is for?
<wgrant> The front page now tells me that Ubuntu is related to MySQL.
<thumper> rockstar: I pack on the day normally
<rockstar> thumper, well, what I was exploring is whether or not you'll be around tomorrow or if you're leaving tomorrow.
<thumper> rockstar: I leave in 2 days time
<rockstar> thumper, okay, so we can chat tomorrow.
<thumper> rockstar: yes we can
<thumper> rockstar: how's your voice?
<bac> rockstar: have you tried lp.net since it came back up?
<thumper> is it back?
<bac> sort of
<rockstar> bac, just looking now.
<bac> rockstar: disable redirection and see if you get styling
<rockstar> I don't have tabs on the home page.
<bac> i am not
<thumper> gah
<bac> yeah, no tabs.  works on edge
<rockstar> bac, it doesn't work on edge for me.
<rockstar> Oh, well, now I do.
<bac> rockstar: did you do a force reload/whatever
<Ursinha> I used to hate those tabs
<thumper> the coloured numbers have gone :(
<thumper> edge looks good
<wgrant> Woah, got a strange CSS breakage on bugs.launchpad.net. The watermark content was stacked vertically.
<wgrant> Hm. Reproducable.
<rockstar> Yeah, seems that production isn't doing CSS at all.
<Ursinha> same here
<wgrant> Argh, bugtask index regression for bugs with lots of tasks.
<poolie> spm, there's nothing else in there aside from my mail headers
<poolie> i can forward them
<spm> poolie: please
<poolie> as an rt, or just to you, or in a bug?
<poolie> spm: http://pastebin.ubuntu.com/276652/
<spm> paste is fine. :-)
<maxb> From the live frontpage: "#
<maxb> # Launchpad now open source! â 21 Jul 2009
<maxb> Translate a phrase once, have it show up in all your releases.
<maxb> "
<poolie> heh
<maxb> blog integration fail :-/
<poolie> http://failblog.org/2008/07/22/translation-fail/
<poolie> Also:
<poolie> > If you're ready, you can: Read the user guide
<lifeless> classic
<poolie> ooh, am i ready for that?
<poolie> i don't know...
 * thumper -> lunch
<wgrant> The layout of the featured project section is a bit misleading if the day's project is a project group.
<poolie> mm, and they have watery descriptions
<poolie> or the netrek one does
<wgrant> MySQL's was much much worse.
<wgrant> But that was only up for an hour.
* Chex changed the topic of #launchpad-dev to:  This is Launchpad Development Channel | Week 4 of 3.0 | PQM is closed - Release manager is bac - contact for release-critical | https://dev.launchpad.net/CurrentRolloutBlockers | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/
<wgrant> The first blog post link is still broken.
<wgrant> Though the article is available.
 * mwhudson lunches
<poolie> spm, i got another bounce from forster 8m ago
<spm> poolie: yeah, still working on it
<thumper> mwhudson: any reason why we don't allow git imports over https?
<mwhudson> thumper: i didn't know git worked over https
<mwhudson> thumper: it's probably just a matter of relaxing the Field?
 * thumper nods
<thumper> mwhudson: do you have the bzr-git plugin locally?
<mwhudson> thumper: sometimes
<mwhudson> doesn't seem like i do right now
<thumper> hmm, ok
<spm> poolie: fyi. should all be good now.
<wgrant> How does the freeze go after release? Does everything remain frozen until after the reroll?
<wgrant> OOPS-1363EC162
<wgrant> I cannot file an Ubuntu bug on edge, although it works on production.
<wgrant> Aha.
<wgrant> I think I know why.
<wgrant> Nrrrrg @ last-minute changes with incomplete tests.
<wgrant> Is that OOPS complaining that a DistributionSourcePackage has no bug_supervisor?
<thumper> wgrant: I'll look for you
<thumper> wgrant: although may need to wait a few minutes as oopses are synced every 10 minutes
<wgrant> Odd that it doesn't affect production, though. Does the production config not have malone.ubuntu_disable_filebug enabled?
<poolie> thumper: it looks like the merges sent in email when new mps are created include conflict markers?
<poolie> nm, mwh confirmed it's by design
<mwhudson> wgrant: ForbiddenAttribute: ('bug_supervisor', <lp.registry.model.distributionsourcepackage.DistributionSourcePackage object at 0xbe86dd0>)
<mwhudson> wgrant: so yes, you're basically right
<wgrant> mwhudson: Great.
<wgrant> Thanks.
<mwhudson> thumper: can you review https://code.edge.launchpad.net/~mwhudson/launchpad/puller-proxy-argh/+merge/12327 ?
 * thumper looks
<thumper> mwhudson: what about hosted branches?
<mwhudson> thumper: we access them over a fancy local transport basically
<thumper> but needs proxy or doesn't care?
<mwhudson> isn't involved
<mwhudson> so doesn't care
<thumper> ok
 * thumper waits for the diff
<thumper> mwhudson: I think I have a test to confirm recording the failure
<thumper> but making schema right now
<thumper> mwhudson: done
<thumper> mwhudson: I asked for bac to rc it
<thumper> I'm wondering how often the mail processor runs though
<thumper> hmm,
<thumper> it failed for some reason
<thumper> :(
 * thumper looks for the oops
<thumper> fuck!!!"
<thumper> FFS
 * thumper shakes his fists
 * thumper wants to curl up into a ball
<mwhudson> thumper: ?
<thumper> mwhudson: when I tried to request bac using email https://lp-oops.canonical.com/oops.py/?oopsid=1363CEMAIL1
 * thumper is making another branch
<thumper> mwhudson: https://code.edge.launchpad.net/~thumper/launchpad/job-fail/+merge/12328
<mwhudson> thumper: aaaaaaa
<mwhudson> thumper: also, "huh" ?
<thumper> mwhudson: when I request another reviewer, we send them email
<thumper> mwhudson: which includes the diff
<mwhudson> it would be rare to have missing permissions for the launchpad user
<mwhudson> dbuser
<mwhudson> thumper: yeah
<thumper> mwhudson: the process mail script tried to send the mail
<mwhudson> thumper: oh!
<thumper> yeah
<mwhudson> la-di-da
<mwhudson> wgrant: btw my ami-from-scratch branch should now let you make an image based on an arbitrary one and run the tests
<mwhudson> wgrant: for example ec2 test -m based-on:<some blank ami>
<wgrant> mwhudson: Very nice.
<wgrant> mwhudson: Although I certainly see why they need pre-population.
<mwhudson> (i haven't tried a non-hardy base yet, but i don't know of a reason why it might not work)
<wgrant> The checkout of RF is sloooow.
<wgrant> mwhudson: The sources.list entries are hardcoded, for one thing.
<mwhudson> wgrant: not any more :)
<wgrant> mwhudson: Ah, handy.
<wgrant> mwhudson: Apart from that it works OK.
<mwhudson> wgrant: cool
<wgrant> The only other change I made that wasn't a workaround for a Karmic bug was adding '-o Apt::Install-Recommends=no' to the apt-get arguments to avoid downloading so much crap.
<mwhudson> ah ok
<mwhudson> that's probably a good idea
<mwhudson> wgrant: could you do that with /etc/apt/preferences or some similar file too?
<wgrant> mwhudson: You could.
<wgrant> And I do normally.
<wgrant> I forget the incantation.
 * wgrant hunts.
<wgrant> APT::Install-Recommends "false";
<wgrant> In a file somewhere in /etc/apt/apt.conf.d
<thumper> mwhudson: I have a test for the permission failure too
<mwhudson> thumper: cool
<mwhudson> thumper: i reviewed your first branch
<thumper> mwhudson: ta
<thumper> test just pushed up
<thumper> the diff should update shortly \o/
<thumper> I confirmed it failed with the same error first
<thumper> and then it passed after I made schema
<thumper> mwhudson: and on that note, I'm EODing
<thumper> I'll check later
<thumper> mwhudson: thanks for the reviews
<mwhudson> thumper: ok
 * mwhudson eods
<noodles775> Morning all.
<spm> hey noodles775
<mwhudson> morning noodles775
<noodles775> hi guys :)
<spm> mwhudson: that eod thing.... didn't your folks tell you that telling lies is naughty? ;-)
<mwhudson> spm: emma's away at the moment so i don't get told off for coming back to the computer in the evening :)
<spm> haha
<jml> so, what's up in #launchpad-dev?
<lifeless> stuf
<lifeless> f
<lifeless> f
<mwhudson> jml: i greet you as you greeted me this morning!
<jml> mwhudson, with something to review? :)
<mwhudson> jml: yes
<jml> mwhudson, wonderful.
<noodles775> Thanks BjornT for updating the windmill infrastructure! (I'm just catching up on email). Being able to use the factory will be *very* helpful for soyuz windmill tests!
<noodles775> heh... gone.
<noodles775> Thanks BjornT for updating the windmill infrastructure! (I'm just catching up on email). Being able to use the factory will be *very* helpful for soyuz windmill tests!
<BjornT> noodles775: np. it was actually quite fun :)
<lifeless> ouch
<lifeless> I just read the current rocketfuel-setup...
<lifeless> its quite the little dpkg replacement not
<lifeless> s/not/now/
<wgrant> Why?
<lifeless> installing files into your system wide path
<lifeless> [I'm not mentioning the appalling amount of system that make install does]
<wgrant> So it does.
<wgrant> install has always scared me a bit.
<wgrant> I don't normally expect a make target to eat my Apache.
<lifeless> indeed
<mwhudson> apache :(
<mwhudson> i have this cunning plan to take it away and use a twisted web server instead of apache
<mwhudson> allenap: fancy a call in a bit?
<allenap> mwhudson: Yeah, sure. 5 minutes okay?
<mwhudson> allenap: a bit more than that would be better, actually
<mwhudson> allenap: 35 mins?
<allenap> mwhudson: Yeah, that works too. 0830 UTC then.
<mwhudson> cool
<jml> mwhudson, you mean a tornado server, right :P
<mwhudson> jml: oh yes, rigth
<jml> mwhudson, was my unannounced diff > 800 lines?
<mwhudson> jml: i think it's 850
<mwhudson> jml: if you don't have time to review it, no worries
<mwhudson> jml: it's not going to land until monday or so anyway, after all
<mrevell> Morning
<jml> I love the 3.0 UI, but it's making me realize how much more awesome Launchpad could be.
<wgrant> There must be a better place for the registration slot.
<wgrant> It currently sits a few pixels below the level of the tabs, which doesn't make sense and looks beyond strange.
<mwhudson> jml: well a path between here and there is your job :)
<jml> mwhudson, yes :)
<jml> mwhudson, I was just looking at your merge proposal and realized that it fixed a bug that wgrant filed... way too many clicks for me to tell Launchpad at that
<jml> s/at/about/
<wgrant> Which bug did I file?
<mwhudson> public ec2 image one
<jml> no!
<mwhudson> no?
<jml> "rocketfuel-setup is broken"
<mwhudson> oh right
<wgrant> Ah. Excellent.
<jml> but I had to open the branch page, then open a bugs page, search for the bug to find the ID and then copy paste it into the branch page and then close both tabs and return to the MP
<wgrant> The MP page normally shows the bugs for me.
<wgrant> But I didn't see an email about that branch being linked.
<wgrant> So mwhudson didn't tell bzr.
<wgrant> So LP could not have known.
<jml> wgrant, why can't I link a bug from the MP page?
<jml> wgrant, why does the bug/branch link form not let me search for bugs?
<jml> that's what I mean.
<wgrant> Oh, right, I misread that you couldn't see from the MP page that it fixed the bug.
<wgrant> Sorry.
<wgrant> jml: So, what does the Project Strategist do?
<spm> wgrant: "other duties as directed" ;-)
<jml> wgrant, run around like a headless chook making macabrely distorted clucking noises
<wgrant> jml: Ah, excellent. that is what the project has been missing all these years.
<allenap> mwhudson: Ready when you are, but I'm in no rush.
<jml> wgrant, more seriously, define our overall strategy, get people excited about it, define features, listen to stakeholders, review db patches.
<mwhudson> allenap: now works for me
<wgrant> jml: Aha.
<wgrant> I've been wondering for a while whether LP branches are redistributable. Don't they contain a whole lot of proprietary, undistributable code without a license that we're not even meant to have?
<jml> wgrant, answering such questions is not the responsibility of the Product Strategist.
 * jml reviews patches
<mwhudson> allenap: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/422385
<mup> Bug #422385: Graph of test run times <build-infrastructure> <test-system> <Launchpad Foundations:New> <https://launchpad.net/bugs/422385>
<henninge> sinzui: Hi!
<sinzui> hi henninge
<henninge> sinzui: I just reported bug 435712 and bug 435743
<mup> Bug #435712: Move registration and status informartion from heading slot to main and registering slot. <story-ui-3> <Launchpad Answers:Triaged> <https://launchpad.net/bugs/435712>
<mup> Bug #435743: Bread crumb missing for a single question <Launchpad Answers:New> <https://launchpad.net/bugs/435743>
<sinzui> hmm
<henninge> sinzui: is that planned to be fixed already or shall I prepare a branch?
<sinzui> I wonder if that relates to the FAQ bug I reported two weeks ago
<henninge> sinzui: well, that title is borked, too.
<sinzui> henninge: rockstar is handling Answers. If you see an opportunity to fix it please do
<henninge> Launchpad itself FAQ #44: "Is it possible to link a project to packages in a PPA?"
<henninge> sinzui: OK, just wanted to avoid doubled work.
<sinzui> henninge: I report that there are no titles on faqs
<henninge> sinzui: there is now but it's too verbose.
<henninge> sinzui: I'll just update the bug description
<bigjools> wgrant: yo
<sinzui> henninge: They FAQ title issue may be harder. I talked to rockstar about this and we discovered that FAQ does not have a view, the ZCML is generating a view for the template and IFAQ. If making a view with a page_title is hard, consider it out of scope.
<wgrant> bigjools: Hi. You want my priorities?
<bigjools> wgrant: how did you guess
<henninge> sinzui: OK, I just updated the bug for now.
<wgrant> bigjools: Less than 30 seconds before you called I decided I should start collating them.
<henninge> bac: do I submit 3.0 UI fixes to db-devel to be included in the 2nd roll-out?
<bigjools> wgrant: the deadline expired already!  But since you're so great I will make an exception.
<wgrant> bigjools: I'm not sure I can give any valid data. That's why I've not responded.
<sinzui> wgrant: I would like your priorities for Registry, If you can find time to think about it, I would appreciate it.
<wgrant> bigjools: The only real wish I had was from an archive admin, and that is to make the queue page suck less.
<wgrant> I cannot give any more on behalf of MOTU.
<bigjools> wgrant: yeah, that page is major suck.  Any insights into how to make it better are gratefully received
<wgrant> bigjools: Well, there are a couple of people doing archive admin without shell access now, so it might be possible to get input.
<bigjools> wgrant: understanding the MOTU workflow would be a good start
<wgrant> sinzui: Why does MOTU have input for Registry?
<sinzui> wgrant: Because Registry owns distro, distroseries, distrosourcepackages, sourcepackages.
<sinzui> wgrant: maybe I do not need your help with these, but I think you may have insights into how we can improve the workflow for linking packages to upstream, and ensuring the information and actions use need on those pages are present.
<wgrant> sinzui: Ah, I completely forgot that somebody owned packagings. They haven't been touched in years.
<wgrant> Anyway, fooding.
<deryck> Morning, all.
<noodles775> hiya deryck
<wgrant> deryck: Morning. Sorry for not getting priorities to you on time, but I do now have one.
<wgrant> Version tracking.
<deryck> wgrant, hi.  no worries.  can you explain a bit what you mean?
<wgrant> deryck: At the moment there's no way to tell in which version of a package or project a bug is present.
<wgrant> deryck: This really sucks.
<noodles775> wgrant: regarding the queue... although we didn't get to do it as part of 3-0, we started documenting a lot of the use-cases etc. at https://dev.launchpad.net/SoyuzDistroSeriesQueueImprovementsSpec (and the page linked from it).
<wgrant> The Debian BTS allows people to track in which version a bug is present, and in which it was fixed. It sucks less.
<deryck> wgrant, ok, gotcha
<jml> deryck, good morning.
<jml> deryck, I feel I should draw your attention to https://bugs.edge.launchpad.net/malone/+bug/435651
<mup> Bug #435651: Unable to edit bugs <Launchpad Bugs:New> <https://launchpad.net/bugs/435651>
<wgrant> noodles775: I think I've seen that before.
<wgrant> jml: ScottK was.... displeased, to say the least, about that.
<deryck> jml, yes, that's a dupe of another bug.  it's a high priority, in the really really high sense of the word high. :)
<deryck> jml, that is coming up a lot.
<jml> deryck, ok, that's good news :)
<noodles775> wgrant: yep - I got you to contribute to it back then - I just meant that it'd be good to continue documenting there (if people have ideas/issues) so we can address needs properly this time (I think there's been a few attempts).
<jml> wgrant, I'd be very upset if it affected me.
<deryck> jml, I had wanted to fix it this week, but just not enough hours in the day.
<jml> deryck, understood. it's been an unusually busy week, to say the least.
<deryck> indeed
<jml> actually, just thinking about this whole mess makes me want to purchase a muffin.
<jml> I think I'll do that.
<lifeless> deryck: if its high priority, can I humbly suggest it's metadata be updated accordingly?
 * lifeless finds the new location to look for dups
<lifeless> is there a bug that 'is a dup is not part of the main /data/ area for bugs ?
<beuno> lifeless, no. It's a global action, so it went into the global actions menu
<wgrant> It's not global.
<lifeless> beuno: *setting* it is global. READING it is now.
<wgrant> It's no more global than the status.
<lifeless> s/now/not/
<beuno> ah
<beuno> yes
<beuno> so, deryck inherited a branch from me that fixes that
<beuno> removes the bugtask table for dupes, with a big ass message telling you it's a dupe of X
<beuno> with a link
<beuno> as in "nothing to see here, move along"
<lifeless> nice
<lifeless> though perhaps having the table greyed out or something would be useful for folk trying to decide if the bug realyl isa dup
<beuno> do yuo think the table gives you information about the bug?
<beuno> rather than the description and comments?
<jml> beuno, if it affects more than one project, it gives you info
<beuno> a little bit, yes
<jml> beuno, yes, a little.
<beuno> that needs some thought then
<jml> beuno, this is a tangent, but...
<jml> beuno, what if we made /bugs/NNNN be the canonical_url of a bug
<lifeless> beuno: /data/ gives me data.
<lifeless> beuno: how much from that particular atom? I don't know; but I know its easier to ignore something greyed out than write an API call to read it when its hidden.
<beuno> jml, I'm all for that
<jml> beuno, what would the page look like for bugs with multiple tasks?
<jml> (bearing in mind that dupe bugs won't show the task table)
<beuno> jml, when there's a contextless URL?
<jml> beuno, yeah.
<beuno> yeah, it gets interesting
<beuno> no logo, no links to other bugs...
<beuno> (when you have multiple bugtasks)
<beuno> we spent a lot of time talking about it in the BA bugs UI sprint
<beuno> there are probably mockups of it...
<beuno> let me find it...
<beuno> (the quick answer is: other parts of Launchpad need changing)
<deryck> lifeless, sorry was on call.  it's ok now?  This was just confusion over where dupe info is displayed?
<beuno> ok, no mockups
<jml> where are the docs describing the rules for commit messages on Launchpad?
<lifeless> deryck: yah, you said 'bug X is high and I mean really high', but it claimed to be unconfirmed, new.
<lifeless> deryck: then I saw that it was a dup.
<deryck> lifeless, gotcha.
<lifeless> \o/ just got a team joining mail that referenced launchpad.dev
<james_w> lifeless: a bit like bug 357336?
<mup> Bug #357336: "You have been added to <team>" mail contains invalid (API) link <api> <Launchpad Registry:Fix Released by bjornt> <https://launchpad.net/bugs/357336>
<danilos> noodles775: hi, I am going to fix one small UI bug in translations, and I wonder if you have a minute to discuss a proper fix for https://bugs.edge.launchpad.net/launchpad/+bug/435346 (i.e. where should I include style="clear:both;" :)
<mup> Bug #435346: 3.0 interface overflows sidebars and causes horizontal scrolling if you manually change browser font sizes <Launchpad itself:New> <https://launchpad.net/bugs/435346>
<danilos> jtv: ping
<lifeless> james_w: sounds like it indeed
<lifeless> bug 435834
<mup> Bug #435834: Translator comment needed for links <i18n> <Ubiquity Slideshow for Ubuntu:New> <ubiquity-slideshow-ubuntu (Ubuntu):New> <https://launchpad.net/bugs/435834>
<lifeless> bug 435843
<mup> Bug #435843: team welcome mail references launchpad.dev <Launchpad itself:New> <https://launchpad.net/bugs/435843>
<lifeless> ^^^
<wgrant> Huh. It's actually hardcoded in the email snippet.
<lifeless> wgrant: I assumed so when I saw it
<lifeless> wgrant: as I couldn't see API's generating that particular URL :P
<noodles775> danilos: sure... looking now.
<danilos> noodles775: thanks
<mrevell> jml: ping
<noodles775> danilos: so adding clear:both to the #maincontent rule (style-3-0.css line 7) is probably a good place...
<noodles775> danilos: it fixes the issue for me in FF with mthaddon's setup.
<noodles775> danilos: can you test that in epiphany?
<danilos> noodles775: sure
<purserj> just out of curiosity, is there an admin panel type setup for launchpad?
<jml> mrevell, hi
<mrevell> hi jml, I pung you right? Now I need to remember why
<jml> you did.
<leonardr> james_w, gary told me you had a question about launchpadlib yesterday. do you still have the question?
<james_w> about lazr.restful I guess actually
<leonardr> james_w: ok, i can answer that as well
<james_w> just trying to find the paste
<james_w> leonardr: I filed bug 435309, and did some grepping and came up with http://paste.ubuntu.com/276442/ . I was wondering how far that was likely to be from working.
<mup> Bug #435309: Please expose +delete on branches <Launchpad itself:New> <https://launchpad.net/bugs/435309>
<james_w> I'm forging web app requests now, so it's not critical, but hey, if I've got a patch for a bug then I might as well submit it, eh?
<leonardr> james_w: that diff is code that you wrote?
<james_w> yeah
<james_w> based on some code I found for milestones
<leonardr> james_w: instead of export_write_operation, use export_destructor_operation
<leonardr> and don't use export_as
<leonardr> what you've done is publish a POST operation called 'delete'. the code you worked off of may have predated export_destructor_operation
<EdwinGrubbs> sinzui: I'm not sure how to test your bug 407055
<mup> Bug #407055: NavigationMenu is still needed but not supported by base-layout <story-ui-3> <Launchpad Registry:Fix Released by sinzui> <https://launchpad.net/bugs/407055>
<james_w> leonardr: like http://paste.ubuntu.com/277117/ ?
<james_w> leonardr: break_references=False won't interfere with the check for free_parameters? That check is for explicit call_with that allows those parameter to be set in the API?
<leonardr> james_w: give it a try, but if there's a default value for the parameter it shouldn't be counted
<leonardr> if you actually want to expose break_references, you'll have to do it with POST
<james_w> yeah
<james_w> I'm a bit unsure about that anyway
<james_w> It feels like you would want it to be True always, but it's obviously there for a reason
<bac> hi mrevell
<mrevell> hi bac!
<bac> mrevell: could you add some thoughts on bug 435599, perhaps explain why we were using the non-human-readable blog URLs, comments on reachability w.r.t. embargo, etc?
<mup> Bug #435599: Link to LP 3.0 blog post on front page is broken <Launchpad itself:Triaged> <https://launchpad.net/bugs/435599>
 * mrevell looks
<leonardr> james_w: talk to the code hosting team. you should be able to set the default-through-the-web-service to true
<james_w> leonardr: I will do, thanks
<abentley> james_w: break_references seems way too dangerous to be default.
<james_w> abentley: is it possible to query the references?
<abentley> james_w: Yes.  (that's what we show on the confirm page)
<abentley> james_w: See Branch.deletionRequirements.
<james_w> ok
<bac> hi cprov
<cprov> bac: hey
<bac> cprov: what is the status of def-row?  could you update CRB?
<cprov> bac: we will know in ~3h, code fix is r=noodles. Will do.
<bac> cprov: so you just sent to ec2?
<cprov> bac: no, I've cowboyed the patch in production, more effective ;)
 * bac averts his eyes
<mrevell> deryck: I'm getting an internal server error when I try to change a bug's project in the web UI. Want me to pastebin?
<deryck> mrevell, sure
<deryck> mrevell, and from what to what are you trying to change?
<matsubara> Ursinha, stub, Chex, gary_poster, rockstar, bigjools, henninge, sinzui, allenap: LP production meeting in 11 min at #launchpad-meeting
<matsubara> make that 10 min :-)
<mrevell> deryck: bug 432965 -- trying to change from launchpad to launchpad-doc -- https://pastebin.canonical.com/22552/
<mup> Bug #432965: help for creating a branch for a project links to +junk <launchpad-documentation> <Launchpad Documentation:New for matthew.revell> <https://launchpad.net/bugs/432965>
<deryck> hmmm
<deryck> mrevell, so the change did take for the bug, right?
<mrevell> deryck: not AFAIK. I've tried twice and both times got that internal server error in a red pop-up
<mrevell> deryck: Adding a comment work fine btw
<deryck> mrevell, for this bug -- https://bugs.edge.launchpad.net/launchpad-documentation/+bug/432965 ?
<mup> Bug #432965: help for creating a branch for a project links to +junk <launchpad-documentation> <Launchpad Documentation:New for matthew.revell> <https://launchpad.net/bugs/432965>
<sinzui> EdwinGrubbs: can you attend the Launchpad production meeting for me in #launchpad-meeting in 4 minutes. I am sprinting.
<EdwinGrubbs> sinzui: ok
<EdwinGrubbs> sinzui: is there any info I need to relay?
<mrevell> deryck: Oh, okay, so the change did take but it didn't show on the page, instead I got the ISE
<deryck> mrevell, this was via AJAX the first time?  Maybe the UI failed to update, but the change happened, which led to the error you're seeing now.
<mrevell> deryck: Oh weird, right. Yeah, both times via Ajax
<deryck> mrevell, I've made notes and will watch; if this happens again, we can file a bug.
<sinzui> EdwinGrubbs: Barry will be available to work on the Expat error in the next 3 working days.
<rockstar> henninge, why did you change bug 430332 into a completely different bug?
<mup> Bug #430332: FAQs have too verbose titles <Launchpad Answers:Triaged by rockstar> <https://launchpad.net/bugs/430332>
<deryck> kfogel, tags auto complete from official tags only.
<henninge> rockstar: let me try to remember ...
<henninge> rockstar: because they have title now but the wrong ones?
<henninge> rockstar: ok, maybe I should have filed a new bug
<deryck> bac, ping
<bac> hi deryck
<henninge> rockstar: and may, just thinking, I am talking about page headings and you may be talking about the page title?
<rockstar> henninge, yes, could you please revert that bug and create a new one?
<rockstar> henninge, I think that's also the case.
<rockstar> Or reverse, really.
<kfogel> deryck: AH.  Thanks.  I was confused, because (re bug #432965) I'd seen the "launchpad-documentation" tag on *other* bugs, and therefore expected it to complete on bug #432965 as well.
<mup> Bug #432965: help for creating a branch for a project links to +junk <launchpad-documentation> <Launchpad Documentation:New for matthew.revell> <https://launchpad.net/bugs/432965>
<mup> Bug #432965: help for creating a branch for a project links to +junk <launchpad-documentation> <Launchpad Documentation:New for matthew.revell> <https://launchpad.net/bugs/432965>
<kfogel> mrevell: see above re "launchpad-documentation" tag
<deryck> kfogel, yeah, this is part of the problems with official vs unofficial tags.  only the most aggressive tagger/qa-er follows the distinction.
<mrevell> kfogel: thanks, did you see my comment on the bug?
<kfogel> deryck: well, the distinction is mysterious.  Now, if adding an unofficial tag resulted in a confirmation step or something, the user might be aware of what they're doing.
<kfogel> (confirmation steps are not evil under all circumstances, they're only evil when they're easily habituatable, which this wouldn't be -- for those who want to observe the official/unofficial distinction, anyway).
<deryck> right
<kfogel> mrevell: I did.
<henninge> rockstar: reverted
<henninge> rockstar: filed bug 435973
<mup> Bug #435973: FAQ page headings are too verbose <Launchpad Answers:New> <https://launchpad.net/bugs/435973>
<rockstar> henninge, thanks.
<Fly-Man-> Simple question
<Fly-Man-> Is the http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel the branch that also holds the latest ui changes for 3.0 ?
<beuno> Fly-Man-, yes
<beuno> it holds what is running on Launchpad or newer
<bac> hi jml
<jml> bac, hello
<jml> it wasn't me.
<bac> jml i am looking at https://code.edge.launchpad.net/~jml/launchpad/code-to-branches/+merge/12288
<bac> are noodles775's concerns still valid?  is this branch a risk for integration failure?
<jml> it's always going to be a risk.
<jml> I haven't tested the existing proposed branches yet.
<bac> i know there is always risk.  based on his concerns is this one especially likely to cause problems?
<jml> I'd have to look at the diffs of the other proposed branches to know for sure.
<bac> jml:  i want to approve it.  can you run through ec2 again and submit before 0700UTC tomorrow?
<jml> bac, sure. I can do that now.
<bac> jml:  wonderful.  approved.  remember to use the magic to go to db-devel
<jml> bac, I shall.
<bac> (i only keep repeating that b/c it's the kind of thing i'd flub up.)
<jml> bac, actually, I'll use the other branch I made
<jml> ec2 land https://code.edge.launchpad.net/~jml/launchpad/code-to-branches/+merge/12288 -s "Change the 'Code' tab to 'Branches'."
<bac> oh, fancy
<jml> yeah.
<bac> jml how hard would it be for ec2 to mail a summary (just the test passed/failure list) to the MP?
<jml> coming soon to a trunk near you.
<jml> bac, only a little hard.
<bac> i'd love to look at a MP and see the ec2 results
<bac> jml-hard or mortal-hard?
<jml> well, here's how I'd do it.
<jml> I'd change ec2 to spit out subunit test results, rather than what it does now
<jml> subunit basically being parseable test results.
<jml> I'd then, I guess, add something to customize test output
<bac> sounds good.  perhaps i'll suggest it to our next build engineer
<mrevell> See you in the morning people.
<jml> I think all the pieces are there actually
<jml> I hacked zope.testing to do subunit output a while ago
<jml> getting ec2test to use it is a necessary step for parallelizing across multiple machines.
<sinzui> bac: ping
<bac> sinzui: hi
<sinzui> bac: I want an RC to land this branch: https://code.edge.launchpad.net/~sinzui/launchpad/sprint-is-physical
<sinzui> bac: This is db patch so that we can provide the feature to the UDS edge users quickly. Jorge needs this to do logistical planning for UDS
<bac> sinzui: does it have db approval?
<sinzui> bac: it has jml and stub's approval
<bac> sinzui: is sabdfl's approval required?
<sinzui> No. jml does schema approval
<bac> oh, nice.
<bac> sinzui: i'm going to have to defer until i can discuss it with flacoste
<sinzui> bac: okay. thanks for considering this
<bac> sinzui: if approved the PQM landing deadline will be tomorrow at 0700UTC.  will that be a problem?
<sinzui> no.
<bac> sinzui: francis and i will talk about it but my gut feeling is it will not meet the criteria to be included.
<sinzui> A successful UDS does not meet criteria
<beuno> *tension*
<bac> we've had many successful UDS meetings without this patch
<sinzui> The number or remote users seems to be increasing,
<bac> sinzui: i'm going to present it.  i'm just saying based on the feedback and comments i got from kiko and flacoste for the review of the release i don't think it meets the criteria.
<bac> sinzui: in prepartion will you create a MP for it?
<bac> ah, i see it
<sinzui> bac: it has onc
<flacoste> bac: i agree, i don't see a reason for including this in this release
<rockstar> Has anyone else been having problems getting their dev server running today?  Mine seems to start up, but when I look up launchpad.dev, apache tells me the server isn't running.
<Fly-Man-> rockstar: you installed it with the rocketfuel-setup ?
<rockstar> Fly-Man-, no.  This configuration worked yesterday.
<rockstar> salgado, ping
<salgado> hi rockstar
<rockstar> salgado, I wonder if you might help me debug why apache doesn't think my dev server is running.
<salgado> rockstar, sure, I can try
<rockstar> salgado, these lines are in my /var/log/apache2/error.log : http://pastebin.ubuntu.com/277354/
<rockstar> But make run reports that DebugLayerHTTP is started and running on that port.
<salgado> rockstar, what do you see on http://127.0.0.88:8085/ ?
<rockstar> salgado, it just spins, never completes.
<salgado> rockstar, can you try stopping apache and reloading that?
<rockstar> salgado, ah, it looks like launchpad.dev:8085 doesn't work, but specifying IP does.
<rockstar> salgado, I get an oops page, and lots of this in the logs: http://pastebin.ubuntu.com/277357/
<salgado> rockstar, a real OOPS or just a not-found?
<rockstar> salgado, ah, yeah, it's a 404
<salgado> rockstar, so, I guess it's fair to assume the webapp is running fine, so that we can start poking at apache?
<rockstar> salgado, sure.
<rockstar> I restarted the app, everything looks fine.
<salgado> rockstar, you're not on karmic, right?
<rockstar> salgado, yes, I am on Karmic.
 * salgado goes look for recent apache uploads to karmic
<rockstar> salgado, ah, and I just did an upgrade so I could get bzr 2.0...  that could be it.
<salgado> rockstar, I guess restarting apache doesn't make things any better?
<rockstar> salgado, nope.  No errors or anything, it just doesn't want to proxy.
<rockstar> salgado, got it.  Something was screwed up with my hosts file...  I haven't touched that since I first set it up.
<salgado> wow, that's weird
<rockstar> I guess something in the recent upgrade got more finicky with my /etc/hosts.
<Fly-Man-> rockstar: You're running it locally ?
<Fly-Man-> or on a external machine
<Fly-Man-> the web browser
<rockstar> Fly-Man-, this is my local dev instance.
<Fly-Man-> rockstar: You have seen the explanation to get it to external ?
<mwhudson> good morning
<EdwinGrubbs> barry: your changes for bug 434761 are missing one of the portlets shown in the mockup attached to the bug. I assume this was intentional, but I wanted to make sure.
<mup> Bug #434761: Make the home page pretty <story-ui-3> <Launchpad Registry:Fix Released by barry> <https://launchpad.net/bugs/434761>
<barry> EdwinGrubbs: which one?
<EdwinGrubbs> barry: the portlet in the top left corner of the mockup which lists the various sections of Launchpad and probably links to different pages in the tour or guide.
<barry> EdwinGrubbs: that only displays for anonymous users
<mwhudson> gmb: did you get ec2 demo working in the end?
<EdwinGrubbs> barry: ok, I'll mark off the item in the test plan.
<EdwinGrubbs> barry: can you also look at this question: https://answers.edge.launchpad.net/launchpad/+question/80578
<barry> EdwinGrubbs: thanks
 * barry looks
<jml> hey guys
<jml> guess what
<jml> I just did this:
<jml> ../auto-land/utilities/ec2 land https://code.edge.launchpad.net/~jml/launchpad/code-to-branches/+merge/12288 --force
<jml> and the script just did this:
<jml> Merge proposal is not approved, landing anyway.
<jml> ['../auto-land/utilities/ec2', 'test', '--headless', u'--email=jml@mumak.net', '-b', u'launchpad=db-devel', '-s', u"[release-critical=bac][r=michael.nelson][ui=beuno][bug=373341] Change 'Code' tab to 'Branches'.", 'bzr+ssh://bazaar.launchpad.net/~jml/launchpad/code-to-branches']
<jml> (except for real, rather than just printing out a command list)
<barry> EdwinGrubbs: question answered
<jml> how cool is that!
<barry> jml: that's pretty cool that you can land proposals that haven't been approved! <wink>
 * Fly-Man- frowns
<jml> barry, look at the proposal :)
<Fly-Man-> could not change directory to "/root/launchpad/lp-branches/devel"
 * Fly-Man- looks at installation
<Fly-Man-> Something doesn't look good there
<jml> barry, the status wasn't set to "approved", but all the votes are approvals.
<barry> jml: when are we getting auto status changes? <wink> (guess i should bug thumper about that)
<barry> jml: but yeah, cool!
<gmb> mwhudson: I did it manually :).
<gmb> jml: Sweet.
<mwhudson> gmb: cool
<maxb> "Uses Launchpad for Answers and Branches" hrm
<mwhudson> gmb: sorry about breaking it
 * maxb is unconvinced about this whole Code -> Branches thing
<gmb> mwhudson: That's okay, it gave me something to think about :)
 * jml -> dinner
<rockstar> maxb, me too.
<barry> me three
<rockstar> However, thumper had a point when we were talking about the link to code browse.  Sometimes the branch isn't code, it's documentation, or a paper, or images, or anything number of things.
<rockstar> Instead of Branches, let's just say Stuff.
<rockstar> "Uses Launchpad for Answers and Stuff"
<maxb> heh
<maxb> I guess "Uses Launchpad for Answers and Version Control" is a bit excessive and jargon-ish
<maxb> I worry, however, about users asking "So where is the trunk?"
<rockstar> s/Version Control/Bazaar/
<rockstar> maxb, that's what the development focus is for.
<rockstar> maxb, although I've often thought we need to have a better way of illustrating that.
<maxb> To people not indoctrinated into bzr terminology, branches == secondary
<rockstar> maxb, right.
<mwhudson> elastifox is being useless for me recently
<rockstar> mwhudson, yes, me as well.
<mwhudson> i don't think it can cope with the number amis that are currently out there at all well
<mwhudson> oh, and the launch dialog is taller than my screen :)
<thumper> hi hi
 * thumper goes to look at email
<Fly-Man-> What was the command to stop the mailserver to keep sending emails to xmlrpc-private again ?
<thumper> flacoste: I'm not sure the db permission for this has been updated: https://code.edge.launchpad.net/~thumper/launchpad/permission-fail/+merge/12329
<thumper> flacoste: although I can understand your reasoning
<thumper> flacoste: so we should just get the permission updated
<flacoste> thumper: yes, please!
<flacoste> no DB patches in the roll-out please!
<thumper> flacoste: I wasn't aware that the security.cfg was considered a db patch
<thumper> flacoste: we certainly allow it onto devel
<flacoste> well, we do, but it has no effects
<flacoste> because we don't run the security.py script on udpate
<flacoste> so we could land it, but it wouldn't have any effect, so we better not land it :-)
<bac> mwhudson, thumper: you saw the email about the re-roll?
<thumper> bac: not yet
<thumper> bac: have now :)
<bac> thumper: so you've got 10 hours...
<bac> go!
<mwhudson> bac: yes
<mwhudson> bac: my r-c branch is in ec2
<bac> mwhudson: great.
<bac> mwhudson: would you and thumper update CurrentRolloutBlockers when your branches land.  there's a new section at the bottom
<mwhudson> bac: ok
<bac> thx
<Fly-Man-> kfogel: *ping*
<Fly-Man-> wth was that process that stopped the calling of the xmlrpc-private
<Fly-Man-> Ahh, thank you
<Fly-Man-> killall mailmanctl
<Fly-Man-> barry: *ping*
<Fly-Man-> flacoste: *ping*
<flacoste> hi Fly-Man-
<Fly-Man-> Both, I edited the https://dev.launchpad.net/Running
<Fly-Man-> to include the Advanced running page that kfogel made
<Fly-Man-> that has the advanced things to get the Launchpad running locally in development mode
<flacoste> thanks!
<Fly-Man-> and how to get branches to auto approve and imported
<barry> Fly-Man-: hi
<Fly-Man-> barry: See comment on the Running page
<Fly-Man-> I added the kfogel page that has more explaining on advanced use of the Launchpad locally
<barry> Fly-Man-: probably a better way is:
<barry> lib/mailman/bin/mailmanctl stop
<Fly-Man-> barry: I didn't write that page ;)
<Fly-Man-> kfogel did :p
<barry> Fly-Man-: :) i'll update it
<Fly-Man-> But it does the same ;)
<Fly-Man-> It stops the spam on my console ;)
<barry> yeah, but maybe not so cleanly if you actually wanted to run mailman at some point ;)
<Fly-Man-> Haha
<Fly-Man-> true
<barry> updated
<barry> bac: CRB updated
<bac> thanks
<rockstar> bac, is PQM going to open tomorrow, barring any acts of God tonight?
<mwhudson> hate week 4
<EdwinGrubbs> barry: are you familiar with the "Add Architecture" link on the distroseries +index page?
<rockstar> mwhudson, is there a way for me to fire off an ec2 instance to run all the Javascript tests only?  Like, a windmill specific image or something?
<barry> EdwinGrubbs: no ;)
<thumper> email done
<rockstar> thumper, okay, you wanna chat?
<mwhudson> rockstar: no, i don't think so
<mwhudson> rockstar: file a bug?
 * rockstar makes a sad face
<rockstar> mwhudson, launchpad-foundations?
<mwhudson> rockstar: yeah, tag it build-infrastructure
<rockstar> mwhudson, ack
<EdwinGrubbs> flacoste: ping
<mwhudson> rockstar: i can make an image for you i guess, it'll take an hour or so
<flacoste> hi EdwinGrubbs
<thumper> rockstar: just chasing an oops
<thumper> rockstar: yes, shortly
<rockstar> mwhudson, I wouldn't sweat it right now.  I just thought it'd be nice to not have to fight with Karmic to get windmill running correctly.
<EdwinGrubbs> flacoste: Are you familiar with the "Add architecture" link on the distroseries +index page?
<mwhudson> rockstar: the only difference from the standard image is installing a bunch of extra software right?  xfvb and firefox?
<mwhudson> rockstar: yeah, it's a good idea :)
<rockstar> mwhudson, you would know the differences better than I.
<flacoste> EdwinGrubbs: not really
<flacoste> EdwinGrubbs: that's a soyuz thing i think
<flacoste> EdwinGrubbs: what's your question
<EdwinGrubbs> flacoste: The "Add architecture" link is only displayed if the distroseries already has other architectures listed. This seems wrong, but it doesn't look like new behavior, so I don't know if ubuntu distroseries are created somehow differently.
<flacoste> EdwinGrubbs: well, they have an initial set
<flacoste> EdwinGrubbs: and that actually might be a proxy to not display this link on distro that don't use Soyuz
<flacoste> i think distro only have arch if they are Soyuz-enabled
<flacoste> but this seems to be an obfuscation and the check should be made clearer
<al-maisan_> EdwinGrubbs: I believe the creation of a distro series is somewhat of a manual process; once the series was created all the packages from the previous/stable series need to be cloned/copied for example..
<al-maisan_> i.e. this is *not* a web UI work-flow :)
<EdwinGrubbs> al-maisan_: If I create a new distroseries by hand with the "Add series" link, such as https://staging.launchpad.net/ubuntu/foo then it doesn't show the "Add architecture" link. Are you saying that this won't affect real ubuntu developers, since they are doing it differently?
<al-maisan_> EdwinGrubbs: I guess that's right.
<rockstar> thumper, https://bugs.edge.launchpad.net/launchpad-code/+bug/426141
<mup> Bug #426141: "Link to a bug report" is temperamental <post-3-ui-cleanup> <ui> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/426141>
<sidnei> gary_poster: ping?
#launchpad-dev 2009-09-25
<thumper> I wish I knew how big lp:mysql-server was
<thumper> I'm streaming it down now with no indication of % complete
<mwhudson> it's probably about 700 megs
<lifeless> its big
<thumper> lifeless: streaming from LP though gets upto 200kb/s
<thumper> lifeless: which I think is close to saturating my down pipe
<thumper> ah
<thumper> no it isn't
<thumper> but it is better than it used to be :)
<lifeless> I'm encouraging the sun folk to move to 2a
<lifeless> once drizzle do I think jay will get the message soon enough :)
<wgrant> Should LP's mirrored copies of branches be repacked now that LP has bzr 2.0.0?
<wgrant> (db-)devel aren't too badly packed, but they're worse than they could be.
<thumper> wgrant: probably
 * thumper wants to talk to a foundations person
<thumper> badly
<thumper> rockstar: I just used JS to update some bug statuses, went to the listing and it showed me the old ones
<wgrant> That's right.
<thumper> rockstar: this is the same behaviour you are seeing on the page where it doesn't come back correctly
<wgrant> Webservice POSTs aren't enough to blacklist your session from the slave.
<thumper> WTF not?
<wgrant> Is bug.
<thumper> wgrant: do you know the bug number?
<wgrant> Hunting.
<rockstar> wgrant, bug plz
<rockstar> :)
<rockstar> thumper, this is a good fing.  It means that my javascript doesn't suck so bad.
<rockstar> (It still sucks though)
<thumper> rockstar: yes
<wgrant> Hmmm. Can't find it.
<mwhudson> haha
<mwhudson> # Launchpad virtual domains. This should be on one line.
<mwhudson> 127.0.0.88      launchpad.dev ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname}
<mwhudson> # Launchpad virtual domains. This should be on one line.
<mwhudson> 127.0.0.88      launchpad.dev ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname} ${hostname}
<mwhudson> in /etc/hosts
<mwhudson> i think my script isn't quite right...
<wgrant> bug #351724 is all I can find.
<mup> Bug #351724: Inline editing of bug summary is overwritten by edit of description <Launchpad Foundations:Confirmed> <https://launchpad.net/bugs/351724>
<wgrant> How do I object to a merge proposal?
<wgrant> The approved fix for bug #435628 is bad.
<mup> Bug #435628: Attempting to file a bug on an Ubuntu source packages OOPSes when bug filing is disabled <oops> <Launchpad Bugs:In Progress by deryck> <https://launchpad.net/bugs/435628>
<mwhudson> wgrant: you can "add a review" i think?
<wgrant> mwhudson: Ah, so I can. I was looking for the ghost reviewer that used to be there. But anyway, not much point doing that now it's approved.
<mwhudson> wgrant: well, telling people somehow would be good
<wgrant> There aren't going to be bugs people around in time for the re-roll, are there?
<wgrant> deryck: Unlikely ping about the above.
<deryck> hey
<deryck> wgrant, I've got a fix for that already.  it got rc approval today.
<wgrant> deryck: Ah, great. Can you check my comment on https://code.edge.launchpad.net/~deryck/launchpad/filebug-redirect-package-oops-435628/+merge/12366?
<deryck> so it will make the reroll
<wgrant> Yes, but the fix is bad.
 * deryck looks
<deryck> wgrant, ah, ok.  I can work up a better fix tonight then.
<wgrant> deryck: Great, thanks.
<wgrant> (permissions-wise, the bug supervisor of a source package is already the bug supervisor of the distribution)
<deryck> I thought the bug was caused because source packages didn't have bug supervisor.
<wgrant> It is.
<wgrant> The bug supervisor is inherited from the distribution.
<wgrant> So it's not a separate attribute.
<deryck> right
<deryck> I was confused by what you meant with "is already the bug supervisor."
<wgrant> Sorry, I was rather unclear.
<deryck> wgrant, I'll be afk for a bit longer but then will work up a better fix.  hopefully bac will be around to confirm for rc again.
<wgrant> deryck: Thanks.
<deryck> np
<mwhudson> thumper: wanna review https://code.edge.launchpad.net/~mwhudson/launchpad/public-only-update-sourcecode/+merge/12394 ?
<mwhudson> or anyone else, of course
<gary_poster> sidnei: pong, but have to go away soon
<thumper> stub: morning
<thumper> stub: https://code.edge.launchpad.net/~thumper/launchpad/permission-fail/+merge/12329
<thumper> stub: not landing as an RC, but has a db permission that needs to be set
<stub> np
<stub> thumper: Permissions all granted on production
<thumper> stub: ta
 * mwhudson (a) back from lunch (b) happy to have figured out https://bugs.edge.launchpad.net/launchpad-code/+bug/435783
<mup> Bug #435783: branch appears in loggerhead but can't be read over http <Launchpad Bazaar Integration:New> <https://launchpad.net/bugs/435783>
<thumper> mwhudson: bug 385032 is done right?
<mup> Bug #385032: branchupgradejob should not upgrade in place <Launchpad Bazaar Integration:Triaged by mwhudson> <https://launchpad.net/bugs/385032>
<thumper> damn
<thumper> wrong one
<thumper> bug 371484
<mup> Bug #371484: branch puller should be a branch job <branch-puller> <Launchpad Bazaar Integration:Triaged by mwhudson> <https://launchpad.net/bugs/371484>
<mwhudson> thumper: no
<thumper> poo
<thumper> push it off or unschedule?
<thumper> tech-debt?
<mwhudson> thumper: it uses job-type scheduling, but it's not a row in the BranchJob table yet
<mwhudson> thumper: let's do it, it shouldn't be very hard
<mwhudson> (famous last words, ofc)
<thumper> ok, I'll add to 3.1.10
<thumper> mwhudson: look at the job oops report
<thumper> mwhudson: three different issues to do with diffstat generation
<thumper> mwhudson: I'm going to create a branch to catch and log, but continue
<thumper> mwhudson: since we don't do anything with the diffstat just yet
<mwhudson> thumper: hm, i don't have the oops report
 * mwhudson stabs thunderbird in the head
<thumper> https://devpad.canonical.com/~lpqateam/oops-summaries/jobs-2009-09-24.html
<jtv> mwhudson: indeed, working with staging-local branches worked near-perfectly for me yesterday.  Thanks.
<mwhudson> jtv: glad to hear it
<jtv> Revision pages kicked me back to the front page, but I imagine that's because revisions don't normally live on staging and there'd be trouble.
<jtv> mwhudson: the other thing we've been looking at that you may know more about is the Job/BranchJob system.  It seems to have been designed with all sorts of heartbeat monitoring and watchdogging in mind, but none of it is implemented.
<mwhudson> jtv: yes, i think that's a fair description
<mwhudson> jtv: abentley knows most about this code fwiw
<mwhudson> jtv: did you see that thumper found the bug that was probably causing the seemingly forever running Jobs?
<jtv> No!?
<jtv> what was the bug that was probably causing the seemingly forever running jobs?
<mwhudson> jtv: this bug https://bugs.edge.launchpad.net/rosetta/+bug/434192
<mup> Bug #434192: bzr imports are sometimes stuck in 'running' state <Launchpad Translations:Triaged by jtv> <https://launchpad.net/bugs/434192>
<jtv> That's the problem description... finding that isn't very impressive.  Hasn't he found the cause?
<mwhudson> yes, that's what i was trying to say
<mwhudson> jtv: r8523 of db-devel should fix it
<jtv> !
<mwhudson> jtv: basically, when a job failed, it wasn't properly marked as failed in the database
<mwhudson> because we went "transaction.abort(); mark job failed; raise"
<mwhudson> not "transaction.abort(); mark job failed; transaction.commit(); raise"
<jtv> Damn, I checked for that and found nothing wrong.
<jtv> Because the exception was caught one level higher, I thought,
<jtv> and then the transaction would be committed either at the beginning of the next iteration or when the script completed.
<mwhudson> well, maybe we misdiagnosed
<mwhudson> maybe it only happens when two jobs in a row fail or something?
<jtv> No, because the next commit happens before the next job starts running.
<jtv> Maybe if somehow the end-of-script commit doesn't happen
<jtv> Or the exception is not one that's caught, though IIRC the catching clause cast a pretty wide net.
<jtv> (Even SystemError and break)
<mwhudson> huh yeah
<thumper> jtv: the transaction isn't committed when the script ends
<thumper> jtv: it is aborted
<thumper> jtv: hence the failure to record the last one
<jtv> ahhhh
<mwhudson> jtv: what was happening in our case was that the oops reporting itself was blowing up, because of a lack of config values
<mwhudson> ... ending the script, then what thumper said took over
<jtv> ...and no place for that error to go.  Neat.
<jtv> I considered that, but thought people would have noticed.  -1 for second-guessing.
<mwhudson> the job stuff isn't completely battle hardened yet
<mwhudson> i guess we really should use it for the puller, that seems to be particularly good at shaking out race conditions
<jtv> I noticed that CodeImportJob did implement all of the watchdog stuff, completely separate from Job.
<jtv> Another thing about Job is it could still die from a kill, and there'd be nothing to GC the dead "running" job.
<mwhudson> the code import stuff precedes and somewhat inspired the job stuff
<mwhudson> and is rather more battle hardened
<jtv> Very important not to count on the original process getting things into their final state.  I expected to find some kind of GC job for Jobs/BranchJobs.
 * stub wonders if it is possible to install an atexit handler that bitches if the script terminates without an explicit transaction.commit() or transaction.abort()
<stub> Or just hack it into LaunchpadScript.... I don't think you can tell though...
<jtv> stub: wouldn't it lead to people slapping unnecessary or half-baked commits and aborts onto difficult code paths?
 * jtv is a big fan of explicit-commit, implicit-abort
<jtv> mwhudson: frustrating...  I'm trying to read Tim's db-devel fix, but the interesting part won't show up in the page.  Folding out that section just waits forever.
<jtv> Did he add a commit as well as dealing with the cause of the oops-reporting failures?
<mwhudson> jtv: he added a commit
<jtv> ah good, I expected it but better safe than sorry
<jtv> Where did the oops-reports URL go again?  https://devpad.canonical.com/~matsubara/oops.cgi is no longer accessible.
<mwhudson> _thumper_: 33 megs of diff eh?
<thumper> mwhudson: heh, yeah
 * thumper is EDOing
<thumper> I'll check later on some test runs
 * mwhudson too
<stub> jtv: It would lead to people slapping an explicit abort at the end of their script, which at least makes people think about it.
<stub> jtv: I think implicit abort is good, but explicit abort is better.
<jtv> stub: but at the end of your script is no good; you'd be getting this warning on top of regular errors, so people would either ignore it or silence it without giving it much thought.
<stub> jtv: I don't follow why that would happen
<stub> If you get multiple errors, you always just pay attention to the first.
<jtv> Unless it seems to be just fluff.
<jtv> You want an explicit commit at the end of your script; that's easy.  But when things go wrong, you break out of your normal path and don't get there.
<stub> If you have fluff errors, you have bigger problems.
<jtv> So you have an exception, and besides the regular error, you'd get a warning "by the way, you didn't abort explicitly."
<stub> Indeed. Or you don't warn at all when the script is terminating because of an exception.
<stub> Or non-zero return code or whatever.
<jtv> But then what's left?  "You need an explicit commit at the end of the script."  For simple scripts it's actually quite nice that you can make them transaction-unaware: they're basically the transaction body.  To me it's more a hack that sometimes we have to do explicit commits.
<jtv> Right now it's LaunchpadScript's responsibility to bracket, and your derived script provides the body.
<jtv> So in fact I'd be more interested in the opposite: a warning against explicit commits/aborts during appserver requests.
<jtv> stub: feel like a lumberjack?
<stub> not today - up early and already partaken. This 8am thing is scary.
<jtv> I've heard of it
<jtv> I usually get these phases after travelâsuch as that last trip
<mrevell> Morning
<jml> good morning
<wgrant> Morning mrevell/jml.
<henninge_> jml: Hi!
<henninge> thumper: gone for the weekend?
<henninge> jml: as a former code guy, are you able to tell me which the cronjobs are that are running the branch jobs?
<jml> henninge, I don't quite follow, what are you trying to find out?
<jml> henninge, or rather, there's more than one cronscript running branch jobs-
<jml> so it depends on which job you mean.
<henninge> jml: all jobs access the branch table to change job status.
<henninge> all jobs *that* access
<henninge> jml: background:
<henninge> today's roll-out will include a fix by Tim that will prevent from jobs remaining in the "running" state for ever and that will also let us see the oopses of our jobs.
<henninge> to start on a clean slate, I wan't to set all jobs marked as "running" to "failed"
<henninge> but I can only do that if those "running" jobs are not really running. For that I need to stop all jobs that run jobs.
<jml> I see.
<henninge> jml: those are the one I try to round up.
<henninge> ones
<jml> henninge, here's what I'd do if I were you
<jml> bzr ls -VR --kind=file --null | xargs -0 grep -In JobRunner.fromReady
<henninge> jml: good idea.
<jml> henninge, and then look for the ones that are branch jobs, based on context
<jml> henninge, (most of them will be)
<jml> henninge, because there's no one cronscript and there's no canonical list.
<henninge> jml: yes, I am aware of that.
<henninge> jml: actually, I'll go for all jobs, not only branch jobs, since the bug was in the job system itself.
<henninge> jml: thank you
<jml> henninge, np. you might also want to grep for JobCronScript
<henninge> ok
<henninge> jml: yup, just saw that that calls fromReady, too.
<jml> cool.
<deryck> Good morning, all.
<mrevell> morning deryck
 * deryck hides his still-hasn't-blogged head in shame
<mrevell> haha
<mrevell> :)
<wgrant> How acceptable is it to produce a branch which is a collection of largely unrelated trivial UI fixes?
<bigjools> if they're genuinely trivial it sounds fine
<asabil> hi all
<asabil> is there any documentation about how to deploy lp for production ?
<Fly-Man-> Is there a Wiki page on how the cron is defined ?
<henninge> Hi, I just tried to push a branch locally to dev. Traditionally this would only work when pushing to ~sabdfl branches but that name has been changed to ~mark now. It seem, though, that sabdfl is still found somewhere. What needs to be updated here? http://paste.ubuntu.com/277814/
<henninge> jml: (ex code guy ;) Any idea? ^
<wgrant> henninge: ~/.ssh/config
<henninge> wgrant: oh, that's where! Thanks!
<henninge> wgrant: and now I know what to do when I want to push to a different branch. Thanks again!
<henninge> s/branch/user/
<wgrant> henninge: You can always use bzr+ssh://user@bazaar.launchpad.dev/~user/project/branch, of course.
<henninge> too much noise .. ;-)
<henninge> yeah, you're right
<henninge> too many things to remember and to connect to each other ...
<Fly-Man-> wgrant: Who's the server guru again ?
<wgrant> Fly-Man-: 'server guru'?
<Fly-Man-> Yeah, 1 or more ppl that manage the server
<Fly-Man-> I'm trying to setup the cron jobs for the cronjobs that I found in the folder
<wgrant> Note to self: remember to reset /etc/hosts after running ec2demo, or be prepared to get very strange pages at launchpad.dev next time...
<Fly-Man-> but it seems that there's 1 or more cronjobs that can't run simularly
<wgrant> Fly-Man-: What are you trying to do?
<Fly-Man-> wgrant: I'm trying to setup the lp-branches/devel
<Fly-Man-> and trying to setup cron jobs instead of me constantly clicking them
<wgrant> Fly-Man-: To do what?
<Fly-Man-> to run my internal system
<Fly-Man-> building also fails for some strange reason
<Fly-Man-> because before all I had to do is make a directory in the /var/tmp folder
<Fly-Man-> but now it doesn't even do checkouts from local svn/git based trunks
<jml> henninge, use ./utilities/make-lp-user
<jml> henninge, and remove any mention of sabdfl from your .ssh/config
<Fly-Man-> Finally
<Fly-Man-> Now the code importer does his magic again ...
<henninge> jtv1: This looks like a cocnfiguration error for errordir to me, doesn't it? http://paste.ubuntu.com/277857/
<jtv1> henninge: is that what the job runner's attempts at oops logging were breaking on?
<jtv1> they said it was because of missing config entries.
<henninge> jtv1: probably
<henninge> jtv: The missing config may just be an issue on dev, though. I have added that now and will retry.
<jtv> henninge: most of that stuff is in the shared part of the config though
<henninge> jtv: no, in the shared part error_dir is None, not only for rosettabranches but for most others, too.
<jtv> ah ok
<henninge> jtv: all others set it in development/launchpad-lazr.conf
<henninge> we didn't
<henninge> but I don't know about production config.
<henninge> jtv: and oops_id ...
<henninge> oops_prefix, that is
<henninge> jtv: now I got an oops! 2009-09-25 12:08:38 INFO    Job resulted in OOPS: OOPS-1364RSBR1
<jtv> henninge: good!
<jml> kiko, good morning!
<kiko> morning jml
<kiko> how are you doing?
<jml> kiko, well! just typing out the draft programme for next week
<kiko> good job
<jml> kiko, and then I have a million hours of meetings
<asabil> I am trying to run launchpad from an installed egg
<asabil> but when I run the bin/run script I get a: ImportError: cannot import name IAuthenticationUtility
<henninge> jtv: here is the oops: Oops-Id: OOPS-1364RSBR1
<henninge> Exception-Type: NoSuchFile
<henninge> Exception-Value: No such file: ('tree_root-20070725222321-bwkrhbkxcrm83ygz-1', 'rcryderman@gmail.com-20090925041620-7chqzwqcbehtmzz0')
<henninge> Date: 2009-09-25T12:08:38.944943+00:00
<henninge> Page-Id:
<henninge> Branch: jobrunner_fix
<henninge> Revision: 8526
<henninge> User: None
<henninge> URL: None
<henninge> Duration: -1
<henninge> branch_job_id=3
<henninge> branch_job_type=Rosetta Upload
<henninge> branch_name=%7Emark/awn/0.4
<henninge> job_id=3
<henninge> Traceback (most recent call last):
<henninge>   Module lp.services.job.runner, line 142, in runAll
<henninge>     self.runJob(job)
<henninge>   Module lp.services.job.runner, line 121, in runJob
<henninge>     job.run()
<henninge>   Module lp.code.model.branchjob, line 791, in run
<henninge>     self._init_translation_file_lists()
<henninge>   Module lp.code.model.branchjob, line 761, in _init_translation_file_lists
<henninge>     changed_files.append((
<henninge>   Module bzrlib.revisiontree, line 68, in get_file_text
<henninge>     _, content = list(self.iter_files_bytes([(file_id, None)]))[0]
<henninge>   Module bzrlib.revisiontree, line 84, in iter_files_bytes
<henninge>     raise errors.NoSuchFile(e.revision_id)
<henninge> NoSuchFile: No such file: ('tree_root-20070725222321-bwkrhbkxcrm83ygz-1', 'rcryderman@gmail.com-20090925041620-7chqzwqcbehtmzz0')
<henninge> oops, sorry
<jtv> henninge: paste would have worked!
<henninge> I *have* pasted it: http://paste.ubuntu.com/277895/
<henninge> that was my intention ... ;)
<jtv> henninge: I think there are more oopses of this ilk in the codehosting oops reports from time to time.
<henninge> jtv: but I con confirm that thumpers fix is working, all jobs are in "failed" state.
<jtv> henninge: that's good.  There will be more "hanging" jobs in the future as scripts are killed for whatever reason, but nowhere near as many.
<henninge> jtv: so we still need a garbage collection, I guess.
<jtv> yes, eventually
 * henninge relocates
<allenap> gary_poster: Is it okay for me to push new revisions to trunk for lazr.restful?
<gary_poster> allenap: sort of :-)  to explain...
<gary_poster> allenap: if it is reviewed, then the process that has been recommended to me is to ``bzr co lp:lazr.restful`` , merge the desired branch , and ``bzr commit -m '[r=whoever] message'``.  I vaguely recall scenarios in which the same effect can be accomplished other ways, but the important idea is that all commit messages to the trunk should be of the pattern [r=*] * .
<kiko> james_w, hey, how's it going?
<gary_poster> That may have been truncated; let me know if it appears to not be complete
<allenap> gary_poster: Ended with "pattern [r=*] * .".
<gary_poster> allenap: then message received :-)
<allenap> gary_poster: I'll follow that. I assume the same goes for wadllib? Also, currently there is a single failing test in trunk for lazr.restful. Should I do something about that?
<gary_poster> allenap: wadllib: yes
<gary_poster> allenap: failure: yes.  a bug minimally (point it out to me and I'll mark it critical, or you can).  fixing it would be lovely, and possibly necessary if you need a release today, unless you want to lean on me to try and figure it out.  (leonardr would almost certainly have an easier time addressing it.)
<gary_poster> (leonardr is out today)
<allenap> gary_poster: It seems like a simple fix; I'll get an mp together.
<gary_poster> allenap: awesome thank you
<Fly-Man-> wgrant: *ping*
<Fly-Man-> What is devpad ?
<james_w> hey hey kiko
<kiko> james_w, how's it going?
<james_w> kiko: I'm good thanks. How are you?
<kiko> james_w, pretty busy, but good
<beuno> flacoste, hi
<beuno> flacoste, do you have 15-20 minutes to talk to me now-ish-y?
<flacoste> beuno: in 2-5 minutes?
<beuno> flacoste, perfect
<flacoste> beuno: skype me
<flacoste> beuno: or do you need me to call a number?
<beuno> flacoste, skyping
<beuno> flacoste, I have no sound
<beuno> one sec
<flacoste> beuno: that's bad!
 * Fly-Man- shall rephrase his Q
<Fly-Man-> How do I get an example from the crontab that a development server can run
<Fly-Man-> and also can be placed on the Wiki as an example
<bac> hi jml
<rockstar> maxb, you around?
<maxb> hiya
<rockstar> maxb, have you gotten Windmill running on hardy.
<rockstar> Er, on Karmic...
<maxb> I've never tried Windmill at all
<maxb> This is "make jscheck" ?
<maxb> My policy on javascript is to leave it to other people :-)
<jml> bac: hi, I'm on a call atcm.
<maxb> At least until we're happy on python 2.6
<rockstar> maxb, try this: ./bin/lp-windmill -e test=lib/code/windmill firefox http://launchpad.dev:8085
<bac> jml: np. ping me when you have a free moment.
<jml> bac, will do
<maxb> rockstar: I am about to disappear for ~20 mins, will try when I can
<rockstar> maxb, great, thanks.
<maxb> I assume from the URL I'm supposed to make run first?
<Fly-Man-> kfogel: Maybe you have a answer to this wise question ?
<Fly-Man-> Where on the dev.launchpad.net is a simple example of the cron that staging or edge runs ?
<jml> Fly-Man-, "the cron"
<jml> ?
<Fly-Man-> jml: yes, I figure there's not more then 1
<jml> heh heh
<Fly-Man-> and I am sure there's someone that can look on devpad
<Fly-Man-> where kfogel posted an example for that
<Fly-Man-> according to the search on the dev.launchpad
<jml> maybe I'm missing some context
 * Fly-Man- is getting tired of manually running the cron scripts
<jml> which ones?
<Fly-Man-> rosetta-imports
<Fly-Man-> the standard karma updates
<Fly-Man-> etc
<Fly-Man-> etc
<jml> Fly-Man-, Launchpad.net is run on a number of different machines and the cronjobs are spread across those
<Fly-Man-> jml: but still there must be 1 total list of the jobs that run ?
<jml> Fly-Man-, a while ago, faced with a problem similar to yours, I wrote the make target 'sync_branches'
<jml> Fly-Man-, I don't think there is.
<Fly-Man-> jml: I know that there's sync_branches
<Fly-Man-> but that doesn't solve the issue
<Fly-Man-> sync_branches works for bzr imports
<jml> Fly-Man-, it solves the issue for the codehosting cronscripts.
<Fly-Man-> and I have more then just the bzr imports
<Fly-Man-> jml: I run the latest build locally
<Fly-Man-> Having issues to even get a branch to import normally
<Fly-Man-> and translations aren't picked up if I'm not running the rosetta cron scripts
<jml> Fly-Man-, I was suggesting that you do something similar to what I did, and add other helpers for running the cron scripts.
<jml> brb.
<Fly-Man-> jml: I think the suggestion is great :)
<Fly-Man-> But that doesn't solve the main issue
<Fly-Man-> The main issue is that I want to run Launchpad like a normal intranet version app
<Fly-Man-> and that means that I am not able to click every 10 mins on every cron script in that folder, just to make the user happy
<Fly-Man-> and since I know that there's someone here that can either make a compilation of what the cron jobs are
<Fly-Man-> and when they should be run
<Fly-Man-> I'm hoping that someone might help
<Fly-Man-> thus making it possible to run it as a intranet application for my developers
<Fly-Man-> and not like the idea was, locally on 1 pc
<bigjools> why are you just not using Launchpad itself?
<Fly-Man-> bigjools: Good Q, bad answer
<Fly-Man-> These are school kids that program things
<Fly-Man-> and no internet connection available all the time
<Fly-Man-> so their internet timer is limited
<bigjools> what do they need to do, exactly?
<Fly-Man-> bigjools: They need to be able to create a project
<Fly-Man-> upload their translation files
<Fly-Man-> be able to import their own git repro's
<Fly-Man-> and be able to help each other with their projects
<Fly-Man-> In other words:
<Fly-Man-> The trunk version of Launchpad will be enough for them
<Fly-Man-> as I donated a server to their school
<Fly-Man-> so they could have a local system that works
<bigjools> I honestly don't see how an intermittent internet connection prevents that, especially if you're using Bazaar
<Fly-Man-> but so far, I'm forced to login with ssh every hour to run the cron scripts
<Fly-Man-> bigjools: Bazaar is nice
<Fly-Man-> especially when it works
<Fly-Man-> because they have TurtoiseBzr now
<bigjools> interesting comment
<Fly-Man-> and so far, lpt://dev/project doesn't like to be uploaded to the server
<Fly-Man-> So I think it might be time to just use Launchpad for all the things but the bzr
<Fly-Man-> and install fusionforge next to it
<Fly-Man-> so they can use that to make branches
<Fly-Man-> and update that inside launchpad
<bigjools> well I think you need to ask someone why you can't push branches
<bigjools> because a lot of people are doing it quite successfully ;)
<Fly-Man-> bigjools: I started using the trunk
<Fly-Man-> because launchpad.net doesn't even import the most simple svn and git tree that I have
<Fly-Man-> either it fails on import
<Fly-Man-> or the svn/git parser dies
<bigjools> have you asked a Codehosting expert to take a look?
<Fly-Man-> bigjools: Yes :)
<Fly-Man-> and let's see:
<Fly-Man-> "This is a problem with the svn trunk"
<Fly-Man-> "This is a problem with the svn parser we use"
<Fly-Man-> "This is a Git issue, we'll fix it somewhere in fall 2009"
<Fly-Man-> That's the answers so far
<bigjools> ok
<Fly-Man-> the strange thing is
<bigjools> well if you're dead set on running your own instance of Launchpad, you did replace all the trademarked images I hope?
<Fly-Man-> when I run it locally, it imports the whole svn or git without problems
<Fly-Man-> bigjools: of course :)
<Fly-Man-> that's what the readme on the website said
<Fly-Man-> and it's a intranet version
<Fly-Man-> so there's no outside connection
<bigjools> I don't think that makes any difference ;)
<Fly-Man-> bigjools: According to the file it does
<bigjools> well, I'm sorry someone couldn't help you with the importing.  If it works for you locally then perhaps it works in our new release.
<Fly-Man-> bigjools: what release would that be ?
<bigjools> you can use the Launchpad images only for development and testing purposes
<Fly-Man-> 3.0 ?
<bigjools> yes 3.0
<kfogel> Fly-Man-: the only example I posted is on dev.launchpad.net/Contributions, but that cron job has nothing to do with running Launchpad.
<Fly-Man-> kfogel: I know, i found a message on dev.launchpad about you explain that there's a cron example of devpad
<Fly-Man-> https://dev.launchpad.net/Translations/LanguagePackSchedule?highlight=%28cron%29
<kfogel> Fly-Man-: since I know very little about Launchpad production practices, if I said I knew an example of a cron job I was probably lying.
 * bigjools goes to eat
<Fly-Man-> kfogel: I included your runninglocally page in the How to btw
<kfogel> Fly-Man-: heh, I wouldn't call it  my page only because I mostly took instructions from other people (though I guess I did test them).  Anyway, glad it's been useful!
<Fly-Man-> kfogel: It's been usefull
<Fly-Man-> but the problem that occurs is in the part that you explain how to push a bzr
<Fly-Man-> bzr push -d <some branch> lp://dev/~<you>/+junk/branchname
<Fly-Man-> this doesn't work
<Fly-Man-> when on a remote machine
<beuno> Fly-Man-, I suspect because they can't resolve lp:// remotely...?
<Fly-Man-> Correct
<beuno> right, so there you get into more complex issues, like the launchpad plugin in bzr
<kfogel> Fly-Man-: have yuo fixed up the wiki page to explain this issue?  (I thought you had, right?)
<Fly-Man-> kfogel: barry fixed up that page of yours
<Fly-Man-> because you wrote killall mailmanctl
<kfogel> Fly-Man-: oops
<Fly-Man-> and barry thought that was a bit harsh
<kfogel> Fly-Man-: actually, I didn't write that (at laest, not that I remember)
<Fly-Man-> but the method he described is even worse ;)
<Fly-Man-> as that doesn't kill anything
<kfogel> Fly-Man-: I hardly ever use the killall command, as it postdates when I learned Unix and I've got a fossilized brain :-).
<Fly-Man-> But the point to this all is
<Fly-Man-> The source is open
 * rockstar lunches
<Fly-Man-> but when someone wants to get it to work remotly
<Fly-Man-> they'd need patience of a elephant to get something working together
<rockstar> Fly-Man-, you've discovered the REAL secret to Launchpad.  We have AMAZING LOSAs.
<Fly-Man-> LOSA ?
<beuno> sysadmins
<beuno> Fly-Man-, Launchpad is not built as a software that can be moved around
<beuno> it's a service
<beuno> that has been open sourced
<Fly-Man-> beuno: I know
<Fly-Man-> and that's the point exactly
<beuno> if it's not easy to install, it's because it isn't
<Fly-Man-> It's made easy to get the source
<beuno> nad our resources are targeted at making the service better
<beuno> it's easy because *we* need it to be easy to develop
<Fly-Man-> but after that, the problems to make it a working something
<beuno> it's not intentional, it's just where our focus is
<Fly-Man-> is like asking Santa Clause for a new bicycle
<Fly-Man-> You think you will get it
<Fly-Man-> but you will never get it
<beuno> no, that is the way *you* picture it
<beuno> because you're linking open source to your view of it
<Fly-Man-> beuno: Correct :)
<beuno> it's open source so our users can help us improve
 * Fly-Man- is in more then 20 open source projects
<Fly-Man-> and we all have the need to ask questions and hope to get back info
<beuno> this is not an open source application
<beuno> this is an open source service
<Fly-Man-> but in the 30 projects I take part in
<Fly-Man-> we always tend to make documentation so ppl understand
<Fly-Man-> and the dev wiki is definitly a good start
<Fly-Man-> and I am happy that I can run it remotly now
<Fly-Man-> but some pieces of the big puzzle are just missing
<beuno> Fly-Man-, because those projects only succeed with more users and developers
<beuno> Launchpad is funded as a service
<beuno> our goal is to make it better
<beuno> that's what we get paid for
 * rockstar gives beuno an "AMEN!"
<Fly-Man-> and I'm hoping that by asking some one might feel the need to express how it works
<Fly-Man-> so that can be documented
<beuno> we provide a service, and do what no one else does:  give you the code
<rockstar> ...and with that, I go locate viddles
<Fly-Man-> so that other ppl don't have the issue I'm facing
<Fly-Man-> beuno: Ever heard from SourceForge ?
<Fly-Man-> They made something called Gforge
<Fly-Man-> and thought that ppl wanted it
<Fly-Man-> that project is now taken over by ppl that want to make it better
<Fly-Man-> and is called FusionForge now
<Fly-Man-> and every step on that path is trail and error
<Fly-Man-> but we tend to make it better
<Fly-Man-> and the feeling that I have from Launchpad is that it's nice to test things on
<Fly-Man-> but it's never a complete package
<beuno> sourceforge stopped releasing their code
<Fly-Man-> because you'd need to fiddle and use things that's never written down
<beuno> they dropped a tarball
<Fly-Man-> Yupz, Gforge Express and Gforge Community
<beuno> we are an open source service, and we have decided to making it an amazing service, *not* a product
<Fly-Man-> and the only one they develop on themselves is expensive
<beuno> so if there's no documentation, it's because we don't have any
<beuno> and will not invest time in it, since it won't make it a better service
<Fly-Man-> In other words, here's the code
<Fly-Man-> fiddle with it
<Fly-Man-> but don't ask us how to make it work for you
<Fly-Man-> that's the feeling I have with it
<beuno> "help us improve"
<beuno> "send us patches"
<beuno> "participate in discussions"
<Fly-Man-> beuno: Improvement can only be made when you can test everything there is
<Fly-Man-> on a remote machine
<Fly-Man-> not on a local machine
<beuno> Fly-Man-, you can:  use the service
<Fly-Man-> beuno: the service doesn't function on some parts
<Fly-Man-> which I find strange
<beuno> it does
<Fly-Man-> why does a svn/git import on the local version work
<beuno> launchpad.net works very well
<Fly-Man-> and why does it fail on launchpad.net ?
<Fly-Man-> it's the same server it's talking to
<Fly-Man-> the same svn trunk it's pulling
<beuno> I don't know, there's probably a bug there, or a connection issue, or whatever?
<beuno> there's thousands of working imports
<Fly-Man-> beuno: I know
<Fly-Man-> and that's very good :)
<beuno> good
<beuno> so, it's open source
<Fly-Man-> but when I can't import a simple svn trunk
<beuno> if you have a problem
<beuno> find the bug, fix it, send us a patch
<Fly-Man-> so I can use the translations files that are in my trunk
<beuno> we'll help you test it and submit it
<beuno> so, either file a bug and help chase it, or look at the code and try to find the problem, send a patch
<beuno> everyone wins
<Fly-Man-> beuno: Okay, then let's send a bug report
<Fly-Man-> why are you using a compiled version of svn that uses python
<Fly-Man-> or git compiled that uses python /
<Fly-Man-> why not just a clean svn checkout <url>
<beuno> I guess because we use bzr-git to import branches?
<beuno> I don't know the code imports in detail
<Fly-Man-> because that's 1 of the main issues that I'd like to see fixed
<Fly-Man-> use the tools that are there
<Fly-Man-> grab a svn trunk
<Fly-Man-> then compile it into a bzr
<beuno> I suspect we don't want to double the amount of space per imported branch
<beuno> or maintain svn/git/cvs/hg branches
<Fly-Man-> and the best part is this
<beuno> or deal with their problems
<Fly-Man-> Bazaar is hosted by ....
<Fly-Man-> Launchpad
<Fly-Man-> and what does Bazaar have
<Fly-Man-> svn2bzr is a tool to convert Subversion repositories into Bazaar repositories.
<Fly-Man-> But enough on the trunk problems
<Fly-Man-> because the main issue why I am not using Launchpad for my projects is mainly
<Fly-Man-> my users like svn and git
<Fly-Man-> and I don't want them to learn yet another code handling tool
<beuno> so maybe Launchpad is not the right tool...?
<Fly-Man-> beuno: Well, so far Launchpad is handy for the translations part
<Fly-Man-> that's about the only thing that works like a charm
<beuno> so use it for that
<Fly-Man-> I am
<beuno> good
<beuno> then you're happy
<beuno> I'm glad to see that
 * Fly-Man- shakes hand of beuno
<Fly-Man-> If you're happy with that, then I am happy too
 * Fly-Man- smiles
<beuno> I'm always happy
<Fly-Man-> beuno: Can you do me a favor then
<Fly-Man-> and delete the code part on 1 project
<Fly-Man-> as it won't import anyway
<Fly-Man-> https://code.edge.launchpad.net/fusionforge
<Fly-Man-> Leave the flyman trunk there
<Fly-Man-> I will use it to push the translations in
<beuno> you want me to delete this?  https://code.edge.launchpad.net/~vcs-imports/fusionforge/trunk
<Fly-Man-> Yes, as it won't import
<beuno> Fly-Man-, I need you to delete the series it's linked to: https://code.edge.launchpad.net/fusionforge/trunk
<Fly-Man-> You cannot delete a series that is the focus of development. Make another series the focus of development before deleting this one.
<beuno> that is annoying
<Fly-Man-> Yes
<beuno> I will need you to do that, unfortunetly
<Fly-Man-> Can you disable the import
<Fly-Man-> then I will redirect the translations to that one that's still there
<beuno> we can try and ammend the URL?
<beuno> see if that's what's making it fail?
<Fly-Man-> Hmm, I have a better idea
<Fly-Man-> let's just delete the project
<beuno> does "svn checkout svn://scm.fusionforge.org/svnroot/fusionforge/trunk: work?
<Fly-Man-> yup
<Fly-Man-> within 20 secs
<Fly-Man-> then I have the complete trunk
<Fly-Man-> I'm running Hudson to test the trunk
<Fly-Man-> so I know that it fetches within 20 secs
<beuno> pysvn._pysvn_2_4.ClientError: Connection closed unexpectedly
<beuno> so it's a connection error that's preventing it from importing
<beuno> it drops suddenly at some point
<Fly-Man-> yupz, I checked with the admin of that server
<Fly-Man-> he sees that Launchpad connects
<Fly-Man-> then after 1,5 or 2 mins Launchpad drops the connection
<beuno> well, I kicked off the import again while adding a trailing slash
<beuno> and it's working
<beuno> 2 minutes in
<Fly-Man-> poof
<beuno> and failed again...
<Fly-Man-> there is goes
<beuno> ok, so, if you're interested in pursuing this, file a bug
<Fly-Man-> beuno: it's almost like it doesn't like svn
<Fly-Man-> https://code.edge.launchpad.net/~vcs-imports/opensim/svn-trunk
<Fly-Man-> this is another project
<Fly-Man-> this tries to grab an svn from another server
<Fly-Man-> and after 1 hour, Launchpad just gices up
<Fly-Man-> but when you look on the buildserver
<Fly-Man-> the whole svn trunk is already there
<Fly-Man-> Same goes for the Git trunk
<Fly-Man-> as I wasn't sure if it was svn that had issues
<Fly-Man-> I tried to import the git trunk
<beuno> it's not good that there are so many failing imports, this is something that needs to be looked in to
<Fly-Man-> https://code.edge.launchpad.net/~vcs-imports/opensim/new-trunk
<Fly-Man-> So this is the Git trunk
<Fly-Man-> and it failed just as miserable as the svn
<Fly-Man-> but the git at least says something wise
<Fly-Man-> it can't decompile something
<beuno> yeah, this needs to be raised
<beuno> I've pinged the bzr-git developer about it
<Fly-Man-> but beuno, do you understand now why I don't have trust in the code importer /
<beuno> yeap
<Fly-Man-> :)
<beuno> it's not working reliably for you
<beuno> we need to fix it
<Fly-Man-> Okay, and that's why I saw the announcement for the launchpad going opensource
<Fly-Man-> and decided to give that a spin
<Fly-Man-> because 1 thing I miss is an option to import an already bazaar repro into Launchpad
<Fly-Man-> to have Launchpad as a backup
<beuno> there are imports for bazaar branches
<beuno> they are called mirrored branches
<Fly-Man-> how do I add one ?
<Fly-Man-> Ahh, register new branch
<Fly-Man-> then just setup mirrored ?
<beuno> yeap
<Fly-Man-> (KnitPackRepository('http://scm.fusionforge.org/bzr/fusionforge/.bzr/repository/') has no revision ...)
<beuno> right, sso you need to specify a branch
<beuno> not a repository
<Fly-Man-> beuno: All I entered is
<Fly-Man-> (KnitPackRepository('http://scm.fusionforge.org/bzr/fusionforge/
<Fly-Man-> http://scm.fusionforge.org/bzr/fusionforge/
<beuno> that is a repository
<Fly-Man-> Anonymous read-only Bazaar gateway (updated hourly)
<beuno> you need to point it to a branch
<Fly-Man-> bzr checkout http://scm.fusionforge.org/bzr/fusionforge/svn-trunk-ro fusionforge-trunk
<beuno> right, point it at: http://scm.fusionforge.org/bzr/fusionforge/svn-trunk-ro
<Fly-Man-> Hmm, I might know the answer to that one
<Fly-Man-> bzr 1.0
<Fly-Man-> K, I give up on this
<Fly-Man-> even with another url it fails
<maxb> Fly-Man-: If you look to the Launchpad licence, it's fairly clear that Canonical doesn't really want people to run their own Launchpads.
<Fly-Man-> maxb: I have seen it
<maxb> Which is sad, because that would be neat.
<Fly-Man-> maxb: Well, you can run your local version
<Fly-Man-> but you'd need to fiddle around to make it a working version
<maxb> But I can understand why given that running your own Launchpad either dilutes the value of launchpad.net, or takes away money that you might otherwise be paying to Canonical
<Fly-Man-> maxb: In what way would I be paying Canonical when I only want hosting of my open source projects ?
<maxb> If it's open source projects, that falls under the heading of "dilutes the value of launchpad.net"
<maxb> Part of what makes Launchpad great is that it's a one-stop-shop for OSS
<maxb> The money aspect is applicable if the motivation for running a Launchpad instance is private/proprietary projects
<Fly-Man-> yup
<maxb> Which I'd love to do at my office, if I could do it legally
<maxb> :-)
<Fly-Man-> and when FusionForge does the same with translations as Launchpad
<Fly-Man-> then I think my choice will be a lot easier ;)
<maxb> As far as LP documentation is concerned, I've seen Canonical folks make reference to the LOSAs private collection of howto wiki pages. If they were prepared to open those onto the dev wiki, I reckon there'd be a fair amount of interesting info there
<maxb> I should post to the mailing list
<Fly-Man-> maxb: I think I know the answer to that request
<abentley> rockstar: Around?
<maxb> It never hurts to ask
<Fly-Man-> maxb: True
<abentley> maxb: The LOSA documentation is, or should be, purely about operational issues.  I agree that anything which isn't should be opened.
<Fly-Man-> abentley: Does running cron jobs fall under that operational part ?
<abentley> Fly-Man-: Yes, I would think so.
<Fly-Man-> abentley: Then the docs are of no use ;)
<Fly-Man-> the operational part
<Fly-Man-> because as I heard earlier, the parts that someone would need most
<Fly-Man-> is the part that doesn't open up to the outside
<maxb> Well, it's nice that Canonical open-sourced it at all
<maxb> And Soyuz and Codehosting were going to be withheld at one point
<Fly-Man-> maxb: Yes, don't get me wrong
<Fly-Man-> I am very happy that it got opensourced
<Fly-Man-> but with opening up the source and then saying "Well, there's more but we won't tell you"
<Fly-Man-> but you can help us with improving
<maxb> Yeah, I agree that's an irritation
<Fly-Man-> then my feeling is that they did this just because large companies asked about it
<maxb> Well, helping improve LP helps me in that launchpad.net, which I use, gets better
<maxb> But there's an irritation in the "so close but so far" position
<abentley> Fly-Man-: We did it because open-source lovers wanted it open-sourced, and so that others could contribute.
<maxb> Also LP is teaching me a lot about large systems in Python
<Fly-Man-> abentley: Yes, but i've held that speech before this hour
<Fly-Man-> and someone pointed out that it's opensourced to make it better
<Fly-Man-> well, in order to make it better I would need to be able to have it running just like a development machine
<abentley> Fly-Man-: AIUI, large companies were no part of the motivation.
<Fly-Man-> so be able to test all the features that Launchpad.net has
<abentley> Fly-Man-: "make run_all" is what we developers use for that.
<Fly-Man-> abentley: but don't tell me that you don't have a cron job schedule with it
<Fly-Man-> or did you want to say that you don't use translations, code importer, etc ?
<abentley> Fly-Man-: Why not?
<maxb> There is documentation on the dev wiki that tells you what cronscripts to poke when to make codehosting work
<Fly-Man-> maxb: I know which scripts there are
<Fly-Man-> and also that they're run
<abentley> Fly-Man-: Us developers do not have any cron scripts scheduled.
<Fly-Man-> but what I lack to find is how many times a day 1 script is run
<Fly-Man-> or which scripts I need to run at what times
<Fly-Man-> because simply 3 scripts have names that tell me when to run then
<maxb> Well, you don't really need to know that unless you want the instance to work for something other than single-user development
<Fly-Man-> maxb: Exactly
<Fly-Man-> Why did you think I wrote the piece about the remote access ?
<Fly-Man-> not that I have 1 machine
<Fly-Man-> but that I can login with more then 1 machine to do testing
<maxb> And Canonical quite clearly doesn't want to facilitate you doing anything other than single-user development
<Fly-Man-> upload things
<Fly-Man-> maxb: Yes, that's the policy I feel
<Fly-Man-> but whenever a sys admin that's on this channel says
<Fly-Man-> "Hey, run rosetta-po-importer.py every 15 mins from the hour"
<Fly-Man-> then I would know how many times I would have to have it run
<Fly-Man-> or differently
<Fly-Man-> "I think you could run the code-importer.py every 5 mins"
<Fly-Man-> that would make more sense then
<Fly-Man-> "Uhm, we have no clue"
<beuno> that depends on your systems, traffic, etc
<abentley> Fly-Man-, maxb: We don't want a million different Launchpads popping up, because that dilutes the value of Launchpad as a system that connects multiple projects together.
<beuno> so, it's an operational issue
<beuno> so, it's not part of Launchpad
<beuno> dude, listen to what we're telling you
<beuno> we're not evil, we just don't work for you
<Fly-Man-> beuno: So in order to get the information that I would need for my version of testing
<Fly-Man-> I would need to write a nice email to the launchpad mailinglist
<Fly-Man-> or maybe the head of the development on Canonical
<beuno> you would need to do operational work
<Fly-Man-> and that's 1 thing that they'd prohibit by making this a single user development system
<Fly-Man-> no outgoing email
<abentley> Fly-Man-: The number of times you run code-importer per day is purely arbitrary.  Our particular crontabs are not something you would need to set up a competing service, much less do remote testing.
<Fly-Man-> etc
<Fly-Man-> abentley: But it would clarify some more about what the scripts do
<maxb> abentley and beuno are right: What we have here is a situation where people have been freely given access to a huge amount of code, but haven't been given all the pieces to use it in the way they want, and are focussing on the negative, despite the fact that we have any of it is a gift
<Fly-Man-> maxb: I agree on that
<Fly-Man-> It's a gift
<abentley> Fly-Man-: What would it clarify?
 * beuno high-fives maxb 
<Fly-Man-> abentley: It would clarify how many times I would run which script
<Fly-Man-> in order to have it perform like a development machine that could do production
<maxb> It would clarify what you would need to do to establish a working model of production.
<Fly-Man-> maxb: Correct
<maxb> You don't necessarily need a working model of production to be an effective developer
<beuno> yes, that would require work from our part on documenting it, probably changing the way some things work, etc
<Fly-Man-> as I am a developer that always tests things as if they're a production machine
<abentley> Fly-Man-: If the scripts aren't clear enough about their function for you to decide how often to run them, that's a bug we will happily fix.
<beuno> this is not what we want to spend time on, as a project
<maxb> In fact I doubt you could reasonably run a working model of the entirety of production on a single system and develop on it, unless it was uber-powerful
<Fly-Man-> abentley: So where do I place that bug then ?
<Fly-Man-> because I think that's a reasonable solution to this
<maxb> Fly-Man-: Well you'd start by examining every file in cronscripts/* and making a list of which ones you couldn't figure out
<abentley> Fly-Man-: When in doubt, file on the main launchpad project.  If it's misfiled, someone will fix it.
<maxb> an index to scripts/* and cronscripts/* broken down by launchpad application would actually be rather neat
<maxb> maybe we should start one on dev.lp.net
<Fly-Man-> maxb: And I would be happy to write those pages
<maxb> start one up and I'll happily help
<Fly-Man-> but in order to write things, I would need to know what the scripts would do, how many times they're run in a production environment
<maxb> No you wouldn't
<Fly-Man-> so I'll file a bug/blueprint to ask
<maxb> That would be silly
<Fly-Man-> maxb: Why would it ?
<Fly-Man-> abentley asked me to file one
<Fly-Man-> so I nicely written one
<Fly-Man-> And we'll see what the outcome of it will be
<maxb> He asked you to file a bug on scripts that were unclear as to their purpose. That is quite thoroughly independent from disclosure of production crontabs
<Fly-Man-> maxb: I filed a blueprint asking to be explained either in the scripts themselves or with a response on the purpose of the scripts in the cronscripts and scripts folder
<Fly-Man-> k, time for a restfull weekend
<Fly-Man-> Thank you all for listening and for all your advice :)
<mrevell-dinner> Night all
<barry> kfogel: nice
<kfogel> barry: now we have to actually remember to use it.
<kfogel> we'll see
<kfogel> barry: oh, hey, can you review a launchpadlib branch?  https://code.edge.launchpad.net/~kfogel/launchpadlib/426323-apidoc-html-title-attrs/+merge/12442
<kfogel> barry: easy one, just adds title attributes to the api ref HTML.
 * barry looks
<barry> kfogel: this looks fine.  are there any wadl related tests in the launchpadlib tree that you could piggyback on?  i don't know if launchpadlib currently tests its wadl or not
<kfogel> barry: I don't know either.
<barry> and unfortunately leonardr isn't around.  maybe flacoste knows?
<barry> kfogel: i'm going to mark this needs fixing for now, but if we find the answer it'll be an easy switch
<kfogel> barry: sounds good
#launchpad-dev 2009-09-26
<wgrant> kfogel: Your /Contributions script has become rather confused with the db-stable=>devel merge.
<kfogel> wgrant: oh really?
 * kfogel looks
<wgrant> kfogel: See r9571
<wgrant> Not sure of a good way to fix this.
<kfogel> ACK
<kfogel> sigh
<wgrant> You sort of have to run over both devel and db-devel, only counting real top-level merges.
<kfogel> wgrant: right, because it finds any top-level rev that includes a rev somewhere beneath it by that contributor.
<kfogel> wgrant: that was not a response to what you said
<kfogel> wgrant: just typing at same time
<kfogel> wgrant: yeah, I think LogExCons:log_revision() is where the logic needs to be tweaked.
<kfogel> wgrant: hmmmm, this is deeper than that.
<wgrant> kfogel: Is it?
<kfogel> wgrant: well, I just mean that first of all, running across two branches instead of one is going to change things a bit.  It's not rocket science, but it's not a fix localized to just that one method either.
<kfogel> I think your solution is basically right.  I'm worried what will happen when there's a db-devel -> devel merge, though.  We'll still need a way to distinguish a "real" top-level rev from that kind of merge rev.
<wgrant> kfogel: Perhaps just run across db-devel, and be a little bit special when both the parent and grandparent are PQM revisions.
<wgrant> Where by parent and grandparent I mean the other way around.
<wgrant> The two subsequent children, that is.
<kfogel> wgrant: I have to go have dinner with my girlfriend right now.  Could you file a bug, include a transcript of our irc session, and assign the bug to me?  (If you use Emacs, then http://svn.red-bean.com/repos/kfogel/trunk/.emacs has a function kf-irc-prettify you can use to format it nicely).
<wgrant> kfogel: Sure.
<kfogel> wgrant: thanks
<wgrant> kfogel: Bug #436957
<mup> Bug #436957: Contributions script gets confused with db-stable=>devel merge <Launchpad Foundations:New for kfogel> <https://launchpad.net/bugs/436957>
<wgrant> devel is back open already?
<rockstar> wgrant, yeah, I think it's open already.
<rockstar> Actually, already is a little inaccurate.  It usually opens the Friday after a release.
<wgrant> Ah. I thought I remembered it taking a little longer after 2.2.7.
<rockstar> It might have. Things were really hairy after we open sourced.  That might have had something to do with it.
<wgrant> Any sysadmins likely to be around ATM?
<wgrant> (see #launchpad)
<rockstar> wgrant, okay, looking for someone now.
<wgrant> rockstar: Thanks.
<wgrant> rockstar: The issue, as usual, is that poppy on germanium is dead.
<rockstar> lifeless, do you happen to have super powers for this?
<lifeless> nope
<lifeless> dey iz gone
<wgrant> Needs LOSA, sysadmin or possible cprov.
<rockstar> lifeless, okay.  I thought I'd ask, since you special circumstances folks have all sorts of random privs.  :)
<cprov> wgrant: I'm on it.
<rockstar> wgrant, yea, I think I'm going to have to wake someone up.
<lifeless> rockstar: :) - SC is gone now ;)
<rockstar> cprov, yay!
<wgrant> cprov: Thanks.
<rockstar> lifeless, really?  So are you on the Bazaar team now?
<lifeless> rockstar: have been since stevea moved to online services
<wgrant> cprov: In case sysadmins can't be raised in a reasonable amount of time (since this happens often), cocoplum's poppy is just as good, isn't it?
<lifeless> SC got split at that point; stub -> foundations, jamesh to online, me to bzr
<cprov> ppa.l.n:21 is up
<rockstar> lifeless, ah, interesting.
<wgrant> Ah, didn't know stub was SC.
<rockstar> cprov, you is awesome.
<lifeless> it wasn't a very formal dept :)
<rockstar> Yea, that's what I gathered.
<cprov> wgrant: I'm not sure what you mean ... half-dead :)
<rockstar> lifeless, although I was still quite new when Online Services was created.
<Chex> rockstar: I think ftp /put is back now
<wgrant> cprov: I mean that cocoplum's poppy should be able to accept PPA uploads too, right?
<cprov> wgrant: yes, it does
<cprov> wgrant: and fails less often
<cprov> wgrant: I'm pretty sure LOSAs got smsed due to the poppy failure, I will check with them Monday.
<wgrant> cprov: Even on weekends?
<cprov> wgrant: uhm, you are right, probably on weekends
<rockstar> wgrant, how do you think codebrowse stays up.
<rockstar> (for various definitions of "up")
<lifeless> superglue
<wgrant> rockstar: Well, it often doesn't...
<rockstar> lifeless, we need a python library called superglue.
<wgrant> cprov: btw, myÂ lp-buildd and pkg-create-dbgsym changes are with their respective owners now.
<cprov> wgrant: yeah, I just saw it. Nice one!
 * cprov -> bed
<cprov> g'night duderinos!
<wgrant> Night cprov.
* bac changed the topic of #launchpad-dev to:  This is Launchpad Development Channel | Week 4 of 3.0 | PQM is OPEN | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in #launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | This channel is logged: http://irclogs.ubuntu.com/
<kfogel> jml: are you on?
#launchpad-dev 2009-09-27
<asabil> hi all
<wgrant> Hi asabil.
<asabil> I wanted to construct a python egg from the launchpad source code
<asabil> so I did run python setup.py bdist_egg
<asabil> the egg is successfully built, but it seems like the dependencies are quite incorrect
<asabil> or at least they don't include the version (which leads to breakage with zope > 3.5)
<asabil> are there any plans to make use of the versions.cfg file in setup.py ?
<wgrant> asabil: Why do you want to do that? It would be quite difficult, as there are lots of non-egg dependencies.
<asabil> wgrant: actually I want to run a launchpad instance where I work
<asabil> and the easiest way to deploy it seemed to build an egg
<wgrant> asabil: You know that running your own is very strongly discouraged, and that you can't do that without replacing all of the images, and that it's deployed using bzr normally?
<asabil> wgrant: well it is an internal instance within the company I work for
<wgrant> asabil: Even so, you cannot legally run it without replacing all of the images.
<asabil> wgrant: that's fine
<asabil> I will do that
<asabil> the question is then, how do I deploy launchpad using bzr ?
<maxb> asabil: you run a development instance by following the instructions on the wiki
<maxb> Canonical have not disclosed documentation on deployment per se
<Fly-Man-> Morning
<Fly-Man-> Anyone else having troubles installing the dev version
<Fly-Man-> With the latest bazaar, i get segmentation fault while it's working on fetching the trunk
<mwhudson> hello
 * mwhudson doesn't suppose there are going to be many people around today
<spm> mwhudson: (not in yet, just passing thru): given that sysadmins don't qualify as people, I will have to concede the statement.
 * mwhudson wonders how other developers would react to code being landed r=spm
<spm> "W.T.F. Crack is this P.O.S.!!?!?!?!?" <== suggested response
<Fly-Man-> What's happening ?
 * Fly-Man- tries to grab the latest code for launchpad
<Fly-Man-> and I keep getting the segmentation fault on it ?
<mwhudson> Fly-Man-: !!
<mwhudson> Fly-Man-: what platform/bzr version?
<Fly-Man-> mwhudson: Ubuntu 9.04, bzr 2.0.1
<Fly-Man-> bzr pulled from the ppa that's described here
<Fly-Man-> https://dev.launchpad.net/Getting
<mwhudson> Fly-Man-: that's certainly unexpected
<Fly-Man-> mwhudson: Uhm, yes
<Fly-Man-> tell me about it ...
<Fly-Man-> the only error log that I get is
<Fly-Man-> Making local branch of Launchpad trunk, this may take a while... ./rocketfuel-setup: line 372:  9105 Segmentation fault      bzr branch http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/ $LP_TRUNK_NAME ERROR: Unable to create local copy of Rocketfuel trunk
<Fly-Man-> And I have had this issue with 1.18 as well
<Fly-Man-> but then I cleanslated the machine
<Fly-Man-> installed it again
<Fly-Man-> and then it worked
<mwhudson> Fly-Man-: can you try running gdb --args python `which bzr` branch http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/ ~/launchpad-trunk
<mwhudson> ?
<Fly-Man-> sure
<mwhudson> Fly-Man-: do you know how to use gdb at all?
<Fly-Man-> bope
<mwhudson> so type c and press return at the '(gdb)' prompt
<mwhudson> then wait, and see if it crashes
<Fly-Man-> The program is not being run. ?
<mwhudson> Fly-Man-: oh, sorry, 'r'
<Fly-Man-> j
<Fly-Man-> k
<Fly-Man-> it's running
<mwhudson> of course, it will probably work fine now
<Fly-Man-> It's still downloading
<Fly-Man-> usually it fails at about 175 Mb
<Fly-Man-> it's at 78 now
<Fly-Man-> Yupz
<Fly-Man-> there it is:
<Fly-Man-> [#########\          ] 141001KB   510KB/s | Fetching revisions:Inserting stream Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb7ea66c0 (LWP 3653)] 0x0810ab1a in ?? ()
<mwhudson> Fly-Man-: can you run 'bt' and pastebin the output?
<Fly-Man-> http://launchpad.pastebin.com/d64861a3d
<Fly-Man-> Voila
<mwhudson> Fly-Man-: argh, that's not so useful :/
<Fly-Man-> mwhudson: What were you expecting ?
<mwhudson> Fly-Man-: do you mind installing python-dbg and trying again?
<Fly-Man-> Nope,the machine is already messed up anyway :p
<Fly-Man-> same command ?
<mwhudson> Fly-Man-: yeah
<Fly-Man-> running now
<Fly-Man-> mwhudson:
<Fly-Man-> got the error now
<Fly-Man-> http://launchpad.pastebin.com/d364c32a9
<mwhudson> Fly-Man-: bt again?
<Fly-Man-> http://launchpad.pastebin.com/d1e011574
<Fly-Man-> Need to jump into bed now
<Fly-Man-> mwhudson: But if you see anything interesting, I will be back in Â± 10 hours
<Fly-Man-> Nite :)
<mwhudson> "hmm"
<lifeless> mmh
#launchpad-dev 2010-09-27
<lifeless> man, where did the day go
<mwhudson> lifeless: good question
<poolie> hello lifeless, mwhudson
<mwhudson> poolie: i've gotten a bit confused, sorry to say -- do you want me to land your mbp-trivial branch?
<poolie> i'd like someone to do it
<poolie> i don't think i have the right to land myself atm
 * thumper -> modaks for lunch
<lifeless> are you in ~launchpad? if so you should modulo someone putting your key in pqm
<lifeless> which is a simple losa request :)
<mwhudson> poolie: i'll land it then
 * poolie looks
<poolie> also, landing is kind of a many-roundtrip thing
<poolie> and it seems to mess up my "i'll spend one day on launchpad" plan
<lifeless> yeah, I can get that
<mwhudson> well, if you get in the position that you can run ec2 land yourself it's a lot easier
<mwhudson> but yes
<lifeless> happy to do for you in general, just noting that policy wise, you should be allowed
<poolie> i realize it may be partly my fault but the mean latency is somewhere over 24h
<poolie> s//well over
<poolie> thanks
<poolie> just got a "thankyou" mail for bzr, specifically for mgz
<poolie> and also for gnukeyring
<poolie> what a nice way to start the week
<poolie> btw i'm sure this landing latency will get better
<mwhudson> i was saying to jml the other day that one thing i miss least from the days of officially being a launchpad hacker is the battle to land branches
<lifeless> I've figured out why we get N running librarians
<mwhudson> poolie: your branch is playing in pqm now
<lifeless> mwhudson: you're now doing that what, 50% of the time ;P
<lifeless> we get N running librarians because:
<lifeless>  - we use atexit (which isn't what you might think it is)
<mwhudson> lifeless: only when cody-somerville is being slow at reviewing branches
<lifeless>  - the existing kill-stuff code looks in $root/librarian.pid
<lifeless>  - we rm -rt $root
<lifeless> s/rt/rf/
<lifeless> mwhudson: oh, so your soyuz-skin is going into a different tree?
<lifeless> or you're working on this bash stuff?
 * lifeless twists the knife
 * mwhudson goes for a walk in the sun instead
<lifeless> mwhudson: I am genuinely interested in the soyuz skin project, its very unclear to me where its at.
<mwhudson> lifeless: yes, a fair bit of bash hacking
<mwhudson> lifeless: i think "a bit stalled" would be the current summary
<mwhudson> lifeless: salgado would know more than me
<mwhudson> back in a bit
<poolie> heh, how can anyone not be in ~launchpad-users? :)
<lifeless> kk
<poolie> (i realize it's a list)
<poolie> i am in ~launchpad
<lifeless> we could add new accounts to it automatically
<poolie> can i send a mail or should you?
<poolie> an RT, i mean
<lifeless> then they would get a prompt to subscribe straight away.
<lifeless> poolie: you should; usual thing.
<poolie> k thanks
<lifeless> oh yeah, I know where the day went. daylight savings.
<lifeless> nz is UTC+13 now
<lifeless> and with my typical early start
<lifeless>  5 files changed, 60 insertions(+), 85 deletions(-)
<lifeless> \o/
<lifeless> mwhudson: and here is your monday present https://code.edge.launchpad.net/~lifeless/launchpad/test/+merge/36674
<michaelh1> Afternoon.  Can access the blueprints on a project from the API?
<poolie> hi michaelh1, i think you can
<mwhudson> uhh
<beuno> I thought blueprints didn't have an API at all?
<mwhudson> i don't think blueprints are _very_ exposed
<beuno> :)  hi mwhudson!
<mwhudson> hi beuno
<michaelh1> poolie: I see there's a 'specification' object in the API docs but no 'specifications_collection' on a project
<lifeless> james_w put them up on the API
<lifeless> they are probably still quite vestigial
<mwhudson> certainly, there is a lot of permission-by-view in the blueprints code, so i really hope those bits aren't exposed
<lifeless> probably it is
<lifeless> acid test on whether stallman was right about needing passwords
<mwhudson> seems like the only bit that's exposed is for linking/unlinking branches and specs, probably for ajax love to that feature?
<ajmitch> mwhudson: I think that's what was blocking that branch from being merged, last I saw it was still a work in progress
<wgrant> mwhudson: That was my vague recollection, yes.
<mwhudson> michaelh1: you can ask the linaro infrastructure team to work on this if you like :-)
<lifeless> mwhudson: but they might go blind :P
<michaelh1> mwhudson: I might do.  I'm looking for some type of meta blueprint that has others attached to it.  The current Launchpad UI makes this hard to navigate
<ajmitch> lifeless: I would say "it's not that bad", but then again it's why I didn't go any further with it :)
<lifeless> ajmitch: its primarily a) old and b) unmaintained.
<wgrant> c) pointless
<ajmitch> both of which don't really lend themselves well to having someone jump in & do a few fixes
<lifeless> its currently unique in LP
<wgrant> lifeless: Howso?
<lifeless> I have sympathy for the view that blueprints and bugs should be facets of one thing; but at the moment thats the way it is
<lifeless> wgrant: ^
<wgrant> lifeless: How is it unique?
<lifeless> wgrant: dependencies primarily
<wgrant> Ah.
<wgrant> Yes.
<lifeless> also some of the reports
<wgrant> It also shells out to dot.
<wgrant> I died inside when I saw that.
<ajmitch> on page view?
<wgrant> Yes/
<ajmitch> oh my
<lifeless> old skool
<persia> Very
<ajmitch> I bet that won't fall under the 99% rule very easily
<lifeless> for rendering?
<lifeless> mmm separate resource I think; also deleted nw.
<ajmitch> ok
<lifeless> (At least, i think it was deleted)
<wgrant> I didn't think it was deleted.
<wgrant> Maybe the full project overview thing.
 * ajmitch woudl think it could take awhile to do if it was a large graph of blueprints, and that page hadn't been hit recently
<wgrant> https://blueprints.edge.launchpad.net/soyuz
<mwhudson> fortunately it's also totally unreadable when there are a lot of blueprints
<wgrant> Launchpad also doesn't know how to capitalise its own name, apparently.
<ajmitch> wgrant: that's amusing, given how https://blueprints.edge.launchpad.net/launchpad-project links to it
<wgrant> Indeed.
<wgrant> The blueprint listing reminds me of the good old days.
<wgrant> Of the really old 2005-ish theme.
<ajmitch> that was stylish
<lifeless> hey
<ajmitch> at least compared to the ubuntu bugzilla :)
<lifeless> anyone know how to get buildout working outside of LP?
<mwhudson> lifeless: svn cat <some url> > bootstrap.py; python bootstrap.py
<james_w> the branch is blocked on making the model safe to expose
<james_w> I have a partial branch to do that, I think the main thing before it can be reviewed is some permission checks which involve moving some code from security.py to the model
<lifeless> mwhudson: I meant in zope.testing specifically
<lifeless> mwhudson: this is what I was meaning:
<lifeless> http://pastebin.com/Q2KbG7rs
<ajmitch> oh, that problem - I ran into that in the weekend & didn't go any further
<mwhudson> lifeless: that looks odd
<lifeless> mwhudson: this happens every time I attempt to use buildout.
<lifeless> mwhudson: I've a pretty firmly entrenched opinion now.
<mwhudson> there are some arguments you can pass to bootstrap i think...
<ajmitch> lifeless: this is why I was complaining in #nzpug this morning about buildout :)
<lifeless> it trying to write to /usr/local is spectactularly naughty.
<mwhudson> lifeless: bootstrap.py --eggs=eggs maybe
<lifeless> mwhudson: this isn't in the LP tree, I don't see why that would help ?
<mwhudson> lifeless: i think this will make it install eggs in a directory called 'eggs'
<lifeless> its finding my existing setuptools deb package, then going nana
<mwhudson> lifeless: rather than /usr/local
<lifeless> mwhudson: ah, interesting.
<mwhudson> lifeless: i'm cargo culting, clearly, but try it
<lifeless> sure
<lifeless> I probably shouldn't be so negative about it
<lifeless> except that it seems to be a net time consumer
<mwhudson> i have mixed feelings about buildbot
<mwhudson> when it works, it's quite ok
<mwhudson> when it doesn't, it's ****ing mysterious at times
<lifeless> robertc@lpdev:~/zope.testing$ python ./bootstrap.py --eggs=eggs
<lifeless> Error: Invalid option --
<mwhudson> um
<mwhudson> i meant buildout there
<mwhudson> although both statements are accurate
<mwhudson> !?
<lifeless> mwhudson: spectacular
<lifeless> :)
<lifeless> $ python ./bootstrap.py bootstrap --help
<lifeless> Getting distribution for 'distribute'.
<lifeless> ...
<lifeless> see under 'above failure'
<mwhudson> maybe the bootstrap.py in the zope.testing tree is very old?
<lifeless> http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=error+%2Fusr%2Flocal%2Flib%2Fpython2.6%2Fdist-packages%2Fsetuptools-0.6c11-py2.6.egg-info%3A+Permission+denied
<lifeless> its not an unknown thing :)
<mwhudson> yeah i tried that too :)
<lifeless> I think this is a sign that I should migrate my lappy to maverick too
<lifeless> so, I shall.
<wgrant> Beware the wallpaper.
<lifeless> wgrant: Doom3 >> all other.
<wgrant> Hm?
<lifeless> I've not had a default wallpaper in many many many years
<lifeless> my desktop does, so I already know what the mav paper looks like.
<wgrant> Ah.
<mwhudson> i see my desktop about once a month
<wgrant> I occasionally empty a workspace, and then am blinded.
<lifeless> the moire on my 1600x1200 crt is quite spectacular
<lifeless> wheee wow dpkg is slow these days.
<lifeless> fsync for the -pain-
<lifeless> [on ssd no less]
<poolie> https://bugs.launchpad.net/bugs/648504 has a complaint about the dupefinder being too tight now
<_mup_> Bug #648504: exceptions.NotImplementedError: should resend request to http://feeds.edge.launchpad.net/bazaar/, but this isn't implemented <Bazaar:New> <https://launchpad.net/bugs/648504>
<poolie> i realize it's a tradeoff
<spiv> What would be magic would be some sort of "yes this traceback and version match (and this traceback isn't a symptom of multiple separate bugs)" dupe-matching.
<spiv> But there's a fair bit of handwaving involved in describing exactly what would be awesome there :)
<wgrant> spiv: apport does that.
<wgrant> The retracers compare stack traces and dupe bugs as appropriate.
<spiv> wgrant: not exactly
<spiv> Right, after I've either filed my bug or, as a reporter, decided one of the suggested bugs is probably the same even though I'm not a developer and hardly qualified to know.
<wgrant> It has been argued that the dupefinder should be disabled for crashes, since the retracers can match them much more accurately.
<spiv> I've been regularly asked by Launchpad recently to judge if random Xorg crash reports from other people with vaguely similar laptops are the same as mine, whic his a bit erid.
<spiv> s/erid/weird/
<spiv> Almost as weird as that typo!
<spiv> Yeah, that would make sense to me.
<jtv> mwhudson: did you see the oopses for the recipe branch build?  BuildFarmJob without specific_job.
<jtv> (See the launchpad-dev list.)
<wgrant> jtv: You sure it was a recipe build?
<jtv> wgrant: BuildFarmJob.job_type == 3
<jtv> That's a RECIPEBRANCHBUILD, according to my map.
<wgrant> Ah.
<wgrant> That kind of BuildFarmJob.
<wgrant> Errrrrrrr.
<wgrant> Hwhat?
<wgrant> Oh, wait, misread.
<wgrant> Fail.
<wgrant> Is there a packagebuild with build_farm_job=1977174?
<cody-somerville> Is anyone here familiar with how pip interprets package versions?
<wgrant> I know just enough to not drown. What's the issue?
<cody-somerville> wgrant, sent you pm since its offtopic
<adeuring> good morning
<poolie> does the lp webapp have a default log file in production?
<bigjools> good morning
<poolie> hi bigjools
<thumper> bigjools: morning / evening
<poolie> hi jml ?
 * bigjools has too much email
<wgrant> Morning bigjools.
<bigjools> hello William
<mrevell> Hello
<bigjools> morning mrevell
<wgrant> bigjools: Ubuntu wants ubuntu-release to be able to accept from UNAPPROVED in the Release pocket, and ubuntu-sru from UNAPPROVED in Proposed. Do you have any objections to extending queue admin perms to include optional pocket and status restrictions?
<bigjools> wgrant: provided I see a bug filed with a comment from Colin, that's fine
<wgrant> bigjools: Great, thanks.
<bigjools> wgrant: however I don't want those values hard-coded
<bigjools> I guess we can do it through ArchivePermission
<wgrant> bigjools: Certainly not. I'll just extend ArchivePermission to have upload_status and pocket fields.
<wgrant> Like we do with components already.
<bigjools> cool
<bigjools> yay for nullable FKs
<jml> hello everyone.
<bigjools> morning jml
<jml> bigjools, hi
<bigjools> jml: did you do any more work on the tests over the weekend?
<jml> bigjools, fwiw, I didn't get around to buildd-slavescanner.txt. I got fed up with having to do that TwistedLaunchpadZopeless dance so I started work on Deferred support for testtools.
<jml> bigjools, and then my batteries ran out.
<bigjools> heh
<bigjools> you need to run powertop
<jml> bigjools, I wanted to land a branch that killed buildd-slavescanner independently of the refactoring
<jml> bigjools, I do so from time to time
<bigjools> something's screwing you over
<jml> bigjools, I think it was Chrome, actually
<bigjools> npviewer.bin?
<jml> no, I don't think so.
<wgrant> :( A power problem not caused by Flash?
<bigjools> jml: ok did you figure out those adaptation errors?
<jml> bigjools, no. just focused on buildd-slavescanner
<bigjools> ok
<jml> bigjools, only had 90mins of hacking time :)
<bigjools> so you didn't change any of the builderslave-resume branch?
<bigjools> (which appears to  be the new integration branch!)
<jml> bigjools, I'll push up what I've got.
<jml> bigjools, I don't think I did.
<bigjools> ok
<bigjools> I will spend the next million hours reading email then get back to that branch
<lifeless> yay upgrade glitches
<jml> lifeless, yay indeed.
 * bigjools WTFs at the wtf bug tag
<bigjools> StevenK: will i-f-p skip disabled arches?
<jml> stub, will -vvv on ./bin/test also give transaction debug messages?
<stub> jml: Doubtful - I don't think test runners can use the python logging module as that is being used by the tests they are running.
<jml> stub, cool. checking since we run w/ -vvv on ec2.
<StevenK> bigjools: Doubtful, since that didn't exist when I was working on it.
<lifeless> stub: jml: You could sensible capture debug messages to a detail.
 * lifeless crashes completely.
<bigjools> StevenK: ok can you add it to the list please, it's critical to get fixed before natty
<wgrant> Do we have a rollout before natty?
<wgrant> Doesn't the current i-f-p stuff live in db-devel?
<bigjools> we don't have a db rollout
<stub> lifeless, jml: Yes. We could make bin/test add a handler to getLogger('txn') that emits messages where we want, although we might have to reset it after every test in case the test tore things up.
<lifeless> stub: not bin/test - use a Fixture and register it with self.addDetail.
<StevenK> wgrant: No
<StevenK> bigjools: Right, I'll sort it out tomorrow
<wgrant> StevenK: Ah, good.
<bigjools> StevenK: thanks - I'll add a card now
<StevenK> It should be quite quick
<jml> stub, I think lifeless is talking about the facility in TestCase where you can add details to test output in response to certain events (generally exceptions)
 * wgrant pokes at apt-ftparchive.
 * bigjools gets caffeine
<stub> Right. We could do it, but we haven't done it :)
<StevenK> bigjools: It can be worked around with application of -a
<stub> As it emits a log message when the transaction starts, this might be useful for tracking down code that holds open long running transactions which can be sucky (such as the transaction being opened by Storm refreshing a property...)
<wgrant> Gnargh lucilleconfig kill kill.
<wgrant> Oh wtf.
<wgrant> bigjools: We need to stop creation of new arch-indep publications before maverick, or we'll need to do some manual cleanup before maverick gets changed to CURRENT.
<wgrant> Since we need p-d-r to remove all the files.
<bigjools> wgrant: gnar
<wgrant> Hm, except that p-d-r doesn't obviously respect the Release pocket freeze, so it might be OK to have it remove them afterwards.
<bigjools> I'd rather it worked now
<wgrant> At least there appear to only be two places that create arch-indep publications.
<wgrant> So, fix those two locations, tweak lucilleconfig to exclude disabled DASes, Delete existing publications, and we may be able to get maverick into a sane state.
<wgrant> I think.
<wgrant> Has the on-disk archive ever been compared with what Soyuz thinks should be there?
<bigjools> not to me knowledge
<bigjools> my*
<wgrant> p-d-r looks buggy, so I suspect there's a lot of cruft in the pool.
<deryck> Morning, all.
<jml> deryck, good morning
<bigjools> wgrant: fyi, I just filed bug 648715
<_mup_> Bug #648715: Binary publications should not be created for disabled architectures <soyuz-publish> <Soyuz:Triaged> <https://launchpad.net/bugs/648715>
<gmb> Okay, I know that I know the answer to this, but I can't remember what it is for the life of me: "psycopg2.InterfaceError: connection already closed" <-- what is that and why is it happening? Any ideas?
<wgrant> gmb: Your PostgreSQL may be in recovery mode.
<wgrant> Check its logs.
<wgrant> Hm, no, that's a different thing.
<gmb> wgrant, It is a pg problem though; make schema is blowing up. I'll dig into it further. Thanks for the pointer anyway.
<jml> danilos, hi
<danilos> jml, hi
<jml> danilos, marjo has asked for a feature along these lines: "Enable translators working in Launchpad to seamlessly submit those translations to the upstream project to which they apply. "
<jml> danilos, I thought we did that already.
<danilos> jml, well, "seamlessly" is very hard... that's next on our list after we've got the "seamless" imports going
<danilos> jml, ("next on our list" if we are to continue on our bridging-the-gap theme for translations)
<danilos> jml, what we've got know are partial tools that enable people to do lot of that work manually
<danilos> s/got know/got now/
 * bigjools notices the EINTR bug that poolie fixed and doesn't know whether to laugh or cry
<jml> danilos, you guys are working on smoother imports now?
<danilos> jml, "seamless" would be to have a button saying something like "submit these translations upstream" where they'd get into the upstream workflow for handling translations
<danilos> jml, well, it's more like "we are still working on that"
<danilos> jml, it's been going pretty slow
<danilos> jml, "smoother imports" is getting translations directly from upstream into ubuntu
<jml> danilos, with what degree of interaction from users / admins?
<danilos> jml, two differing steps: 1. get upstream translations into LP upstreams (requires code imports and admin interaction for now, but already possible); 2. set up packaging links between upstream series in LP and Ubuntu sourcepackages
<danilos> jml, for 1, we want to improve the process further once we have the groundwork laid out to support actual sharing of translations between ubuntu and upstreams
<jml> danilos, I think Registry has done a lot of work on making code import, project registration & linking easier. Not 100% sure about series branches specifically.
<danilos> jml, 1. already works for a wide range of intltool- and gettext-based upstreams, but requires admin set-up which is not nice
<jml> danilos, admin set up per package?
<danilos> jml, I know, they are doing a good job with splitting the "official_*" tags as well
<danilos> jml, in general, for translations it's pretty simple to set up so we just need to follow the same pattern and come up with good privilege models
<danilos> jml, basically, set-up for translations should only include "this has external translations, IMPORT THEM" and "link the series with sourcepackage"
<danilos> jml, "link the series" step is pretty nicely handled by registry folks already
<jml> cool.
<danilos> jml, though, it'd be nice to integrate into one step if someone's interested in doing it all in one code (i.e. integrate set-up code branches, turn the translation imports on, link to source packages steps)
<danilos> s/in one code/in one go/
<danilos> typing ahead of me :)
<jml> danilos, I guess there are two potential issues with having them split up: multiple POSTs, and users not necessarily knowing what the next step is
<danilos> jml, well, there's always ajax, and there's always code-reuse :) if we make those bits of pages nice reusable ajaxy "portlets" (not necessarily in zope sense, but just bits that can be plugged into other pages), it would make a nicer experience without increasing our workload too much
<danilos> jml, fwiw, some of these things might already be easily reusable, I haven't looked
<jml> danilos, you said there's some ground work that needs to be done. I had thought you'd already done it.
 * jml nods
<danilos> jml, well, we've got a huge feature branch in progress that I said is going slower than expected: that's to actually get upstream translations shared with Ubuntu directly
<danilos> jml, we are nearing completion of that bit, but likely not this cycle after all
<jml> danilos, I understand :) huge feature branches being what they are.
<jml> danilos, with the other side, sending translations upstream seamlessly -- is there any reason to *not* do it after you've done the inbound direction?
<danilos> jml, not really, it's just a lot of work because many upstreams will have differing needs... but we should attack it in a similar way, go for big "easy" upstreams first (gnome, kde, translationproject), then for big "hard" upstreams (mozilla, openoffice) and so forth
<jml> danilos, cool
<jml> danilos, it's rather nice that our broader plans happen to mesh with what Ubuntu says they need :)
<danilos> jml, yeah, I am very happy with that as well :)
<jml> danilos, thanks for your time. I'll let Marjo know our current plans.
<danilos> jml, cheers
<jml> flacoste!
<flacoste> hi jml!
<jml> flacoste: welcome back :)
<flacoste> hello fellow launchpadders!
<noodles775> Hey! Welcome back flacoste
<flacoste> hi noodles775! are still a launchpadder ;-)
<flacoste> or did you move on already?
<flacoste> not that I wouldn't greet you if that was the case :-)
<noodles775> heh, yep - will be switching sometime soon, but just working on some soyuz UI work beforehand.
<noodles775> (And I'll still be here on #launchpad-dev anyway)
<bigjools> hey flacoste, flumper will be pleased to see you :)
<flacoste> bigjools: yeah, he told me that he was looking forward to give me my job back!
<flacoste> you guys gave him a hard time?
<bigjools> depends who "you guys" is I guess :)
<deryck> hey wb flacoste!
<flacoste> hi deryck!
<wgrant> bigjools: Disabling an arch is somewhat problematic. If you disable it (to prevent new publications) then mark its publications deleted, it never gets published to actually remove them.
<bigjools>  /o\
<bigjools> grar
<wgrant> But I suppose we won't be doing this until powerpc dies in at least a couple of releases.
<bigjools> ?
<wgrant> bigjools: We shouldn't be disabling another DAS until powerpc dies. And that will be a while.
<wgrant> And sparc/ia64 need manual cleanup anyway, so it's not too bad.
<bigjools> ok
<bigjools> right
<wgrant> Hmmm.
<cr3> buildout question: is there a way to leverage buildout someone to build against package versions available in a particular release to make sure the code will work on that release?
<jml> huh?
<jml> sinzui: you around?
<sinzui> I am
<jml> sinzui: there have been some requests about blueprints on the stakeholder list. I have this feeling that you're the right person to talk to to get a sense of difficulty of implementation
<sinzui> jml :( Am I really the last remaining engineer to have hacked on blueprint?
<jml> sinzui: I don't know! You just have a blueish tinge to your aura.
<sinzui> I can help. I am pretty knowledgeable of the bug reports that often underly a blueprint feature request
<jml> sinzui: cool.
<jml> sinzui: what we want, probably, is easy ways to get a list of blueprints that are assigned to members of a given team
<sinzui> That sounds a lot like my proposal to find the intersection of items assigned to a team for a milestone. I really would like a common way to say I want to see the items for the members of a team for any structure
<cr3> jml: what that "huh" for me?
<jml> sinzui: yes, that would be ideal.
<jml> cr3: I guess when you say "release" you're talking about something other than a release of Launchpad.
<cr3> jml: sorry, yes, I meant release of Ubuntu
<jml> cr3: the whole point of buildout is that you are insulated from the underlying OS.
<jml> cr3: well, maybe that's the whole point.
<cr3> jml: that is indeed a point but I figured it would also be used to couple with a particular OS
<cr3> jml: for example, I happen to used a dependencies branch from where buildout can only get dependencies, nowhere else. I use this as a snapshot of what is known to work, rather than relying on the latest code. I believe launchpad does the same under source-dependencies or somesuch
<cr3> jml: however, if that list of packages were taken from the release of an OS, that would provide somekind of predictability that it should work on the OS. the problem with that is that: 1. the orig.tar.gz files on archive.u.c are named funny; 2. those files are also not quite what's on the release of the OS.
<cr3> jml: so, perhaps another approach would be to bzr branch lp:ubuntu/release/dependency instead of using tarballs
<cr3> jml: I was hoping this was already attempted by someone so that I could learn from their experience rather than wasting time myself finding out there's a real problem
<jml> cr3: perhaps. you might also want to ask on general zope channels.
<jml> abentley, jelmer: where are we at with being able to import non-master git branches?
<abentley> jml: it's not something I've been following.
<jml> abentley: np. just picking on you as a visible code team member :)
<abentley> jml: the issue is that bzr-git is tied into the standard Bazaar branch behaviour, and that doesn't support colocated branches.
<abentley> jml: so someone from the Bazaar team could update you on colocated branch support.
<jml> abentley: ta. I'll mosey on to #bzr.
<deryck> *sigh*
<deryck> I wish I had a notification system that would ping me -- "the builders are up and green.  go for it! now!"
<wgrant> Don't worry, there's still gambling involved -- if you're lucky we'll be in testfix again by the time EC2 finishes :)
<deryck> heh
<deryck> My statement presumed I had already had a couple ec2 failures and was prepared to go to pqm directly.
<wgrant> Ah.
<wgrant> Thus ensuring that the cycle continues.
<deryck> maybe.  In this case, I had a translations windmill test that failed in ec2, and I ran locally with no issues.  So submitted directly.
<jml> sinzui: hi
<sinzui> hi jml
<danilos> deryck[lunch], it might be a test that could be helped with a longer timeout somewhere for ec2 runs, it's useful if you file a bug so we can look at it and close it as 'invalid' because we can't reproduce it... I mean, perhaps increase a timeout for a page load or two if it's a clear-cut case like that
<jml> noodles775: do I remember wrongly, or were you looking at generic comments code recently?
<noodles775> jml: Yes I was.
<abentley> jml: I was, too.
<jml> ooh.
<jml> well, my question to both of you...
<jml> ted was asking about attachments on MPs
<jml> I thought this was roughly analogous to sharing comments code between bugs & MPs.
 * noodles775 didn't realise the lp.services.comments code was used by bugs yet?
<jml> I don't know if it is
<jml> I'm asking you :)
<jml> I guess not then.
<noodles775> AFAICS, the distroseriesdifference comments were the first re-use, but abentley might know more.
<abentley> jml: I'm pretty sure the display of comments is shared between bugs and merge proposals.
<noodles775> abentley: grep for "from lp.services.comments"
<noodles775> In db-devel I see only code and (now) registry (for the distroseriesdifferences)
<stub> Do we ever delete Revisions? Might we ever?
<abentley> rockstar: didn't we work on sharing comments code with bugs?
<noodles775> jml: sorry, what was your question?
<jml> noodles775: I still haven't formulated it yet :)
<rockstar> abentley, I think thumper did something like that.
<jml> perhaps, a) how different are MP comments and bugs comments at the code level?
<jml> and b) how easy would it be to extract the bugs attachment thing and make it re-usable
<noodles775> jml: don't MP comments already support attachments?
<jml> noodles775: I think there's no web UI for it
<wgrant> They're also implemented rather differently.
<wgrant> MPs just look at extra MessageChunks.
<wgrant> Bugs have explicit BugAttachments created from MessageChunks.
<rockstar> abentley, jml, noodles, I'm pretty sure BjornT and thumper talked about how to unify them.
<noodles775> jml: but fwiw, I don't see why the UI code couldn't be shared in lp.services.comments
<jml> rockstar: noodles775: thanks.
<cr3> out of curiosity, where does the name "assets" come from in respect to static css files seem to be built?
<noodles775> Night all.
<maxb> [Merge] lp:~mterry/gnome-control-center/ubuntu-2.32.0 into	lp:~ubuntu-desktop/gnome-control-center/ubuntu
 * maxb is deeply confused why ~vcs-imports got attached as a reviewer to that
<bdmurray> Is there a convenient way to get <h1> from browser.contents in a test?
<deryck> bdmurray, it's just beautiful soup underneath, so can't you do browser.contents.h1 or browser.h1 to get the first h1?
<bdmurray> deryck: that didn' work out so well
<deryck> bdmurray, have you seen lib/canonical/launchpad/doc/pagetest-helpers.txt ?  Nothing on h1 specifically, but might help you think about how to get at the content you want.
<jml> findByTag('h1'), perhaps?
<deryck> bdmurray, also the README and REFERENCE in lib/canonical/launchpad/pagetests might help.
<bdmurray> deryck: thanks
<lifeless> moin
<mars> morning lifeless
<lifeless> hmm, no gary
<jml> lifeless: good morning.
<jml> lifeless: you're up bright and early
<lifeless> jml: daylight savings
<mars> lifeless, gary won't be back until Wednesday
<lifeless> mars: darn
<lifeless> I have this buildout problem ...
<jml> lifeless: oh. nice.
<mars> lifeless, what is the problem?
<mars> lifeless, I may be able to help, having set up buildout for a project or two recently
<lifeless> robertc@lpdev:~/zope.testing$ python ./bootstrap.py
<lifeless> After install bootstrap.
<lifeless> Creating /usr/local/lib/python2.6/dist-packages/setuptools-0.6c11-py2.6.egg-info
<lifeless> error: /usr/local/lib/python2.6/dist-packages/setuptools-0.6c11-py2.6.egg-info: Permission denied
<lifeless> An error occurred when trying to install distribute 0.6.14. Look above this message for any errors that were output by easy_install.
<lifeless> While:
<lifeless>   Bootstrapping.
<lifeless>   Getting distribution for 'distribute'.
<lifeless> Error: Couldn't install: distribute 0.6.14
<mars> lifeless, weird.  What bootstrap are you using?  The one from the PyPi zc.buildout page/
<lifeless> mars: the one in the source tree
<mars> hmm, that should work
<lifeless> mars: bzr branch lp:zope.testing; python ./bootstrap.py
<lifeless> mars: see what happens?
<mars> ah
<mars> lifeless, ok.  That may be an old bootstrap.py
<mars> checking
<benji> lifeless: I /think/ this is cause by distribute trying to fake up a setuptools egg (part of the setuptools impersonation it does); it's somewhat icky, but you should be able to fix it by running your bootstrap as root one time
<mars> :(
<lifeless> benji: hell no
<benji> heh
<mars> benji, maybe just 'sudo aptitude install python-distribute'?
<lifeless> benji: if it wants to write to /usr/* it die a fiery death.
<benji> mars: don't know; maybe
<mars> lifeless, yes, it should not be trying that
<lifeless> statik: hi; I think google calendar forgot that you're on the other side of the world: its moved the appointment to be the same NZT rather than UTC
<lifeless> statik: but, as it got me up for it, want to me now, or in an hour ?
<mars> "Copyright (c) 2006 Zope Foundation and Contributors." - yeah, that's an old one
<mars> 2006 for bootstrap.py in zope.testing
<lifeless> mars: this is in my lp vm - a lucid one; distribute isn't packaged there.
<lifeless> mars: so, how does one fix this?
<james_w> setuptools in lucid /is/ distribute isn't it?
<lifeless> james_w: in maverick maybe
<lifeless> python-setuptools                                     0.6.10-4ubuntu1launchpad1                             Python Distutils Enhancements (setuptools compatibility)
<mars> mine died on 'fetching distriubte', trying 'python bootstrap.py -vvvv'
<mars> it worked that time?
<lifeless> no, thats dpkg -l python-setuptools
<mars> lifeless, what happens when you run "python bootstrap.py -vvvv" ?
<lifeless> so, copying the lp bootstrap into the tree worked
<mars> running it again after it faults should not make it run.  That is some weird bug.
<james_w> lifeless: http://packages.ubuntu.com/source/lucid/distribute
<lifeless> mars: it didn't work at all
<lifeless> mars: however many times it was tried; copying the lp bootstrap.py into the tree made it work.
<lifeless> james_w: thanks
<lifeless> grah
<lifeless> bin/test
<lifeless> Traceback (most recent call last):
<lifeless>   File "bin/test", line 17, in <module>
<lifeless>     import zope.testing.testrunner
<lifeless> ImportError: No module named testrunner
<lifeless> (this is zope.testing :/)
<mars> lifeless, yep, they split
<mars> lifeless, did you run bin/buildout?
<mars> lifeless, I'm checking buildout.cfg in the zope.testing source tree - it knows about zc.recipe.testrunner, so it should work correctly
<mars> look at the built parts in that file
<mars> bin/test is broken for me too
<lifeless> mars: yes, I ran bin/buildout
<lifeless> mars: you're serious? zope.testing.testrunner is not in the zope.testing package?
<mars> lifeless, yes, they split: zope.testing.testrunner became its own package, IIRC.  Jim Fulton coded it himself?
<lifeless> I hope I won't seem shallow when I say that this is madness: I just want to fix layers for lp
<jml> z.testrunner 4.0
<mars> heh
<jml> lifeless: the recent move has slowed me down from contributing upstream to z.testrunner
<lifeless> perhaps we should just stop using it
<jml> you won't see me arguing
<lifeless> jml: I was going to run the test suite, so that the subunit fixing patch could be applied
<mars> lifeless, funny - zope.testing's setup.py does not reference zope.testrunner, and neither does the buildout.cfg
<mars> I guess someone forgot to add the dependency
<lifeless> I wonder how much money I could make, taking bets on how many years before this is packaged properly in Ubuntu
<mars> lifeless, add 'zope.testrunner' to the list of files in buildout.cfg [versions], then add 'zope.testrunner' to the [test] part eggs= list
<lifeless> mars: zope.testrunner is what I need to be working on I suspect, or both at once.
<lifeless> mars: how does one tell buildout to do that ?
<mars> lifeless, hack buildout.cfg
<mars> here, just a sec
* lifeless changed the topic of #launchpad-dev to: Launchpad Development Channel | Performance Tuesday ! | Week 2 of 10.10 | PQM is open for business | firefighting: - | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<benji> it appears that the comment in zope.testing's [versions] section applies; someone forgot to remove that version pin; if I remove it and rebuild the tests run and pass
<mars> lifeless, ^
<lifeless> benji: thats in buildout.cfg?
<mars> benji, cool.  I think sidnei has commit rights?  For all I know you do too :)
<lifeless> wow,
<lifeless>   Ran 30 tests with 0 failures and 0 errors in 18.258 seconds.
<benji> lifeless: yes
<benji> mars: I do.
<lifeless> I'm impressed at 0.5 sec each for a lightweight project :><
<lifeless> so, I presume these projects needs to be changed in lockstep; whats the blessed way to do that?
<lifeless> If it was deb based I'd just set PYTHONPATH and be done with it.
<benji> lifeless: >= version requirements in setup.py should be enough
<lifeless> benji: I'm not sure that I' asking the correct question.
<lifeless> benji: I need to edit code in *both* packages.
<lifeless> benji: and run one against the edited other. Not against pypi versions.
<lifeless> benji: how would you do this?
<james_w> lifeless: develop = . ../other-project
<lifeless> james_w: in?
<james_w> the one that imports the other
<james_w> buildout.cfg in the main section
<lifeless> james_w: they import each other
<james_w> then in both?
<lifeless> ok
<james_w> it basically puts ../other-project on PYTHONPATH when you run ./bin/ in the branch you put that setting in
<james_w> with extra magic of cours
<benji> lifeless: ah, I was talking about making the releases; you can use "develop = /path/to/the/other/thing" in the [buildout] section of each check out to make them see each other (possibly with changes to each [versions] section as well)
<lifeless> is there a way to do that without editing a version controlled file?
<lifeless> it will be frustrating to have an unclean tree all the time
<benji> lifeless: you can use a different config (other than buildout.cfg) and run buildout with -c /my/hacked/up/config.cfg
<lifeless> benji: does that have to be a full copy?
<james_w> bug 13002
<_mup_> Bug #13002: Toshiba battery events flood <acpi-support (Ubuntu):Fix Released by thombot> <https://launchpad.net/bugs/13002>
<lifeless> theres no way to just override develop= ? e.g. via .buildout.cfg or something ?
<james_w> err bug 613002
<_mup_> Bug #613002: Please add a way to optionally extend <Buildout:New> <https://launchpad.net/bugs/613002>
<jml> g'night all.
<lifeless> night jml
<james_w> lifeless: extends =, but you it's editing a version controlled file and you can't commit it
<benji> lifeless: or you can give buildout the info on the command line, something like bin/buildout buildout:develop=...
<benji> lifeless: yep
<benji> (full copy)
<rockstar> benji, do you know much about buildout? (I'd ask gary, but he's not around)
<benji> rockstar: a bit; what's up?
<rockstar> benji, a voice call would be great, if you can spare it.
<benji> rockstar: sure; it'll be a few minutes though.  Do you want me to ping you when I'm available?
<rockstar> benji, that would be great.
<benji> k
<lifeless> benji: hi
<lifeless> https://code.edge.launchpad.net/~lifeless/zope.testing/subunit/+merge/26638
<lifeless> benji: this is going to remain broken forever I think
<lifeless> benji: it took me 8 weeks to figure out how to run the test suite; I humbly suggest that practicality should win here.
<salgado> Edwin-afk, we seem to have some spurious TeamParticipation entries which might be caused by those changes you did to the code which maintains that table: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/597208 (last comment is the relevant one)
<_mup_> Bug #597208: Run cronscripts/check-teamparticipation.py on production and make its output more visible <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/597208>
<benji> lifeless: I should be able to take a look in a few hours
<malaria> jtv: danilos wanted me to pop here about this bug: https://bugs.launchpad.net/rosetta/+bug/608631
<_mup_> Bug #608631: Visual tag to represent narrow non-breaking spaces <diacritic:Invalid> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/608631>
<malaria> (anyway, hi everyone)
<lifeless> malaria: jtv will be around in about 7-8 hours
<malaria> lifeless: ok, it's the same every day?
<lifeless> I don't know what you're asking
<lifeless> he sleeps like everyone else ;)
<malaria> lifeless: of, course, I mean it's because of it's timezone
<lifeless> yes
<malaria> so I have to schedule the best moment to go back here
<benji> rockstar: skype?
<benji> or mumble
<benji> or smoke signals
<rockstar> benji, whoa, the people I needed both responded at the same time.
<benji> heh
<rockstar> benji, let me chat with sidnei first.  It's possible I may not even need to bug you.
<benji> k
<rockstar> benji, okay, I do think I want to chat with you.
<rockstar> benji, what's your skype name?
<benji> rockstar: benji_york
<flacoste> lifeless: morning
<lifeless> hi flacoste
<lifeless> are you back ?
<lifeless> flacoste: I was just running out the door for a short errand
<flacoste> lifeless: i am!
<lifeless> but would love to catch up after that, if thats ok ?
<flacoste> lifeless: that was my goal, when will you be back?
<lifeless> < 20 min
<flacoste> ok
<thumper> rockstar: please check QA on kanban
<rockstar> thumper, ah!
<lifeless> flacoste: ok
<rockstar> thumper, hm, qa on one of my items is bad (it doesn't fix the bug it's supposed to, nfi).  Where should that card go?
<thumper> rockstar: it stays in the qa lane and you fix it :)
<rockstar> thumper, okay.
<wallyworld> morning
<flacoste> lifeless: https://chinstrap.canonical.com/~stub/splitit/
<Ursinha> lifeless, hello
<rockstar> "Get up, stand up. Stand up for your right"
<Ursinha> haha
<Ursinha> lifeless, I believe r11579 landed the other half's fix of bug 506256, but the landing has no qa tags, so the bad-commit tag is still there
<_mup_> Bug #506256: Remove Popen from buildstatus_OK <bad-commit-11566> <buildfarm> <qa-needstesting> <Soyuz:Fix Committed by jelmer> <https://launchpad.net/bugs/506256>
<Ursinha> and it's blocking further revisions
<lifeless> Ursinha: hi
<lifeless> bigjools was going to cp both revs
<lifeless> I don't think he has yet, lets check prod-stable
<Ursinha> lifeless, so I guess we could unblock other bugs by marking this one as qa-ok?
<Ursinha> assuming both parts have already been QAed, of course :)
<lifeless> flacoste: https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt
<Ursinha> lifeless, flacoste, prettier: https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html :)
<lifeless> Ursinha: so, prod stable does not have both fixes
<lifeless> Ursinha: and we have to deploy both - see the bad-commit-xxxx tag
<Ursinha> lifeless, I know... let me try again
<Ursinha> lifeless, are both on edge and QAed?
<lifeless> looking
<Ursinha> lifeless, that's what matters so we can unblock the bug, right?
<lifeless> this is the fixes=12345 stuff I was mentioning - same as rollback but rollforward
<Ursinha> I know
<lifeless> :P
<Ursinha> that needs to be discussed and implemented
<Ursinha> I mean something else
<lifeless> I'll be back in a minute, real-life interrupt
<Ursinha> sure
<lifeless> sorry, back
<lifeless> wgrant: around perchance?
<lifeless> Ursinha: https://bugs.edge.launchpad.net/soyuz/+bug/128259
<_mup_> Bug #128259: Buildmaster should not call "uploader" script for processing incoming binaries <buildd-manager> <qa-needstesting> <soyuz-build> <Soyuz:Fix Committed by jelmer> <https://launchpad.net/bugs/128259>
<lifeless> qa-needstesting
<Ursinha> lifeless, hmm, what's your point? :)
<lifeless> Ursinha: you were asking if the second half fixed it - its unknown ?
<Ursinha> lifeless, I'm asking what's about that bug
<lifeless> Ursinha: that bug is attached to the commit that is the other half of 11566
<Ursinha> I thought the other half of that bug was something related to that bug, just another branch ref. the same bug #
<Ursinha> but now I see
<lifeless> Ursinha: yeah; the other half references two bugs.
<wgrant> lifeless: Hi.
<lifeless> hi
<lifeless> wgrant: wondering if you have an opinion on the qa-ness of bug 128259
<_mup_> Bug #128259: Buildmaster should not call "uploader" script for processing incoming binaries <buildd-manager> <qa-needstesting> <soyuz-build> <Soyuz:Fix Committed by jelmer> <https://launchpad.net/bugs/128259>
<lifeless> see backscroll
<wgrant> I haven't heard.
<wgrant> StevenK might know.
<lifeless> also, killing pids that happen to be in a file that was stale weeks ago is really pretty nasty.
<wgrant> But deploying that without thorough, thorough QA would be a seriously terrible idea.
<lifeless> This layer stuff really concerns me :)
<wgrant> Hm?
<wgrant> Ah.
<wgrant> Right.
<wgrant> Are those revs in prod-stable yet?
<wgrant> bigjools might have already CP'd them.
#launchpad-dev 2010-09-28
<lifeless> wgrant: no, they aren't.
<lifeless> he was going to.
 * wgrant blames email.
<thumper> wgrant, StevenK: ping
<lifeless> flacoste: when you get up
<lifeless> https://chinstrap.canonical.com/~stub/splitit/4vs5/diff_shipit-20090810T_212109_vs_204654/
<thumper> do either of you know where build queue entries are kept?
<wgrant> BuildQueue, you mean?
<lifeless> flacoste: the request response time degrades terribly as load goes on in that benchmark - we'd want it to stay flat
<thumper> wgrant: perhaps
<lifeless> flacoste: according to that , we'd be able to run at 30-40 concurrent users max on that config
<wgrant> thumper: What are you looking to do, exactly?
<thumper> wgrant: I'm chasing down some weird old buildfarmjobs
<thumper> wgrant: there are some entries there that aren't being dispatched
<thumper> wgrant: and I'm wondering why
<wgrant> thumper: These aren't the same ones that don't have a specific_job?
<thumper> wgrant: there are 15 old recipe buildfarmjob rows, 12 of those don't have a sourcepackagerecipebuild, 3 do
<thumper> I'm wondering what happened to those 3
<wgrant> thumper: SourcePackageRecipeBuildJob links SPRBs to Jobs. BuildQueue.job then references that Job.
<wgrant> So there are three rows that you need to look for for each of those three builds.
<thumper> so to go from the buildfarmjob to the buildqueue you need to go through 5 tables?
<thumper> that sounds freaking insane
<wgrant> The links that I just referenced are all scheduled for demolition.
<wgrant> BuildFarmJob is going to replace all of them.
<thumper> wgrant: so BuildFarmJob is the new goodness?
<wgrant> thumper: That's right.
<thumper> wgrant: and sourcepackagerecipebuild is staying?
<wgrant> Now Translations is on it, I just need to find a free weekend and delete the rest.
<wgrant> Right.
<wgrant> SourcePackageRecipeBuild*Job* is dying.
<thumper> ok
<thumper> but builds are being dispatched through the buildjob right now?
<wgrant> Yes.
<thumper> but not for much longer?
<wgrant> Correct. Soon only BuildFarmJob, PackageBuild and SourcePackageRecipeBuild will be involved.
<thumper> ok
<wgrant> The BuildQueue and SourcePackageRecipeBuildJob tables will vanish, and everyone will be a lot less confused.
<thumper> and no links to the Job table at all?
<wgrant> Once we have everything sitting well-abstracted on top of it, BuildFarmJob will probably migrate to storing most of its data in a Job.
<thumper> cool
<wgrant> But that's not a significant change, so hasn't been thought about too much yet.
<thumper> thanks for the help
<wgrant> I decided that having BFJ store things in a Job from a start would be even more confusing: it would mean having two Jobs for every build farm task during the migration period.
<thumper> so...
<thumper> these other three rows have no sourcepackagerecipebuildjob links
<wgrant> You're not checking on staging, are you?
<thumper> hence not being built?
<thumper> I am right now
<thumper> but I can fling the query at spm
<wgrant> The staging restore dequeues builds. I don't know if it deletes SPRBJs too.
<wgrant> But it definitely deletes the BuildQueues.
<poolie> so generally speaking i feel i should add fixtures rather than add to the LaunchpadObjectFactory
<poolie> is that true?
<thumper> poolie: who said what about the factory?
<thumper> poolie: can you give me an example?
<poolie> sorry, my recollection of it is vague
<poolie> i thought that abentley said it was quasi-deprecated?
<poolie> or not a good pattern?
<wgrant> Sampledata is deprecated.
<poolie> the example is if i want a thing to establish feature rules for testing
<wgrant> The factory is very much not.
<thumper> wgrant: in the end, the BuildQueue rows are missing for the respective jobs
<wgrant> thumper: Do they have SPRBJs?
<thumper> wgrant: yes
<thumper> wgrant: and Jobs
<wgrant> thumper: There's nothing special about the three?
<thumper> wgrant: not that I can fathom without actually looking :)
<thumper> wgrant: they are from july
<wgrant> It could just be a botched deletion, I suppose.
<thumper> yeah, I suppose
<wgrant> If it hasn't happened in three months...
<james_w> are daily recipe build jobs being created?
<poolie> https://bugs.edge.launchpad.net/launchpad/+bug/649500 is amusing
<wgrant> I think I saw a bug about that a while ago.
<wgrant> The issue has certainly been present forever.
<poolie> can i have just features/browser.py, or should it be a submodule?
<poolie> ah i see there are some precedents for a plain file
<wgrant> Bug #640435
<_mup_> Bug #640435: branch name conflicts with zope.ManageContent <oops> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/640435>
 * mwhudson wtfs at poolie's bug
<poolie> i guess it's inherited from some builtin zope thing
<poolie> is it a cms or a framework? who can tell
<mwhudson> ah yeah
<wgrant> Well, the ZTK was meant to fix that duality.
<wgrant> I think it has.
<mwhudson> j'accuse zope.app.publisher
<poolie> yep
<wgrant> Er.
<wgrant> Why do we use that?
<rockstar> \o/
 * rockstar conquers buildout
<poolie> specifically BrowserSkinsVocabulary
<wgrant> I would have thought all our needs would be in zope.publisher.
<poolie> it doesn't seem to add anything we do want
<wgrant> lib/canonical/launchpad/doc/zcmldirectives.txt:#        <class 'zope.app.publisher.browser.viewmeta.SimpleLaunchpadViewClass'>,
<wgrant> WTF?
<wgrant> I get the feeling that I don't want to look at that file.
<mwhudson> well hehy, if we can fix a bug by dropping a dependency
<wgrant> We still import a whole lot of stuff from it.
<wgrant> But I'm fairly sure it was all moved to other packages ages ago.
<wgrant> Oh look, zope.app.publisher imports them from zope.browserpage.
<mwhudson> wgrant: certainly looks like it
<wgrant> Hm.
<wgrant> But we still need it for XML-RPC :(
<mwhudson> it's probably not very hard to write a zcml directive that unregisters the offending view
<wgrant> I'd personally prefer to see if we can stop needing IMethodPublisher, since that's our remaining dependency on zope.app.publisher. There must be a replacement...
<mwhudson> it
<mwhudson> seems pretty tiny
<wgrant> It really is.
<wgrant> Hm. Looks like z.a.p might provide the xmlrpc:view ZCML directive.
<wgrant> So it may be harder to excise.
<wgrant> Why is that in there, I wonder...
<wgrant> Ah, the ZTK steering committee appears to have just not yet decided where to put it.
<wgrant> Grar.
<wgrant> Hmm.
<wgrant> What happens if we just remove the zope.app.publisher ZCML inclusion?
<wgrant> And import just the zope.app.publisher.xmlrpc
 * wgrant tries.
<wgrant> That seems to have worked.
<mwhudson> i wonder if there's some way of finding all the places where we import from deprecated locations
<wgrant> Given the recent ZTK reshuffles, that's probably most of our imports...
<wgrant> All the xmlrpc tests are happy with my fix, and the webapp seems to work.
<wgrant> I'm not sure how, though.
<wgrant> Something else must be pulling in the zope.browserpage and co.
<thumper> lifeless: got any ideas about https://bugs.edge.launchpad.net/launchpad-code/+bug/537116 ? I don't know where to start looking.
<_mup_> Bug #537116: bzr branch from launchpad disconnected after exactly one hour <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/537116>
* thumper changed the topic of #launchpad-dev to: Launchpad Development Channel | Performance Tuesday ! | Week 3 of 10.10 | PQM is open for business | firefighting: - | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<lifeless> thumper: his firewall perhaps ?
 * lifeless shoots first, asks questions later
<lifeless> we could try and reproduce
<lifeless> I suspect something at his end though, because e.g. pulls of LP can be an hour and work
<poolie> there's no timeout on our end?
<poolie> it's plausible it's his firewall
<poolie> a bit strange if it kills an actually active socket though
<lifeless> spm: do we have anything that would kill a bzr serve process / ssh connection after 1 hour ?
<spm> I can think of several possibilities, but don't *know* which is likely.
<spm> i'd be asking for a snoop that shows the termination. that may be a clue.
<mwhudson> we have code in launchpad that's supposed to kill _idle_ connections after an houe
<mwhudson> *hour
<poolie> as far as whether it's killed by a reset or socket close
<poolie> mwhudson: where is that code?
<mwhudson> poolie: not sure now since jml shuffled this area
 * mwhudson pokes
<poolie> if it was an econnreset it would be more likely to be a router intervention, i think
<poolie> but it's just an early eof, which could be anything
<poolie> perhaps is slightly more likely to be app code than networking
<mwhudson> poolie: lp.services.sshserver.service
<mwhudson> poolie: line 150-ish
<mwhudson> oh right
<mwhudson> well he's definitely being cut off by the idle_timeout
<mwhudson> but what's happening is that the branching runs for an hour
<spm> <mwhudson> poolie: line 150-ish <== was that from memory? or did you look it up? ;-)
<mwhudson> then the connection goes idle
<mwhudson> then an hour after that he's disconnected
<mwhudson> spm: i looked it up :-)
<spm> :-)
<mwhudson> poolie: there is also a bug in conch's ssh key renegotiation
<mwhudson> that usually kicks in after a gigabyte of traffic
<mwhudson> he doesn't seem to be close to that though
<poolie> aside from anything else we should upgrade the origin branch
<poolie> well, it would be an incredible coincidence for that to happen after an hour
<poolie> but perhaps there's a time-based renegotiation too?
<poolie> do you have a bug number for that?
<spm> it wouldn't be some reverse speed of light problem maybe? http://www.ibiblio.org/harris/500milemail.html
<mwhudson> poolie: yes, but i can't find it
<thumper> poolie: I'm contacting the project owner
<thumper> web2py owner that is
<poolie> spm if we have users more than one light-hour away, uh..
<poolie> i'll be impressed
<spm> you never know......
<poolie> about 1e9 km
<lifeless> tcp over spaceship would be painful
<lifeless> talk about slow start
<spm> lifeless: you've not seen that rfc? it's an update on 1149
<lifeless> carrier pigeon?
<mwhudson> http://twitter.com/#!/colmmacuait/status/25352220323
<poolie> nice
<spm> lifeless: indeed
<spm> bwhahaha
<poolie> so in a bit of poking around i can't see anything in conch to do with automatically renegotiating keys, based on either traffic or time
<poolie> it may well be there but i don't see it
<mwhudson> poolie: it's client side
<nigelb> spm: heh, that was a good one about 500 miles
<spm> nigelb: *very* old favourite. The Story Of Mel, is another
<nigelb> spm: Story of Mel?
<spm> http://www.pbm.com/~lindahl/mel.html
<poolie> mwhudson: and not implemented by conch as a client?
<mwhudson> poolie: probably not
<poolie> mwhudson: but ok, i can see how openssh might ask  for a new key after a few gb and then that could cause trouble with the server
<poolie> but that's almost certainly not what we're seeing here
<mwhudson> this is infuriating, i spent quite a while looking at this and writing it up and now i can't find it
<mwhudson> poolie: right
<poolie> mwhudson: i'm trying to branch from there
<mwhudson> poolie: i think openssh's default is 1 gig
<mwhudson> you can change it
<poolie> my connection is faster so it may just complete
<poolie> says "depending on the cypher 1-4GB"
<poolie> spm I watched "Colossus: The Forbin Project" last night
<poolie> had to bite my tongue a lot
<poolie> "ffs it never works first time"
<spm> poolie: I've never heard of that one! I shall have to chase!
<poolie> visually beautiful
<stub> lifeless: https://bugs.launchpad.net/bugs/637507 if you haven't seen it. I don't understand the low level stuff or the risks, but sounds like something we might want to do across the board.
<_mup_> Bug #637507: Uploads with extra data in the .tar.gz rejected unnecessarily <boobytrap> <soyuz-upload> <Soyuz:Triaged by jelmer> <https://launchpad.net/bugs/637507>
<lifeless> stub: hey
<lifeless> stub: see the cassandra mail?
<lifeless> stub: sigpipe handling; yes, it should really be reset by subprocess automatically.
<stub> lifeless: yes, and pfibiger pinged me this morning.
<lifeless> stub: a wrapper for it would be useful
<stub> lifeless: I have to think about the timing for the cassandra - my lease on a new house starts the same day.
<lifeless> meep
<stub> lifeless: knowing the location would be helpful - short haul might be ok
<lifeless> us I believe
<stub> lifeless: I was told 'up to mariana'
<lifeless> ah, interesting
<stub> u1 is us centric though, so probably dullas again
<lifeless> would taipei count as short haul ?
<stub> yes
<stub> I suggested Taipei. 'We should all get to Taipei' I recall from a keynote.
<stub> Only problem with Taipei is I would want to take a holiday there and I can't ;)
<lifeless> heh
<wgrant> Why is Dallas so popular?
<lifeless> cheap, reasonably central
<lifeless> (I guess, I have no knowledge)
<lifeless> wgrant: hey, do you happen to know the name of the signal raised in +filebug w/apport ?
<wgrant> lifeless: Signal?
<lifeless> event
<lifeless> thingy dookhicky
<wgrant> lifeless: To do what?
<wgrant> I don't know of a special event.
<adeuring> good morning
<michaelh1> Hi there.  I've started getting 'Errors in work item definitions' from 'Launchpad work item tracker <noreply@launchpad.net>'
<michaelh1> emails.  How can I stop them?
<lifeless> michaelh1: thats not an lp service, for all that its using the launchpad.net domain
<lifeless> last i heard Martin Pitt was running it
<lifeless> bigjools: hi; CPing your thing ?
<lifeless> [thats code for 'had a good weekend?']
<michaelh1> Right, I'll track pitti down...
<bigjools> moin
<lifeless> wgrant: this is what I was meaning
<lifeless> http://pastebin.com/SHStVhUv
<lifeless> though, that may not be enough
<lifeless> I think I need to get a profile
<lifeless> (can apport be pointed at staging?)
<poolie> do i need an __all__ even in tests?
<StevenK> poolie: Only if they export something
<poolie> thanks
<mrevell> Mornin'
<poolie> hi there
<wgrant> lifeless: APPORT_STAGING=1 ubuntu-bug linux
<wgrant> IIRC
<lifeless> the main reason we need __all__ is the import fascist requires that imports be in it
<lifeless> this is a bit silly
<lifeless> because you can do module._thing
<poolie> you mean it doesn't really guard against using private interfaces?
<lifeless> right
<lifeless> it doesn't seem to have any functional benefit
<wgrant> I think it's a handy check.
<wgrant> If it works.
<wgrant> But I don't think it does.
<wgrant> it hasn't whinged at me much lately.
<wgrant> Not being very fascist at all.
<lifeless> I question the value now that security is on the model
<lifeless> s/ now/ particularly now/
<wgrant> It makes some attempts at preserving layering.
<poolie> assuming people actually respond by changing the layering, not just updating the paperwork
<lifeless> wgrant: with the assumption that the layering is useful; the primary differences between view and model code are:
<lifeless>  - some model code is db backed
<lifeless>  - model code wasn't allowed to cache for a while
<lifeless>  - model classes get interfaces (high overhead) and security (useful where it matters)
<poolie> re bug 646563, is it really true that login(something); getUserBrowser() doesn't give you a browser as that user?
<_mup_> Bug #646563: want a way to make a TestBrowser logged in as a particular user <testing> <Launchpad Foundations:New> <https://launchpad.net/bugs/646563>
<lifeless> the first item is a performance problem, the second isn't relevant anymore and the third adds a good 15+ percent to the code base, but *mostly* is just boilerplate.
<jml> let's not forget that the import fascist also prevents us from using storm sorting in view code
<lifeless> jml: yes, an import 'benefit', that one.
<lifeless> jml: if you wanted to remove it, I'd be fine with that.
<jml> lifeless: landscape has an importguardian that's, well, better
<lifeless> jml: I remain fundamentally unconvinced that this is appropriate for python, at all.
<jml> lifeless: last time I tried this, I went to split that out into lazr.importguardian, but got blocked on new lazr packages being very hard to make
<lifeless> poolie: yes, its true.
<lifeless> jml: why shouldn't we just remove it?
<wgrant> What does the guardian do?
<jml> lifeless: don't know, basically
<jml> wgrant: I can't remember the details beyond "like the fascist, but nicer; let's you import for sorting"
<wgrant> Why were they both created in the first place?
<jml> ahh, now _that_ is a historical question
<jml> so the answer is clearly "for historical reasons"
<wgrant> Heh.
<poolie> i have code to add getUserBrowserAsTeamMember in https://code.edge.launchpad.net/~mbp/launchpad/flags-gui/+merge/36415
<poolie> i might just move that to BrowserTestCase as part of this same mp?
<wgrant> poolie: Is that really worth its own method?
<jml> I suspect it was to stop programmers from doing bad things like circumventing the interface/security code
<poolie> wgrant: how would you write a test that needs a logged in user?
<wgrant> (as opposed to getUserBrowser(getTeamMember(blah)))
<lifeless> frankly, that sort of thing, unless there is a really big win, just annoys me
<lifeless> poolie:
<poolie> wgrant: that doesn't seem to work
<jml> lifeless: well, yes :)
<lifeless> user = self.factory.makePerson(password='test')
<lifeless> browser = self.getUserBrowser(user=user)
<poolie> right, then add them to those teams
<poolie> it's only 5 lines but assuming it doesn't exist already, it seems reusable
<lifeless> I think its a bit of a kludge
<lifeless> how about this
<lifeless> getUserBrowser(user=user) resets the users password if its wrong
<lifeless> or
<lifeless> how about we make the default password in makePerson be 'test'
<lifeless> uhm
<lifeless> I'm not against a convenience helper gluing stuff together
<jml> anyway, I must ablute. back later.
<poolie> mm, or i could add a teams=None parameter to getUserBrowser
<lifeless> I think I'm mainly reacting to the fact that one is needed here.
<lifeless> poolie: I don't understand why team membership and browser instance creation are coupled.
<lifeless> they seem like vastly different concerns.
<lifeless> if you did this:
<poolie> getUserBrowser creates a new person
<lifeless>  - change makePerson to use 'test' as the default password
<lifeless> then you can do the following:
<lifeless> then gUB will 'just work'
<lifeless> and if you want a team relationship you can make that and pass in a user (and again it will just work)
<poolie> i'm reluctant to change something called by so many tests as makePerson
<lifeless> and yet that is what makes it valuable to change
<lifeless> losa ping; I'd like to request profiling on staging please
<mthaddon> lifeless: is it urgent - working on something just at the moment
<lifeless> mthaddon: I can't claim urgent, but its 2130 for me, if I can get this before I head to sleep I may be able to confirm/deny a theory for the +filebug timeouts.
<lifeless> and kick it over to deryck for further examination
<mthaddon> can you file an RT and I'll get to it a little bit later on (if you can include the info that's needed to hand over to deryck)?
<poolie> another option would be to stash the unhashed password on the object
<lifeless> mthaddon: no, the info is me analysing kcachegrind
<lifeless> mthaddon: which is what the profile would give me; if you get a timeslice ping me
<lifeless> mthaddon: if you don't ping, thats fine, I'll do with someone tomorrow morning.
<mthaddon> lifeless: k, will do - how long of a timeslice would you need?
<wgrant> lifeless: Do we not have a URL trigger for that yet?
<lifeless> mthaddon: you edit one config file and restart the appserver; I go play until I have the data; then you revert the config file and restart, and trigger your rsync that copies the profile files to sodium.
<lifeless> wgrant: we do, but because its not secured it requires a config change to enable it.
<wgrant> lifeless: ... ah. Useful.
<lifeless> wgrant: next step is a featureflag to enable it, and a group scoped to 'launchpad'
<lifeless> sorry, a scope, which looks up the ~launchpad group.
<lifeless> mthaddon: http://pastebin.com/yTp0TL1D is the change; I'm sure this is in LOSA docs already
<mthaddon> lifeless: diff applied and staging restarted
<lifeless> thank you
<lifeless> mthaddon: thanks; revert it anytime you like; and please kick off the rsync of the profiles (AFAIK its not cronned; maybe it is but just very infrequent)
<lifeless> mthaddon: no rush
<poolie> lifeless: realize it's dead late but if you sometime want to do a meta-review on https://code.edge.launchpad.net/~mbp/launchpad/flags-gui/+merge/36415
<poolie> that could be good
<poolie> especially as to whether the ui is adequate to start with
<poolie> we could do that thursday
<lifeless> poolie: it sounds fine to me
<poolie> mthaddon: when things are not on fire, perhaps you would like to comment on the devops-usability of that mp
<poolie> s//of the feature proposed in that mp
<poolie> thansk
<poolie> i'm a bit impatient to get it done
<lifeless> poolie: its better than sql, so I'd just land it
<poolie> yeah :)
<poolie> i appreciate the reviews though
<lifeless> bigjools: so, are you going to CP 11566 and 11579 (IIRC) today?
<bigjools> lifeless: jelmer is preparing a CP, yes
<bigjools> not sure of the revnos
<lifeless> great
<lifeless> we noted that one of the bugs is not qa'd
<bigjools> which?
<lifeless> bug 128259
<_mup_> Bug #128259: Buildmaster should not call "uploader" script for processing incoming binaries <buildd-manager> <qa-needstesting> <soyuz-build> <Soyuz:Fix Committed by jelmer> <https://launchpad.net/bugs/128259>
 * bigjools f ixes that
<bigjools> pylint blows
<jml> yes
 * bigjools considers fixing the lint make target
<jml> if I cared a little bit more, I'd write a Python formatting checker/fixer that was as fast as pyflakes
<bigjools> it really hates our new import style
<jml> and then nuke pylint with great nuking
<bigjools> we should just get rid of pylint
<bigjools> it's worse than useless
<jml> no arguments here.
<jml> the reason I want a formatting checker/fixer is I'm sick of thinking about formatting.
<jml> but that doesn't block removing pylint
 * bigjools blinks
<bigjools> urgh, a shell script
<jml> I'm closing my mail & IRC clients for a bit to get some work done. Call my phone if you need me.
<deryck> Morning, all.
<wgrant> bigjools: The publisher will no longer die if there's an unconfigured series, will it?
<bigjools> wgrant: no idea
<wgrant> Yeah, it looks like it was fixed a couple of months ago.
<wgrant> (#ubuntu-devel just mentioned that they couldn't target specs to natty yet)
<jelmer> wgrant: That was one of the booby trap issues I fixed last release IIRC
<jelmer> bug 55288
<_mup_> Bug #55288: publisher gets very unhappy about unknown distroreleases <boobytrap> <oops> <qa-ok> <soyuz-publisher> <Soyuz:Fix Released by jelmer> <https://launchpad.net/bugs/55288>
<bigjools> \o/
<wgrant> That's the one.
<wgrant> Also, I hate ISPs.
<wgrant> My international routing has just collapsed for the fourth time this evening.
<wgrant> 70% packet loss FTW.
<stub> gmb: https://code.edge.launchpad.net/~shttps://code.edge.launchpad.net/~stub/launchpad/trivial/+merge/36853
<gmb> stub: I'll take a look now, thanks.
<gmb> stub: s/rouge/rogue in your commit message :)
<stub> blah. twiddled in the web.
<gmb> stub: r=me
<adeuring> Hi deryck, could you please run this query on staging: https://pastebin.canonical.com/37772/ (or an EXPLAIN ANALYZE)?
<deryck> Hi adeuring.  Sure.
<deryck> adeuring, so you want the explain analyze mostly?  Or just need the query run?
<adeuring> deryck: I think the EXPLAIN ANALYZE is more interesting :)
<deryck> ok
<bigjools> I am so utterly frustrated with the slow test suite
<deryck> adeuring, http://pastebin.ubuntu.com/502120/
<adeuring> deryck: thanks!
<deryck> bigjools, I feel you.  Combined with fails in ec2 and buildbot and it takes *for* *freakin* *ever* to land anything.
<adeuring> so, fast enough :)
<deryck> adeuring, well, for now.
<bigjools> deryck: stop feeling me :)
<deryck> heh
<bigjools> deryck: yeah, we have to do something.  I will bring it up in tomorrow's call.
<adeuring> deryck: yes, but the old query needed 177 seconds or so
<deryck> adeuring, ah, yes.  So that's much better.
<adeuring> erm, 17 seconds...
<deryck> bigjools, thanks for bringing it up.  I agree.  We can't keep putting it off.  Something has to be done.
<bigjools> quick someone, do Something!
<bigjools> deryck: I have an idea but we can discuss tomorrow
<deryck> excellent.
<jml> mrevell: https://bugs.launchpad.net/bugs/649764
<_mup_> Bug #649764: Getting started documentation is not very searchable <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/649764>
<bac> hi mars, did you ever get your clean install of maverick and did you see the authentication window when running windmill tests?
<mars> bac, I got my maverick install running, I have not tried the tests
<bac> mars: ok, i'm curious to see what you find when you run them.
<mars> is the Tomboy notes indicator applet messed up for anyone else?
<mars> it is showing a bunch of blank separator lines
<mars> maxb, can we call the new PPA "graveyard"? :)
<maxb> heh
<maxb> Is production still PostgreSQL 8.3 at this point?
<mars> I'll check
<cr3> leonardr: hi there, I'm getting "TypeError: Could not serialize object <object> to JSON", is there a practical way to debug that?
<mars> mthaddon, what version of Postgres are we running right now?  I can't dig up the wiki page for it :(
<mars> maxb, I'm +1 on the PPA idea, but I do not have the rights to create it
<maxb> No rush, we can wait for consensus and then get one of the (rather few) team admins to do it
<leonardr> cr3: is this when you invoke a named operation? if so, what does your python method return?
<bigjools> hmmm, when running the test suite locally, the windmill tests pop up a browser that seems to stall on some sort of auth dialog
<cr3> leonardr: this is in my own code, not launchpad, and yes, this is when I invoke a named method called createTestRun which returns an object which implements ITestRun
<mars> bigjools, yes, a known problem on Maverick
<bigjools> mars: ah ok
<mars> bigjools, I can look at it now that I am actually running said distro :)
<cr3> leonardr: aha, when calling simplejson.dumps(test_run, cls=ResourceJSONEncoder), I get: TypeError: can't compare offset-naive and offset-aware datetimes
<bigjools> it's amazing how much of our stuff breaks with each new Ubuntu release :(
<cr3> leonardr: I seem to be getting somewhere :)
<leonardr> cr3: good, that's what i was going to suggest
<leonardr> 'couldn't serialize' is masking some other error
<mars> bac, bigjools, bug 649886
<_mup_> Bug #649886: Windmill tests throw login window popups on Maverick <build-infrastructure> <Launchpad Foundations:New> <https://launchpad.net/bugs/649886>
<bigjools> mars: cool thanks
<bac> thanks mars
<mars> close to bug 650,000
<_mup_> Bug #650: broken package dependency's (i think :S still learning) <acroread (Ubuntu):Invalid> <https://launchpad.net/bugs/650>
<bigjools> lifeless: when you're awake, I'm interested to understand why you're importing stuff from the soyuz module into the bugs module in one of your changes.  It causes circular imports in the test runner unless it's invoked with -t
<cr3> leonardr: oddly, running simplejson.dumps(test_run, cls=ResourceJSONEncoder) the first time returns a typeerror but running the second time works fine :(
<leonardr> cr3, let me see your test code?
<leonardr> check to see if the dump process modifies any of the attributes of your object
<bigjools> deryck: hi, got a sec?
<deryck> bigjools, getting on call.
<bigjools> deryck: np, it can wait
<cr3> leonardr: argh, found the problem: setting a DateTime(allow_none=True) column to datetime.now(pytz.UTC) isn't the same as setting it to UTC_NOW :(
<leonardr> cr3: different things get set in the database?
<cr3> leonardr: not sure, let me have a look
<cr3> leonardr: looks like the same thing is landing in the database, the only perceptible difference is that the datetime object contains a timezone when set explicitly in now()  but not when retrieved from the database
<leonardr> cr3: is the object with the timezone being stored in memory and reused later? the problem is being caused by mixing them
<leonardr> or are you comparing the datetime object from the database to datetime.now?
<cr3> leonardr: I'm not sure where the datetimes are being compared, not in my code for sure. it seems to be either by storm or lazr
<deryck> bigjools, hi.  I can chat now if you still need.
<bigjools> deryck: I'm otp now :)
<deryck> heh
<deryck> ok, we'll try later then :-)
<leonardr> cr3: try stepping through simplejson.dumps()
<sinzui> ls
<sinzui> oops
<jpds> sinzui: No OOPS ID?
<sinzui> jpds, I was attempting to list a dir in my terminal, xchat had focus
<jpds> ;-)
<cr3> leonardr: turns out the problem goes deep into the zope browser absoluteurl routine, which calls upton the __name__ attribute of my object which returns self.name which probably triggers something in storm, like cash refresh or somesuch
<cr3> leonardr: in that particular context, just calling self.name causes the typeerror (I'm using storm from trunk)
<bigjools> deryck: ok I'm free now if you are
<deryck> heh
<deryck> bigjools, I'm about to jump on my standup
<bigjools> lol
<deryck> bigjools, I can do bottom of the hour, but then I have another call at the top of the next hour.
<bigjools> deryck: perhaps I can do it real quick on mumble right now?  it won't take long
<deryck> sure.
<bigjools> deryck: bin/test -vv test_deathrow
<mars> apport: "Your system encountered a serious kernel problem."  :(
 * bigjools is totally loving lp-open
<bigjools> bzr lp-open that is
<jml> \o/
<bigjools> although sometimes I hanker for an IDE
<mars> nice, I didn't know about that command
<mars> bigjools, here is what I am using: http://www.openkomodo.com/
<bigjools> interesting
<bigjools> can I keep my vim editor embedded? :)
<mars> hmm, it has a full vim emulation mode - embedding, I don't know about that
<bigjools> argh my eyes, TCL
<bigjools> well if it reads my current vim config...?
<bigjools> grrr fscking testfix mode
<jml> I'm off. See you all tomorrow.
<bigjools> nn jml
<EdwinGrubbs> sinzui: do you know why the error_dir is always set to none for new sections in schema-lazr.conf? It seems like that means every new section will require a change to the production config to set the error_dir. Otherwise, exceptions will be lost when it raises an exception that error_dir was not set.
<deryck> leonardr, ping
<sinzui> EdwinGrubbs, the ErrorLogger uses the default from its section, then updates the information is present in the section it is running all
<sinzui> EdwinGrubbs, also, lifeless refactored error reporting to use a separate logging service that manages the dir, so it is often inconsequential.
<leonardr> deryck,. hi
<deryck> hi leonardr.  I have an issue that I think involves the JavaScript API client, LP.client.
<deryck> leonardr, can I explain to you and get your feedback on it?
<deryck> I need help working out what's happening :-)
<leonardr> ok, sure, maybe mars can help if i can't
<deryck> ok
<mars> ?
<mars> deryck, this the firebug return values thing?
<deryck> mars, this is the comment posting issue I mentioned before.
<deryck> yes
<deryck> mars, leonardr, see bug 541993, especially my comment at comment #15.
<_mup_> Bug #541993: Adding comments to a bug shows [Object object] instead of comment <comment-handling> <javascript> <ui> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/541993>
<mars> deryck, I didn't ask before, but do you see the behaviour on launchpad.dev?
<deryck> yes
<mars> deryck, ok, have to go to lunch due to circumstances here, but some thoughts: it could be comment.js is listening for the wrong XHR events, and you are encountering race conditions as a result
<deryck> mars, ok, let's catch up more after your lunch.  I have to do a call shortly too.
<EdwinGrubbs> sinzui: ok, it looks like lp.services.job.runner.JobCronScript is doing something wrong by calling errorlog.globalErrorUtility.configure(self.config_name), since it blows up if error_dir is not specified in the config for the cronjob.
<sinzui> EdwinGrubbs, sounds like an undocumented requirement
<EdwinGrubbs> sinzui: hmmm, it seems like the JobCronScript should just have an if-statement that only runs configure if error_dir is not None for its specific section.
<sinzui> EdwinGrubbs, I think that is a sound suggestion if there is not a reason error_dir can be the default. I suppose a lot of use case for jobs describe non-webapp processes
<sinzui> EdwinGrubbs, if the process is considered to be the webapp, then I agree the default error_dir should be used
<cr3> is there something in launchpad, perhaps under lazrjs, to render a table from a restful call?
<mars> cr3, in soyuz for the PPAs, I think.
<cr3> mars: thanks for the lead, I'll look around there
<mars> cr3, lib/lp/soyuz/javascript/lp_dynamic_dom_updater.js /might/ have some useful code
<mars> cr3, line 86 has an example usage.  Search for the symbols in our .pt template files for real-world usage
<sinzui> flacoste, are we talking today?
<flacoste> sinzui: we should!
<flacoste> sinzui: mumble?
<mars> rockstar, ping, I am looking at deryck's problem with the bug comment async-post code, and wondering if your yui 3.2.1 branch may fix the issue.  Is that branch usable (or landed?)
<rockstar> mars, I'm working on it right now.
<rockstar> mars, I don't think a new yui is going to fix the issues though.
<sinzui> flacoste, mumble
<deryck> Hi mars.  When you said you thought we might be listening for the wrong XHR event.  Is there a way to globally log every event fired?  A flag to Y.Event or some such?
<mars> rockstar, ok, I am wondering if it is a race condition with XHR event handling - Y.io is one possible culprit
<bdmurray> sinzui: from your comments on my +subscriptions branch I get the impression that after clicking Continue on the +subscribe page the user should be returned back to +subscriptions is that right?
<rockstar> deryck, there is, but it gets noisy.  Set your log level to "debug"
<mars> deryck, yes, you can log everything.  Fire up launchpad.dev, it will be easiest that way
<rockstar> Er, filter.
<sinzui> bdmurray, yes
<rockstar> mars, I really suspect the problem to be in the lp.client
<bdmurray> sinzui: okay and that should be possible by setting next_url for the form?
<mars> rockstar, it could be there too, yes.  I am looking at the code, and it is a bit hairy
<sinzui> bdmurray, yes, or by using the redirect mixin
<rockstar> mars, yeah, I recall BjornT futzing with it a bit at the last lazr-js sprint.
<rockstar> mars, I'm currently in the process of getting all the python logic out of lazr-js and into a new library.
<sinzui> bdmurray, I think the mixin also provides a cancel link
<mars> rockstar, awesome :)
<bdmurray> sinzui: okay, thanks
<mars> deryck, ok, pointed question to diagnose this: what is the content-type header for the named operation, and it's HTTP status?
<mars> deryck, for the response
<mars> deryck, I am looking at line 186 of client.js, and how the callback argument changes type depending on the HTTP headers
<deryck> mars, text/plain;charset=utf-8 with an X-Content-Type-Warning that it was guessed.  And status is 201.
<mars> deryck, ok, and the following response?  201 is continue, so there should be a 200 right after it
<deryck> rockstar, so how do I sent my log level to debug for YUI?
<rockstar> deryck, in the YUI_CONFIG, set your filter: "debug"
<deryck> mars, 200 for application/json
<rockstar> deryck, that will get noisy as hell though.
<deryck> that's what I want. :-)
<rockstar> deryck, it's like a monkey paw though.  You'll get what you want, but at a cost you may not want to pay.
 * mars gestures towards the firebug console filter field
<rockstar> mars, yeah, but the sheer amount of events that fire just on the startup of the page is HUGE.  :)
<mars> deryck, you could always hack the page template to use the io-debug.js file directly.  As long as it appears after event.js then it will work as expected
<mars> as long as it appears after io-base.js <=
<deryck> ok, thanks.
<mars> argh, this code twists your brain.  There are a lot of callbacks in here
<mars> it's like reading a twisted mix of functional, procedural, and prolog
<deryck> yup
<deryck> mars, rockstar -- so nothing extra from this diff:  http://pastebin.ubuntu.com/502236/  What did I do wrong?
<mars> deryck, in the net tab, are you sure io-debug is in use?
<mars> second, client.js does not make use of the LPS config var
<mars> third, rockstar spoke of the YUI_CONFIG setting - that is new to me
<mars> well, new in that I have only heard passing mention of it
<deryck> I'm definitely using io-debug.js.  I see a get for:  https://bugs.launchpad.dev/+icing/rev11594/yui/io/io-debug.js
<deryck> But I think I need this filter in LP.client, as you note.
<deryck> hmmm, still no luck.  I'll wait on rockstar to see how I've misused this.
<mars> deryck, so I have a hack that may help narrow things down.  Try running your test with this patch: http://pastebin.ubuntu.com/502239/
<deryck> mars, are line 8 and 9 really different?
<mars> deryck, whitespace
<mars> editor did that
<deryck> ok
<deryck> mars, what should I be looking for here?  patch applied.  Same behavior by posting a comment.
<mars> deryck, ok, that is a nod towards the problem being in the result processing and not the event order
<deryck> ok
<deryck> mars, I don't think it's event order.  Unless it's something to do with the client patching on.success.
<mars> yep
<mars> but this rules that out
<sinzui> flacoste,  RT#41631
<_mup_> Bug #41631: deskbar didnt recognize short nautilus bookmarks <deskbar-applet:Fix Released> <deskbar-applet (Ubuntu):Fix Released by desktop-bugs> <https://launchpad.net/bugs/41631>
<lifeless> moin
<mars> morning lifeless
<achuni> morning lifeless
<mars> deryck, does this patch work? http://pastebin.ubuntu.com/502247/
<deryck> mars, trying now....
<mars> neat, YUI has touch gestures capability
<deryck> mars, doesn't fix the "object Object" dom update.  Does add more logging, obviously.
<mars> hehe
<mars> deryck, ok, was the log output useful?  Or was it just a bunch of "object Object" junk?
<deryck> mars, yeah, object object or object XMLHttpResponse stuff.
<achuni> hi! buildbot question... prod_lp threw a "substantiate failed" recently and the whole thing was restarted, but it hasn't picked up the branch I had landed since then.  Is it just a matter of waiting, or should I use the /force form?
<mars> deryck, ah, see, that is useful - you now know where it changed from the response to the wrapped value
<mars> achuni, if you landed it before the restart, then yes, someone needs to force the build
<achuni> mars: yup, in fact I was concerned the land was what caused it to fail, but lifeless pointed out "substantiate failed" wasn't due to the code itself
<mars> nope, that is the network reminding us it is still there laughing at us
<achuni> :)
<deryck> mars, copied from firebug output: http://pastebin.ubuntu.com/502252/
 * achuni tries a bit of force then
<mars> deryck, so it is this line: representation = Y.JSON.parse(response.responseText);
<achuni> mars: yay, substantiate success, building now. thanks!
<mars> achuni, np
<mars> deryck, what is the whole stack of code supposed to return?  A JS Resource object?
<lifeless> any soyuz folk still here ?
<deryck> mars, insert_comment_HTML expects a string as it's first argument, which should be the xhtml returned in the get response.
<mars> ok
<mars> deryck, uh, why is the content type application/json then?
<deryck> mars, not sure.  When I do this with my debugger statement in the middle method trick and wait a beat or two.... the final GET has a content type of application/xhtml+xml and there is no "representation" log line.
<mars> deryck, let me rephrase that: so the content type is application/json - are you getting back a JSON object holding XHTML as the response body, or XHTML as the response body?
<deryck> mars, see above from me
<mars> weird
<deryck> mars, maybe this will make it clearer:  http://pastebin.ubuntu.com/502262/
<deryck> mars, the middle method sets the accept parameter to get xhtml, but this only works with the debugger line set.
<mars> well, it beats jumping around the file like I've been doing :)
<mars> deryck, and the Accept header in the request is correct?
<mars> deryck, with and without the debugger line
 * deryck confirms or denies....
<deryck> mars, yes, accept header is right, with or without debugger statement.
<mars> k
<deryck> mars, I see no difference in the request headers (debugger or not).  The response headers are different.  With debugger there is a Keep-Alive and Connection header.
<mars> interesting
<lifeless> matsubara: tudo bem
<matsubara> lifeless, oi, tudo bem e contigo?
<lifeless> Hah, thats exhausted my pt - whats 'contigo'?
<lifeless> matsubara: you were working on feature flag controlled timeouts
<lifeless> matsubara: hows that going? do you need a hand?
<matsubara> lifeless, I'll get back to work on that this week. I put it on hold due to the sprint last week.
<matsubara> lifeless, "oi tudo bem e contigo?" means "hi, I'm fine, you?"
<lifeless> matsubara: no worries; I'll be in sydney tomorrow, so to be sure it gets in before we freeze, if its still pending tomorrow can you please push up your WIP and I'll tag-team with you on it
<lifeless> matsubara: thanks [language help :)]
<matsubara> lifeless, ok. I'll ping you tomorrow
<lifeless> matsubara: I'll be starting late because of the plane trip - about 9am sydney time - I wouldn't want to hold you back late @ work
<mars> deryck, that really sounds like a browser-based issue of some sort, either caching or... getting the wrong response for a request.
<mars> deryck, for the response with the incorrect information, is there a body?  What happens if you enable the "Show XMLHTTPRequest" in the Console options tab?
<deryck> mars, I have that enabled.  It gets the JSON representation of the comment in the wrong response (i.e. without debugger statement); otherwise, it gets the xhtml representation.
<mars> deryck, try shutting that feature off
<deryck> mars, that works now.
<mars> deryck, one of these then: http://code.google.com/p/fbug/issues/list?can=1&q=xhr+-lite+show+xmlhttprequests&sort=-id&colspec=ID+Type+Status+Owner+Test+Summary&cells=tiles
<deryck> mars, but I have the same issue on my phone, in a chrome based browser.
<mars> deryck, ok, so just to confirm: the bug appears when that Firebug console option is enabled, and the bug disappears when it is not enable?
<deryck> mars, indeed, that is correct.  And it appears consistently against staging on my phone, and I have no developer options for the browser to toggle on and off.
<deryck> mars, so I agree it seems Firebug is causing us to get the cached XHR.  Chrome on the phone must do the same.
<mars> .oO( whaaaa! )
<deryck> You're too l33t for me.... is that crying, wailing, or sudden inspiration?
<mars> the first two
<deryck> ok
<mars> I should have written 'whhaaaagggghhh!'
<mars> deryck, out of curiosity, what does your phone say about this page? http://www.mnot.net/javascript/xmlhttprequest/cache.html
 * deryck reaches for phone
<lifeless> achuni: hi
<lifeless> achuni: what rev of devel did you land your shipit sourcedeps.conf change on ?
<mars> deryck, what browser phone?
<mars> deryck, grammar fail
 * achuni checks
<mars> deryck, what version of the browser do you have on your phone?
<achuni> lifeless: 11642
<lifeless> achuni: cool, thanks.
<achuni> np
<lifeless> achuni: you may not be aware but we're overhauling our code->live story a lot at the moment.
<deryck> mars, cache control headers are all fail on the phone.
<lifeless> achuni: so I'm checking that my assumptions about our use cases are right.
<deryck> mars, it just says "Web version 7" nothing more specific.  It's chrome, obviously, since it's an android phone.
<achuni> lifeless: ah where should we get the updates about that from?
<mars> deryck, that page I gave you tells you the browser user agent up at the top of the page
<deryck> ah
<lifeless> achuni: the dev list
<mars> I have "Testing Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.63 Safari/534.3"
<mars> on the desktop
<deryck> mars, Version/4.0 Mobile Safari/530.17.
<achuni> k
<lifeless> achuni: changes that are deployed are in the wiki naturally (e.g. /LEP/ReleaseFeaturesWhenTheyAreDone lists its progress, and the private wiki pages will be changing soon, but they are active not planning/discussion)
<lifeless> jml: could you package up your difftodo plugin? or get someone in #bzr to do that?
<deryck> a ha.  Now I get why this doesn't fail for the code team.
<mars> deryck, ?
<deryck> mars, because they build a new URL when getting the fragment, so they're not susceptible to caching.
<rockstar> deryck, sorry, went to eat food.
<mars> yeah
<rockstar> deryck, did you figure out your issue?
<deryck> boo-yah!  I have a winner.
<mars> was wondering that
<mars> deryck, not that for your phone, "If the browser cache does not pay attention to these directives, it can't be controlled by authors."
<mars> *note
<mars> except if you rotate the URL
<deryck> exactly. :-)
<deryck> mars, rockstar -- and here's the fix:  http://pastebin.ubuntu.com/502284/
<mars> congrats.  That was a difficult one
<rockstar> deryck, what. the. hell.
<rockstar> deryck, it's caching a 404?
<mars> lol
<deryck> rockstar, firefox with firebug and mobile safari use the cached version of the resource.  Have to fake them out.
<lifeless> 404's are cachable.
<rockstar> deryck, holy hell.
<lifeless> in a negative sense
<deryck> it's not really a 404 :-)
<lifeless> squid does this all the time.
<rockstar> lifeless, yes, we see this negative affect in deryck's bug.
<deryck> no, there's no 404 there.
<deryck> it's the same resource.  the query param is ignored.
<rockstar> deryck, what's at the the end of the resource then?
<deryck> it's basically -- ?foobarjunk
<rockstar> deryck, if you just get it without the query param, what would you get?
<mars> rockstar, two bugs: first, Firebug was caching the 404 because the "Show XMLHTTPRequests" option was enabled in the Console tab - shutting it off fixed it in FF
<deryck> rockstar, the cached version
<rockstar> deryck, and that cached version is what?
<mars> rockstar, second bug: iPhone does not obey any cache headers according to http://www.mnot.net/javascript/xmlhttprequest/cache.html, so deryck had to force it to stop caching using url rotation
<rockstar> deryck, weren't you seeing this bug in Chrome as well?
<deryck> rockstar, it's mobile safari, not chrome.  Samsung sluts.
<deryck> :-)
<rockstar> deryck, yeah, but I'm pretty sure I've seen this bug since I started using Chromium exclusively.
<rockstar> mars, have you filed a bug with firebug?
<deryck> rockstar, it has to be caching issues either way.  I'm pretty confident of the fix after chatting with mars for so long.
<rockstar> deryck, oh, I don't doubt that this would fix it.  The fact that it occurs at all is craziness.  :)
<deryck> rockstar, this is an argument in favor of code team way of appending +fragment to a resource url to fetch the fragment new.
<deryck> rockstar, yeah, it's silly.
<mars> rockstar, ugh, no.  I'm too burned after this to do so, and that tab is known to have issues. FB 1.6b1+ should fix it though
<rockstar> deryck, yeah, normally, we do ++fragment.  The double plusses indicated visually that it's a fragment.
<lifeless> Gotta love mnot. The man is a god.
<rockstar> mars, okay, I'll file the bug.  I was futzing with Firebug source the other night, so I may be able to provide some more details.
<mars> rockstar, ok.  Apparently they also really like to look at bugs with test cases, but that means you'd have to write something with web.py (or cgi) to recreate the 404
<mars> rockstar, or we could ask deryck to test in firebug 1.6b1
<_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> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
<deryck> rockstar, they have a few that hint at the issue.  but they seem to lack a single case of it, as mars notes.
<deryck> b1?  really mup?
<rockstar> mars, deryck, yeah, I think writing the test case will indicate exactly what the problem is.
<deryck> 6b1
<deryck> bug 1.6b1
<_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> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:In Progress by sabdfl> <
<deryck> heh
<mars> firebug 6000.1
<_mup_> Bug #6000: vice 1.16-4 FTBFS <vice (Ubuntu):Fix Released by motu> <https://launchpad.net/bugs/6000>
<rockstar> deryck, mup is short for muppet, which, AIUI, is not a term of endearment, especially when coming from elmo.
<deryck> sorry, I'm punching after this afternoon.
<rockstar> deryck, :)
<deryck> Glad to have a fix I can use, though.
<rockstar> deryck, you'll be happy to know I'm currently massaging lazr.jstools into lazr-js.
<deryck> nice!  I am happy.
<deryck> I'm out.  Later on, everyone.
<abentley> rockstar: but elmo is a muppet on Sesame Street!
<rockstar> abentley, don't tell HIM that.  :)
<rockstar> Might as well tell the dude he's adopted.
<lifeless> \o/ /tmp directory leak in the test suite found :)
<flacoste> lifeless: is the token-based private librarian deployed?
<flacoste> thumper: hi, since my call with gary isn't happening, i'm available earlier
<lifeless> flacoste: no, losa in progress
<thumper> flacoste: ok
<lifeless> flacoste: we're bringing it up on staging first, obviously. Once its qa'd and we've checked we don't (for instance) blow out the session db size, we'll configure it in prod.
<lifeless> flacoste: and after that flick the switch.
<flacoste> lifeless: ok
<lifeless> flacoste: there is, as far as we know, no code to write.
<lifeless> flacoste: and the code is in all branches; its totally deployment & config.
<bdmurray> sinzui: here is a diff of what I had to do to get continue to redirect to +subscriptions - https://pastebin.canonical.com/37799/.  Does that seem reasonable to you?
<sinzui> bac: branch-listing.pt may render faster if we used "sprite branch" instead to using an <img> element 75 times
<bac> sinzui: good point
<sinzui> bdmurray, that looks good
<bdmurray> sinzui: in line 33 there is a change to display the bug number as it would be weird to say "this bug" on +subscriptions that seems okay too?
<sinzui> bdmurray, yes
<bdmurray> sinzui: great, I'll go see if there are other tests I need to fix up and push it
<rockstar> mars, does jslint REALLY require bzrlib?
<rockstar> mars, actually, I should say, "could we accomplish the same thing without bzrlib?"
<cr3> hi folks, what's the lazr-js/build directory used for? I see it created in the jsbuild_lazr Makefile target, but not used afterwards
<lifeless_> sinzui: so, memcache and efficiency
<lifeless> there's a design tension in our use of the DB and out use of memcache.
<lifeless> we try to do a few very efficient queries to the DB to get data.
<lifeless> and then we do memcache interception of the iteration in the page template.
<lifeless> But the DB work is already done.
<cr3> nevermind, found it: lib/canonical/launchpad/icing/lazr -> ../../../../lazr-js
<lifeless> So the only saving memcache offers is over the tal rendering.
<sinzui> I expected to save cost on renders a lot of bugs decorated with badges and users/teams links that also have icons
<sinzui> s/renders/rendering/
<lifeless> sinzui: it beggars the imagination that an RPC to get 30 bytes of data could be faster than generating those bytes from the live objects we've already retrieved from the database.
<lifeless> sinzui: I mean, if its true we have serious efficiency issues in the rendering stage that we -have- to fix to have fast memcache-misses.
<lifeless> sinzui: grabbing a whole rendered table in one hit could well be faster than rendering.
<lifeless> sinzui: grabbing a single row would be highly questionable, grabbing a single cell implausible.
<wallyworld___> morning
<lifeless> win 66
<bac> hi lifeless got a minute?
<lifeless> sure
<sinzui> lifeless, I see two cases of cache:private in registry still. the one I intended to get rid of caches a milestone in a table row when shown on a series or +milestones page. I intended to cache the entire listing for anon only.
<lifeless> sinzui: caching the entire listing is ok, but we cache anon *pages* in squid anyway.
<lifeless> sinzui: so I wonder what incremental benefit memcache will have there.
<sinzui> ha.
<lifeless> bac: whats up?
<rockstar> abentley, make-super-duper-clean-no-srsly is really effective when using buildout.
<abentley> rockstar: this is "rm * -R; bzr revert"?
<rockstar> abentley, yes.
<abentley> rockstar: hehe.
<rockstar> cr3, hi
<cr3> rockstar: hi there
<rockstar> cr3, I see you are futzing with lazr-js.
<rockstar> cr3, I'm making some changes to pull the build-type code out into a separate package.  Will that cause problems for you?
<cr3> rockstar: probably, but I could follow the evolution in the launchpad build scripts
<cr3> rockstar: thanks for the heads up though, at least I won't be too surprised when something suddenly fails to build :)
<rockstar> cr3, okay.  Yeah, the launchpad build script stuff is the last place that's going to change.  I'm currently massaging lazr.jstools back into lazr-js.
<cr3> rockstar: while you have your hands in that code, might you happen to know why SRC_DIR seems to be set to src-py/lazrjs instead of src-js/lazrjs in build.py?
<rockstar> cr3, setuptools, I think.
<rockstar> cr3, this oddity is one of the reasons I'm abstracting these tools.
<cr3> rockstar: setuptools indeed, setting the wrong directory for some reason... lets see how I can workaround that
<rockstar> cr3, you'll also notice __init__.py in src-js/lazrjs
<rockstar> cr3, why do you need to work around it?
<cr3> rockstar: or make setuptools behave to have the proper path
<rockstar> cr3, everything is hairy right now, but it should all work.  If it's not working, I'd be curious to know why not (and maybe a pastebin of the error)
<cr3> rockstar: there's no error message really, I buildout lazr-js from trunk (called toolchain) which results in the path build/source-dependencies/lazr-js/trunk/src-py in the build/parts/scripts/site.py
<cr3> rockstar: note that this is not in the launchpad codebase though, just using lazr stuff in another project
<rockstar> cr3, ah, use make.
<rockstar> cr3, ah, okay.
<cr3> I'll give the beta lazr-js tarball a try instead of building from the trunk, one moment...
<rockstar> cr3, yeah, uh, I guess my work would make it easier for you, but I'm still massaging it all together.
<rockstar> cr3, there is only trunk.
<rockstar> cr3, ignore any other branches.
<rockstar> Otherwise, you will be misled.
<rockstar> At some point, I will clean that up.
<cr3> rockstar: this is the branch I'm using: https://code.edge.launchpad.net/~launchpad-pqm/lazr-js/toolchain
<rockstar> cr3, yeah, that's right.
 * cr3 builds with tarball and crosses fingers
<lifeless> argh, stab stab stab layers.
<lifeless> and woo
<lifeless> I've finally figured out why we get multiple librarians running
<cr3> rockstar: tarball works fine, problem solved :)
<rockstar> cr3, yay!
<cr3> rockstar: another advantage is that I can relax when your changes kick in since I now have a working snapshot of lazr-js
<rockstar> cr3, yup.  You can easily upgrade lazr-js without having to worry about the python dependencies as well.
<bac> hi james_w, you still around?
<james_w> hi bac
<bac> james_w: you've got quite a few approved branches that need landing.  is there something blocking you?
<lifeless> thumper: ping
<lifeless> thumper: nvm
<james_w> bac: nothing except my lack of time
<bac> james_w: i understand.  you've done a lot of really good work that it would be nice to get landed.  let me know if i can help.
<james_w> bac: I count three, are there more than that somewhere?
<bac> james_w: yes, just those three
<james_w> bac: ok, I'll merge them up and try and land one now
<bac> thanks james_w
<lifeless> mwhudson: hey
<mwhudson> lifeless: hi
<lifeless> mwhudson: so I found more nasty nasty dirt landing this patch you reviewed monday
<lifeless> I'd like a casual eyeball over the incremental
<mwhudson> lifeless: ok
<mwhudson> lifeless: link?
<lifeless> http://bazaar.launchpad.net/~lifeless/launchpad/test/revision/11644
<lifeless> is the only non-obvious commit
<mwhudson> lifeless: unnique is a typo
<mwhudson> lifeless: "so store a valid path temporarily" -- i think you mean invalid path?
<lifeless> valid - its a string
<lifeless> as opposed to correct
<mwhudson> ah
<lifeless> clearly confusing, will rephrase
<mwhudson> thanks
<lifeless> s/valid/plausible
<lifeless> mwhudson: that was all ?
<mwhudson> lifeless: yes
<lifeless> thanks
<lifeless> you can see the hair I'm uncovering
<mwhudson> yeah, it's awesome that you're doing this
<lifeless> I'm struggling to decide whether to fix layers
<lifeless> or just bring testresources in.
<mwhudson> lifeless: i think i said to jml when you got the TA position that one of the reasons I was glad was that you were much less likely to get discouraged by this sort of thing than a typical human being :-)
<lifeless> I am the hulk in this respect.
<lifeless> fueled-by-anger
<jml> lifeless: jkakar & I have discussed rage-driven development
<lifeless> nice
<mwhudson> i occasionally find code that i wrote and remember how extremely angry i was when i wrote it
<lifeless> so what I actually meant was that my motivation increases the more problematic stuff I run into.
<lifeless> not that I feel /angry/ as such.
<mwhudson> right, that's a more useful effect
* lifeless changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 3 of 10.10 | PQM is open for business | firefighting: - | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<poolie> hello jml, mwhudson
<jml> hi everyone. I'm not really here.
<poolie> suits you :-P
#launchpad-dev 2010-09-29
<bdmurray> sinzui: the +subscriptions mp is ready for rereview now - https://code.edge.launchpad.net/~brian-murray/launchpad/limited-subscriptions-page/+merge/35177
<jml> I'm so behind on email.
<mwhudson> jml: i suggest putting a small weight on your 'y' key
<jml> mwhudson: I much prefer '['
<jml> mwhudson: even so, I've still got 50+ threads marked as "actually, I should read this" and another 20+ as "should answer"
<mwhudson> ah ok, that's a harder problem
<jml> yes.
<jml> I think the only answer is to never concentrate ever again
<jml> (unless an email demands that I do so)
<jkakar> jml: Remove the label from all the emails.  Important things that you should have paid attention to will either (a) get taken care of naturally or (b) spiral out of control and explode.
<jkakar> jml: It'll be easy to see which things need attention. :)
<jkakar> jml: I've been enjoying the labelling system you described to me... I find it really hard to be disciplined to actually do the "and get back to deal with labelled items" part, though.
<jkakar> Much of the time I procrastinate and then, when I get back to the items, they're no longer relevant.  It's quite an effective technique.  I'm very efficient.
<thumper> lunch calls
<wgrant> buildd-manager seems broken.
<wgrant> Can someone check its logs?
<wgrant> Did the CP end up happening?
<wgrant> StevenK: ^^
<poolie> thumper: i have a deal for you
<poolie> thumper: get someone from your team to review and sponsor jam's lp-serve branch, and then he can move on to commit to stacked branches
<wgrant> sinzui: Does the move of tales to lp.app imply that we're not going to split it?
<sinzui> no
<wgrant> Ah, good.
<sinzui> 25% belongs in lp.app, 50% registry
<thumper> poolie: ok
<thumper> poolie: deal
<rockstar> thumper, skype?
<thumper> rockstar: sure, let me finish my roll first
<thumper> rockstar: ok, now
<wgrant> sinzui: Are you sure that users should be granted access to see *everything*? Even embargoed security bugs?
<sinzui> wgrant, I am not sure
<lifeless> In the context of an already private project?
<lifeless>  / distro
<wgrant> Right.
<sinzui> lifeless I think the issue can be generalised to all projects and distros.
<sinzui> If I grant view on a public project with private bugs and branches I assume most cases I mean to let the user see everything
<sinzui> but in the case of security (which is security contact, not bug supervisor) we may want to require subscription
<wallyworld__> thumper: ping
<rockstar> wallyworld__, I understand you're wanting to do some YUI stuff.
<wallyworld__> rockstar: yeah. do you want to take a peek at https://code.edge.launchpad.net/~wallyworld/launchpad/improved-broken-link-handling
<wallyworld__> and tell me i'm doing it all wrong
<wallyworld__> we can skype after you've had a look?
<rockstar> wallyworld__, okay, I'll take a look.  I was actually going to say "we can skype tomorrow and chat about it"
<wallyworld__> rockstar: tomorrow is fine
<rockstar> wallyworld__, as it stands, this is my wife's night off this week, and if I don't watch Madmen with her, I will probably find the locks are changed the next time I leave the house.
<wallyworld__> rockstar: np. we can chat tomorrow. i forgot it was way past eod for you, sorry
<rockstar> wallyworld__, my EOD is kinda fuzzy some days.  :)
<wallyworld__> rockstar: me too :-) i was up late last night figuring out some of the YUI stuff that i'm playing with now
<wallyworld__> hopefully i'm not totally on the wrong track. :-)
<rockstar> wallyworld__, I'm still trying to find the right track with YUI.  :)
<wallyworld__> well, i just tried to see how other stuff had been done and go with the flow. anyway, have a good time watching madmen. talk tomorrow
<wgrant> mwhudson: Does Shotwell realise that it doesn't own your photos?
<mwhudson> wgrant: what do you mean?
<wgrant> mwhudson: F-Spot likes to copy the photos into its local library and store all metadata somewhere other than the EXIF tags.
<wgrant> Which makes it impossible to use across multiple machines.
<mwhudson> wgrant: i think it's better about the copying (when you import it asks if you want to copy them)
<mwhudson> wgrant: dunno about tags
<thumper> wallyworld__: hey
<wallyworld__> thumper: just wanted to skype at some point about the new work. when you are free
<thumper> wallyworld__: I'm never free :)
<thumper> cheap maybe, but not free
<thumper> wallyworld__: let me get a small bit of work done
<thumper> then we can talk
<wallyworld__> ack. i'll have lunch
<denniss1> #bshellz
<thumper> ProgrammingError: operator does not exist: text = bytea
<thumper> has anyone been fixing these on trunk yet?
<lifeless> no
<mars> thumper, bug 631010
<_mup_> Bug #631010: ProgrammingError: operator does not exist: text = bytea <database> <maverick> <storm> <Launchpad Foundations:In Progress by mars> <https://launchpad.net/bugs/631010>
<mars> thumper, working on it right now
<lifeless> that reminds me to talk to doko or simila rabout it
<thumper> is that the package downgrade hack?
<lifeless> yes
 * thumper sighs
<lifeless> mars: if the fix is 'scatter u around the place' then its going to make the code base really ugly.
<lifeless> mars: so please don't do that ;)
<mars> lifeless, https://bugs.edge.launchpad.net/launchpad-foundations/+bug/631010/comments/4
<_mup_> Bug #631010: ProgrammingError: operator does not exist: text = bytea <database> <maverick> <storm> <Launchpad Foundations:In Progress by mars> <https://launchpad.net/bugs/631010>
<lifeless> mars: do you mean to say you're putting the older version in the ppa ?
<lifeless> mars: if so cool, but can you please file a bug on maverick at the same time?
<thumper> mars: do you have the downgrade command handy?
<mars> thumper, no, sorry, in the thread, look for "aptitude hold python-psycopg2", maybe "apt-get install python-psycopg2=2.0.13-2ubuntu2"
<mars> just a guess
<mars> lifeless, what do you mean "file a bug against maverick"?  Like bug 585704?
<_mup_> Bug #585704: Storm test suite fails when using psycopg2 2.2 <Storm:Fix Committed by jamesh> <https://launchpad.net/bugs/585704>
<lifeless> no
<lifeless> I mean that psycopg2 in maverick is buggy
<lifeless> this change (presumably from upstream) is -not safe- to make in python 2.x modules.
<lifeless> python 2.x is hopeless confused about bytes vs text, and I can pretty much guarantee that every python webapp on pgsql will be fucked by maverick.
<mars> lifeless, may I suggest you file the bug then, if you know the implications and the people involved?
<lifeless> I don't know the people.
<lifeless> but sure
<wgrant> OTOH we could just fix LP.
<thumper> sudo dpkg -i --force-downgrade python-psycopg2_2.0.13-2ubuntu2_amd64.deb
<mars> ah
<thumper> that's what I did (for future reference)
<lifeless> wgrant: it will, I guarantee, bit us for months.
<lifeless> wgrant: its unbelievably hard to be 'correct' in this regard in python 2.
<lifeless> even if you just use the core built in things like 'Exception'
<wgrant> lifeless: It is hard, but Storm already forces us to be pretty much correct.
<wgrant> There are only a few places where we're not.
<lifeless> wgrant: really?
<mars> so does anyone know if simply copying the package from Lucid to Maverick in the LP PPA would work?
<lifeless> wgrant: so < 2 hours work?
<wgrant> lifeless: Storm will refuse str vs unicode mismatches.
<wgrant> lifeless: So it's only where we're using string-based SQL that there are problems.
<lifeless> wgrant: thats only one form of incorrectness
<lifeless> wgrant: if its so transparent, presumably storm can fix it transparently?
<wgrant> lifeless: Storm is pedantic in the way you say psycopg2 shouldn't be.
<wgrant> And has been since day 1.
<mars> wgrant, maybe you know if the package can simply be copied?
<lifeless> wgrant: then how can this issue exist? we pass 99% of everything through storm
<wgrant> lifeless: Pillar name retrievals don't go through Storm.
<lifeless> mars: if wgrant is correct just fixing LP would be better?
<wgrant> eg. getUtility(IDistributionSet)['ubuntu'] doesn't.
<lifeless> wgrant: they don't?
<wgrant> Because of the pillar name mess.
<lifeless> what does it go through ?
<mars> lifeless, I think henning looked at that, but he "stopped doing this when I hit the first decoding errors. :("
<mars> He was putting u'' or unicode() around the query parameters in the test suite
<wgrant> lifeless: IPillarNameSet, which constructs parameterised SQL manually.
<lifeless> wgrant: but that still goes through storm
<lifeless> we ask storm to run it and storm asks psycopg to run it
<wgrant> Right.
<lifeless> so I repeat, why can't storm fix this?
<poolie> does "fix released locking" mean that once a bug is fixreleased, it can't leave that state?
<lifeless> actually lets back off
<lifeless> poolie: I think so
<wgrant> Because Storm is even more pedantic than psycopg2. It would go against its normal policies to fix it.
<lifeless> wgrant: We have two competing theories.
<lifeless> wgrant: one is that its shallow.
<lifeless> wgrant: the other is that its complex and contains surprises.
<wgrant> mars: You should be able to get away with copying the Lucid *primary archive* version of psycopg2 to Maverick in the PPA.
<lifeless> wgrant: The data we have supporting it being shallow is nonexistent.
<lifeless> wgrant: its speculation based on the changes storm needed itself to work.
<mars> wgrant, ok, that would solve the Py2.5 dep problem by being for Py2.6.  I'll give it a shot
<wgrant> I was able to fix lots of it just by hacking the celebrity descriptors to unicode() their names.
<wgrant> mars: We shouldn't have psycopg2 for Lucid in the PPA at all.
<lifeless> wgrant: the data we have suggesting it being complex is - decode errors being thrown when putting u before strings was attempted.
<lifeless> plus how freaking hard it was to get bzr roughly sane, and the testtools stack similarly.
<lifeless> wgrant: I humbly submit that you're being optimistic, unless you have more data you haven't presented.
<wgrant> The thing is that LP is already very close, because Storm and Zope force it to be.
<mars> poolie, I wouldn't be surprised.  There must be a fair bit of thought behind a request like that.
<lifeless> wgrant: but they don't
<lifeless> Foo.name=='thing' <- clearly not 'correct'
<lifeless> Foo.name=u'thing' <- clearly ugly. Vive la Python tres.
<wgrant> Well, let's get Zope running on 3.2 :P
<lifeless> wgrant: and 'thing' works at the moment in lucid.
<lifeless> wgrant: whyever its not working in maverick is a regression in the stack.
<lifeless> in python 3 it would be correct, and historically in python 2 it is also correct.
<wgrant> Has anybody talked to the psycopg2 folks about this?
<lifeless> meh, mere facts.
<lifeless> https://bugs.edge.launchpad.net/ubuntu/+source/psycopg2/+bug/650777
<_mup_> Bug #650777: operator does not exist: text = bytea <amd64> <apport-bug> <maverick> <psycopg2 (Ubuntu):New> <https://launchpad.net/bugs/650777>
<lifeless> http://comments.gmane.org/gmane.comp.python.storm/1256
<lifeless> its also partly storm
<lifeless> treating str as a bytea
<lifeless> which is arguable either way as 'correct' in Python2 - but clearly isn't pleasant to interoperate with.
<poolie> is there any systematic preference towards having one feature rules page that appears either editable or not, vs having a separate edit page to which only some people have access?
<poolie> launchpad tends towards the latter but the former seems to have less dry
<poolie> less repetition, i mean
<mtaylor> Can't open average time db /var/debbuild/avg-build-times
<mtaylor> Can't open average space db /var/debbuild/avg-build-space
<wgrant> mtaylor: That's normal.
<mtaylor> wgrant: then why did this fail
<mtaylor> wgrant: http://launchpadlibrarian.net/56710656/buildlog_ubuntu-lucid-amd64.drizzle_2010.09.1797-1.1~lucid01_BUILDING.txt.gz
<wgrant> That looks like an upload failure.
<wgrant> Can you link me to the build?
<wgrant> Ah, there.
<mtaylor> wgrant: ah yes
<mtaylor>  -> http://launchpadlibrarian.net/56710652/57D507LpzoCnzjO9QXav5M64BhB.txt (duplicate key value violates unique constraint "binarypackagerelease_binarypackagename_key"
<wgrant> Yes.
<wgrant> Which means a bug has resurfaced.
<wgrant> Sigh.
<wgrant> Your build is fine; just ignore the failure.
<wgrant> It already finished once, then magically got illegally retried.
<mtaylor> ok. cool
<mtaylor> well, glad I could help find a bug :)
<lifeless> poolie: I don't care either way.
<wgrant> mtaylor: With any luck it will be fixed after tonight's cherrypick.
<mtaylor> w00t
<wgrant> It replaces what I suspect to be the problematic code, for others reasons.
<StevenK> lifeless: Ping
<lifeless> hi
<StevenK> lifeless: Re: your mail about poppy, is there anything you need me to fix?
<lifeless> it was meant to educate
<lifeless> I knew you and jml collaborated on that stuff
<lifeless> and this got through your pair programming sessions.
<StevenK> lifeless: I'm happy for education and the chance to clean up after my mistakes
<lifeless> StevenK: my 'test' branch has fixes.
<lifeless> StevenK: I appreciate the offer to clean up, but there's no need to handoff here.
<lifeless> I'll be back around later
<stub> lifeless: Are you hacking layers today?
<lifeless> stub: lp:~lifeless/launchpad/test has layer stuff in it and is in ec2land atm
<lifeless> stub: got a request?
<stub> I didn't want to conflict.
<lifeless> if you check that you don't conflict with my branch, it will be fine.
<lifeless> what are you doing ?
<stub> I think I might have pushed too early - pqm is currently in process of landing by branch, and I pushed new revisions. Have I borked it or will it only merge revisions pushed when it started processing?
<stub> Making the thread check more robust - there is a codehosting test that occasionally fails, so I'm giving garbage threads a few seconds to shut down and gc.collect() to help them along
<stub> Uncommit and push overwrite before PQM finishes processing?
<wgrant> Doesn't the signed request include a rev ID?
<stub> No it doesn't
<stub> lifeless: ^^
<wgrant> Well. That's a bit strange.
 * stub tries the push overwrite before it is too late
<stub> bah - something else has it locked
<lifeless> it will only merge what it found when it started.
<stub> ok. So I can get this changed reviewed and check for conflicts :)
<lifeless> stub: any reason we can't just remove the thread check? what does it actually help us with? Or make it like the bzr one (reports at the end on tests that leaked)
<stub> lifeless: We can drop the thread check if we don't care about tests leaving threads lying around. I've mentioned that option when that has come up in the past, but people have always opted for fixing the source of the issue.
<lifeless> stub: I quite like what bzr does:
<lifeless>  - gathers threads
<lifeless>  - doesn't fail, but reports on the tests that leaked.
<lifeless> its a mix of both worlds.
<lifeless> I very much like fixing the source of issues, but a thread not being gone by the time a test finishes isn't prima facie an issue
<lifeless> bbs
<stub> A test can turn the fail into a warn if it wants, or we could set it globally by changing the flag in BaseLayer.
<poolie> any guesses why my validate method is getting an empty 'data' dict?
<poolie> i guess the field is not correctly seen as a widget
<poolie> jtv i realized i can use validate() to give a better syntax error message
<jtv> poolie: yes, that's a good place for it.
<lifeless> stub: so rather than adding multi second delays
<lifeless> stub: lets make it a warning
<lifeless> stub: globally
<stub> lifeless: Tests rarely hit this - we will be delaying maybe one in 10 test runs a few seconds
<jtv> poolie: I see no excuse for the field not to be in the data dictâ¦ does the form use GET instead of POST or something?
<stub> I'd like to land it as is because the revision did get through PQM :-/
<lifeless> stub: thats fine, but perhaps you could follow up with more stuff?
<stub> So the sleep is still valuable as it is 1) unreasonable to expect tests to wait on every thread spawed, particularly if they were not responsible for spawning it 2) sometimes threads can take a while to shut down.
<stub> Are both those points reasonable?
<lifeless> mmm
<lifeless> so we had a period in bzr where we tried a few different things
<stub> We can of course make the sleep less - maybe 100 checks at 0.1 second intervals rather than 10 at 1 second?
<stub> If it is just the thread didn't get allocated enough cpu to shutdown, it is likely sorted in milliseconds.
<lifeless> so, to cleanup threads, they *have* to be joined
<poolie> jtv i've solved it now
<jtv> poolie: what was it?
<poolie> i had handcrafted html for the textarea and i should have let launchpad generate it
<poolie> well, zope
<poolie> then the field name would have matched what it expected
<jtv> ah ah ah
<jtv> So your data wasn't emptyâyou just weren't looking for the right key!
<stub> lifeless: I looked for a way to do that and couldn't find it. A second check now and it looks like I *can* iterate over the new threads and join them with a timeout.
<lifeless> stub: well, more importantly, I think this invalidates 1)
<lifeless> test code is either directly responsible for spawning the thread, or its using an api which must have a facility to join its own threads
<stub> Yes. I think we can make BaseLayer wait for the threads to terminate for a period of time. I think it is worth failing the test if they don't die, as it is a leak.
<lifeless> or its something like a thread pool which reasonably wants to stay active.
<poolie> jtv, it was empty, but that's because zope code doesn't pass through unrecognized input parametres
<poolie> my god it's a bit disgusting how many http requests there are per page in test mode
<stub> We have a flag to turn the fail into a warn. I think it is worth keeping it as a fail until we actually have threads that should remain active across threads.
<poolie> i realize in production some things are rolled up into larger resources
<lifeless> if we want to catch incidental spawned threads that leak, we either need an API to say that some threads *are* expected, or we have to ensure that all tests clean up everytime
<jtv> poolie: a lot of those will be for icing that isn't served by LP
<lifeless> setting up a thread pool is both reasonably cheap and also reasonably expressed as a fixture for sharing across tests.
<lifeless> so I think we can say 1) it is reasonable to require tests to join all threads they cause (in)directly to be spawned.
<jtv> poolie: but it'd be great if we could reduce the requests and db queries we see on dev systems, yes
<lifeless> stub: with that assertion, 2) becomes irrelevant,
<lifeless> stub: what do you think?
<stub> Yes, 2 becomes irrelevant.
<stub> 1) is still relevant though, as threads could be spawned by third party libraries like bzrlib.
<lifeless> does my argument for revising (1) make sense to you?
<stub> No.
<stub> If bzrlib starts spawning a new thread where previously it didn't, it is unreasonable to update all the LP tests to check for this new thread to terminate.
<stub> or zope or psycopg or whatever
<lifeless> But a test fail is a test fail.
<jtv> poolie: perhaps you can help me with the traceback you see near the end of this "make harness" session: https://pastebin.canonical.com/37820/
<lifeless> stub: I mean, I agree, thats why I was suggesting warning only initially;
<stub> The layer will wait for the thread to terminate if it takes time (the spurious failures I'm trying to address), and if it doesn't terminate in a few seconds, then it fails.
<jtv> poolie: that's on the staging db.  Why the lp-internal URL scheme, and why does convert_path_to_url choke on it?
<stub> warnings just get ignored, and we are left with a test isolation leak
<lifeless> I think warnings that are very clear are less likely to be ignored
<lifeless> 'test foo leaked 4 tests' is pretty clear.
<lifeless> stub: waiting for e.g. a thread pool thread to terminate is likely to just timeout, only a few threads are ones that will naturally go away.
<stub> So what is the advantage of warning? I see absolutely none, except a potential problem has leaked into the codebase. Its not like we expect this to happen - we have never had a thread leak that wasn't a) spurious b) an error
<lifeless> stub: I don't think its a strong argument for the layer waiting at all given that being able to wait successfully is itself a special case.
<stub> (a or b)
<poolie> jtv, this is just spm randomly typing stuff?
<poolie> jtv, that transport is registered by the lp-serve plugin
<lifeless> sigh, openid grrr grr grr grr
<poolie> so for some reason that's not loaded in this process
<jtv> poolie: no, this is spm pasting a script I wrote up for this purpose into make harness.
<poolie> either
<poolie> 1- you didn't ask for plugins to be loaded in this interpreter
<poolie> 2- that plugin wasn't found, probably because it wasn't on your path
<poolie> 3- other
<lifeless> stub: so there are three approaches: a) wait and fail; b) warn [no point waiting if it can't fail], c) fail [make it the tests responsibility]
<stub> For b), we should wait. We don't want spurious warnings as people just filter them out as noise.
<lifeless> stub: I don't see the value of waiting
<jtv> poolie: well I didn't ask for them to be loaded in this script, but it's not unthinkable that the branch scanner (which goes through similar steps) doesn't either.  How do I ask for that?
<lifeless> stub: we've spent enough time on it - do what makes sense to you.
<lifeless> stub: I can say that I wouldn't wait :)
<stub> lifeless: warn and not wait is the solution everyone has rejected so far.
<poolie> jtv bzrlib.plugin.load_plugins
<poolie> jtv importing lp.codehosting seems to do that as a side effect
<jtv> poolie: yup, see it in the __init__
<jtv> .py
<jtv> So that's my script, not the branch scanner code
<jtv> Thanks!
<poolie> try running bzrlib.plugin.plugins()
<jtv> poolie: locally that gives me a bunch, including lpserve.
<poolie> k
<poolie> perhaps the paths are being set up wrong so it's not loaded
<jtv> poolie: well in that script I think I simply didn't do anything that loads it.  Trying a corrected version now.
<lifeless> stub: sure, thats doesn't mean its wrong :P
<lifeless> stub: anyhow, as I say, do what makes sense to you
<wgrant> lifeless: What does the bad-commit-11566 tag do?
<poolie> hi jtv? all ok?
<jtv> hi poolie!  No reply from spm yet
<lifeless> wgrant: https://dev.launchpad.net/QAProcessContinuousRollouts
<lifeless> StevenK: I would like an answer on my concurrent poppy question
<StevenK> lifeless: I've had a few stack dumps since then, can you please re-ask?
<lifeless> StevenK: look in the mailing list :)
<StevenK> lifeless: And no, we don't
<StevenK> lifeless: Both cocoplum and germanium run the FTP and SFTP servers
<StevenK> And I have no idea about how either of those services would cope or behave in a load-balancing situation
<noodles775> Morning ppl
<lifeless> StevenK: we don't what ?
<StevenK> lifeless: We don't run a single copy of both the FTP and SFTP servers.
<lifeless> for ppas, how many copies do we run ?
<StevenK> One, on germanium
<wgrant> But cocoplum's works perfectly well.
<StevenK> lifeless: Notice I'm not disagreeing it's a SPOF, I'm disagreeing that we only run one copy.
<lifeless> StevenK: I don't know what you're saying at all
<lifeless> StevenK: so i'm trying to pin it down
<lifeless> wgrant: will a ppa upload to *either* work for PPAs' ?
<wgrant> lifeless: Yes.
<lifeless> so all we hve to do is shove ha proxy in front and make all the dns names point at the same place?
<StevenK> That will then cause havoc
<wgrant> I'd prefer to resolve a germanium SPOF in a way that doesn't involve cocoplum.
<lifeless> what havoc?
<StevenK> Since people download and upload from ppa.launchpad.net
<lifeless> let me explain what I need.
<lifeless> I need:
<wgrant> lifeless: Does haproxy do FTP and SFTP?
<lifeless>  - to know whether the software is safe to run concurrently for a given 'queue' (or whatever abstraction it uses - sounds like it is)
<wgrant> poppy can safely run concurrently, yes.
<lifeless>  - to provide a detailed request for config changes to the losas to eliminate the current downtime during upgrades.
<wgrant> It's not safe to run multiple upload processors, but we do anyway.
<lifeless> upload processors are less concerning
<lifeless> because its not listening on the network
<wgrant> Right.
<lifeless> so
<wgrant> But we can't safely run multiple upload processors from different hosts.
<lifeless> so, which machine is the ppa one
<wgrant> germanium
<lifeless> and what is cocoplum known as?
<wgrant> cocoplum is the other instance -- it is ftpmaster.
<lifeless> does ftpmaster provide an HTTPS interface?
<lifeless>  and HTTP ?
<StevenK> No
<wgrant> Not externally.
<lifeless> so, how does this sound.
<StevenK> HTTP only, and only internally
<lifeless> is that http apache?
<StevenK> Yes
<lifeless> here is what I propose
<lifeless> ha proxy with ppa and ftpmaster pointing at it
<lifeless> ha proxy directs http requests to germanium
<lifeless> ha proxy or germanium's apache sends ftpmaster internal requests to cocoplum
<lifeless> ha proxy directs ftp and sftp to either machine depending on whats running
<wgrant> This sounds like two SPOFs.
<wgrant> Also, will FTP be much of a fan of being run through haproxy?
<lifeless> wgrant: SEP
<StevenK> Or SFTP, for that matter
<wgrant> SFTP should be fine.
<wgrant> It's a single TCP stream.
<lifeless> so, elmo has said there is a tool (it might not be haproxy) for doing this stuff.
<StevenK> I'm worried about host keys
<lifeless> if there isn't we'll have to go find or write one.
<lifeless> StevenK: ok, thats a good point. We can do one of two things.
<wgrant> StevenK: They'd have to be the same on both.
<wgrant> Easy enough.
<lifeless> we can say 'these should really have been one service', announce and JFDI it.
<StevenK> I'm also worried about user-confusion
<wgrant> lifeless: Why should ftpmaster.internal requests go through germanium?
<lifeless> or we can say 'these are meant to be different', and we then bring up new instances of these services on other machines and tell the twisted daemon to use an appropriate host key.
<lifeless> StevenK: getting rid of downtime can go a long way :)
<lifeless> note that openssh host keys are not involved here
<lifeless> because its twisted doing ssh
<wgrant> lifeless: The two hostnames used for FTP and SFTP are upload.ubuntu.com and ppa.launchpad.net.
<lifeless> wgrant: so what are the two spofs you see?
<lifeless> wgrant: I'm suggesting only that ftpmaster things on the hostname that poppy is on get redirected.
<lifeless> wgrant: if there is no http/https on 'upload.ubuntu.com' then its irrelevant
<wgrant> lifeless: ftpmaster.internal should still point at cocoplum. upload.ubuntu.com and ppa.launchpad.net will point at haproxy.
<lifeless> yes
<wgrant> haproxy forwards HTTP(S) to germanium, and sends ftp/sftp to germanium or cocoplum.
<lifeless> yes
<wgrant> This leaves germanium as only a SPOF for PPA, not ftpmaster too.
<lifeless> anything else we need to tweak, or can I shoot this off?
<wgrant> Well, it's not safe at the moment.
<lifeless> wgrant: is it less safe than what we have now?
<wgrant> Uploading to both can result in rather corrupt archives.
<wgrant> If I upload a package twice to one host, it will be rejected the second time.
<lifeless> what do you mean?
<wgrant> If the second one lands on another host, and is processed simultaneously, both uploads may succeed.
<wgrant> This is not theoretical -- this happened to me a couple of months ago.
<lifeless> sounds like a bug
<wgrant> It is, yes.
<lifeless> when will you fix it?
<wgrant> We need better locking. But neither Julian nor I have much idea of how to do it.
<lifeless> [did you see what I did there?]
<lifeless> wgrant: how did that happen? or were you uploading to the other host deliberately?
<wgrant> lifeless: I'd waited an hour for an upload to be processed on germanium, and had no response. So I uploaded to cocoplum. Also no response.
<wgrant> Half an hour later, both uploads were processed simultaneously.
<wgrant> And my PPA got rather unhappy.
<lifeless> wgrant: could we just put a unique index on the archive?
<wgrant> lifeless: Over about 6 tables, sure.
<StevenK> No
<wgrant> ie. "no"
<wgrant> Archive-BPPH-BPR-BPF-LFA
<StevenK> SPPH
<StevenK> SPR
<wgrant> That too.
<wgrant> And SPRF.
<stub> I'm fixing the stable->db-devel merge conflict
<StevenK> So it's Archive-BPPH-BPR-BPF-SPPH-SPR-SPRF-LFA
<wgrant> We could put a constraint in, I suppose.
<StevenK> Tasty, 8 table unique index
<lifeless> mmm, that says you have a buggy model.
<lifeless> we should look at that.
<wgrant> The model is horrifyingly complex.
<wgrant> I'm not sure it's *buggy*.
<lifeless> now
<lifeless> its simple to fix this
<lifeless> rather than active active
<lifeless> active-failover
<lifeless> is the load on the system low enough that that would work
<StevenK> Not for cocoplum
<StevenK> The publisher on cocoplum is mean
<stub> wgrant: If you need to enforce uniqueness over that many tables, it is buggy (well - unsupported by RDB model). The data that needs to be unique needs to be broken out into a separate table.
<lifeless> StevenK: why are we talking about the publisher?
<StevenK> Because it's involved as well, it runs on cocoplum for the Ubuntu archive
<stub> fudz
<lifeless> StevenK: It wasn't listed in the changes proposed above, can you describe how its connected?
<StevenK> lifeless: You asked if the load on the system is low enough
<lifeless> ok
<lifeless> so if we make germanium the normally active master
<lifeless> for poppy
<lifeless> can cocoplum handle the load for say 30 minutes during a germanium services reboot ?
<StevenK> It will suffer, and I have no idea about germanium's nominal load, since I don't have access to it
<lifeless> the question is whether the uploads during that period would feel degraded to users.
<lifeless> but if the main load is the archive, it would presumably feel just like upload.ubuntu.com does today.
<lifeless> so, we have:
<lifeless> upload & ppa -> haproxy
<lifeless> http -> germanium
<lifeless> sftp and ftp -> germanium unless its down, then to cocoplum
<lifeless> announce and consolidate a single hostkey for both services
<StevenK> They may already share one, but I'm unsure
<lifeless> ok, go/nogo ?
<lifeless> I'm going to cc bigjools
<lifeless> but I want to be sure we're happy with the plan first
<StevenK> To be perfectly honest, I have my doubts, but nothing I can put my finger on.
<StevenK> Call it a gut feeling
<lifeless> ok
<lifeless> Will let Julian mull on it.
<StevenK> That bit sounds good
<wgrant> stub: I'm not sure there's a significantly better way, unfortunately.
<StevenK> In an utterly unrelated question, can I have an __init__ function take arguments if it's being called from getUtility(Interface) ?
<lifeless> no, but you can register an instance rather than a factory
<stub> StevenK: utilities are singletons and even shared between threads.
<lifeless> wgrant: whats the bug number ?
<poolie> it seems like zope, if a field is '', omits it from the data dict?
<poolie> is that true or am i doing something weird?
<lifeless> I would not be surprised. Displeased, but not surprised.
<poolie> hm
<poolie> it's kind of unfortunate because it conflates that case with "i made a mistake and didn't get the form i expected"
<lifeless> wgrant: does that race condition exist with ftp + sftp as well ?
<wgrant> lifeless: I don't think so.
<wgrant> But I can't see the configs.
<wgrant> Do they use the same upload queue directory?
<StevenK> No, they don't
<StevenK> Oh, queue directory. Yes.
<wgrant> Then they're safe.
<poolie> jtv, lifeless, i think i'm finally almost there
<adeuring> good morning
<poolie> hi abel
<wgrant> lifeless: Do you have a plan to remove the main germanium SPOF?
<wgrant> That is HTTP.
<wgrant> It probably has more users than any other LP service.
<lifeless> san
<wgrant> Ideally, yes.
<wgrant> Do you have one?
<lifeless> soonish
<wgrant> Excellent.
<wgrant> Will it be used for the librarian too?
<lifeless> probably
<lifeless> though running something like ceph might be even better
<wgrant> Hmm. Maybe.
<wgrant> But SANs are easier.
<lifeless> not really
<lifeless> dufferent
<lifeless> grrr ec2land fail
<wgrant> Can we rename it to ec2reject?
<poolie> it's kind of russian-roulette landing isn't it
<wgrant> It varies.
<wgrant> For a while it was almost always one-shot.
<wgrant> Then it... wasn't.
<StevenK> ec2 landifyourelucky
<lifeless> well
<lifeless> this is changing fundamental assumptions
<lifeless> so its not surprising to be playing 'tanks'
<lifeless> its just slow.
<lifeless> bbiab
<mrevell> Morning
<jml> lifeless: the ec2 land fail... what was the bug?
<stub> Does the failure at https://lpbuildbot.canonical.com/builders/lucid_db_lp/builds/272/steps/compile/logs/stdio make any sense to anyone?
<stub> Failure looks genuine, and the landing is the stable -> db-devel merge
<stub> https://lpbuildbot.canonical.com/changes/13 - tales stuff being modified by someone.
<wgrant> Um. "Dissolve cornflakes"?
<wgrant> Ah, I see.
<stub> I'd guess https://lpbuildbot.canonical.com/changes/9
<stub> nope - that is production...
<lifeless> jml: interrupted subunit stream, probably due to the layer code - perhaps even the thing I fixed in zope.testrunner that isn't merged yet because it has no tests because buildout was not working for it
<lifeless> stub: sinzui moved tales to a new place
<bigjools> jelmer: there he is :)
<stub> https://lpbuildbot.canonical.com/changes/12 from jcsackett, but that landed on lp/devel too recently to be affecting db-devel?
<stub> oic. so moving it broke some new code on db-devel
<lifeless> stub: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/607391 needs qa
<_mup_> Bug #607391: upgrade robustness for cronscripts <cron> <qa-needstesting> <Launchpad Foundations:Fix Committed by stub> <https://launchpad.net/bugs/607391>
<lifeless> stub: and if it needs special deployments stuff, writing up in the normal fashion.
<lifeless> stub: its next in the https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt queue
<stub> k
<stub> I'm sending a [testfix] with the corrected import
<jml> lifeless: ahh, ok
<jml> lifeless: I guess we ought to upgrade to z.testrunner if we can, just to make sending things upstream easier (or, as you say, abandon it altogether)
<lifeless> abandooon
<lifeless> one less thing to maintain.
<jml> lifeless: well, first port of call is stop using layers :)
<jml> alternatively, stop needing z.testrunner to do layers
<lifeless> working on that, this branch keeps bouncing with more glitches
<lifeless> because the tolerance for bad environment goes way deep
<jml> lifeless: good luck!
<lifeless> thanks
<stub> If we stop using layers, I don't think there is any reason to use z.testrunner.
<jml> stub: yeah, that's my impression too
<stub> mthaddon: Can you confirm that staging cronscripts are happily running? (This is for QA).
<mthaddon> stub: erm, all of them? not quite sure what you mean
<stub> mthaddon: Any of them
<mthaddon> stub: process-mail.py seems to be working fine
<stub> mthaddon: Assuming they are running, can you please create http://paste.ubuntu.com/502544/ as cronscripts.ini in the root of the staging tree and run an arbitrary cronscript?
<stub> It should give you a log message about being disabled, and I can qa-ok by bug.
<stub> (INFO level message)
<stub> Wee! The daily storm is starting. Love the show this time of year ;)
<mthaddon> stub: https://pastebin.canonical.com/37829/
<stub> mthaddon: Ta. That's everything I need.
<mthaddon> k
<stub> mthaddon: So two changes you should like have landed. The --log-file argument has changed. Now you can run cronscripts as 'foo.py -q --log-file=debug:/srv/logs/foo.log' and have WARNING and above go to stderr and DEBUG and above go to the log file. -qq if you only want to see ERROR and above as you would expect.
<stub> mthaddon: logrotate will work fine on these logs - the module will notice and cope with the file being rotated under its feet.
<stub> mthaddon: The other one is cronscripts.ini being available at a configurable URL and enabling/disabling scripts individually or in bulk. I suspect the first use of this will be to disable the cronscripts while running upgrade.py etc. during the staging restore.
<stub> mthaddon: How should we go about documenting these?
<mthaddon> hmm
<mthaddon> stub: I think probably an email to the losas is the way to start - we can then figure out what to do from there
<stub> mthaddon: ok. Will do.
<gmb> Well now, this is special...
<gmb> Does anyone have any idea why I've suddenly started having this problem after merging devel: http://pastebin.ubuntu.com/502558/
<gmb> stub: Is this ^^ something to do with the logging stuff you were working on last week?
<gmb> Or am I just seeing "logger" and jumping to conclusions?
 * gmb make cleans
<stub> gmb: I think it is fallout
<gmb> stub: Okay. We'll see what happens when I've cleaned and rebuilt.
<stub> gmb: We were previously throwing away a lot of log messages by accident. We should fix that noise in the Librarian log file. Ideally by someone who understands how twisted does its logging.
<stub> I think we currently have some frankenstein Python/twisted hybrid?
<stub> Might just involve adding a NullHandler to getLogger('librarian') in lp_sitecustomize.py or in the librarian startup gumph.
<stub> gmb: This won't stop the librarian from starting though, so either the real error is further down or the real error isn't being output because librarian logging has been screwed.
<gmb> Hmm, interesting.
<stub> gmb: Suspect rogue librarian process (aka. the usual suspects)
<gmb> Entirely possible.
 * gmb goes to poke around
<stub> jml might know since I saw his XXX somewhere in there...
<jml> hello.
<stub> jml: I broke librarian logging. please fix it.
<jml> stub: OK. I'll need some coffee and to finish with this email thread first though.
<stub> score
<gmb> stub, jml: FTR the problem went away after make clean / make. No stale processes hanging around.
<jml> \o/
<jml> gmb: I guess there's a deeper bug about the shitty failure mode
<gmb> Indeed.
<gmb> I do like the librarian's strategy of just shouting about the problem twenty or thirty times and then falling over. That might be the new way forward for error handling.
<jml> gmb: in particular, shouting about the wrong problem
<gmb> Yes. That was somewhat unhelpful.
<stub> We could make our logs more readable by dropping the LEVEL prefixes entirely and use repetition to indicate severity.
<deryck> Morning, all.
<jml> stub: I disagree. We should use ANSI colors to indicate severity.
<stub> --log-file=debug:/var/tmp/log.html --log-format=html
<stub> <blink>No handlers could be found for loggNo handlers could be found for logger "librarian"No handlers could be found for logger "librarian"er "librarian"</blink>
<wgrant> jml: Critical errors can blink!
<wgrant> Damn, I was beaten.
<deryck> allenap, morning.  Do you think we need a card on the kanban board for bug 650991?  Or does the current card cover it?
<_mup_> Bug #650991: Add getSubscriptionsForBug to IStructuralSubscriptionTarget <Launchpad Bugs:In Progress by allenap> <https://launchpad.net/bugs/650991>
<allenap> deryck: I've forgotten how I should model these things. So, that bug is going to end up having 2 or more branches. I've completed the first, am working on the second. Should I have a card for each branch or bug?
<deryck> allenap, I think generally we want a card for each branch.  Thinking being that the branch is the unit of work.
<allenap> deryck: Okay, I'll make it so.
<jml> I'm going to gently ambiate feelings of warm encouragement about fixing the librarian's bad failure mode
<deryck> allenap, thanks!  Just trying to get us conscious about moving work forward clearly.
<deryck> allenap, you can use the incremental flag as you land these and just do qa on the final branch/card that closed the bug, though.
<deryck> so the other cards can land and flow straight into done-done.
<allenap> deryck: Okay, cool.
<adeuring> deryck: could you please run an EXPLAIN ANALYSE for this query on staging: https://pastebin.canonical.com/37832/ ?
<bigjools> jelmer: congrats on the new buildd-manager code, it looks to be FREAKING ROCK :-)
<deryck> adeuring, sure.  Doing so now....
<adeuring> thanks!
<jml> wuuu
<deryck> wow, that's a query, adeuring :-)
<adeuring> ;)
<jml> bigjools: that's in stable now?
<bigjools> jml: it's gone live
<bigjools> db-stable I think
 * wgrant watches build farm latency drop to zero.
<jml> bigjools: ahh, ok.
<jml> bigjools: just thinking about merging it into the twisted work
<wgrant> Logtails updating a couple of times a minute... I approve.
<noodles775> Niice
<wgrant> better than every 20 :)
<bigjools> :)
<bigjools> jml: yes, I'd merge it
<bigjools> jml: although thinking about it, I think we already have it
<bigjools> it landed a while ago
<jml> bigjools: yeah, but we've been developing from devel/stable, not db-devel
<jml> bigjools: which revision is jelmer's change?
<wgrant> It shouldn't be in db-
<jml> or what branch...
<bigjools> good point well made
<wgrant> 11566 or so?
 * wgrant checks.
 * bigjools is busy rescuing the librarian
<wgrant> jml: 11566
<wgrant> devel
<jml> wgrant: you know, that's just a little eerie.
<jml> wgrant: but thank you.
<bigjools> there was another branch
<wgrant> Oh, right, 11579
<wgrant> That fixes recipe builds.
<bigjools> lifeless: ping
<bigjools> optimistic ping....
<wgrant> It's 1am...
<bigjools> they're on DST already?
<wgrant> Last Sunday.
<bigjools> huh, weird :)
<wgrant> We're not until this weekend, though.
<wgrant> They are special.
<deryck> adeuring, it still hasn't completed.  I think I should kill it.
<bigjools> and another month for us
<adeuring> deryck: gahhh...
<bigjools> to go back that is
<bigjools> it's going to make my standups interesting with Steve
<adeuring> deryck: could you try this one: https://pastebin.canonical.com/37835/ ?
<deryck> adeuring, sure
<deryck> adeuring, still going.  I'll kill it now.
<adeuring> deryck: yeah, sure
<wgrant> bigjools: Why don't we run the upload processor every minute?
<bigjools> which upload processor?
<wgrant> The one behind popp.
<wgrant> +y
<bigjools> hysterical raisins
<wgrant> I presume we now run the buildd-manager one every minute.
<bigjools> 30 seconds actually
<wgrant> Even better.
<wgrant> (how?)
<jml> dear pycon, please stop calling for papers when I am phenomenally busy on non-programming stuff, love jml
<bigjools> wgrant: oh I lie, it's every 5
<bigjools> minutes
<wgrant> bigjools: Uh, really?
<bigjools> it should be every minute... jelmer?
<wgrant> That's going to break date_finished pretty badly.
<wgrant> Although not as badly as it was broken before, I guess.
<jelmer> bigjools: the upload processor runs every 5 minutes
<jml> just to confirm...
<jml> IBuilder.active = True does not imply that there's an active build on that builder
<jml> ?
<wgrant> active just controls whether it's shown on /builders.
<wgrant> So, no, it's unrelated to whether there's a build on it.
<wgrant> Yes, we like confusing names.
<jml> wgrant: ta
<wgrant> bigjools: Um.
<wgrant> bigjools: You didn't run that SQL, did you?
<wgrant> That's rather overbroad :/
<bigjools> I did
<wgrant> bigjools: I think you just deleted most of hardy.
<bigjools> wgrant: huh?
<bigjools> wgrant: actually I see what you mean
<bigjools> arse
<wgrant> bigjools: You found all binaries in intrepid that weren't published or pending, and deleted their files.
<wgrant> Most of those are inherited from dapper.
<wgrant> Er.
<wgrant> Hardy.
<wgrant> And will be in jaunty and co too.
<wgrant> We need to move this expiration to something more like the librarian GC.
<wgrant> (excluding active records, rather than trying to select inactive ones)
<bigjools> yes, reference counting would be nce
<bigjools> nice
<wgrant> I forget how librariangc does it.
<wgrant> But it's reasonably not too bad.
<wgrant> But anyway, I hope the GC hasn't run yet, or we are screwed if we want to be able to initialise natty.
<bigjools> it has not
<bac> abentley, adeuring, allenap , bac, danilo, sinzui, deryck, EdwinGrubbs, flacoste, gary, gmb, henninge, jelmer, jtv, bigjools, leonard, mars, noodles775
<bac> : reviewers meeting starting soonish
<bigjools> bac: I will be late
<bigjools> sorry
<mars> bac, gary is out today, he sends his apologies
<maxb> My email "[Launchpad-dev] RFC: Cleaning Launchpad Lucid PPA" is lonely. Anyone feel like replying? :-)
<jml> maxb: I feel totally unqualified to reply in any way other than "Gosh I'm glad someone else is taking care of this"
<maxb> heh
<salgado> sinzui, we seem to have some spurious TeamParticipation entries which might be caused by those changes Edwin did to the code which maintains that table: https://bugs.edge.launchpad.net/launchpad-foundations/+bug/597208 (last comment is the relevant one)
<_mup_> Bug #597208: Run cronscripts/check-teamparticipation.py on production and make its output more visible <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/597208>
<sinzui> :(
<sinzui> salgado, there are all merged teams. I think they were merged using the delete action which is a special form of merge
<salgado> sinzui, they're not all merged. for instance, https://edge.launchpad.net/~ubuntuone-users is on that list
<sinzui> salgado, I delete mailing-list-beta-testers myself. This is a bug in the delete rules. I assumed something like this could not happen since delete is a subclass of merge where the destination team is ~registry
<salgado> oh, nm me
<salgado> I see that the entry is for another team that merged into ubuntuone-users
<sinzui> salgado, Do we have a script to clean up the mess that is in TeamParticipation?
<salgado> sinzui, nope
<gmb> Can someone remind me what I need to do to enable a feature flag in my dev environment? I.e. how do I get features.getFeatureFlag('malone.foo-bar.enabled') to return True?
<sinzui> okay, I will arrange a code fix and a cleanup
<wgrant> Can someone poke ISD about the login.launchpad.net issue that has been reported in #launchpad?
<wgrant> I can confirm; it seems fairly broken.
<deryck> gmb, I believe you're looking for noodles775 reply to the email thread "how to use feature flags".  And subsequent emails.
<deryck> gmb, unless you mean doing the db insert locally to enable the flag?
<deryck> If I'm understanding this right, not having used it myself.
<noodles775> gmb: http://pastebin.ubuntu.com/494656/ is what I'm using (just line 3).
<gmb> noodles775: Thanks.
<noodles775> wgrant: I've pinged the ISD guys.
<wgrant> noodles775: Thanks.
<flacoste> gmb: poolie landed a UI for this yesterday
<bdmurray> sinzui: the +subscriptions mp is ready for rereview now - https://code.edge.launchpad.net/~brian-murray/launchpad/limited-subscriptions-page/+merge/35177
<sinzui> bdmurray, salgado should go first
<salgado> bdmurray, sinzui, I've just started. :)
<bdmurray> sinzui: okay
<lifeless> bigjools: yo?
<lifeless> flacoste: For simpler rollouts I think qastaging is needed, but not edge gone.
<lifeless> flacoste: discuss.
<bigjools> lifeless: jeebus, it's what, 4am there?!
<lifeless> yes, early plane flight to sydney. brb
<gmb> I would like it noted that the fact that +subscribe is handled by BugTaskView instead of BugSubscriptionAddView (or similar) is a) odd and b) annoying.
<bigjools> lifeless: anyway unping
<bdmurray> I concur
<bdmurray> salgado: what bug didn't send you back to +subscriptions on clicking cancel?  it works for me
<salgado> bdmurray, I think I tried a couple different ones.  let me try again
<lifeless> bigjools: hah, ok
<salgado> bdmurray, indeed, reproduced with bug 13 and bug 4
<_mup_> Bug #13: empty signing rules lead to invalid checksums <Baz (deprecated):Fix Released by lifeless> <https://launchpad.net/bugs/13>
<_mup_> Bug #4: Importing finished po doesn't change progressbar <Launchpad Translations:Fix Released by carlos> <Ubuntu:Invalid> <https://launchpad.net/bugs/4>
<bdmurray> salgado: as name12?
<salgado> bdmurray, yes
<deryck> gmb, indeed, it's ridiculous.  And we're likely doing extra work for the regular view that we don't need.
<bdmurray> salgado: okay, thanks I'll poke at it some more
<gmb> deryck: Indeed. So, new bug to file, then :)
<deryck> gmb, yes, indeed.
<gmb> (I'll fix that before doing bug 651108
<_mup_> Bug #651108: Update the bug +subscribe view to include the options for bug_notification_level <story-better-bug-notification> <Launchpad Bugs:In Progress by gmb> <https://launchpad.net/bugs/651108>
<salgado> bdmurray, I see at http://bazaar.launchpad.net/~brian-murray/launchpad/limited-subscriptions-page/revision/11486 that it will redirect to the referrer when you hit the Continue button but not the Cancel link.  for the link you need to set cancel_url, IIRC
<bdmurray> salgado: http://bazaar.launchpad.net/~brian-murray/launchpad/limited-subscriptions-page/annotate/head%3A/lib/lp/bugs/templates/bug-subscription.pt the cancel href is set to the _return_url there
<bdmurray> salgado: so I'm not quite certain how that is happening for you.  Does the branch also require sinzui's approval?
<salgado> bdmurray, I think I know what's going on... ReturnToReferrerMixin must be mixed into a LaunchpadFormView, but you've mixed into a LaunchpadView
<salgado> bdmurray, does the Cancel link work for you?
<salgado> bdmurray, yes, it needs sinzui's approval as well
<bdmurray> salgado: yes and the test in lib/lp/registry/stories/person/xx-person-subscriptions.txt works too
<salgado> bdmurray, I thought that maybe I could have a plugin which was causing chromium to not send the referrer, but I see the same behaviour on epiphany, which has no extensions here
<salgado> bdmurray, the last rev on your branch is r11487, correct?
<bdmurray> salgado: I just pushed 11488 which fixed the Continue test in the previously mentioned test
<lifeless> see you on the flip side
<bigjools> jml: I thought of another thing we need to sort out in the async world of buildd-manager code - the log messages are going to look *weird* out of order, so they need vastly improving with more context :)
<jml> events!
<flacoste> gmb: who is the release manager for 10.10?
<gmb> flacoste: Edwin.
<flacoste> gmb: thanks! and hi!
<gmb> flacoste: Hi! Welcome back :)
<henninge> danilos: can have a look at this, please? http://paste.ubuntu.com/502711/
<danilos> henninge, I don't like the orange colour on the web page
<henninge> danilos: This error comes straight from gettextpo.
<henninge> :-P
<henninge> The difference is "msgid_plural"
<danilos> henninge, sounds like what jtv has seen recently with upgrade to maverick as well
<henninge> ah, I was expecting some upgrade in gettext
<danilos> henninge, we should probably normalize these into exceptions in pygettextpo and not worry about the text
<danilos> henninge, though, not sure how doable it is... where do you see this?
<henninge> in a pagetest
<danilos> henninge, locally or? I am assuming it's maverick?
<henninge> yes, locally on maverick
<henninge> http://paste.ubuntu.com/502712/
<henninge> error display in pagetests sucks
<henninge> I'll just add some ... to get the test passing on both maverick and older ...
<henninge> danilos: ^
<danilos> henninge, yeah, it sucks, though I've been fighting my test runner today as well
<danilos> henninge, it'd be very useful to try it out on both (you can run just a single test on ec2)
<henninge> danilos: I want a full run now, anyway.
<bigjools> henninge: it sucks when people do "print browser.contents" and then match with an ellipsis ... :(
<danilos> bigjools, oh, you should have seen most of our pagetests from back in the day then, you'd love it
<bigjools> danilos: dude, I work in Soyuz .... :)
<henninge> bigjools: I replaced it with "extract_text" in this instance ;-)
<bigjools> henninge: did you get the page fragment too? :)
<henninge> Oh, it was already just a tag being tested.
<henninge>   >>> for tag in find_tags_by_class(user_browser.contents, 'error'):
<henninge>   ...     print extract_text(tag)
<bigjools> heh :)
<jml> heh heh
<jml> lifeless: lounge?
<lifeless> yes
<lifeless> downloading my failed stream so i can try to fix the errors
<sinzui> jcsackett, you may be partly responsible for the sampledata conflict. Do you want to try to fix it my merging stable into db-devel, then submit the resolution to pqm?
<jcsackett> sinzui: actually, i just saw those errors, did a clean merge of devel and db-devel on my machine with resolution, and was about to ask you about it.
<sinzui> no
<sinzui> stable to db-devel
<sinzui> jcsackett, we have a step them ensure that db-devel will also merge into stable for CP and rollouts. The failures are saying we cannot do either
<jcsackett> sinzui: yeah, i follow that; just didn't realize which branch was involved. i'm pulling down stable now to merge--i suspect the resolution step will be the same.
<sinzui> jcsackett, pull db-devel, merge in production-stable, resolve, push, send to pqm
 * lifeless waves
<sinzui> jcsackett, remember that this is developer data, not test/app data so sending to to ec2 is pointless
<jcsackett> sinzui: got it. does using lp-land work for that, or is there some special invocation?
<abentley> jcsackett: you're not supposed to land database changes to devel/stable.  The one exception seems to be security.cfg
<abentley> jcsackett: In this case, you haven't changed the database schema, so you shouldn't have needed to change the sampledata.
<sinzui> jcsackett, bzr pqm-submit -m "[testfix][r=<review>][ui=none] Resolve conflicts."
<jcsackett> abentley: i was under the (errant) belief that referred only to schema changes (like adding columns); i had made a change for sample data to illustrate some cases per salgado's request.
<jcsackett> this won't happen again. sorry all.
<jml> jcsackett: sorry our process isn't simpler or at least more self-documenting
<sinzui> abentley, I am not sure jcsackett broke rules since his change was for engineers. The data is not used by the test runner
<abentley> sinzui: If there's not a rule, there definitely should be, because what just happened is what will always happen.
* flacoste changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 2 of 10.10 | PQM is open for business | firefighting: - | https:/â/âdev.launchpad.net/â | Get the code: https:/â/âdev.launchpad.net/âGetting
<jml> yay more rules
<jml> oh wait I mean boo.
<abentley> jml: simpler rules: "don't change anything in "database/" except security.cfg and current-dev" becomes "don't change anything in "database/" except security.cfg."
<jml> abentley: I like simpler.
<jcsackett> sinzui: okay, i have resolved conflict; you want to take a look at it beforehand?
<sinzui> sure
<jcsackett> sinzui: hm; diff looks ridiculous. fixing the merge error was just a case of deciding which block of blank lines to keep.
<jcsackett> sinzui: https://pastebin.canonical.com/37863/
<sinzui> r=me
<jcsackett> cool.
<jcsackett> submitted.
 * jcsackett hides in cave.
<jcsackett> should i update the wiki describing editing sampledata to include the fact that changes must be submitted to db-devel, not devel?
<abentley> jcsackett: please do.
<jcsackett> sinzui: https://pastebin.canonical.com/37865/
<cr3> hi folks, anyone happen to know where/how the "webservice" part of "${context/webservice}" is defined? I looked throughout interfaces and zcmls, but couldn't quite find where/how that attribute or method is defined.
<jcsackett> abentley, can you take a look at this? https://pastebin.canonical.com/37865/
<jcsackett> i gather that pqm rejected my merge b/c it found conflict markers, but there appear to be none in my branch or in a local checkout of db-devel if i merge my branch into it.
<jcsackett> (according to the same test).
<abentley> jcsackett: the rejection would have been an attempt to merge stable, not your branch, so that's the closest thing to try.
<cr3> nevermind folks, found it under lazr.restful stuff
<jcsackett> abentley: why would it be trying to merge stable if it's trying to merge my testfix?
<cr3> by the way, what does "LAZR" stand for? Launchpad And Zope REST?
<abentley> jcsackett: Oh, I thought you were referring to the original failure.
<jcsackett> abentley: no, this was a response to my testfix.
<jcsackett> i know what the conflict was in merging stable; that's what i resolved.
<jcsackett> was hoping error code in the paste might be more meaningful to someone else, and give me something to chase.
<abentley> jcsackett: What you pastebinned is not what PQM does if there's a merge conflict.
<bac> hi abentley, i used 'bzr lp-land' this morning and it sent my branch off to pqm even though i had uncommitted changes.  most of the other tools check for that, should lp-land too?
<abentley> jcsackett: That's a rule that's checking for unwanted database changes.
<jcsackett> abentley: dig. i'm confused since the error appears to be in make check_merge.
<abentley> jcsackett: We don't check for conflict markers, we check the status code of the merge command.
<jcsackett> abentley: ah, i see. the test i see when running make check_merge is test_no_conflict_markers, which is where i made the guess.
<abentley> jcsackett: this is checking that the outcome of the merge is reasonable.
<abentley> jcsackett: not checking whether the merge succeeded.
<abentley> jcsackett: Okay, maybe we *also* check for conflict markers, but those would be markers that got there because someone committed them.
<jcsackett> abentley: okay. so then, is my supposition that what is failing in the paste happens after pqm is merging the testfix into db-devel?
<jcsackett> abentley: i'm tryin to chase down the error so i can figure out what in the testfix is unpalatable and fix it.
<abentley> jcsackett: yes.  After the merge, it's running make check_merge
<jcsackett> so, theoretically, if i have a clean branch of db-devel, merge my testfix into it, and run make check_merge, if all is well locally i shouldn't be seeing that error?
<jcsackett> abentley^
<abentley> jcsackett: You should try doing the merge locally and then running "make check_merge" locally.
<abentley> jcsackett: yes.
<jcsackett> abentley: excellent. that's what i did, and the make check_merge passes locally.
<jcsackett> abentley: i suppose not 'excellent', as that removes the most obvious path for a fix.
<sinzui> jcsackett, sorry. I was in a meeting you are landing in db-devel: pqm-submit --submit-branch=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel
<sinzui> jcsackett, bzr before that command and -m "message" after that command
<abentley> jcsackett: okay, make sure your db-devel is up-to-date.
<sinzui> jcsackett, did you branch devel or db-devel as your base?
<jcsackett> sinzui: db-devel.
<abentley> bac: I guess that would make sense, to be in line with pqm-submit.
<sinzui> okay, then I think you are fine
<sinzui> jcsackett, if I gave you my bazaar aliases, then dbsubmit  does the pqm-submit --submit-branch=bzr+ssh://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel
<bac> abentley: yeah, it would be nice.  i just put us in [testfix] b/c i made a change to a failed test but then sent it off to PQM without commiting the change.  :(
<bac> abentley: i'll open a bug
<jcsackett> sinzui: thanks.
<jcsackett> abentley: thanks as well.
<jml> g'night all
<rockstar> Has the upload server for PPAs changed?  I can't ping upload.launchpad.net
<rockstar> Ugh, it's ppa.launchpad.net
<bryceh> in a configure.zcml, when should I make my classes class="lp.bugs.model.*" vs. class="canonical.launchpad.database" ?
<salgado> bryceh, always the former. canonical.launchpad.database is deprecated and at some point everything there will have been moved somewhere else
<bryceh> salgado, ok thanks
 * rockstar goes to find lunch
<mwhudson> what does 'dissolve cornflakes' mean as a commit message?
<thumper> :)
<thumper> I saw that too
<bac> hi thumper
<thumper> I think it was a merge conflict resolution
<thumper> hi bac
<bac> thumper: the branch i landed redesigned the a project's code page to show whether the project uses launchpad, and if it does not to show where the code is hosted
<thumper> bac: so what change the capitalisation?
<bac> thumper: part of that design was to add side portlets to the page to bring it into the 3.0 UI world
<bac> those statements went from in-line to being in a portlet
 * thumper is not happy
<thumper> who reviewed it?
<bac> thumper: salgado, allenap, sinzui, and mrevell
<bac> thumper: look at screenshots at http://people.canonical.com/~bac/code_usage/
<maxb> uhoh, we have code imports failing with NoWhoami again
<maxb> https://answers.edge.launchpad.net/launchpad-code/+question/127341
<thumper> bac: what about personal branches? distro branches?
<thumper> bac: the style of those will now be inconsistent?
<thumper> bac: also, I don't see the point of saying that branches will be public initially
<thumper> bac: no-one can make public branches private
<mwhudson> maxb: eek
<mwhudson> maxb: particularly as it's failed on each importd :/
<mwhudson> losa ping
<bac> thumper: look at curtis' last comment on https://code.edge.launchpad.net/~bac/launchpad/bug-643538-code/+merge/36377
<bac> thumper: the one from jml specifically asking for consistency across tabs for projects
<mbarnett> heya mwhudson
<mwhudson> mbarnett: has anything happened to the ~importd/.bazaar/bazaar.conf files on the import slaves recently?
 * thumper sighs
<thumper> bac: so... back to the consistency thing then
<thumper> bac: have the other branch listings been changed?
<bac> thumper: no
<maxb> mwhudson: Yes, I think *ALL* cscvs imports are currently failing, but only when the upstream repository has a new commit. And this is why the entire collection of CSCVS imports haven't migrated to failed already
 * thumper agrees with maxb
<mwhudson> maxb: this is strange, we definitely had them working at some point since the nowhoami behaviour got rolled out
<maxb> So why is this not affecting non-CSCVS imports? :-/
<thumper> maxb: all the others use a common base class
<thumper> maxb: which I think has been fixed for the no-whoami thingy
<mwhudson> no
<mwhudson> it's because they use a different api to create commits
<mwhudson> at least, i think
<mwhudson> create revisions rather
<thumper> mwhudson: there was a bzrlib bug where the method was ignoring the param
<mwhudson> thumper: ah
<thumper> mwhudson: so you still had to set BZR_EMAIL env
<maxb> This problem arose between 2010-09-08 and 2010-09-12
<thumper> mwhudson: also, about the incorrectly stacked distro branches
<thumper> mwhudson: we can fix it by running bzr reconfigure --unstacked on them
<thumper> mwhudson: I'm trying to avoid writing a "special" fixit script
<mwhudson> thumper: seems fair enough
<wallyworld___> morning
<thumper> wallyworld___: morning
<sinzui> thumper, I agree with you
<thumper> sinzui: which bit?
<thumper> abentley, rockstar, wallyworld___: standup?
<sinzui> thumper, I reported bugs on blueprint and malone when I saw project was changed when the feature was about specifcationtarget and bugtarget. branch collections/target must be the on on launchpad and behave like all launchpad
<wallyworld___> yep
<abentley> thumper: okie
<thumper> sinzui: I don't understand what you just said
<sinzui> thumper, no 2.0 designs
<sinzui> thumper, do not make IProduct an exception
<mbarnett> mwhudson: sorry, overly distracted over here with a db issue.
<mbarnett> mwhudson: will have to look at that in a few
<bac> thumper: i think sinzui is saying we'll update the other pages as soon as possible.  is that right curtis?
<sinzui> yes. If someone else does not report the bug I will
<sinzui> besides jml, will not end bridging-the-gap until his vision of consistent UI and clarity of message is met
<rockstar> wallyworld___, ping me when you're ready. :)
<wallyworld___> rockstar: do you want to talk now or a bit later? if later, i'll go grab a coffee and breakfast
<rockstar> wallyworld___, have breakfast first.  I can wait.
<wallyworld___> rockstar: i saw your message after i sent mine. i can talk now if you like. might be good to get it done
<rockstar> wallyworld___, if you're good to go, I am.
<wallyworld___> rockstar: skype?
<rockstar> wallyworld___, http://developer.yahoo.com/yui/3/io/
<james_w> rockstar: merged your bzr-builder branch, apologies for the delay
<james_w> while there I found a case where a bug was corrupting the text of recipes
<james_w> but there was in fact not enough checking in __str__ to catch the problem
<rockstar> james_w, ah!  Thank you for doing that.
<poolie> hi rockstar, james_w
<rockstar> Morning poolie.
<james_w> hi poolie
<james_w> https://code.edge.launchpad.net/~james-w/bzr-builder/fix-text-of-nest-parts/+merge/37076 if someone wants to review
 * rockstar walks dog
 * thumper afk for brief shopping
<james_w> erm, helps if I actually commit
<james_w> ok, third time lucks
<poolie> hi mars? happy to help with your feature flag test if i can
<james_w> https://code.edge.launchpad.net/~james-w/bzr-builder/fix-text-of-nest-parts/+merge/37080 if someone wants to review
<mars> poolie, sure: I would be glad for the help: https://code.edge.launchpad.net/~mars/launchpad/add-py25-lint
<mars> poolie, this test fails: bin/test canonical.launchpad -t profiling.txt
<mars> poolie, I have to run, but I can check back later
<poolie> k
#launchpad-dev 2010-09-30
<rockstar> Oh balls. jsbuild is icky.
<james_w> is this a known problem, or an artefact of building bzr-builder itself? https://launchpadlibrarian.net/56778044/buildlog.txt.gz
<mwhudson> Get:3 http://ppa.launchpad.net/dailydebs-team/bzr-builder/ubuntu/ maverick/main bzr-builder all 0.4+bzr104+0.0ubuntu45~maverick1 [32.7kB]
<rockstar> james_w, yeah, it looks like bzr-builder is still not updated on the buildds...
<rockstar> Le sigh.
<mwhudson> vs the normal:
<mwhudson> Get:1 http://archive.admin.canonical.com/ubuntu/ lucid-cat-lpbuildd/main bzr-builder 0.2+bzr78+0.0ubuntu44~0.IS.10.04 [25.9kB]
<mwhudson> rockstar: i think it's because the ppa being built for has bzr-builder in it
<james_w> that could well be it
<lifeless> mars: hi
<rockstar> mwhudson, I still think we need at least 0.3 on the builders themselves in order to use SAFE_INSTRUCTIONS.  Isn't that right james_w?
<james_w> I think so
<mwhudson> rockstar: well s/on the builders themselves/in the internal repo/
<mwhudson> rockstar: as it looks like it's installed for each build
<mwhudson> (it's not in the chroot)
<mwhudson> i'm assuming its invoked inside the chroot?
<rockstar> mwhudson, yeah, we haven't gotten that sorted out yet.  There's an open RT about it, but it hasn't been addressed yet.
<thumper> wallyworld___: ping
<wallyworld___> thumper: here
<thumper> wallyworld___: skype?
<poolie> jam1: how did you got with lp-serve?
<mwhudson> hmm
<mwhudson> when i try to authenticate against login.launchpad.net from a locally running webapp, https://login.launchpad.net/+openid seems to be served as text/plain
<mwhudson> that's a bit off
<mwhudson> *odd
<wgrant> mwhudson: SSO has been playing up a bit this morning and last night.
<wgrant> It seems to be reasonably happy.
<SpamapS> I'm curious, how is launchpad librarian's backend handled?
<wgrant> SpamapS: What do you want to know about it?
<wgrant> AIUI it's just on a machine with lots of disk.
<SpamapS> I just get timeouts quite a bit.
<SpamapS> Wondering why.
<wgrant> From the librarian?
<SpamapS> yeah
<wgrant> That's not something I've seen before.
<SpamapS> I'm not alone, other bug triagers have experienced similar things
<wgrant> Just now?
<SpamapS> wgrant: no, they seem to come in spurts.
<SpamapS> wgrant: the next time I experience it, I"ll bring it up more promptly in here
<stub> SpamapS: If you have a launchpadlibrarian.net URL, then you are talking to the Librarian. If you have a launchpad.net URL, you are being proxied via Launchpad for security reasons and the timeout is happening there (open bug, feature landed that should fix it, but still waiting to be tested)
<SpamapS> stub: very likely it was always on private bugs. Good to know its been noticed. :)
<SpamapS> mostly just curious as I imagine the librarian has a lot of files.
<wgrant> Not too many. We're not even at ID 57000000, and a lot of those have since been deleted.
<persia> wgrant, Depends on your scale of reference.  I don't think I have any machines with millions of files :)
<stub> Its just a big tree of files, similar layout to any squid cache
<stub> metadata about the files is all in PostgreSQL
<adeuring> good morning
<StevenK> wgrant: Have you seen anything like http://paste.ubuntu.com/503073/ ?
<mrevell> Hey
<wgrant> StevenK: No, but others have. Apparently a 'make clean' fixes it.
<StevenK> wgrant: Interestingly, 'make clean; make' doesn't fix it.
<wgrant> Odd.
<bigjools> good morning
<wgrant> Morning.
<wgrant> Did the deletion work?
<noodles775> StevenK: did you try deleting relevant direcotries from /var/tmp/
<noodles775> (and ensuring there are no librarian processes hanging around)
<bigjools> wgrant: seems like it recovered some yes
<wgrant> bigjools: But not half the archive? Excellent :)
<StevenK> noodles775: There's no python processes related, and deleting everything from /var/tmp has no effect
<noodles775> hrm.
<wgrant> make clean fixed it for gmb last night.
<wgrant> I wonder why it didn't work here.
<wgrant> How is buildd-manager looking? The queues have been disappointingly small today.
<jelmer> wgrant: I seems to be doing alright so far.
<wgrant> I'm not sure whether the tiny queues are because it's just so quick now.
<wgrant> Or if they just mean that it hasn't really had much thrown at it.
<StevenK> Wait until the first autosyncer for natty
<wgrant> Heh.
<bigjools> wgrant: I see ~280M saved
<wgrant> bigjools: s/M/G/?
<bigjools> wgrant, jelmer: the falloff rate for lots of queued jobs (we get a spike of ~180 jobs each night) is much faster now
<bigjools> wgrant: it might be G, I think the graph is lying to me
<wgrant> bigjools: Average build time should also have dropped by approximately an awful lot.
<bigjools> yes
<bigjools> it has
<jml> ooh. do we have a graph for that too?
<bigjools> I'll dig up stats later
<bigjools> somewhere yes, build lag <blah>
<wgrant> I will be interested to see all these pretty graphs in a couple of months.
<bigjools> heh
<jml> A someday/maybe of mine is to put all of the ones that are relevant to actually administrating Launchpad into Launchpad
<jml> rather than the ones that are merely stats-gathering / popularity metrics
<bigjools> is administrating some strange Australian word?
<StevenK> Like 'setuping'
<jml> bigjools: I've heard it often before, so perhaps yes.
<poolie> 'administer launchpad' sounds a bit medical
<poolie> perhaps appropirate
<jml> bigjools: I guess I should say "ministering unto" now that I'm in the Old World
<poolie> :)
<bigjools> jml: it must have had some sort of attraction for you to come here? :)
<wgrant> "administrating" is valid, but rather rare nowadays...
<bigjools> it's not even in my dictionary
<wgrant> Well, I may then have to make disparaging remarks about your dictionary.
<jml> The Shorter doesn't have an entry for it, but it doesn't for many -ing words.
<bigjools> http://dictionary.cambridge.org/spellcheck/british/?q=administrating
<wgrant> Some sources seem to say that "administrate" was incorrectly formed from "administration", but others say that that is a common misconception.
 * wgrant gives up.
<jml> Cambridge? Bah. What would that upstart little campus know about the English language!
<bigjools> administrate is not there either :)
<jml> I have to go out. Back in a bit.
<bigjools> jml: quickly, is your b-m branch up to date?
<poolie> losa ping?
<mthaddon> poolie: hi
<poolie> hi tom, could you help me briefly to validate the flag control panel?
<poolie> <poolie> on https://edge.launchpad.net/+feature-rules
<poolie> <poolie> please add a line to the end:
<poolie> <poolie> "test_rule test_scope 0 on"
<poolie> <poolie> without the quotes
<mthaddon> as a new line?
<poolie> yes
<mthaddon> ok, done
<poolie> no problems?
<poolie> then delete it again, and we're done
<poolie> thanks
<poolie> you should now be able to use this to change feature flags, without needing raw sql
<mthaddon> ok, done
<wgrant> Sometimes we cannot build packages on Launchpad, because the build-server
<wgrant> runs out of memory. We need at least 5-6GB Ram for more-less normal
<wgrant> compilation.
<wgrant> ^^ I am scared
<jelmer> wgrant: what package is that?
<wgrant> jelmer: yade (see launchpad-users)
<wgrant> noodles775: Any progress on the log parser front?
<jml> hello
<jml> bigjools: yes.
<bigjools> jml: I'll attack it more later today
<jml> bigjools: cool.
<jml> bigjools: my plan of attack for buildd-slavescanner.txt was to make a branch that killed it that would work w/ both our new branch & trunk
<jml> bigjools: but I got fed up with the twisted/testtools thing.
<bigjools> jml: yes, that's a pain.  Did you say you could fix that?
<jml> bigjools: Circumstances permitting, yes.
<jml> bigjools: unfortunately, I haven't really had any time to hack since I got back.
<bigjools> jml: me neither
<bigjools> that will change this afternoon
<jml> bigjools: I'm having a night in Friday, so maybe I'll get it done then.
<bigjools> jml: BTW you'd think that my change to lp_sitecustomize.py would rarely cause a conflict - guess what.... !
<jml> :(
<bigjools> easy to fix, I just thought it was funny
<jml> yeah.
<lifeless> jml: I can has review? https://code.edge.launchpad.net/~lifeless/launchpad/bug-627701/+merge/37094
<jml> lifeless: sure. looking now.
<lifeless> jml: if its within cooee, could you just tweak and land; its a critical patch
<lifeless> jml: I've now been up for 23 hours, so gnight ;)
<jml> lifeless: g'night
<bigjools> jml: I'd debugging that adaptation error we saw in the slave manager test, if you remember it?
<jml> bigjools: I remember the fact of it, but not much else.
<bigjools> jml: it's something that the @write_transaction is doing.  BuildQueue.job gets nulled out :/
<bigjools> if I muck about with cache invalidation it works
<jml> bigjools: ahh right.
<bigjools> so I'm rather confused as to htf is does that
<jml> a good place to start might be to do a timeline
<jml> (or print a bunch of stuff, that always helps)
<bigjools> what does "_get_sqlobject_store().reset()" do
<jml> don't know. is it a storm store?
<bigjools> yes
<bigjools> oh, nm
<bigjools> I thought that was screwing it but it's not
<bigjools> jml: there's some *weird* stuff happening.  Look at this diff: http://pastebin.ubuntu.com/503224/
<jml> bigjools: I see it.
<bigjools> see the second print I added?
<jml> indeed.
<bigjools> when that's added, the code works, if I comment it out, I get the adaptation error
<bigjools> double you tee eff
<jml> that sounds transactional.
<bigjools> yes
<bigjools> cache problems
<bigjools> see what's in the finally?
<bigjools> I don't know why that's needed
<bigjools> I suspect it's fucking with things
<jml> bigjools: perhaps there are tests for sqlbase.py that explain why.
<bigjools> darn, stub's gone
<bigjools> right, if I comment out the reset() it also works
<bigjools> perhaps the answer will present itself over lunch
<jml> yeah
<jml> another approach might be to make a minimal test that reproduces the problem... slowly cutting the extraneous crap away
<sinzui> mrevell, I just remove users from the list in bounce/out-of-office cases. suspending is very hard to undo
<sinzui> actually, now that the user is suspended, it is not possible to remove the user from the list of members :)
<mrevell> sinzui: Damn. Okay, thanks, I was thinking that the problem would apply generally, hence the suspension. How do I remove someone from a mailing list?
<sinzui> when he is not suspended, you visit his membership page from the members list of the team. You can remove him or make him an admin.
 * sinzui looks for example
<sinzui> https://edge.launchpad.net/~launchpad-users/+member/matthew.revell
<mrevell> Ah yes, thanks sinzui
<sinzui> mrevell, because launchpad-users is a mega team, I usually hack the url instead of listing every member https://edge.launchpad.net/~launchpad-users/+members
<mrevell> So, I think I see what you mean about it being hard to unsusepend him.
<mrevell> doh
<sinzui> jml: unification requires me to be very awake. I will think about both questions, neither are easy, though I personally think both are desirable
<jml> sinzui: agreed. remember, we don't care about merging the namespaces yet, just stopping more clashes.
<sinzui> right. teams with project names really confuse me when I am helping users who do not know what either is
<mars> abentley, ping, have you seen spurious test suite failures like this before?: https://pastebin.canonical.com/37924/
<abentley> mars: I don't think so.
<bigjools> gary_poster: hi, can I bother you with some questions about transactions and  caches and some weird behaviour I'm seeing?
<StevenK> mars: I have -- the Hudson instance reguarly has that failure
<gary_poster> gmb or other malone person: help request: starting on https://bugs.edge.launchpad.net/ubuntu/+source/apport/+bug/628755 , I click on "Also affects project" but then only see Apport on https://bugs.edge.launchpad.net/ubuntu/+source/apport/+bug/628755/+choose-affected-product
<_mup_> Bug #628755: Impossible to log in in Launchpad using apport from a tty console with w3m <iso-testing> <Launchpad Foundations:Triaged> <apport (Ubuntu):Invalid> <w3m (Ubuntu):Confirmed> <w3m (Debian):Unknown> <https://launchpad.net/bugs/628755>
<_mup_> Bug #628755: Impossible to log in in Launchpad using apport from a tty console with w3m <iso-testing> <Launchpad Foundations:Triaged> <apport (Ubuntu):Invalid> <w3m (Ubuntu):Confirmed> <w3m (Debian):Unknown> <https://launchpad.net/bugs/628755>
<wgrant> gary_poster: "Choose another project"
<gary_poster> bigjools: on call but will ping
<bigjools> gary_poster: ok, thanks
<gary_poster> wgrant: ah, how weird.  thanks
<wgrant> gary_poster: Very strange UI there, yes..
<mars> abentley, benji has seen that failure three times in a row on EC2 with this branch: https://code.edge.launchpad.net/~benji/launchpad/wadl-refactoring/+merge/36452
<mars> abentley, it certainly looks spurious... unless the test starts up an external process for testing the API or something
<abentley> mars: The worker could well be an external process.
<bigjools> stub: I've got a problem with the @write_transaction decorator
<bigjools> have you got time to help or is it too late there?
<stub> That some twisted thingy?
<bigjools> no
<bigjools> it was in the librarian module
<bigjools> but I moved it recently
<stub> Librarian counts as 'some twisted thingy' :)
<bigjools> anyway check out this diff http://pastebin.ubuntu.com/503278/
<bigjools> the decorator lives in lp.services.database
<bigjools> it calls the code in the diff after the decorated function finishes
<bigjools> the Librarian is more than twisted ...
<bigjools> stub: the problem I am seeing is in some tests for the branch jml and I are working on for a fully async  buildd-manager
<bigjools> the decorated function returns a buildqueue vaguely atomically with that decorator
<bigjools> it's supposed to have a "job" property, but that call to reset the store nullifies the property
<bigjools> I can't for the life of me work out why
<bigjools> if I comment out the reset, it DTRT
<bigjools> also weirdly if I uncomment that "print ret.job" it also fixes it
<bigjools> so I suspect some dodgy cache interaction here
<stub> bigjools: I'd agree. Are you sure of the order your stacked decorators are being run? You can confirm the write_transaction decorator is committing before the reset_store_decorator is resetting the store?
<stub> Not that I understand why you would want to do that...
<bigjools> stub: I went through in pdb and it commit()s before the reset
<bigjools> I've no idea why the reset is needed
<bigjools> and how that could affect this
<stub> Well, it is resetting the SQLObject store (likely the Master), so it is old SQLObject legacy code.
<stub> reset_store seems to be there to support changing connection settings, such as the database user you are connected as.
<bigjools> is it still really needed?
<stub> I don't see why.
<stub> I don't see why it was ever needed, but I never really liked this pattern anyway - the decorators always seemed to be a hack to support code written for autocommit system to sort of work with transactional systems.
<bigjools> well, I am using it so that I get an automatic retry
<stub> I'm not sure if there is some subtlety I'm not thinking of, or if the @reset_stores are there to work around some early Storm issue
<bigjools> I'm hoping that gary_poster can weigh in when he's off the phone :)
<gary_poster> really still on the phone ;-)
<stub> bigjools: Suggest you read the docstring of Store.reset and weep
<stub> bigjools: Looks like you have to throw away your objects after the .reset() is called
<bigjools> :/
<bigjools> I wish that was an option
<stub> I still don't see why you want the reset. Write another decorator that doesn't reset.
<stub> The decorators are broken anyway as they only reset one of the Stores - not all of them.
<bigjools> awesome
<stub> read_transaction should use transaction.doom() too, which wouldn't have existed when it was written, to ensure that nothing in func() commits.
<bigjools> weep
<stub> That one isn't a bug, but would be additional protection
<allenap> gmb, anyone: Do you know why the SourceForge bug tracker is disabled?
<gmb> allenap: Because we can't sync with it.
<gmb> So it was just chewing cycles and failing.
<allenap> gmb: Did that change recently?
<gmb> allenap: Nope, ages ago. The problem is that the SF templates changed but our SF ExternalBugTracker screen scrapes.
<gmb> Hence, boom.
<gmb> But we haven't been able to assign anyone to fix it.
<bigjools> stub: ok cheers, I'll mull this one over
<allenap> gmb: Gah. Also, there are lots of registered bug trackers with http://sourceforge.net/tracker/?group_id=336232&atid=1408830 like urls. I thought those would have been prevented.
<allenap> Or maybe we don't de-dupe those.
<mars> flacoste, ping
<flacoste> hi mars
<gmb> allenap: I have no idea how we deal with those (Well, badly, apparently) but I haven't looked at SF for > 18 months, I think.
<allenap> gmb: Okay.
<allenap> gmb: And ta.
<gary_poster> bigjools: off call.  can I still be of help, or did stub already dash your hopes and dreams sufficiently?
<bigjools> gary_poster: he largely did, yes :)
<gary_poster> :-) ok
<bigjools> gary_poster: the pertinent question was why is the write_transaction decorator resetting the store after committing
<bigjools> it's screwing with my partial commit, basically
<gary_poster> and the answer was something to the effect of "because that's how things are done with Storm/our DB"?
<bigjools> gary_poster: neither of us knows
<gary_poster> oh
<bigjools> could be an sqlobject throwback
<bigjools> the effect of doing it is that all my in-memory db objects are suddenly invalid
<gary_poster> I know that I've talked to Francis about this before--ZODB keeps objects around after commits, and AIUI Landscape actually does too
<gary_poster> I believe we don't because of paranoia
<gary_poster> but that's something from well before me being around
<bigjools> yeah
<gary_poster> stub, does that ring a bell, that we reset on commits because of paranoia, and Landscape does not?
<gary_poster> I suspect to change that, we'd have to do a big honking audit and see what the implications are and blah blah blah
<bigjools> gary_poster: it's only the write
<bigjools> gary_poster: it's only the write_transaction decorator
<bigjools> irc fail
<bigjools> which is used only in my app and the librarian AFAICT
<gary_poster> the read transaction decorator doesn't toss everything out at the beginning?  I think that's our policy for web requests, so it ought to be the story for other code too.  I don't know the story for those decorators, but what stub says above about transaction.doom sounds right.
<stub> gary_poster: It might be a paranoia thing, but I don't know if it actually helps at all.
<stub> gary_poster: It might be an attempt to ensure that any objects that leak outside of the transaction are useless and can't be used to accidently start a new transaction
<gary_poster> stub, do we have invalidations set up for Storm across connections?
<stub> eg. access a stale attribute on an object and a new transaction is started
<gary_poster> that's the kind of thing that would be unncessary with the current set up
<stub> no, we only do that in the appserver. We have lots of code that relies on objects being available across transactions
<stub> jml, spiv or jamesh might know the history of why the reset is there.
<jml> I don't.
<jml> We used to have something similar for the authserver (RIP)
<gary_poster> but, I mean, a changed object committed in thread/connection X will cause that object to be flushed and reloaded in subsequent thread/connection Y, yeah, stub?
 * gary_poster about to go on another call
<jml> perhaps it is meant to be used with threads. bigjools certainly isn't using threads yet.
<gary_poster> subsequent transaction in thread/connection Y I mean
<gary_poster> yes, the policy is for threads
<bigjools> that'd make a lot more sense
<stub> jml: These decorators would be those same authserver decorators
<jml> stub: ahh, ok :)
<jml> stub: then yeah, we were doing @defer_to_thread; @write_transaction
<bigjools> jml: what's the right way of re-raising an exception as a Failure?
<jml> bigjools: depending on exactly what you mean: try: thing_that_raises(); except: return Failure()
<bigjools> ah that was it
<jml> bigjools: alternatively, just use maybeDeferred
<jml> return maybeDeferred(thing_that_raises)
<bigjools> jml: the problem is in the startBuild code, it raises from verifyBuildRequest
<jml> bigjools: ahh ok.
<bigjools> I don't want to return
<bigjools> jml: see the _dispatchBuildCandidate we wrote
<bigjools> the failure.trap does bugger all for CannotBuild which happens immediately :)
 * jml depresses his mental clutch and swiftly changes gears
<jml> bigjools: yeah,  I'd change this line:
<jml>         d = self.startBuild(candidate, logger)
<jml> to:
<jml>         d = defer.maybeDeferred(self.startBuild, candidate, logger)
<bigjools> right
<bigjools> ok that's more like it - now to work out how we buggered the logic elsewhere :)
<jamesh> gary_poster: some of the big hammer style reset logic probably traces its roots back to when the code was using sqlobject/sqlos
<gary_poster> jamesh: ah ok, thanks.  so, we ought to consider removing the hammer and see if it buys us any performance wins, then, in your opinion?
<jamesh> sqlos's transaction handling was particularly busted, to the point where it would only join a connection to the transaction the first time.  So tearing things down completely was necessary to make the second transaction in the thread work
<gary_poster> bleh
<jamesh> there might be other code that depends on it, but Storm itself shouldn't need that kind of thing.
<jamesh> sqlobject on its own wasn't so bad, but sqlobject+sqlos was a mess.
<gary_poster> right, the other code is what I was afraid of generally, since I knew Landscape was keeping the objects around
<jamesh> like Storm, sqlobject had its own connection wrappers and did some house keeping on commit or rollback.
<jamesh> sqlos tried to get sqlobject to run on top of a zope.rdb connection, and then try to make sure the house keeping occurred when the connection got committed or rolled back behind sqlobject's back
<jamesh> it didn't always get things right.
<jamesh> The Storm zope integration code does things right, and the Storm level abstraction is registered with the transaction manager
<gary_poster> Right, cool, jamesh.  If ever I want to muddle around in the code, do you happen to know where the code is in Storm to invalidate changed objects on transaction boundaries?
<bigjools> jml: Total: 32 tests, 0 failures, 0 errors
<jml> bigjools: woot.
<bigjools> I am surprised
<jml> bigjools: this test_manager?
<bigjools> yes
<bigjools> all the FakeMethod crap is still there, we can do it properly now
<jml> I'm surprised too :)
<bigjools> and I can simply remove TestRecordingSlave
<jml> what about RecordingSlave?
<jml> can you remove that?
<bigjools> yup
<bigjools> it's not used in that branch at all
<jml> \m/>.<\m/
 * bigjools does a little dance
<jml> bigjools: I can cast my eye over the code (although maybe not today)
<jml> bigjools: http://paste.ubuntu.com/503374/ has all of the other stuff that I still had down as to-do.
<bigjools> ok, I'll take a butchers
<jml> not a builders
<jml> English slang is very confusing.
<bigjools> s/English/Cockney/
<malaria> Hi everyone, I would like to discuss https://bugs.launchpad.net/rosetta/+bug/608631 and the attached patch
<_mup_> Bug #608631: Visual tag to represent narrow non-breaking spaces <diacritic:Invalid> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/608631>
<malaria> danilos, if you are here?
<danilos> malaria, hi, I've got to finish something and then I can help out... is something like 30 mins ok?
<malaria> danilos: no problem, I can wait
<danilos> malaria, thanks :)
<bigjools> g'night folks
<jml> g'night all.
<danilos> malaria, hi, sorry, it took longer than I expected
<malaria> danilos: no problem, I ran some test in the mean time
<danilos> malaria, basically, the main issue is that you've got to provide an executable test
<malaria> danilos: There isn't already a test for other tags? (so something easy to modify)
<danilos> malaria, even though the doctest you updated looks just like documentation, you can run it with "./bin/test -cvv -m lp.translations -t browser-helpers.txt"
<danilos> malaria, oh, yes, there is, it's the same file you updated :) also, I am not sure of the name "[nbthin]" (actually, I am sure that we can come up with a better name :)
<malaria> ok for the test
<malaria> danilos: about the name, do you have a idea?
<malaria> the relevant name should be [nnbsp], but it's actually too close to [nbsp]
<danilos> malaria, I was going to ask you the same thing - I'd say 'thinspace' but this is a nb variant
<malaria> danilos: the html 'shortcut' for the thin space is &thinsp;
<danilos> malaria, 'nbthinspace' is too much to type imo, so how big of an issue is typing this out?
<malaria> [nbthinsp] seems too long for me too
<danilos> malaria, right, and there's no &nbthinsp; character reference?
<malaria> danilos: no
<danilos> malaria, yeah
<malaria> danilos: does [nbthin] really sounds clumsy?
<danilos> malaria, it really sounds weird to me, but I guess we can also ask a few other people as well
<EdwinGrubbs> abentley: Have you encountered this problem writing tests for cron scripts? The cron script creates a new entry in the ScriptActivity table, but between each test method, the sequences are reset to the original value, since it believes that it has rolled back any changes to the tables.
<danilos> malaria, i.e. you can get a reviewer to think about it so it's not a blocker for going into review
<malaria> danilos: of course, the best would be to have a localised version of each tag (ie [fine] in French) but it can't be done right now
<abentley> EdwinGrubbs: no, I haven't noticed problems like that.
<danilos> malaria, right, we'll get it sometime in the future and then the problem won't be so bad
<danilos> malaria, anyway, I don't think we should spend sleepless night on this
<abentley> EdwinGrubbs: I assume it hasn't actually rolled back the changes?  What changes?
<danilos> malaria, how familiar are you with our submission/review process?
<malaria> danilos: I'm an absolute newbie :-)
<danilos> malaria, heh, ok, so there's also https://dev.launchpad.net/PatchSubmission for some documentation
<EdwinGrubbs> abentley: the most important change is the new row inserted into the ScriptActivity table. The next test method that runs tries to insert another row, but since the sequence has been reset, it collides with the previously added primary key.
<malaria> danilos: yes, I had a look to it already
<danilos> malaria, basically, you'll have to add some tests for what you are adding, sign a contributor agreement and then you are ready to go if you ask me :)
<danilos> malaria, cool, do you need any help with that?
<malaria> danilos: I have to look the test stuff closer
<malaria> danilos: I will ask here if I need some advices
<abentley> EdwinGrubbs: I actually haven't had any dealings with the ScriptActivity table.
<malaria> danilos: anyway, can you have a look at this? http://malaria.perso.sfr.fr/fines/rosetta_nbthin_test.png
<danilos> malaria, right, sounds good
<malaria> danilos: it's from a test (patched version of course)
<danilos> malaria, yep, does the +filter page fail to "escape" them?
<malaria> danilos: even if those char are unlikely to be the last of a string, there seems to be a bug in this case
<malaria> danilos: no, escaped tags seem to just work
<danilos> malaria, hum, interesting... it would be nice to demonstrate this with a test (that fails)
<malaria> danilos: ok, I will have a look
<malaria> danilos: but I think this is an other issue (not a regression because of the patch I mean) and this situation should not happen in "real life"
<malaria> (ie. last char is nbsp or nnbsp)
<danilos> malaria, yeah, it's unrelated to this, but would still be nice to fix
<malaria> danilos: ok
<danilos> malaria, I don't even think it would be that unlikely (for example, with string composition, you may often want nbsp at the end of one string)
<danilos> malaria, but if it's really a problem, please file a separate bug about it and don't work on it right now :)
<malaria> danilos: ok :-)
<danilos> malaria, (just to keep things simpler)
<thumper> morning
<sinzui> thumper, https://blueprints.edge.launchpad.net/~launchpad/+specworkload
<rockstar> abentley, wanna chat?
<abentley> rockstar: sure.
<rockstar> abentley, I'll call you.
<lifeless> jml: so did you have a review?
<wallyworld> morning
<jml> lifeless: yes. I did it.
<jml> lifeless: waiting for your reply.
<mars> morning wallyworld
<jml> but I must sleep soon
<wallyworld> hi mars
<lifeless> jml: I can't see it on the review page... how odd
<lifeless> ah now it works
<rockstar> wallyworld, thumper, standup?
<wallyworld> yep. then coffee :-)
<jml> wallyworld: ahh, classic mistake
<rockstar> wallyworld, not sure how long it takes you to get coffee, but you could gamble on when you think thumper will be here for the standup.
 * thumper is here
<thumper> do it
<thumper> do it now
<lifeless> getFeatureFlag does not define raising as part of its contract
<wallyworld> jml: well, i am the eternal optimist. i also think hally berry will return ny calls one day too :-)
<jml> lifeless: so why the finally: at all?
<lifeless> jml: but if it did raise the if timeout_str code path would not run
<lifeless> I think you have misread the code
<jml> lifeless: quite right.
<jml> lifeless: so why the finally: at all?
<lifeless> it restores the reentrancy check disabling feature flags setting the timeout
<rockstar> wallyworld, I don't see you on skype.
<wallyworld> rockstar: skype is running and i'm logged in and all that
<jml> lifeless: yeah, I get that, but not why it's in a finally, if getFeatureFlag does not define raising as part of its contract
<lifeless> jml: because ctrl-C
<jml> lifeless: ok
<lifeless> jml: etc, defensive programming
<jml> lifeless: what about my other review point?
<lifeless> "I'll add some more to the prose to point folk at feature flags info.
<lifeless> "
<jml> lifeless: ta
<lifeless> specifically
<lifeless> -periods.
<lifeless> +periods. For more information on feature flags see lp.esrvices.features.
<jml> fix the typo & you're laughing
<lifeless> that was a test ;P
<jml> I am going to sleep, perchance to watch several episodes of The Wire
<lifeless> enjoy, please vote on the form on your way through.
<jml> already done
<sinzui> gary_poster, ping
<gary_poster> sinzui: five min
<lifeless> jml: thank you!
<mars> how long does it take for a dput package to show up in the team PPA?
<mwhudson> mars: depends on the ppa build queue
<mars> mwhudson, any place I can look?  LP ate my upload yesterday - I would like to know if it even got through :(
<mwhudson> mars: oh, a day or so is way longer than it should be
<mars> hehe
<mwhudson> mars: did you get an 'accepted' mail?
<mars> I just uploaded it now.  An no, I did not get any mail
<mwhudson> you should get that within 5 minutes
<gary_poster> sinzui: pong
<mwhudson> it's possible that if you didn't sign it with a key registered on lp that it will just get eaten
<sinzui> gary_poster, my name is now in the emails associated with lazr.restful does not compile on python 2.5 failures
<mars> mwhudson, even if dput says "Good signature" everywhere?
<sinzui> gary_poster, what is the plan to deal with this...I do not think I can fix this build
<mwhudson> mars: possibly, i mean dput doesn't know which keys are registered in lp
<mwhudson> mars: have you successfully uploaded to the ppa before?
<mars> nope
<mwhudson> any ppa?
<mars> nope
<mwhudson> have you signed the code of conduct?
<mars> had to learn so time, didn't I? :)
<mars> ah, nope
<mwhudson> well do that then :)
<mwhudson> though i thought that resulted in emailed rejections
<mwhudson> mars: have you seen https://dev.launchpad.net/LaunchpadPpa by the by?
<bdmurray> I am adding a checking to a view to see if the referer is localhost to help a test pass and that feels hackish to me.  Is it?
<mars> yes, those were the directions I was following
<mwhudson> ok cool
<mars> bdmurray, are you checking for the existance of a referrer?  'localhost' exists for every test run, so is it possible for the test to fail?
<bdmurray> mars: https://pastebin.canonical.com/37968/
<gary_poster> sinzui, the general pain is supposed to end next week, with lucid all around.  For this particular problem, you should ignore it, though I will pursue some questions on my side as to whether I will ignore it.
<sinzui> thanks
<thumper> abentley: https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/libsoup2.4/lucid
<mars> bdmurray, what happens with your patch if the referrer is None?
<thumper> abentley: https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick
<mars> bdmurray, it looks like it will take the first conditional branch.  The old behaviour had it taking the second.
<bdmurray> mars: okay, if I get that squared away though does checking for localhost seem reasonable?
<mars> bdmurray, if the XXX comment says "We need to do this because [foo] is different when running the test suite", then it sounds ok.
<abentley> thumper: hitchhiker lp:~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick mirror . local
<mars> bdmurray, is this a problem where the test harness returns a different value than production?
<bdmurray> mars: as I understand it yes and ReturnToReferrerMixin helps with this but because BugTaskView does some rendering of its own using that mixin wasn't working
<mars> bdmurray, well, I'm out of my depth here then :)
<mars> sorry I can't help more
<mars> mwhudson, you were right about the mails.  Turns out the rejection mail was sent to only the last address on my key
<mwhudson> mars: huh, that sounds a bit odd, but ok
<mars> well, I have three addresses on my key.  The rejection mail was only sent to one of them.
<mwhudson> still seems strange, surely it should be sent to your preferred email address?
<mwhudson> or at least the one in the changes file
<mars> it went to my preferred address.  The one in the changes file didn't get it, and the other one in the "Change" record didn't get it either
<mwhudson> ah
<mars> well, it is fixed now, and building
<mars> mwhudson, still around?
<mwhudson> mars: it's 11:45 am, so it would be a bit early for me to bunk off :-)
<mars> heh
<mwhudson> although i suppose i'll be off for lunch soonish
<mwhudson> mars: how can i help?
<mars> mwhudson, would you happen to know the dpkg or apt invocation that would take an on-disk .deb(s) and place it in the system cache?
<mars> I want to test the launchpad-dependencies package I just built
<mwhudson> mars: no, why not run dpkg -i $deb
<mwhudson> ?
<mars> hmm.  That did not work because the new version forces a downgrade of python-psycopg2, which dpkg won't do becauase it is "not on the system"
<mwhudson> ah ok
<mars> however, if I use apt-get to download the downgraded package
<mars> then it would be there for dpkg to use
<lifeless> losa ping; whats the eta for having all db servers on lucid ?
<mwhudson> mars: "apt-cache add" maybe?
<mars> the "debugging only" warning is a bit unsettling
<wallyworld> thumper: ping?
<thumper> wallyworld: hey
<wallyworld> i figured out the windmill stuff myself, but there's a bug in the windmill code....
<mwhudson> mars: asking wgrant or some distro person is probably a better idea than asking me :-)
<wallyworld> it is fixed in trunk but the only download package is still 1.3 beta2
<mars> mwhudson, I will, thank you for the help though
<wallyworld> so what's the go here?
<mars> wallyworld, if you want to upgrade it, huge +1 from me
<mbarnett> lifeless: hmm, that is an interesting question.  I am not sure.  I belive that the process is starting tonight, but I have not been working on the lucid upgrades, so I am not sure what the overall schedule is right now.
<mars> wallyworld, in fact, the Windmill maintainers explicitly requested that we do so
<mars> for testing
<wallyworld> ok. i would have to produce the source egg from trunk directly since the lasted packaged version is from 2009
<mars> they said 1.4 is entirely backwards compatible
<mars> oh, that....
<lifeless> mbarnett: we have a buildbot failure due to python2.6, and I'm skeptical we'll be fully on lucid/python2.6 tomorrow; thats why i'm enquiring.
<wallyworld> wonder why they are so slack with packaging a new version ?
<mars> ... uhm, /that's/ why I haven't done it yet
<wallyworld> s/version/release
<mars> wallyworld, they may have just missed it.  If you jump onto #windmill and ask, they will help
<mars> wallyworld, our sdist of windmill is... odd
<mars> I couldn't recreate a clean build when I last tried it
<wallyworld> mars. will do thanks. i basically need to pull their trunk and package something newer than the 1.3b2 release we currently use in lp
<mars> however, if I tried it again, I would just try tossing the stock 1.4 sdist into the tree and give it a go
<mars> wallyworld, go for 1.4.0 then.
<wallyworld> mars: will do
<maxb> jelmer: Do you think it is practical to make a bzr-svn release happen and get it into Launchpad 10.10?
<maxb> It would be good to get the KDE branch fixes
<poolie> hi there
<jelmer> hi maxb, poolie
<jelmer> maxb: We're already past FinalFreeze, I don't think these bugs qualify as release critical.
<maxb> jelmer: Launchpad 10.10, not Ubuntu 10.10 :-)
<jelmer> maxb: ahh, sorry
<jelmer> maxb: Yes, that would definitely be possible.
<maxb> It's not essential - the project-neon folks won't mind if it slips, since my desktop is currently importing kdebase and kdesupport for them hourly :-)
<poolie> thumper, no lp committers  have read <https://code.edge.launchpad.net/~jameinel/launchpad/lp-service/+merge/35877> yet
#launchpad-dev 2010-10-01
<thumper> poolie: correction, no lp committers have commented on it
<thumper> I've looked at it and determined that I'm not qualified
<thumper> I'll poke jml and mwhudson :)
<poolie> haha
<poolie> ok, thanks :)
<lifeless> so, if its conditional.
<lifeless> lets land it.
<lifeless> and iterate.
<thumper> lifeless: you review it then
<lifeless> rs=lifeless
<lifeless> done
<mwhudson> poolie: is it proposed into the right branch?
<mwhudson> 4907	+<!-- TranslationTemplateBuild -->
<mwhudson> doesn't seem like something i'd expect to see
<poolie> lifeless: i think it is worth fixing the issues andrew raised
<lifeless> poolie: right
<poolie> but none of them seem profound so i wanted to pipeline other reviews
<lifeless> I knew that the code had been reviewed.
<lifeless> and andrew is an emeritus lp reviewer.
<lifeless> so he can vote it through.
<poolie> mwhudson: i suspect it is a mix of db-devel and devel, so it may not be possible to land until they merge
<poolie> which may now have happeende
<poolie> jam will also need someone to sponsor this and to help him shake it out on staging
<thumper> or it is landed on db-devel
 * thumper is off next week
<poolie> thumper:  you mean it could land on db-devel instead?
<thumper> yes
<mwhudson> poolie: it definitely can't land on devel until the next release
<mwhudson> well, unless there's some history rewriting
<poolie> meaning 2 weeks from now?
<mwhudson> i think it's a bit more than that
<poolie> but if it landed on db-devel, it would be available for testing on staging?
<mwhudson> yes
<mwhudson> poolie: the branch has conflicts with db-devel it seems
<mwhudson> jam: can you merge db-devel, fix the conflicts and repropose it against db-devel?
<poolie> i don't think he's here at the moment but i put that on the mp
<mwhudson> thanks
<thumper> I think getting a new mp against db-devel would help
<thumper> as it would avoid all the extra crap
<thumper> we should allow target editing
<thumper> (but don't yet)
<thumper> and a way to regenerate the diff
<thumper> yet more on the mp todo list
<nh2> hi, I'd like to develop new features for rosetta (launchpad translations), but there are quite a lot of branches. Which one should I use as a base?	
<maxb> https://dev.launchpad.net/Trunk will help you understand how the various branches relate
<maxb> Or, in short, base of lp:launchpad/devel
<nh2> maxb: nice, thank you
<wallyworld> thumper: yo
<thumper> wallyworld: hi
<wallyworld> skype?
<thumper> ok
<poolie> thumper: i agree changing the target wbn
<wgrant> mars: Um, good luck with getting dpkg to downgrade packages.
<wgrant> Downgrades aren't actually supported.
<poolie> ?
<wgrant> s/dpkg/apt/
<poolie> meaning the packages aren't required to cope with it?
<wallyworld> packaging 101 question: is there a script to make a tar.gz from an egg for adding to download-cache?
<wgrant> poolie: Correct.
<wgrant> apt will try very hard to avoid it.
 * thumper feels like crying
<thumper> why is this so fucking hard
 * thumper is upset bzr doesn't allow me to push without stacking
<poolie> thumper: init the branch, turn off stacking, then push
<thumper> I can't init the branch
<thumper> the branch is trunk
<poolie> ?
<thumper> I'm trying to fix up the remaining 9 maverick branches that are stacked on lucid
<poolie> it already exists on lp and is stacked?
<thumper> where reconfigure --unstacked breaks
<thumper> poolie: yes
<thumper> I have local full copies of the branches on devpad
<thumper> and I was trying to move the existing .bzr to backup.bzr using hitchhiker
<thumper> and repush the full unstacked branch
<thumper> but I can't
<thumper> two problems stop it
<thumper> there is a bug in LP where the trunk is offered to stack when pushing trunk
<thumper> (in the weird edge case where you do that)
<thumper> and that bzr can't avoid stacking at creation time
<thumper> you'd think it wouldn't be that hard
<wgrant> thumper: --stacked-on= doesn't help?
<thumper> wgrant: is that valid?
<wgrant> thumper: I think so.
<wgrant> It used to be.
 * thumper pokes something
<thumper> $ bzr push lp:~thumper/wikkid/test --stacked-on=
<thumper> Created new stacked branch referring to file:///home/tim/sandbox/wikkid-sandbox.
<wgrant> .... great.
<wgrant> Well, you could start pushing, kill it before it finishes, then push again.
<wgrant> That should result in it being unstacked.
<thumper> I'm tempted to just use hitchhiker to copy the .bzr dir from the devpad copy
<thumper> that may work
<poolie> :/
<lifeless> poolie: lynne is back, but I'm feeling shitty - going to find a local gp and pop in.
<lifeless> once I get through to a human @ vodafone
<poolie> np
<thumper> although I'd have to do something about the checkout dir
<poolie> there is a medical centre under the forum, on the side nearest the urban; good luck
<lifeless> 6 minutes on hold so far
<thumper> poolie: can you think of a better idea?
<poolie> i'm trying to understand what you're trying to do
<thumper> poolie: ok... here goes
<thumper> https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick is stacked on https://code.edge.launchpad.net/~ubuntu-branches/ubuntu/lucid/libsoup2.4/lucid
<thumper> it shouldn't be
<thumper> the lucid branch should be stacked on maverick
<thumper> I'm trying to fix that
<thumper> or
<thumper> more correctly
<thumper> I'm trying to unstack the maverick branch
<thumper> I don't care about lucid not being stacked
<thumper> however
<poolie> ok, and just reconfiguring it fails how?
<thumper> reconfigure --unstacked breaks
<thumper> with an error similar to what I pastebinned yesterday
<thumper> http://pastebin.ubuntu.com/502991/
<thumper> well, this is for lp:ubuntu/language-pack-gnome-tg
<thumper> but it is also one of the 9 that fail
<poolie> ok and you have new proper copies of the branches elsewhere
<thumper> 312 of the 321 incorrectly stacked branches got unstacked correctly using reconfigure --unstacked
<thumper> yes, on devpad
<poolie> hm
<poolie> is it an option to just overwrite it using sftp+?
<thumper> what do you mean?
<poolie> well, first, let me try to work out if that revision is meant to be in either of those brancehs
<maxb> thumper: Why can't you just mv .bzr backup.bzr.~1~ in hitchhiker, then bzr init lp:foo; bzr reconfigure --unstacked lp:foo; bzr push lp:foo ?
<thumper> maxb: because bzr init lp:foo errors
<maxb> !
<thumper> yeah
<poolie> thumper: because it tells it to stack on itself?
<poolie> can you pastebin that error?
<thumper> the error is worse now :(
<poolie> uh, still?
<thumper> bzr: ERROR: Server sent an unexpected error: ('error', '<Fault -1: "Unexpected Zope exception: CannotHaveLinkedBranch: <Distribution \'Ubuntu\' (ubuntu)> cannot have linked branches.">')
<poolie> !
<poolie> that's not my fault :)
<thumper> I was going to look at those after I had fixed these branches
<poolie> hm so what do you want?
<poolie> i can make a patch to disable stacking on random things
<poolie> or we can manually edit that repo
<poolie> or we can investigate why it won't unstack
<thumper> poolie: is it possible to have a hacky plugin to allow me to push without stacking?
<thumper> poolie: that might be easiest
<poolie> sure
<thumper> poolie: then I could move the .bzr to backup.bzr with hitchhiker
<thumper> poolie: and push the full copy in
<poolie> i'm just wondering if you're going to hit the same zope error?
<thumper> that zope error is due to it looking for the branch to stack on
<thumper> I can use the full url to hitchhiker in still
<thumper> so all we need is to be able to push an unstacked branch
<thumper> then we can look into the unstacking failure
<thumper> et al
<thumper> I need to fix those error messages
<thumper> but I'm not sure that'll get done in time
<thumper> i.e. by EOD as I'm off next week
<thumper> I might get abentley to look into it next week
<thumper> I'm guessing it isn't actually that hard
<thumper> just catching the error in the right place
<thumper> and returning it correctly though the smart server
 * thumper looks for food
<poolie> thumper, i'll see what i can do about it
<poolie> i don't think i'll have access to write to those branches but that can probably be fixed
<thumper> poolie: if you can get me the hacky plugin, I can put it on devpad and push the branches
<thumper> poolie: you can always test it locally
<poolie> k
<poolie> just testing it
<maxb> Did anyone make any headway on the CSCVS  NoWhoami problem yesterday?
 * maxb is collating a list of failed imports
<thumper> maxb: not that I know of
<thumper> maxb: is there a bug filed?
<mwhudson> we need a losa to look at the importds i think
<thumper> mwhudson: do you think that is better than hacking CSCVS?
<mwhudson> thumper: maybe not
<poolie> thumper: ok, lp:~mbp/bzr/stacking adds a -Ddisable_stacked_on_url debug flag
<poolie> which should do what you need
<poolie> you can set that for pushing, etc
<mwhudson> i don't understand why it changed though :/
<thumper> poolie: can I just check that out on devpad and use the bzr in it directly?
<thumper> poolie: do I have to compile anything?
<thumper> $ bzr branch  lp:~mbp/bzr/stacking mbp-bzr
<thumper> bzr: ERROR: The branch lp:~mbp/bzr/stacking has no revision None.
<thumper> ?
<poolie> ah, heh
<poolie> i'm using it to push itself, so it's taking a bit longer than usual :)
<poolie> i'll push it to devpad in a shared repo
<poolie> hang on
<poolie> thumper: that branch is there for you now
<thumper> poolie: on lp?
<poolie> yup
<thumper> poolie: do I have to "make" anything
<thumper> ?
<thumper> poolie: doesn't quite work: $ ~/mbp-bzr/bzr push -Ddisable_stacked_on_url --use-existing lp:~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick
<thumper> Using default stacking branch /~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick at lp-64804368:///~ubuntu-branches/ubuntu/maverick/libsoup2.4
<thumper> bzr: ERROR: The branch 'bzr+ssh://bazaar.launchpad.net/~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick/' cannot be stacked on '/~ubuntu-branches/ubuntu/maverick/libsoup2.4/maverick'.
<poolie> thumper: sorry, back now, no, you shouldn't need to build anythnig
<poolie> can you paste the traceback please?
<thumper> there was no traceback
<poolie> not even in .bzr.log?
 * thumper looks
<thumper> poolie: devpad:/home/tim/.bzr.log
<thumper> mwhudson: ping
<poolie> sorry thumper, that's -Ddisable_set_stacked_on_url
<poolie> :/
<poolie> my mistake
 * thumper sighs
<poolie> obviously it's too long
<thumper> what about -Ddisable_stacking
<mwhudson> thumper: hi
<thumper> mwhudson: got a few minutes for a pre-impl?
<poolie> that would've been smarter
<thumper> mwhudson: translatePath errors
<mwhudson> thumper: ok
<thumper> mwhudson: thanks
<mwhudson> hmm
<mwhudson> thumper: can you hear me?
<thumper> mwhudson: no all I could here was me
<mwhudson> bah
<poolie> thumper: i'm trying to work out if i should file a follow-on bug to  fix this properly
<mwhudson> oh ffs
<poolie> perhaps it is that we want a configuration option to say whether bzr should trust server-suggested stacking?
<thumper> poolie: it would be great to have a client side way of saying "ignore stacking"
<poolie> thumper:  i guess it's bug 368913
<_mup_> Bug #368913: bzr tries to stack on a new branch with stacking policy pointing at . <launchpad> <stacking> <Bazaar:Confirmed> <https://launchpad.net/bugs/368913>
<poolie> and bug 391405
<_mup_> Bug #391405: want an option to force stacking or not when creating a branch <stacking> <Bazaar:Confirmed for mbp> <https://launchpad.net/bugs/391405>
<poolie> thumper: sorry for the lag, is it ok now?
<thumper> poolie: looks like that works
<thumper> 8 left to fix
<poolie> it's hard to get used to having so much code in .txt files
<poolie> how do i run just a single doctest?
<poolie> i mean, a single file?
<wgrant> bin/test -t blahblah.txt
<wgrant> Don't try to give the full path -- it's often not what you expect.
<poolie> ah, so bugs-emailinterface as a workaround for something appears under lib.canonical.launchpad.ftests
<poolie> not the module that actually contains it
<wgrant> It varies.
<stub> poolie: Everything in canonical.launchpad shouldn't be there (but where to put it? Its still unclear often where under lp. things should go)
<poolie> stub: well, in this case the actual file is in lp.bugs.tests
<poolie> which is not a bad place for it imo
<poolie> something to do with bug 305856
<_mup_> Bug #305856: Spurious/intermittent test failure in answers/doc/emailinterface.txt <spurious-test-failure> <tech-debt> <Launchpad Answers:Triaged> <https://launchpad.net/bugs/305856>
<stub> right. but people are encouraged to put new stuff in the 'correct' place rather than in canonical. which might explain the disconnect
<thumper> wallyworld: normally page tests test no-js functionality
<thumper> wallyworld: and the windmill ones test js functionality
<thumper> wallyworld: interactively I use a firefox plugin to disable js
<wallyworld> thumper: in that case, everything should be sweet, no?
<thumper> wallyworld: have you checked that the existing test coverage covers the case you care about?
<wallyworld> yes, xx-branchmergeproposals.txt
<thumper> wallyworld: have you made the fix?
<wallyworld> that doc test basically creates merge proposals etc and checks the results
<wallyworld> i added to it as well as part of the increased test coverage for the new stuff in the branch
<thumper> wallyworld: you are good to go now
 * thumper EOWs
<wallyworld> thumper: thanks. enjoy your week off :-)
<noodles775> Morning
<wgrant> Morning noodles775.
<poolie> ok
<poolie> trying to fix my dkim/gpg failures now
<poolie> omg these doctests with everything running together
<poolie> w
<adeuring> good morning
<lifeless> stub: ttps://bugs.edge.launchpad.net/launchpad-foundations/+bug/640125 is linked to the branch in rev 11567, but it needs qa
<_mup_> Bug #640125: cron scripts should log everything, but only send mail for errors <canonical-losa-lp> <qa-needstesting> <Launchpad Foundations:Fix Committed by stub> <https://launchpad.net/bugs/640125>
<stub> Yup. That might have got to staging now so can be tested when I've kicked off the 8.4 slave
<wgrant> What do we use python-tickcount for?
<wgrant> It seems odd that nobody else on the planet needs it.
<lifeless> stub: its causing https://devpad.canonical.com/~lpqateam/qa_reports/launchpad-stable-deployment.txt issues  because (like me) you reuse branches
<lifeless> wgrant: lsprof didn't exist
<bigjools> morning all
<wgrant> Morning bigjools.
<poolie> oh yay
<wgrant> lifeless: Can we use lsprof instead?
<lifeless> well we won't get ticks, but I'm not sure they are a great proxy
<lifeless> better to implement bug xxxx for per thread resource usage in oops.
<wgrant> (python-tickcount and ubuntu-keyring are the two packages that really tie us to Ubuntu)
<mrevell> Hey
<jml> Good morning
<jml> thumper, poolie: hi
<jml> thumper, poolie: I've honestly been meaning to check out jameinel's branch. Really.
<poolie> np, it shouldn't be your job to review everything
<poolie> though i guess this is a bit in your areao
<poolie> gmb: can i trouble you for an incremental review on https://code.edge.launchpad.net/~mbp/launchpad/dkim/+merge/35985
<jml> noodles775: just looking at your comment ordering post...
<jml> noodles775: out of curiosity, is the code in that demo using lp.services.comments?
<noodles775> jml: yep.
<jml> noodles775: cool :)
<mrevell> noodles775: ping
<noodles775> jml: I had to modify lp.services.comments a bit, and I think lp.services.comments could be generalised a bit more too.
<noodles775> mrevell: yup?
<jml> noodles775: both make sense.
<jml> noodles775: as far as I know, lp.s.comments is an intent-to-generalize more than an actual proven generic solution.
<mrevell> noodles775: Hey, do you have time for a call today? I'd like to pick your brains on your screencast recording setup.
<noodles775> mrevell: sure, although it's just gtk-recordmydesktop. I can talk now, or after lunch, whatever works for you.
<mrevell> noodles775: Is in five minutes okay?
<noodles775> Sure, I'll be in the soyuz 1-1 on mumble?
<mrevell> Ta
<jml> afk for ~20 mins
<jml> now, to action
<bigjools> jml: where is your bzr plugin to show the XXXes?
<jml> lp:difftodo
<bigjools> jml: rock, thanks
<jml> it's not bundled as a regular plugin. am happy to help w/ install issues
 * bigjools as adding copious more to the b-m code
<bigjools> jml: I checked it out in plugins/ and did "bzr todo" - how easier can it be? :)
<jml> bigjools: glad to hear it. it's just been ages since I've installed it or had a new user, so was expecting worse.
<bigjools> jml: this _deferred_list stuff is a nightmare :/
<jml> bigjools: I've long thought so :)
<bigjools> jml: in particular the way it chains callables together in the recording slave with the *DispatchResult at the end
<jml> bigjools: you mean the way it hangs so much on exactly what kind of dispatch result you get?
<bigjools> jml: it's a consequence of the recording slave strategy.  Because it doesn't know in advance what Deferreds will be fired or how many of them, it just keeps processing the recorded slave calls until it hits an instance of the BaseDispatchResult
<jml> ahh
<bigjools> which, when called,p does a Thing
<jml> bigjools: that makes a strange kind of sense
<bigjools> the Thing to do was decided ages ago
<bigjools> jml: yes, that's the annoying thing about it :)
<jml> bigjools: actually, I was going to ask you about the branch anyway...
<bigjools> jml: fire away
<jml> bigjools: I'd like to keep up-to-date with the changes. I'll probably have thoughts, questions etc. What's the most helpful way of sending those back to you?
<jml> bigjools: as I get them, or wait until you've reached some kind of checkpoint or... ?
<bigjools> jml: as you get them would be good - I'm committing a few times a day when I work on it, but that's not regular at all
<jml> bigjools: will do.
<bigjools> I'm trying to make the commit messages as useful to you as possible
<lifeless> stub: any idea about the 15 second update in the +delete bug?
<stub> ENOCONTEXT
<jml> bigjools: not promising I'll get any time. I just filled up an a4 page with "work things currently on the go"
<bigjools> ha
<lifeless> stub: https://bugs.edge.launchpad.net/launchpad-registry/+bug/652802
<_mup_> Bug #652802: Person:+delete timeouts on teams <Launchpad Registry:Triaged> <https://launchpad.net/bugs/652802>
<bigjools> jml: BTW remember all those traps we added that just log messages?
<jml> bigjools: yeah.
<bigjools> jml: I've decided that we should remove them, because inside scan() it catches all errors anyway and does the failure counting.
<bigjools> if we can make all aspects of the job management get failure counted for free, that would be...win
<jml> bigjools: that makes sense... as long as the errors don't get lost.
<bigjools> jml: I can still log - just throw the failure again
<jml> bigjools: for me, the confusing part of the error handling is that some parts catch and throw away and others re-raise and others catch and then signal failure with some different mechanism
<bigjools> jml: you're not alone in confusion
<jml> bigjools: it would be nice if everything just damn well raised & let the bm take care of it all.
<lifeless> exceptions are great for errors
<bigjools> in exceptional cases
<bigjools> routine errors - no
<lifeless> you've argued this before, but not made a compelling case
<stub> lifeless: It is slow because it is trying to update 25k rows in a table of 60million
<lifeless> oh wow.
<lifeless> deceptive ;P
<lifeless> thanks for looking that up
<stub> real question is how come it managed that query in 15s. Took my test 46s :)
<deryck> Morning, all.
<lifeless> night all
 * bigjools drowns in build manager hideousness
<deryck> That rabbitmq hang on shutdown is annoying.
<bigjools> deryck: yes
<bigjools> I've made a /etc/default/rabbitmq file that overrides the DAEMON variable in the startup script to /bin/true
<deryck> I shall do that now.
<bigjools> death to persistent services only needed by LP....
<jml> om nom nom
<maxb> My /etc/default/rabbitmq says "exit 0" :-)
<bigjools> heh
<bigjools> our fake logger copes quite miserably when one of the strings it's trying to log has a % in it
<jelmer> which of our 3 fake loggers ? :-)
<bigjools> quite
<allenap> bryceh: Can you triage bug 644794? It's one of yours :)
<_mup_> Bug #644794: Link BugTrackerComponents to distro/sourcepackages <Launchpad Bugs:New> <https://launchpad.net/bugs/644794>
<jml> bigjools: I thought we fixed that.
<jml> sinzui: hi
<sinzui> hi jml
<jml> sinzui: (foo,) is perfectly valid Python syntax, PEP 8 preferred and our historical coding standard. Why are we changing it?
<sinzui> because PEP8.py is complaining and I do not want to see the complaint
<jml> sinzui: fix pep8.py
<sinzui> maybe
<jml> sinzui: or stop using it. it's putting the cart before the horse to change the way we write code to match a bug in a third-party tool.
<sinzui> would you like to put pylint back
<jml> no.
<jml> but that's not the only other option open to us :)
<jml> sinzui: https://code.edge.launchpad.net/~jml/pocket-lint/singleton-tuples/+merge/37242
<deryck> allenap, many many thanks for helping triage bugs today.  Sorry if I'm stepping on you, too. :-)  Was trying to help catch them up today as well.
<allenap> deryck: I haven't noticed actually.
<deryck> ok, cool
<jml> sinzui: thanks for the review. how soon can we have the patched version on developer machines?
<bigjools> jml: we have, but this time it's in the string outside of the exc_info
<jml> deryck: is sladen filing bugs by email, or is the dupe checker substantially worse
<jml> bigjools: huh what?
<bigjools> jml: a traceback being passed in instead of using exc_info, basically
<sinzui> jml: soon is never an option with building PPAs. maybe Wednesday
<jml> sinzui: what needs to happen?
<jml> bigjools: sorry I think I missed some context.
<jml> bigjools: oh never mind
<bigjools> sinzui: there are plenty of buildd-admins around who can rescore builds, I'm one of them ;)
<sinzui> I push the new source package then we wait for its turn to be built
 * sinzui has never consider cheating
<jml> sinzui: I have a graph that shows the queue empties regularly
<sinzui> wel not on this subject anyway
<sinzui> jml, the last pocket-lint build for Jelmer took about a weeks to do all the hops
<bigjools> sinzui: anyway the queue is small
<jml> sinzui: well, let me know when you've pushed the build. I guess it has to go into the launchpad developer PPA?
<sinzui> jml, okay
<sinzui> jml, we just vopy it
<sinzui> copy
<jml> sinzui: nice.
<allenap> deryck: Can you triage bug 651128? I can't really judge how important it is.
<_mup_> Bug #651128: Email bug submission fails due to erroneous bad signature detection <Launchpad Bugs:Confirmed> <https://launchpad.net/bugs/651128>
<deryck> allenap, sure, I'll take a look.
<allenap> deryck: Thanks.
<deryck> np
<deryck> jml, I believe he is email filing the bugs.
<jml> deryck, I wish we could force a dupe checker into everyone's email client.
<deryck> yup
<deryck> would save us all a lot of time. :-)
<deryck> I don't really like our behavior of adding bug watches when someone adds a link for a tracker we recognize.
<deryck> Maybe this helps other projects but for malone it's almost always wrong to do this.
<noodles775> mars: Regarding bug 644984, does that mean that lifeless' fix (r11597 in devel) is not in production-devel, or that it is but didn't fix it?
<_mup_> Bug #644984: test_runAll_mails_oopses fails sometimes <qa-needstesting> <Launchpad Foundations:Fix Committed by mars> <https://launchpad.net/bugs/644984>
<noodles775> (you might want to re-open the bug if so)
<mars> noodles775, I haven't looked yet (that is why I left it Fix Commited)
<noodles775> Ah.
<mars> need to do this first, then thtat
<deryck> hurray for allenap and I!  bug box 0.
<allenap> deryck: We rule :)
<mars> deryck, is that a first?
<mars> for anyone?
<deryck> mars, oh, no.  We keep our New bug count at zero as best we can.
<deryck> mars, I've just let it slip for a little over a week as I was coding more.  And I new most of them were dupes or need lots of explaining to users and was being lazy.
<deryck> to my defense this is often the case for malone bugs and I was just worn down by it temporarily :-)
<mars> heh
<deryck> The overlays are not aligned properly anymore, I think
<deryck> allenap, what do you make of kitterman's comment in the follow up to bug 651128?  Maybe this is a problem with that script?  No one else is having issues with bad sigs.
<_mup_> Bug #651128: Email bug submission fails due to erroneous bad signature detection <Launchpad Bugs:Confirmed> <https://launchpad.net/bugs/651128>
<malaria> danilos: Hi, are you here?
<allenap> deryck: We could ask him to file a bug by email directly to try and isolate requestsync.
<deryck> allenap, indeed.  I'll ask him to confirm on staging.
<malaria> danilos: about the agreement, do I send it to you? (I mean, in addition to contributor-agreement@canonical.com )
<danilos> malaria, hi, no, no need to
<malaria> danilos: ok, so just for contributor-agreement@canonical.com
<malaria> danilos: done. I re-created my branch on top of trunk and I updated the patch (now tests in browser-helpers.text work)
<malaria> danilos: what more can I do?
<danilos> malaria, the next step is to propose it for merging :)
<danilos> malaria, see https://dev.launchpad.net/CoverLetters for how to describe the change as well :)
<jml> danilos: can you please give me a non-ascii unicode literal for Python?
<danilos> jml, in what format? :)
<danilos> \u0422 is probably a Cyrillic character
<jml> danilos: something I can paste into a Python file as a unicode literal :)
<mars> jml, Ä
<danilos> jml, does the above work, or you want something like "Ð´" :)
<danilos> I seem to ask too many questions and mars is quicker to the point :)
<jml> foo = <thing>; I want something for <thing>
<danilos> jml, right, well, foo = u'Ð¿ÑÐ¾Ð±Ð°' should do if you are using utf-8 encoding
<jml> danilos, mars: thanks.
<jml> danilos: groda?
<danilos> jml, it's "proba" (Ð¿ is like Greek pi :), meaning "test"
<jml> dammit. I always get that wrong.
<jml> some day...
<jml> fwiw, if you paste the literal into a file, you get... SyntaxError: Non-ASCII character '\xd0' in file testrepository/tests/ui/test_cli.py on line 198, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
<jml> using         error_text = u'\u043f\u0440\u043e\u0431\u0430'
<jml>  instead.
<mars> jml, you have to tell your editor to save it as utf-8 with a BOM
<danilos> jml, you need to use "# -*- encoding: utf-8" (PEP-9 I think)
<danilos> uhm, I mean PEP263 as the error message says :)
<jml> ahh :)
<jml> I'm going to live on in merry ignorance of what BOM means in this context
<mars> byte order mark
<mars> silly thing needed by Windows
<danilos> jml, BOM with UTF-8 is creepy stuff (it's "byte-order mark" and "byte-order" doesn't make much sense with a byte stream like UTF-8; it's something like \ufffe or \ufeff)
<jml> although I value the beauty and richness of human culture
<jml> sometimes I wish the Romans had beaten everyone
<mpt> Credo te iustum locum quaerere Quotes Page
<jml> mpt: no, I'm not.
<mpt> :-)
<malaria> danilos: 'make lint' give me some "Line exceeds 78 characters" warning is this a problem? (there are other warnings for no-patched parts of the code...)
<danilos> malaria, yeah, a reviewer will usually ask you to fix these (even if you didn't cause them)
<malaria> danilos: ok, so I'm going to fix these.
<malaria> danilos: one more thing, it complains about "narrative uses a moin header." I don't really get what this mean...
<bigjools> jml: have you looked at my changes yet?  No rush, but I have a question if you have.
<jml> bigjools: no, not ye.
<bigjools> jml: ok, I am in the mood to delete code and I think I can blitz about 100 lines of crap in manager.py
<bigjools> but some of it is most intriguing
<jml> bigjools: ooh.
<malaria> danilos: ok, I found
<jml> bigjools: which bits?
<bigjools> jml: it's all of the stuff that deals with recording slave, processing the deferred_list etc
<bigjools> but I can't figure out wtf the stuff in checkDispatch is needed for
<bigjools> the error handling I think can move moved wholesale to the startCycle method
<bigjools> s/move/be/
<jml> bigjools: agree re error handling
<jml> (also, we should have a doCycle method, or something that does everything sans scheduling the next call)
<bigjools> jml: already done :)
<jml> bigjools: sweet.
<bigjools> makes the tests somewhat nicer ...
<jml> bigjools: in that case, error handling should be there, not startCycle
<jml> bigjools: I'm not at all surprised :)
<bigjools> yes the error handling is in the equivalent of your doCycle
<jml> on checkDispatch, the bit that I don't get is this:
<jml>             if method in buildd_success_result_map:
<jml>                 expected_status = buildd_success_result_map.get(method)
<jml>                 status, info = response
<jml>                 if status == expected_status:
<jml>                     self.callSlave(slave)
<jml>                     return None
<bigjools> that's exactly what I am pondering over too
<jml> under what circumstances is 'response' a 2-list?
<bigjools> I think it's checking return values only for some of the calls
<bigjools> why.... who knows
<jml> 'callSlave' is just "do the next step", iiuc
<bigjools> yep
<bigjools> it's clearly not needed any more, I'm just trying to work out if it's doing something we need
<bigjools> err that doesn't parse well
<bigjools> but you get the idea :)
<jml> yeah, I do :)
<jml> bigjools: my guess is that the chunk of code pasted above is belt-and-braces for RecordingSlave
<jml> based on how buildd_success_result_map gets used in it
<bigjools> I tend to agree
<jml> where does checkDispatch get 'response' from?
<jml> from callSlave...
<bigjools> xmlrpc.Proxy callback
<jml> yeah
<jml> so if I'm reading this correctly (big 'if'), the behaviour in trunk is to terminate the series of calls to the remote slave as soon as we get an 'ensurepresent' return value that's not (True, $SOMETHING) or a 'build' return value that's not (BUILDING, $SOMETHING)
<bigjools> that's about it
<jml> I don't know why that's desirable behaviour.
<bigjools> I've looked at that code many many times in the last 6 months and I still don't know either
<jml> it sounds to me as if those checks ought to be done around explicit calls to build() and ensurepresent()
<jml> perhaps it's a fail-fast kludge?
<bigjools> we can bear it in mind when we change the BlockingProxy over
<jml> I don't think we need to.
<jml> we can bear it in mind if stuff on dogfood breaks because we call the slave too often.
<bigjools> mebbe
<bigjools> in that case, I'm nearly done, it's just a case of removing swathes of this code, its tests, and dealing with the errors at the top of the call chain
<jml> woot :)
<bigjools> oh, and working out where to commit now that I'm removing the *DispatchResults
<jml> bigjools: this code & conversation reminds me of Kernighan's Law
<jml> "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?"
<bigjools> they're wrapped in @write_transaction
<bigjools> indeed
<jml> bigjools: I guess it makes sense to commit at the very end
<bigjools> jml: I'm not sure about that
<jml> bigjools: well, that's what it does now.
<bigjools> jml: not entirely - it has three separate commits
<bigjools> there's the one around scan(), the one after calling updateStatus and the one when dealing with the end of the dispatch chain
<jml> bigjools: yeah, I mean one to replace the calls in dispatch
<malaria> danilos: I requested merge :)
<jml> bigjools: just in case you missed it...
<jml> <jml> bigjools: yeah, I mean one to replace the calls in dispatch
<danilos> malaria, cool, you can probably get a review from someone on #launchpad-reviews, if not, I'll get to it on Monday (mostly done for the day and I am starving :)
<bigjools> jml: those ones are only wrapping the assesFailureCounts() and the reset_result which cleans the job
<bigjools> both already dealt with
<bigjools> jml: so I'm going to add one at the end of the scan for good measure :)
<jml> hmm.
<malaria> danilos: ok, I'm going to #launchpad-review. Otherwise, have a good week-end ;)
<danilos> malaria, thanks :)
<dobey> deryck, allenap: do you guys know what the heck http://pastebin.ubuntu.com/504016/ means?
<deryck> dobey, I do, unfortunately :-)
<deryck> dobey, your trying to edit the slave bug task rather than the master. where the series is the master, the upstream the slave.
<dobey> i don't think so?
<dobey> or i don't understand what that means
<dobey> but the error message is obviously not helpful to me directly :)
<bigjools> good evening all, have a nice weekend
<dobey> hmm
<dobey> deryck: ok, if that is the problem, how do i determine if i am editing the right thing?
<deryck> dobey, sorry, on call.  I'll explain better in a minute.
<dobey> ok
<jml> g'night all.
<jml> if you see lifeless, tell him to release testr.
<deryck> dobey, sorry for delay.  Had to finish calls.  Does this help explain?  http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-devel/annotate/head%3A/lib/lp/bugs/doc/bugtask.txt#L286
<deryck> The section starting there, "Conjoined Bug Tasks"
 * dobey reads
<dobey> deryck: does launchpadlib know anything about the conjoined_* attributes?
<deryck> dobey, no
<dobey> deryck: so how do i tell if the target i'm looking at, is the one i want, if the bug has a conjoined task for the development series?
<deryck> dobey, perhaps bdmurray or bryceh have some stock code snippets for this they could share.  I don't do this myself much since we don't use series targeted bugs on launchpad.
<deryck> bdmurray, bryceh -- what sort of check do you guys do in lplib to make sure you have the right side of the conjoined bug task?
<bdmurray> I'm still not clear on what a conjoined bug task is. ;-)
<maxb> Urgh. We need support for the code import dispatcher to only dispatch one job per svn repository uuid per importd
<dobey> bdmurray: i think it's sort of like http://southparkstudios-intl.mtvnimages.com/shared/sps/images/shows/southpark/vertical_video/import/season_02/sp_0205_08_v6.jpg?width=480
<sinzui> leonardr, your authorisation email is a great read
<leonardr> sinzui, thanks
<dobey> bdmurray: do you know where the code is that closes Ubuntu bugs based on the (LP: #xxx) comments in debian/changelog for package uploads?
<deryck> bdmurray, so what do you do?  try/except around conjoined?
<deryck> dobey, if it were me, I would inspect the target and see what it is before trying to edit the task.
<bdmurray> deryck: I can't answer that without knowing what exactly a conjoined bug task is
<dobey> deryck: yes, but there is no obvious information about whether the target and series are the same
<dobey> deryck: because the main generic task always has no series
<bryceh> I'm not sure what conjoined means either
<dobey> deryck: better question: why doesn't editing the master, simply edit the slave instead?
<deryck> you'll get a ConjoinedBugTask error if you try to edit the main bug task when it's tracked in the series.
<bdmurray> dobey: No someone the code team would know there is a dpkg part that parses the changelog gets the numbers though
<deryck> it's in soyuz.
<bdmurray> right, that's what I meant!
<dobey> bdmurray: yeah, i'm less interested in the number parsing, than how it deals with picking the bug task based on series
<deryck> dobey, if you edit the master, it will work.  it's editing the slave that fails.  In this case, the primary task, not series task, is the slave.
<dobey> oh
<dobey> deryck: ok, then transpose slave and master in my question :)
<dobey> Launchpad does not know where Soyuz - The Launchpad Package Manager hosts its code.
<dobey> nice.
<deryck> dobey, just construct your searchTasks query to get the ones you want.  using nominated_for
<dobey> deryck: branches don't have a nominated_for
<deryck> so you're going branch-->bug-->bugtask?
<dobey> deryck: i am taking a list of the bugs fixed in a branch (from bzr commit --fixes=blah), and trying to mark them as 'fix committed' when the branch is merged into its target
<dobey> deryck: and having to support different series, makes it hate life
<dobey> because the conjoined task thing kind of screws everything up
<deryck> dobey, I don't know how you can do that without looking at the target.  Because there could be any number of tasks on the bug.
<dobey> deryck: i am looking at the target
<deryck> and can you not tell the different in a series targeted bug from the regular task, looking at the target?
<dobey> deryck: let me try to find a meaningfully useful example to explain with
<james_w> see process_bug in http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/annotate/head:/mass-sync.py
<james_w> it does two passes, one to fill related_tasks for those tasks which have a slave task, then the other to process the bugs
* You're now known as ubuntulog
<dobey> deryck: so on             try:
<dobey>                 print task.target.development_focus
<dobey>             except AttributeError:
<dobey>                 pass
<dobey> ah, stupid paste
<dobey> sorry
<deryck> dobey, I think what james_w pasted above will get you unstuck.  Thanks much, james_w! :-)
<dobey> not sure that will help
<bdmurray> will a rootsite parameter with canonical_url remove 'edge' from a returned url?
<bdmurray> sinzui: do you know? the answer to my question above?
<sinzui> bdmurray, no it removed bugs|translations|etc
<bdmurray> sinzui: does anything strip edge?
<sinzui> no
<sinzui> well, logout does it very well
<bdmurray> heh
<sinzui> bdmurray, few conditions that allow users to leave the env name do so by hardcoding the url, or they set the cookie to disable edge redirection
<bdmurray> sinzui: it's appearing in a bug email body which is then sent to users
<sinzui> well I think that is correct. as an edge user it should be clear I am being directed to edge
<sinzui> bdmurray, is the issue that non-edge users are being sent to edge?
<sinzui> I recall that lp recognises that the user is not an edge user a redirects him or her to lpnet instead
<bdmurray> I believe its more a matter of consistency most, if not all, urls don't contain edge
<sinzui> bdmurray, did you find a solution to you link problem?
<sinzui> bdmurray, I think a lot of email orginate from an lpnet process so they always have lpnet urls
<bdmurray> sinzui: no I did not find a solution
<sinzui> i'll look too
<sinzui> bdmurray, what part of the application is sending emails? is it in proc. Most bug mail is queue and the bug mailer which runs on lpnet only send the email, which has the expected urls
<bdmurray> its in bugchange.py which I think is used by the cronjob that sends bug change notifications
<sinzui> bdmurray, many templates do something like this instead of a canonical_url https://launchpad.net/~%(person)s/+editemails
<sinzui> bdmurray, I do not think edge has cronjobs running
<sinzui> bdmurray, so the problem is in getBugNotification()?
<bdmurray> of BugDuplicateChange yes
<bdmurray> I'm really pretty sure that bugnotification.py is running on loganberry as I had to have a fix cowboyed there once
<sinzui> looks like we are making the data too early. We make it in proc on edge. The data is queue. An external proc on lpnet then pull from the queue and it has urls with edge in it
<sinzui> I wonder if we want to do create something like expand path that takes a path and make it a canonical_url for the current env
<sinzui> bdmurray, so gmb introduce the bug last month, but the first wrong use if it was added by myself in 2007
<sinzui> no, this bug is from 2009
<sinzui> well, regardless we need to decide how to postpone making URLs until we are ready
<sinzui> bdmurray, we may want try forcing canonical url to use config.launchpad,non_restricted_hostname
<sinzui> bdmurray, I think this can be used in any env to make make a canonical path that is concatenated to the non-edge version of the site:  config.launchpad.non_restricted_hostname + canonical_url(bug_task, force_local_path=True)
<bdmurray> sinzui: how would you test it?
<sinzui> bdmurray, this is an example of a less hackish way. We do this for openid/XRDS to ensure lpnet is used: http://pastebin.ubuntu.com/504160/
<bdmurray> sinzui: okay, thanks for the help!
<sinzui> bdmurray, I think we need to push test information into the config to be certain the method under test is making the url we control: maybe http://pastebin.ubuntu.com/504162/
<sinzui> config.pop() reset the config. the config is global...we need to do this so that other tests do not see it
<sinzui> bdmurray, I can see other things, to covert bug to question is also broken
<sinzui> instead of hacking this method. write a function that takes any canonical url, converting it to a URI, then switches the host. That is very easy to test and then reuse
<bdmurray> where would you put such a function?
<lifeless> why do you ned to do that ?
<sinzui> bdmurray, I think we might want add helpers.py to lp.services.mail. There is already a helpers in c.l and I think it too has mail template helpers in it
<sinzui> lifeless, urls are generated in some case edge, then inserted into emails. I see three cases for bugs. I see that many old registry templates avoid the edge host by hard coding the domain in the email template, and interpolate the path from the canonical_url
<lifeless> well we're nuking edge very soon
<lifeless> may be simpler to justs not bother addressing this
<sinzui> oh, then we can also nuke some openid code then
<lifeless> by soon, on the order of weeks
<lifeless> the roadmap is:
<sinzui> bdmurray, maybe you can mark the bug as wont fix, or just note it will be fixed when edge is torn down in a few weeks
<lifeless>  - get qastaging going [in progress with losa]
<lifeless>  - disable edge deploys - start deploying just stable (to both the lpnet and edge servers)
<bdmurray> that makes a fair amount of sense to me when I first looked at the bug I didn't realize the amount of work required
<lifeless>  - disable the edge redirect
<lifeless>  - make apache redirect edge urls to lpnet
<bdmurray> does anybody see what's wrong in my commit message?
<bdmurray> http://pastebin.ubuntu.com/504170/
<lifeless> jam: https://bugs.edge.launchpad.net/loggerhead/+bug/653297 may interest you (or may not, I'm not sure if its something you've looked at)
<_mup_> Bug #653297: http://bazaar.launchpad.net/%7Eindicator-applet-developers/libindicate/trunk/revision/382 errors <oops> <loggerhead:Triaged> <https://launchpad.net/bugs/653297>
<sinzui> gary_poster, ping
<gary_poster> sinzui, here, but running very soon
<sinzui> gary_poster, do you have any immediate plans for Account and EmailAddress
<gary_poster> sinzui: all plans are recorded in https://dev.launchpad.net/LEP/OpenIdRoadmap with associated (linked) bugs
<jam> lifeless: I had not seen that before, offhand it looks like concurrent access to the structure, popping an item out while the other is accessing it.
<sinzui> gary_poster, I think Foundations does not claim EmailAddress any more since full separation and I also think you have no interest in LoginToken because only the registry uses it to confirm (not login)
<lifeless> jam: yeah, thats plausible
<jam> anyway, end-of-week here
<lifeless> ditto :)
<gary_poster> sinzui: noone is working on these at this time, nor will they be in the next few weeks at least (and you can see that stuff ideally happens before EmailAddress/Account work, in the form of separating ShipIt)
<gary_poster> does not claim...um...
<sinzui> gary_poster, I want to move LoginToken and EmailAddress to lp.registry. I may do that with Account because I think it is being demoted to something smaller like an ssh key
<sinzui> gary_poster, unless you say no right now, I am taking all three objects. your roadmap tells me you do not want them and are working to not have them
<gary_poster> sinzui, we care about EmailAddress because of SSO integration; and we have some clean-up plans for it that you can see on that wiki page (e.g. bg 629172).  Other than that we don't care about it.  I don't care about LoginToken at all AFAIK.  If you are OK with our plans on the roadmap and with being very careful with the EmailAddress because of the SSO stuff, I'm happy for you to take them (and even appreciative)
<gary_poster> May have been truncated: ...If you are OK with our plans on the roadmap and with being very careful with the EmailAddress because of the SSO stuff, I'm happy for you to take them (and even appreciative).
<sinzui> my immediate goal it to get A and EM out of c.l so that I can make progress resolving circular imports
<sinzui> I can move account somewhere else, I think I think in 6-12 months, you will be done and the models will be largely a registry concern
<gary_poster> sinzui, I like that goal.  The SSO stuff is my only immediate concern, and I don't think that your change will affect it.  Maybe check with stub if you are not confident yourself.
<sinzui> gary_poster, thank. I am not changing db. I just want the import lines in our code fixes
<gary_poster> sinzui, great, thank you.  have a great weekend.
<lifeless> sinzui: rev 11576 needs qa
<lifeless> sinzui: you reviewed it, perhaps you can tell if its ok or not ?
<lifeless>   [r=gmb][ui=salgado, sinzui][bug=439831, 489483,
<lifeless>         629063] Add a font-family declaration for inline description editing
<lifeless>         widgets which ensures consistency and uses the Ubuntu font if present.
 * sinzui lookds
<lifeless> https://bugs.edge.launchpad.net/malone/+bug/435865 is the blocking bug I think
<_mup_> Bug #435865: Use fixed-width fonts for bug summaries <Launchpad Bugs:Fix Committed by deryck> <https://launchpad.net/bugs/435865>
<lifeless> according to https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
<lifeless> sinzui: thanks
<lifeless> back after breakfast
<sinzui> well that is a little easier than my negative tag search
<sinzui> lifeless, does this report of fix committed without tags concern you: https://bugs.edge.launchpad.net/launchpad-project/+bugs?orderby=targetname&search=Search&field.status:list=FIXCOMMITTED&field.tag=-qa-ok+-qa-needstesting+-qa-untestable&field.tags_combinator=ALL
<sinzui> I use it from time to time to check if we missed something
<lifeless> that useful
<lifeless> (not back, just picking upo a book for lynne)
#launchpad-dev 2010-10-02
<lifeless> rockstar: around ?
<lifeless> https://bugs.edge.launchpad.net/launchpad-code/+bug/623102 needs qa
<_mup_> Bug #623102: AttributeError on +request-builds page <oops> <qa-needstesting> <recipe> <Launchpad Bazaar Integration:Fix Committed by rockstar> <https://launchpad.net/bugs/623102>
<lifeless> its now the front of the queue in https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
<wgrant> Fuck.
<wgrant> Does anyone know how far back we keep primary archive publisher logs?
<jelmer> good morning wgrant  :-)
<wgrant> jelmer: Morning.
<wgrant> >>> BinaryPackagePublishingHistory.distroarchseries in [1]
<wgrant> True
<wgrant> That looks like a bit of a misfeature.
<jelmer> whu? How is that happening?
<wgrant> jelmer: I suspect it's because __eq__ returns a Storm expression.
<wgrant> Which evaluates to True.
<wgrant> (and causes a very nasty bug.......)
<lifeless> wgrant: nice branches
<wgrant> lifeless: I'm getting lots of timeouts on MPs tonight.
<wgrant> Hah, nice timing.
<lifeless> got some #'s
<wgrant> OOPS-1736EC482
<wgrant> I suspected librarian issues, but then there were some reports of abnormal IBugTarget:+bugs timeouts in #launchpad.
<lifeless> 113003.01SQL-launchpad-main-masterSELECT "_6".branch, "_6".id, "_6".revision, "_6".sequence FROM BranchRevision AS "_6" LEFT JOIN BranchRevision AS "_7" ON "_7".revision = "_6".revision AND "_7".branch = %s WHERE "_6".branch = %s AND "_6".sequence IS NOT NULL AND "_7".id IS NULL ORDER BY "_6".sequence DESC LIMIT 10
<lifeless> (13 seconds)
<lifeless> possibly fat indices on branchrevision
<wgrant> Or general DB slowness.
<wgrant> Given the other issues this evening.
<lifeless> were there oops ids for them?
<lifeless> we might be running on a different master I guess; I dunno where the migration got to.
<wgrant> OOPS-1736F673
<wgrant> lifeless: That was one of them.
<lifeless> 115046.01SQL-launchpad-main-masterSELECT Bug.heat FROM Bug, Bugtask WHERE Bugtask.bug = Bug.id AND Bugtask.product = 8920 ORDER BY Bug.heat DESC LIMIT 1
<lifeless> (15 seconds)
<lifeless> so yes, some issue
<lifeless> man the sodium crashes make our reporting so useless
<lifeless> I can't really tell if there is an oops spike or not.
<lifeless> jml: around ?
<jml> lifeless: am now.
<lifeless> jml: ah, lp:~lifeless/launchpad/bug-627701
<lifeless> jml: It failed on ec2; I've pushed up a fix, but its a little deeper than previous
<lifeless> jml: I would like another eyeball over it
<jml> lifeless: sure
<lifeless> jml: I'm primarily worried about clarity for the next person eyeballing the code
<jml> pep8 grumble grumble
<lifeless> I will also admit that I sent it to ec2land when I thought you were out :> I will land a tweak if you have changes, and it gets through as-is.
<jml> +        # DB tracers are not safe for reentrant use, so we nmust do this
<jml> typo
<lifeless> thanks
<jml> lifeless: other than that, looks about as clear as it's going to get. _get_request_timeout is hard to follow, but that's not new in your most recent change.
<jml> lifeless: I suspect anyone wanting to change this code is going to have to think hard & do some poking around (e.g. what's opstats? I kind of know, but I'd want to know more before I changed that code)
<lifeless> yeah
<lifeless> the opstats conditional there is fugly
<lifeless> jml: I hope my mail about qa didn't come across as grumpy or whatever; it wasn't meant to be
<jml> lifeless: no, it doesn't.
<jml> lifeless: I have some problems with the process that I think are fairly significant
<lifeless> https://devpad.canonical.com/~lpqateam/qa_reports/deployment-stable.html
<lifeless> jml: we should debug those
<jml> lifeless: but it's hard to be clear about them at the same time as being civil. :)
<lifeless> jml: in private mail you can be less civil if you like ;)
<jml> lifeless: ok :)
<lifeless> wgrant: I think there may be a db issue; theres a spike in OOPSes even though the data is crap.
<lifeless> losa ping - we're seeing normally fine queries ballooning to 15 seconds, multple tables; if someone can eyeball the db servers health etc that would be awesome
<wgrant> lifeless: sodium's still being crap?
<lifeless> wgrant: yes
<seiflotfy> hey guys
<seiflotfy> oh nigelb is here too
<nigelb> heh
<seiflotfy> Ursinha, there?
<seiflotfy> Ursinha, we need help
<seiflotfy> i registered a project but set the worng maintainer
<seiflotfy> and now cant change it to m4n1sh
<seiflotfy> beuno, jml ^^
<seiflotfy> or lifeless ^
<Ursinha> seiflotfy, what happens when you try to change?
<Ursinha> or you just can't?
<Ursinha> I can't
<Ursinha> (at least can
<Ursinha> (at least can't find where the option is..)
<maxb> maintainer == owner, no?
<maxb> and you can only give ownership to teams you are a member of
<seiflotfy> maxb, Ursinha i cant do anything
<seiflotfy> i cant change it bac
<seiflotfy> althoug i creatd the project
<seiflotfy> there is no team (yeT)
<maxb> as I said, you can only change it to teams you are a member of
<seiflotfy> i have zero access
<nigelb> you created a team and gave access to somone else wrongly?
<nigelb> s/team/project
<seiflotfy> nigelb, yes
<nigelb> In retrospect using a team would have been a better idea.  I suppose somone here can change it for you.
<seiflotfy> yes please
<m4n1sh> any LP admins here? me and seiflotfy have made a huge mistake. jml lifeless Ursinha
<maxb> m4n1sh: What exactly is the problem? Project has been given away to person who is not associated with it?
<m4n1sh> maxb: check https://launchpad.net/trophylicious
<m4n1sh> seiflotfy registsred it and tried to assign it to me (~manishsinha)
<m4n1sh> maxb: but did a mistake and assigned it to ~manish
<m4n1sh> maxb: now since he is just the driver, he cant revert it back
<m4n1sh> maxb: what is the solution now?
<maxb> seiflotfy should file a question (https://answers.launchpad.net/launchpad/+addquestion) explaining what happend and asking for it to be reassigned
<m4n1sh> maxb: sure. Will tell him when he is around
<m4n1sh> thanks
<nigelb> sigh, I suggested that at the beginning.
<m4n1sh> nigelb: that was the only way even I could have thought of, but still
<m4n1sh> nigelb: seeing your after a long time. sup?
<nigelb> m4n1sh: all good, what about you?
<maxb> I'm afraid I think you need a full admin to change project ownership, so this will almost certainly have to wait for Monday
<m4n1sh> nigelb: mine is also fine, too much work, too much code to handle :)
<nigelb> lol
<m4n1sh> maxb: full admin means? means the admin who handles LP Registry?
<m4n1sh> I mean the team which takes orphaned projects and re-assigns them? that team?
<m4n1sh> nigelb: yeah. Zeitgeist integration is very very time consuming
<maxb> full admin rather than registry-admin
<m4n1sh> maxb: okay fine. We can wait till monday. Will tell seiflofty to file the question tomorrow, which can be taken care on monday
<maxb> m4n1sh: It would be wise to come back here on Monday and ask nicely for an admin to look at the question
<m4n1sh> maxb: who all are the LP admin present on this channel?
<m4n1sh> I see gary online a lot of time, does he have admin rights?
<lifeless> moin
<seiflotfy> waaaaaaaaaaah
<seiflotfy> i need help
<lifeless> hi, whats up ?
#launchpad-dev 2010-10-03
<lifeless> if any losa happens to be around, buildbot has been smoking weed again.
<lifeless> moing
<lifeless> oh crud no spm today
<lifeless> we're going to be in testfix -all- day
<jml> lifeless: then release testr :)
<jml> lifeless: also, I'd like to have a voice call w/ you tomorrow evening my time. later would be better (need to do post-work shopping) you up for it?
<lifeless> sure
<jml> lifeless: cool. thanks.
<jml> g'night all.
#launchpad-dev 2011-09-26
<lifeless> time to extract the logging oops code I think
<lifeless> poolie: you wanted to talk qbr ?
<poolie> hi there
<poolie> sure, if you have some time we could chat
<poolie> otp at the momemnt but won't be long
<lifeless> cool
<lifeless> I'm on sky.net, or my landline, ring whenever
<nigelb> Morning!
<lifeless> hola
<wallyworld_> wgrant: so in the qas mailbox, there's mail for when new bugs get created but no mail for comments or privacy changes etc. am i doing something wrong?
<wallyworld_> nigelb: hello
<wgrant> wallyworld_: You've run send-bug-notifications.py?
<wallyworld_> wgrant: no. i though the cron job was set up on qas to do that
<wallyworld_> but no?
<wgrant> I don't think so.
<wallyworld_> i need to ask to get that script run then?
<wgrant> Yes
<wallyworld_> thanks
<wgrant> The general rule is that if something would be convenient and easy, qastaging has to have it done manually or it's impossible.
<wallyworld_> hah
<lifeless> with the new script server for [qa]staging
<lifeless> we'll get more things running
<lifeless> still need more db grunt for some tasks though
<lifeless> wallyworld_: you should never remove bad-commit-xxxx tags
<lifeless> wallyworld_: they control the bad-revision-range marking for the qa-tagger.
<lifeless> wallyworld_: *if* we were to rollback prod, not having it would be bad
<wallyworld_> oh, sorry
<nigelb> Hrm, no stub yet.
<lifeless> (think of it this way - that old revision is still bad, right ?)
<wallyworld_> yes
<nigelb> How does one get a run a garbo job running?
<wallyworld_> nigelb: there's cron scripts
<wallyworld_> garbo-hourly.sh etc
<wallyworld_> .py
<nigelb> so, that script has to get checked in?
<wallyworld_> sorry,
<wallyworld_> the cron scripts run garbo-hourly.py
<wallyworld_> which you can run yourself
<wallyworld_> on your dev system
<nigelb> I want it run on production :)
<lifeless> it happens automatically
<lifeless> just land the change, qa it, deploy.
<nigelb> ah
<nigelb> okay
<lifeless> for qa you'll need a paid dev help, to get losas to run it and then check the db
<nigelb> It still gets checked in even if its a one time thing right?
<lifeless> yes
<lifeless> code land qa deploy wait delete land qa done
<nigelb> wow
<nigelb> fixing tech debt is *hard*
<nigelb> I need to do 6 landings for this bug.
<nigelb> 3 in devel and 3 in db-devel.
<lifeless> 3 in db-devel ?
<nigelb> Yeah
<wallyworld_> so if we can avoid introducing tech debt in the first place......
<nigelb> hheh
<lifeless> one for the new column, one to drop the old columns. Whats the third db-devel one ?
<lifeless> indices I guess.
<nigelb> ah, no
<nigelb> two.
<nigelb> I counted the garbo jobs in db-devel last time.
<nigelb> bug 5283
<_mup_> Bug #5283: "Home page" vs. "Description" is misleading <easy> <lp-registry> <tech-debt> <ui> <Launchpad itself:Triaged by nigelbabu> < https://launchpad.net/bugs/5283 >
<lifeless> so in devel you need:
<lifeless>  1- add new column, change appservers to *write* to that column as well as the old columns, and introduct garbo job.
<poolie> lifeless, hi, how about now?
<lifeless>  2- change appservers to read from the new column and drop the garbo job
<lifeless> 2 landings AFAICT
<lifeless> poolie: sure
<nigelb> lifeless: cool! that's better. I was counting each step as a differnt landing :)
<lifeless> OTP now
<nigelb> stub is awake but being productive off IRC. HA.
<wgrant> The bug privacy APIs are a mess :(
<StevenK> huwshimi: O HAI
<huwshimi> StevenK: Hello!
<StevenK> huwshimi: I pointed you at https://code.launchpad.net/~stevenk/launchpad/include-ppa-url/+merge/76499 last week, but I missed your answer. Can we have a quick mumble about it?
<huwshimi> StevenK: Oh right, sure
<StevenK> wgrant: Can you join mumble for one tick?
<wgrant> lifeless: How long since you've talked to Curtis about disclosure?
<wgrant> lifeless: eg. what we discussed last week about the mess around special-casing security?
<lifeless> several weeks
<lifeless> if you want me in on a stand up or party to a discussion - just let me know
<StevenK> Oh, JS, please die on a fire
<wgrant> lifeless: There are branches flying around now to sort of finish the partial implementation of that, so it probably needs discussion RSN.
<nigelb> StevenK: Eventually, everything will be in JS :p
<StevenK> Continue is not the right button in Firebug, what's the right one to step to the next statement?
<wgrant> lifeless: Doing anything except special-casing security is currently believed to be out of scope :(
<wgrant> Because stakeholders have not asked for it.
<wgrant> But I don't think we should break our privacy support just because stakeholders don't ask for it to not be broken :/
<nigelb> StevenK: Next?
<nigelb> err
<nigelb> "Step Into"
<nigelb> BUt you may want to add more breakpoints
<nigelb> I generally breakpoint like 6 to 7 lines
<lifeless> wgrant: so, arrange a 3-way with you me and curtis minimally
<StevenK> wallyworld_: The event from clicking the ok button doesn't fire :-( http://pastebin.ubuntu.com/697061/
<huwshimi> wgrant: The bug is bug #859386. Would you mind triaging it appropriately and editing it so that it makes sense?
<_mup_> Bug #859386: Merged teams with ppas are still linked to from +archivesubscriptions <Launchpad itself:New> < https://launchpad.net/bugs/859386 >
<wgrant> huwshimi: Thanks. I've duped it against but #684112
<_mup_> Bug #684112: +archivesubscriptions shows links to merged users. <404> <lp-registry> <merge-deactivate> <tales> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/684112 >
<wgrant> bug #684112
<_mup_> Bug #684112: +archivesubscriptions shows links to merged users. <404> <lp-registry> <merge-deactivate> <tales> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/684112 >
<huwshimi> wgrant: oh right, thanks :)
<poolie> hi all, could i get a review of https://code.launchpad.net/~mbp/launchpad/858618-affecting-me/+merge/76880 (and a few other small ones)
<poolie> huwshimi, what do you think of my screenshot on bug 858618 - i presume it's unobjectionable for ui but thought i'd ask
<_mup_> Bug #858618: hard to find bugs that affect you in a project <bugs> <ui> <Launchpad itself:In Progress by mbp> < https://launchpad.net/bugs/858618 >
<huwshimi> poolie: I think it fits nicely with the other content there. Such a lovely little feature :)
<poolie> yeah
<poolie> copy & paste ftw!
<nigelb> huwshimi: hey
<nigelb> I was askign to chat with you
<huwshimi> nigelb: Hey there
<poolie> i hope also to soon do /~/+affectingbugs but i didn't quite get to it
<poolie> the implementations of bugs/~mbp and bugs/bzr are alarmingly different
<huwshimi> poolie: Yeah that would be nice too
<poolie> to my eyes anyhow
<nigelb> huwshimi: How would one go about overriding the default CSS on one particular page? (Without killing kittens :P)
<poolie> o/ nigelb
<nigelb> Morning poolie!
<huwshimi> nigelb: I'm not sure exactly what you mean (well, I understand the kittens bit).
<nigelb> huwshimi: It fix for bug 806660 is to split the form into two tables. This adds some extra margin.
<_mup_> Bug #806660: "Add a new address" in e-mail settings does the wrong thing when pressing Enter <easy> <ui> <Launchpad itself:Triaged by nigelbabu> < https://launchpad.net/bugs/806660 >
<nigelb> The margin is part of the default CSS, which I want to override and set to 0.
<nigelb> s/It fix/The fix/g
<lifeless> poolie: if thats going in the side portlet
<lifeless> poolie: you'll want to test the performance carefully, or feature flag it
<lifeless> poolie: the portlet has some inefficiences in it
<poolie> yeah it's doing one more query
<huwshimi> nigelb: Do you have the code pushed to LP yet?
<poolie> lifeless, what would be a reasonable test?
<lifeless> poolie: performance of that query on the most-affected person in Ubuntu
<lifeless> if its under say 100ms its probably ok for now
<nigelb> huwshimi: No, its in a branch.
<nigelb> let me see if I pushed the branch
<poolie> lifeless, and, sorry how can i most easily find out the query time?
<nigelb> huwshimi: this is what I've done so far. https://code.launchpad.net/~nigelbabu/launchpad/registry-email-add-806660/+merge/75676
<huwshimi> nigelb: Ah cool thanks
<nigelb> I have the manual style override in my local branch, but I didn't push it.
<huwshimi> nigelb: So overrides normally happen by either applying an existing class (you'll have to hunt through and see if there are any generic classes that do what you want. Failing that try and write a generic class for the situation. Failing that write a more specific class.
<lifeless> poolie: generate the query locally, then get a losa to run it on prod
<huwshimi> nigelb: If you're writing new classes make sure they end up somewhere logical in the style sheet (i.e. not the end of the file)
<lifeless> poolie: for magic ocnstants, use a few separate queries to establish them (e.g. the person most affected, the distro id etc)
<poolie> ok
<poolie> i can get at the staging db
<poolie> so that should give me the right constants? but not necessarily representative timing?
<huwshimi> nigelb: More specifically that means applying a second class to the table (I'm guessing that's where you're currently applying the styles at the moment).
<huwshimi> nigelb: Have a hunt around in the stylesheet (do you know where that is?) for the .form class and see if anyone has done something similar.
<lifeless> poolie: right
<nigelb> huwshimi: cool, I'll look
<nigelb> (At work right now and away from my hacking laptop)
<huwshimi> nigelb: Great, let me know if you get stuck
<jtv1> wallyworld_: this may be more of what we discussed beforeâ¦ I filed bug 859369.  I've also got a multi-thousand-line lint fixup branch going into testing.
<_mup_> Bug #859369: Hideous lint in choiceedit.js <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/859369 >
<nigelb> multi-thousand line. wow.
<poolie> could anyone guess why, running tests locally, things that try to upload to the librarian fail with
<poolie> UploadFailed: Server said: 500 Internal server error
<poolie> lifeless, re bug search timing
<poolie> many of those portlets are going to be retrieving similar kinds of data - counts across the bugs in a particular pillar
<poolie> i suppose they could possibly be bummed together into a smaller number of queries
<poolie> at least for, for example, the aggregation by status or by importance
<lifeless> poolie: yes, a couple of passes of such grouping have already been done
 * wgrant hates the product/distribution split
<adeuring> good morning
<poolie> o/ adeuring
<adeuring> hi poolie
<poolie> hi danilos
<poolie> could you read https://code.launchpad.net/~mbp/launchpad/855150-no-potemplate-mail/+merge/76878 for me
<lifeless> can someone confirm that canonical.librarian.tests.test_db_outage.TestLibrarianDBOutage.test_outage was broken on the 19th
<danilos> poolie, sure
<danilos> poolie, btw, note that you are also fixing bug 353648 with this
<_mup_> Bug #353648: Template import success notifications shouldn't be sent to package uploaders <lp-translations> <Launchpad itself:Triaged by danilo> < https://launchpad.net/bugs/353648 >
<poolie> oops :)
<danilos> poolie, well, if your bug was only about this (you did raise other problems), I would have marked it as a duplicate of that bug and extended it to not be just about package uploaders but project maintainers as well :) so, you are actually fixing that other bug only :)
<danilos> poolie, anyway, looks good, r=me
<danilos> poolie, fwiw, there is web UI that shows if the template has been imported already, it might be hard to find though, but that's a different problem
<poolie> awesome
<poolie> yes, talking it over with robert, we thought that if it's not visible (enough) that can be a separate bug
<poolie> so we could probably just do a short blog post saying the mails are going to cease
<poolie> i don't think any other prep is needed
<danilos> poolie, yeah, agreed, I'd even say that it's most important to let our CHR people know about it if people come asking (i.e. "no success emails anymore, go to your project/+imports page to see the status of the upload")
<lifeless> stub: hey, still around ?
<stub> lifeless: yer
<lifeless> would you be up for a brief call - want to touch base on some rt's with you
<stub> lifeless: k
<stub> lifeless: lets see if skype works...
<stub> lifeless: skype didn't survive the upgrade
<wgrant> stub: There's a multi-arch workaround for that.
<wallyworld_> jtv: choiceedit.js came across directly from lazr-js
<wgrant> https://bugs.launchpad.net/ubuntu/+source/skype/+bug/830440
<_mup_> Bug #830440: skype: error while loading shared libraries: libXss.so.1: cannot open shared object file: No such file or directory <apport-collected> <oneiric> <running-unity> <ia32-libs (Ubuntu):Won't Fix> < https://launchpad.net/bugs/830440 >
<wgrant> stub: ^^
<jtv> wallyworld_: aigh.
<wallyworld_> ?
<jtv> wallyworld_: I saw your name in âbzr annotateâ and so hoped you'd be familiar with the code.
<jtv> There's some fuss about which of JavaScript's delightful comparison operators to use, and I didn't want to touch that for fear of introducing subtle breakage.
<wgrant> I think we should probably just ban ==...
<wallyworld_> jtv: sadly no. when i brought everything across, i shaved a yak or two to get it all to play nicely, that;s all
<wgrant> JS type coercion: Australia says no.
<wallyworld_> jtv: i've had the same issues. once, i converted ==  to === and some bugs appeared
<poolie> wgrant, stop the floats!
<jtv> wallyworld_: well, at least that validates my response.
<wallyworld_> so i had to use Y.Lang.isValue() instead
<lifeless> jamesh: so the exception name qualification bug in python-oops : are you going to patch it, or its just a nice to have?
<jtv> wallyworld_: I did that in one place.  Very C-ish loop.
<wgrant> poolie: Heh.
<wallyworld_> ah C, the good old days :-)
<jamesh> lifeless: was planning on putting together a patch.  Just haven't done so yet.
<lifeless> jamesh: no worries
<jtv> Any reviewers in the house?  https://code.launchpad.net/~jtv/launchpad/post-857155/+merge/76837
<jtv> stub, are you OCR'ing today?
<bigjools> I pine for the C
<lifeless> jamesh: let me know if the libraries still need work to play nice
<stub> jtv: No. My brain isn't working today.
<jtv> stub: insert coffee.
<stub> jtv: Done all that. I've just got the lurgy that has been doing the rounds.
<jtv> And no more Monday reviewer for Europe, I see.  Maybe I should change slots to cover that hole.
<jtv> stub: feel better.
<jamesh> lifeless: sure.
<wallyworld_> bigjools: C is good, but C++ is better :-)
<stub> Monday is light.
<lifeless> -lol- http://www.boganipsum.com/
<bigjools> wallyworld_: naturally! better than most things
<wgrant> lifeless: I think that did the rounds while you were away :P
<wgrant> lifeless: But yes, hilarious.
<lifeless> wgrant: probably yeah :)
<lifeless> markov FTW
<poolie> stub, lifeless, are the query changes in https://code.launchpad.net/~mbp/launchpad/855150-mail-disabled/+merge/76876 dangerous at all?
<lifeless> stub: are you installing that workaround, or should I call a landline?
<nigelb> stub: had you landed the patch that you approved earlier today or should I ask the OCR?
<nigelb> err, db patch
<stub> lifeless: turtles all the way down. Finished reporting the bug on software centre (well... confirming it affecting me)
<lifeless> stub: lovely!
<stub> lifeless: It could take a while. Mobile better.
<lifeless> poolie: 61	+ def test_get_recipients_team_with_disabled_account(self):
<lifeless> 62	+ """Mail is not sent to teams containing people with a non-active account.
<lifeless> 63	+
<lifeless> poolie: surely 'mail is not sent to people with non active accounts' ?
<lifeless> poolie: or are you intending to disable all notifications if one person in the team-owning team is inactive?
<lifeless> (if so, your patch doesn't achieve that ...)
<jtv> wgrant: pretty boring run so farâ¦  the version we have in Sources.gz is always the oldest version we have in the database.
<lifeless> stub: kk, will be a minute, nappy change time
<stub> ... and perhaps a hose.
<poolie> lifeless,  the docstring is wrong, the intention of the test is meant to be 'mail is not sent to team members who have inactive accounts'
<bigjools> wallyworld_: it's not better than cricket though
<jtv> wgrant: then again, the actual domination algorithm hasn't changed, so arguably we don't need to continue the current run.  We could just alter Sources.gz for a version we've already dominated, and re-run.
<lifeless> poolie: so the change is fine I think
<lifeless> poolie: but it's incomplete
<lifeless> poolie: this covers the case of 'when contacting a team who do we wamil'
<lifeless> poolie: emm, I have a memory of there being another case for members of (rather than walking the owner tree)
<lifeless> poolie: you might like a separate test where the disabled person is a member of the team rather than the owner
<wallyworld_> bigjools: not much is better than cricket :-D
<lifeless> poolie: (oh, and to change that test to have the owner not be in the team [the default is the owner is a member])
<lifeless> poolie: HTH
<poolie> so you're saying, two tests:
<poolie> 1- disabled person is a member (not the owner)
<poolie> 2- disabled person is the owner (not a member)
<poolie> arguably there should be one for indirect membership
<poolie> for curiousity was doing this by tweaking the storm query a clean way?
<jtv> wgrant: stats snapshot shows gina making pretty good progress actuallyâ¦ https://pastebin.canonical.com/53350/
<lifeless> poolie: I think so yes
<lifeless> poolie: I may be wrong / misremembering
<stub> lifeless: have working skype
<lifeless> oh, good timing
<lifeless> stub: have you signed in?
<jelmer> hmm, so how do I sensibly check if a branch is private from within the Launchpad code ? accessing .private raises Unauthorized
<jtv> Anyone willing to review?  https://code.launchpad.net/~jtv/launchpad/post-857155/+merge/76837
<jtv> lifeless: would you be up for a review?
<lifeless> jtv: not just now sorry; otp, then nabbing tom, then familty
<jtv> OK
<jtv> Anyone else?
<jtv> Reviewer needed!
<jtv> Reviewer needed, since Friday, for critical bug.  No volunteers?  It doesn't have to be the same people every time!  https://code.launchpad.net/~jtv/launchpad/post-857155/+merge/76837
<jtv> poolie, you're a reviewer, right?
<jtv> allenap, maybe you can review it for me?  Q/A is already well underway, so no very obvious huge blunders.
<poolie> jtv with trainer wheels
<jtv> Ah
<allenap> jtv: Okay.
<jtv> thanks!
<jtv> wgrant: I think gina's about done with sid.
<jtv> Yup.  Stats time.
<wgrant> jtv: And it's only running over sid, so that's good.
<jtv> Yes.
<jtv> I didn't see any point in running it on the other series.
<wgrant> Neither.
<wgrant> And we don't have a source archive for them.
<jtv> Stats before & after:
<jtv> https://pastebin.canonical.com/53347/
<jtv> https://pastebin.canonical.com/53353/
<poolie> jtv it's not obviously wrong but i really have very little understanding what this is doing
<jtv> poolie: Gavin's having a closer look, thanks.
<jtv> wgrant: stats look fairly sane to me, prima facie.  Only sid seems affected, about the same numbers of packages got deleted and stayed published as before, and we get about 1 DSDJ per deleted package.
<wgrant> jtv: It doesn't seem to have done anything obviously entirely insane, which is about as much as I expected to glean from this test run.
<allenap> jtv: Approved, with a caveat about testing.
<jtv> Quite.  Then again, the algorithm's substantially the same so it's important to know we didn't skip large numbers of dominations.
<jtv> thanks allenap!
<poolie> jtv, could you look at https://code.launchpad.net/~mbp/launchpad/858618-affecting-me/+merge/76880 for me?
<jtv> OK
<poolie> lifeless, tests added; they pass
<lifeless> cool
<poolie> anything else? don't want to rush but would like to kick it off before i sign off
<lifeless> seems fine to me :)
<jtv> poolie: done with your MP.  Hope it answers your question; do let me know if it doesn't.
<bigjools> lifeless: testing your oops_twisted
<bigjools> it's blowing up
<bigjools> http://pastebin.ubuntu.com/697174/
<lifeless> bigjools: no publisher configured
<lifeless> bigjools: file a bug though, with no publisher it shouldn't blow up
<bigjools> lifeless: should be
<bigjools> lifeless: here's the branch change: http://pastebin.ubuntu.com/697177/
<lifeless> so the failure is in fallback_report
<lifeless> which takes the ids, the report and the event, and is called after the publishing deferred fires
<bigjools> lifeless: it's adding a FileLogObserver
<lifeless> bigjools:
<lifeless> +    if options["oops-dir"]:
<lifeless> +        repo = DateDirRepo(options["oops-dir"], options["oops-prefix"])
<lifeless> +        config.publishers.append(defer_publisher(repo))
<lifeless> bigjools: so 2 things; one - there is a bug (please file it on python-oops-twisted, will fix for you tomorrow)
<bigjools> ok
<lifeless> and two, you need this line:
<lifeless> config.publishers.append(defer_publisher(repo.publish))
<lifeless> the bug is that if there is no publisher, the fallback code crashes, rather than e.g. forwarding the original event
<bigjools> lifeless: what is the bug (for the title) ?
<bigjools> sorry, should have read first
<lifeless> 'if there is no publisher, the fallback code crashes'
<lifeless>  :P
<bigjools> :)
<bigjools> was too busy typing to read you :)
<lifeless> no worries
<bigjools> lifeless: that change didn't help
<wallyworld_> A tachyon walks into a bar. The bartender says "We don't serve your kind here." The tachyon replies "You did tomorrow". HAHAHAHAHA
 * bigjools sees tumbleweed
 * bigjools hears a dog barking in the distance
<lifeless> bigjools: this is what I think will fix it (I'll do the test in the morning)
<wallyworld_> you lot have no sense of humour
<lifeless> http://pastebin.com/6qWMhzZn
<lifeless> bigjools: However, the root issue is that its not seeing the id in the report
<bigjools> wallyworld_: that's irony :)
<wallyworld_> :-)
<lifeless> bigjools: how are you testing this?
<bigjools> "Your paste has triggered our automatic SPAM detection filter"
<bigjools> nice
<jtv> wallyworld_: we have a sense of humour, but we keep up with the news.  Had the joke included a speeding neutrinoâ¦
 * wallyworld_ thought they were the same thing
<wallyworld_> doh
<wallyworld_> i fail
<bigjools> lifeless: I am not starting the rabbit server before txlongpoll - I can't think of a decent unit test yet
<lifeless> bigjools: ok, and how are you starting txlongpoll ?
<bigjools> bin/twistd -n amqp-longpoll -l mylog -u guest -a guest -f 9999
<lifeless> bigjools: I believe options['date-dir'] is not set.
<jtv> wallyworld_: they may be the same thing for all I know, but I can't imagine anyone being surprised if a tachyon went faster than the speed of light.
<bigjools> AH
<bigjools> fuck
<lifeless> bigjools: which will cause you to have no publisher.
<bigjools> indeed
<bigjools> \o/
 * jtv vows, if ever invited, to do his round of the Top Gear test track in reverse in order to get the lowest-ever time.
<bigjools> http://pastebin.ubuntu.com/697182/
<lifeless> bigjools: just like a bought one
<lifeless> shame about the poor backtrace
<lifeless> but thats out of our immediate control
<bigjools> lifeless: yeah, and the fact it writes them every second
<bigjools> (which is the reconnection interval)
<bigjools> but hey
<lifeless> bigjools: thats something we can throttle in oops-tools / oops-amqp
<bigjools> that'd be a nice enhancement
<lifeless> (e.g. throttle on the server side, not client - or we can do client as well, in future, but I'm more interested in server side smarts)
<lifeless> easier to deploy
<bigjools> lifeless: heh, the fallback output is a little whack
<lifeless> oh ?
<bigjools> http://pastebin.ubuntu.com/697183/
<lifeless> wtf
<jtv> bigjools: our big test run on dogfood is done; mind if I run some smaller ones?
<bigjools> jtv: sure
<lifeless> bigjools: bug for that please.
<jtv> thx
<bigjools> heh
<lifeless> also, wtf. wtf. wtf.
<bigjools> lifeless: so I should be able to have a fallback without the publisher set, right?
<bigjools> that's just the first bug
<lifeless> yep
<bigjools> ok, that saves me some code :)
<lifeless> you can drop the patch I pastebinned into your local egg for now
<bigjools> right, ta
<lifeless> night night
<bigjools> nn lifeless
<jtv> wgrant: once it's been dominated, re-dominating sid's 680 remaining packages takes 2s Â±1s.  So the optimization works.
<wgrant> jtv: Excellent.
<wgrant> jtv: Let's deploy the hell out of this.
<jtv> We haven't tried the changes to Sources.gz yet.  Not sure it's worth it.
<wgrant> I don't think it is.
<jtv> Good enough for me, really; it's a simple change.
<jtv> rvba: that leaves just your branch for bug 827608 blocking our deployment.  Do you need any help completing that?
<_mup_> Bug #827608: Sync requester isn't credited with upload <derivation> <qa-ok> <Launchpad itself:Fix Committed by rvb> < https://launchpad.net/bugs/827608 >
<rvba> jtv: Nice timing, I've /just/ QA'oked it.
<jtv> :)
<jtv> bigjools: we're done with dogfood for now.
<bigjools> jtv: ta
<jtv> About to deploy the gina optimization.
<jml> Hello
<jml> I'm trying to set up python-oops-twisted so I can address a bug reported against testtools
<jml> The instructions say to run 'python bootstrap.py'
<jml> but that doesn't work (see https://bugs.launchpad.net/python-oops-twisted/+bug/859566)
<_mup_> Bug #859566: Fresh checkout doesn't buildout <python-oops-twisted:New> < https://launchpad.net/bugs/859566 >
<jml> If I create a download-cache directory, I get told: Error: Couldn't find a distribution for 'zc.buildout==1.5.1'.
<wgrant> jml: I believe it's meant to be used with LP's download-cache.
<wgrant> jml: You may have luck with disabling install-from-cache in buildout.cfg, however.
<lifeless> or pass it the --online (not how its spelt) option to force downloading unsigned stuff from pypi
<wgrant> I assume that's set...
<wgrant> Aha.
<bigjools> I had no problems with it but then I didn't build it on its own, I pulled it into txlongpoll
<jml> wgrant: I don't have any special option set for that.
<jml> lifeless: none of the options to bootstrap seem to match that
<wgrant> jml: It's in python-oops-twisted's buildout.cfg.
<wgrant> Not your global one.
<jml> wgrant: oh right. ta.
<bigjools> does it not have a makefile?
<jml> It's fun the way every different buildout project has a slightly different way of becoming usable
<wgrant> Yep.
<bigjools> jeepers
<jml> Now buildout can't find 'oops'. Error: Couldn't find a distribution for 'oops==0.0.6'.
<wgrant> oops 0.0.7 is on pypi, not sure about 0.0.6
<lifeless> should work fine with 0.0.7
<jml> I'll tweak the settings
<lifeless> just bump the dep
<nigelb> Hrm, no european reviewer today :(
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: benji | Critical bugs: 261 - 0:[#########]:256
<nigelb> Aha!
<nigelb> benji: Could you land something to db-devel for me? I have stub's ack.
<benji> nigelb: sure
<nigelb> benji: Thanks! here's the MP - https://code.launchpad.net/~nigelbabu/launchpad/create-description-5283/+merge/76818
<benji> nigelb: are you aware of the ordering in which DB changes and code changes should be done?
<nigelb> benji: All deps must land and be in production before landing?
<nigelb> This is the first branch, I have to land code after this is deployed.
<nigelb> Oh, you'll have to land it with partial
<benji> nigelb: right, cool; I just wanted to make sure you were aware
<nigelb> benji: Thanks. I did mess up once before :)
<benji> nigelb: I don't know what "land it with partial" means.  Will you explain?
<wgrant> --incremental
<nigelb> ah, right. incremental.
<nigelb> thanks wgrant :)
<wgrant> (and yes, this patch is fine to land now and deploy in 20 hours)
<nigelb> (my suspicions on whether wgrant has written a bot with AI increases)
<benji> gotcha
<nigelb> someone did do somethng in db-devel without doing a make sample data.
<nigelb> "make sampledata"
<nigelb> Those changes are in my patch :|
<benji> nigelb: shall I mark that MP approved?
<deryck> Morning, all.
<jml> deryck: good morning.
<flacoste> morning deryck
<cr3> benji: thanks for the help on Friday, problem solved! instead of creating a proxy object, it turns out there was an actual problem in the design and after refactoring I could get the parent context for the object that needed an absolute url resolved
<benji> cr3: cool, I'm glad it worked out
<bigjools> jam: hi - apparently you did something to make the bzr server show the connecting user on the ps output
<jam> bigjools: probably at some point in time.
<bigjools> jam: I was wondering if you could point me to the right piece of code
<jam> bigjools: checking
<bigjools> thanks
<jam> bigjools: http://bazaar.launchpad.net/~launchpad-pqm/launchpad/devel/view/head:/lib/lp/codehosting/vfs/hooks.py
<jam> 'import setproctitle'
<bigjools> jam: awesome, thanks
<jam> http://pypi.python.org/pypi/setproctitle
<jam> I believe mwhudson is the one who wrote the original stuff, but I at least was exposed to it.
<sinzui> benji, I have two small branches I hope you can review: https://code.launchpad.net/launchpad/+activereviews
<jml> I've started getting these errors: http://paste.ubuntu.com/697373/
<jml> login_anonymously is not something I would normally expect to fail with a parse error.
<jml> Hmm.
<jml> Some kind of caching thread-safety thing, it seems.
<jml> now, to find which ... oh screw it I'll blow the cache away
<nigelb> benji: Hey, if you haven't already, please do.
<nigelb> I stepped out immediately after that. Sorry! :-)
<benji> nigelb: (I was at lunch) yep already done; it's winding it's way through the machinery as we speak
<benji> sinzui: sure, I'll take a look now (was at lunch)
<nigelb> benji: Thanks again :)
<sinzui> benji, I am tweaking the non-active-user-bug-mail branch. I found a comment in a test that I know how address
<benji> sinzui: ok
<bac> hi deryck
<jml> Hmm.
<jml> login_anonymously is getting corrupted again
<jml> what local xml does it need to parse?
<jml> The WADL, is the answer.
<jml> So how come the wadl gets corrupted when multiple programs are running against the same cache?
<jml> I guess the answer is that they all write indiscriminately and there's no actual thought to addressing the problem
<jml> tap tap
<jml> is this thing on?
<nigelb> nope, you're talking to yourself :P
<deryck> Hi bac
<benji> jml: a WADL race? that's not good
<benji> (but it sounds funny when you say it out loud)
<sinzui> benji, I put https://code.launchpad.net/~sinzui/launchpad/non-active-user-bug-mail/+merge/77004 back into review after updating two existing tests
<benji> sinzui: k, I'll take a look at it now
<jml> g'night all
<jml> benji: heh
<jml> benji: email sent.
 * jml has to go
<benji> sinzui: sorry, that took a while, but I'm done with https://code.launchpad.net/~sinzui/launchpad/non-active-user-bug-mail/+merge/77004
<sinzui> np. I am already working on another branch
<allenap> abentley: Do you have some time to revisit https://code.launchpad.net/~allenap/launchpad/longpoll-merge-diff-event/+merge/76407?
<abentley> allenap: sure.
<allenap> Thanks.
<abentley> allenap: why have you s/provides the expected interfaces/provides  expected interfaces/ ?
<allenap> abentley: Lint, that's all.
<abentley> allenap: test_monitor, test_run_object_events need descriptions.
<allenap> Right, I'll fix that.
<abentley> allenap: Why is there a BranchMergeProposalWithPreviewDiffDelta?
<allenap> abentley: So that merge_proposal_modified can use BranchMergeProposalDelta to figure out that nothing has changed (because it's not interested in preview_diff) and other code that is interested in preview_diff can use BranchMergeProposalWithPreviewDiffDelta.
<abentley> allenap: it seems counterintuitive that the standard version is incomplete.  If we need two versions, I suggest renaming the old one to BranchMergeProposalDeltaWithoutPreviewDiff
<allenap> abentley: Okay, I considered that but was too lazy to change all the call sites. I will unleash the sed.
<abentley> allenap: cool, thanks.
<abentley> allenap: Other than those things, it seems fine.
<allenap> abentley: Cheers, thank you :)
<sinzui> benji, do you have time to review another small branch: https://code.launchpad.net/~sinzui/launchpad/target-picker-adapters-0/+merge/77044
<benji> sinzui: sure
<sinzui> jcsackett, do you have time to mumble a bug that may not be trivial.
<jcsackett> 	sinzui: sure. bug num?
<sinzui> jcsackett, bug 857785
<_mup_> Bug #857785: pickers do not show custom icons <disclosure> <target-picker> <Launchpad itself:Triaged> < https://launchpad.net/bugs/857785 >
<Lifelrss> Flacosre
<Lifelrss> Bah. Flacoste. Adsl down. Ring housephone?
<flacoste> Lifelrss: no problem
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 261 - 0:[#########]:256
<jelmer> any reviewers in tha house?
<lifeless> sinzui: hi
<sinzui> hi lifeless
<lifeless> sinzui: can I grab a quick call with you today sometime? (otp with flacoste atm)
<sinzui> lifeless, sure. maybe in 45 minutes?
<lifeless> sinzui: sure. I have to leave here in 1 hour for a doctors visit w/Lynne
<lifeless> sinzui: so will need to be short - but we can do that :)
<sinzui> lifeless, I can talk in 15 minutes, my wife volunteered to make dinner.
<lifeless> that would be great. Please thank her *very* much
<sinzui> lifeless, shall I call you on skype?
<lifeless> please
<wallyworld> sinzui: wgrant: we having a standup today?
<wallyworld> never mind, wrong room
<StevenK> Haha
#launchpad-dev 2011-09-27
<poolie> losa ping, i'd like help qa'ing bug 855150
<_mup_> Bug #855150: excessive translation import template mails (also poor phrasing) <mail> <qa-needstesting> <spam> <translations> <Launchpad itself:Fix Committed by mbp> < https://launchpad.net/bugs/855150 >
<poolie> wgrant, lifeless, wallyworld, can you help me work out how to qa it at all?
<poolie> i'm not sure manual qa would have a good tradeoff in this case
<poolie> since there is a fairly good unit test, and the dependencies for it (branches, mail) are a little annoying on qas
<wgrant> I was not a minute away from asking you about that.
<wgrant> poolie: You can't do it with a manual upload?
<hloeung> poolie: how can I help you?
<wgrant> Without branches?
<poolie> hloeung, i'm just trying to work that out
<poolie> hloeung, can you tell me how i'd find out if the poimport cron job runs on qas?
<poolie> wgrant, ok i'll upload a tarball and we'll see
<hloeung> poolie: I've checked and it seems there isn't any poimport cron jobs for QAStaging
<poolie> could you run rosetta-poimport for me please?
<hloeung> poolie: sure!
<hloeung> poolie: https://pastebin.canonical.com/53423/
<wgrant> That looks like success.
<wgrant> There's an email about the error, but nothing about the successes.
<poolie> hloeung, also send-bug-notificatinos?
<hloeung> poolie: done
<poolie> wgrant, unless you can think of anything else i'm going to say that's qa-ok
<wgrant> poolie: It looks fine to me.
<wgrant> Lifelrss: Back yet?
<StevenK> Does Y.Assert have a isNotNull ?
<wgrant> Y.Lang.isValue?
<wgrant> false for null/undefined, true for everything else.
<wgrant> Except possibly NaN. That might be false as well.
<wgrant> I forget.
<StevenK> This is for a test, mind.
<StevenK> Y.AssertTrue(Y.Lang.isValue()); ?
<StevenK> wallyworld: ^ ?
<wallyworld> StevenK: if you are checking that variable xxx is not null and not defined, that will work
<wallyworld> but you don't need the isTrue
<wallyworld> assrtTrue
<wallyworld> or maybe you do
<wallyworld> it's in a test, so yes i think
<wallyworld> there is also isNumber, isBoolean etc
<StevenK> It's a node
<wallyworld> ah, right, then isValue i think is what you want
<wallyworld> solves the == vs === problem
<wgrant> wallyworld: Are you on top of your two QA items?
<wallyworld> wgrant: nope, finishing off something else
<nigelb> Hrm, I wonder why I havent got email from the landing last evening :|
<wgrant> wallyworld: Any ETA on the QA? I'd like to deploy in the next hourish, before sending it off to the downtime hosts tonight.
 * wallyworld sighs. i was hoping not to have to context switch :-(
 * wallyworld looks at bugs again
<wgrant> It doesn't look like it should take long :)
<StevenK> wgrant: Which revision were you planning?
<wgrant> 14041
<wgrant> Send it out to ndt+librarian2 ASAP, then ftpmaster/ppa/librarian1 tonight if nothing blows up.
<StevenK> Poor mizuho. It will be 150 revisions behind after that NDT.
<wgrant> I'd been putting off librarian1 updates until it was HA, but that could still be weeks away, given what happened on Thursday :/
 * StevenK wonders if there is any update with galapagos
<wgrant> It's only been down for more than a month :)
<wgrant> It makes https://devpad.canonical.com/~wgrant/production-revnos ugly :(
 * wallyworld stabs qas. qa would be so much easier without the timeout errors
<wgrant> wallyworld: Indeed :(
<StevenK> wgrant: You should generate pretty HTML :-P
<wgrant> StevenK: The script to generate it is, er, slightly unpleasant, due to the format of the input.
<wgrant> carob:~wgrant/bin/parse-revnos.py, if you have a strong stomach.
<StevenK> Yes, that is disgusting
<StevenK> Perl!
<StevenK> wgrant: Will you add forster in, or that can be done after?
<wgrant> StevenK: forster/crowberry can be done without downtime later.
<nigelb> StevenK: I dedicate this one to you :D https://twitter.com/#!/DEVOPS_BORAT/status/117613205576089601
<wgrant> But since spm is not here, I shall not ask too much of hloeung :)
<wgrant> Speaking of Perl.
<hloeung> wgrant: I can try do those too if you like
<wgrant> Best Practical appears to have the bzr colocated branch syntax, and are now importing even more RT code into LP :(
<StevenK> "Source of Oracle is tell me latest version of PostgreSQL can be able download from mysql.com."
<nigelb> lol
<wgrant> hloeung: I know codehosting is a pain...
<wgrant> Forgive me, Unity. I did not mean to offend you by closing Empathy.
<StevenK> Hah
<StevenK> I am disappoint. wc -l of my diff is 235
<wallyworld> wgrant: done
<wgrant> wallyworld: Thanks!
<StevenK> Can haz review? https://code.launchpad.net/~stevenk/launchpad/private-bug-unsubscribe-confirm-2/+merge/77091
<wallyworld> StevenK: i'll grab it
<StevenK> Awesomeness.
<StevenK> Or something.
<StevenK> My two garbo populators are doing nothing on prod
<StevenK> Continiously blocked by postgres or archivepublisher transactions
<wgrant> Not continuously.
<wgrant> But often.
<wgrant> I'm not sure why they're making no progress.
<StevenK> I'm trying to figure that out
<lifeless> so for archivepublisher... we should fix that ;)
<wgrant> We should.
<wgrant> It's probably process-death-row.
<wgrant> Which is now taking 1.5 hours instead of 8 minutes.
<wgrant> And yes, there's a lot of stuff that should be fixed.
<wgrant> But we cannot fix them.
<wgrant> There are no resources to fix them.
<lifeless> wgrant: i spoke with flacoste and sinzui about security / privacy and implementation
<lifeless> wgrant: I can give you a summary if you haven't had one already; the next step is for one of us to nab mrevell and run some questions by him
<wgrant> lifeless: I was about to ask if you wanted to talk about that. I discovered another larger issue overnight.
<wgrant> Discussed it with sinzui in the standup, and we have no idea how to solve it.
<wgrant> Apart from going back to 2004 and hitting people who suggest multitask bugs :)
<wgrant> lifeless: I've not had a summary of the discussions you had, however.
<StevenK> process-death-row would make sense
<wgrant> It'll be far more obvious tomorrow.
<StevenK> If it isn't p-d-r, it's backups, and if its not those two it's replication lag
<wgrant> Because they'll be using custom DB users.
<wgrant> lifeless: So, a summary would be nice :)
<wallyworld> StevenK: done, with comments :-)
<wgrant> StevenK: What if I try to unsubscribe the team that confers visibility?
<lifeless> wgrant: skype ?
<poolie> cinerama, https://bugs.launchpad.net/launchpad/+bug/860273
<_mup_> Bug #860273: private ppa 'technical details' incorrect for admins <affects-canonical-is> <confusing-ui> <p3a> <private> <Launchpad itself:Triaged> < https://launchpad.net/bugs/860273 >
<adeuring> good morning
<huwshimi> mrevell: Can you think of a better title than "Customise visible information"
<poolie> huwshimi, "show/hide"?
<poolie> (8 letters)
<poolie> lifeless, i'm going to write a braindump pre-lep for ssh oauth and git to get it off my brane
<lifeless> sure
<huwshimi> poolie: It's for choosing what bug info will appear in the list (the link opens a popup)
<lifeless> edit result/report columns
<huwshimi> lifeless: Without using the word columns?
<huwshimi> I also don't want it to sound like it will be filtering anything
<huwshimi> tricky
<huwshimi> visible properties?
<poolie> put a disclosure triangle next to the column headings?
<lifeless> huwshimi: so we're editing more than columns ?
<huwshimi> lifeless: This mockup doesn't have columns
<lifeless> huwshimi: or we're avoiding the word column ?
<lifeless> huwshimi: the search result doesn't ?
<huwshimi> lifeless: it's just for a normal listing of bugs (except that the bugs are not being displayed in columns)
<lifeless> fields ?
<poolie> dare i ask how are they being displayed?
<huwshimi> poolie: In a list
<lifeless> views, properties, attributes, fields - easy to hand synonyms
<poolie> mm
<poolie> i guess what i'm getting at is, perhaps we can do without text and just show the things that are available
<poolie> perhaps not
<lifeless> huwshimi: this is the solution for arbitrary things being included yes ? I like poolies suggestion of showing a single row 'sample' and letting folk drag/drop to-from it
<lifeless> or perhaps show a sample with greyed out fields for things not being shown and clicking on them enables that field
<huwshimi> ok, that will have to do for today. Night all
<lifeless> nn
* gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: gmb | Critical bugs: 261 - 0:[#########]:256
<lifeless> teal is sinzui, wally, wgrant, stevenk and <memory fail>
<lifeless> ?
<wgrant> lifeless: jcsackett
<lifeless> thanks
 * wallyworld wishes were were the purple team
<wallyworld> we were
<bigjools> wallyworld: could be arranged
<poolie> itym maroon
<nigelb> For a suffient bribe?
<nigelb> *sufficient
<nigelb> bigjools: YOu sound right out of Godfather there :P
<lifeless> bigjools: python-oops-twisted 0.0.2 is in trunk, I'm going to cut a release in a minute
<wallyworld> bigjools: ok, when you are out here i'll see what i can do
<lifeless> bigjools: I couldn't reproduce that wtf thing, so I've asked for you to gather some info
<bigjools> ok
<lifeless> bigjools: it may be something like 'something somewhere using cStringIO
<bigjools> I'll reproduce
<lifeless> bigjools: I also added support for filtered oopses
<bigjools> cool
<lifeless> bigjools: if its filtered it now won't call the fallback at all; if its not published it forwards the event unaltered.
<bigjools> lifeless: generally I want both
<jtv> stub: ReadOnlyLaunchpadDatabasePolicy is only for full-on read-only mode, right?  Wasn't there also some policy to get read-only transactions, but on the master store?
<jtv> We need to get object modifications in buildd-master under control so we know when we're committing what.
<lifeless> bigjools: is that endorsing my change or asking for something different ?
<bigjools> lifeless: it sounds ok, if it's not you can be sure I'll let you know, or fix it :)
<lifeless> \o/
<lifeless> The filtering is so that if you e.g. ratelimit, the fallback doesn't end up not being ratelimited.
<lifeless> the publishing is the case you identified yesterday
<lifeless> tarball on pypi now
<lifeless> bigjools: I need to chase a few other things; can you add it to the download cache yourself?
<bigjools> lifeless: excellent, I can sure
<stub> jtv: I don't recall a policy for only read-only transactions on the master store.
<jtv> :(  There's @read_transaction, but that still gives you a regular transaction (it just aborts it).
<jtv> (And actually it should probably abort even on failure)
<stub> jtv: What are you trying to do? Might be best to write a context manager that does 'set transaction_read_only to true' (or whatever it is) if necessary and resets on exit.
<jtv> Yeah.
<jtv> I'm trying to make sure that builders and builds do not get modified except from specific, well-bracketed pieces of code.
<stub> jtv: I think the only place we set transaction to read only mode is in the test harness so 'slave' connections fail writes.
<jtv> Then I suppose I could try to promote whatever we have there to something production-usable.
<stub> jtv: We can remove access to them entirely except via stored procedures?
<jtv> That may be taking it a bit too far; the code does rely on having the ORM.
<jtv> I'm not sure how far down into various class hierarchies the object changes go.
<stub> jtv: So various db users need write access to the tables, but you want to ensure modifications only happen in certain code paths.
<jtv> Yes, I think that's right.
<jtv> The latter part is definitely right.
<stub> The logic you are enforcing is too complex to do this in the Storm database classes? Or are you scared of people bypassing the ORM?
<jtv> No, not particularly worried about people bypassing the ORM.  Just don't know how to do it in Storm.
<stub> This *might* mean we need a service that is responsible for making the modifications, and everything else just gets SELECT access to the tables.
<jtv> That may already be the case.  The immediate problem is that that single service is complex and twisted.
<lifeless> jtv: properties?
<stub> Yes, so maybe easiest and best in the long run to split it into bits.
<lifeless> jtv: and/or validators?
<bigjools> lifeless: oops_twisted is not installing
<stub> We have examples for enforcing some stuff like this at the Storm level...
<bigjools> error: Setup script exited with error: package directory './oops_twisted' does not exist
<jtv> lifeless: that's approaching it from the wrong end.  The code is already there, and complex; I want to get a handle on what it's already doing.
<bigjools> lifeless: and bootstrapping doesn't work on a new checkout so I can't debug
<jtv> stub: right now it's too many small bits.  That's part of the problem, in a way.
<lifeless> bigjools: wow thats one messed up tarball
<jtv> So as the first step I want database changes explicit, and then I want to use that to make sure no unrelated changes go into the same transaction.
<lifeless> bigjools: Have I mentioned my... disdain for setuptools?
<bigjools> lifeless: :(
<jtv> stub: although to achieve that, the transactions may well get chopped into smaller bits.  But first we need to be very sure that we understand their boundaries.
<stub> Anyone know why we are emitting long poll specific events on object creation/deletion instead of general events any service can listen for?
<lifeless> bigjools: new tarball up
<bigjools> lifeless: 0.0.3?
<lifeless> bigjools: 0.0.2
<lifeless> bigjools: it had 0 downloads ;)
<bigjools> lifeless: tut tut
<bigjools> I downloaded it
<lifeless> bigjools: EPIC SHRUG
<wgrant> lifeless: You are the bane of packagers everywhere :)
<bigjools> how will I know I have the fixed one?
<lifeless> bigjools: specifically, because it was barfing on build, you can't have an egg for it, so it won't hit the failure mode of not updating for someone
<lifeless> bigjools: if it was building brokenly, it would be different
<bigjools> lifeless: fancy updating the lp code too? :)
<lifeless> bigjools: not a code problem
<bigjools> why is bootstrapping buggered?
<lifeless> bigjools: bad MANIFEST file
<lifeless> bigjools: so the 0.0.2 tarball file had no contents beyond setup.py
<bigjools> lol
<lifeless> README, PKG-INFO and an oops_wsgi directory.
<lifeless> totally epically fucked
<bigjools> BTW electrician in the house, I may lose connectivity
 * stub wonders if Storm has a facility for putting a store into read only mode.
<jtv> stub: blast.  I thought you were referring to knowledge of such a thing earlier.
<wgrant> stub: If it did, would we have *_ro? :)
<bigjools> gah Makefiles
<wgrant> stub: Can't we just use SET TRANSACTUION READ ONLY?
<wgrant> s/U//
<stub> wgrant: We create all the _ro users such as their default transaction mode is read only
<stub> So the test harness stuff is not applicable here
<stub> But 'with read_only(store):' is little effort
<stub> store.execute('show transaction_read_only').get_one()[0] for the current value, store.execute('set transaction_read_only = true') to set it...
<jtv> I could extend the @read_transaction we have now, provided we only use it in fresh transations.
<stub> jtv: if it aborts at the end, it would be a fail to use it for anything that wasn't a fresh transaction
<stub> Unless it stacks or something
<jtv> Exactly.
<jtv> Stacking it could be risky given its retry behaviour.
<lifeless> .
<jtv> Librarian uses it in one place.  Unfortunately the code seems to have celebrate obscurity, but it doesn't look as if it has fresh connections.
<bigjools> lifeless: still seeing both bugs with latest oops_twisted
<jtv> It also uses twisted's deferToThread; allenap, one thing I wondered about there is that storms are not supposed to be thread-safe.  Is that all taken care of?
<lifeless> bigjools: you've updated your versions.cfg ?
<bigjools> lifeless: I am not using LP
<bigjools> this is txlongpoll
<lifeless> bigjools: sure, but its a buildout project too right ?
<bigjools> lifeless: yeeesssss
<lifeless> bigjools: so it has its own versions.cfg, right ?
<bigjools> nope
<bigjools> that's an LP thing
<jtv> DigestSearchResource... another one of those ancient, under-documented classes that used to make our lives a living hell.  I'm sure it'll be clear to someone out there, but not to me.  :(
<stub> jtv: stores are retrieved through zstorm, which hands out a store specific to the thread. You would have to go out of your way to hand your store to another thread.
<bigjools> lifeless: I have rebuilt my entire egg from scratch, and oops_twisted 0.0.2 is in dists
<bigjools> since I specified that in setup.py ;)
<jtv> stub: does twisted keep a worker thread with a dedicated store for this kind of thing?
<lifeless> meep. Well, you may want one ;)
<lifeless> so that you don't get new releases of $stuff without warning.
<lifeless> bigjools: anyhow, run buildout with -v or something and confirm that you have 0.0.2 in use. Or check your sys.path etc
<lifeless> bigjools: you can specify versions in setup.py ?
<stub> jtv: I don't know about twisted worker threads. I just know that when you request a store, you get a store for the current thread and not a store used by some other thread.
<bigjools> Getting required 'oops-twisted>=0.0.2'
<bigjools> lifeless: of course you can
<lifeless> bigjools: anyhow, I believe you. So put a breakpoint in the 0.0.2 code and see what happes
<jtv> stub: ah, so it's on-demand.  I think that means this is safe, thanks.
<allenap> jtv: Each bit of code that is passed to deferToThread() needs to get its own store.
<jtv> And does it?  :)
<allenap> jtv: I don't know about the librarian...
<jtv> Apparently it gets its own store on demand, so that sounds like it's alright.
<lifeless> bigjools: in the 'if ids:' if block at the end of log.py
<jtv> allenap: Yeah, never mind the librarian.  This bit of code is probably from the days when we thought that cryptic code was better because it was By And For Geeks(tm).
<bigjools> ok, re-rinning
<jtv> bigjools: lather, rin, repeat.
<bigjools> jtv: FUGU
<jtv> $ dict fugu
<bigjools> jtv: like FUBU
<lifeless> mmm noms
<jtv>  fugu
<jtv>        n : delicacy highly prized in Japan but highly dangerous
<stub> Why are we emitting LongPoll specific events rather than generic events on Storm lifecycle that any process can subscribe to?
<bigjools> allenap: ^
<jtv> bigjools: thank you, that helps.  I think the other one was fgbg.
<stub> Just wondering if there is a reason, or if services that listen for new rows to be created in the database are going to be listening for misnamed events
<allenap> stub: I don't understand. The longpoll code subscribes to the generic events and then re-emits them via Rabbit.
<stub> oh... I thought I saw us explicitly emitting LongPollSomething events on Storm object creation and deletion, rather than StormSomething events.
<stub> Which might just be naming
<bigjools> lifeless: http://pastebin.ubuntu.com/697804/
<jtv> stub: not taking the risk on @read_transaction; I can't be sure what games people play with it.  A "with" sounds good.  I'll also need one that gives a temporary exemption.
<allenap> stub: There are subscription handlers for (Storm, IObject{Created,Modified,Deleted}Event) so far, so it does rely on code to explicitly emit those lifecycle events. We can add more subscription handlers for other events later, this just fits our needs so far and should fit a lot of other situations.
<stub> jtv: I don't know the details of your problem, but a pair of context managers that can be nested would be nice and potentially useful elsewhere.
<jtv> stub: yup.  By "would be nice" by the way I do not mean that I expect you to do it; I'll whip something up and if you're interested, let you know when I think it's in a reviewable shape.
<stub> allenap: As long as we don't end up emitting 3 specific messages per row updates when 1 general one would do and can be routed with rabbit.
<allenap> stub: That will be the case. By default no lifecycle events are emitted for Storm stuff; it needs to be done explicitly.
<stub> cool
<stub> Might be able to use this for real time karma updates...
<allenap> Yeah :)
<stub> Still needs the daily job if we want degradation though so not a major win unless we decide on a new design
<stub> allenap: Originally I was thinking of hooking up zope.event, but I didn't know about the Storm event model back then and I don't think we gain anything by hooking zope.event up in addition.
<stub> (Maybe Storm should be using zope.event :) )
<stub> jtv: I'm happy to review it. It should be maybe 10 lines plus boilerplate?
<jtv> stub: I'm more worried about design than I am about the code.  Who commits when.
<stub> jtv: I worry that we spend too much time working around a flawed design rather than rewriting - some of this stuff has been a problem for years and most people are too scared to mess with it. I certainly don't know enough to know if the existing design can be rescued or needs to be replaced.
<wgrant> stub: That comes up a lot nowadays...
<wgrant> But buildd-manager was rewritten like 2 years ago.
<jtv> My fingers ache to do it again, but realistically...
<jtv> See the "read-only transactions" part as a way of getting a grip on what the existing design really does.
<jtv> Once we have that under control, we'll have a much better idea of our options.
<allenap> stub: This does rely on zope.event, but there are no automagically emitted events as Storm objects change state. Storm model instances do have EventSystem which can be used to track changes at a very fine-grained level, but I think piping those out over a message queue would be like a fire hose.
<stub> allenap: Isn't that why we have this high performance messaging system ;-)
<stub> It can handle a zajillion messages per whatsit!
<allenap> stub: We have yet to see if it's high performance :)
<stub> allenap: I also considered database triggers emitting events...
<jtv> (In practice I hear it's often more like 0.6 zajillion per whatsit.)
<allenap> stub: Oh, in that case, I think we should hook into sys.settrace().
<stub> You win
<stub> Unless I suggest.... ptrace!
<allenap> Dammit!
<jtv> On a sidenote, I see that raw_connect defaults to SERIALIZABLE.  I thought it was READ COMMITTED nowadays.  Will we go REPEATABLE READ with 9.1, or upgrade to the new SERIALIZABLE?
<danilos> gmb, hi, got time for a short review? https://code.launchpad.net/~danilo/launchpad/bug-847485/+merge/77142
<gmb> danilos: Hi, sure.
<stub> wgrant was talking about serializable/read committed by default the other day. Scripts should be defaulting to read committed since they almost certainly won't handle serialization exceptions.
<jtv> Yes, I thought we made them default to read committed some 3 or 4 years ago.  So surprising to see this in raw_connect.
<stub> And one day I'll read the docs and learn what the difference between repeatable read and serializable is
<lifeless> jtv: oh, 9.1 adds explicit repeatable read ?
<wgrant> jtv: So, I've been far too deep in this stuff lately...
<stub> jtv: Is raw connect what scripts use or what the appserver eventually relies on for its connection?
<bigjools> lifeless: did you see my debugger results?
<jtv> lifeless: sort of.  It's the new name for the existing "serializable."
<lifeless> jtv: and there is a new serializable ?
<lifeless> bigjools: no
<wgrant> jtv: initZopeless, may it rest in peace, override the default to read_committed.
<wgrant> s/override/overrode/
<wgrant> jtv: All scripts called that, so scripts ended up read_committed.
<stub> its more serializable than the old serializable I hear
<jtv> lifeless: yes.  Turned out there was a purely optimistic implementation for true SQL serializability for MVCC databases.
<wgrant> jtv: While the appserver didn't, so ended up with the default in the config file: serializable.
<bigjools> lifeless: http://pastebin.ubuntu.com/697804/
<jtv> wgrant: thanks for explaining that.
<bigjools> lifeless: the report dict has no "type" entry
<wgrant> jtv: Scripts now override this explicitly.
<jtv> I say "SQL serializable" because there's been great confusion over it.
<wgrant> jtv: Rather than it being hidden in the default of one of initZopeless' arguments.
<jtv> The standard describes two symptoms that you don't want in transaction isolation: "phantom reads" and, er, another thing.
<jtv> One is basically "you've seen a row in this transaction, you read it again, and now it's changed."
<lifeless> bigjools: ok, new bug :) - what does the original event have in it ? (first line of that function, print event)
<jtv> The other is, if I recall correctly, rows not suddenly appearing in or disappearing from the results of your query.
<jtv> SQL described the isolation levels in terms of the exclusion of these two symptoms, and said that neither can happen in SERIALIZABLE.
<jtv> So that's what postgres implemented.
<bigjools> lifeless: http://pastebin.ubuntu.com/697815/
<jtv> It didn't have the changing rows, so two of the lesser isolation levels (read uncommitted & repeatable read) were utterly meaningless in postgres.
<jtv> Instead you always got one of the better isolation levels.
<jtv> But then it turned out that what SQL said about phantom reads etc. in SERIALIZABLE was descriptive, not definitive.
<bigjools> lifeless: different problem, *same* bug :)
<stub> which is the sort of behavior ODBC encoded in its api (you get the isolation you requested or better)
<jtv> The *definition* of SERIALIZABLE is that the result must be as if no two transactions overlapped in time.
<lifeless> bigjools: same top level symptom agreed.
<jtv> And so postgres 9.1 has an optimistic technique to guarantee serializability, at the cost of more serialization failures obviously.
<lifeless> bigjools: what has me confused here though is how the type key is missing
<jtv> But no new locks, which is incredibly cool in itself.
<jtv> REPEATABLE READ in postgres actually guarantees more than it does in SQL, but it was the next step down for the old, dishonoured SERIALIZABLE implementation.
<stub> At this point I have no idea if the appserver would benefit or suffer from the new isolation level. Scripts will remain with read committed by default.
<lifeless> bigjools: you've got a tb_text and a time, which  means emit didn't crash
<lifeless> bigjools: can you print config.on_create
<stub> I suspect we need to instrument our transaction retry handling to see what sort of genuine overhead we get with the extra protection
<jtv> Might be useful to know at any rate.
<stub> Yup
<bigjools> lifeless: what scope?
<bigjools> it's not in that func
<lifeless> bigjools: self.conf
<lifeless> bah
<jtv> FWIW the only paradoxes that the existing "serializable" leaves us open to involve cross-table consistency.
<bigjools> ah
<lifeless> self.config
<bigjools> lifeless: you want the function or it's invocation?
<bigjools> its
<lifeless> its a list of functions, I hope
<lifeless> self.config.on_create
<bigjools> 2011-09-27 12:30:01+0100 [-] (Pdb) [<function attach_exc_info at 0x2ba5488>, <function attach_date at 0x2ba5410>, <function copy_key at 0x2ba5230>, <function copy_key at 0x2ba52a8>, <function copy_key at 0x2ba5320>]
<lifeless> ok, so we need to look at whats going on with emit
<lifeless> line 58
<lifeless> it should branch into the 'if 'failure' in eventDict: block
<lifeless> and before we call
<lifeless> report = self.config.create(context)
<lifeless> our context should have an exc_info key with a (type, value, tb) tuple in it
<bigjools> lifeless: I think you need to re-create this locally
<lifeless> bigjools: yeah, probably.
<bigjools> it's not hard
<lifeless> bigjools: I have tomorrow off
<lifeless> bigjools: for baby stuff, but I'll see what I can do
<bigjools> I'm in hospital later :p
<lifeless> bigjools: can you shoot me a mail with 'do this you daft bugger and it should break for you' instructions ?
<bigjools> yarp
<lifeless> defensive programming says we should tolerate the type etc being missing
<lifeless> and I'll do that
<lifeless> but we also want good output, so we need to figure out whats up.
<bigjools> lifeless: I'll put it on the bug
<lifeless> bigjools: a new one please!
<gmb> danilos: approved.
<lifeless> bigjools: it really is a different issue, though its hitting the same area of code
<bigjools> lifeless: you didn't close the old one, and I consider it still unfixed
<lifeless> bigjools: there may be multiple root causes
<bigjools> bugs are to report symtoms, not causes
<lifeless> sure, and your symptoms have changed :)
<bigjools> not at all, it crashes in exactly the same way AFAIAC
<lifeless> bigjools: if you have no publisher, it shouldn't crash now
<lifeless> bigjools: and I *know* you have a publisher here, because I can see the publisher assigned OOPS id
<bigjools> the d o u b l e spaced log is still happening too
 * bigjools caves in
<lifeless> bigjools: sure, and that hopefully the repro instructions will let me see
<bigjools> for a quiet life
<lifeless> bigjools: try without --date-dir=... or whatever the option is - I bet it won't crash.
<bigjools> lifeless: it isn't, correct
<lifeless> so, this is a flip in your symptoms :)
<lifeless> now with a publisher, its barfing, and thats because attach_exc_info isn't attaching the info for some really odd reason
<lifeless> which I'll track down, and separately make it not crash if that happens.
<bigjools> https://bugs.launchpad.net/python-oops-twisted/+bug/859545
<_mup_> Bug #859545: Fallback code corrupts the output <python-oops-twisted:Triaged> < https://launchpad.net/bugs/859545 >
<lifeless> bigjools: gl with the op
<bigjools> added it there
<bigjools> lifeless: ta
<lifeless> from pypi ?
<lifeless> {from where should I grab the gg}
<lifeless> bigjools: ^
<bigjools> https://launchpad.net/txlongpoll
<bigjools> not on pypi
<bigjools> (yet)
<lifeless> https://bugs.launchpad.net/python-oops-twisted/+bug/860490
<_mup_> Bug #860490: oops reports with no type/value crash the fallback reporting code <python-oops-twisted:Triaged> < https://launchpad.net/bugs/860490 >
<lifeless> bigjools: http://pastebin.com/GrvVx1ZM is the direct fix (but we need to see why you aren't getting those values regardless)
<jelmer> hmm, am I supposed to be able to upload to maverick-proposed if it is for a package in a package set that is in my permission set?
<wgrant> jelmer: Remember that packagesets and their permissions are series-specific.
<jelmer> wgrant: ah, that must be it
<jelmer> wgrant: I figured I would've been added to the packageset in all active series but that doesn't appear to be the case
<jelmer> and I could swear I uploaded to lucid-proposed earlier, but apparently not.
<StevenK> nigelb: r14041 is now live everywhere, so your DB patch can land.
<lifeless> adeuring: your wiki docs are confusing :)
<lifeless> column1 > value1 AND column2 > value2 -> that would be wrong, and the implementation using tuples now doesn't it ?
<adeuring> lifeless: any suggestions for improvements?
<lifeless> (column1, column2) > (value1, value2)
<adeuring> right
<lifeless> adeuring: that was the only thing
<lifeless> adeuring: nice stuff
<adeuring> lifeless: thanks :)
<deryck> Morning, everyone.
<nigelb> StevenK: \o/ Thanks!
<nigelb> StevenK: Do I propose an MP?
<StevenK> nigelb: Yes, put up an MP for it.
<wallyworld> sinzui: hi. this bug subscription thing is a bit of a mess. if you agree with my branch to stick it behind a feature flag as requested by rob, would you be able to push it to ec2 for me? i believe folk are keen to see it land asap but i'm quite tired now and need sleep.
<sinzui> wallyworld, The bug looks to be invalid. I would not want to land any branch that make Lp lie to 99% of users
<wallyworld> sinzui: np. i was following orders :-) i'll let you discuss it with rob, matthew etc.
<sinzui> wallyworld, does you branch revert Lp to lie?
<sinzui> wallyworld, your branch looks like it is changing flags, which is not what the bug talks about
<wallyworld> i think they just wanted launchpad back to how it was 48 hours ago - the branch does tha by putting the new stuff behind a ff
<wallyworld> sinzui: yes, i commented on the bug to change the description
<sinzui> okay. I will review the branch an land it if I am satisfied that the correct behaviour is still in the code base
<wallyworld> originally i was proposing a compromise or whatever, but then it was decided just to stick it all behind a ff just to revert lp
<wallyworld> so that the ubuntu folks wouldn't get very upset
<sinzui> wallyworld, I am approving your branch and will land it now
<wallyworld> thanks! i'm frustrated somewhat by the confusion
<wallyworld> but it seemed from irc that we needed to take this action quite urgently, hence i staryed up to catch you and get your +1 on it. we can discuss more tomorrow at the standup i guess
<nigelb> StevenK: thanks! Will do
* gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 261 - 0:[#########]:256
<jcsackett> sinzui: have a few moments to mumble?
<sinzui> yes
<sinzui> jcsackett, 770213
<sinzui> jcsackett, bug 770213
<_mup_> Bug #770213: globalsearch's submit button has no value, thus is strangely represented for screen reader users as unnamed <trivial> <wai> <Launchpad itself:Triaged> < https://launchpad.net/bugs/770213 >
<nigelb> benji: hi
<benji> nigelb: hi
<nigelb> benji: I didn't get a success/failure email for yesterday's landing. Did something go wrong?
<benji> nigelb: it may well have; I've had trouble lading things of late.  I'm doing another run on a different branch now; once I figure out the problem I'll re-run your branch.
<nigelb> benji: cool, thanks!
<benji> np
<mtaylor> hey guys - bugs email interface - setting fix committed doesn't seem to work if the bug is attached to multiple projects
<mtaylor> https://bugs.launchpad.net/nova/+bug/854614
<_mup_> Bug #854614: metadata service local-hostname is not fqdn <server-o-rs> <OpenStack Compute (nova):Fix Committed by smoser> <nova (Ubuntu):Fix Committed by smoser> < https://launchpad.net/bugs/854614 >
<mtaylor> see the email from our gerrit, and then that the status did not update from the email
<mtaylor> nevermind - jeblair found the affects feature (or already knew about it, he's smart like that)
<sinzui> jcsackett, do you have pqm power now?
<jcsackett> sinzui: alas, no. i tried several combinations of settings to no avail, and then realized it was getting on in the afternoon and i hadn't had lunch.
<benji> jcsackett: what kind of pqm problem are you having?  I'm having issues with it too.
<jcsackett> benji: pqm-submit is throwing an smtp error.
<benji> hmm, so you're not using ec2 land?
<jcsackett> benji: no, i have other problems with ec2 land. :-P
<jcsackett> since some issues when i updated to oneiric i've been essentially unable to land. it's a bit frustrating.
<jcsackett> sinzui has been helping me diagnose, but we have not yet solved the problems.
<sinzui> jcsackett, maybe you should paste the error
<sinzui> and maybe use canonical's pastebin
<jcsackett> sinzui: https://pastebin.canonical.com/53486/
<jcsackett> not terribly informative.
<sinzui> jcsackett,  and you are using the same smtp_* rules as I have in my bazaar.conf?
<jcsackett> sinzui: yup.
<sinzui> do you have other directly matching rules?
<jcsackett> you mean like via locations.conf?
<jcsackett> i have some smtp_ stuff set there, but it's the same as in bazaar.conf
 * jcsackett takes another look,
<bac> abentley: i took care of that private project
<abentley> bac: thanks!
<lifeless> morning
<abentley> lifeless: you know how we're upgrading all branches to 2a-based formats?  loom branches can't even be upgraded to other loom formats.
<abentley> https://pastebin.canonical.com/53491/
<lifeless> they used to be able to
<lifeless> I don't know whats changed there, but I assume its a bzrlib core thing
* StevenK changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK | Critical bugs: 261 - 0:[########*** stack smashing detected ***: ./lp terminated
#launchpad-dev 2011-09-28
<poolie> hi
<wgrant> Morning poolie.
<wgrant> They're multiplying.
<poolie_> poolies?
<wgrant> That's the one.
<wgrant> Or two.
<huwshimi> wgrant: And now there are none
<wgrant> :(
<wgrant> jtv revived Zopeless stuff in his megalint again.
<StevenK> Oh, bleh
<StevenK> nigelb: 1) Your branch doesn't seem to include any changes; 2) It should be targetted against db-devel
<wgrant> 46 conflicts encountered.
<StevenK> wgrant: Whee
<StevenK> Sigh, it does include changes.
<StevenK> MPJ has lost its mind again
<wgrant> StevenK: Link?
<StevenK> wgrant: https://code.launchpad.net/~nigelbabu/launchpad/kill-statusexplanation/+merge/77211
<wgrant> StevenK: It doesn't have any changes.
<wgrant> It was merged then reverted.
<wgrant> nigelb will need to revert the revert.
<StevenK> 41	- var warning = overlay.one('.private-bug-warning');
<StevenK> 42	+ warning = overlay.one('.private-bug-warning');
<StevenK> lol?
<StevenK> Oh, let me guess. In JavaScript 'warning' is a reserved word?
<nigelb> wgrant: wait, revert the revert?
<nigelb> thta sounds convoluted :)
<StevenK> nigelb: It's true
<wgrant> nigelb: Reverting in a DAG-based DVCS involves doing a reverse-cherrypick of the revison that you want to revert.
<wgrant> nigelb: So to revert the revert, it's probably easiest to do a reverse-cherrypick of the reversion revision.
<poolie> mwhudson, lifeless, huwshimi, i drafted https://dev.launchpad.net/LEP/SSH_OAuth based on my discussion with robert yesterday
<poolie> not planning to run with it at the moment but thought i'd get it down
<StevenK> So I have brutally hacked twisted to fix the text/html Content-Type pollution, do I tar it up and stuff it into the download-cache, or do I need to do more?
<nigelb> wgrant: Let me try this.  (lost power for an hour)
<wgrant> StevenK: Is it the fix that they've applied to trunk?
<StevenK> wgrant: It is
<StevenK> wgrant: I had to apply it manually since patch couldn't work it out
<wgrant> StevenK: you'll need to create the tarball using whatever mechanism we use for Twisted, add it to download-cache, update the version in versions.cfg, and hope that you got everything right.
<StevenK> Yes, it's the "create the tarball using whatever mechanism we use for Twisted" that I'm concerned about
<wgrant> I normally try a few different things, and then take the one that looks the most like the old tarball.
<StevenK> It looks like a source tarball
<mwhudson> poolie: nice
<mwhudson> poolie: fwiw, ssh is extensible enough that we could define an auth_oauthtoken method or something
<mwhudson> poolie: you'd have to use paramiko rather than openssh for that sort of game though
<mwhudson> (tbh just using the token as a passphrase would seem to be ok)
<StevenK> wgrant: Just tarring up what I had looks very similiar
 * StevenK runs bzr add, bzr ci, because what could possibly go wrong
<wgrant> StevenK: Don't commit until you've tested it..
<StevenK> Test it how?
<wgrant> Add it to versions.cfg, make, and see if LP starts
<poolie> mwhudson, yeah adding a new mechanism was my first thought too
<poolie> seems cleaner; robert suggested just pretending it's a password may be easier
<poolie> perhaps also we would log in as mbp+oauth@bazaar.launchpad.net and do it there
<poolie> bit kludgy perhaps
<poolie> it's basicalyl bug 297398
<_mup_> Bug #297398: using ssh keys to connect to bazaar.launchpad.net confuses users a great deal <confusing-ui> <lp-code> <Launchpad itself:Triaged> < https://launchpad.net/bugs/297398 >
<poolie> mwhudson, ok that's all i'm planning to actively do on it
<poolie> if you want to work on it i'll help though
<mwhudson> poolie: i guess i should try to land my feature flags xmlrpc branch again
<poolie> oh i thought it did land
<poolie> that would be great in its own right
<mwhudson> it did, and was reverted because it broke feature flags in the webapp
<mwhudson> changing launchpad is hard :/
<poolie> :/
<poolie> at least this patch will make it incrementally easier
<nigelb> mwhudson++
<nigelb> :)
<poolie> probably somebody with more zope blood on their hands could have made flags provide global state in a better way than i did
 * mwhudson runs ec2 land
<nigelb> Hrm, what's with me and db-devel. Second patch also seems to be having issues.
<StevenK> It does?
<poolie> does anyone disagree with me calling bug 858605 untestable?
<_mup_> Bug #858605: launchpad sends mail for people with an inactive account <mail> <qa-untestable> <Launchpad itself:Fix Committed by mbp> < https://launchpad.net/bugs/858605 >
<StevenK> Bleh, my source tarball still proclaims itself as Twisted 11.0.0
<nigelb> Argh. How do I revert?
<poolie> revert what?
<nigelb> I need to revert a revert.
<poolie> tell me more?
<mwhudson> nigelb: find the revision that reverted your change
<mwhudson> run bzr merge -r $rev..before:$rev .
<nigelb> Well, I overeagerly landed a db-devel change, which wgrant reverted. I need to revert that revert.
<nigelb> ah, I can find the revision number in the bug.
<nigelb> Let me hunt it down.
<nigelb> mwhudson: that didn't work. maybe my revno was wrong.
<nigelb> What am I doing wrong - http://paste.ubuntu.com/698277/
<mwhudson> well, conflicts don't necessarily mean you are doing it wrong
<mwhudson> nigelb: looks like you forgot the '.' at the end though
<nigelb> ah
<nigelb> mwhudson: Worked. Thanks!
<mwhudson> nigelb: cool
<nigelb> StevenK: do you need stub's ack to land that?
<nigelb> Or can you ack it on the basis of the earlier "okay"
<StevenK> nigelb: It is easier if you have DB sign-off again
<nigelb> okay
<nigelb> I wonder what timezone stub is living in today.
 * StevenK renews his hatred of Twisted
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-860920/+merge/77271 desires your perusal.
<nigelb> wgrant: Very dry branch name ;)
<wgrant> nigelb: Yeah, I'm mostly adding code, unfortunately.
<wgrant> But I will hopefully delete half of our test layers this weekend :)
<nigelb> ...
<nigelb> What's going away? Zopeless?
<wgrant> Zopeless went away on Monday.
<wgrant> But there are still *ZopelessLayer.
<wgrant> I'm hopefully going to merge them into *FunctionalLayer.
<StevenK> wgrant: Can you explain the changes to configure.zcml?
<StevenK> The addition is fine, the removsls
<StevenK> Sigh
<wgrant> StevenK: DistributionSourcePackage was unique among IBugTarget implementers in that it named the attributes on IBugTarget explicitly, rather than just allowing the whole interface.
<wgrant> Since I was adding a new attribute to the interface, rather than add another name I opted to follow the rest of the implementers and allow the whole interface.
<StevenK> Which resulting in removing a whole slate of stuff from the ZCML. Right.
<wgrant> Right, since you can't declare multiple permissions for the one name, even if those permissions are identical.
<StevenK> wgrant: r=me
<wgrant> Thankyou sir.
 * StevenK goes back to bashing his head against Twisted or Zope
<wgrant> Oh?
<StevenK> You know the latter already, the former is trying to get my tarball of Twisted to identify itself with a different version
<StevenK> Can't find the arguments to setup.py, or even if that will help one iota
<StevenK> And Twisted's build system is worse than ours.
<wgrant> wallyworld: Is the deval failure yours?
<wgrant> devel
<wgrant> https://lpbuildbot.canonical.com/builders/lucid_lp/builds/1414/steps/shell_6/logs/summary
<wallyworld> wgrant: don't know. haven't seen it yet. let me look
<wallyworld> wgrant: could be. but how did it pass ec2 i wonder
<wgrant> wallyworld: It's possible that you conflicted with megalint-II
<wgrant> eg. it revived a test that I deleted on Monday.
<wallyworld> ah. oh well. i'll update from devel and fix
<wgrant> Thanks.
<wgrant> It may not be yours, but it certainly looks likely...
<wallyworld> wgrant: curtis landed the branch for me late last night after i went to bed. i assume it was put through ec2
<wgrant> I saw he made a last-minute change.
<wgrant> He appeared in the blamelist of the merge.
<wallyworld> wgrant: passes locally with latest devel
<wgrant> wallyworld: That is extremely unfortunate.
<wallyworld> wgrant: yes. let me look at the source code vs the test failure output
<wallyworld> wgrant: i get the same error locally if i comment out the settin gof the feature flag in the doc test
<wallyworld> so an initial guess is that the feature flag was ignored by the doc test
<wallyworld> even though it was set
<wgrant> wallyworld: The doctest isn't run more than once?
<wallyworld> not that i know of
<wallyworld> but the part of the doc test that needs the ff is inside a set/clear block
<wallyworld> wonder if it's a genuine issue or a spurious failure
<wallyworld> wgrant: does it fail for you locally?
<wallyworld> bin/test -vvct initial-bug-contacts.txt
<wgrant> No :(
<wallyworld> wgrant: so resubmit and hope for the best?
<wgrant> wallyworld: Force the build when it fails? I guess so.
<wallyworld> yeah, that what i meant sorry
<wallyworld> maybe jenkins would build it ok :-)
<wgrant> Heh
<wallyworld> so ec2 is happy and it runs locally. stupid buildbot
<wgrant> Wow.
<wgrant> The rabbitmq people have made their build system even worse.
<wgrant> 2.3.1 was already one of the most distro-hostile I've seen, and 2.5.0 is worse...
<StevenK> wgrant: How so?
<wgrant> StevenK: For starters, see http://hg.rabbitmq.com/rabbitmq-mochiweb/file/b41f8ab516d6/Makefile
<wgrant> StevenK: Yes, the Makefile in the root directory of the package does one thing: include umbrella.mk from outside the package.
<wgrant> The rabbitmq-mochiweb test suite is also convinced that it wants to build its own rabbitmq-server.
<wgrant> Because dependencies are hard, I guess.
<wgrant> They seem to have basically rewritten the build system twice between 2.3.1 and 2.5.0, so my old fixes don't work :(
<wgrant> Ahh.
<wgrant> The plugin in Ubuntu (rabbitmq-stomp) works around this by not running the test suite.
<wgrant> But I got it working with 2.3.1... so I will do it again.
<wgrant> Perhaps all Erlang developers are crazy.
<StevenK> I'd agree with that.
<StevenK> For starters, they use Erlang.
<wgrant> Meh, Erlang has some pretty nice bits.
<wgrant> Why will people not stop writing their own shitty application-specific packaging systems!?
<wgrant> Oh cool, they're now including webmachine stuff in rabbitmq-mochiweb.
 * wgrant sobs.
 * jtv consoles wgrant
<jtv> "There, there.  This is all part of growing up.  Eventually you'll learn that it all goes away for a while after large quantities of beer."
<jtv> Yeah, I know.  I'm a natural at this.
<wgrant> Heh
 * StevenK kicks LaunchpadSearchView for being horrid.
<nigelb> jtv++
<jtv> nigelb: that returns the old value of jtv.
<jtv> Although it does increase me, for which I am grateful.
<nigelb> heh
<jtv> Now, what are we talking about?
<nigelb> Beer?
<jtv> Ah!
<adeuring> good morning
* danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK, danilos | Critical bugs: 261 - 0:[########*** stack smashing detected ***: ./lp terminated
<lifeless> wgrant: how do you build txlongpoll from tarball? Perhaps julian means build from branch ?
<wgrant> lifeless: What might Julian mean where?
<lifeless> https://bugs.launchpad.net/python-oops-twisted/+bug/859545
<_mup_> Bug #859545: Fallback code corrupts the output <python-oops-twisted:Triaged> < https://launchpad.net/bugs/859545 >
<wgrant> lifeless: I presume he means from the branch, rather than an egg.
<rvba> lifeless: I also think he meant from the branch.  Also note that we renamed the generated executable from twistd to txlonpoll.
<wgrant> rvba: Hm, why?
<wgrant> That seems very confusing.
<rvba> huwshimi: Hi!  Thanks for the longpoll icons.  I'll see what the others have to say but I like them :).
<lifeless> there is a separate txlongpoll executable that just runs it isn't there?
<rvba> lifeless: that's is still in the works AFAIK.
<rvba> wgrant: why confusing? The goal was to avoid clashing with other twistd services.
<wgrant> rvba: 'bin/txlongpoll amqp-longpoll' is more confusing.
<wgrant> twistd is slightly more obvious.
<lifeless> the problem will be file collisions I suspect
<wgrant> When included in LP, sure.
<rvba> True
<wgrant> But that's a matter for LP's buildout.cfg.
<wgrant> Not txlongpoll'
<wgrant> s.
<wgrant> wallyworld: Hm.
<wgrant> wallyworld: My ec2 run has just failed with that error...
<wallyworld> wtf?
 * wgrant runs the whole layer locally.
<huwshimi> rvba: No problems!
<rvba> huwshimi: one remark:
<rvba> huwshimi: allenap noted that the failure icon looks a little bit like the Ubuntu Circle of Friends.
<huwshimi> rvba: Ah, good point. I might make it a little less like that :)
<huwshimi> rvba: I'm just heading off, if you have any other comments can you send me an email and I'll get to it tomorrow.
<allenap> huwshimi: Fwiw, I like the spinning circle :)
<huwshimi> allenap: OK cool :)
<huwshimi> night all
<StevenK> jml: O hai
<jtv> cjwatson: are debian imports working normally for you?  We got gina's run time back down to half an hour or so, and everything goes through proper domination now.  Packages deleted from Debian also have their publications deleted.
<cjwatson> jtv: the last thing I uploaded to Debian (yesterday evening) has been imported, which is about all I can say really
<lifeless> bigjools: looking at txlongpoll
<cjwatson> hmm
<lifeless> bigjools: why do you have a custom log *and* twistd.log ?
<cjwatson> jtv: https://launchpad.net/debian/+source/debian-installer-utils - is the 1.84 "not published" there normal?
<cjwatson> on the front page?
<jtv> cjwatson: I'll have to check up on that -- otp now, gimme a few
<wgrant> cjwatson, jtv: gina wasn't setting datepublished for a while. We should set it to datecreated where it's not set.
<wgrant> bigjools: ppa:wgrant/rabbitmq has rabbitmq-management 2.5.0 for oneiric now. I had to disable the full functional tests, since the new plugin build system is even more distro-hostile than the old one, but the unit tests all pass and it works fine.
<bigjools> lifeless: are you running it with -n ?
<bigjools> wgrant: \o/
<lifeless> bigjools: yes
<bigjools> wgrant: awesome, thanks
<bigjools> lifeless: that buggers up logging for some reason
<lifeless> bigjools: not at all
<jtv> cjwatson, wgrant: it does indeed look like datepublished was simply not set at that point (should've been done in May for this one I guess).  More interesting is that 1.84's publication in sid is Published; that should only be the case if 1.84 is still occurring in sid's Sources.gz.
<lifeless> bigjools: -n makes it log to stdout, and disables the default twistd.log
<lifeless> bigjools: if you run without -n, you get *two* logs
<bigjools> ah ok
<bigjools> lifeless: in that case, the FileLogObserver is not being added correctly
<lifeless> bigjools: its because the default setup includes another observer
<lifeless> bigjools: see https://bugs.launchpad.net/txlongpoll/+bug/861234
<bigjools> I think I need to add my code back that adds it separately
<_mup_> Bug #861234: logs to both custom log and twistd.log <txlongpoll:Triaged> < https://launchpad.net/bugs/861234 >
<lifeless> bigjools: the mylog observer is  being added just fine
<bigjools> lifeless: yeah, the bug describes what I meant :)
<lifeless> I have fixed the extra spaces thing
<lifeless> I can't reproduce the other failure yet
<lifeless> bug 860490
<_mup_> Bug #860490: oops reports with no type/value crash the fallback reporting code <python-oops-twisted:Triaged> < https://launchpad.net/bugs/860490 >
<bigjools> that line used to be in the code but I took it out by mistake when I converted to using oops_twisted
<bigjools> that's weird
<lifeless> bigjools: https://bugs.launchpad.net/python-oops-twisted/+bug/860490/comments/6
<_mup_> Bug #860490: oops reports with no type/value crash the fallback reporting code <python-oops-twisted:Triaged> < https://launchpad.net/bugs/860490 >
<bigjools> lifeless: I can't figure out wtf is wrong then, it's 100% reproducible here
<bigjools> lifeless: when I break on that method, the first call succeeds, the 2nd fails
<bigjools> with the deferred failure
<lifeless> it gets called once per connection attempt for me
<bigjools> there's the difference then
<bigjools> I exepct you're getting a different failure
<bigjools> have you got the same versions of everything I wonder
 * bigjools otp in a bit
<lifeless> anyhow, I'm going to implement the defensive programming solution
<bigjools> ok
<bigjools> without the bare except I hope
<lifeless> but we'll still need to figure out why you are not getting an exception data there
<lifeless> because that will devalue your oops reports
<wgrant> jtv: 1.85 is new today, so 1.84 still being around is not surprising.
<bigjools> jtv, wgrant: I am about to initialise p-series on DF, are you guys done with all the long-running stuff you were doing on there?
<jtv> I am.
<wgrant> I'm not using it.
<bigjools> ta
<wgrant> So feel free to break it :)
<jtv> Concur.
<jtv> wgrant: whether it's surprising is one thing, but I'm interested in another: is it actually the case?
<wgrant> jtv: Yes, both versions are in http://ftp.debian.org/debian/dists/sid/main/source/Sources.gz
<jtv> Good!
<jtv> cjwatson: you should also see older package releases becoming Superseded, but the domination we implemented for gina does support multiple live versions in one release / pocket / archive.
<cjwatson> Right.  (When are we going to get similar behaviour of keeping multiple sources around until everything builds, I wonder ... or, more importantly, multiple arch: all)
<jtv> The underlying mechanics are there now, for both Gina's domination and regular domination.
<wgrant> bigjools and I have some disagreements on how that should be done.
<jtv> The hard part for regular domination is getting the right information about what versions should be considered live, and feeding it into those mechanics.
<lifeless> bigjools: what try:except ?
<lifeless> bigjools: 0.0.3 pushed
<lifeless> bigjools: (and on pypi)
<bigjools> ta
<lifeless> bigjools: we need to sort out whats up still, and as I can't reproduce yet, that means stepping through some with you :)
<bigjools> ok will need to be tomorrow
<lifeless> bigjools: sure hting
<bigjools> (still otp)
<bigjools> jml: do you know if there's a way to stop a Deferred firing until a write transaction is finished?
<lifeless> bigjools: wrap it in a deferred that will tie into the transaction
<bigjools> we want to block any deferred firing until a txn is done, so if a callback calls code that returns deferred we want the txn done before that deferred fires
<lifeless> I don't see any possible way to do that
<bigjools> we want to make sure txn boundaries don't cross callbacks, basically
<jtv> We'd be fine if we had a way to stop twisted from giving any time to another thread of execution while we're in a given stretch of code.
<lifeless> a deferred is equivalent to a function call - it would be like making *all* function calls in any thread block based on some other state
<wgrant> bigjools: Aren't transactions restricted to inside the function?
<bigjools> this is a problem in the buildd-manager
<wgrant> bigjools: So a transaction won't be in progress when it returns to the reactor...
<lifeless> bigjools: you could push the db access into the API and use that instead; thats the long term plan *anyway* (per SOA & data encapsulation)
<jtv> The core problem, I think, is that we want to be sure in a particular stretch of code that we don't accidentally call something that will do anything deferred.
<bigjools> lifeless: yes, but we need a very fast api first :)
<lifeless> bigjools: we have one
<wgrant> Also, pushing this to the API would just make things even worse.
<lifeless> bigjools: the overhead for a single call is very low
<wgrant> The problem is not that transactions are being held around. It's that we're doing data modification in places that we shouldn't be.
<bigjools> lifeless: xmlrpc yes, webservice no
<wgrant> Eliminating transactions from that just makes it harder to track down.
<lifeless> bigjools: !cite - I've looked, and the webservice overhead is low
<nigelb> lifeless: can do you have time to ack a db patch?
<lifeless> bigjools: also, internally I'd be suggesting using xmlrpc *anyway* as we have that infrastructure setup.
<bigjools> lifeless: not low enough for this
<nigelb> s/can you/do you/
<lifeless> nigelb: no, I'm on annual leave today :P also, see policy - stub approves except when he's not here.
<lifeless> bigjools: is 2ms low enough ?
<bigjools> no
<bigjools> that's slow
<lifeless> bigjools: because thats the size it was looking like last time I compared the delta from xmlrpc to json api
<bigjools> if it were 2us I'd be happy
<lifeless> bigjools: that doesn't make any sense to me - we can't even query the db twice in 2ms.
<nigelb> lifeless: oh. right. wednesday. Well, stub hasn't been here yet. Which is why I asked. I'll wait for him :)
<bigjools> so you want to add more latency?
<lifeless> bigjools: *if* it had to, I could tolerate 8ms per slave build, which would allow for 4 API calls in the critical path for dispatching and completing a build
<lifeless> bigjools: but we're not going to get clarity by tossing sketches back and forth on IRC
<bigjools> lifeless: I used to work in sub-millisencond latency over networks. If you take the Db out of the equation, replacing an internal python call with a 2ms latency remote call doesn't sound clever
<jml> jtv: you can 'stop Twisted from giving any time to another thread of execution' by not using threads and doing a blocking call
<jtv> jml: yes I had figured that bit out, thank you
<bigjools> jtv: ^ that is why I said not to call them threads :)
<jtv> (notice irony there)
<lifeless> bigjools: of course, but you don't do a literal transcription just replacing db calls with api calls.
<jml> jtv: ok.
<lifeless> bigjools: that wouldn't work well for many reasons, transactions being one of them
<jtv> I'm not talking about threads, of course, merely about threads of execution in twisted.
<lifeless> bigjools: so measuring the performance by estimating overhead from a direct transcription isn't a good estimator
<bigjools> lifeless: ok, this is a conversation better left for in-person I think
<jml> jtv: I'm not interested in having an ironic conversation right now.
<jtv> (Seeing how much taller than lifeless bigjools is)
<jtv> jml: neither am I.  What I'm trying to do is ensure that twisted does not give any time to another job deeper down in my call tree.
<bigjools> lifeless: I am sure we can come to a good agreement somewhere, but it's hard to explain without waving arms around
<lifeless> bigjools: yup, I get that
<wgrant> wallyworld: bin/test -vvct initial-bug-contacts.txt -t bugtracker-tokens.txt
<lifeless> jtv: don't return from your function then.
<wallyworld> wgrant: you want me to run those?
<lifeless> jtv: (and don't yield either)
<wgrant> wallyworld: That reproduces the failure.
<wgrant> wallyworld: We have a test isolation issue.
<wallyworld> wgrant: bugtracker-tokens wasn't even changed in that branch
<wgrant> wallyworld: Correct.
<wallyworld> so somehow the ff is not being homoured
<jtv> lifeless: I don't want to "just not do" the thing I want to prevent; I want to establish some certainty that it's not inadvertently happening somewhere deeper down in the call tree.
<wallyworld> in the failing doctest
<wgrant> wallyworld: Right, presumably bugtracker-tokens is corrupting the state.
<wallyworld> that sucks :-(
<wallyworld> has this happened before, the same way?
<wallyworld> is there something we can recall that will help solve it?
<wgrant> Not identical, but we do occasionally have stuff like this.
<wgrant> I'm tracking down the problematic call.
<wallyworld> ok
<wallyworld> i'm hacking javascript. for the disclosure mockups
<wallyworld> let me knoe if i can do anything
<wgrant> Ah, it looks like it's XMLRPCTestTransport.
<wgrant> That is an evil piece of code. I recall it from my Python 2.7 experiments.
<jtv> lifeless: don't forget to "make lint" your branches!  From a quick glance at your self-approved branch, I get the impression that there will be some warnings in there.
<jtv> Or is it not a Launchpad branch?  That'd explain why it ended up in my main mailbox.
<jtv> stub: as promised... https://code.launchpad.net/~jtv/launchpad/pre-717969/+merge/77299
<stub> jtv: I'm not sure I like DatabaseTransactionPolicy having an implicit commit. It goes against your reasoning in the MP synopsis, and means you can't mix read-only and read-write code paths in a transaction.
<jtv> stub: I feel the same, but didn't see support in the underlying APIs for a non-committing version.
<jtv> For example, how do you reset policy when you're in a failed transaction?
<stub> Why do you need it?
<jtv> When an exception is taking you out of the policy, it needs to reset previous policy.  But at that point the transaction may be broken.
<jtv> I could abort at that point, start a new transaction, set policy, and commit -- but that brings us back to it being a transaction boundary.
<stub> Sounds like we need to issue a transaction.abort() if we are exiting the context handler because of a psycopg2.Error
<stub> Although a higher level could be handling it...
<stub> blah
<stub> Hmm... I wonder if we can setlocal instead?
<stub> doesn't help in this case, but set local might be nicer anyway
 * stub looks into savepoints
<stub> jtv: savepoints make this nicer, and you get better nesting behavior too
<jtv> Are we talking about a savepoint in the postgres sense?
<jtv> Nested transactions, basically?
<stub> jtv: savepoint mytoken; set local default_transaction_readonly true; [...]; release savepoint mytoken;
<stub> yet
<stub> yer
<stub> or rollback to savepoint mytoken
<jtv> But that won't work if the transaction breaks, will it?
<stub> It will rollback the 'set' too (per documentation on the SET statement)
<stub> jtv: transaction breaks gets an implicit release of the savepoint
<jtv> (Also, I couldn't swear that the big performance problems with savepoints were solved in 8.4 as opposed to 9.0 :)
<stub> its all aborted and it is all rolling back until the code that wants to handle it starts a new transaction
<bigjools> cjwatson: I just did a test run of initializing p-series on dogfood, do you want to check it? It seems to be ok to me.  https://dogfood.launchpad.net/ubuntu/p-series
<wgrant> bigjools: It used the cloner, not the copier, right?
<stub> If there is a performance problem, we could consider a switch to turn it off on production. The goal of this code is to prove what sections of code are doing, so mainly applicable to test suite and maybe staging
<bigjools> cloner
<jtv> stub: I don't see nested transactions playing well with other transaction boundaries though.
<stub> jtv: Yes, it won't play well if the code wrapped by the context manager does commit or rollback
<jtv> There are commits and rollbacks in there already.  We could perhaps get rid of those, but it makes me slightly more nervous.
<stub> Implicit commits where previously there were no commits seems to be making the original problem worse rather than better (updates that should be atomic being made in separate transactions)
<stub> So what happens if the context manager, if it catches a psycopg2.Error, does a transaction.abort(), reset policy, reraise exception?
<stub> We could even break the transaction again after resetting the policy if we want to be totally transparent
<jtv> That doesn't play very well with other transaction handlers.
<jtv> Sorry:
<jtv> with other *exception* handlers.
<jtv> We could try it with a slight twist:
<stub> I don't see why. The db transaction is broken. There is nothing to do with the db transaction except issue an abort
<jtv> reset policy
<jtv> if *that* raises a psycopg2 error, abort & reset policy.
<jtv> And then commit.
<stub> oic. yes, because the exception might have been caught inside but left the db connection broken
<stub> Your idea seems sane to me
<jtv> That worries me.
<stub> You had to get a good idea eventually.
<jtv> There is another problem, however.
<jtv> Assuming the transaction was not broken, then what if the context outside of the policy breaks or aborts the transaction that we reset the policy in?
<stub> Or does me thinking an idea sane cause you problems? ;)
<nigelb> stub! Morning!
<stub> Morning!
<nigelb> stub: Could you review https://code.launchpad.net/~nigelbabu/launchpad/kill-statusexplanation-field-forever/+merge/77273
<jtv> (See why I never liked the primary use case for this python feature?)
<jtv> nigelb: I saw him first!
<stub> jtv: What feature do you need to solve this problem correctly?
<nigelb> jtv: My review is quicker. Already approved once. Need a fresh approval for safety :D
<jtv> stub: for that one, clairvoyance.  Thanks.  :)
<jtv> nigelb: I should never have looked at your MP.  :)
<jtv> stub: it was more things like "figure out the state of the ongoing transaction" that could be solved with API extensions.  But this one is really nasty.
<jtv> There is completely different approach: set hooks client-side to manipulate every transaction as it's created.
<nigelb> jtv: hahaha :D
<stub> Just looking at psycopg2 docs.... connection.set_session(readonly=True)... API has become fatter in recent years with active development
<stub> We could hook into the transaction easily enough...
<stub> connection.get_transaction_status() seems useful
<stub> or connection.status even
<stub> http://initd.org/psycopg/docs/connection.html
<jtv> Ah, thanks.  I browsed around the python objects but didn't find that stuff.
<stub> We might need to update our psycopg2
<stub> (which would be a good thing probably - it seems to have moved out of maintenance only to active development mode, but we only update it when we trip over crashers).
<stub> nigelb: So what changed with that db patch?
<jtv> stub: gah.  set_session sounded so nice, but: "The function must be invoked with no transaction in progress."
<nigelb> stub: Nothing. It was reverted because the devel changes weren't deployed everywhere. I un-reverted it.
<nigelb> The code changes are now deployed everywhere. Or so StevenK tells me.
<bigjools> wgrant: do you have any idea what port the rabbit management plugin uses for additional server instances?
<stub> So it is the same patch and my mind isn't playing tricks on me
<nigelb> No, it isn't :)
<wgrant> stub, nigelb I ensured that 14041 was deployed everywhere yesterday.
<wgrant> https://devpad.canonical.com/~wgrant/production-revnos
<nigelb> wgrant: I owe you a beer. Or a few actually.
<wgrant> bigjools: rabbitfixture disables it.
<stub> wgrant: Saw that on the mailing list. Thanks!
<bigjools> wgrant: what if it doesn't?
<wgrant> bigjools: It'll fail to start, because it will try to use 55672 again.
<nigelb> StevenK: OHAI, around?
<bigjools> wgrant: ok ta
<wgrant> bigjools: You can configure it, however.
<stub> wgrant: If you are looking for suggestions, map server names to meaningful Launchpad terminology (cronscripts, appservers, buildd-manager etc.)
<wgrant> bigjools: And rabbitfixture can be given a list of plugins to whitelist.
<bigjools> wgrant: it's a blocker for that test fix you had
<rvba> wgrant: how can I enable it again (if I shutdown the machine's instance)?
<nigelb> jtv: ah, can you land that MP? (want a link?)
<wgrant> bigjools: http://www.rabbitmq.com/management.html describes how to configure the port.
<stub> jtv: So does being able to get the connection status help us?
<bigjools> wgrant: thanks
<rvba> wgrant: tweaking rabbitfixture I guess.
<jtv> stub: don't know, really -- set_session certainly doesn't seem to.
<wgrant> rvba: Actually, I may never have landed the whitelisting support. For now you can just remove the RABBITMQ_PLUGINS_DIR fixture from rabbitfixture.
<stub> jtv: I guess it is pretty much the same just trying the reset and if it fails with a db error abort the transaction and reset
<rvba> wgrant: okay, thanks.
<stub> jtv: connection.status is cleaner, but need to poke into Storm internals to get the psycopg2 connection
<jtv> stub: I think one of the bigger problems is nested commits.
<stub> Why?
<jtv> Things get a bit complex for my liking if we try to do this without transaction boundaries:
<jtv> set policy
<jtv> register hook to repeat setting policy for next transaction
<jtv> on exit:
<jtv> reset policy
<jtv> handle failure if any
<jtv> unregister hook
<stub> context manager does set session read_only, which persists over transaction boundaries. On exit, resets with set session read_only again.
<jtv> Doesn't work with nested commits.
<stub> Why not?
<stub> oh... set session might not work inside a transaction...
<jtv> Well according to the psycopg2 docs it doesn't, but even assuming that it does, there is some transaction weirdness there.
<stub> I'm looking at the pg docs, and 'set session' inside a transaction block rolls back with the transaction
<jtv> Right.
<jtv> I think that was the weirdness that was bothering me: persists across transactions but rolls back with the transaction it's in.
<jtv> Made it hard for libpqxx.  :)
<cjwatson> bigjools: not really sure exactly what to look at, but it looks ok from a preliminary glance
<cjwatson> bigjools: shouldn't https://dogfood.launchpad.net/ubuntu/+source/man-db have p-series somewhere?
<cjwatson> bigjools: or is that pending a publisher run?
<bigjools> yeah pending publishing, and the series needs to be frozen
<bigjools> cjwatson: what checks do you normally make?
<wgrant> It's not pending publishing.
<stub> jtv: "A special case is    SET followed by SET LOCAL within    a single transaction: the SET LOCAL value will be    seen until the end of the transaction, but afterwards (if the transaction    is committed) the SET value will take effect.   "
<wgrant> It's just because the series is Future.
<cjwatson> I guess it would be interesting to try an initial publisher run on df and run compare-archives between oneiric and p-series
<wgrant> So it doesn't show up on DSP:+index.
<wgrant> https://dogfood.launchpad.net/ubuntu/+source/man-db/+publishinghistory
<cjwatson> compare-archives being http://paste.ubuntu.com/698441/
<wgrant> cjwatson: Can't really do that on DF without spending 1.5 days publishing oneiric first :/
<stub> jtv: bah... but not rollback :-P
<cjwatson> wgrant: oh dear
<bigjools> cjwatson: that'd help if we already had all of oneiric published on DF :)
<jtv> stub: not relevant, I hope -- "set transaction" is separate to "set" and inherently transaction-local.
<wgrant> cjwatson, bigjools: Or we could just debmirror in a few minutes...
<wgrant> Let's do that.
<cjwatson> the interesting changes to initialisation were in things like copying custom uploads around, I thought
<bigjools> disk space might be an issue
<cjwatson> so that seems more interesting to check if we want to dry-run init
<wgrant> bigjools: Not for one series and four archs of oneiric.
<bigjools> shurg
<bigjools> and shrug
<jtv> stub: I hope this illustrates why I (1) went with commits here and (2) didn't buy the primary use case for python context managers.  :)
<cjwatson> shurg sounds like a star wars monster
<bigjools> :)
<jtv> wgrant: oneiric _is_ a series
<wgrant> Shh
 * jtv shhes
<bigjools> cjwatson: yeah copying custom AND auto-initialisation of all pockets on the first run
<bigjools> I shall do a publication
<bigjools> wgrant: you probably know more about debmirror than me, you can either do it or I can take monkey instructions
<wgrant> bigjools: It's pretty trivial to use, with the minor issue that it's probably not installed on mawson.
<stub> jtv: file:///usr/share/doc/postgresql-doc-8.4/html/sql-set-transaction.html , so 'set transaction' is the current transaction and 'set session characteristics as transaction' is future transactions. I don't know if the latter rollsback.
<jtv> stub: interestingly, "set transaction" can switch back and forth during a transaction.  I remembered it as working only at the beginning of one.
<stub> jtv: The docs make you think that, but they are describing the isolation level.
<jtv> You can happily commit a transaction with changes that is currently "set transaction"ed as read-only.
 * jtv looks up the docs
<stub> set transaction to set the isolation level has to happen at the start. read only/read write is apparently allowed anywhere.
<jtv> ah
<stub> bah.... it rollsback too
<stub> Can't seem to set state inside a transaction that survives a rollback
<stub> Which would normally be a good thing.
<jtv> Well IIRC there is one exception to that:
<jtv> prepared statements.
<jtv> Or maybe what upset me at the time was that they did roll back... forget now.  :)
<stub> ohh... nasty idea.
<stub> nm... pointless nasty idea involving temporary tables.
<jtv> Oh give it up.  :)
<stub> I don't see much use to this as it stands though, because issuing implicit commits is making our problem worse I think.
<stub> And the work around is ugly and painful involving hooking into the transaction machinery
<cjwatson> wgrant: but OTOH it is a fairly self-contained script
<stub> jtv: Its pretty much like @write_transaction
<jtv> stub: I don't see how.  Same arguments as for read_transaction.
<wgrant> cjwatson: It is.
<wgrant> Well, it was.
<wgrant> It may have done an sbuild and turned into a horrid Perl module mess since I last looked :)
<stub> jtv: Yes, and we are not using read_transaction because of this behaviour, and the proposed solution also has this behaviour.
<jtv> stub: read_transaction/write_transaction are half-hearted about it.  At least what I've got here enforces the read-only property and supports nesting.
<jtv> (Also, read_transaction/write_transaction could easily make a horrible mess if they have to retry ongoing transactions, AFAICS)
<stub> jtv: Not sure if we want to support nesting though unless we also break commit/rollback
<jtv> I hate the implicit commits, but...
<jtv> For what I'm doing, yes, nesting would be very useful.
<jtv> It's basically a complex, multi-function version of the second example I gave in the docstring.
<stub> jtv: Implicit commits can lead to corruption and data loss. Can we work with an implicit rollback?
<cjwatson> wgrant: no, I believe it's still pretty self-contained
<jtv> stub: could you elaborate?
<stub> Scattering new commits randomly around the codebase is dangerous as you end up committing things you were hoping to rollback. Even if you are careful, the next person might not be. Scattering new rollbacks randomly around the codebase is safer (but still not 'safe' as we might be dealing with non-db resources too).
<stub> The problems with 'try: reset(): except psyocpg2.Error: abort(), reset()' also affect the current implementation don't they?
<jtv> Just that one, AFAICS, and that's about the easiest problem we have here.
<stub> If code inside the policy issues commits or rollbacks, the policy is no longer in effect.
<jtv> Not in my code.
<jtv> See the documentation & tests.
<wgrant> Perhaps you want a decorator that monkeypatches out transaction.commit and transaction.abort.
<jtv> go play outside!
<stub> jtv: You only test it survives commit, not rollback
<jtv> stub: You're preaching to the choir as far as implicit commits are concerned, but I'd much rather have well-defined transaction boundaries on this (with another curse in the direction of G. v. Rossum on this topic) than something that's complicated to follow.
<jtv> stub: I can add a test case for that; won't affect the code.
<stub> jtv: How will it work? Rollback rolls back the SET
<jtv> stub: actually, I do test that case.
<stub> If it works, the other solution works too
<jtv> It's the very last test in the test case.
<jtv> No, because my present solution can commit the SET.  :)
<jtv> "test_policy_survives_abort": "Even after aborting the initial transaction, a transaction policy still applies."
<jtv> The point is to get well-defined behaviour.
<stub> So we have two implicit commits
<stub> I really don't see how this can be used safely.
<stub> Hmm
<jtv> There is one small tweak that could make it more palatable: abort at the end, rather than committing.
<stub> The implicit commit at the start is the same.
<stub> You might as well just put the connection into autocommit mode.
<jtv> Not the same.  You have an explicit statement there doing stuff with the database.
<jtv> At least there you can read it and think "this will do something to the database."
<jtv> Exit is the really nasty part.
<stub> __enter__ would need to 'transaction.abort(); set' and __exit__ would need to 'transaction.abort(); set'
<jtv> (See my line of reasoning against python context handlers as transaction managers at the time)
<stub> Sorry... __enter__ transaction.abort(); set; commit()
<jtv> What I tried to do, and couldn't make work unfortunately, was ensure that if a transaction is ongoing, it's "blank"
<jtv> (in the sense of what SET TRANSACTION <isolation level> would accept)
<jtv> If we can query a connection's transaction state, we could require an explicit commit/abort just prior to the context.
<stub> That might be connection.status == TRANSACTION_STATUS_IDLE
<jtv> Yeah.
<jtv> Or get_transaction_status.
<jtv> I believe connection.status returns a different enum.
<stub> I think they are the same thing, just different spelling
<stub> oh... different enums
<jtv> An initial implicit commit becomes a lot more palatable if we can check that no transaction is ongoing.
<jtv> Basically, who's going to notice an extra commit in that case?
<stub> jtv: yes, that is fine.
<jtv> We can turn the implicit final commit into an abort, raising a resolute middle finger to the whole context-manager design process.
<jtv> Or better yet!
<stub> jtv: And I think that helps solve the original problems.
<jtv> "if exiting normally, assert that no transaction is ongoing."
<stub> Yup. 'This chunk of code is called without an ongoing transaction and will commit or abort'
<jtv> That's what I really wanted, but couldn't find the supporting API to implement.
<jtv> And when you exit, it had better be either with an exception or after you have cleared out any open transactions.
<stub> Nesting means a commit or abort would have to happen before the nesting happens, which is also good I suspect.
<jtv> Yes, that's expected.
<stub> I think this design is no longer dangerous and helpful.
<jtv> Could you disambiguate that with some parentheses?
<stub> (no longer dangerous) and helpful
<jtv> Phew.  Thanks.
<jtv> stub: I can create a new exception type for "transaction still open," but do you happen to know of one I could reuse?
<stub> RuntimeError ?
<stub> I can't think of anything suitable that already exists
<jtv> Isn't really a runtime error; more like a logic error.
<jtv> I'll just create a new exception class then.
<stub> Yer... just subclass Exception I guess
<jtv> But now I need to leave!
<stub> Night
<jtv> stub: oh, and: read-only doesn't need an explicit commit really, does it?
<stub> jtv: it does if you want it to persist over multiple transactions, especially if you hit code protected by the @read_transaction decorator.
<jtv> I mean it would be safe to commit a read-only transaction implicitly at the end of the policy.
<stub> flush first
<jtv> Of course.
<jtv> Or wait, not on commit.
<jtv> On aborting a read-only one, flush.
<jtv> (I had that in an earlier iteration)
<jtv> I think abort is probably needlessly expensive for a read-only transaction.
<stub> If you are in read only mode, abort or commit doesn't matter. You want to flush anyway, so ensure any exceptions that should be raised are raised.
<jtv> Exactly.
<stub> For read only mode, you can go with flush, abort, set, commit in the __exit__
<stub> Sorry. flush, confirm status, abort, set commit
<jtv> Wasn't abort horribly expensive?
<stub> Same for read write, since the inside is supposed to have committed or aborted already
<stub> I don't know if abort is more expensive than commit.
<stub> I suspect not if there are no changes, which there shouldn't be.
<jtv> What I mean is, we don't need to require an explicit commit/abort for a read-only transaction.
<jtv> For a read-write transaction, you want an explicit commit at the end of a successful run.
<jtv> For a read-only transaction, why bother?
<stub> point
<jtv> Then again, it does keep the bracketing explicit.
<jtv> I mean, having a transaction.commit() at the end of the policy's code region keeps bracketing explicit.
<stub> So with read_only: stuff followed by with read_write: stuff, the second block would fail because we are already in a transaction
<jtv> No, because the un-setting of the policy does need a commit.
<jtv> (Which is implicit).
<stub> oic
<stub> Anyway, basic behavior of '__enter__ confirms no transaction in progress and sets persistent state' and '__exit__ confirms no transaction in progress and resets persistent state' is fine. And 'persistent state' means set followed by commit.
<stub> jtv: But you were leaving
<jtv> Trying to anyway.  :)
<jtv> The main tests are written & documented; can implement tomorrow.
<stub> yup.
<jtv> Thanks!
<stub> I just hope connection.status or connection.get_transaction_status() does what we need :-)
<allenap> StevenK, danilos: Could either of you do a short review for me? https://code.launchpad.net/~allenap/launchpad/silence-amqplib-logger/+merge/77310
<danilos> allenap, I have a call in a few minutes, I'll pick it up after the call if it's still there :)
<allenap> danilos: Ta.
<danilos> allenap, r=me, thanks for fixing this :)
<nigelb> danilos: Hey, could you land something for me? Its already approved for db-devel.
<allenap> danilos: Thanks!
<danilos> nigelb, sure, though if it's the same thing benji was on a few days ago, I think he might get it sorted for you today :)
<nigelb> danilos: Its another one :)
<nigelb> https://code.launchpad.net/~nigelbabu/launchpad/kill-statusexplanation-field-forever/+merge/77273
<deryck> Morning, all.
<danilos> nigelb, sure thing then
<nigelb> danilos: Thanks!
<nigelb> So, instead of one db patch, I'm landing 2 db patches in one day :)
<danilos> nigelb, it probably means we'll have to serialize and roll one-by-one to production on consecutive days, but we'll see emails from people who do the rollout on the list :)
<nigelb> danilos: heh :)
<deryck> adeuring, abentley -- let's hold off on standup for 10 minutes. compiling some stuff to send you both that we need to chat about.
<adeuring> deryck: ok
<abentley> deryck: ack.
<deryck> abentley, ready when you are.
<deryck> abentley, don't hear you.
<abentley> deryck: same here.
<deryck> abentley, we heard you then
<stub> gary_poster: Here yet? http://paste.ubuntu.com/698496/
<gary_poster> stub, hi, yes.  I was going to try to fiddle with what your email said.  reading pastebin...
<stub> gary_poster: So the first test passes, although I'm not sure if that is a good thing
<gary_poster> heh
<stub> gary_poster: The second test demonstrates a case we are not handling
<stub> gary_poster: an OperationalError is raised if the Store is attempting to connect for the first time and the server isn't there.
<stub> Which I guess is technically correct, as you can't disconnect unless you have previously managed to connect...
<gary_poster> stub: for first test, what did you change to get things fixed (I see change in 23-29 but that is more tests, not a change to get things to pass)
<stub> This would be the 'appserver bounced while the db is down' situation. We don't have to handle it this branch if you don't want to.
<gary_poster> stub, ack for second test, thinking.
<gary_poster> stub, won't we want to register a similar/identical view for OperationalError then?
<gary_poster> That seems reasonable on the face of it
<stub> gary_poster: Yes. We might see operational error in other more serious cases (like disk full), but 503 would be acceptable behaviour I think.
<gary_poster> ok stub.  I can do that easily enough.
<gary_poster> stub, what am I missing from the first test though (test_error_view_integration)--did you initially dupe the problem I reported, and then fix it somehow?
<stub> gary_poster: Yes. If you move the 'use_fixture' to before you register the wsgi stuff it explodes like you found.
<gary_poster> Ah!
<stub> I don't see why it should do that. It worries me.
<gary_poster> how odd
<gary_poster> yeah
<gary_poster> ok, stub, thank you very much!  This helps a lot.  I'll proceed and ignore the worry myself unless you suggest otherwise.
<deryck> adeuring, abentley -- ready on Skype when you guys are.
<abentley> deryck: on.
<deryck> abentley, you're showing offline for me and can't dial you.
<abentley> deryck: 2 different versions of Skype hate me.
<deryck> heh.
<deryck> abentley, shall I try the regular number?
<flacoste> man, wadllib API sucks
<flacoste> i've never seen such a convulated API
<flacoste> and i probably reviewed some of it... *sigh*
<nigelb> Historic moment of self realization? :)
<cr3> hi folks, has there been any interest in running launchpad with pypy to potentially improve performance?
<benji> APIs (like code) don't age well
<cr3> benji: I don't think many things age well, even in nature things just die and are born again :(
<benji> cr3: there's certainly interest but there are (at least) two negatives: we have lots of dependencies that don't work with pypy and LP isn't especially CPU bound (as far as I know)
<benji> cr3: true, but we often think of digital (mathematical) constructs being immune from aging (like, say, Dijkstra's algorithm); IMO, code and APIs don't age well because we know more now than we did when we created them
<cr3> benji: same might apply to mathematics as well, consider hilbert threw a wrench in euclidian space. same reason as you mention though, "we know more now..."
<cr3> axioms change, just like in code, which breaks everything built on top of them
<cr3> apache had a great axiom of pre-forking but then we found that asynchronous sockets might be preferable in lots of cases
<benji> this is true; I guess we need to embrace refactoring like Turritopsis nutricula (http://en.wikipedia.org/wiki/Turritopsis_nutricula)
<cr3> benji: to keep the analogy, I wonder what would be the equivalent for code to return in a polyp state... stable release? :)
<benji> cr3: I was thinking more like a rewrite of a chunk of code such that it still performs its essential functions while shedding accumulated, non-essential functionality
<cr3> benji: I've always had difficulty with rewrites which others have most likely felt as well: people usually expect the same functionalities as before, sometimes even the quirky ones!
<cr3> benji: the problem is more about managing expectations than a technological one
<benji> cr3: indeed
<benji> I aspire to be minimalist, especially with code, and one of my mantras is "do less".
<cr3> benji: ironically, I've seen the amount of code I write increases with experience because I happen to know more about doing things right which is usually more verbose :(
<jcsackett> sinzui: are you up for some mumbling?
<sinzui> barely. I am ill and struggling to fix the broken test suite.
<sinzui> I will start mumble in a few minutes when I get control of my computer
<jcsackett> sinzui: sure. no worries.
<gary_poster> stub, fwiw, I couldn't dupe your solution for the first test by rearranging the lines--I had made some name changes but it was otherwise identical.  So, I'm thinking that solution may be to fragile to pursue after all.  I've tried the three request solution (primary, secondary, clear) but that caused errors for subsequent tests (the ProgrammingError showed up for them).  I've tried reconnect_stores() and helps me dupe
<gary_poster> 't let me do a DisconnectError.
<gary_poster> So, I'll dig in some more and send you an email at my EOD if I still don't have a solution
<stub> gary_poster: garh
<stub> gary_poster: Have you got anything more verbose out of that ProgrammingError?
<gary_poster> no, stub.  no.  any hints on how to get more?
<stub> Just wondering if our reporting is not outputting the informative string in the exception, or we are somehow getting a ProgrammingError('')
<gary_poster> stub, I can instrument closer to the error
<gary_poster> I'll check it out
<stub> I can have a further poke tomorrow anyway at the underlying issues, but can't see how it is possible to get a ProgrammingError if the database is inaccessible, nor how to get one that only triggers when the PGBouncerFixture is loaded but not being connected through.
<gary_poster> stub, it actually happens in one of my tracebacks in a rollback
<gary_poster> thanks stub
<stub> gary_poster: might be an untested codepath then? ProgrammingError means SQL syntax error, or attempting to access a table that doesn't exist or you have no permissions on, or something like that.
<gary_poster> hm...I saw the pgbouncer sets up security
<gary_poster> but I didn't know enough about the details to have an opinion or thought about it
<gary_poster> the pgbouncer fixture, I should say
<stub> possibly, if it is attempting to connect as some user not defined in security.cfg
<stub> or the default user (your unix username)
<gary_poster> stub, where the "it" attempting to connect is LP here, I guess?  the bouncer itself is dead by the time we get the programming error, according to the bouncerlogs I looked at yesterday...
<gary_poster> OK, I got more SQL than I shake a stick at...wading through...
<gary_poster> hm, going to try that again with more info about whether there was an error...
<gary_poster> yeah, SELECT getlocalnodeid() is the only interesting one
<gary_poster> um
 * gary_poster goes to take a break :-P
* abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: StevenK, danilos, abentley | Critical bugs: 261 - 0:[########*** stack smashing detected ***: ./lp terminated
<lifeless> morning
<nigelb> Morning lifeless
<nigelb> benji: Hey, just checking if you were able to sort out your ec2 land troubles
<nigelb> Also, \o/ my first db-devel patch landed
<lifeless> nigelb: second surely?
<benji> nigelb: I just now got evidence that it's working for me again.  I'll resubmit your branch within the hour.  (If you can easily remind me which one it is, that would be appreciated.)
<nigelb> lifeless: second one is one the way :D
<nigelb> benji: https://code.launchpad.net/~nigelbabu/launchpad/create-description-5283/+merge/76818
<lifeless> nigelb: wasn't the first 2 weeks back ?
<nigelb> lifeless: well, that got reverted.
<lifeless> right
<nigelb> I just un-reverted it.
<lifeless> still count s:P
<nigelb> ha!
<benji> I just got the same failure on two ec2 runs of different branches: http://paste.ubuntu.com/698675/. I can't reproduce the failure locally.  Anyone seen this?
<benji> nigelb: bad news, conflicts: http://paste.ubuntu.com/698689/
<tedg> Hello, I'm looking for where in the LP codebase the bugzilla sync code is.
<tedg> Could someone give me a pointer?
<lifeless> at a guess, lib/lp/bugs/ somewhere. I'd do a 'find . -name "*bugz*"
<tedg> lifeless, Are bugz, the new hip bugs?  ;-)
<tedg> Heh, I just got an timeout oops browsing the LP source code ;-)
<lifeless> yeah, loggerhead still needs a performance love-in
<tedg> lifeless, Okay, found what I was looking for.  Thanks!
* abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 261 - 0:[########*** stack smashing detected ***: ./lp terminated
 * mwhudson wonders, could ~launchpad-reviewers be set as the reviewer team for lp:txlongpoll?
<mwhudson> oh it is
<mwhudson> then could ~lazr-developers _not_ be subscribed to all code review mail?
<mwhudson> er, failures in lib/lp/bugs/doc/initial-bug-contacts.txt -- not my fault?
<mwhudson> maybe not
<mwhudson> bug 861510
<_mup_> Bug #861510: XMLRPCTestTransport is not torn down properly <test-system> <Launchpad itself:Triaged> < https://launchpad.net/bugs/861510 >
<_thumper_> wallyworld_: ping
<mwhudson> ok, bug 861510 is very very screwed
<_mup_> Bug #861510: XMLRPCTestTransport is not torn down properly <test-system> <Launchpad itself:Triaged> < https://launchpad.net/bugs/861510 >
<mwhudson> arughjkfsdafdaslkjhfalsdkjfh
<mwhudson> omg omg
<lifeless> mwhudson: cats?
<mwhudson> lifeless: no
<mwhudson> lifeless: thread locals
<mwhudson> much more terrifying
<lifeless> rather like regexes
<mwhudson> lifeless: looking at
<mwhudson> <mwhudson> lifeless: no
<mwhudson> argh
<mwhudson> https://bugs.launchpad.net/launchpad/+bug/861510
<_mup_> Bug #861510: XMLRPCTestTransport is not torn down properly <test-system> <Launchpad itself:Triaged> < https://launchpad.net/bugs/861510 >
<lifeless> yeah
<lifeless> I saw it go past, decided to err on the side of sanity and close my eyes ;(
<mwhudson> i don't get all the details
<mwhudson> but the problem is that doing the XMLRPCTestTransport thing ends up calling set_permit_timeout_from_features(True)
<mwhudson> and then everything else goes wrong
<mwhudson> lifeless: in general i am becoming more of the opinion that all 'global-ish' things in launchpad should be explicitly tied to the request/participation
<mwhudson> and using thread locals is just a recipe for confusiong
<mwhudson> (mostly confusion in test suites rather than real code)
<mwhudson> of course the interaction is a thread-local, but there's only one of it and we're in general _reasonably_ good about keeping its state in check
<lifeless> mwhudson: IIRC we were both of that opinion, and firmly so, when I filed that bug about scripts and participations :)
<mwhudson> yeah
<mwhudson> i guess i'm even more of it now :)
<mwhudson> lifeless: i think i hadn't realised how bad having lots of thread locals is
<lifeless> and its viral
<lifeless> once you have one its hard to not have another
<mwhudson> i'd say it's more like when you have _two_ it's hard not to have another
<mwhudson> i think it would be possibly to have one thread local to rule them all
<lifeless> mmm
<mwhudson> https://bugs.launchpad.net/launchpad/+bug/861510/comments/3
<_mup_> Bug #861510: XMLRPCTestTransport is not torn down properly <test-system> <Launchpad itself:Triaged> < https://launchpad.net/bugs/861510 >
<lifeless> I don't think 2 drives three more than 1 drives 2, TBH
<wallyworld_> jcsackett: hi
<wallyworld_> thumper: hi
<thumper> wallyworld_: hi
<thumper> wallyworld_: how's tricks?
<wallyworld_> how goes it?
<wallyworld_> busy
<wallyworld_> doing some mockups for disclosure, lots of javascript
<wallyworld_> finished improving pickers
<thumper> cool
<thumper> I have a minor feature request
<wallyworld_> how's dx?
<thumper> :)
<wallyworld_> sure
<thumper> when we attach diffs to outgoing code review and branch emails
<thumper> can we utf-8 encode plz?
<wallyworld_> sure, can't see why not
<thumper> we have people with weird names committing or .po file stuff et al
<wallyworld_> not surprised :-)
<thumper> dx is interesting
<thumper> so so much going on
<thumper> almost scarey
<wallyworld_> good stuff?
<wallyworld_> i guess you are focused on squashing the last few oneiric bugs
<wgrant> There's two weeks to go! Not the final stretch yet.
<wgrant> Still got another 10 FF violations to land, probably :P
<thumper> wallyworld_: final cut for upload is today
<wallyworld_> thumper: does it fix the stacking issues?
<thumper> wallyworld_: the rest of the bug fixes are going in as distro patches :)
<thumper> wallyworld_: almost all of them are fixed
<wallyworld_> \o/
<thumper> wallyworld_: apparently there are still and edge case or two out there
<wallyworld_> been driving me crazy
<thumper> the big problem is it needs a fundamental refactoring to compiz internals
<wallyworld_> thumper: my main other gripe is with the global menu behaviour, but you know that :-)
<thumper> X sucks
<wallyworld_> yep
<thumper> yeah... I know that
<wallyworld_> i'm fining it's taking more mouse clicks to do what i want :-(
<wallyworld_> oh well
<wgrant> wallyworld_: I'm guessing there's no standup today?
<wallyworld_> wgrant: don't know?
<wgrant> Given sinzui's email.
<wallyworld_> i was hoping to catch up with jcsackett briefly
<wallyworld_> wgrant: if there's nothing in particular to discuss, we can skip it
<wallyworld_> thumper: do you know if "Show Desktop" on the launcher is broken? well it is for me
<wgrant> Does that still exist?
<wallyworld_> on mine it does
<wgrant> Maybe I just removed it and forgot...
<wallyworld_> i updated just now and its icon has changed but it still doesn't work
 * wallyworld_ has to go run an errand
<poolie> hi all
#launchpad-dev 2011-09-29
<poolie> lifeless, re that query for bugs affecting users
<poolie> i'll try it without the subquery
<poolie> that sql is being generated by higher level code that asks for a query affects_me=True
<poolie> would it be risky, or beneficial, to change the way that's implemented in general?
<poolie> so that it always does a join
<poolie> or is it likely to be sensitive to the larger query of which it's a part?
<lifeless> sadly its risky
<lifeless> however I tried a join and it wasn't substantially better
<lifeless> backlog in -ops has pastebin / explain for hloeung
<lifeless> not saying 'do not join', more 'join may not be enough / may be a distraction'
<mwhudson> lifeless: https://code.launchpad.net/~mwhudson/launchpad/introduce-IParticipationWithAnnotations-bug-623199 btw
<mwhudson> (running it through ec2 test now)
<lifeless> cool
<thumper> wallyworld_: I don't have a show desktop in the launcher
<wallyworld_> thumper: hmmmm. mine has been there for a while. perhaps it got removed and i still have an old launcher entry which points to nothing
<wallyworld_> if it has been removed, how does one show the desktop now?
<thumper> wallyworld_: it is in alt-tab
<wallyworld_> thumper: so it is. too many keypresses though :-(
<thumper> what is the purpose of showing the desktop?
<wallyworld_> so i can access icons and shortcuts i have there
<thumper> wallyworld_: try super-D
<wallyworld_> hitting super brings up the launcher
<wallyworld_> and then 'd' has no effect
<thumper> wallyworld_: hold down super and press "D"
<thumper> works for me
<wallyworld_> yehah i tried that too
<thumper> wallyworld_: I think your computer just hates you
<wallyworld_> i knows i like kde
<wallyworld_> it
<wallyworld_> generally i don't mind unity except for that key workflows are too inconvenient
<wgrant> unity --reset?
 * wallyworld_ tries that
<wallyworld_> still hates me
<wgrant> jelmer: https://code.launchpad.net/~guadalinex-members/firstboot/gecos is a bit special.
<StevenK> Can haz review? https://code.launchpad.net/~stevenk/launchpad/fix-search-oops/+merge/77429
<StevenK> lifeless: Can we close bug 702188? Since we haven't had read-only mode for a few months now ...
<_mup_> Bug #702188: librarian 500s during read-only mode <librarian> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/702188 >
<poolie> lifeless, huwshimi, so as a compromise for 'bugs affecting me' perhaps i'll just leave off the count
<poolie> it looks a bit odd
<poolie> https://bugs.launchpad.net/launchpad/+bug/858618/+attachment/2477988/+files/20110929_001.jpeg
<_mup_> Bug #858618: hard to find bugs that affect you in a project <bugs> <ui> <Launchpad itself:In Progress by mbp> < https://launchpad.net/bugs/858618 >
<poolie> but i think it's still a step forward
<poolie> what an awful jpeg
<poolie> but you get the idea
<huwshimi> poolie: Is the query too slow or something?
<huwshimi> poolie: I agree it looks a little odd, but I'm not sure we can do anything about it
<jtv> We definitely need a psycopg upgrade for what I'm doing.  :(
<poolie> huwshimi, yes, it is a bit slow
<poolie> and robert's reasonably concerned that just adding more to this page will make it worse
<poolie> perhaps we can eventually make them fetched asynchronously
<poolie> obviously there would still be some db load from it
<poolie> huwshimi, so what i'm really wondering is, do you think it's a step forward over all?
<huwshimi> poolie: I would have thought having links to those pages would be super useful (is there currently any other way to view them without doing an advanced search?). I'm not sure I understand how it could make thinks worse.
<poolie> i also think it would be super useful, and there is no way other than an advanced search
<poolie> and as a consequence the url is risible
<poolie> so i think the worse is only in it being a little ugly and people perhaps complaining it's broken
<poolie> which we can fix separately
<poolie> either through a smarter query or caching or whatever
<poolie> perhaps a triggered update of a cache table
<poolie> thanks
<huwshimi> poolie: Now that I'm thinking about it again,  one think that might be worth considering is putting those links into their own portlet (maybe with a "My bugs" title... or something more appropriate) to make a bit more of a feature out of the fact those links now exist.
<poolie> all the per-person links?
<huwshimi> poolie: Yeah, although really this is a different issue...
<poolie> indeed
<poolie> in fact turning them into toggle filter buttons would be great, i think
<lifeless> huwshimi: I like your search mockup; have you considered having the search terms visible in the result (like search facets)
<poolie> so you can get to 'high', 'open and closed', 'affects me'
<poolie> but this is much bigger, i just wanted a bit of a stop gap
<lifeless> huwshimi: you may have and decided its out of scope, but if you haven't thought about it, I can point you at a number of bugs related to folk doing iterative refinement of searches
<lifeless> which this could help with
<poolie> huwshimi, oh could i see your mockup?
<huwshimi> poolie: What I really would like to do at some point is have a "these are link to the things in this context that apply to me" portlet that is consistent across as much of Launchpad as we can, which would include those links on the bug pages
<poolie> yeah
<huwshimi> lifeless: Oh, do you mean the mockups for the bug columns work?
<lifeless> huwshimi: yes
<huwshimi> lifeless: I think deryck has decided that doing anything to the search is out of scope for the short turn around they have for this feature, except maybe the summary of terms (which I think was in the mockup)
<huwshimi> poolie: Emailed
<lifeless> huwshimi: no worries
<poolie> ah i see what you mean about 'no columns'
<lifeless> huwshimi: it will be an improvement nevertheless
 * StevenK prods lifeless a little harder.
<StevenK> [12:44] < StevenK> lifeless: Can we close bug 702188? Since we haven't had read-only mode for a few months now ...
<_mup_> Bug #702188: librarian 500s during read-only mode <librarian> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/702188 >
<huwshimi> lifeless: Yeah, I'd really like to see that advanced search stuff turned into filters etc. I did in fact do some basic mockups for that, but at this stage it's out of scope. Hopefully that might turn into a second stage of this work another time.
<lifeless> StevenK: sure
 * StevenK dithers between Fix Released and Invalid
<wgrant> Won't Fix
<StevenK> wgrant: Thanks. Done.
<StevenK> lifeless: I'm also having trouble making a tarball of Twisted 11.0.0 plus a cherry pick I applied to it, I would love a bit of help if you're able.
<lifeless> StevenK: what happens?
<StevenK> lifeless: TBH, I thought I just had to tar up the new bits -- but it still identifies itself as 11.0.0, so buildout loves me not.
<lifeless> I have no idea how to make a twisted release
<lifeless> it used to be a Dark Art
<StevenK> You told me how to do a storm release with setup.py flags, I was wondering if they could be used ...
<lifeless> possibly
<lifeless> know, can I remember them... your shell history might be  abetter bet ;)
<StevenK> I tried that yesterday, no dice.
<lifeless> egg_info might be the key
<wgrant> egg_info -b-blahsomesuffix sdist?
 * StevenK is concerned the tarball is 700KiB smaller ...
<StevenK> And is .gz for further hilarity
<StevenK> No docs. Handy.
<StevenK> In fact, there is no egg info in the old tarball.
<lifeless> twisted devs are even less keen on eggs than I
<nigelb> benji: heh, its probably conflicting with my commit to db-devel. I'll get a new branch ready soonish
<benji> nigelb: cool; just let me know and I'll land it when you're ready
<StevenK> Using ./setup.py egg_info and tarring up that results in buildout still insisting it's 11.0.0
<StevenK> wgrant: It seems you fixed bug 55099 along with your BugTask target work. Do you want to close it?
<_mup_> Bug #55099: IBugTaskSet.createTask should take a target argument <lp-bugs> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/55099 >
<wgrant> StevenK: Indeed, nice find.
<StevenK> I need to remove a key from the prod configs before I can rip it out of schema-lazr, right?
<wgrant> Yes.
 * wgrant hunts for a reviewer for https://code.launchpad.net/~wgrant/launchpad/no-key-oopses/+merge/77447
<StevenK> wgrant: I've been looking for a reviewer for 3 hours
<wgrant> StevenK: Yours is certainly *a* fix, but I don't think it's the right Zopey one.
<StevenK> Awww
<jtv> I've got some time to review right now.
<jtv> Ahhh--treating upload errors as user errors.  Been wishing for that.
<jtv> wgrant: review done
<StevenK> MPJs have been going *really* slowly :-/
<jelmer> wgrant: hmm, indeed
<wgrant> jtv: Ah, I keep forgetting we're on 2.6 now.
<wgrant> Thanks.
<wgrant> jelmer: There are a couple of others like it.
<StevenK> wgrant: 2.6? We should move to 2.7 :-P
<wgrant> You'd think.
<cjwatson> Do I need a bug report to attach to a branch that removes code?  I assume it'd be qa-untestable, so doesn't need a bug for QA workflow, right?
<poolie> cjwatson, i believe you do not need one
<cjwatson> Thanks.  Not ready to submit it yet, waiting for an RT to be resolved so that I can deploy the replacement
<lifeless> cjwatson: depends on the code being removed.
<lifeless> cjwatson: e.g. we can verify that some action *doesn't* happen, so there is no intrinsic untestability of removal per se - but some removals may be untestable (as some additions and modifications are untestable)
<nigelb> Can someone help me QA bug 88545 :)
<_mup_> Bug #88545: Abolish the "statusexplanation" database field <bad-commit-10978> <lp-bugs> <qa-needstesting> <tech-debt> <Launchpad itself:Fix Committed by nigelbabu> < https://launchpad.net/bugs/88545 >
<cjwatson> lifeless: it's removing one of the ftpmaster scripts
<cjwatson> so not so much some action doesn't happen, as (about to be) dead code
<lifeless> cjwatson: for that I would just nuke from orbit with no bug.
<lifeless> cjwatson: unless you want something to point at an celebrate.
<nigelb> lol
<cjwatson> hah.  ok
<lifeless> cjwatson: (I'm very keen to remove all archive admin access to the db, you might be able to tell :P)
<cjwatson> I've noticed
<cjwatson> still some way to go, but archive-cruft-check is a fairly easy one to migrate now that I have a full dists/ mirror on lillypilly
<cjwatson> and maybe if I help a bit with it people won't lecture me as much ;-)
<lifeless> cjwatson: I'm actually fine with stuff still running on coco, just removing the db access and the potential for massive locks and errors there is the key thing :)
<lifeless> cjwatson: I'm glad you're putting some time into it!
<cjwatson> we fixed all our locally-written out-of-tree db access quite a while back; everything we run that touches the db is in the LP tree now.  TBH it mostly amounts to queue, change-override, and lp-remove-package
<cjwatson> nowadays
<cjwatson> though I wouldn't swear to there being nothing else
<cjwatson> oh, and sync-source for the cases that the API method doesn't cover yet
<lifeless> yeah, but until we nuke *everything* we can't disable the account
<cjwatson> right
<cjwatson> we have quite a few reports to migrate to lillypilly
<cjwatson> but I think that's all unblocked now
<wgrant> cjwatson: Ah, excellent, always good to remove code.
<poolie> could i get a review on https://code.launchpad.net/~mbp/launchpad/323000-affecting-user/+merge/77469 please?
<nigelb> poolie: Is that a new filter?
* rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba* (allenap) | Critical bugs: 261 - 0:[########*** stack smashing detected ***: ./lp terminated
<rvba> poolie: Sure.
<poolie> nigelb, it's a link to see the bugs that affect you
<nigelb> poolie: Neat!
<nigelb> <3 it
<nigelb> I'm guessing now, people will more aggresively use the affects me
<poolie> https://bugs.launchpad.net/launchpad/+bug/323000/+attachment/2478784/+files/20110929_002.png
<_mup_> Bug #323000: Make "this bug affects me too" bugs visible from user profile <lp-bugs> <profile> <Launchpad itself:In Progress by mbp> < https://launchpad.net/bugs/323000 >
<nigelb> I saw
<bigjools> wgrant: https://launchpad.net/~lynxman/+archive/ppa
<poolie> rvba, so what did you think of https://code.launchpad.net/~mbp/launchpad/323000-affecting-user/+merge/77469 ?
<rvba> poolie: done with the review in just one sec.
<poolie> thanks!
<rvba> poolie: I know it's just a drive by fix but I confess I *love* the removal of all the "List" in front of every single link ;).
<poolie> yeah i do too
<poolie> :)
<poolie> > LIST AFFECTING BUGS
<poolie> it's not cobol
<poolie> thanks for the reivew
<poolie> rvba i saw robert just closing some tech debt bugs with the comment that someone will fix them when (and only when) they see the code and care about changing it
<poolie> and the bug is noise
<poolie> and i'm inclined to agree
<nigelb> poolie: heh, its not COBOL
<rvba> poolie: Okay, I understand.
<poolie> i believe in cleaning things up, i just doubt the bug will make it happen
<wgrant> bigjools: We clearly have some differing opinions. I may track him down later.
<bigjools> wgrant: yes, that's why I pointed it out
<wgrant> bigjools: Well, this is all based on my packaging from yesterday.
<rvba> poolie: True. Especially since the bugs are piling-up quickly IÂ guess.
<wgrant> But he's done odd stuff like installing the .ez again.
<wgrant> Instead of linking the package in.
<wgrant> I wonder if there's a reason for that.
<rvba> poolie: but like you said, the duplication in this particular file is really *bad* ;)
<wgrant> Hmmmmm interesting.
<poolie> rvba the main thing that puts me off cleaning it up is that i can see it's using some amount of zope magic but i don't understand it well enough to know if it's tasteful or not
<wgrant> rabbitmq-management is based on mine, but rabbitmq-management-agent is based on rabbitmq-stomp.
<poolie> hm, the duplication perhaps suggests nobody else is comfortable with it either :)
<rvba> hehe
<poolie> i think actually possibly the whole url structure and ui needs to be reconsidered
<poolie> so that these are not just ~6 totally  different pages  (even with less code duplication) but a generic bug list with some filters
<poolie> i guess we could make the bugs./~ page just link to generic bug searches
<rvba> That sounds like a good idea.
<poolie> hm
<wgrant> bigjools: I fixed the FatalUploadError OOPSes, btw.
<poolie> but there is no generic bug search?
<bigjools> \o/
<poolie> oh, there is
<poolie> like to https://bugs.launchpad.net/bugs/+bugs?field.searchtext=&orderby=-importance&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&assignee_option=any&field.assignee=&field.bug_reporter=mbp&field.bug_supervisor=&field.bug_commenter=&field
<poolie> .subscriber=&field.tag=&field.tags_combinator=ANY&field.status_upstream-empty-marker=1&field.has_cve.used=&field.omit_dupes.used=&field.omit_dupes=on&field.affects_me.used=&field.has_patch.used=&field.has_branches.used=&field.has_branches=on&field.has_no_branches.used=&field.has_no_branches=on&field.has_blueprints.used=&field.has_blueprints=on&field.has_no_blueprints.used=&field.has_no_blueprints=on
<poolie> like to https://bugs.launchpad.net/bugs/+bugs?field.reporter=mbp
<poolie> but, it's a bit harder to navigate from there - you lose the context of coming to it from ~mbp
<rvba> Good point ...
<poolie> mrevell, speaking (vaguely) of responsive design, have you visited askubuntu.com from a mobile browser?
<poolie> it is a thing of beauty
<mrevell> poolie, I havent; I'll have a look, thanks.
<poolie> thanks allenap
<nigelb> poolie: wow. Its awesome on a mobile.
<poolie> yeah
<poolie> it even has little unfoldy overlay bits, which
<poolie> obviously are possible on webkit
<poolie> but, i rarely see sites that both use ajax *and* are mobile specifci
<nigelb> The firefox input website also has a cool looking mobile UI.'
<poolie> mrevell, just one quick thing while i'm tweaking, i'd like to change the 'get the code' in the footer to point to dev.l.n not to the branch contents
<poolie> (which are not actually all that useful without instructions)
<poolie> we've got past "omg there's actual code" and now we can look for at least some people to really change it
<nigelb> heh
<nigelb> So, point it to https://dev.launchpad.net/Getting
<mrevell> Aside from /Getting being the scariest wiki page I have seen this month, I think that's a great idea.
<poolie> that's why i was going to go to the top level
<poolie> it's a bit less scary
<poolie> including having a "noooo i just want cds"
<mrevell> poolie, Sounds like a grand plan :)
<nigelb> Is /Getting that scary? :)
<poolie> well, not really ,but it does have "i need help with lp"
<poolie> and the top level has an easy "Get the source code" link
<mrevell> nigelb, I didn't read a single word on that page and I was scared.
<mrevell> It's a lot of text.
<poolie> :)
<nigelb> haha
<mrevell> It needs a Usability and Communications Specialist to fix it.
<mrevell> Barring that, a Product Manager.
<nigelb> Which needs a product manager to hire one ;)
<mrevell> :)
<mrevell> heh
<mrevell> nigelb, getting there...
<poolie> a Brave U&C Specialist
<nigelb> Brave/Fearless all that
<mrevell> which makes me think of the Holy Grail
<nigelb> We should register launchpad.xxx and it should show the list of all XXX comments in the code.
<nigelb> Just to show the sense of humour we have ::P
<poolie> :)
<mrevell> "Getting the Launchpad source code is fairly simple," and here are 1092 words to tell just how simple.
<nigelb> Its only one step.
<nigelb> Get rf and run it.
<mrevell> Yeah, assuming you want rf to take over your machine. I'm not deliberately sniping at that page; I can, though, see some ways in which it can be better.
<poolie> well
<poolie> it's getting better
<poolie> but it is not trivial
<poolie> https://code.launchpad.net/~mbp/launchpad/get-the-code/+merge/77496
<nigelb> I did let rf take over my machine. BUt maybe we should have a page with the different ways including that thing wgrant uses
<nigelb> (containers?)
<poolie> i think they're under /Running
<poolie> i have used schroots in the past
<mrevell> I use a VM
<poolie> at the moment i'm running it outside because it's slightly easier
<poolie> but it's good to know they're there
<mrevell> Yeah, I think new U&C person and I will need a mini-sprint where we get together for a couple of days to garden the dev wiki.
<nigelb> I found it less blocking when launchpad was just running on my machine
<nigelb> that way I wanted to touch the code more often :)
<poolie> i wonder, while i'm there, if i should link to the blog too
<poolie> it's one of the more interesting bits
<poolie> compared to, say, the Terms of Use ;-)
<nigelb> heh
<mrevell> Yeah, shouldn't make the footer too wide, right?
<mrevell> But, then...
<mrevell> we have "Take the tour" and "Read the guide" just above
<mrevell> maybe the blog link should go beside those.
<poolie> i'd like to unify them too
<poolie> it's a little weird with the shaded bar and then the unshaded bar
<poolie> and one is left aligned and the other centered
<poolie> well, maybe we can
<wgrant> nigelb: I use LXC (see /Running/LXC). On Oneiric it works really well.
<wgrant> And it only takes a couple of seconds to start.
<wgrant> I have a few scripts in ~/bin
<wgrant> So to start the VM I just run lp-start on the host. lp-sh will SSH in and preserve the working dir, or you can give it a command and it will run that. lp-bounce restarts the appserver quickly. It all works pretty smoothly, and didn't take long to get used to.
<nigelb> wgrant: Needs Oneiric right?
<nigelb> I'm not quite ready to part with Lucid :)
<wgrant> Works OK on Natty, but not Lucid.
<mrevell> I wonder how important it is to make Launchpad work well on mobile browsers. My gut feeling is that we should do it; I need to get some research to back me up :)
<StevenK> rvba: O hai, I have two reviews for you -- https://code.launchpad.net/~stevenk/launchpad/kill-+viewstatus/+merge/77460 and https://code.launchpad.net/~stevenk/launchpad/drop-mdzcsv/+merge/77464
<nigelb> mrevell: Checkout other codehosting websites as well
<nigelb> maybe we need a mobile bzr client :P
 * nigelb runs
<rvba> Hi StevenK, okay, I'll have a look.
<poolie> mrevell, personally i think it's pretty far down the line
<poolie> so i mention that more just because i was impressed than that i thought we should do it
<mrevell> Yeah, it is impressive. We get requests every now and then; Stuart Langridge last night, for example.
<poolie> oh for a mobile site?
<poolie> i think if we had internal notifications/timelines they would be a good thing to make work well mobile
<poolie> so people could check up on things in idle moments
<lifeless> I'd argue for an app, not a mobile site per se. IMBW.
<StevenK> http://lpqateam.canonical.com/ does not need OpenID?
<StevenK> lifeless: ^
<poolie> lifeless, which is kind of to say: apis useful enough someone could make an app
<poolie> few roundtrips, maybe notification/activity apis
<mrevell> If we took the responsive web design approach (basically, you make sure your site renders well on different form factors, mobile, PC, whatever), then it'd be more sustainable, I think, than an app. It would be good to see the API in such a state that it could support a widely used mobile app, though.
<rvba> StevenK: r=me&allenap.  Nice cleanups ;)
<StevenK> rvba, allenap: Many thanks for the reviews. :-)
<rvba> np
<deryck> Morning, all.
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rvba* (allenap), jcsackett | Critical bugs: 261 - 0:[########*** stack smashing detected ***: ./lp terminated
<rvba> Morning jcsackett!
<jcsackett> morning, rvba. :-)
<deryck> abentley, coming for standup.  sorry to be running later.
<abentley> deryck: s'okay.
<allenap> Thanks for the review jcsackett :)
<jcsackett> you're welcome, allenap. :-)
<allenap> jcsackett: Got time for another one? https://code.launchpad.net/~allenap/txlongpoll/queue-prefix-optional/+merge/77535
<jcsackett> allenap: sure thing.
<jcsackett> allenap: r=me.
<allenap> jcsackett: Thanks :)
<bigjools> gary_poster: do you know if we have a convention for versioning eggs where I've backported a revision from upstream's trunk?  setup won't let me use a "+" in the version string :(
<gary_poster> bigjools, revision and "-r12345" can't be forced upon the situation somehow?
<bigjools> that's what I am using
<bigjools> looks *wrong* as I am used to Debian versions :)
<gary_poster> bigjools :-) I say go with it
<bigjools> gary_poster: I guess I will, thanks :)
<gary_poster> welcome :-)
<bigjools> gary_poster: any ideas what's going on here? http://pastebin.ubuntu.com/699159/
<gary_poster> bigjools, what's that ">" doing in there?  :-)   if this is versions.cfg, just specify a version
<bigjools> gary_poster: it's not, it's from setup.py for txlongpoll
<bigjools> it finds the distro but there's an error, I don;t know what that error means
<bigjools> I guess it's a problem in the Twisted dist
<bigjools> yeah,the file is in the original but not in the sdist that setup makes :(
<gary_poster> bigjools, on call will be with you soon
<mgz> hello, I wonder if anyone would be interested in landing a launchpadlib mp for me?
<mgz> <https://code.launchpad.net/~gz/launchpadlib/trivial_homeless_launchpadlib_dir/+merge/46150>
<mgz> allenap perhaps?
 * nigelb waves to mgz :)
* rvba changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jcsackett | Critical bugs: 261 - 0:[########*** stack smashing detected ***: ./lp terminated
<nigelb> Congrats on the new job!
<mgz> ...I did wonde what that syntax was in the on call review field...
<mgz> thanks nigelb!
<allenap> mgz: Sure, let me take a look.
<nigelb> mgz: That meant rvba is a trainee reviewer being mentored by allenap :)
<gary_poster> bigjools, I don't know what the story is there.  .py files are generally included by default AFAIK.  You can mess with MANIFEST.in to try and get it, I guess
<bigjools> gary_poster: I think it's something to do with how the egg is built
<bigjools> well, the distribution I mean
<gary_poster> right, the sdist
<bigjools> gary_poster: it's missing a few setup.py files in the tree.  They are there in the tarball in the LP download cache
<bigjools> so I must be building it wrong
<gary_poster> bigjools, the only thing I would know to look at on the basis of that traceback is MANIFEST.in...
<bigjools> there's no MANIFEST.in, just a MANIFEST
<bigjools> hmmm I wonder if I grabbed the wrong source
<gary_poster> bigjools, in your original package you would create a MANIFEST.in.  MANIFEST is generated, using MANIFEST.in if it exists and otherwise doing whatever it thinks it ought to do.  But, yeah, something like "grabbing the wrong source" would make more sense to me because *.py stuff is always included by default AFAIK, so that really doesn't make a lot of sense to me.
<bigjools> indeed
<bigjools> well, there's no MANIFEST* in the download tarball
<bigjools> so I guess it's generated "doing whatever it thinks it ought to do"
<bigjools> jml: I reckon you've built custom Twisted distros for LP, do you know the runes to do it right?
<gary_poster> yes, bigjools
<jml> bigjools: IIRC, it's pretty straightforward
 * jml thinks
<bigjools> jml: I'd just running setup.py sdist, but it's not generating the right MANIFEST by the looks of it, it's missing some setup.py files in the tree
<jml> Hmm.
<bigjools> s/I'd/I'm/
<jml> I don't recall that.
<jml> (Maybe I just made a tarball?)
<jml> Hmm.
<jml> Oh, right.
<jml> ./bin/admin/build-tarballs . /tmp/twisted-release/
<jml> (pilfered from http://twistedmatrix.com/trac/wiki/ReleaseProcess)
<jml> Maybe I did that.
<sinzui> jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/ask-question-from-bug/+merge/77562
<jcsackett> sinzui: sure.
<jml> bigjools: ^
<bigjools> jml: thanks - I don't have a bin/admin :(
<jml> bigjools: now that's just weird. It's a checkout of the tree?
<bigjools> jml: yes
<bigjools> well, new tarball download
 * jml svn ups
<jml> oh, that might not get included in the release tarballs
<bigjools> ah
<jml> right. it doesn't.
<jml> (incidentally, can I help get these patches upstream?)
<bigjools> jml: they are already upstream, just not released
 * deryck lunches offline for daycare pickup
<bigjools> it's the fix for 638, adds a --logger option
<jml> bigjools: ahh, cool.
<bigjools> nasty change if you ask me :(
<bigjools> so I backported the patch anyway, and it all works fine locally.  Now I need to package it!
<bigjools> maybe I should just svn co it
<jml> Twisted's pretty darn stable, I'd recommend just svn co to the latest revno.
<bigjools> oh, really?
<jml> well, by "recommend", I mean 'consider as an option'
<bigjools> :)
<allenap> mgz: Landed :)
<jcsackett> sinzui: r=me, looks good.
<sinzui> thank you
<mgz> allenap: thanks!
<jml> it's unlikely to break compatibility, the NEWS files will flag any changes that do, and there isn't much QA that happens before turning trunk into a release -- it's all done at commit time.
<jml> but, alternatively, co releases/twisted-11.0 or whatever and apply the patch manually.
<bigjools> jml: I was taking the conservative option but you fill me with ebullient confidence
<jml> that said, in the past, I'm pretty sure we've done something like just apply the patch to the download-cache tarball, run the Twisted tests and then retar it.
<jml> sorry for the meandering response
<bigjools> jml: re-tarring it sounds the safest option for sure
<bigjools> but I may stick my neck out
<jml> I'll count this as another vote to release Twisted
<bigjools> :)
<jml> we're due another one anyway
<cjwatson> jcsackett: would you mind reviewing https://code.launchpad.net/~cjwatson/launchpad/remove-archive-cruft-check/+merge/77524 ?
<jcsackett> cjwatson: sure.
<jcsackett> cjwatson: this deals with stuff i'm not totally familiar with. i take it the ubuntu archive admins are the only ones who needed this stuff?
<flacoste> jcsackett: i'm +1 on your review
<flacoste> jcsackett: can you land it for cjwatson please, unless cjwatson has PQM access nowadays
<jcsackett> flacoste: i *probably* can, landing is sometimes so so for me. :-p
<jcsackett> cjwatson: do you have landing powers, or do you need a helping hand?
<nigelb> Hi! Could someone with access to qastaging db help me qa a db patch?
<flacoste> nigelb: sure
<flacoste> nigelb: what do i need to do?
<nigelb> flacoste: aha, let me grab the bug
<flacoste> jcsackett: is sinzui still stick today?
<sinzui> I am about
<flacoste> hi sinzui! how are you feeling?
<sinzui> ell
<sinzui> well
<flacoste> pffew
<flacoste> for  a moment, i thought it was a 'h' that was missing!
<flacoste> glad to hear you are feeling better!
<nigelb> flacoste: This is my change set http://bazaar.launchpad.net/~launchpad-pqm/launchpad/db-stable/revision/11030
<nigelb> I need someone to "check the duration that the patch took to apply in the qastaging-restore logs on devpad"
 * flacoste looks
<nigelb> patch number is patch-2208-84-1.sql if that helps
<flacoste> nigelb: hashn't been applied yet
<nigelb> flacoste: Oh. Landing on qastaging doesn't apply it automatically?
<flacoste> nigelb: you landed on db-devel, right?
<nigelb> Yeah
<flacoste> which gets deployed to staging
<nigelb> "Fixed in db-stable r11030"
<flacoste> but last staging update dates from 2011-09-28 08:10:25
<flacoste> that's 10 hours ago
<flacoste> let me investigate what is happening there
<nigelb> this was 11 horus ago
<nigelb> hours, not the Egyptian diety
<nigelb> *deity
<flacoste> lol
<flacoste> yeah
<flacoste> and staging is running r11032
<flacoste> so your patch should have been applied
<flacoste> i'm probably looking in the wrong log file
<nigelb> ah
<flacoste> ah
<flacoste> i need to sync the log first
<flacoste> of course
<flacoste> doh
 * sinzui has a Gunbis cat that has been staring at him for 3 Horuses.
<flacoste> lol
<nigelb> heh
<flacoste> nigelb: i'm hopping on a call, this might lag a little, are you around for the next hour?
<nigelb> flacoste: I'll be in bed by then, I don't mind picking it up tomorrow
<flacoste> nigelb: will email you then
<nigelb> flacoste: Cool, thanks!
<flacoste> nigelb: ok, back
<nigelb> flacoste: and I'm still up :)
<flacoste> waiting for logs to sync...
<lifeless> *yawn*. babies.
<nigelb> Morning lifeless
<flacoste> morning lifeless
<flacoste> working with python-gdata and the gdata API, i'm actually appreciating launchpadlib
<nigelb> heh
<nigelb> python-gdata is a fun API.
<flacoste> nigelb: you have a weird definition of fun
<nigelb> I once used it for some calender stuff and decided I will never touch those ever again.
<flacoste> lol
<flacoste> yeah, i totally understand that feeling
<nigelb> the documentation is awesome
<nigelb> Takes about 1 hour to figure out :P
<flacoste> well, the gdata documentation
<jcsackett> cjwatson: i've sent your branch out to land.
<nigelb> and then you spend a next 8 head-desking how to get it to do what you want.
<flacoste> nigelb: oh, you are only talking about understanding the 5 different ways in which you can authenticate
<flacoste> yes, that took me about 1h
<nigelb> heh
<nigelb> flacoste: what specifically are you trying to do?
<flacoste> nigelb: 2011-09-29 15:37:48 INFO    2208-84-1 applied just now in 0.3 seconds
<nigelb> w00t
<nigelb> I'll paste that to mark the bug qa-ok
<flacoste> nigelb: i'm trying to update spreadsheets
<nigelb> Oh. Ew.
<flacoste> yeah
<nigelb> That's going to be super painful.
<flacoste> yeah
<flacoste> the update API isn't exposed in python yet
<flacoste> and isn't that hot to begin with
<flacoste> and resorting to xls export isn't that fun either
<nigelb> This means you'll have to play with a fair bit of XML.
<flacoste> not sure how good is the round-tripping story there
<flacoste> nigelb: no way! i'm not writing XML :-)
<nigelb> heh
<flacoste> nigelb: i'll upload new CSV files at the worst
<nigelb> Eventually, you'll end up writing a new app to replace what you did with google docs spreadsheets :)
<nigelb> To be fair, that'll probably end up being easier as well. :P
 * nigelb sleeps
<lifeless> flacoste: as an API wrapper launchpadlib is certainly easy to roll with; its defects are nonobvious to a casual user ;)
<flacoste> :-)
<mwhudson> gary_poster, lifeless : you might be interested in https://code.launchpad.net/~mwhudson/launchpad/introduce-IParticipationWithAnnotations-bug-623199/+merge/77611
<gary_poster> mwhudson, hey, cool
<mwhudson> gary_poster: https://bugs.launchpad.net/launchpad/+bug/861510 made me angry enough to start thinking about it again :-)
<_mup_> Bug #861510: XMLRPCTestTransport is not torn down properly <test-system> <Launchpad itself:Triaged> < https://launchpad.net/bugs/861510 >
<gary_poster> mwhudson, heh, I'm sorry you got angry, but glad you channelled it productively :-) .  As far as approving, I have no idea if you caught everything, but I'm a big +1 on making progress either way.  I'll approve it if you like.
<gary_poster> (If so, I'll look a bit more carefully ;-) )
<mwhudson> gary_poster: i don't know whether i should try to use it before landing, i think it probably makes sense to validate the idea
<gary_poster> ...and my wife just came in to ask me when I was going to quit :-P
<mwhudson> haha
<mwhudson> well, ok, maybe leave it for today then :-)
<mwhudson> i probably won't have time to work on it until next week
<gary_poster> mwhudson, ok, thanks :-) .  The only thing I don't want to see is the progress languish...
<mwhudson> ffs qastaging
<lifeless>  mwhudson whats down with qastaging?
<mwhudson> lifeless: just timing out a lot
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 261 - 0:[########*** stack smashing detected ***: ./lp terminated
<lifeless> sinzui: hey, so your long mail was interesting
<lifeless> sinzui: if you want to touch base about it monday or something, that would be cool
<sinzui> lifeless, yes please! I expect to have a few additional ideas about policy
<sinzui> huwshimi, https://launchpad.net/~huwshimi/+participation
<sinzui> wallyworld, StevenK, wgrant, I will be a few minutes late to the meeting.
<wallyworld> ok
* wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Critical bugs: 261 - 0:[########*** stack smashing detected ***: ./lp terminated
 * wgrant fixes the conflict.
<wgrant> But there is no conflict...
<wgrant> Hm, I wonder if the push failed.
<poolie> hi all
<poolie> hi afc, did you see your bug was fixed?
<wgrant> lifeless: https://pastebin.canonical.com/53637/ <- we seem to have a PQM bug.
<StevenK> wgrant: https://bugs.launchpad.net/unity/+bug/861710
<_mup_> Bug #861710: [regression] smspillaz fails to sleep at proper hours, despite solar status <bitesize> <end-of-cycle-euphoria> <insanity> <madness> <Compiz:Confirmed for smspillaz> <ubuntu-community:New> <unity:Confirmed for smspillazs-mom> <Weather Indicator:Opinion> <firefox (Ubuntu):Triaged by micahg> <linux (Ubuntu):Triaged by jjohansen> <unity (Ubuntu):Triaged by smspillazs-mom> < https://launchpad.net/bugs/861710 >
<lifeless> wgrant: meep!
<wgrant> lifeless: Just a bit.
<lifeless> wgrant: is it repeating ?
<wgrant> lifeless: For about 5 hours now.
<wgrant> Oh.
<wgrant> No, sorry.
<wgrant> That particular error only happened once.
<lifeless> ok, file that on pqm then
<lifeless> whats the other error ?
<wgrant> But it hasn't pushed, so it keeps trying to remerge and finding nothing to do.
<lifeless> righto, thats easier to fix
<wgrant> No error, just needs a manual push, I guess.
<lifeless> we'll need to see if the next merge repeats that error
<StevenK> sinzui: Would you mind +1'ing the MP we spoke about on the call?
<sinzui> I will
#launchpad-dev 2011-09-30
<wallyworld> sinzui: you were right. before ff bug count = 21961. after = 21984
<wallyworld> unless we had those new bugs filed in the few minutes between running the queries which is possible
<wgrant> wallyworld: Could you please review https://code.launchpad.net/~wgrant/launchpad/trim-dak-utils/+merge/77629?
<wallyworld> sure
<wallyworld> as soon as the diff updates
<wallyworld> bring on longpoll
<wgrant> Hmm, it should already be up to date.
<wgrant> The warning is gone now.
<wallyworld> wgrant: did you run lint? there's an unused import in sync-source.py
<wallyworld> wgrant: the error handling sematics seem to be changed. dak_utils.fubar wrote to stderr and exits. now we throw an exception. will the caller of the script  "do the right thing" when it receives an exception? do we need to change any tests to match the new behaviour?
<StevenK> wallyworld: I find it amusing that you think the scripts in question are tested.
<wallyworld> StevenK: they're not?
<StevenK> I suspect they aren't.
<wallyworld> oh well. i thought the question was worth asking
<StevenK> qa-tagger disabled
<StevenK> I'm playing with where it is published
<wgrant> wallyworld: Oh, I guess sync-source.py might possibly be worth linting.
<wgrant> wallyworld: The others I dare not try.
<StevenK> nigelb: Do you happen to be here?
<StevenK> Haha
<wgrant> wallyworld: But the only unused import I see is _pythonpath.
<wgrant> Which isn't unused at all.
<wallyworld> wgrant: that's the one
<wgrant> wallyworld: All scripts need to import that.
<wgrant> To get the right python path.
<wgrant> Imports with sideeffects ftl.
<wallyworld> oh, ok. it was showing up as unused for me
<wgrant> It is unused.
<wgrant> It just has side-effects.
<wgrant> All scripts do it :(
<wallyworld> right.
<wgrant> Yay buildout.
<wgrant> Those two scripts are hopefully not long for this world, anyway.
<wallyworld> the other questions about error handling?
<wgrant> As for the dak_utils.fubar replacement... it's a LaunchpadScript now (I ported it two weeks ago), so raising LaunchpadScriptFailure logs an error and exits.
<wgrant> And there are no tests.
<wgrant> Well, no tests for error handling.
<StevenK> qa-tagger re-enabled, please visit our new location at http://lpqateam.canonical.com/qa_reports/deployment-stable.html
<wgrant> Just a couple of trivial end-to-end functionality checks.
<wallyworld> ok. thatnks for the explanation
<wgrant> StevenK: Excellent.
<wgrant> StevenK: Although it is tempting to s/qa_reports/qa-reports/
<StevenK> And redirect in place
<StevenK> wgrant: I can if you wish
<wgrant> Underscores make me sick :)
<wgrant> LP forbids them in most places.
<StevenK> wgrant: So, do eet, or we don't care?
<wgrant> Might as well do it.
<wgrant> Pretty URLs are nice.
<wgrant> Thanks.
<StevenK> Everything changed.
<StevenK> Drafting announce message to -dev
<wgrant> Although I am glaring disapprovingly at your tag-nator-o-matic.sh diff :)
<StevenK> Why?
<wallyworld> wgrant: r=me
<wgrant> wallyworld: Thanks.
<wgrant> StevenK: Hardcoding devpad-specific paths is evil.
<wgrant> The old way was slightly evil too.
<wgrant> But this is worse.
 * StevenK handwaves
<StevenK> Patches welcome, etc, etc.
<wgrant> StevenK: You probably also need to tell the dashboard about the new paths.
<StevenK> Ah
<StevenK> Yes, since I moved them
<StevenK> carob doesn't have bzr grep. For shame.
<StevenK> wgrant: Dashboard's config fixed.
<wgrant> Thanks.
<wgrant> Oh, staging's DB actually managed to restore last weekend.
<StevenK> Gasp!
<StevenK> Or something.
<StevenK> wgrant: Did you see my kill-+viewstatus MP?
<wgrant> StevenK: I did.
<StevenK>  92 failures, 15 errors
<wgrant> lol
<StevenK> wgrant: However, I wanted to pick your brain -- due to removing +viewstatus, some TAL now fails due to data/task_link being gone, or something
<sinzui> wallyworld, The sql statement has still *not* completed
<StevenK> Haha
 * StevenK points sinzui at the launchpad-dev mailing list
<wallyworld> sinzui: bollocks. perhaps we just set them all the true
<wallyworld> just to get some data there
<mwhudson> hooray feature flags are still working on prod
<sinzui> wallyworld, Maybe we should consider restoring the db to qastaging more than twice a year
<StevenK> That would be nice.
<wallyworld> sinzui: +1 on that
<wallyworld> then this issue would not have happened
<StevenK> TBH, I think sourcherry can just restore qas's db after stagings
<wallyworld> once a day would be nice
<StevenK> Sure, if you want qas down for six hours
<wallyworld> six hours! jeez
<poolie> StevenK, congrats on making things a bit more open
<poolie> iwbni that page also showed recently deployed revisions
<StevenK> poolie: Thank you :-)
<StevenK> poolie: That's lpqateam.c.c, which is already open
<poolie> rather than cutting off at the point of what is actually deployed now
<wgrant> Indeed.
<StevenK> wgrant: http://pastebin.ubuntu.com/699465/
<StevenK> wallyworld: That's roughly how long staging is down over the weekend
<wgrant> wallyworld: A DB restore takes about 24 hours.
<wgrant> And the service has to be down for a little while (not quite 6 hours, though).
<wallyworld> why can't we just use normal replication type processes? ie feed across archive logs as they occur (to use Oracle terminology)
<wgrant> qastaging and staging have writes.
<StevenK> And there is data we prune before restore
<wgrant> Syncing archive logs won't help unless we then use PITR to regress the DB.
<wallyworld> so no easy naswer
<wgrant> Plus using backups means we have evidence that our backups work.
<wallyworld> true
<wgrant> StevenK: THe problem there should be pretty obvious :)
<wgrant> StevenK: You no longer define task_link...
<wgrant> - task_link = edit_link if can_edit else view_link
<StevenK> wgrant: Right, but what the heck can I set it too
<wgrant> edit_link is probably fine
<wgrant> The number of people who have deliberately gone to +viewstatus in the last three years is probably vanishingly small.
<StevenK> So just task_link = edit_link = ... ?
<wgrant> Yes.
<StevenK> Right
<wgrant> wallyworld: If you want we can probably kick off a qastaging restore now.
<wallyworld> wgrant: that would save sinzui some sql grief
<wgrant> Although just before the weekend might not be ideal, because it's not automatic.
<wgrant> But say we do it on Monday morning.
<wgrant> You can land your DB patch on Tuesday.
<wallyworld> ok
<wallyworld> it's only a column not null patch so no biggie
<mwhudson> monday morning apac time is probably the best time for having a losa around but not disrupting people too much
<spm> mwhudson: not when it's a public holiday
<mwhudson> yes
<wgrant> Is it really?
<mwhudson> is it a public holiday on monday?
<wgrant> lol ACT
<spm> NSW/ACT
<wgrant> lol NSW too.
<wgrant> Which public holiday?
<StevenK> Labour Day
<spm> does it matter? :-)
<wgrant> We have nothing between like June and November.
<wgrant> Ahh.
<StevenK> So we celebrate by doing none.
<spm> ACT has our silly public hol a week later.
<spm> Family and Community Day, or something. from memory.
<wgrant> Oh great, AFL Grand Final this weekend.
<spm> So Vic is having ALL of next week off.
<wgrant> Heh
<StevenK> % bzr log | head -n 7 | tail -n 1
<mwhudson> did the fuss about someone claiming that the reason women don't get paid as much as men was down to women taking time off to have their periods make it over the ditch?
<mwhudson> http://twitter.com/#!/Hilary_Barry/status/88679250365919232 in any case
<wgrant> Heh.
<mwhudson> spm: it's the NRL final too, so i think NSW will be hung over for a weel too
<mwhudson> *week
<wgrant> Both on one weekend? Is that normal?
<mwhudson> no idea
<mwhudson> i don't live in/come from victoria, why would i know anything about afl?
<spm> ^^ this
<wgrant> Heh, indeed.
<spm> and yes, I believe it is very normal. totally difference markets, so no real overlap.
<spm> different*
<mwhudson> i only really know about the nrl final because the nz warriors are in it
<StevenK> Silly Freenode
<spm> still chuckle at the pic a mate had; the poster reading I support NZ and any team playing against Australia.
<mwhudson> ... unless it's the springboks, i suspect
* wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Critical bugs: 254 - 0:[#######=]:256
<StevenK> Gasp
<nigelb> StevenK: I am now
<nigelb> StevenK: \o/ Public deployment reports!
<StevenK> nigelb: I thought you'd be excited
<wgrant> nigelb: I've requested the deployment of your statusexplanation patch for tonight.
<nigelb> StevenK: First mail I opened today :)
<StevenK> Careful. Now nigelb might explode with happiness
<nigelb> wgrant: Thanks! I was planning on poking you about that.
<nigelb> hahaha. Entirely possible.
<StevenK> Mailing list archive still doesn't have my mail, though.
<nigelb> How does db-devel work for deployment?
<wgrant> nigelb: We push the desired revision to the DB master (wildcherry), run full-update.py to apply the patches, then merge that revision into devel.
<nigelb> ah, more manual process than for devel?
<wgrant> nigelb: Pretty similar.
<wgrant> huwshimi: Did you find a solution to your Unity oddness?
<wgrant> huwshimi: I just upgraded and got the same thing.
<nigelb> ah, I need to sort out an issue I had with my second db-patch.
<huwshimi> wgrant: No, I was going to report a bug, but didn't know how so haven't yet
<wgrant> thumper: Is Nautilus' root window meant to be unhappy with sitting entirely on the screen now?
<thumper> wgrant: ahhh... whut?
<huwshimi> wgrant: It's a new Unity feature called The Void
<huwshimi> thumper: Like this: http://imgur.com/GeKHl
<huwshimi> thumper: The desktop is out of aligment, but everything works (except the void behind)
<thumper> that looks like a fubar
<huwshimi> thumper: windows, dash, launcher etc. all sit on top of the void with no problems
<wgrant> DnD in the shifted root window is also a bit odd.
<wgrant> It detects the drop at the location it would be if it wasn't shifted.
<wgrant> But normal clicks work fine.
<nigelb> This reminds me - is everything alright with Mark's dictionary? :)
<wgrant> nigelb: It is getting a bit late :(
<nigelb> wgrant: I feel weird with UDS scheduling started and no name yet.
<wgrant> thumper: people.canonical.com/~wgrant/what.png is mine
 * wgrant tries it on different hardware.
<wgrant> Bug #862743
<_mup_> Bug #862743: Desktop drawn with offset <amd64> <apport-bug> <oneiric> <running-unity> <unity (Ubuntu):Confirmed> < https://launchpad.net/bugs/862743 >
<nigelb> wgrant: Is that one dialog box that you dragged in "the void"?
<wgrant> nigelb: Yes.
<wgrant> There's no window ther.
<nigelb> Ew.
<wgrant> So it starts as what looks like uninitialised GPU memory.
<nigelb> 3 weeks to release? WIN.
<wgrant> 3 weeks?
<wgrant> 2 weeks - 1 day :)
<nigelb> Oh, right. Its friday.
<wgrant> Hm, Ubuntu Mono is pretty nice.
<nigelb> Screenshot plz?
<wgrant> Upgrade from Lucid :P
<nigelb> Maybe soon.
<nigelb> I don't want to setup about 5 to 6 build environments again.
<nigelb> Launchpad, firefox, ubuntu web projects, mozilla web projects, work env.
<wgrant> And now X crashes.
<nigelb> wgrant: Bwahaha! I haz Ubuntu Mono
<nigelb> I remembered that Ubuntu members have access to the private PPA :)
<nigelb> And yeah, its pretty neat
<huwshimi> nigelb: You can actually download it from http://font.ubuntu.com/ too
<nigelb> huwshimi: yeah, but the PPA was easier :)
<thumper> huwshimi, wgrant: please file bugs with pictures and graphics drivers
<wgrant> thumper: In addition to the existing 36-affected bug #862743?
<_mup_> Bug #862743: Desktop drawn with offset <amd64> <apport-bug> <oneiric> <running-unity> <unity (Ubuntu):Confirmed> < https://launchpad.net/bugs/862743 >
<thumper> wgrant: nah
<wgrant> There's no proprietary driver listed in that bug, so it's probably not fglrx's fault.
<thumper> huwshimi: what GPU?
<thumper> wgrant: also, what's your GPU?
<huwshimi> thumper: erm
<huwshimi> thumper: How do I find out?
<huwshimi> thumper: I used to know this stuff, but Ubuntu has been to easy for too long :)
<thumper> huwshimi: glxinfo
<wgrant> thumper: Radeon 5700 of some variety.
<wgrant> With whatever fglrx oneiric has these days.
<wgrant> Radeon HD 5700, that is.
 * thumper is passing information on
<huwshimi> thumper: it's an AMD of some kind
<wgrant> My GM45 should be upgraded in a few minutes.
<wgrant> Will see if that is borked too.
<huwshimi> wgrant: The fix in that thread fixed it for me
<huwshimi> *thread/bug
<thumper> what was the fix?
<huwshimi> "pkill nautilus"
<thumper> heh
<huwshimi> thumper: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/862743/comments/12
<_mup_> Bug #862743: Desktop drawn with offset <amd64> <apport-bug> <oneiric> <running-unity> <unity (Ubuntu):Confirmed> < https://launchpad.net/bugs/862743 >
<thumper> huwshimi, wgrant: have either of you had that happen after a reboot (when not upgrading)?
<wgrant> thumper: I've never seen it before today.
<wgrant> Ah, pkill nautilus worked for me this time.
<huwshimi> thumper: Yeah I rebooted after the upgrade to see if that would fix it. It didn't.
<wgrant> I tried it half an hour ago and it just crashed unity.
<wgrant> And X crashed 30s later, before I could get to apport.
<wgrant> Which caused compiz to crash again, wiping out the original report.
 * thumper snorts
<nigelb> StevenK: Its been an hour and I still don't see your email in the web archive :(
<nigelb> that was definitely badly timed :|
<wgrant> thumper: Affects my Intel GM45 too.
<thumper> weird
<StevenK> I see wallyworld is eshewing underscores for esoteric guest nicks.
<thumper> wgrant, huwshimi: looks like jason just committed a fix for that
<huwshimi> thumper: :D
<wgrant> thumper: Great.
<wgrant> Ah, I see.
<nigelb> StevenK: How often does Launchpad mailing list archive get updaetd?
<wgrant> Heh.
<wgrant> Poor forster is a little overloaded at the moment.
<wgrant> It's meant to be ~instantaneous.
<wgrant> But ubuntu-x-swat has a very large archive.
<nigelb> Its ben ~2 hours :P
<nigelb> *been
<wgrant> A week ago it was around two days behind :/
<wgrant> I fear we may need to disable ubuntu-x-swat's archive.
<nigelb> my theory was it hates StevenK. This explanation works as well :P
<wgrant> That works.
<StevenK> wgrant: Do we still use a DebugLayer for anything?
<StevenK> I'm still tempted to rip out config.canonical.show_tracebacks in this branch, too.
<wgrant> We still run a separate DebugLayer HTTP listener in dev. Not sure why.
<StevenK>         if canonical.launchpad.layers.DebugLayer.providedBy(self.request):
<StevenK>             self.debugging = True
<nigelb> hah, bug has connections! https://bugs.launchpad.net/ubuntu/+source/software-center/+bug/752790/comments/6
<_mup_> Bug #752790: unbuntu software center <amd64> <apport-bug> <apport-lpi> <natty> <software-center (Ubuntu):Expired> < https://launchpad.net/bugs/752790 >
<StevenK> Holy heck that diff generation was fast
<StevenK> wallyworld: https://code.launchpad.net/~stevenk/launchpad/kill-plaintext-traceback-rendering/+merge/77647
<nigelb> wgrant: Do you notice that Ubuntu Mono is smaller than the default mono?
<nigelb> (well, the old monospace font)
<wgrant> nigelb: Significantly so :(
<nigelb> Yeah, I had to increase font size from 10 to 12
<StevenK> How can I figure out which revision removed a file?
<wgrant> StevenK: I tend to "bzr log -v" then search through that.
<wgrant> There may be a better way.
<wallyworld> StevenK: doing it now
* wgrant changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Critical bugs: 247 - 0:[#######=]:256
<nigelb> StevenK: do you know the file?
<nigelb> you should be able to do bzr log /path/to/file
<StevenK> That says not versioned
<StevenK> Either way, bzr log -v is a good idea
<nigelb> That's intersting. I just tested it on a standalone repo on my machine and it worked.
<StevenK> And one more tech-debt bug closed.
<nigelb> \o/
<nigelb> I have a tech-debt bug to close as well.
<wallyworld> StevenK: i wonder if PageTestLayer itself is still used at all?
<StevenK> wallyworld: Story tests
<wallyworld> ok
<wallyworld> StevenK: r=me
<jtv> wgrant: did you just assign an ancient "we should rewrite cron.publish-ftpmaster" bug to me just so I could get the karma for it being Fix Released?  :)
<wgrant> jtv: Probably.
<wgrant> I am gardening.
<jtv> Well thanks.
<spm> [16:44:06] <wgrant> I am gardening. <== with a chainsaw? at ~ 3-5 inches above the ground?
<StevenK> That's the best way to do it.
<nigelb> spm++
<spm> my F-in-law is a former cane farmer. from tropical queensland. his idea of a light prune involves a chain saw at a similar "height"
<nigelb> With wgrant's history of deleting large parts of launchpad codebase, I'm guessing his idea of gardening is similar.
<spm> HEH
<spm> oops. sorry, caps fail
* wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 247 - 0:[#######=]:256
<bigjools> morning
<wgrant> Morning bigjools.
<huwshimi> Have a nice weekend everyone
<bigjools> hello huwshimi
<bigjools> thanks for the icons
<rvba> \o huwshimi
<huwshimi> bigjools: Hey. No problems :)
<lifeless> bigjools: hey
<lifeless> bigjools: so I may have been a bit cryptic on the bug - let me know if os
<lifeless> *so*
<bigjools> lifeless: not even in my email yet
<bigjools> lifeless: oneiric's network manager doesn't write resolve.conf properly for static interfaces .... screws me every day
<bigjools> but thanks :)
<lifeless> bigjools: win!
<bigjools> not so much!
<lifeless> sarcasm!!
<bigjools> irony!
<lifeless> !!! --- !!!
<adeuring> good morning
<lifeless> wallyworld: wgrant: win - OOPS-2099AR35 - fallout from updating subscriptions when retargeting
<wallyworld> lifeless: you mean associating a bug with a different project/distro as opposed to changing privacy/security settings ?
<lifeless> yes
<lifeless> its correctly unsubscribing launchpad-security
<lifeless> but the redirect is to a 404 (and so oopses as its internally generated)
<wallyworld> i'm not aware of what actions we take when retargetting. i just did the privacy/security stuff
<lifeless> when one retargets such that one can't see, we probably want to return the,m to the original context
<wallyworld> that sounds reasonable
<lifeless> wallyworld: I know, its a corner case we didn't identify in advance
<wallyworld> i assume this can wait till next week?
<lifeless> I'm filing a bug for it. I'll tag it disclosure (as disclosure made it possible to happen).
<lifeless> yes, it will be rare.
<wallyworld> cool. i'll make sure it's fixed first up
<lifeless> bigjools: hi, is bug 241646 still a bug ?
<cjwatson> jcsackett_: thanks!  (yes, the Ubuntu archive admins are to the best of my knowledge the only users of this)
<bigjools> lifeless: technically yes, but I've never seen it a problem in practice
<jelmer> wallyworld: hi
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Critical bugs: 247 - 0:[#######=]:256
<bigjools> wgrant: I'm adding rabbitmq-management to lp-messagequeue-deps now that you packaged oneiric.  Current version is 0.99, might either head to 0.99.1 or bit the bullet and go 1.0
<wgrant> bigjools: Or 0.100..?
<wgrant> But yes, good plan to add it.
<bigjools> I typed that and it looked horrible!
<wgrant> Better than 1.0 :)
<bigjools> what's this aversion to 1.0!
<wgrant> We're hardly stable :P
<bigjools> it's a f***ing dependency package!
<wgrant> We could also just drop the 0. and go straight to 100
<lifeless> we really should do bug 288645
 * wgrant pokes _mup_
<wgrant> Bug #288645
<wgrant> grr
<lifeless> mup was a victim of the netsplit I think
<wgrant> Ah, that one.
<bigjools> Bug #288645: "Register a branch" on hosted branches is confusing <https://launchpad.net/bugs/288645> <launchpad [Triaged/High] No assignee>
<wgrant> There's a lot of LP UI bits that could do with some fixing...
<bigjools> pls to be reviewing https://code.launchpad.net/~julian-edwards/meta-lp-deps/add-rabbit-management/+merge/77692
<bigjools> gah, still "Updating diff...". If only we had some way of making that update automatically.
<wgrant> It often takes >30min at this time of night :/
<bigjools> hmmm should I be targeting oneiric
<bigjools> does it matter with recipes?
<wgrant> Doesn't matter hugely.
<wgrant> Recipes will do it.
<bigjools> k
<wgrant> https://lpstats.canonical.com/graphs/BuildersActiveVirtual/20110924/20111001/ is somewhat upsetting.
<wgrant> Perhaps they will come back automatically.
<nigelb> StevenK: Whenever it is that I meet you, I'll buy you a beer :D
<nigelb> (Deployment report)
<bigjools> wgrant: no, we need to ping brendan
<wgrant> Most of them have been gone for slightly under a day.
<wgrant> But some have been gone for longer.
<wgrant> Not sure what's going on there.
<bigjools> they have a cron job to put them back each morning
<wgrant> Apparently not :/
<bigjools> it's broken :)
<bigjools> I'm going to start the publisher on DF BTW
<bigjools> let it steam over the weekend
<wgrant> A -A or -P will crash.
<wgrant> Due to The 53.
<bigjools> grar
<bigjools> right, off for a liquid lunch
<wgrant> You could grab them into the pool manually and then run the rescue script.
<wgrant> There should only be 4 in oneiric that are problematic.
<wgrant> (BPPH IDs and filenames are in my analysis)
<nigelb> wgrant: \o/ Thanks!
<nigelb> One tech-debt bug fixed!
<nigelb> Also, another mpt bug nailed.
<wgrant> Heh.
<wgrant> Should have closed it hours ago, but forgot.
<nigelb> 368 tech-debt bugs. wow.
<wgrant> More than 5800 open bugs :)
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring,bac | Critical bugs: 247 - 0:[#######=]:256
<StevenK> nigelb: :-D
<mrevell> Hey, I have an old branch. I've rocketfuel-got and merged devel into my branch. My branch's utilities directory seems to have stayed old; there's no ec2 in there, just the old ec2test.py. Any tips on what I need to do to fix that?
<deryck> adeuring, abentley -- morning.  do both of you have google plus access?
<abentley> deryck: I do.
<adeuring> deryck: no
<deryck> adeuring, do you have a google account?
<adeuring> deryck: yes
<deryck> adeuring, can you give me that account addr info privately?
<flacoste> mrevell: have you run make yet?
<deryck> abentley, I'd like to try standup on Google+ this morning, for reasons to be obvious later.  adeuring is still getting setup.
<abentley> deryck: okay.
<deryck> so ping adeuring when you're in.  if it goes too long, we can default to mumble.
<adeuring> deryck, abentley i think i now have an account
<deryck> ok, cool.  let me find you....
<deryck> adeuring, can you search for me and add me to a circle?
<adeuring> I'll try
<deryck> never mind, adeuring.  found you.
<deryck> adeuring, abentley --trying a g+ hangout invite.
<adeuring> deryck: installing a plugin now...
<deryck> adeuring, ok.
<adeuring> USB headset
<adeuring> deryck: the plugin does nor detect the ZSB headset
<deryck> adeuring, ah.  abentley says his works but starts muted.
<deryck> adeuring, abentley -- starting hangout again now.
<mrevell> flacoste, Ah, no, I hadn't, thanks.
<flacoste> mrevell: try a make clean ; make and see if things change
<flacoste> it should run bootstrap for one
<rsalveti> hey, I'm looking at packaging recipes now, and noticed we only have 2 build options, daily and on request
<rsalveti> at least for us it would be useful to have something like weekly or similar instead of just daily
<rsalveti> is this exported by the launchpad api or should I just fill a bug at lunchpad? (if there is no bug for this yet)
<rsalveti> if we can request the builds by the api we can just set up a cron
<bigjools> rsalveti: there's a requestBuild method on the source_pacakge_recipe
<jelmer> rsalveti: note also that the daily build will only happen if the branch has actually changed
<deryck> abentley, adeuring -- let's mumble
<jelmer> Looks like berlios.de is shutting down at the end of the year
<rsalveti> jelmer: sure, that's fine
<rsalveti> bigjools: great, guess that should be enough
<rsalveti> thanks guys
<abentley> jelmer: This git import branch isn't staying up to date, and I'm having trouble understanding the log.  Any ideas? https://code.launchpad.net/~ribalkin/ucloud/import
<jelmer> abentley: hi
<abentley> jelmer: Hi.
<jelmer> abentley: that's odd, seems like the fetch operation doesn't import the branch tip for some reason
<jelmer> lp/lib/lp/codehosting/codeimport/worker.py:777
<abentley> jelmer: I tried importing that branch locally, and I got an up-to-date copy.
<abentley> jelmer: that was a few days ago.
<jelmer> abentley: yeah, it works fine here too
<jelmer> when you say importing, did you try the code importer locally, or just "bzr branch https://github.com/cyberb/uCloud.git" ?
<abentley> jelmer: just bzr branch...
<jelmer> abentley: is there a bug report about this?
<abentley> jelmer: no, it came in to help@launchpad.net, so there's an RT.
<abentley> jelmer: https://support.one.ubuntu.com/Ticket/Display.html?id=5780
<abentley> jelmer: (apparently they've renamed the branch from trunk)
<jelmer> abentley: hmm
<jelmer> abentley: I have to EOD, can you file a bug about this?
<abentley> jelmer: sure.
<jelmer> abentley: I can't easily reproduce it with a similar code path as launchpad uses either:
<jelmer> http://pastebin.ubuntu.com/699875/
<jelmer> abentley: it looks like an intermediate issue
<jelmer> abentley: A new import doesn't seem to have this problem
<abentley> jelmer: https://bugs.launchpad.net/launchpad/+bug/863414
<_mup_> Bug #863414: git import stops updating <code-import> <Launchpad itself:Triaged> < https://launchpad.net/bugs/863414 >
<jelmer> abentley: lp:~vcs-imports/ucloud/cyberb
<abentley> jelmer: not surprised, really.  In fact, it looks like they may have done a fresh import.
<jelmer> the main import still appears to be failing
<jelmer> I'd be interested to have a look at the problematic branch
<jelmer> some other day though :)
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: bac | Critical bugs: 247 - 0:[#######=]:256
<deryck> gary_poster, ping
<gary_poster> hey deryck
<deryck> gary_poster, do you have time sometime during the next 1 to 1.5 hours to do a short call about couple things?
<gary_poster> deryck, absolutely.  now is fine, or later
 * gary_poster gets headset
 * gary_poster has headset and is on Skype
<deryck> gary_poster, ok, coming nowâ¦..
<lifeless> gary_poster: ping
<gary_poster> hey lifeless
<lifeless> in https://code.launchpad.net/~gary/launchpad/bug844631/+merge/77725 you delete the store reset code
<lifeless> including our tests-get-clean-stores logic :)
<lifeless> I can't see it being reinstated anywhere
<lifeless> gary_poster: I didn't see mention of this in the cover letter
<lifeless> gary_poster: publication.py, @@ -751,29 +750,6 @@
<gary_poster> lifeless, yes, it was in the first comment
<gary_poster> lifeless, "lib/canonical/launchpad/webapp/publication.py has deleted code because Stuart told me to.  See comments 14 and 2 of https://bugs.launchpad.net/launchpad/+bug/844631 ."
<_mup_> Bug #844631: Launchpad should return 503 error pages when database is unavailable <escalated> <fastdowntime-later> <Launchpad itself:In Progress by gary> < https://launchpad.net/bugs/844631 >
<lifeless> ah, following pointers, una momento
<gary_poster> lifeless, I may have misunderstood, and would appreciate your guidance there
<gary_poster> lifeless, I'm also happy to simply remove that deletion and leave it for Stuart
<lifeless> comment 2 was noting one of the symptoms
<lifeless> gary_poster: I think you misunderstood. digging...
<gary_poster> lifeless, instead of digging, how about I simply reinstate and leave it for stub?
<lifeless> well, I'd like this to land ;), nearly done
<gary_poster> lifeless, yeah, sure, but it would be easy to reinstate that bit and move on
<lifeless> gary_poster: I think he meant
<lifeless> 'delete the call to .raising()'
<lifeless> gary_poster: the calls to store.rollback() and store.reset() are still needed
<lifeless> gary_poster: however, looking at that oops referenced in comment 2
<gary_poster> if we're not sure, I still am happy to simply reinstate and leave for stub
<lifeless> its clearly not fixed
<lifeless> so yeah, I think reinstate is safest
<gary_poster> cool lifeless thanks
<lifeless> (it also exposes a tech debt issue - we'd have objects surviving cross-request without the loop, and thats something I would have though was tested ;))
<gary_poster> lifeless, I haven't run the full test suite with this.  I often do, but was focusing on my changes as fairly isolated.  I kind of had forgotten about trying to follow stub's instructions.  So there may in fact be tests.
<lifeless> gary_poster: ah cool
<lifeless> gary_poster: I have commented on the source bug - https://bugs.launchpad.net/launchpad/+bug/504291/comments/11 and https://bugs.launchpad.net/launchpad/+bug/504291/comments/12
<_mup_> Bug #504291: DisconnectionErrors (already disconnected) happening again <fastdowntime> <lp-foundations> <oops> <Launchpad itself:Triaged by stub> <Storm:Invalid> < https://launchpad.net/bugs/504291 >
<_mup_> Bug #504291: DisconnectionErrors (already disconnected) happening again <fastdowntime> <lp-foundations> <oops> <Launchpad itself:Triaged by stub> <Storm:Invalid> < https://launchpad.net/bugs/504291 >
<gary_poster> cool
<bac> lifeless: did you notice i had claimed gary_poster's branch and was in the process of reviewing it?
<lifeless> bac: no I didn't
<bac> lifeless: ok. it was just odd to see it had been approved in the interim.
<lifeless> sorry for any confusion, and I'm glad you reviewed it too
<lifeless> bac: looks like you're making progress on the INCOMPLETE stuff. Cool!
<bac> lifeless: yeah, there was a particularly annoying bug that held me up.  i'm going to send an email to the dev list about it
<lifeless> I'll read that mail :)
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Critical bugs: 247 - 0:[#######=]:256
#launchpad-dev 2011-10-01
<lifeless> nigelb: you might like bugs 401620 401432 401633 401639 401640
<lifeless> infinity: is bug 409519 still the case?
<_mup_> Bug #409519: partner overrides and cache shouldn't be in ftproot <lp-soyuz> <soyuz-publish> <Launchpad itself:Triaged> < https://launchpad.net/bugs/409519 >
<lifeless> bah
#launchpad-dev 2011-10-02
<StevenK> Oh, bah. Firefox, why are you hiding the URI schema for http:// URIs? :-(
<lifeless> because chrome did it and so its obviously cool.
<lifeless> nevermind that it completely messes things up
<StevenK> If Firefox is just going to copy Chrome, that's disappointing.
<lifeless> oh, I agree.
<nigelb> lifeless: <3
<nigelb> thanks!
<nigelb> StevenK: Speaking of browsers, this might be entertaining - http://lh4.googleusercontent.com/-lwEG-pIhR3Q/TodEKkigwVI/AAAAAAAACgs/ARfogL6LqXM/s512/msft.jpg
<StevenK> nigelb: I saw that
<nigelb> :)
<lifeless> under one page of mediums left
<mwhudson> lifeless: and hey, i just closed two of the bugs you reclassified
<lifeless> mwhudson: cool
<mwhudson> three!
<nigelb> do I hear a four? ;)
<lifeless> going once
<lifeless> spring cleaning :)
<mwhudson> sadly no more yet
<nigelb> I think I found the best spring cleaning material in tech-debt.
<nigelb> Although fixing one bug = at least 2 to 3 MPs :P
<mwhudson> my current launchpad side project is made of tech-debt
<lifeless> nigelb: thats more like an attic :) - this is stuff that we have lying around uncategorised ;)
<nigelb> lifeless: heh
<nigelb> I can see the spiderwebs hang off those bugs :P
<lifeless> :)
<wallyworld_> wgrant: were you going to look at 863098?
<wgrant> Bug #863098
<_mup_> Bug #863098: OOPS when retargeting a private bug to a context the user cannot see private bugs by default <404> <bugs> <disclosure> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/863098 >
<wgrant> I wasn't.
<wallyworld_> ok. i can
<jelmer> hi wallyworld_, wgrant
<wgrant> Evening jelmer.
<wallyworld_> hello
<wgrant> wallyworld_: Thanks.
<wallyworld_> np. just wan't to make sure we weren't going to double up
<wallyworld_> i hate unity today. had to totally blow alway all my settings to get it to not lock up the desktop
<wgrant> wallyworld_: I suspect the solution will be to just subscribe the actor, as we do when making a bug private in the first place.
<wallyworld_> wgrant: that would work code wise. is that what we want to do policy wise? i guess so
<wgrant> +          xdr: {use: 'flash'},
<lifeless> or just set next_url to a different value
<wgrant> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
<lifeless> + add a notification
<lifeless> I wouldn't expect the actor to be subscribed; in fact it will be explicitly *against* one of curtis' rules to do that.
<lifeless> the rule being 'for "private projects" newly private-in-that-project bugs have no subscriptions other than the default set'
<wgrant> Private projects don't exist.
<wgrant> So rules around them aren't relevant yet.
<wgrant> c-i-p is a default-private-bugs project, where the reporter has a subscription regardless.
<lifeless> 'private bugs by default' seems to be your proxy for now
<lifeless> wgrant: the reporter is one of the default set of subscriptions
<lifeless> wgrant: the triager isn't
 * wallyworld_ wonders whether to take the red pill or blue pill
<mwhudson> hooray for not landing code until you have a use for it
<wgrant> lifeless: But the triager is the one reporting the bug in the "private project".
<wallyworld_> mwhudson: you referring to your mp from friday?
<mwhudson> wallyworld_: yes
<lifeless> wgrant: ahhh, no I'm not :)
<lifeless> wgrant: meh, I can see arguments both ways.
<wallyworld_> mwhudson:  do you have a specific use case for it now?
<lifeless> wgrant: whatever you guys decide, I think it needs documentation if it will increase the visibility of such bugs
<mwhudson> wallyworld_: basically, it seems stuffing things in annotations is unpleasant, better to just have an IParticipationExtras interface that separately defines the things we care about
<wgrant> lifeless: I feel that all these changes are insane.
<wgrant> lifeless: Because they're making an existing confusing and exceptional privacy mechanism even more confusing and exceptional, in a gradual fashion.
<wgrant> lifeless: Rather than a one-off change to a sensible one.
<mwhudson> wallyworld_: yeah, trying to (only) store the feature flag controller on the participation
<lifeless> wgrant: so the goal is a sensible one; I agree that gradual changes can be tricky.
<lifeless> wgrant: I wouldn't want to see massive code drops, but I could totally see stuff being feature flagged until all the bits are in place
<wallyworld_> mwhudson: +1 for that ff change
<wgrant> For stuff like this they're not tricky: they're dangerous.
<wgrant> lifeless: Right, that is what I intended from the start. But it seems everyone prefers gradual change :/
<wgrant> Normally, sure. But not for something like this.
<lifeless> wgrant: talk to your team :)
<lifeless> wgrant: FWIW, to me, feature-flagged to ~launchpad isn't gradual change, because only we're affected, and we can deal.
<lifeless> wow, our lp-oops install has masssssive cruft in it
<lifeless>                                            QUERY PLAN
<lifeless> ------------------------------------------------------------------------------------------------
<lifeless>  Seq Scan on oops_oops  (cost=0.00..1991487.27 rows=2772 width=68)
<wallyworld_> wgrant: so, what's the consensus? subscribe or redirect with notification?
<wgrant> Not sure.
<wgrant> But looks like we need to roll back the latest devel rev.
<wgrant> It breaks lots of profiling tests, it seems.
<wgrant> (and introduces Flash, so getting rid of it is a bonus :))
<wallyworld_> flash?
<wallyworld_> what for?
<wgrant> Bypassing cross-domain request restrictions.
<wgrant> I assume.
<wallyworld_> you mean someone wrote action script?
<wgrant> No.
<wgrant> YUI has some Flash embedded.
<wgrant> To use as an XHR transport.
<wgrant> To violate browser cross-domain request restrictions.
<wgrant> Because Flash is more holey.
<wallyworld_> i thought flash functionality was implemented using ActionAcript
<wallyworld_> ActionScript
<wgrant> This is a prebuilt SWF in YUI.
<wallyworld_> ok
<wallyworld_> yuck
<wgrant> Because fuck good practice, let's put proprietary compiled formats in our tarballs :)
<lifeless> the 503 page ?
<wgrant> lifeless: Yes.
#launchpad-dev 2012-09-24
 * StevenK stabs the uploadprocessor tests
<StevenK> Fill up a bunch of changes files with the same signature and different data and then a new test fails GPG verification
<lifeless> can has review ?
<lifeless> https://code.launchpad.net/~lifeless/pybars/bug-1040096/+merge/125874
<StevenK> And back to fighting with gpg
<StevenK> wgrant: The current files specify a DSA key ID that isn't in the keyring
<wgrant> StevenK: Which file?
<StevenK> wgrant: steven@undermined:.../suite/bar_1.0-4% GNUPGHOME=../.. gpg --verify < bar_1.0-4_source.changes
<StevenK> gpg: WARNING: unsafe permissions on homedir `../..'
<StevenK> gpg: Signature made Thu 25 Jan 2007 07:02:00 AM EST using DSA key ID 6C64A8C5
<wgrant> StevenK: lib/lp/testing/gpgkeys/data/foo.bar@canonical.com.sec
<wgrant> sec  1024D/6C64A8C5 2005-04-13 Foo Bar <foo.bar@canonical.com>
<wgrant> (passphrase is 'test')
<StevenK> wgrant: Ah, thanks.
<StevenK> wgrant: GNUPGHOME=. gpg --import < <.sec> and then --clearsign worked
<StevenK> wgrant: Ah ha, actual    = 'Unhandled exception processing upload: too many values to unpack'
<wgrant> Excellent
<StevenK> Haha, yeah, fileline.strip().split() -> ValueError
<wgrant> As you'd expect :)
<StevenK>  lp.archiveuploader.tests.test_uploadprocessor.TestUploadProcessor.testUploadWithMalformedSectionIsRejected
<StevenK>   Ran 1 tests with 0 failures and 0 errors in 2.382 seconds.
<wgrant> Do you reject it directly, or just do a split(' ', 4) and let it fail when the filename is malformed?
<wgrant> split(' ', 3) actually, I guess
<StevenK> I catch the ValueError and yield UploadError
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/deal-with-badly-formed-section/+merge/125908
<StevenK> wallyworld_: I'd ask you to review that branch, but you'd see 'lib/lp/archiveuploader' in the diff and run screaming. :-)
<wgrant> StevenK: Looking
<wallyworld_> StevenK: sorry, was buying lunch, otherwise would have looked
<StevenK> wallyworld_: It's all good, I was only teasing you
<StevenK> I should go and buy part of my lunch
<StevenK> Otherwise I'll be having toasted turkey sandwiches with no bread
<StevenK> wgrant: Oh haha. I bet I know what is causing bug 899123
<_mup_> Bug #899123: IntegrityError raised deleting a series <bugs> <milestones> <oops> <series> <Launchpad itself:Triaged> < https://launchpad.net/bugs/899123 >
<wgrant> StevenK: Hm?
<wgrant> StevenK: It'
<wgrant> s pretty clear what the problem is.
<StevenK> wgrant: Oh? My thought is bugtasks that self.user can't see, so don't get returned so the milestone can be cleared
<wgrant> StevenK: Exactly
<wgrant> The product the series is on gives it away
<StevenK> Oh, I read the code to deduce that
<StevenK> The fact that the code is in lib/lp/registry/browser/__init__.py makes me sad
<mwhudson> wgrant: just because i know you'll understand my pain
<mwhudson>  Aggregate  (cost=1996.76..1996.77 rows=1 width=0) (actual time=449033.137..449033.137 rows=1 loops=1)
<mwhudson> i suspect this estimate of being slightly inaccurate
<wgrant> Heh
<wgrant> Django amuses me
<wgrant> The schema style it encourages introduces a lot of potential planning issues
<mwhudson> fortunately i have already rewritten this query
<lifeless> Â/win 94
<wallyworld_> StevenK: wgrant: fancy a quickie? https://code.launchpad.net/~wallyworld/launchpad/bug-sharing-policy-weirdness-1055250/+merge/125916
<StevenK> With you?
<wallyworld_> yes!
<StevenK> wallyworld_: You can't use setB{ug,ranch}SharingPolicy ?
<wallyworld_> where? test?
<StevenK> Yeah, in the tests
<wallyworld_> using setXXX() in the tests errors because it tries to create another commercial subscription and do other things we don't care about
<StevenK> Create? I thought it checked them
<wallyworld_> creating a project with private sharing policy creates a subscription at the same time
<wallyworld_> in the factory
<wallyworld_> i guess setXXX() should behave properly if there's already a subscription
<StevenK> wallyworld_: setB{ug,ranch}SharingPolicy will work fine if you're tossing in FORBIDDEN, read the code.
<wallyworld_> yes, i wonder why i got an error then, i'll retry
<StevenK> wgrant: So would user=ILaunchpadCelebrites.admin in RegistryDeleteViewMixin._getBugtasks cause me to get murdered?
<wallyworld_> StevenK: i must have been on crack or something. works. changes pushed
<wgrant> StevenK: I think so, yeah
<StevenK> wgrant: :-(
<wgrant> If you have no other choice, then maybe
<StevenK> I think my other choice is store.find(BugTask, BugTask.milestone == ...) but conjoined masters foul that up
<wgrant> StevenK: Or to give bugtasksearch an option to not do privacy checks
<StevenK> wgrant: Which I've not seen in my searching.
<wgrant> Right, you probably need to add such a feature
<lifeless> we probably should upgrade the oops-tools on lp-oops
<lifeless> or give it a quiet death
<StevenK> If we can import the oops in lp-oops into oops, then we can shoot it
<lifeless> or we could just let them go away
<StevenK> Sure, let's make a bunch of criticals more useless, what could possibly go wrong.
<lifeless> wel
<lifeless> how often do you reference them
<lifeless> and how often have they stopped happening entirely?
<StevenK> lifeless: There are a large number of critical bugs that include an OOPS and very little else. Some of these OOPSes can not be found at all, and others are only on lp-oops.
<StevenK> This OOPS happened once and hasn't occured for two years and yet we have a Critical open with no useful content.
<lifeless> so, close the critical
<lifeless> if the critical is an oops or timeout
<lifeless> the report will tell us if it happens again
<StevenK> lifeless: Bug 893576 is a good example
<_mup_> Bug #893576:   AttributeError: 'SourcePackageRecipeRequestDailyBuildView' object has no attribute 'index'  <oops> <recipe> <Launchpad itself:Triaged> < https://launchpad.net/bugs/893576 >
<lifeless> StevenK: its on neither server?
<wallyworld_> wgrant: StevenK: when a commercial voucher is redeemed, i would expect the bug/branch sharing policies to be set to proprietary automatically rather than requiring the maintainer to go to +sharing to update. from what i can tell, this doesn't happen. do we want to fix?
<StevenK> lifeless: Right
<wgrant> wallyworld_: Not exactly
<wgrant> wallyworld_: The normal use case is that someone creates a project as Other/Proprietary
<StevenK> lifeless: I'm struggling to find a bug that has an OOPS that is on lp-oops but not oops, but they do exist, and their content level is about the same as that bug.
<wgrant> So they automatically get Proprietary
<wallyworld_> wgrant: sure, but when the subscription expires and then extended
<wallyworld_> is the case i'm talking sbout
<lifeless> StevenK: so, I would grep for the error
<wallyworld_> we don't reset the policies from forbidden (or public) back to proprietary
<wgrant> wallyworld_: That's really rare and easy for them to fix manually, and we can't do it unambiguously, so probably not
<lifeless> e.g.
<lifeless> oops-amqp/launchpad/production$ grep SourcePackageRecipeRequestDailyBuildView . -r
<lifeless> if its not there, close the bug - its not happening enough to worry about for now
<wgrant> The bug is still there
<wgrant> And it's trivial to reproduce
<wallyworld_> wgrant: but it mirrors the concerns about leaking info. if they extend the subscription, they would rightly expect stuff to be private from then on. but it won't be unless they do something
<lifeless> wgrant: thats good then, you can fixup the bug
<wgrant> wallyworld_: eg. ubuntuone-servers is Other/Proprietary
<wgrant> wallyworld_: But the bugs are usually public
<wallyworld_> wgrant: or push a branch
<lifeless> wgrant: I'm just saying that we have 2K errors a day, stressing about data for something with an incident rate < 1/2 weeks is not worth doing
<wgrant> wallyworld_: Sure, and it'll tell them they need to go to +sharing to fix it
<StevenK> wgrant: Then please link a proper OOPS to the bug :_0
<lifeless> thats 1 every 2 weeks.
<wgrant> StevenK: I have
<wgrant> But it's literally as trivial as it can get
<wgrant> Just go to the pageid referenced in the OOPS
<wallyworld_> wgrant: we are now arguing different sides of the same thing we were discussing last week
<wgrant> boom
<wgrant> wallyworld_: My argument last week was primarily based on the fact that it is dangerous to leak things
<wgrant> This won't leak things
<wgrant> It will reject them
<wallyworld_> yes it will
<StevenK> Oh, let me guess +request-daily-build only wants POST
<wallyworld_> if they have changed to public
<lifeless> wgrant: that oops wasn't readable
<wgrant> wallyworld_: If they set it to Public then they probably want it Public...
<lifeless> was it ?
<wgrant>  AttributeError: 'SourcePackageRecipeRequestDailyBuildView' object has no attribute 'index'
<wgrant> ^^ that is the pageid
<wallyworld_> wgrant: they will rightly expect getting s new subscription will make things proproetary sgasin
<wgrant> Well, no actual pageid
<wgrant> But view name
<wgrant> wallyworld_: Why?
<wallyworld_> why not? i would
<wgrant> They explicitly set it to Public after the subscription expired
<wallyworld_> sure, asnd then thry buy another subscription
<wallyworld_> so they expect things to go back to provate
<wgrant> The reactivation page could hint that it hasn't changed your existing settings
<wallyworld_> reasonable expectation
<wgrant> It probably should do that, in fact, for when projects initially obtain a commercial subscription
<wgrant> But we shouldn't just override what they asked us to do 5 minutes ago
<bigjools> WTF: bzr: ERROR: Permission denied: "Cannot create 'add-maas-cluster-packaging'. Only Bazaar branches are allowed."
<wgrant> bigjools: Your URL is bad
<lifeless> wgrant: no orccurences of that oops on neem prod
<wallyworld_> wgrant: hmmm. i wonder if we can tell the difference
<wallyworld_> i'll raise a bug and we can discuss on the call
<wgrant> wallyworld_: Which difference?
<bigjools> wgrant: the branch already exists, I am pushing an update
<wallyworld_> tomorrow
<wgrant> wallyworld_: In neither case do we want to do it automatically.
<wgrant> bigjools: What's the URL?
<bigjools> oh wait
<wallyworld_> wgrant: i disagree
<bigjools> fuck sake
<wgrant> wallyworld_: The voucher redemption page should certainly point to +sharing
<wgrant> But to change it automatically? That's pretty strange.
<wallyworld_> the difference between initially getting a subscription and extending one
<wallyworld_> why?
<bigjools> wgrant: thanks, pebkac, but you pointed me in the right direction
<wgrant> Heh
<bigjools> hint: moving branches to a subdir confuses bzr :)
<wgrant> wallyworld_: Just because my code is proprietary doesn't meant that my bugs are.
<wgrant> For ease of setup we do make that policy decision, once, at project creation
<wgrant> We never set the sharing policies ourselves ever again, *except* for setting them to Forbidden when a subscription expires
<wgrant> In all other situations we do what the project owner asked.
<lifeless> StevenK: so - if the oops doesn't exist on eithe rserver, try wgrants heuristic if you have a view, try grepping for the view or its base r something on neem, and then close.
<lifeless> StevenK: diminishing returns after that, we're not doing a NASA.
<wallyworld_> wgrant: but we can leak info because the project owner would have rightful expectstion thast extending a subscription would make stuff proprietary again
<StevenK> lifeless: But if you want to destroy lp-oops and free up CPU time on carob, go ahead
<wgrant> wallyworld_: That's extremely debatable if they're previously explicitly set it to Public.
<wallyworld_> not to me
<wallyworld_> i would expect it
<wgrant> wallyworld_: The commercial subscription documentation has always made clear that it doesn't implicitly turn on privacy features
<wallyworld_> since it was only set to public to reset the forbidden
<wgrant> It just enables you to configure them
<wallyworld_> until they got to buy a new subscription
<wgrant> wallyworld_: If your stuff is proprietary and you set your policies to public, then you are really really stupid.
<wallyworld_> well, i argued the same thing last week
<wgrant> Huh?
<wgrant> No, last week you argued it was really really stupid and we could do whatever we wanted just because you ignored an expiry email
<wgrant> I argued that we couldn't
<wgrant> Now I'm arguing that we can respect Public if they project owner set Public.
<wgrant> There's no inconsistency in my position.
<wallyworld_> fsvo
<wallyworld_> it depends on project owner expectations
<wgrant> OK
<wgrant> Why would you set it to Public?
<wallyworld_> mine would be that buying a subscription makes stuff private
<wgrant> That's something that has never been true.
<wgrant> And we never state that
<wgrant> And it doesn't always make sense.
<wgrant> We make it clear that you need to configure your project's privacy options.
<wallyworld_> hmm. ok. if it's never been true, then i guess no need to change. but i find it strange we do it that way
<wgrant> Now, yes, it was pretty strange that the default for a new proprietary project was for everything to public.
<wgrant> And we fixed that default.
<wallyworld_> i see extending a subscription in the same light
<wgrant> I'm Product Strategy
<wgrant> I want to have proprietary bugs and branches on Unity so I can perform my nefarious freedom-hating deeds in secret
<wgrant> Now, the project is currently listed as GPL
 * ajmitch quotes out of context
<wgrant> But I need a commercial subscription, so I buy and activate it
<wgrant> Now all the random user bugs and branches are Proprietary because Launchpad changed something without asking me :(
<wallyworld_> no, that's exactly what i would expect
<wallyworld_> as the owner who bought the subscription
<wallyworld_> because i was the one who bought the subscription expecting to hsve private stuff
<wgrant> Expecting to have private stuff.
<wallyworld_> i guess you and i have different expectstions
<wgrant> Not expecting everything to be forced private despite me saying yesterday that it was public by default.
<wallyworld_> i would have only said that yesterday because i hadn't decided to buy a subscription yet
<wgrant> No
<wgrant> Unity wants "Public, can be proprietary" for bugs and branches
<wallyworld_> but once i make the decison to prchase, i want proproertary
<wallyworld_> and even if i didn't it's best to fail closed as you said last week
<wallyworld_> easy to make a few things public again than the other way round
<wgrant> If we're unilaterally making a change then we have to fail closed.
<wgrant> It's far better for everyone if we can avoid making a change at all
<wallyworld_> but buying a subscription is a change
<wgrant> In general, users will be less surprised if we do what they say
<wgrant> "buying commercial subscription" != "making project private"
<wallyworld_> yes, and to me, buying a subscription carries certain expectations
<wgrant> Then we need to fix the pages to make it clear that those expectations are false.
<StevenK> wallyworld_: So, you have a public product with public bugs and branches.
<wallyworld_> yes, i but now i want to buy a subscriotion
<StevenK> wallyworld_: You buy a subscription since you want to have some work be private until you're ready to release it.
<wallyworld_> yes
<StevenK> wallyworld_: So now all the current stuff is all private? Does not make sense.
<wallyworld_> no, not the existing stuff
<wallyworld_> new stuff
<StevenK> You don't want new stuff all private too
<wallyworld_> stuff i create *after* i buy the subscription
<StevenK> Just selected stuff
<StevenK> wallyworld_: Since not all new work is going to be on the private work
<wallyworld_> yes, but branches need to be proprietary by default
<wgrant> Buying a Launchpad commercial subscription means you get to use proprietary features.
<StevenK> No, they don't
<wgrant> That's all it does.
<StevenK> wallyworld_: So, you put up a bug fix branch for the released work. It should be public, why did LP create it as private?
<wallyworld_> better to do that than leak info
<wallyworld_> this would be easier using voice, let's discuss tomorrow
<StevenK> I agree with wgrant, fwiw
<wgrant> Sure
<wallyworld_> as a customer, i guess my expectations are different to yours
<StevenK> wallyworld_: Ask thumper what he would expect
<wgrant> thumper wrote branch privacy
<wgrant> He's probably not a good person to ask :)
<StevenK> Hahah
<StevenK> wgrant: So, IntegrityError: update or delete on table "milestone" violates foreign key constraint "bugtask__product__milestone__fk" on table "bugtask"
<StevenK> (From a test I wrote)
<wgrant> Great.
<StevenK> Now to find the user bit in search_bugs again
<wgrant> wallyworld_: We certainly need to rewrite the commercial views, emails and documentation to make clear that you probably want to visit +sharing
<wgrant> But I don't think making the change automatically is a good idea
<wgrant> And it's certainly not mandatory.
<wallyworld_> wgrant: but last week your argued that noone reads emails :-P
<wgrant> wallyworld_: My company's commercial subscription admin left the company a month after they activated the commercial subscription :(
<wgrant> So the expiration email that Launchpad sent to us 11 months later was gone
<StevenK> wallyworld_: As an aside, "Public, can be proprietary" means all new stuff should be private?
<wallyworld_> yeah, i know the argument. its the same for this new case too
<wallyworld_> StevenK: no
<wgrant> But the commercial subscription admin didn't leave 30 seconds after activating the subscription, so they were able to see that email, as well as the page confirming that the subscription was active.
<StevenK> wallyworld_: But that's what you said?
<StevenK> wallyworld_: You said you buy a subscription which allows you to set "Public, can be proprietary" and therefore since you'd bought a subscription all new stuff should be private
<wallyworld_> StevenK: no, i said the sharing policy should be changed from forbidden or public to proprietary when a commercial subscription is purchased or extended
<wgrant> There's a difference between failing open by a unilateral action from Launchpad 12 months after the other involved party interacted with us, and failing open because Launchpad respected a user's configuration and then hinted that they might want to verify it immediately after an action that could be misunderstood as automatically changing them.
<wallyworld_> sort of. human error and all that. fail open sometimes is still fail open
<wgrant> Sure
<wallyworld_> StevenK: does it make more sense now with the above clarification?
<StevenK> wallyworld_: No, but like you said, let's use voice tomorrow
<wallyworld_> ok
<StevenK> Failing that, I'm sure wgrant and I can fly to Brisbane to beat sense into you.
<wgrant> :)
<wallyworld_> i can see both sides of the coin
<wgrant> As can I
<wgrant> And your side has some good arguments
<wgrant> But I think it's less surprising if we do nothing and *say* that we've done nothing.
<wgrant> Anyway
<wgrant> => mumble tomorrow :)
<StevenK> wgrant: So, I should add ignore_privacy=False to BugTaskSearchParams
<StevenK> And then use that in _build_query
<wgrant> StevenK: Something like that
<StevenK> _deleteMilestone runs as the user so if we return bugtasks they can't see, they can't change them either. :-(
<StevenK> wgrant: I don't really want to add in rSP either
<wgrant> StevenK: It might have to
<wgrant> StevenK: Like package uploads closing bugs.
<StevenK> Yea
<StevenK> Pity
<StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/delete-milestone-all-bugs/+merge/125924
<wallyworld_> rsp :-(
<StevenK> wallyworld_: I have little choice
<wallyworld_> StevenK: too bad. i guess rsp is used elsewhere as well where it's unavoidable
<StevenK> wallyworld_: I don't like it, but if all references aren't scrubbed, we get an OOPS.
<wallyworld_> StevenK: are there likely to be many bugtasks in that loop? should we look to do a bulk delete instead?
<StevenK> We can't do a bulk delete
<StevenK> We aren't deleting them
<StevenK> Well, we are if they're conjoined
<wallyworld_> s/delete/update
<wgrant> Um
<wgrant> Hm
<wgrant> Deleting tasks like that
<wgrant> Ew
<wgrant> ew
<wgrant> ew
<wgrant> It's existing code
<wgrant> But ew
<StevenK> wgrant: The correct thing to say is 'Conjoined masters. Ew. Ew. Ew. Ew. Ew.'
<wgrant> I think that code's probably even wrong
<wgrant> How does that make sense?
<wgrant> If we do happen to want to delete the conjoined master, the slave is still going to have the milestone set, isn't it?
<StevenK> I tend to close my eyes and say "LALALALA" every time someone mentions conjoined bugs
<StevenK> wgrant: There is a test for the conjoined master case, but I don't know.
<StevenK> wgrant: And I don't get the SourcePackageRecipeRequestDailyBuildView object has no index bug -- I'm guessing we don't want to render it directly
<wgrant> StevenK: Presumably it's never meant to try to render the form, right.
<StevenK> Well, there is no form
<StevenK> On the action, we request a build and redirect away
<wgrant> Right.
<StevenK> Which I'm guessing it means it was POST'd to, so I should redirect to the recipe in initialize() if it's GET?
<wgrant> Or potentially remove the view and replace it with an API call
<wgrant> I'm not sure what the view does.
<StevenK> Haha
<wgrant> Hm?
<StevenK> It does AJAX stuff
<wgrant> I'm completely serious
<wgrant> If it doesn't do anything special, it can probably be an API call.
<StevenK> wgrant: There is some JS that POSTs to it directly
<wgrant> Clearly.
<wgrant> But why is it not an API call?
<StevenK> It gets the AJAX stuff back and uses it to update the page
<wgrant> Aha
<lifeless> don't we have an html representation thingy in the API ?
<lifeless> its terrible but it exsists
<wgrant> We do
<wgrant> I'm not sure it's immensely useful here
<wgrant> It probably wants to get the entire build table back
<lifeless> hmm
<lifeless> if only we had some sort of client side template system
<wgrant> Indeed!
<StevenK> requestDailyBuild also may raise two exceptions which the view catches and turns into notifications
<lifeless> StevenK: so whats the simplest thing you can do here ?
<StevenK> lifeless: Add an initialize() method and redirect, like I've done
<lifeless> StevenK: cool
<StevenK> wallyworld_, wgrant: https://code.launchpad.net/~stevenk/launchpad/no-render-sprrdb/+merge/125930
<lifeless> StevenK: btw, multiple tasks referencing one milestone is a model violation
<lifeless> StevenK: it only happens because we haven't done onlyseriestasks yet, *and* we don't do non-series milestones.
<lifeless> so s/is a model/should be a model/ really
<StevenK> lifeless: You have yet to convince people about onlyseriestasks :-)
<StevenK> wallyworld_: You have even more QA!
 * StevenK upgrades DF, since that will take a few eons
<StevenK> I wonder if qas will have updated and the deployment report updated before DF finishes
<wallyworld_> yes, indeed
<wallyworld_> not used to it being so soon
<StevenK> Hahahaha
<StevenK> steven@undermined:~/ubuntu% dput dogfood:~stevenk/ppa/ubuntu xserver-xorg-video-ati_6.13.2-1ubuntu3_source.changes
<StevenK> Invalid Files line in .changes:
<StevenK>   5266cb3d554ecf973e03af8003e24932 2838 x11, foobar optional xserver-xorg-video-ati_6.13.2-1ubuntu3.dsc
<wallyworld_> StevenK: and i can just use the project i set up this morning to qa a different bug and which caused me to file and fix this one i'm doing now
<wallyworld_> mid you, i did lp-land
<wallyworld_> mind
<wallyworld_> we do need to put ec2 on steroids
<StevenK> wallyworld_: Go on, then. I'll wait here. :-P
<wallyworld_> there's a few options isn't there. but we really should pick one and get it done i guess
<wallyworld_> i like whatever has no more ec2 bills each month
<StevenK> Jenkins with parameterized builds, then
<wallyworld_> yes!
<StevenK> wallyworld_: Then shake lifeless until that falls out
<wallyworld_> i think if we all beat him up that will help
<StevenK> There, my QA is done too
<wgrant> What is this madness?
<wgrant> Bug #1055250
<wgrant> qa-ok
<_mup_> Bug #1055250: Bug sharing policy weirdness on +sharing page <disclosure> <qa-ok> <sharing> <ui> <Launchpad itself:Fix Committed by wallyworld> < https://launchpad.net/bugs/1055250 >
<wgrant>  Reported by Ian Booth 5 hours ago
<StevenK> Haha
<wallyworld_> i cheated though
<wallyworld_> i skipped ec2
<StevenK> wallyworld_, wgrant: Can I have a review now? https://code.launchpad.net/~stevenk/launchpad/no-render-sprrdb/+merge/125930
<wallyworld_> sure
<wallyworld_> StevenK: when do we hit that view via a get?
<StevenK> wallyworld_: When people URL hack
<wallyworld_> ah, ok
<StevenK> It turns up every now and again
<wallyworld_> r=me
<wallyworld_> sigh. i just ran > 3000 [B|b]ug tests with an AssertionError inserted into some code and the only failure was an artificially constructed doc test.
<wgrant> We have some assertions commented out in Soyuz because lots of tests fall afoul of them
<wallyworld_> back to the drawing board, may need to use a soft oops to find it in prod
<wgrant> What are you asserting?
<wgrant> We may be able to neuter the test :)
<wallyworld_> i put in the assertion to try and find the cause of the issue
<wallyworld_> that the subject of a bug notification contains [Bug 123] and nothing else
<_mup_> Bug #123: There's no direct way to see the project info when translating it <lp-translations> <Launchpad itself:Fix Released> < https://launchpad.net/bugs/123 >
<wallyworld_> to fix bug 138775
<_mup_> Bug #138775: Notification subject included bug number but no summary for 'subscriber of duplicate' bug notifications <email> <lp-bugs> <regression> <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/138775 >
<wgrant> I mostly see that with imported comments
<wallyworld_> poking around the code doesn't seem to show how we are invoking the notification calls with no subject set
<wallyworld_> i'll revisit tomorrow, gotta do a few things now
<wgrant> Ahh
<wgrant> So
<wgrant> I think there's two bugs there
<wgrant> The comments this year refer to something different
<wgrant> The original one is probably long gone.
<wgrant> Oh
<wgrant> Except it's not
<wgrant> blah
<wgrant> Oh no
<wgrant> It is all the same issue
<wgrant> czajkowski's screenshot is of an email from an imported comment
<wgrant> It just happens to also be through a dupe subscription
<wallyworld_> ok, so imported comments may be directly related
<wgrant> That's the only case we have any recent evidence of
<wallyworld_> i'd love to find a test which causes the issue, will try looking for imported comment tests
<wgrant> wallyworld_:
<wgrant>         return getUtility(IMessageSet).fromText(
<wgrant>             owner=poster, subject='', content=comment['text'],
<wgrant>             datecreated=comment['time'].replace(tzinfo=pytz.timezone('UTC')))
<wgrant> In lib/lp/bugs/externalbugtracker/bugzilla.py
<wallyworld_> ok, so if that's the case, then perhaps there's not much we can do
<wallyworld_> perhaps the bug is now invalid
<wgrant> I don't believe the original bug exists
<wgrant> any more
<wgrant> The 2012 stuff is separate
<wgrant> External comments are imported with an empty subject
<wallyworld_> great, i'll mark the bug as such
<adeuring> good morning
<wgrant> :(
<wgrant> buildbot failure
<wgrant> Ah, that one
<wgrant> FAILURE: lp.buildmaster.tests.test_builder.TestSlave.test_status_after_build
<stub1> Spurious test failure with ec2 from frinday: lp.registry.tests.test_product.TestProduct.test_pillar_category
<wgrant> stub1: Have you looked at the error message?
<wgrant> IIRC that's the one I deliberately broke
<wgrant> But the error should be obvious if it is
<stub1> Obvious errors are common in test suites :)
<wgrant> It was "raise Exception('Nothing to see here.')" or so
<stub1> yeah
<wgrant> Yeah, that's fixed now
<wgrant> Was just testing that the new buildbots picked up failures.
<wgrant> stub1: Do you intend to deploy the new pgbouncer during an fdt window soonish?
<stub1> wgrant: Yes
<wgrant> Great.
* benji___ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: benji | Firefighting: - | Critical bugs: â
<adeuring> benji: could you please review this MP: https://code.launchpad.net/~adeuring/launchpad/sharingjob-remove-bp-subscriptions/+merge/126008 ?
<cr3> hi folks, is there a reason why Launcphad builders use ascii encoding? I thought the default encoding for Ubuntu, for all languages, was utf-8 but I could be wrong
<benji> adeuring: sure
<adeuring> benji: thanks. Just noticed that there are merge conflicts..
<rick_h_> adeuring: yea, you hit the moving of InformationType and such to lp.app.enums
<benji> adeuring: I'm done reviewing https://code.launchpad.net/~adeuring/launchpad/sharingjob-remove-bp-subscriptions/+merge/126008
<adeuring> benji: thanks!
<rick_h_> benji: for your reading pleasure if you get time https://code.launchpad.net/~rharding/launchpad/regjs/+merge/125780
<benji> rick_h_: I am warming up the new browser tab factory as we speak.
<rick_h_> benji: ty much, appreciate it
<rick_h_> benji: ignore the small yui 3.5.1 one. I'll self review that once we get the productino changes into place. Just holding off until then before moving it forward
<benji> k
<rick_h_> benji: so yea, that large html swatch was pulled from production. It's generated by the server side Widget stuff and it seemed best just to copy/drop it into place to dupliacte things.
<rick_h_> load the page, find the element, "copy as html" from the debug tools. I can note taht in the test .html file as the location for future use?
<benji> rick_h_: at a minimum we should include a comment stating why it is there, hints in the tests that failures might mean that the copied HTML needs to be updated, and detailed instructions on how to update it
<benji> or we can decouple the tests from the HTML (being more unit-y, I would guess)
<rick_h_> benji: ok, I'll doc it up. It just takes a lot to bootstrap the choice widget html and such so I cheated as I didn't think of a good way to generate it manually
<rick_h_> benji: no, you're right. Part of this came from debugging was hard. the choicewidget doesn't just update the radio button so I needed a full ChoiceSource instance to test against
<rick_h_> I'll look at what I can lose/redo there
<tumbleweed> benji: can I prod you to look at https://code.launchpad.net/~stefanor/launchpad/edit-packagesets/+merge/124555 ?
<benji> tumbleweed: sure
<rick_h_> let's put this fancy new buildbot to work! bwuhahaha
<czajkowski> hehe
<czajkowski> rick_h_: it sounds evil when you say it
 * rick_h_ is feeling very evil genius atm
<rick_h_> benji: ping, I cleaned up the sample html. I still need it because I do some ancestor checking and the license is double nested so I want to test that
<rick_h_> benji: but I removed all but a single option value from each level so that it's a lot less/cleaned up with a comment up top
<benji> cool, I'll taake a look in a minute
<rick_h_> benji: ty
<rick_h_> die buildbot die...that is all
<rick_h_> ok, that is cool I can break and unbreak buildbot over lunch
<benji> rick_h_: I'm afraid I'm being difficult re. https://code.launchpad.net/~rharding/launchpad/regjs/+merge/125780 (I wrote the last comment a while ago but forgot to ping you)
<rick_h_> benji: yea saw it. I understand. I got sidetracked trying to unbork buildbot
<rick_h_> benji: so I'll go back and copy and paste, but yea part of the test is to make sure we manipulate the dom correctly so really just no good way to make sure of that without having it in place there
<rick_h_> where we're missing that live state of automated testing against a live running web page
<benji> rick_h_: yeah, we're in an odd place there; I think you've struck just about the best balance we can at the moment
<cr3> hi folks, is there a reason why Launcphad builders use ascii encoding? I thought the default encoding for Ubuntu, for all languages, was utf-8 but I could be wrong
<tumbleweed> only in in a UTF-8 locale
<cr3> tumbleweed: not sure I I understand :)
<tumbleweed> cr3: the problem you are running into is that the default locale is C, which pre-dates UTF-8. There is a C.UTF-8 locale if you want things to assume UTF-8
<cr3> tumbleweed: isn't the default locale on ubuntu something like en_US.UTF-8? the C locale is ancient, I'm just not sure how it's representative of any installation of ubuntu I've encountered so far
<tumbleweed> cr3: no. Although it would be in a desktop environment
<cr3> tumbleweed: hm, ubuntu server looks like en_US by default which is probably not UTF-8. that would answer my question, thanks!
<tumbleweed> cr3: and builds happen in minimal chroots, with no locale specified
<lifeless> morning
<cr3> tumbleweed: the reason I ask is that it's annoying to have unit tests pass when run locally but fail when run during the build process. do you happen to know if it's common when unit testing to clear the environment?
<tumbleweed> cr3: it's a common issue to run into when running unit tests during builds
<cr3> tumbleweed: I wonder if it's actually a good indication to improve my test runner though
<cr3> I had a quick look at the launchpad bin/test script and it only does some changes to the environment like os.environ['TZ'] = 'Asia/Calcutta', but I wonder if test runners should be wrecking more havok in the environment to avoid some assumptions
<tumbleweed> benji: thanks
<benji> my pleasure
<tumbleweed> should I prod anyone for a DB review?
<benji> you can request a DB review on the MP
<tumbleweed> what do I need to do to do that?
<sinzui> benji, do you have time to review https://code.launchpad.net/~sinzui/launchpad/pageids/+merge/126081
<cjwatson> cr3: yes, you ought to improve your test runner here.  The default locale in the absence of indications to the contrary in the environment is C
<cjwatson> cr3: depending on the test runner, you might either want to run everything with locale bits cleared from the environment, or you might want to run the tests multiple times in different locales, or you might want to run everything forcing a UTF-8 locale (and in that case C.UTF-8 should be suitable on modern releases)
<cr3> cjwatson: agreed, at first it looked like the builders were annoying but making assumptions on a sane environment is ironically insane
<cr3> cjwatson: have you ever seen a test runner actually clear all the environment? I've been looking around, mostly at python projects providing a ./test script, and this doesn't seem to be common
<cjwatson> Even Ubuntu server is probably UTF-8 by default in general, but there are many contexts where you can end up starting something with a minimal environment
<cjwatson> cr3: *shrug* not an expert on test runners
<cr3> cjwatson: I checked a fresh install of ubuntu and the LANG was set to en_US, but that might be because of my preseed
<cr3> s/ubuntu/ubuntu server/
<cjwatson> that's not the default
<cr3> cjwatson: hm, thanks for the heads up, I should look into fixing that
<cjwatson> we certainly don't use legacy ISO-8859-1 locales by default anywhere
<cjwatson> cr3: sbuild will build your package in a cleaned environment
<cjwatson> I'm fairly sure it clears the locale
<lifeless> sinzui: lp:~sinzui/launchpad/pageids
<sinzui> yes
<lifeless> sinzui: I think you may have misunderstood the issue; the PPR handles spaces AFAIK
<lifeless> sinzui: its having the revisionid in the pageid thats a problem
<sinzui> oh,
<lifeless> sinzui: because it means we cannot aggregate times across deploys.
<sinzui> well I fixed that accidentally
<lifeless> great.
<cjwatson> cr3: also note that, if you were sshing in, our ssh forwards the locale by default
<cr3> cjwatson: fyi, I use the example preseed from the installation-guide-i386 as reference and my template is even very friendly to diff against it, that's where I got the default value for en_US
<cr3> cjwatson: I use that package to keep my preseed up to date with latest developments
<cjwatson> Mm, probably ought to fix that, although I had a feeling that it was supposed to turn it into the nearest UTF-8 form automatically
<cjwatson> Anyway, OT for this channel, feel free to file bugs :)
<lifeless> flacoste: hi ?
<cr3> cjwatson: will do
<benji> sinzui: sure
<flacoste> hi lifeless
<sinzui> jcsackett, do you have time to talk?
<sinzui> benji, thank you for the corrections
<benji> my pleasure
<jcsackett> sinzui: sure.
<sinzui> jcsackett, hangout?
<jcsackett> sinzui: started.
<rick_h__> hey all, I've got biuldbot broken atm, just pushed a fix (hopefully) and going to be afk for 20min while it runs. I'll be back in when it finishes to hopefully drive this through.
<rick_h__> general heads up, I emailed a reply to the buidlbot message as well
<lifeless> rick_h__: thanks
<mwhudson> \o/ for parallel testing
<jelmer> \o/ indeed
* benji changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugs: â
<mwhudson> huh
<mwhudson> make in the launchpad root (which i haven't done in a loooong time, to be fair) failed like this:
<mwhudson>     ImportError: /home/mwhudson/canonical/repos/launchpad/devel/lib/gettextpo.so: wrong ELF class: ELFCLASS32
<mwhudson> that's ... more exciting than i expected?
<cjwatson> Sounds like you last built it in a 32-bit environment, and make doesn't notice that it needs to rebuild them because as far as it's concerned all the timestamps are up to date.
<mwhudson> yeah, but that seems pretty unlikely in itself
<mwhudson> anyway, make clean && make worked
<lifeless> mwhudson: lxc bind mount vs direct access?
<mwhudson> lifeless: ah yes, that's probably it
<rick_h__> bah, missed a handful of tests. This might still fail
<rick_h__> ok, so down to one failing. It was one of the handfull my regex missed so updated and send back to buidbot
<rick_h__> <3 the rocking parallel tests
<wgrant> wallyworld_: Were you going to comment on bug #138775?
<_mup_> Bug #138775: Notification subject included bug number but no summary for 'subscriber of duplicate' bug notifications <email> <lp-bugs> <regression> <story-better-bug-notification> <Launchpad itself:Triaged> < https://launchpad.net/bugs/138775 >
<wgrant> And ideally close it
<wallyworld_> wgrant: yes, getting to it
<wgrant> Great, just checking it hadn't dropped off your radar
<wallyworld_> nope
<cjwatson> We have a stupidly near deadline for getting signed kernels sorted out in Ubuntu, which requires https://code.launchpad.net/~cjwatson/launchpad/uefi-copy-no-auto-approve/+merge/126128 or something like it - if anyone has time to review that I'd appreciate it
<cjwatson> (I know, my lack of planning isn't your emergency)
<cjwatson> (Also the branch name is a bit crap, it reflects the first half of the change)
<wgrant> Looking
<wgrant> I was just about to ask about that, yeah
<cjwatson> I only remembered about it after I'd already committed so the later stuff had the existing branch nick all over the metadata
<lifeless> wgrant: that bug on legacy mirroring - have we deleted the code?
<wgrant> cjwatson: archiveuploader's CustomUploadFile.autoApprove doesn't autoapprove PPA uploads, does it?
<lifeless> wgrant: if so, I don't think it should be FR, but perhaps dropped to High. The point was to migrate all the branches behind the scenes.
<wgrant> lifeless: No, I think there's another bug for that
<cjwatson> wgrant: It doesn't, but there's a higher-level method that does
<wgrant> lifeless: No, the point was that legacy mirroring was broken
<wgrant> Legacy mirroring is no longer broken, so that bug is fixed :)
<cjwatson> wgrant: BuildDaemonUploadPolicy.autoApprove
<wgrant> Ah, right
<cjwatson> (Should I tweak the comment?)
<wgrant> That would be lovely
<lifeless> wgrant: the question was about it being broken
<lifeless> wgrant: the bug was about it being something folk have to reconfigure to get to
<cjwatson> Done
<wgrant> [Bug 1051097] Re: legacy bzr mirroring broken
<_mup_> Bug #1051097: legacy bzr mirroring broken <code-import> <regression> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/1051097 >
<wgrant> lifeless: Bug #872312
<_mup_> Bug #872312: kill BranchType.MIRRORED <code-import> <lp-code> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/872312 >
<lifeless> ok
<wgrant> cjwatson: Wow, getTargetArchive was a bit odd
<cjwatson> Wasn't it
<cjwatson> "Why doesn't this work ... oh"
<wgrant> cjwatson: Did you check history to confirm there wasn't a reason for it?
<cjwatson> CustomUploadCopier was rather obviously single-goal-oriented to start with; I've been gradually generalising it
<wgrant> i can't see one, but you never know..
<wgrant> Ah
<cjwatson> I didn't explicitly do so, but let me have a quick dig
<cjwatson> Well, it dates right back to the original fix for bug 659769, when that file was added
<_mup_> Bug #659769: should copy custom uploads to newly-initialised release <derivation> <lp-soyuz> <new-release-cycle-process> <qa-ok> <soyuz-publish> <Launchpad itself:Fix Released by jtv> < https://launchpad.net/bugs/659769 >
#launchpad-dev 2012-09-25
 * cjwatson looks at the whole of r13734
<cjwatson> In that revision, it had one caller, which was always copying from series.previous_series to series
<cjwatson> I'm right in my presumption that series.previous_series is always in the same distribution, aren't I?
<wgrant> Right
<wgrant> Yes
<lifeless> well
<lifeless> we hope so
<cjwatson> I did check it was true for Ubuntu
<wgrant> The code ensures it's always true
<wgrant> The DB does not
<cjwatson> So I think this was essentially an attempt at generalising to derived distributions
<cjwatson> But that actually what we have now in PackageCopier does a better job
<cjwatson> And the publisher code doesn't care
<wgrant> Yep
<wgrant> r=me
<wgrant> We really need to merge the uploader and copier eventually...
<cjwatson> Yeah, it's a pretty ugly separation
<cjwatson> They're kind of converging by iterative generalisation
<wgrant> And it's only getting uglier
<wgrant> Yeah
<cjwatson> But stuff like that duplicated policy code is really hard to fix in the current layout
<wgrant> And there are subtle differences.
<wgrant> Largely unavoidable in the current layout, as you say
<cjwatson> Different ancestry calculation between them
<cjwatson> And within the uploader, come to that, but that's a different matter
<wgrant> Yes...
<cjwatson> cf. my comment in check_copy_permissions :-)
<wgrant> really we want to rework PackageUpload+PackageCopyJob to work with just a "bunch of packages"
<wgrant> Then copies and uploads can use the same infrastructure, just from different sources
<wgrant> That would also probably necessitate making custom uploads not horrible
<wgrant> Or at least less horrible
<cjwatson> They could do with having something that resembles a database representation
<wgrant> Myes.
<cjwatson> Rather than just being bolted onto the side of PackageUpload and forgotten about
<lifeless> cjwatson: long tradition of that :)
<lifeless> cjwatson: when schema changes were impracticle
<cjwatson> Mm
<cjwatson> At least we don't have sourceless custom uploads any more :)
<wgrant> Indeed
<cjwatson> Right, thanks, I've sent that off to EC2.  I'll QA in the morning if it's got that far
<wgrant> " 1 â 75 of 296 results "
<wgrant> !
<wgrant> cjwatson: Great
<StevenK> wgrant: Criticals?
<wgrant> StevenK: Yeah
<wgrant> In launchpad, though, not launchpad-project.
<StevenK> Yeah
<StevenK> wgrant: Right, I can see the 35 BMPs
<StevenK> Well, my query doesn't return the BMP ids, it returns the duplicated merge_diffs, but the 35 is the important bit.
<wgrant> Is it actually 35?
<wgrant> Right
<StevenK> SELECT merge_diff FROM branchmergeproposal WHERE merge_diff IS NOT NULL GROUP BY merge_diff HAVING COUNT(*) > 1;
<wgrant> Right, exactly.
<StevenK> Incredibly simple
<StevenK> wgrant: So I'm not sure what we should do, though
<wgrant> StevenK: Delete 35 MP diffs :)
<StevenK> wgrant: How will that help? There are two BMPs with the same merge_diff
<wgrant> Um, yeah, maybe I'm misremembering
<wgrant> Do we have a bug about this?
<StevenK> I do not think so
<StevenK> But I haven't gone diffing
<StevenK> Er, nice slip. digging
<wgrant> Ah
<wgrant> So I guess we want to duplicate the previewdiffs
<StevenK> How do we do that in 2.5 seconds? :-)
<wgrant> There's only 35 records...
<StevenK> wgrant: Sure, but I'm not sure how to pull out only one BMP, duplicate its previewdiff and then set it back.
<wgrant> StevenK: We'd probably want to duplicate the LibraryFileAlias, Diff, and PreviewDiff, then set BranchMergeProposal.merge_diff
<StevenK> LFA is involved?
<StevenK> wgrant: I can't see how LFA is involved
<wgrant> StevenK: diff.diff_text is an LFA
<StevenK> Ah
<wgrant> No two previewdiffs reference one diff, and no two diffs reference one LFA
<StevenK> wgrant: I'm just not sure how to duplicate rows, making sure that FKs are sane and then setting BMP.merge_diff
<cjwatson> Isn't bug 497772 released now?  That was apparently in launchpad-buildd 112, and top-of-changelog is 114
<_mup_> Bug #497772: exceptions.AttributeError: 'DebianBuildManager' object has no attribute '_subprocess' <oops> <launchpad-buildd:Fix Committed by jelmer> < https://launchpad.net/bugs/497772 >
<wgrant> StevenK: I'd probably write a query to find a temp table of the newer BMP of each of the 35 pairs, then execute a PL/pgSQL function to duplicate the three rows and switch the FK
<StevenK> cjwatson: Ah, but what launchpad-buildd is deployed on the builders ...
<wgrant> 114
<wgrant> So yeah, that can be closed
<cjwatson> launchpad-buildd | 113~0.IS.08.04 | hardy-cat-buildd | source, all
<cjwatson> launchpad-buildd | 113~0.IS.08.04 | lucid-cat-buildd | source, all
<cjwatson> But either way ...
<wgrant> Buildd toolchain package versions: launchpad-buildd_114-0~53~0.IS.08.04 python-lpbuildd_114-0~53~0.IS.08.04 bzr_2.5.1-0ubuntu2.
<cjwatson> Ah, good
<wgrant> Mysterious
<cjwatson> launchpad-buildd | 114-0~53~0.IS.08.04 | hardy-cat-proposed | source, all
<wgrant> Ah
<wgrant> Where did you get a cat madison?
<cjwatson> chinstrap:~cjwatson/madison-lite-cat/
<cjwatson> madison-lite --config=config there
<wgrant> Ahh, thanks
<cjwatson> And I run ./make-local-mirror occasionally to refresh the local Packages/Sources
<cjwatson> Actually in fact that's cronned houry
<cjwatson> *hourly
<cjwatson> It is a foul hack but it works
<cjwatson> Is there any way to get the OOPSen in bug 809937?  Neither lp-oops.c.c nor oops.c.c seems to have them any more
<_mup_> Bug #809937: Timeout accepting packages  <queue-page> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/809937 >
<cjwatson> I suspect that's a dup of bug 745799, but it would be nice to be able to check
<_mup_> Bug #745799: DistroSeries:+queue Timeout accepting packages (bug structural subscriptions) <qa-ok> <timeout> <Launchpad itself:In Progress by cjwatson> < https://launchpad.net/bugs/745799 >
<wgrant> It's probably a dupe
<wgrant> We'll know for sure when the +queue POST oopses never appear again :)
<StevenK> wgrant: So my plan based on your plan is a function that we call once per previewdiff, I'm clear on how to duplicate the data using INSERT INTO, but how do get back the id so I can keep FKs sane?
<wgrant> But it may be worth duping that
<wgrant> StevenK: INSERT INTO foo (bar, baz) VALUES (what, ever) RETURNING id INTO some_var;
<wgrant> RETURNING is normal PostgreSQL; it's how we get the IDs back in Storm
<wgrant> INTO is PL/pgSQL
<StevenK> wgrant: UPDATE branchmergeproposal SET ... WHERE merge_diff = pd_id LIMIT 1;  doesn't make sense, right?
<wgrant> StevenK: Indeed not
<wgrant> StevenK: The function will presumably be called with a BMP ID
<StevenK> wgrant: I've written it for a previewdiff id
<StevenK> It even works
<StevenK> Let me pastebin it up so you can insult me.
<StevenK> :-P
<StevenK> wgrant: http://pastebin.ubuntu.com/1225731/
<wgrant> StevenK: Right, easy solution is to use the MP ID instead
<wgrant> Then grab the merge_diff from that
<StevenK> wgrant: It works this way? :-)
<wgrant> Oh, I see you do the SELECT first, right
<wgrant> Is that quick enough on DF?
<wgrant> If not, just move the SELECT merge_diff bit to before the statement timeout
<StevenK> So I've tested one run, I'm just about to try it with -f and a ROLLBACK
<wgrant> Right
<StevenK> Hah, my end SELECT line is wrong
<StevenK> wgrant: It times out. :-(
<wgrant> Right, so swap lines 6 and 8
<StevenK> wgrant: It times out at INSERT INTO libraryfilealias
<StevenK> It already printed SELECT 35
<wgrant> Have you explained the INSERT INTO?
<StevenK> wgrant: Just about to.
<StevenK> wgrant: 3ms
<wgrant> Perhaps just a cold cache? Run again?
<StevenK> Oooh
<StevenK> It prints duplicate_preview_diff, 35 blank rows and then (35 rows), can make it uh, not do that?
<StevenK> Into a pager, which results having to hit q
<StevenK> wgrant: ^
<wgrant> Not sure
<wgrant> But it's because the function is returning null
<StevenK> wgrant: Actually, I think the SELECT duplicate_preview_diff(merge_diff) ... is doing it
<wgrant> Exactly.
<wgrant> You asked it to return the result of that function
<wgrant> Which is NULL
<wgrant> for each row
<StevenK> Ah
<wgrant> so 35 times
<StevenK> But it's declared as RETURNS void ?
<wgrant> Which means it returns null
<lifeless> out for a short while
<wgrant> It just can't return anything itself; it always evaluates to null
<StevenK> wgrant: So what do I instead?
<wgrant> StevenK: Ignore it, probably
<wgrant> I'm sure ops can press q
<StevenK> lifeless: I'd like to chat about some SQL I'd like to run on prod when you're back.
 * bigjools owes wallyworld_ alcohol for adding the commit msg to MP emails
<bigjools> or caffeine, pick your drug of choice
 * wallyworld_ likes Southern Comfort
<wallyworld_> i assume it worked to your satisfaction then
<StevenK> Is that a euphemism for wgrant?
<wallyworld_> oooooh
<bigjools> haha
<wgrant> StevenK: https://oops.canonical.com/oops.py/?oopsid=OOPS-4845cff98595cfa456992a710aaff661 is a bit odd
<wgrant> I suspect it's a regression from your stuff
<StevenK> Blink
<StevenK> Oh, we switched to SRF
<wgrant> Ah
<wgrant> Yeah
<wgrant> And when given a name, I bet it uses BPBSet instead of BFJSet
<wgrant> And the former is probably SQLObject
<wgrant> Yeah
<lifeless> StevenK: hi
<StevenK> lifeless: O HAI. The SQL in question is https://pastebin.canonical.com/75216/
<lifeless> sudo execute me some sql ?
<StevenK> lifeless: The background is that when wgrant and I were migrating staticdiff to previewdiff we didn't check for and discard duplicates, so now we have 35 previewdiffs that are referenced by more than one branchmergeproposal
<lifeless> StevenK: I see
<lifeless> StevenK: you have  afunction in there; how have you validated it ?
<StevenK> lifeless: I ran it on DF
<lifeless> StevenK: so if it did the wrong thing, we have no idea ? :)
<lifeless> let me give it some eyeballing
<lifeless> ok, I **think** it will be ok
<StevenK> Right, it is just duplicating the data and then picking one of the BMPs as a victim
<StevenK> And we have 2 previewdiffs that are lucky and linked from 3 BMPs
<StevenK> So we'll have to run it twice
<StevenK> lifeless: If you'd prefer, I'm happy to perform some validation on DF after lunch?
<lifeless> that would give me some comfort yes
<lifeless> its just a little too large to visually confirm
<bigjools> we need a "pebkac" bug status
<lifeless> StevenK: like, check it really only updates one of them, not both sides
<stub> lifeless: it does, because the final update will fail because the id column is unique and it matches with the = operator.
<StevenK> lifeless: http://pastebin.ubuntu.com/1225881/
<stub> StevenK: Want me to run it?
<StevenK> stub: I was happy enough to go through webops, but please do.
<StevenK> stub: You'll need to run it twice -- two lucky previewdiffs are linked to 3 BMPs
<stub> StevenK: Done. 35 rows fixed, then 2 in the second run
<StevenK> stub: Fantastic, thanks.
<wgrant> StevenK, stub: Thanks
<wgrant> The broken MPs are no longer broken.
<StevenK> It should makes the OOPS report a bit happier too
<wgrant> StevenK: Were you going to look at the Builder:+history regression, or should I fix it?
<StevenK> wgrant: Can you remind me of that Builder:+history regression and your thoughts on it?
<wgrant> StevenK: The OOPS I pointed out this morning. If you look at Builder.getBuildRecords, you'll see it uses a different method if a name filter is specified.
<wgrant> BinaryPackageBuildSet.getBuildsForBuilder returns an SQLObjectResultSet, which SRF chokes on
<wgrant> So we just need to Stormify BinaryPackageBuildSet.getBuildsForBuilder
<wgrant> Probably about 5 minutes of work :)
<wgrant> Plus DEATH TO SQLOBJCT
<wgrant> +E
<StevenK> wgrant: No point for a test, just make it Stormier?
<wgrant> I think so.
<StevenK> wgrant: Did you see buildbot is still full of hate and not love?
<wgrant> Although a test could be done in about 4 lines.
<wgrant> StevenK: A second spurious rabbitmq failure? Yeah
<wgrant> A bit odd
<wgrant> But we'll see if it happens again
<StevenK> wgrant: It's a bit more than 5 minutes.
<StevenK> BinaryPackageBuildSet.handleOptionalParamsForBuildQueries() is disgusting
<wgrant> Oh, I missed that call
<wgrant> But it's not that bad
<wgrant> The only issue is that you probably have to port the rest as well
<StevenK> Yes
<wgrant> That's only two other methods, luckily
<StevenK> Didn't we write a Storm archive privacy method?
 * StevenK tries to remember
<lifeless> wgrant: a little more context when downgrading importance would be lovely
<lifeless> wgrant: it would avoid questions like 'why isn't it critical', which I might otherwise ask
<wgrant> lifeless: The only questionable things I've downgraded are the crashes in ec2 demo
<wgrant> AFAICR
<lifeless> yah
<lifeless> just a -little- context, is all I'm asking for
<wgrant> I decided that nobody cares about ec2 demo apart from jml, and it's never been reliable, so it's probably not worth a critical
<wgrant> Or two
<lifeless> sure
<lifeless> but all folk like me see
<lifeless> is 'critical->high'
<lifeless> with no more info at all
<wgrant> True
<lifeless> not even the fact its ec2 demo vs ec2 land
<lifeless> so just saying 'ec2 demo is a best effort subproject - not treating as critical' would be more than enough
<wgrant> [Bug 993300] Re: Error in apache config during ec2 demo
<_mup_> Bug #993300: Error in apache config during ec2 demo <ec2> <Launchpad Developer Utilities:Triaged> < https://launchpad.net/bugs/993300 >
<wgrant> It says "demo"
<wgrant> but k
<StevenK> wgrant: Holy crap, I think I win
<wgrant> StevenK: What have you broken?
<StevenK> wgrant: 3 files changed, 74 insertions(+), 91 deletions(-)
<StevenK> It almost works
<wgrant> :( +74
<lifeless> -91
<wgrant> Sure
<wgrant> But normally if I frown at him he gets it even more negative
<StevenK> It only works sometimes.
 * StevenK tries to work out where builder fits in
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/stormier-getbuildsforbuilder/+merge/126159
<wgrant> StevenK: Looking
<StevenK> wgrant: So, I was happy to move that into get_archive_privacy_filter, but BFJ's usage of it wants Or(PackageBuild.id == None, <archive privacy stuff>)
<wgrant> StevenK: Does it want it?
<wgrant> or is it a bug?
<StevenK> I don't think it is
<wgrant> Why does BFJ's usage of it want that?
<wgrant> Oh, I misread
<wgrant> Surely BFJ also wants the admin/anon special cases?
<StevenK> It has it!
<wgrant> StevenK: And how does it differ?
<StevenK> clauses.append(Or(PackageBuild.id == None, Not(Archive._private)))
<StevenK> That's the user is None case for BFJ
<StevenK> clauses.append(Not(Archive._private))
<StevenK> And the one I added in the branch
<wgrant> OK, I'm confused
<wgrant> "I was happy to move that into get_archive_privacy_filter"
<wgrant> What is "that"?
<StevenK> I could hack around it by doing if clause: return Or(clause, filter) else return filter
<wgrant> StevenK: BuildFarmJobSet.getBuildsForBuilder does the same thing, except in the admin case
<wgrant> And get_archive_privacy_filter should return True for an admin
<wgrant> So the admin case will be Or(PackageBuild.id == None, True)
<wgrant> Which should perform fine
<StevenK> wgrant: http://pastebin.ubuntu.com/1226047/
<StevenK> It doesn't fix the LIKE bit yet
<StevenK> Or my indentation sins
<StevenK> wgrant: origin = [PackageBuild] is because it's always used whereas the old code pulled it in later
<wgrant> k
<StevenK> Hmm, why is where wrapped in brackets with no comma or line wrap
<wgrant> StevenK: I'm not sure it's worth having that clause arg
<StevenK> wgrant: You'd rather toss Or(PackageBuild.id == None, ...) into BinaryPackageBuild's callsite too?
<StevenK> Even though it wasn't there before
<wgrant> StevenK: SOmetimes people (eg. me, sometimes) wrap 'where=Foo.bar == baz' in parens
<wgrant> To make it less ambiguous
<StevenK> Fair enough
<wgrant> 'cause it really looks like the = should bind tighter there
<wgrant> But it doesn't
<StevenK> Trying to work how you'd prefer the filter = [ block to be indented
<wgrant> Which?
<wgrant> In get_archive_privacy_filter?
<StevenK> Yeah
<wgrant> The second element of the list is indented further than the first
<StevenK> Oh, duh
<wgrant> Which doesn't make much sense
<wgrant> Yeah
<wgrant> StevenK: So, back to PackageBuild.id == None: no, I would include PackageBuild.id == None in BFJS as we do today
<StevenK> wgrant: So, PackageBuild.id == None into BinaryPackageBuild's callsite?
<wgrant> So it becomes Or(PackageBuild.id == None, get_archive_privacy_filter(user))
<StevenK> *get_archive_pri ...
<StevenK> :-)
<wgrant> Not if it returns an Or, no
<StevenK> It wasn't
<wgrant> It wasn't, no
<wgrant> But it should
<StevenK> Or() doesn't make sense for the BPB case
<wgrant> It should return Not(Archive._private), or True, or Or(Not(Archive._private), Archive.ownerID.blah)
<wgrant> I think
<wgrant> Why not?
<StevenK> Oh, hmm
<StevenK> wgrant: Wait, what about Or(PackageBuild.id == None, Or(...)) ?
<wgrant> What about that?
<wgrant> It's arguably slightly ugly, but meh?
<StevenK> Sorry, is having the or's nested a bad thing?
<wgrant> Only if you consider nested ORs to be a bad thing.
<wgrant> And I don't see why you would
<StevenK> wgrant: http://pastebin.ubuntu.com/1226063/
<wgrant> StevenK: Looks reasonable. There's no other admin/anon specialcases in the callsites that you can eliminate?
<StevenK> Not that I can see.
<wgrant> :(
<StevenK> However, I'm going to actually stop work and do the LIKE stuff tomorrow
<wgrant> :)
<StevenK> So I'll have a dig to see if that function can be grafted into other sections of the code.
<StevenK> And it will be glorious, etc, etc
<adeuring> good morning
<lifeless> right now, what was I doing this morning? Thats right, I was doing a plugin for bzr
 * lifeless writes some code
<StevenK> lifeless: The morning may have gotten away from you.
<lifeless> rather
<czajkowski> wallyworld: I see you're working on the text for the commercial email, I have an action item to add some text to that could you point me in the right direction please?
<wallyworld> czajkowski: sure. the change has landed already and is awaiting deployment. the file i edited is product-commercial-subscription-expired-open-source.txt in email templates
<wallyworld> is this the one you want?
<wallyworld> czajkowski: there's a few other templates in the same directory as well
<czajkowski> wallyworld: not done this before, basically looking for the mail that is sent to a person after they purchase a subscription so I can add the launchpadstatus feed links on identi.ca/twitter and our blog url
<wallyworld> for other commercial emails of various sorts
<czajkowski> nods
<wallyworld> czajkowski: ok, let me find the template
<wallyworld> czajkowski: product-license-other-proprietary.txt is sent when a project is first created with a proprietary licence and gets an initial 30 day subscription, but just right now, i can't find what is sent when a subscription voucher is redeemed
<wallyworld> czajkowski: if you overlap with sinzui, he will likely be able to tell you immediately where to look. if if you have a bit of text from an email, i can search for it
<czajkowski> wallyworld: I dont but will do in a bit thanks for the help, also see pm for other bit
<lifeless> wow
<lifeless> I can't get used to this fast buildbot ;)
<czajkowski> heh
<mgz> I'd say you've been working on launchpad for too long, BUT THAT'S NOT TRUE ;_;
<mgz> moving back to a bzr-pqm style landing would be nice, rather than the current complications
<StevenK> mgz: Purple has been talking about it
<mgz> I trust purple.
<StevenK> Means ec2 can just go and die too
<lifeless> J
<lifeless> E
<lifeless> N
<lifeless> J
<lifeless> I
<lifeless> N
<lifeless> S
<lifeless> *FFFAAARRRXXXXX* at the typo.
<mgz> ehehehe
<czajkowski> LOL
<StevenK> lifeless: Sounds good. Get me hardware and I'll break my back to set it up?
<lifeless> StevenK: we have the hardware now; prae as master and commander, huey and dewie as slaves
<StevenK> lifeless: I have a plan in the next few days to look at configuring and ec2 instance with LXC as an ssh slave and make sure Jenkins can drive it
<wgrant> yeah
<wgrant> We discussed on the call this morning about setting up Jenkins to do pre-merge testing using the existing slave setup
<nigelb> the server names are getting quite hilarious :P
<StevenK> nigelb: huey and dewie are not the real names
<StevenK> And prae is praseodymium
<nigelb> Oh boy
<nigelb> I hope the names don't match up to some sort of internal DNS. That's a hard to type name ;)
<mgz> we have codenames for codenames around here,
<lifeless> nigelb: they do.
<nigelb> lifeless: oh dear
<StevenK> Awww, leningradskaya no longer resolves
<StevenK> (yes, real server name)
<lifeless> nigelb: we just call it praÃ«
<nigelb> StevenK: *snicker*
<StevenK> nigelb: So there's this thing, called tab complete?
<nigelb> Hah.
<StevenK> ssh running under zsh will tab complete from known_hosts and .ssh/config
<lifeless> there is a helper
<nigelb> true true. I use it all the time.
<lifeless> that knows about all hosts
<lifeless> for Canonical
<nigelb> Oooh.
<lifeless> (internal only)
<lifeless> I don't know if the engine code for it is open - haven't checked. I don't think its super deep though, you can probably invent the same for whereever you are quite easily.
<lifeless> bzr tree, metadata populated by sysadmins, pull and run make.
<nigelb> ah interesting.
<nigelb> I've not yet worked with organizations that's gotten into > 30 servers.
<StevenK> Ahh, well ....
<StevenK> :-)
<nigelb> YEah, small time :P
<cjwatson> FWIW, in grumpy mode: I find the business of slang names for servers makes things very difficult to follow; there are times when it's taken me months to realise that what I thought were two different servers people were talking about was actually just one.  Much as I object to the pervasive coining of new initialisms in Ubuntu-land which also confuse newcomers, so it's probably a lost cause ...
<wgrant> huey and dewie are sluagh and radande :)
<wgrant> And prasÃ© is praseodymium
* frankban changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban | Firefighting: - | Critical bugs: â
<rick_h_> morning
<wgrant> 3
<rick_h_> 2
<rick_h_> 1
 * rick_h_ wonders what happens now
<czajkowski> breakage
<lifeless> wgrant: lp:~lifeless/+junk/bzr-mkghosts
<lifeless> wgrant: You should be able to figure it out from that
* rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: frankban, rick_h | Firefighting: - | Critical bugs: â
<sinzui> czajkowski, Lp does not send out email to people who purchase subscriptions. Lp is not the store or salesforce. Lp send emails when the user selects a special licence, or the commercial subscription expires
<czajkowski> sinzui: right but I'm looking to add launchpadstatus and blog.launchpad.net urls to *some* mail
<czajkowski> which would you suggest
<sinzui> czajkowski, I am not sure. Lp doesn't send out emails to people who register projects or teams or join Lp, which happens to be the only cases I think users would want to be reminded up status information
<czajkowski> sinzui: the logic behind this was I talked to mrevell about how our commercial owners may not know about lpstatus such as build issues or downtime, and we should possibly link them in one of the mails
<czajkowski> so they can reference them
<sinzui> well
<sinzui> we do not have such an email for customers
<czajkowski> hmm ok
<sinzui> I suggest the warning email we send to users who select the three odd licenses. The email explains Lp's policies about open source projects
<czajkowski> ok thanks
<sinzui> czajkowski, lib/lp/registry/emailtemplates/product-license-other-proprietary.txt is sent to the user who chooses Other/Proprietary from the licenses
<sinzui> czajkowski, this is the text: http://pastebin.ubuntu.com/1226560/
<deryck> abentley, adeuring, rick_h_ -- don't forget to tag any cards review that we should look at today.
<czajkowski> deryck: just the person, on the last call we had I said i could do some testing re bp, can you point me in the right direction if it;s ready
<deryck> czajkowski, hey, sorry, was on call.....
<deryck> czajkowski, so I think the idea would be that you play with privacy on blueprints and see if it works like you expect or if you have questions about it....
<deryck> czajkowski, I assume matsubara will do more exploratory testing, actually trying to get it to break.
<czajkowski> nods ok
<deryck> czajkowski, thanks!
<adeuring> frankban_, rick_h_: could one of you please review this MP: https://code.launchpad.net/~adeuring/launchpad/revokeAccessGrants_specs/+merge/126261 ?
<rick_h_> adeuring: will do
<adeuring> rick_h_ thanks!
<rick_h_> adeuring: r=me with one typo in comment
<adeuring> rick_h_thanks!
<sinzui> jcsackett, do you have time to lp-land https://code.launchpad.net/~jcsackett/launchpad/rip-out-portlet
<rick_h_> czajkowski: how about http://ubuntuone.com/4TlJf9tXAV2NDiJvi2i91v as an image or too technical and I should see if we can use the YUI logo or something
<czajkowski> cool
<czajkowski> rick_h_: thanks
<rick_h_> czajkowski: so will get feedback from deryck and I'll get with you to put something together to the world.
<rick_h_> thanks for the help/advice!
<czajkowski> perfect
<czajkowski> just an image helps when we share it on places
<czajkowski> default will pull in the lp image
<rick_h_> k
<deryck> rick_h_, so generally, I like the post very much.  I'm not crazy about the double use of the word modern or modernize....
<deryck> rick_h_, I would describe what we had before as ancient. :)  I think it's more like "bleeding edge" now or "easier to keep pace with YUI updates" or something like that.
<deryck> wouldn't describe, I meant
<rick_h_> deryck: sure
<rick_h_> deryck: how about just 'update'
<deryck> rick_h_, yeah, that works.
<deryck> it was just crusty technically what we had before, but it wasn't not-modern, IMO.
<rick_h_> yea, I was just thinking of things like the Y.App more 'modern front end' kind of stuff.
<rick_h_> but that's why I get you all to sanity check me :)
<rick_h_> http://paste.mitechie.com/show/La3GvwYPeAqqtNralwCs/ tweaked and 'updated' and 'new'
<deryck> yeah, I followed what you meant.
<deryck> looking now....
<deryck> rick_h_, much better.  a final language nit-pick... combo'd could be expanded to comboed, or else rewritten as "combo-loaded"
<rick_h_> deryck: yea, thanks much better as combo loaded
<rick_h_> czajkowski: ok, so updated text, added some links, and make the paragraphs one line to be more WP friendly http://paste.mitechie.com/show/1nO5FCkCr2lT0viQfJx4/
<rick_h_> czajkowski: let me know if there's anything else you need on your end and thanks!
<czajkowski> rick_h_: do you want me to add it t the blog ?
<rick_h_> czajkowski: yes please
<rick_h_> czajkowski: or do I have access? I guess I didn't look if I had access to the blog
<czajkowski> stabs 2FA!!!
<rick_h_> czajkowski: yea sorry I can log in but don't seem to have any access. If you could post it would appreciate it
<czajkowski> I want to find the person who's bright idea was t have it on all the time and make sure they dont ever get beer!
<czajkowski> rick_h_: so if you sign in and create a user I can then make you and admin
<czajkowski> all LP devs should be able to write posts
<rick_h_> czajkowski: ok, I did create a user account
<rick_h_> if you can add me I'll post it and not bug you :)
<czajkowski> 2 ticks
<czajkowski> I need to find you first
<rick_h_> rharding? Richard Harding, something like that I'd imagine
<czajkowski> ahh I was looking under rick_h_
<czajkowski> you're admin now
<rick_h_> ty
<czajkowski> np :)
<jcsackett> sinzui: i was fixing an issue with my colo-repo; looks like you landed it for me?
<sinzui> yes
<jcsackett> sinzui: ok.
<sinzui> jcsackett, I suck. There are two failures that look real, but ec2 test did not see them.
<sinzui> jcsackett, I will fix them since I landed it
<jcsackett> sinzui: you got caught by something i had been working on -- i had noticed just a handful of references to the db_column and was cleaning them up, but apparently failed to mark the MP back to WIP.
<sinzui> oh bugger, we exported that attr.
<sinzui> I may need to put it back
<czajkowski> sinzui: any idea why this person is rnning into this issue reporting a bug....https://answers.launchpad.net/launchpad/+question/209537
<sinzui> czajkowski, no idea since the oops is not there. I suggest runing `ubuntu-bug  initramfs-tools-bin`
<sinzui> oh, maybe it is because you need registered gpp-keys to use bug mail
<sinzui> czajkowski, we silently drop mail from unknown/unverified senders because it is a huge spam vector
<czajkowski> sinzui: he's submitted bugs before so was confused
<czajkowski> sually if you get a n oops when reporting the bug, it still gets reported
<sinzui> jcsackett, date_next_suggest_packaging is a very obscure attr. I really doubt anyone knows it exists.
<jcsackett> sinzui: it wasn't exported for a particular version of the API; does that default to beta or devel?
<sinzui> jcsackett,  https://launchpad.net/+apidoc/1.0.html
<sinzui> it is listed as 1.0
<jcsackett> sinzui: which means we can't just remove it.
<jcsackett> i have a branch that adds it back in.
<sinzui> oh
<sinzui> so I could just land the two test fixes, then you can add an empty attr to support the dead api
<jcsackett> sinzui: empty attr?
<sinzui> jcsackett, the attr can return None. We are going to remove the column from the db because Lp does not use it
<jcsackett> sinzui: ah, so on the model make it an @property that just returns None.
<deryck> abentley, adeuring, rick_h_ -- just a heads up, I'm going offline for lunch here shortly, to switch back to the house for the rest of the day.
<rick_h_> deryck: rgr
<sinzui> jcsackett, we may need a setter to that is silently ignored
<jcsackett> sinzui: branch updated.
<sinzui> oh, you have a fix? which branch?
<jcsackett> sinzui: https://code.launchpad.net/~jcsackett/launchpad/fix-rip-out-portlet/+merge/126288
<sinzui> well we want to ripput the tests that want dates too
 * sinzui may have the patch for that.
<jcsackett> sinzui: but this doesn't address test failures, just the atter.
<jcsackett> right.
 * sinzui running the tests
<sinzui> jcsackett, I can land my branch now to fix the suite, or you can merge my patch and gamble lp-landing it.
<jcsackett> sinzui: link?
<jcsackett> let me merge it and run the two tests on my machine.
<sinzui> jcsackett,  the description for the attr shoulr state it is obsolete
 * deryck goes offline for lunch now
<sinzui> jcsackett, http://pastebin.ubuntu.com/1226941/
<sinzui> jcsackett, your addition though restores the webservice test I changed
<jcsackett> sinzui: bloody hell. ok, land yours to unbreak buildbot. i'll resolve the API attr issue separately.
<jcsackett> this is getting too tangled.
<sinzui> okay
<sinzui> jcsackett, so I think think happened because you reused your branch for changes after I did the review
<jcsackett> sinzui: you are correct; i meant to put the MP back into WIP when i noticed (what i thought) were just two more lines that needed removal.
<sinzui> jcsackett, if you want to reuse a branch, you need to delete the review or change the status back to WIP
<sinzui> yes, we agree
<sinzui> jcsackett, I think the revised description should be "Obsolete. The date to resume Ubuntu package suggestions."
<jcsackett> sinzui: sounds good.
<sinzui> jcsackett, merge trunk and put back the webservice test change in http://pastebin.ubuntu.com/1226941/
<sinzui> I think everything will pass
<czajkowski> rick_h_: nice your blog post is being reshared lots
<rick_h_> czajkowski: yay!
<rick_h_> now back to my coding hole for the rest of the year
<czajkowski> rick_h_: tis ok 2013 is close by you can do another post then
<jcsackett> sinzui: https://code.launchpad.net/~jcsackett/launchpad/restore-date_next_suggest_packaging/+merge/126293
<sinzui> jcsackett, r=me
<jcsackett> sinzui: given the fun we just had, i'm ec2ing just to be sure. it is out now.
<danilos> wallyworld, you've got mail (if it goes through, maybe you don't)
<rick_h_> jcsackett: got a sec?
<jcsackett> rick_h_: probably. what's up?
<rick_h_> https://code.launchpad.net/~rharding/launchpad/info_type_events/+merge/126317
<rick_h_> want to get eyeballs on my thoughts for the information type banner event setup
<rick_h_> see #324 in that diff
<rick_h_> and then #295 for using it in the privacy banner and let me know if that makes sense?
<jcsackett> rick_h_: looks like we're showing on public and hiding on private...should be the reverse, right?
<jcsackett> otherwise this looks sensible, though there is a missing step to make sure the banner updates with the correct text.
<jcsackett> i suppose that could just be another thing listening for the change event.
<rick_h_> jcsackett: the privacy banner doesn't have the text does it?
<rick_h_> that's the beta one?
<jcsackett> rick_h_: they both have text.
<jcsackett> privacy banner says stuff like "this bug is proprietary" or "this bug is private security."
<rick_h_> jcsackett: ah ok so the updateText is manually called
<rick_h_> right so I need to find the locations of that and get that into this loop
<jcsackett> rick_h_: and privacy banner is also used on +filebug and when a bug is first filed with messages that say the type is blah b/c blah.
<rick_h_> no, right, I was only looking at the PrivacyBanner implementation and missed that. Cool thanks
<jcsackett> rick_h_: you're welcome.
<jcsackett> rick_h_: i really like the update to use events. wanted something like that done when we started with the information type transitions but the todo got lost in the shuffle.
<rick_h_> jcsackett: right, so then the choicewidget will be setup to fire an information_type:change event with the new value
<jcsackett> rick_h_: right, that's very cool.
<rick_h_> and everyone else can listen for is_public/is_private to show/hide unless they need the value
<jcsackett> much better than the callback madness.
<rick_h_> then they can watch change itself I think
* rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer:  | Firefighting: - | Critical bugs: â
* rick_h_ changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: -  | Firefighting: - | Critical bugs: â
<rick_h_> jcsackett: sinzui was "    ForbiddenAttribute: ('date_next_suggest_packaging', <Product at 0x1bb7ac50>)" related error stuff the things you guys fixed today?
<rick_h_> my ec2 landing failed with some strange doctests and wondered if it's just a matter of pull trunk and resubmit again
<sinzui> rick_h_, that was bad timing.
<sinzui> rick_h_ I landed a test fix for it, jcsackett is landing a branch that puts it back for API 1.0
<rick_h_> sinzui: ok, thanks. I'll keep an eye out for jcsackett's branch then and retry.
<sinzui> rick_h_: you can land now. I landed the test fix and just qaed work from both our squads
<rick_h_> sinzui: gotcha, landing away then. Thanks
<sinzui> rick_h_, jcsackett's branch is in builbot now actually
<rick_h_> sinzui: ok cool. Since it seems the only failures were there I sent it to buildbot and I'll see where it goes.
<rick_h_> I'm getting good at lp-land hah
<lifeless> flacoste: catchup tomorrow I guess ?
<wgrant> yay, masterless webapp
<wgrant> it mostly works!
<lifeless> wgrant: oh, for downtimes?
<wgrant> Yeah
<lifeless> wgrant: did you see my link to the plugin ?
<wgrant> lifeless: I did, yeah, thanks
<wgrant> Looks pretty sensible
<wgrant> push doesn't populate ghosts, does it?
<wgrant> So we'll need to run it on the remote
<lifeless> fetch-ghosts
<lifeless> or use bzrlib's repository primitives directlry and do lprepo.fetch(localrepo)
<lifeless> that will fetch the lot
<wgrant> Right.
<lifeless> I'd run it on the repo on praseodymium
<lifeless> then use the bzrlib primitives
<wgrant> Ah, fetch-ghosts doesn't have a -d
<wgrant> Hm
<lifeless> l = repository.Repository.open_containing('.')
<lifeless> r = repoistory.Repository.open('bzr+ssh://...')
<lifeless> r.fetch(l)
<lifeless> ^D
<wgrant> Yeah
<StevenK> wgrant: I just read backscroll again and you don't mention the file to peer at for LIKE gubbins
<wgrant> StevenK: Hm, indeed.
<wgrant> StevenK: Distribution.searchSourcePackageCaches
<wgrant> Search for LIKE
<lifeless> wgrant: btw in case it wasn't obvious, the ghosts thing is now maintenance squad prob
<wgrant> lifeless: Yep
<mwhudson> wgrant: only if you don't have to think about an answer, but why is it that oauthnonce didn't get moved to memcache or something -- was it behaviour in the face of rolled back transactions?
<lifeless> never been a need
<mwhudson> mm
<mwhudson> i'm sure i remember some goal along those lines
<mwhudson> probably confused though
<lifeless> and retried transactions perhaps
<lifeless> it was very high writes at one point
<lifeless> but not actually a problem compared to say the builddmaster
<wgrant> Retried transactions are the big issue
<wgrant> But there's also the issue that nonces are pointless for our oauth implementation...
<mwhudson> because ssl?  or something else?
<wgrant> Right, SSL
<wgrant> I believe OAuth 2.0 actually drops nonces.
<wgrant> Because it's intended to be run over SSL
<lifeless> OAuth 2 does a lot of things
<wgrant> Lots of things do a lot of things :)
<mwhudson> i find the security aspects of oauth 1 to be a bit .. odd
<mwhudson> like not signing the body
<wgrant> Right
<wgrant> OAuth 1 is pretty stupid
<wgrant> It's from back in the days when people didn't believe that SSL everywhere would work
<wgrant> But Launchpad always has, so OAuth 1 was a Bad Ideaâ¢ for us
<wgrant> We use plaintext signatures, so if you sniff the request you can just replace the nonce and it'll still work...
<mwhudson> could launchpad just ignore the nonces then?
<wgrant> Right, that's what it's tempting to do after thinking a bit more.
<mwhudson> i know nonces in general allow the client to make some decisions about whether to retry a failed request
<mwhudson> but well, http also does that i guess
<lifeless> er
<lifeless> they are solely for replay attack prevention
<lifeless> imagine you have an API 'delete 6 months of audit history'
<wgrant> Yeah, they're nothing to do with client retries
<wgrant> It's just replays
<lifeless> you don't want that played at an attackers convenience
<wgrant> Which SSL does already
<mwhudson> lifeless: i understand that that's the main point yes
<lifeless> mwhudson: s/main/entire/ :)
<lifeless> wgrant: SSL isn't that robust, sorry.
<mwhudson> someone once claimed to me that in a protocol that uses nonces, you can always retry a request if transmission failed
<lifeless> wgrant: MITM in corporates is all over the place, and on some country levels too.
<mwhudson> because it will get NACKed by the server if it did in fact get through
<wgrant> lifeless: We use plaintext sigs
<mwhudson> i wasn't entirely convinced by this :)
<lifeless> mwhudson: they give you a mechanism that HTTP doesn't intrinsically provide, for once and only once.
<mwhudson> lifeless: right
<lifeless> mwhudson: but then so do any of a range of other layer-on-http tools, and I wouldn't want to conflate the two things.
<wgrant> lifeless: SSL/TLS prevent replay attacks unless someone is MITMing your crypto
<lifeless> wgrant: right, which is widespread.
<wgrant> And if someone's MITMing it that badly, then they can just get the secret
<wgrant> And re"sign" a new request with a new nonce
<lifeless> if you generate the secret on the server, yes.
<wgrant> Huh?
<lifeless> wgrant: DH is all about avoiding that attack.
<wgrant> Yes
<lifeless> wgrant: on the MITM side, see e.g. 'sslbump' in squi.
<wgrant> Sure
<wgrant> But if your SSL is MITMed then you're screwed anyway
<wgrant> A nonce doesn't help you if you're sending the secret plaintext over the SSL stream
<wgrant> Because the attacker just grabs the secret and uses it to sign the new request
<wgrant> We can't pretend to defend against successful SSL MITMs.
<lifeless> thats why you don't send the secret over the SSL stream, see above under DH
<lifeless> I'm not saying what we do is good.
<wgrant> But OAuth doesn't use DH...
<lifeless> I'm saying that MITM'd SSL isn't the end of the world.
<lifeless> wgrant: I know.
<wgrant> For our current implementation, MITM'd SSL is the end of the world
<lifeless> wgrant: Have you heard me say 'Oauth is wonderful' recently?
<wgrant> OAuth 1's nonces are attempting to defend against MITM'd SSL
<wgrant> So they're useless
<lifeless> of course, it got more fun with the oauth dude spitting the dummy
<wgrant> 09:44:40 < wgrant> It's just replays
<wgrant> 09:44:43 < wgrant> Which SSL does already
<wgrant> 09:45:15 < lifeless> wgrant: SSL isn't that robust, sorry.
<mwhudson> if you can mitm ssl you can probably get your hands on the session cookie, which is way easier to abuse :)
<wgrant> Or do you mean in general for OAuth, not for us?
<wgrant> mwhudson: Exactly
<wgrant> In our implementation, if SSL's replay protection is bypassed then we're entirely screwed anyway
<wgrant> I think it's pointless for OAuth to try to defend against SSL MITMs, because if you're trying to do that then you'r probably better off using a hardcoded cert anyway
<StevenK> wgrant: http://pastebin.ubuntu.com/1227650/
<wgrant> StevenK: %%%%%%%% Right.%%%%%%%%
<StevenK> Haha
<lifeless> mwhudson: one word, CRIME.
<wgrant> Well, yeah
<wgrant> But it doesn't impact replays
<wgrant> Just... everything else
<StevenK> wgrant: Tossing that branch at ec2.
<StevenK> Jenkins after breakfast
<bigjools> can someone help me work out why one of my LP users is getting MP email please?  I have an account "maas-lander" which is a member of "maas-maintainers" and all new MPs are emailed to it because "maas-maintainers is requested to review", despite maas-maintainers having no subscription settings.
#launchpad-dev 2012-09-26
<wgrant> bigjools: "requested to review"
<wgrant> It's the reviewer
<wgrant> Not a subscriber
<bigjools> so that overrides sibscription settings saying not to email?
<bigjools> sigh
<bigjools> ok how do I stop this?
<lifeless> it doesn't override, its direct notification
<lifeless> remove maas-lander from maas-maintainers
<wgrant> Set a team email address
<wgrant> Or remove maas-lander from maas-maintainers, yeah
<lifeless> put maas-lander and maas-maintainers both in ~canonical-launchpad-branches or a similar branch-only-access team
<bigjools> then it won't be able to land stuff
<mwhudson> lifeless: that's basically a way for evil js to get at http-only cookies isn't it?
<bigjools> man this stuff is over complicated
<lifeless> thats *why* we have that structure in LP, and why I encouraged you to use the same teams, or the same structure, for MAAS :)
<bigjools> lifeless: I understand - or rather I don't understand why it needs to be so complex :(
<lifeless> mwhudson: http://en.wikipedia.org/wiki/CRIME_%28security_exploit%29
<mwhudson> lifeless: "It relies on the attacker being able to observe the size of the ciphertext sent by the browser while at the same time inducing the browser to make multiple carefully crafted web connections to the target site."
<mwhudson> lifeless: if you can do that, you can just carefully craft the results to do evil directly, surely?
<lifeless> mwhudson: yes, but the demonstration is terrifying
<mwhudson> it's a super cool hack
<lifeless> mwhudson: no, you can't
<wgrant> mwhudson: No
<wgrant> mwhudson: By crafting part of a body I can reveal the headers
<wgrant> eg. if I control a string embedded deep in JSON somewhere
<bigjools> !!!!!! I can't set a contact address that is the same as another team's
<lifeless> bigjools: I wouldn't go the contact address route
<lifeless> bigjools: it gets super messy.
<wgrant> ...
<bigjools> I was going to redirect email to launchpad-reviewers
<wgrant> This is already super-messy, and the complex team structure doesn't make it any less messy
<bigjools> exactly wgrant
<wgrant> MP notifications are fundamentally broken
<wgrant> It's always going to be messy until they're fixed
<bigjools> I don't understand the arbitrary refusal to set the contact address to be the same as another team
<bigjools> that's bizarre
<wgrant> It's not arbitrary
<wgrant> It's less than ideal
<wgrant> But it's certainly not arbitrary
<bigjools> the error on screen should say why instead of appearing to be arbitrary
<wgrant> Launchpad doesn't just use it as a contact address
<wgrant> It's also used to look up the team
<wgrant> Mostly by Soyuz
<bigjools> headdesk
 * bigjools sets contact address to devnull@example.com
<wgrant> Good luck confirming that :)
<bigjools> bollocks, it ignored it!
<bigjools> this is fucking infuriating :/
<lifeless> wgrant: I agree that things could be better, but given the *current code base* I think the simplest way to manage it is leaf teams for things that do stuff, and organisational teams put into those.
<lifeless> wgrant: arguing that its broken just aknowledges that it is.
<bigjools> is this recommended structure documented anywhere on the lp wiki?
<lifeless> wgrant: the other reason to do it the same way as LP is that it would be the same way as LP
<lifeless> bigjools: https://dev.launchpad.net/CreatingNewProjects
<bigjools> thanks
<wgrant> lifeless: Sure, but that requires renaming branches everywhere
<wgrant> lifeless: So it's far less destructive to set a contact address
<lifeless> wgrant: ah, that is a cost to moving, yes.
<lifeless> which will hurt.
<bigjools> lifeless: not sure that page helps
<lifeless> bigjools: I don't think we captured the how-we-got-there anywhere other than the list archives :( - sorry!
<lifeless> I have to run, shopping trip to do
<bigjools> lifeless: :(
<lifeless> back soon, good luck solving your headache.
<lifeless> my 2c before I go
<lifeless>  - make a new team -reviewers and copy the direct member list from -maintainers to -reviewers
<lifeless> make it the reviewer
<lifeless> make it owned by -maintainers
<lifeless> and refactor to remove duplication post-release.
 * bigjools made launchpad-reviewers the reviewer
<wgrant> My inbox thanks you
<bigjools> lp-reviewers was a member of the old team anyway
<wgrant> Yeah
<wgrant> But now I'll get less mail :)
<bigjools> that was the idea :)
<bigjools> also, when I change the status of an MP to approved it'd be really nice if it either warned about new versions not in the page or just approved them anyway
<bigjools> :/
<lifeless> zomg its a statik
<wgrant> 2012-09-25 22:55:56 INFO    Outage complete. 0:00:01.818455
<wgrant> getting there
<wgrant> (from the latest staging update)
<StevenK> What, too long?
<wgrant> No reason for it to take more than a couple of hundred milliseconds
<lifeless> StevenK: yeah
<wgrant> security.py is most of the remaining time, I believe
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/bug-1056506/+merge/126358
<StevenK> wgrant: r=me
<wgrant> StevenK: Thanks
<StevenK> wgrant: I heartily approve of lines 61-69
<wgrant> Yeah...
<lifeless> libreoffice starts -fast- on SSD
<wgrant> 2012-09-26 01:17:38 INFO    Resetting permissions.
<wgrant> Security took 0.780465126038
<wgrant> 2012-09-26 01:17:38 INFO    Enabling access to launchpad_dev_master.
<wgrant> 2012-09-26 01:17:38 INFO    Outage complete. 0:00:00.888748
<wgrant> So security.py is indeed probably most of it
<lifeless>       327 /    0  DistroSeries:EntryResource:getBuildRecords
<lifeless>       321 /    0  Person:+specworkload
<lifeless> :(
<StevenK> Why do we get a PQM success mail at 11:59 and then a failure at 12:04?
<wgrant> StevenK: There are lots of mail delays
<wgrant> StevenK: So buildbot-poll sends the email
<wgrant> It gets stuck in a queue
<wgrant> 5/10 minutes later, buildbot-poll sees there's still stuff to merge
<wgrant> Sends the email
<wgrant> Mail queue unclogs, PQM processes both
<StevenK> I look forward to when we can kill buildbot-poll
 * StevenK stabs lxc
<StevenK> wgrant: LXC is impenetrable.
<wgrant> StevenK: Howso?
<StevenK> I don't understand it at all!
<wgrant> I know parts of it all too intimately.
<wgrant> What is it doing to you?
<StevenK> I destroyed the ec2 instance in disgust before lunch, but the lxc-setup-build script in examples was hanging
<wgrant> StevenK: Did you have a base container set up properly?
<wgrant> And where was it hanging?
<StevenK> lxc-wait -n or so, I think
<StevenK> And base container?
<StevenK> See previous statement about impenetrability.
<wgrant> lp-setup-lxc-build relies on there being a base container already
<wgrant> It builds LP inside a container
<wgrant> You can use lpsetup to create this container
<lifeless> I wonder if we need more 'this is how its all put together' docs for this
<wgrant> Yeah
<wgrant> Particularly since the in-DC setup is different
<wgrant> I suspect we'll be able to pull together docs from me watching StevenK trip over everything :)
<StevenK> Oh. Yay?
<wgrant> StevenK: So, do you understand the high-level fundamentals of how parallel testing is implemented for LP today?
<wgrant> I suspect few outside lifeless, I, Yellow, and some ops, do
<wgrant> But I'm not sure how much you've picked up on
<wgrant> As it's all a bit complicated
<StevenK> wgrant: We create 20 containers run a portion of the tests in them, and testr interleaves it all together into a useful subunit stream
<wgrant> StevenK: Right
<wgrant> Now, the 20 containers aren't all created from scratch each time
<wgrant> They're ephemeral (created by the aptly named lxc-start-ephemeral) as clones of a base container
<wgrant> This base container has LP code+deps+DB etc in it.
<wgrant> And it's persistent
<wgrant> lxc-start-ephemeral uses aufs or overlayfs to create effectively COW snapshots of the base container's tree
<StevenK> Right
<wgrant> Then bring up a new throwaway container on that
<wgrant> You can see the buildbot config in lp:~launchpad/lpbuildbot/public
<wgrant> With a testr.conf that calls IIRC lp-setup-lxc-test to run bin/test in an ephemeral container
<StevenK> Yes, it calls /usr/local/bin/lp-setup-lxc-test
<wgrant> testr just calls the command there to run the tests, so testr doesn't know about LXC at all
<wgrant> As far as it's concerned it's just running 20 parallel testrunners locally
<StevenK> I was guessing I needed lp-setup-lxc-build first, but like I said, that wasn't filled with happiness
<wgrant> Right, lp-setup-lxc-build is run as one of the earlier phases of each full testsuite run
<wgrant> It basically just runs 'make build schema'
<wgrant> So that's done in the base container, rather than separately in each cloned one
<wgrant> But it relies on there being a container already
<wgrant> lpsetup init-lxc can probably create it for you
<wgrant> In the DC we do it manually
<StevenK> Right
<wgrant> There's nothing really special about the container created by lpsetup
<wgrant> You can get something roughly equivalent by running rocketfuel-setup in a normal container from lxc-create
<StevenK> wgrant: I'll bring up an ec2 instance in a bit, working on failing tests from my storm branch.
<wgrant> There were failures? :(
<wgrant> Query issues, or just things expecting SQLObjectResultSets?
<StevenK> Yeah, there was a callsite of handleOptional... hiding in registry/sourcepackage.py
<wgrant> Oh
<wgrant> Sinister
<wgrant> Oh right
<wgrant> That one
<StevenK> Yeah
<StevenK> Which I'd like to destroy
<wgrant> I tried once upon a time to make the build API sensible
<wgrant> But didn't quite get all the way
<StevenK> wgrant: Can I kill _get_ubuntu in that class?
<wgrant> StevenK: That comment is prehistoric and no longer correct
<StevenK> So I can kill it?
<wgrant> You should be able to use an inline ILaunchpadCelebrities lookup instead
<wgrant> Yeah
<StevenK> I was going to, yeah
<wgrant> However
<wgrant> Hmm
<wgrant> Check the history on .packaging
<wgrant> I think the Ubuntu specialcase can probably be removed
<wgrant> It's the only callsite of priorReleasedSeries
<wgrant> And seems pretty pointless
<wgrant> Because Ubuntu should have previous_series set properly everywhere
<StevenK> Yeah
<wgrant> Even in sampledata
<wgrant> So I'd try removing that specialcase and all the priorReleasedSeries definitions and seeing if the test suite complains
<StevenK> That gets this branch to -60
<wgrant> You removed it from DistroSeriesSet and the interfaces too?
<StevenK> Nope
<StevenK> Hold on, removed what?
<wgrant> priorReleasedSeries
<wgrant> Its sole callsite is the Ubuntu specialcase in SourcePackage.packaging
<wgrant> And I can't see any value in that special case.
<wgrant> You might be able to find something
<wgrant> But I really can't
<StevenK> Right, it's terrible
<wgrant> Since Ubuntu releases are serial, the first priorReleasedSeries is always going to be previous_series
<wgrant> Except when we're on a non-released non-development series
<wgrant> Like q-series or r-series
<wgrant> Their first priorReleasedSeries is the current release
<wgrant> precise
<wgrant> not quantal
<wgrant> But that provides no value, since with the special case removed it will fall back to quantal which will fall back to precise
<wgrant> So yeah
<wgrant> Delete the special case
<wgrant> Then probably lp-land and see if buildbot complains
<wgrant> It probably won't, and if it does then the fix is easy and meh.
<StevenK> % bzr damage
<StevenK> Using submit branch /home/steven/launchpad/lp-branches/devel
<StevenK> Healing: 134 lines of code
<wgrant> :)
<wgrant> You got both priorReleasedSeries methods and their respective interfaces?
<StevenK> And the *enormous* test
<StevenK> % bzr grep priorReleasedSeries | wc -l
<StevenK> 0
<wgrant> :)
<wgrant> https://code.launchpad.net/~julian-edwards/launchpad/set-previous-series-bug-805913/+merge/66942
<wgrant> is very relevant
<bigjools> what
<wgrant> StevenK: The addendum there doesn't make much sense to me
<wgrant> If there are many unreleased series, then it will just recurse back
<StevenK> Indeed
<wgrant> It's not necessary to jump straight to the last released one, AFAICT
<StevenK> wgrant: Do you want to eyeball a diff before I commit, push and lp-land?
<wgrant> StevenK: If you push I'll check the MP
<wgrant> bigjools: I'm guessing that's all a blur and you don't remember the context around that MP any more?
<StevenK> wgrant: Pushed
<bigjools> not looked, otp
<StevenK> bigjools: Not still dealing with broker from hell?
<bigjools> no thankfully
<wgrant> StevenK: The amount of red in the incremental diff pleases my eyes.
<wgrant> StevenK: Can you run -t packaging or so?
<wgrant> Just in case there's something obvious
<StevenK> wgrant: Total: 109 tests, 0 failures, 0 errors in 6 minutes 27.422 seconds.
<StevenK> Total: 109 tests, 0 failures, 0 errors in 6 minutes 27.422 seconds.
<StevenK> BLEH, this double paste is getting annoying
<wgrant> StevenK: Sounds good
<StevenK> Let me lp-land it
<wgrant> StevenK: Indeed
<wallyworld> cody-somerville: you around?
 * StevenK stabs init-lxc for wanting lots of information
<wgrant> wallyworld: lazr.restful already has infrastructure for detecting canonical_url changds
<wgrant> Though I'm not sure why it's not working here
<wallyworld> this is lazr.restfulclient
<wallyworld> and the code path does not detect it
<wgrant> wallyworld: Sure, but lazr.restful detects a change and sends a 301 with Location
<wallyworld> clearly not :-)
<StevenK> Blink. It debootstraps?
<wallyworld> this is a fairly old bug too
<wgrant> Well, yeah, it doesn't work in this case
<wgrant> But I'd probably investigate why it doesn't work
<StevenK> I'm going to be unhappy if this requires an LP account
<wgrant> Rather than adding that somewhat terrible model hack
<wgrant> StevenK: Why wouldn't it debootstrap?
<wgrant> It needs to create a fresh installation for the container
<StevenK> wgrant: Wasn't expecting it is all
<wgrant> It should be OK with grabbing the branches from LP anonymously, though
<StevenK> You'd think
<StevenK> I've fed it nonense, so we'll see
<wgrant> wallyworld: See lazr.restful._resource.EntryManipulatingResource.applyChanges() for the code which does it on attribute changes
<wgrant> But I guess not on method calls
<lifeless> we could run an image rather than debootstrap
<wallyworld> ok, will look. i didn't realise lazr.restful detected url changes
<lifeless> but LXC isn't [currently] run that way
<StevenK> Rargh
<StevenK> lpsetup needs a bug
<StevenK> It pulls from archive no matter what, it should be configurable
<wgrant> wallyworld: I'm not quite sure where method calls are done, but I know it automatically calls ObjectModifiedEvent, so there must be something there
<wgrant> StevenK: Ah yeah
<wgrant> StevenK: I manually ran lxc-create with MIRROR=whatever beforehand
<lifeless> wgrant: have you had time to look at the ghosts?
<StevenK> Sadly, it's going faster than the ec2 mirror
<wgrant> lxc-create stores a cache keyed on (distroseries, archtag)
<wallyworld> wgrant: by "it", you mean lazr.restful i assume
<StevenK> So I can't complain much
<wgrant> wallyworld: Right, sorry
<wallyworld> ok
<wgrant> lifeless: Not yet, as it doesn't seem overly urgent. If you want me to I'll get onto it nowish, though
<wgrant> I've been fixing bugs to make bigjools shut up :P
<StevenK> That fix should be deployed soon
<wgrant> Indeed :)
<StevenK> wgrant: Right, so init-lxc just finished
<lifeless> wgrant: I'd like to know its good this week
<wgrant> StevenK: Did it branch LP stuff into it and stuff?
<lifeless> wgrant: as config changes when they are needed, are generally needed now
<wgrant> lifeless: Yeah, true
<wgrant> And we have no ops next week
<StevenK> wgrant: I don't think so
<StevenK> wgrant: How can I check?
<lifeless> wgrant: exactly
<wgrant> StevenK: ls ~
<lifeless> wgrant: does the lp-setup-lxc stuff bind-mount ~?
<lifeless> or does it do a fresh copy of everything ?
<StevenK> root@ip-10-78-117-158:~# ls -lh ~
<StevenK> total 0
<wgrant> lifeless: it bind mounts ~
<wgrant> StevenK: Ah right
<lifeless> thats root though :P
<wgrant>     init-lxc            Create an LXC container suitable for later installing
<wgrant>                         a Launchpad development environment.
<wgrant>     init-repo           Get the Launchpad code and dependent source code.
<wgrant>     install-lxc         Completely sets up an LXC environment with Launchpad
<wgrant>                         using the sandbox development model.
<StevenK> Oh, bleh
<lifeless> StevenK: tell me you ran that as root ?
<StevenK> lifeless: Which as root?
<lifeless> StevenK: is this on your machine ?
<wgrant> From install-lxc:
<wgrant>     This is basically the same as running `init-lxc` and then, inside the \
<wgrant>     newly created container, `lp-setup init-repo`, `lp-setup update`, and
<wgrant>     `make install`.
<StevenK> lifeless: Note the hostname
<lifeless> StevenK: doesn't tell me anything
<StevenK> It's an m2.xlarge ec2 instance
<lifeless> StevenK: thanks
<StevenK> m2.2xlarge, rather
<StevenK> 34GiB of RAM
<wgrant> StevenK: So I'd start the container, SSH in, and run lp-setup init-repo, lp-setup update, make install
<StevenK> lxc-start lptests ?
<wgrant> sudo lxc-start -n lptests -d
<wgrant> Without -d it'll start in the foreground and give you local console
<wgrant> Which is usually undesirable
<wgrant> You can then use lp-lxc-ip (or something close to that) to determine the IP address to give to ssh
<StevenK> I thought it was ubuntu/ubuntu
<wgrant> It should be the username and password of whatever account you ran it as, usually
<wgrant> But otherwise ubuntu/ubuntu
<wgrant> Or root/
<StevenK> root/ doesn't work either
<wgrant> It's possible that running it as a passwordless root account has confused it
<wgrant> Check /var/lib/lxc/lptests/rootfs/etc/shadow
<StevenK> Disabled root, it has an jenkins account
<StevenK> But the password isn't jenkins or test or ubuntu or test
<wgrant> Ah, if you ran it as jenkins then it'll have copied your host's jenkins password
<StevenK> Ahh
<StevenK> That I know
<wgrant> I thought you ran it as root, given the PS1 earlier
<StevenK> It insisted I run it with -u
<wgrant> Ah
<wgrant> Right
<StevenK> lp-setup init-repo: error: No bzr launchpad-login set.
<StevenK> Bleh
<wgrant> vim is your friend
<wgrant> I suspect
 * StevenK adds --use-http
<wgrant> Or that
<StevenK> Hm, the amount of progress printed is staggering
<wgrant> In which direction?
<StevenK> Do you want to proceed? [y/N] y
<StevenK>   
<wgrant> Heh
<StevenK> Right, it is doing something, it just isn't telling me
 * wgrant watches 2500 gpg prompts fly past
<StevenK> Hm?
<wgrant> I should probably have disabled signing before running mkghosts
<StevenK> Heh
<StevenK> 20 failures
<StevenK> 6 errors
<StevenK> So, I love
<StevenK> lose, even
<lifeless> wgrant: wheee :P
<wgrant> StevenK: Hm, what
<wgrant> You lost
<wgrant> Terribly
<wgrant> But how
<wgrant> Those errors don't make much sense
<wgrant> It looks like the DSP is ending up None
<StevenK> BrokenImplementation: An object has failed to implement interface <InterfaceClass lp.answers.interfaces.questiontarget.IQuestionTarget>
<wgrant> Ah, no
<wgrant> It's just answer_contacts that's broken, it seems
<wgrant> By "The answer_contacts attribute was not provided" it means "AttributeError: 'NoneType' object has no attribute 'using'"
<StevenK> How did I manage to screw that up?
<wgrant> Oh heh
<wgrant>      @property
<wgrant> -    def _store(self):
<wgrant> -        return Store.of(self.sourcepackagename)
<wgrant> -
<wgrant> That would do it
<wgrant> in sourcepackage.py
<StevenK> Oh, I thought that was unused!
<StevenK> I even bzr grepped for it
<wgrant> QuestionTargetMixin uses it
<wgrant> Anyway, this is why we have 35 minute buildbot :)
<StevenK> Heh
<StevenK> Putting together a testfix
<wgrant> It looks like the only failure, but you would do well to wait until this run finishes and then run all the failures
<StevenK> It's going to require a branch anyway, but yeah
<StevenK> It just finished
 * StevenK grabs the stream 
<wgrant> http://lpbuildbot.canonical.com/builders/lucid_lp_lxc/builds/39/steps/shell_9/logs/subunit/text should be what you want, yeah
<StevenK> Indeed
<StevenK> I was already wgetting when I said I was grabbing it
<StevenK> And I'm now waiting on testr run --failing
<StevenK> (and bzr on said ec2 ...)
<StevenK> jenkins@lptests:~$ du -sh launchpad/lp-branches/.bzr
<StevenK> 229M	launchpad/lp-branches/.bzr
<wgrant> :)
<StevenK> Ran 84 (-22077) tests in 131.750s (-1768.113s)
<StevenK> PASSED (id=1, skips=6)
<wgrant> Excellent
<StevenK> OMG, it finished
<wgrant> Your ec2 instance?
<StevenK> Yeah
<StevenK> lp-setup update depends on CWD? :-(
<wgrant> Yes
<wgrant> as do lp-setup-lxc-test and lp-setup-lxc-build
<wgrant> It makes a fair bit of sense
<StevenK> jenkins@lptests:~/launchpad/lp-branches/devel$ lp-setup update
<StevenK> lp-setup update: error: the target dir /home/jenkins/launchpad/lp-branches/devel is not a valid Launchpad tree.
<StevenK> lp-setup update: error: the target dir /home/jenkins/launchpad/lp-branches/devel is not a valid Launchpad tree.
<wgrant> Not seen that before
<wgrant> Luckily the code is quite sensible
<StevenK> Oh, it's in sandbox, for ... some reason
<StevenK> Testfix landed
<wgrant> Thanks
<wgrant> StevenK: Right, it uses lightweight checkouts
<wgrant> devel is a treeless branch
<wgrant> sandbox is a lightweight checkout
<StevenK> And devel is empty
<wgrant> It has a .bzr
<wgrant> But that's it
<lifeless> wgrant: StevenK: more low hanging fruit: https://bugs.launchpad.net/loggerhead/+bug/869309
<_mup_> Bug #869309: If folders in repository have unicode names, sometimes I get KeyError <navigation> <oops> <trivial> <unicode> <loggerhead:Triaged> < https://launchpad.net/bugs/869309 >
<lifeless> brought to my attendion by the new user that just assigned it to themselves ><
<wgrant> lifeless: But there's no low-hanging fruit :)
<lifeless> wgrant: it has a patch attached.
<lifeless> wgrant: doesn't get much lower :)
<wgrant> Indeed
<StevenK> wgrant: Right, that's all done on my ec2 slave
<wallyworld> is it just me or does anyone else's screen dimming fail to turn the screen back when the mouse is moved? the pointer shows up but the screen stays black :-(
<lifeless> wallyworld: that could be a dropped vsync for unity
<lifeless> wallyworld: it looks like a dimming problem, but it isn't
<wallyworld> it doesn't happen if i turn off "screen dimming after 10 minutes"
<wallyworld> so i just got back from making a coffee and boom :-(
<wallyworld> cause i forgot to turn it off again
<lifeless> chat to RAOF
<lifeless> in #ubuntu-dekstop
<lifeless> desktop
<lifeless> once they finish figuring out where to put the privacy setting
<wallyworld> ok, i'll search bugs first
<StevenK> wgrant: So, next step?
<wgrant> StevenK: Do stuff
<wgrant> Um
<wgrant> StevenK: In sandbox on the host, run lp-setup-lxc-build
<wgrant> See if it works
 * StevenK stabs it for prompting for a sudo password every 2 seconds
<StevenK> wgrant: In a word, no
<wgrant> Heh
<wgrant> buildbot loves you, though
<wgrant> StevenK: What broke?
<wgrant> "Everything" is an acceptable answer.
<StevenK> The script
<StevenK> wgrant: http://pastebin.ubuntu.com/1227964/
<wgrant> This command has to be run as root
<wgrant> sudo it?
<wgrant> Ah
<wgrant> You did
<wgrant> StevenK: Why ~/lp-setup-lxc-build rather than the one installed in PATH?
<wgrant> Did you hack it
<wgrant> ?
<StevenK> There is none in PATH
<wgrant> lp-setup should have come with one
<wgrant> I thought
<StevenK> It's in /usr/share/pyshared/lpsetup/templates/lp-setup-lxc-build
<wgrant> Ah
<wgrant> Right
<StevenK> And I got sick of that long path so I copied it and +x'd it
<wgrant> Container {lxc_name} does not exist
<wgrant> Sounds like you didn't replace the bits of the template?
<StevenK> Oh, I need to sed over it?
<wgrant> It takes {lxcip}, {lxc_name} and {ssh_key_path} variables
<wgrant> The last is just a local SSH key to use to connect to the containers
<StevenK> So I need to fix it, it certainly doesn't use $1 and so on?
<wgrant> Right
<wgrant> lxcip shouldn't be an arg, but the other two arguably should be
<StevenK> wgrant: So the name is lptests or something that will based off it, like current-test-0 or something?
<wgrant> StevenK: lptests is the base, the ephemerals will be something like lptests-temp-wefwhjefuwehfuiweghfuiw
<StevenK> wgrant: Sorry, I mean what should {lxc_name} be?
<wgrant> StevenK: lptests
<StevenK> wgrant: So lxc-stop on lptests failed with Operation not permitted, but it seemed to work
<lifeless> lp:~lifeless/python-oops-datedir-repo/bug-971255 <- another critical for you, MP coming up
<wgrant> StevenK: You need to sudo lxc-* operations, usually
<StevenK> Except the whole script is running as root
<wgrant> That's a little odd
<StevenK> Hm, I think I should done this as an EBS backed instance
<StevenK> wgrant: https://qastaging.launchpad.net/builders/palmer/+history?build_text=libc&build_state=all consistenly times out :-(
<lifeless> https://code.launchpad.net/~lifeless/python-oops-datedir-repo/bug-971255/+merge/126386
<lifeless> wgrant: StevenK: or wallyworld: ^
<StevenK> No diff
<StevenK> No review
<lifeless> StevenK: there is a diff
<lifeless> StevenK: thanks to the magic of ajax
<StevenK> Looks good
<wgrant> StevenK: Indeed, but we're OK as long as the stuff that worked before hasn't regressed.
<wgrant> We should probably just drop name filtering from that page eventually
 * StevenK destroys this instance
<wgrant> StevenK: I'd recommend against using EBS, as that would let you work around setup awkwardness rather than fixing it properly
<StevenK> wgrant: I'm trying to avoid the two hour wait lp-setup install-lxc brings
<wgrant> AH
<wgrant> H
<wgrant> Ah
<lifeless> aH
<lifeless> wgrant: StevenK: wallyworld: https://code.launchpad.net/~lifeless/python-oops-datedir-repo/bug-1003627/+merge/126392 - with this I'll do a release, and we'll have that critical fix-released.
<StevenK> Is the prune bug already solved?
<lifeless> no
<lifeless> the pruning too fast one is
<lifeless> this is pruning-the-right-stuff-is-impossible.
<lifeless> we have to physically partition the datedir repo for things in different project groups
<lifeless> this will fix it
<StevenK> Didn't wgrant write a patch for the prune reference bug?
<lifeless> he did: 19:00 < lifeless> the pruning too fast one is
<lifeless> this is a different prune bug
<StevenK> lifeless: r=me
<lifeless> thanks
<lifeless> wgrant: isn't bug 1050722 FR ?
<_mup_> Bug #1050722: prune only searches for OOPS references up to prune_until <Python OOPS Date-dir repository:Fix Released by wgrant> <python-oops-tools:In Progress by wgrant> < https://launchpad.net/bugs/1050722 >
<wgrant> lifeless: Ah, indeed
<wgrant> Closed, thanks.
<lifeless> StevenK: https://code.launchpad.net/~lifeless/python-oops-tools/bug-1003627/+merge/126401 if you would
<lifeless> StevenK: I've set a commit message, so if you can toggle the MP to approved (if you do approve) that would rock. Thanks!
 * lifeless waves bye-for-a-bit
<StevenK> Do not understand why prune is duplicated
<adeuring> good morning
<lifeless> StevenK: the CLI is the only duplicate
<lifeless> StevenK: oops-tools prunes the DB
<lifeless> StevenK: datedir-repo prunes disk
<lifeless> StevenK: and the API client is in just one place
<StevenK> Yes, but you're duplicating logic between them
<lifeless> StevenK: the CLI only
<wgrant> There is some code that we should dedupe further
<wgrant> But it's not completely terrible atm
<wgrant> and it can't all be generalised
<lifeless> writing a disk-dir implementation of the django orm terrifies me
<lifeless> StevenK: thanks!
<lifeless> StevenK: wgrant: I'll leave you(purple) to get the prune cronjobs raionalised at a convenient
<wgrant> Of course :)
<lifeless> wgrant: thanks
<mvo> hello, it seems like exports for http://bazaar.launchpad.net/~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal/changes  stopped at Aug 16th for some reason, would it be possible to check if something is stuck/stale (lockfile etc)? it would be nice to get a updated package description export for the ubuntu beta2
<czajkowski> wgrant: StevenK wallyworld_ one for you guys to kick or invstigate ?
 * wallyworld_ runs away (my packing foo is zero)
<wallyworld_> packaging even
<dpm> wallyworld_, there's no escape. It's not about packaging, it's about bzr branches ;)
<wgrant> wallyworld_: It's actually translations
<wgrant> Which none of us have any clue on
<wgrant> But let's see
<wgrant> That date is a little suspicious
<wgrant> I wonder if the import was interrupted by a DC move and left a lock around
<wgrant> s/import/export/
<wgrant> Since ddtp exports take forever
<wallyworld_> ah, is that when the move happened
<wgrant> August 18, but yeah
<wgrant> Rather close
<wgrant> 2012-09-26 05:11:44 ERROR   Failure in ddtp-ubuntu/quantal: LockContention(Could not acquire lock "(local)": )
 * mvo has no clue either but hopes it just a "rm export-ddtp-quantal.lock"
<wgrant> mvo: bzr break-lock lp:~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal
<wgrant> should do it
<mvo> \o/
<wgrant> Hopefully it'll say there's a lock there from taotie on Aug 18
<wgrant> It wasn't killed by the move, but exports were severely broken due to fallout from the move a day after
<mvo> wgrant: hm, that did just return, no message no nothing?
<wgrant> :(
<wgrant> Let's see
<wgrant> jam, jelmer, mgz: ^^ any ideas on the above?
<czajkowski> wallyworld_: StevenK could one of you please help me out on https://answers.launchpad.net/launchpad/+question/209465
<wallyworld_> czajkowski: i think if they use one of the supported bug trackers eg bugzilla etc then lp will import bug data but it will still be available in the external system too
<wallyworld_> but i'm not 100% sure what happens the other way
<jam> wgrant: http://bazaar.launchpad.net/~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal/.bzr/repository/lock/ and http://bazaar.launchpad.net/~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal/.bzr/branch/lock/
<jam> show that no lock is currently held.
<czajkowski> wallyworld_: ok thanks :)
<wgrant> jam: Exactly
<jam> I don't really knowt about the exception you saw.
<wgrant> czajkowski: They won't be able to search for or report new bugs on Launchpad, but all data will still be there if they choose to reenable it
<jam> It is possible to be a semi-genuine contention, if you are re-opening a branch in a script, and now one side is holding a lock, and the other is trying to do something.
<wgrant> jam: It's only been happening on that branch since the move chaos
<wgrant> Without code changes
<wgrant> So it seems unlikely to be legitimate.
<wgrant> I don't see howit can be "(local)" but without a URL
<jam> well, we did upgrade bzr in the middle term
<wgrant> It worked on Aug 16, we moved to a new server with significant drama on Aug 18, then it hung a bit until Aug 30, and from Aug 31 it's been giving that error
<wgrant> Was there a bzr upgrade in those two weeks? Possibly...
<cjwatson> tumbleweed: Oh, are you still looking for a db review for your edit-packagesets branch?  https://dev.launchpad.net/PolicyAndProcess/DatabaseSchemaChangesProcess has instructions on whom to seek db reviews from
<tumbleweed> cjwatson: aha, I never looked there. Thanks
<mvo> czajkowski, wgrant: sorry, I was in a meeting now, should I rather file a bugreport about the export issue instead of asking on irc? especially if its not as trivial as I had hoped?
<czajkowski> mvo: probablly best that way the maintenance team can look at it
<StevenK> Which export issue?
<mvo> StevenK: lp:~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal is not getting translation updates anymore since ~1month
<mvo> I filed bug https://bugs.launchpad.net/launchpad/+bug/1056752  now
<_mup_> Bug #1056752: Translations export not working for lp:~ubuntu-core-dev/ddtp-ubuntu/ddtp-quantal <Launchpad itself:New> < https://launchpad.net/bugs/1056752 >
<rick_h_> thanks for the qa wgrant
 * mpt wonders what "div.first{*margin-right:4%;_margin-right:1.3%}" is supposed to do
<mgz> screw with IE users for fun?
<mpt> Neither *margin-right nor _margin-right is a valid property, as far as I know
<mgz> the star property hack targets IE 7 and less, the underscore hack targets IE 6 and less
<rick_h_> wheeee
<rick_h_> css hacks ftw
<mpt> oh I see
<mgz> so, it's deliberatly invalid css to get older buggy browsers that misinterpret it as valid to apply specific rules
<mgz> but... that's pretty bad, setting percent margins is likely to just break things anyway
<mpt> I was just trying to figure out why bug reports had become unreadable, and it was because my custom Launchpad CSS had stopped working
<mgz> and having different values for different browsers then makes working out why something looks funny even more entertaining
<rick_h_> ah, well % css rules are generally a good thing as they keep things in scale for different browser sizes
<rick_h_> we're not in the land of pixel perfect and such
<rick_h_> curious what custom CSS you run with.
<mpt> yay, fixed
<mpt> rick_h_, http://paste.ubuntu.com/1228291/
<rick_h_> mpt: cool
<rick_h_> while I like smaller fonts I've often thought a lot of users must find it small
<rick_h_> jcsackett: ping when you get a sec
* abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: abentley  | Firefighting: - | Critical bugs: â
<rick_h_> abentley: a review for you if you get a chance please https://code.launchpad.net/~rharding/launchpad/info_type_events/+merge/126317
<rick_h_> jcsackett: would appreciate your look as well if you have the bandwidth. ^^
<rick_h_> I think this will address the manual usage and we'll see I guess when I follow up and integrate the change into place.
<abentley> rick_h_: What happens if an item is private and a feature on the page is in beta?  That should show two banners, but you've made it a singleton, IIUC.
<rick_h_> abentley: the beta code is in betabanner.js and has it's own singleton
<abentley> rick_h_: cool.
<rick_h_> that's just moved code, from the bottom to the top of the file so it's how it currently works
<abentley> rick_h_: "@namespace lp.app.banner" reminds me that we haven't reached consensus about whether to separate namespaces from module names.
<abentley> rick_h_: But you didn't change that, so that's alright.
<rick_h_> abentley: yea, at some point I want to put together some notes/examples and see
<rick_h_> I looked at a rename here, but it hit some 50 files and I didn't want to get into it with this
<rick_h_> because we've started a lp.ui namespace and this would be good as lp.ui.banner.PrivacyBanner, lp.ui.banner.BetaBanner, etc
<rick_h_> but for another day
<jcsackett> rick_h_: ping. i lost history in irc, so the details as to why you needed me to ping you are lost to me. what's up?
<abentley> rick_h_: Why attach the _singleton_privacy_banner to window?
<rick_h_> abentley: to be explicit. That's what's happening itself, but making it explicit makes sure in all cases you're using a global instance
<rick_h_> jcsackett: sorry, ping'd earlier because I didn't get how banner rendering worked with the .pt bits
<danilos> deryck, hi, I've filed a few bugs related to specification privacy: bug 1056881, bug 1056891 and bug 1056893 - sorry if I made any duplicates, but I didn't find them
<_mup_> Bug #1056881: Specifications privacy: subscribers can't see private blueprints <Launchpad itself:New> < https://launchpad.net/bugs/1056881 >
<_mup_> Bug #1056891: Specification privacy: upcoming work won't load for anyone if there's any private data on it <Launchpad itself:New> < https://launchpad.net/bugs/1056891 >
<_mup_> Bug #1056893: Specification privacy: no "private content" header on +upcomingwork page with private data <Launchpad itself:New> < https://launchpad.net/bugs/1056893 >
<rick_h_> jcsackett: but basically just ping'd on the review since you looked at it yesterday with feedback
<rick_h_> jcsackett: feel free to ignore
<jcsackett> rick_h_: so all is well now? i'm happy to answer questions whenever. it's not the clearest of code, despite my best efforts at the time. :-P
<rick_h_> jcsackett: well, I broke off rendering into a second step. Just events for now
<jcsackett> rick_h_: dig.
<rick_h_> so might bug you later on, but for now I"m cool
<jcsackett> rick_h_: righto.
<abentley> rick_h_: I don't understand the value of that explicitness.  Because there's no encapsulation, there's no longer a guarantee that it is a singleton.
<rick_h_> abentley: window is a browser enforced singleton global space. It's to make sure you know where that's at and prevents people from looking for var definitions and such
<rick_h_> for instance, in tests, I know I need to reset that window.var
<deryck> danilos, thanks for filing the bugs.
<abentley> rick_h_: Window is just a global.  It doesn't ensure there's only one instance of PrivacyBanner.  If I can set __singleton_privacy_banner to null, then getPrivacyBanner will create a second instance.
<rick_h_> abentley: right, but the module is only loaded once. So it's set to null one on module load. And then never again
<danilos> deryck, yw, thanks for getting this in, Linaro wants to use it asap :)
<rick_h_> except in tests where I do that to do a proper teardown
<abentley> rick_h_: Sorry, forgot I was reviewing before the call.
<rick_h_droid> np
<abentley> rick_h_: It doesn't seem very decoupled to be emitting privacy_banner:hide/privacy_banner:show.  If you know about the privacy banner, why not ns.getPrivacyBanner()._make_public ?
<rick_h_> abentley: because in that case you need to deal with the instance
<rick_h_> abentley: the future branch will get rid of the singleton code so you won't call anything. You'll just fire the event.
<rick_h_> and ideally, you'll be firing the information type event, not the privacy banner event
<rick_h_> so the calling code won't be using _make_public. What you'll have is banners and portlets listening for information_type:change/is_public/is_private events
<abentley> rick_h_: Okay, makes sense.
<abentley> rick_h_: r=me.
<rick_h_> abentley: cool thanks for the review
<jcsackett> abentley: you available to look at a branch that just fixes up sampledata?
<abentley> jcsackett: sure.
<jcsackett> abentley: awesome. :-) https://code.launchpad.net/~jcsackett/launchpad/remove-date_next_suggest_packaging-needs-sampledata/+merge/126475
<abentley> jcsackett: r=me.
<jcsackett> abentley: thanks!
<robbiz^> Hi guys! I've some problems installing launchpad on my laptop, with chroot and rocketful-setup
<robbiz^> can I ask someone of you how to fix it?
<czajkowski> robbiz^: you might have more luck if you start to explain whats going on
<czajkowski> or else posting to launchpad-dev mailing list
<czajkowski> robbiz^: https://launchpad.net/~launchpad-dev
<robbiz^> Ok...
<robbiz^> Well my  postgresql database didn't start
<robbiz^> the message is this
<robbiz^> Error: The cluster is owned by user id 120 which does not exist any more
<robbiz^> going through system folders I've no config file in /etc/postgresql/9.1/main
<robbiz^> I have Ubuntu precise with chroot system as explained in dev.launchpad.net
<jcsackett> sinzui: you free to talk for a bit?
<sinzui> yes
<robbiz^> Ok... Probably it's better to post on the mailing-list!
<robbiz^> :)
<sinzui> jcsackett, ding dong
<sinzui> jcsackett, I think this test should pass, but it does not. It might be the origin of the 404 because mail rationales and canonical urls are need to explain why the email as received: http://pastebin.ubuntu.com/1228850/
<jcsackett> sinzui: awesome.
<lifeless> jcsackett: 'When this is improved' ? <- approved??
<jcsackett> lifeless: Sample data branch?
<jcsackett> lifeless: approved, yes.
<lifeless> jelmer: hey, still interested in packaging lptools ?
<jelmer> hi lifeless
<jelmer> lifeless: no, not really after wheezy
<lifeless> jelmer: have you been using bzr builddeb etc for it, or just regular packaging ?
<lifeless> jelmer: I see 'new upstream snapshot' in the log - can't quite tell :)
<jelmer> lifeless: I only use bzr builddeb for packages in bzr so that must be what I was using :-)
<lifeless> jelmer: also, I haven't used the debian bzr facilities for a couple years - whats the current stuff for pushing there...
<lifeless> jelmer: or perhaps I can convince you to do the upload of 0.2.0 and ITA it at the same time ?
<jelmer> the last branch is @ http://anonscm.debian.org/bzr/bzr/collab-maint/lptools/unstable/
<jelmer> lifeless: Sure, I'm happy to do another upload
<jelmer> lifeless: do you mean RFA rather than ITA?
<lifeless> yes, crossed wires
<lifeless> I was thinking intent to abandon :)
<jelmer> lol
<jelmer> lifeless: but sure, happy to do another upload with 0.2.0 and the RFA
<lifeless> jelmer: that would be awesome, thank you
<lifeless> let me file it
<lifeless> jelmer: actually, I'm going to O it
<jelmer> lifeless: euhrm, okay
<lifeless> jelmer: I doubt there will be another upload before I finish here
<lifeless> jelmer: and after that I'll have other things to worry about, so saying I'd maintain it in the interim would be an exaggeration
<jelmer> lifeless: sounds reasonable to me
<lifeless> http://www.debian.org/devel/wnpp/ : "RFA...hey will maintain it in the meantime, but perhaps not in the best possible way. In short: the package needs a new maintainer. "
<jelmer> lifeless: I originally thought that's what you meant
<lifeless> vs
<lifeless> O
<lifeless> The package has been "Orphaned". It needs a new maintainer as soon as possible
<czajkowski> wgrant: see pm
<jelmer> since I think a RFA doesn't require changes to the package itself
<lifeless> jelmer: I'm not sure O does either does it ?
<lifeless> jelmer: adoption requires the change
<jelmer> lifeless: it does, requires changing the maintainer to Debian QA team
<lifeless> huh, inconsistent docs ftw
<lifeless> jelmer: so, whats easiest for you?
<jelmer> lifeless: if you file the O bugreport I can do an upload that changes the maintainer to the QA team
<lifeless> will do
<lifeless> jelmer: just waiting for the ack
<lifeless> jelmer: bug 688916
<_mup_> Bug #688916: 75-80% CPU-Usage (starting with 1.9.0beta1) <cpu> <Mixxx:Invalid> < https://launchpad.net/bugs/688916 >
<lifeless> well, not that one :P
<jelmer> (-:
* abentley changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: -  | Firefighting: - | Critical bugs: â
<jelmer> we've given up on critical bugs?
* StevenK changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: -  | Firefighting: - | Critical bugs: Ã¢Ë~300
<StevenK> Hm
* StevenK changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: -  | Firefighting: - | Critical bugs: ~300
<sinzui> wgrant, https://code.launchpad.net/~sinzui/launchpad/bug-subselect-timeout/+merge/126566
<StevenK> wallyworld__: http://theamazingios6maps.tumblr.com/
<sinzui> jcsackett, r=me
<jcsackett> sinzui: awesome, thansk.
<sinzui> StevenK, https://devpad.canonical.com/~curtis/launchpad-critical-report/launchpad-criticals.html is updated.
<StevenK> wgrant: So, lp-setup-lxc-build actually does a build
<wgrant> StevenK: Is the build successful?
<StevenK> It looks to run make schema too, it looks fine
<StevenK> wgrant: lxc-stop: failed to stop 'lptests': Operation not permitted and ls: cannot access lptests: No such file or directory are a little concerning
<wgrant> StevenK: You sure it's adequately root?
<StevenK> wgrant: It's running under sudo ...
<elmo> apparmor
<StevenK> sudo lxc-stop -n lptests does not complain
<StevenK> I may have to reach for set -x or run 'id' in the script
<wgrant> The apparmor workaround shouldn't be necessary to get this bit working
<wgrant> Just some stuff inside the container
<wgrant> Like postgres
<wgrant> And I think lpsetup does the apparmor disablement.
<StevenK> Apparently not for nested
<StevenK> According to the README
<StevenK> But who reads those anyway
<StevenK> wgrant: So the next step is to fire up lp-setup-lxc-tests?
<wgrant> StevenK: Right, fill in the lp-setup-lxc-test template and then run something like 'lp-setup-lxc-tests -t lp.services.config' and see what happens
<StevenK> Pain, misery and suffering is my guess
<wgrant> And/or great success.
<StevenK> Well, those aren't mutally exclusive. :-)
<wgrant> StevenK: Any luck?
<StevenK> wgrant: Just about to run it
<StevenK> BLEH
<StevenK> Forgot {ssh_key_path}
<wgrant> Heh
<wgrant> It's easy to do
<StevenK> Rargh, single quotes
#launchpad-dev 2012-09-27
<StevenK> wgrant: http://pastebin.ubuntu.com/1229519/
<wgrant> StevenK: That looks most excellent. Perhaps try some tests that exercise the DB?
<StevenK> Hmmm
<StevenK> -t bugs ?
<wgrant> Though DatabaseLayer setup worked, so it's a good sign
<StevenK> And it can run while I nom
<wgrant> -t bugs is huge
<wgrant> Try archiveuploader
<wgrant> Relatively quick and terrible
<StevenK> wgrant: Right, that looks pretty excellent too
<wgrant> Right.
<wgrant> So, jenkins :)
<StevenK> wgrant: Yes
<wgrant> StevenK: Should be pretty easy, I guess
<wgrant> No need for the complex build rules any more
<wgrant> Just a .testr.conf, lp-setup-lxc-build, testr run --parallel
<wgrant> Or so
<StevenK> Do I need the testr from testing-cabal?
<wgrant> StevenK: You might need new testrepository, testtools and subunit
<wgrant> Might as well grab them all from there
<StevenK> Right
<StevenK> Just installing java and fixing ssh access
<wallyworld> lol
<StevenK> The Jenkins slave is java, no choice in the matter
<wallyworld> i know, just trolling
<StevenK> Slave successfully connected and online
<StevenK> wgrant: So, .testr.conf ?
<StevenK> This is different from the .testr.conf already in the LP tree?
<wgrant> StevenK: Yeah. Grab it from testr.conf in lp:~launchpad/lpbuildbot/public
<wgrant> It has a list command and uses lp-setup-lxc-test rather than bin/test
<StevenK> So I should move it into the tree as the first step?
<wgrant> Just clobber the .testr.conf that's in trunk locally for now
<wgrant> buildbot copies it in at the start of each build
<StevenK> I've added a build step
<LPCIBot> Project devel build #1091: STILL FAILING in 1 min 3 sec: https://lpci.wedontsleep.org/job/devel/1091/
<wgrant> Heh
<StevenK>  sudo lp-setup-lxc-build lptests /home/jenkins/.ssh/id_rsa
<StevenK> sudo: lp-setup-lxc-build: command not found
<StevenK> :-(
<wgrant> Is it in PATH?
<StevenK> It's in /home/jenkins/bin, but it looks like that doesn't work
<wgrant> ~/bin isn't in PATH by default
<StevenK> Well, yes
<LPCIBot> Project devel build #1092: STILL FAILING in 8.9 sec: https://lpci.wedontsleep.org/job/devel/1092/
<LPCIBot> Project devel build #1093: STILL FAILING in 28 sec: https://lpci.wedontsleep.org/job/devel/1093/
<StevenK> Haha
<StevenK> Need testr init first
<wgrant> Ooh
<wgrant> It nearly worked
<StevenK> Are you spying? :-)
<wgrant> Yes
<wgrant> How many threads does the instance have?
 * StevenK firewalls wgrant off
<StevenK> 4 processors, apparently
<wgrant> You'll want testr run --parallel --concurrency=SOMETHING --subunit --full-results
<wgrant> And you'll need to set a shared TEMP, which probably means it needs to be in the code dir
<wgrant> buildbot creates temp/ in the tree at the start of each build
<StevenK> Oooh
<StevenK> This is looking okay
<wgrant> Indeed
<wgrant> concurrency=8 is probably going to die
<wgrant> But we'll see
<StevenK> Die how?
<StevenK> We have 34GiB of RAM
<wgrant> It'll thrash
<wgrant> Ah, so at least RAM won't be a problem
<StevenK> Oh, yeah, java.
<wgrant> Also, your build failed
<StevenK> So we have 4GiB of RAM available
<wgrant> lazr.restful missing from download-cache?
<wgrant> buildbot's happy with it, so I assume you just failed to update
<LPCIBot> Project devel build #1094: STILL FAILING in 2 min 19 sec: https://lpci.wedontsleep.org/job/devel/1094/
<wgrant> Yeah
<wgrant> But it otherwise worked
<StevenK> I guess I need to run bzr pull in the download-cache
<wgrant> You'll want to add bzr up download-cache, and probably update-sourcecode, steps
<wgrant> But you can just do a one-off for now, I suppose
<StevenK> I don't need db setup?
<wgrant> lp-setup-lxc-build should do that
<StevenK> I thought so
<StevenK> Here's a script I prepared earlier
<LPCIBot> Project devel build #1095: STILL FAILING in 10 sec: https://lpci.wedontsleep.org/job/devel/1095/
<wgrant> Evidently not :)
<wgrant> StevenK: scripts/init_testr.py from the lpbuildbot branch may be handy
<wgrant> StevenK: It preserves .testrepository between runs, which makes balancing the tests between runners more effective
<wgrant> And prevents the issue that killed this build :)
<StevenK> Hmmm
<StevenK> Right
<StevenK> So far I'm blowing it away, but that can be fixed
<wgrant> This is looking better
<StevenK> Indeed
<StevenK> wallyworld: Are you watching too, or just ignoring us?
<wallyworld> huh?
<wgrant> Doing proper work, hopefully :P
<StevenK> This is proper work!
<wallyworld> watching what?
<StevenK> Also known as buildbot and buildbot-poll die in a large fire
<StevenK> Jenkins
<wgrant> StevenK: Check in temp/
<wgrant> Are there 8 files with lots of tests listed?
<StevenK> Yes
<wgrant> It's starting up 8 new containers, so it looks good
<wgrant> Great
<wgrant> I think we're good :)
<wgrant> Yay
<StevenK> We are
<wgrant> And it's even tagged properly
<StevenK> jenkins@domU-12-31-39-17-3C-7F:~/launchpad/lp-branches/workspace/devel$ uptime
<wgrant> I must work that out on prod buildbot with gnuoy next week
<StevenK>  01:22:17 up  3:08,  1 user,  load average: 6.70, 2.75, 1.14
<wgrant> :)
<wallyworld> wgrant: i recall reading somewhere why the test count is inflated now. can you remind me?
<wgrant> wallyworld: The Zope testrunner layer setup/teardowns appear as tests
<wgrant> eg 'test: lp.testing.layers.BaseLayer:tearDown'
<wallyworld> really?
<StevenK> I wonder how it will take with 8
<wallyworld> surely we can filter that out
<wgrant> If you grep them out then the count is accurate
<wgrant> StevenK: Didn't jenkins previously show live test stats?
<StevenK> It will show progress, not stats
<StevenK> But it takes like 3 or 4 builds to prime
<wgrant> :(
<wgrant> Yeah
<wgrant> Doesn't subunit2junitxml let it show live counts?
<StevenK> ENOIDEA
<wallyworld> wgrant: StevenK: if you want a break from jenkins, a quickie.... https://code.launchpad.net/~wallyworld/launchpad/embargoed-sharing-policy-ui-1055617/+merge/126585
<StevenK> 8 threads is probably what, 2 hours?
<StevenK> wallyworld: It's building
<StevenK> So now wgrant and I should do a critical or something
<wallyworld> do a review first :-)
<wgrant> I'm waiting for a local testr run too
<wallyworld> oh bollocks. legit bb failure
 * wallyworld fixes
<StevenK> Line 53 can be sucked back onto 47?
<StevenK> Which probably makes the branch neutral
<wallyworld> yeah
<StevenK> jenkins@domU-12-31-39-17-3C-7F:~/launchpad/lp-branches/workspace/devel$ uptime
<StevenK>  01:30:10 up  3:16,  1 user,  load average: 11.62, 9.77, 5.15
<wgrant> StevenK: Well, you did ask it to run 8 multiprocess test suites on 4 cores :)
<StevenK> I should have gone bigger?
<wgrant> Doesn't matter too much
<StevenK> Pft, we have 20GiB of RAM free
<wgrant> I'm not sure what yellow used for scalability testing, but we don't really need that here
<wgrant> We don't care about scaling, just working
<StevenK> It seems to work
<wgrant> Indeed
<wgrant> StevenK: You should probably steal the remaining build steps from master.cfg in the lpbuildbot branch
<wgrant> With scripts/init_testr and co
<StevenK> Aww, can't we just move on and get this on prase? :-P
<wgrant> Also shake Julian until MAAS Tarmac and Jenkins configs fall out!
<StevenK> I think other projects have used it as well
<StevenK> openstack is one I can remember. Until they switched to git, at least
<wallyworld> StevenK: you ok to +1 that branch you looked at?
<StevenK> wallyworld: Sorry, done.
<wallyworld> np thank you
<wallyworld> i was doing the testfix anyway till now
<lifeless> wgrant: pqm 0.6 up on LP, and in trunk.
<lifeless> wgrant: YMMV, may the farce be with U
<wgrant> Thanks
<wgrant> Of course I might just dump PQM and use Tarmac instead :)
<lifeless> fine by me
<lifeless> long as you're not running tests under it
<lifeless> tarmac isn't even faintly paranoid enough about *that*
<StevenK> Tarmac+Jenkins ?
<wgrant> Right, Tarmac + Jenkins is the sensible solution
<lifeless> though I don't know why you'd have tarmac in the picture for that.
<wgrant> Other projects (eg. maas) have you submitting to Tarmac, Tarmac asks Jenkins to build it, then Tarmac commits if Jenkins succeeds
<lifeless> you may not know this, but PQM can get its queue from LP
<lifeless> or could before the code team destroy the API :)
<lifeless> anyhow
<lifeless> there is something funky with that layering
<lifeless> I need to reset my whiteboard to make a case, i think
<wallyworld> do we know why TestArchiveWebservice.test_getAllPermissions_constant_query_count sometimes fails?
<wgrant> wallyworld: It might depend on whether it's the first browser test in that process
<wgrant> lifeless: Yeah, but Tarmac is at least less crufty and abandoned than PQM is today...
<bigjools> tarmac + jenkins is working extremely well for maas so far
<StevenK> bigjools: Are the configs available so we can duplicate it?
<StevenK> wallyworld: You fail. Again.
<wallyworld> huh?
<wallyworld> how?
<StevenK> Oh, the failure wasn't your fault.
<wallyworld> nope
<StevenK> Carry on
<wgrant> Hm
<wgrant> That subunit stream looks a little broken
<StevenK> wgrant: I wonder if bug 1020439 is limited to those few branches
<_mup_> Bug #1020439: AttributeError: 'NoneType' object has no attribute 'items'  in +preview-diff <code-review> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1020439 >
<wgrant> StevenK: Yes
<StevenK> Oh, they have no merge_diff ?
<wgrant> So assign to you and close
<wgrant> Oh oops, wrong bug
 * wgrant -> lunch
<StevenK> Haha
<StevenK> Helpful much
<wgrant> It may be the same, but I can't remember
<wgrant> And am on my way out
<StevenK> wgrant: It still happens
<StevenK> wget a URL from the OOPS gives 00
<StevenK> *500
<StevenK> The MP exists, and has a diff
<LPCIBot> Project devel build #1096: STILL FAILING in 1 hr 46 min: https://lpci.wedontsleep.org/job/devel/1096/
<StevenK> Wha?
 * StevenK prods Jenkins
<StevenK> Hm, it misreports the failure, too :-(
 * wallyworld has an appointment with the tax man :-(
<StevenK> wallyworld: To pay him?
<wallyworld> no, to figure out some of my shit for last year
<wallyworld> bbiab
<nigelb> Don't you pay him for that? :)
<lifeless> We don't pay him for his shit.
<lifeless> That would just be wrong wrong wrong
<nigelb> Heh
<StevenK> wgrant: Halp?
<StevenK> wgrant: bug 1020439 is triggered when previewdiff.diff.diffstat = None and I'm trying to figure out how to not make lazr.restful eat a bullet
<_mup_> Bug #1020439: AttributeError: 'NoneType' object has no attribute 'items'  in +preview-diff <code-review> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1020439 >
<lifeless> StevenK: does lazr.restful want diff to never be None ?
<StevenK> lifeless: Where is that defined?
<lifeless> the schema for the interface
<lifeless> I'm wagging here, of course
<LPCIBot> Project devel build #1097: STILL FAILING in 1 hr 46 min: https://lpci.wedontsleep.org/job/devel/1097/
<StevenK> Jenkins, you make me very sad.
<StevenK> lifeless: readonly=True, I'm not sure what the other defaults are
<lifeless> me neither
<StevenK> They are not set to required=True
<StevenK> So I guess they're False
<StevenK> _StringException: lost connection during test 'lp/registry/javascript/tests/test_milestone_creation'
<StevenK> Hm
<lifeless> StevenK: so - marshaller
<lifeless> StevenK: look at the marshallers available, I'll bet that its one with a bug in it
<StevenK> <class 'lazr.restful.marshallers.DictFieldMarshaller'>
<lifeless> StevenK: so a few lines up
<lifeless>         marshaller = getMultiAdapter((field, self.request), IFieldMarshaller)
<lifeless> that suggests that that is going off the rails, to me at least
<StevenK> lifeless: How?
<StevenK> The field is declared as an exported dict
<StevenK> And it's attempting to unmarshall the contents
<StevenK> It just doesn't deal with None at all
<lifeless> right
<StevenK> Right, if value is None: return {} works nicely
<StevenK> HAH
<StevenK>     def _get_diffstat(self):
<StevenK>         if self._diffstat is None:
<StevenK>             return None
<StevenK> GIGO
<lifeless> EWTF
<lifeless> how is that different to
<lifeless> return self._diffstat ?
<StevenK> Below that it returns a dict
<lifeless> ah
<StevenK> Fantastic, I don't need to touch lazr.restful
<StevenK> lifeless: So, can you look at the last Jenkins build?
<StevenK> lifeless: I have this inkling there is something screwy with the subunit stream
<lifeless> url me up
<StevenK> lifeless: https://lpci.wedontsleep.org/job/devel/lastBuild/
<lifeless> ERROR: cannot verify lpci.wedontsleep.org's certificate, issued by `/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA':
<lifeless>   Issued certificate has expired.
<StevenK> Yes
<StevenK> We should fix that by moving to prase
 * StevenK bangs that drum a little harder
<lifeless> StevenK: ok, so tricks:
<lifeless> cat consoleText| subunit-stats | less
<lifeless> page down till you see
<lifeless> Starting up the container...
<lifeless> after that you should see nothing as subunit will be eating it
<lifeless> when you start seeing something, its because subunit thinks a test prior to it has not finished
<lifeless> and is in pass-through mode on everything other than a terminal for that test.
<lifeless> so
<lifeless> test: lib/lp/soyuz/stories/ppa/xx-private-ppas.txt
<lifeless> is the first output
<lifeless> use that to seek in the raw stream to debug
<lifeless> less consoleText
<lifeless>  / lib/lp/soyuz/stories/ppa/xx-private-ppas.txt
<lifeless> and work back:
<lifeless> test: Could not communicate with subprocess
<lifeless> time: 2012-09-27 04:39:15.455646Z
<lifeless> test: lib/lp/soyuz/stories/ppa/xx-private-ppas.txt
<lifeless> ^ thats invalid yo
<StevenK> Could not communicate with subprocess is zope.testing garbage, isn't it?
<lifeless> yes, its odd that it says 'test: Could not communicate with subprocess'
<lifeless> theres no immediate evidence of interleaving going on
<lifeless> it *could* be a race condition with gc or something
<lifeless> or just bad code for handling that situation
<lifeless> e.g.
<lifeless> there is a reporter thingy in zope.testing
<lifeless> it has a special class for subunit
<lifeless> that class may have a bug
<lifeless> where it reports this situation via the literal 'test: Could not communicate with subprocess\n'
<lifeless> which would be a bug.
<StevenK> Then why doesn't buildbot see that :-(
<lifeless> it may not be encountering 'Could not communicate with subprocess'
<lifeless> or it may be one of the things gary keeps posting a bug link to
<lifeless> StevenK: s    def error_with_banner(self, message):
<lifeless>         self._emit_fake_test(message, self.TAG_ERROR_WITH_BANNER)
<StevenK> Haha
<StevenK> That does seem a little bit like crack, yes.
<lifeless> which calls startTest(test), _emit_tag(tag), addSuccess(test)
<lifeless> so, that should be ok, but..
<lifeless> and in fact..
<lifeless> test: Could not communicate with subprocess
<lifeless>  is line 108890
<lifeless> successful: Could not communicate with subprocess
<lifeless> is 108996
<StevenK> subunit doesn't like tests with whitespace?
<lifeless> so there is an interleaving problem
<lifeless> subunit doesn't care about that
<lifeless> open consoleText with vim
<lifeless> something wrote, to the same fd, a tonne of other test info between the three lines of that self._emit_fake_test function
<StevenK> wallyworld, wgrant: https://code.launchpad.net/~stevenk/launchpad/preview-diff-none-type/+merge/126601
<StevenK> lifeless: Yeah, the line numbers are staggeringly different
<lifeless> StevenK: part of the issue here is that you're getting the demultiplexed stream out of testr
<StevenK> testr run --parallel --subunit --full-results --concurrency=8 | subunit2junitxml -f -o test-results.xml
<lifeless> yeah
<lifeless> testr is running 8 streams on separate fd's and demultiplexing them.
<lifeless> its possibly a bug in your testtools version
<lifeless> what testtools and subunit versions are you running ?
<StevenK> ii  python-testtools                0.9.14+bzr267~ppa37~precise1    Extensions to the Python unittest library
<StevenK> ii  subunit                         0.0.8+bzr176~ppa126~precise1    command line tools for processing Subunit streams
<StevenK> Both from testing-cabal
<lifeless> hmmm
<lifeless> I have to run, cynthia time
<lifeless> suggestion
<lifeless> drop the subunit2junitxml -f -o test-results.xml for now
<nigelb> 54
<lifeless> and the --full-results and the --subunit
<nigelb> argh, sorry!
<lifeless> testr will write its output to .testrepository, the jenkins fs explorer thingy will let us pull the stream down and see what it gets
<lifeless> I will return in ~2 hours
<StevenK> Which is how long the build will take
<wgrant> StevenK: Did the build look successful other than the dead runner and corrupt stream?
<StevenK> wgrant: Mostly
<StevenK> I'm doing what lifeless' suggested, so we'll see
<StevenK> But since testr likes hiding things, we have no output at all
<wgrant> StevenK: Tail the stream
<wgrant> It's in ~/.testrepository
<wgrant> It'll be tmpFOO
<StevenK> Right
<StevenK> wgrant: Can haz review?
<wgrant> Er
<wgrant> Not ~/, but the tree
<StevenK> Yes, I found it
<StevenK> -rw------- 1 jenkins jenkins 3.4M Sep 27 06:22 .testrepository/tmpTDk8xw
<wgrant> StevenK: Nothing else relies on diffstat being None sometimes?
<StevenK> Hm, maybe
<StevenK> wgrant: Good catch. http://pastebin.ubuntu.com/1229847/
<wgrant> Well
<wgrant> This is interesting
<wgrant> I think our bugtracker may be sentient
<wgrant> https://bugs.launchpad.net/launchpad?field.searchtext=quote_like
<wgrant> Look at the first result
<wgrant> First thought was "these results are terrible". Open first result, "Cannot search for identifier containing underscores... well I can search for it but the results aren't any good."
<StevenK> Haha
<StevenK> wgrant: I can't see any other code that relies on diffstat being None
<wgrant> Did you consider making lazr.restful deal with it?
<StevenK> I did, and then decided it was a case of GIGO
<wgrant> Well, we allow object references to be nullable
<wgrant> Why not dicts?
<StevenK> Like you say, it could be fixed in lazr.restful's marshaller. But I decided that fixing LP was a little easier
<StevenK> And it didn't involve working out how to run its tests and then spinning a new release, uploading to pypi and download-cache and then making an LP branch anyway
<StevenK> If you strongly object then I can do that on Tuesday
<wgrant> StevenK: It's not that hard; wallyworld did it yesterday
<wallyworld__> and finished the job today
<StevenK> I know it's not hard. It's easier to just change LP.
<StevenK> wallyworld__: I don't think lp:lazr.restful contains your changes
<wallyworld__> hmm. i'm sure i merged, let me check
<StevenK> Hmm, yeah, revision 200
<wallyworld__> ah, merged restfulclient
<wallyworld__> forgot restful
<wallyworld__> let me do it now
<StevenK> The version.txt in the tree and pypi did not match
<StevenK> And I didn't want to unfix your carefully fixed bug
<wallyworld__> StevenK: done, sorry
<StevenK> https://code.launchpad.net/~stevenk/lazr.restful/dict-unmarshaller-none/+merge/126615
<wgrant> StevenK: Why isn't None None?
<wgrant> None shouldn't be {}
<wgrant> It should be None
<wgrant> probably
<StevenK> Well, it's better than what we have currently, which is AttributeError
<wgrant> Exposing an unstable interface in lazr.restful is not better than AttributeError :)
<wallyworld__> wgrant: StevenK: i had to reboot again after another unity crash and now lp.dev won't load in ff, but loads in chrome. "The connection was interrupted". any idea?
<StevenK> Stop stabbing zope while loading it in Firefox?
<wallyworld__> i have no knife
<wgrant> wallyworld__: Tried restarting Apache? That sometimes indicates it's SSL listening on a non-SSL port or vice-versa
<wallyworld__> wgrant: yeah, tried that
<StevenK> wgrant: Diff updated
<wgrant> StevenK: Have you tried this with lazr.restfulclient?
 * StevenK de-prams his own toys
<StevenK> wgrant: No, I haven't
<LPCIBot> Project devel build #1098: STILL FAILING in 1 hr 45 min: https://lpci.wedontsleep.org/job/devel/1098/
<StevenK> That isn't fun.
<adeuring> good morning
<jtv> Say... I don't have a working launchpad setup at the moment.  Would anyone be able to test & land this branch for me?  https://code.launchpad.net/~jtv/launchpad/format-relative-imports/+merge/124878
<stub> jtv: sending via ec2
<jtv> ?
<jtv> Oh, branch.  Thanks!
<stub> responsive r us
<tumbleweed> stub: talking of responsiveness, have a moment to eyeball https://code.launchpad.net/~stefanor/launchpad/edit-packagesets/+merge/124555 ?
<stub> tumbleweed: done
<tumbleweed> stub: thanks
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: jcsackett  | Firefighting: - | Critical bugs: ~300
<adeuring> jcsackett: thanks for your review!
 * adeuring nearly forgot the MP
<jcsackett> adeuring: you're welcome.
<lifeless> sinzui: https://bugs.launchpad.net/launchpad/+bug/736010 is affecting openstack
<_mup_> Bug #736010: Milestone:+index timeouts <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/736010 >
<lifeless> sinzui: wondering if one of your timeout demolishing machines could cast an eye over it.
<abentley> deryck: I'm getting a test failure on stable.  Both test and code are old.  Can you reproduce?  http://pastebin.ubuntu.com/1230926/
<deryck> abentley, let me see....
<lifeless> sinzui: oh, I see ttx is in #launchpad talking abou tit
<sinzui> lifeless, We have discussed that bug a lot. We think a lot of work is needed t fix this issue. This is a design problem, not a a bad query problem
<deryck> abentley, I don't get that failure.
<lifeless> sinzui: Why do you say its a design problem ?
<lifeless> sinzui: I see 2000ms of time between query 66 and 67 in https://oops.canonical.com/oops/?oopsid=OOPS-c3db3abe60cbad08100ecb38fcac389a#statementlog
<abentley> deryck: Wacky.  It looks legit to me, but it also doesn't seem to happen on ec2.
<deryck> WEIRD
<deryck> sorry to shout, fat fingers :)
<deryck> I wonder what's different for you that you see it?
<sinzui> lifeless, the page only works if you can display all milestones and blueprints. It does not scale. We can improve the queries, but it still will not scale for large projects. I think a proper fix is to load just the crucial/first items, then use ajax to complete the listings, then do the analysis.
<abentley> deryck: Maybe python version.  Are you on quantal 2.7.3?
<lifeless> sinzui: I am confused; the OOPS doesn't show queries as a problem at all.
<lifeless> sinzui: Are we talking about the same issue ?
<deryck> abentley, ah, no.  I still have upgraded actually. :(
<deryck> abentley, but I am on 2.7.3
<sinzui> yes we are, This bug has been around a long time and making queries faster does not fix the issue
<lifeless> sinzui: ok, so we're slightly in sync :) - I see bad python code / tal code.
<sinzui> You can fix that query, but it want users the believe you have fixed the issue for there hundreds of items, we need to think about the solution differently
<sinzui> YES
<lifeless> sinzui: I agree that doing latency hiding and incremental loading would be better.
<sinzui> Late evaulation that because the page relies on bug and blueprint rendering rules
<lifeless> sinzui: but is there not a low hanging just-be-more-efficient step to get Ubuntu and openstack unstuck ?
<lifeless> sinzui: its not late evaluation, only 68 queries on the page before it timed out .
<sinzui> I think we just want to pull the data and have the browser do the analysis...such as I do in the burndown charts I wrote
<lifeless> sinzui: those charts are sweet ;)
<sinzui> I don't believe the issue is low hanging. I have landed more than a dozen speed ups in 2 years. so have you and William
<sinzui> I asks jcsackett to not leap into that bug given the tremendous failure rate
<lifeless> hmm
<lifeless> loaded for me
<jcsackett> lifeless, sinzui: timeout fixed.
<lifeless> 69 queries in 6.83 seconds
<lifeless> jcsackett: how ?
<jcsackett> as i said, was increasing the wrong hard_timeout rule.
 * jcsackett misread the flags.
<jcsackett> the flag was for ProjectMilestone; we just now fixed milestone
<jcsackett> well "fixed" ;-p
<sinzui> lifeless, wgrant, jcsackett, and wallyworld__can discuss the effort to make that page properly fast for all project sizes in a few hours
<lifeless> sinzui: my curiosity is piqued
<lifeless> sinzui: I agree on the long term
<lifeless> but I'm wondering why the short term is so poor
<sinzui> certainty.
<sinzui> 1 day of effort to fix one bug is high certainty to deliver value
<sinzui> 5 days to fix 5 bugs is less certain, but equal value
<sinzui> 10 days to fix 1 bug is even less certain to deliver less value.
<sinzui> lifeless, we are a "machine" because we are taking the most certain bugs first. I asked jcsackett to not work on that one yet because there is more risk involved.
 * sinzui hoped to fix another escalated bug before having to do feature analysis to fix criticals
<lifeless> sinzui: all cool
<lifeless> sinzui: I meant, what about the code makes this one so poor
<lifeless> sinzui: not about your team or your choices ;)
<sinzui> we often choose to make pages do less, or batch. milestones do need to show all items. The tales calls are an embarrassment. I choose to reuse code to keep presentation consistent, but the adaptions are costly.
<sinzui> lifeless, the analysis is costly in Python I think. I know I can do it in JS now.
<lifeless> sinzui: I'm getting a profile
<lifeless> https://qastaging.launchpad.net/++profile++show/ubuntu/+milestone/ubuntu-10.10/+index#
<lifeless> just sneaked in: 3378720 function calls (3296251 primitive calls) in 19.845 CPU seconds
<lifeless> sinzui: there are some low hanging fruit that might make a lot of things better (or might be profile artifacts)
<lifeless>      5134    0.810    0.000    0.979    0.000 enumcol.py:39(__init__)
<lifeless> ^ 4% of total runtime, I believe wgrant has complained about enumcol performance before
<sinzui> yes
<lifeless> a few more like that
<sinzui> this page might break now that there are private bluerprints too. milestones do the private bugs query then cache the permissions, but I did not see such as change land for blueprints
<lifeless> yay
<lifeless> sinzui: the ubuntu timing out page is only 140k in size
<abentley> jcsackett: I have a sequence of four branches that need review.  Are you up for it?
<jcsackett> abentley: if said sequence starts with new-tests, i'm already looking at it.
<abentley> jcsackett: Excellent.  Continues with https://code.launchpad.net/~abentley/launchpad/storm-sprint-queries/+merge/126770 https://code.launchpad.net/~abentley/launchpad/specification-cleanup/+merge/126789 https://code.launchpad.net/~abentley/launchpad/hide-sprint-blueprints/+merge/126792
<jcsackett> abentley: cool. i can get 'em all.
<sinzui> jcsackett, do you have time to review https://code.launchpad.net/~sinzui/launchpad/email-authentication-errors/+merge/126801
<jcsackett> sinzui: sure, you're in the queue.
<jcsackett> still looking through abentley's series.
<sinzui> abentley, rick_h_. was the privacy banner or information portlets updated in the last few days
<sinzui> JS is broken on pages that show the privacy banne like bugs and archives
<abentley> sinzui: Yes, rick_h_ changed the banner code yesterday IIRC.
<sinzui> fab, maybe the diff will help me find the problem
<abentley> sinzui: (rick_h is away)
<sinzui> okay, diff it will be
<jcsackett> abentley: i'm through your series of branches. r=me on all but one which has a few questions.
<abentley> jcsackett: I've replied.
<abentley> jcsackett: Thanks!
<jcsackett> abentley: missed both things you pointed out. given those, r=me on that one as well.
 * jcsackett moves on to sinzui's.
* jcsackett changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: -  | Firefighting: - | Critical bugs: ~300
<sinzui> wallyworld__, If your waking: read this to learn what I have learned so far https://bugs.launchpad.net/launchpad/+bug/1057714
<_mup_> Bug #1057714: javascript is broken on pages that show the privacy banner <bugs> <javascript> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1057714 >
<wallyworld__> sinzui: haven't read that bug but i think it may be a dupe of mine from yesterday, for the mp ypu approved
<wallyworld__> mine is bug 1057248
<_mup_> Bug #1057248: javascript error on bugtask page <javascript> <regression> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/1057248 >
<sinzui> wallyworld__, does this look familiar: http://pastebin.ubuntu.com/1231240/
<sinzui> This is the change, but I do not know why info_type is not defined in the privacy module
<wallyworld__> sinzui: yes. i changed privacy.js and information_type.js
<sinzui> okay,
<wallyworld__> there were vrious issues - 'throw' was misspelt, lots of lint
<sinzui> ah@
<wallyworld__> plus the info_type issue
<sinzui> !
<sinzui> okay
<wallyworld__> landing my branch now
<lifeless> wgrant: enumcol would benefit from a cache I suspect
<lifeless> wgrant: one of the rare times I'll say that
<wallyworld__> we can deploy this morning
<sinzui> we can run the yui layer locally, then lp-land
<wallyworld__> sinzui: yes, doing that now
<sinzui> sorry wallyworld__I remember the diff, but I did not read all the details int he bug. I suck
<jcsackett> sinzui: r=me on your branch.
<sinzui> wallyworld__, I was rushing to review branches because I had a day trip to look at houses
<sinzui> thank you jcsackett
<wallyworld__> np
<cjwatson> wgrant: We've flushed nearly all the queue now following beta-2, and it all seemed pretty snappy; no timeouts in 80+ accepts.  At this point I'm confident with going ahead and removing the queue script.  Is there any remaining review you feel the need to do on https://code.launchpad.net/~cjwatson/launchpad/remove-queue-tool/+merge/114464 ?
<wgrant> cjwatson: Let me look
<wgrant> lifeless: Hmm
<wgrant> lifeless: I might try to profile it a bit harder now that someone other than me thinks it might be a problem.
<rick_h_> wallyworld__: man, so sorry. Just thought I added unused stuff. Tests passed, etc. I shouldn't have tried to rush that before I left
<wgrant> cjwatson: r=me. Are you also going to remove the feature flag check?
<wallyworld__> rick_h_: no problem. shit happens :-)
<rick_h_> wallyworld__: I owe you one. broke it apart and tried to stage it in nice simple bits that didn't get too involved and boom
<wallyworld__> rick_h_: we may need to look at the events - seems there are 2 sets (show/hide banner, info type public/private) that do the same thing. may be able to be refactored to just one set
<rick_h_> wallyworld__: well so I can explain that
<wallyworld__> i didn't get into it too far
<cjwatson> wgrant: That's going through EC2 at the moment (https://code.launchpad.net/~cjwatson/launchpad/pabj-remove-feature-flag/+merge/126090)
<rick_h_> because the filbug.js uses the privacy banner directly with a custom message, you need to be able to talk to the privacy banner with a custom message
<wgrant> cjwatson: Ah, great
<wgrant> I have a fair bit of MP mail; haven't quite caught up this morning yet
<cjwatson> Yep.  Thanks.  I look forward to my giant LoC credit
<rick_h_> wallyworld__: but the normal use case is that someone changes the information_type widget, which fires the information_type:changed, and files information_type:is_public/private and the banner will auto show/hide based on that event
<cjwatson> And I haven't even removed delayed copies yet ...
<rick_h_> wallyworld__: so there's really two use cases and almost should be a different banner, since privacy and security are sharing code tbh
<lifeless> wgrant: there is a kcachegrind file for you
<wallyworld__> rick_h_: ok, thanks for the explanation
<wallyworld__> my main aim was to add the missing tests and get the fix out
<rick_h_> wallyworld__: and in the next branch the banners will render themselves vs the html being in the .pt file, so the events will be used as ways to say "need a banner html setup here"
<wallyworld__> cool :-)
<rick_h_> wallyworld__: right, understand. and it's not 100% tested because it's part 1 of 4 and in general this was 'new unused' code since nothing is firing the events yet
<wallyworld__> rick_h_: one thing. i had to move the info_type namespace variable from the top of the module or else it was undefined
<wallyworld__> i don't know why
<rick_h_> wallyworld__: so like I said appreciate it. Been offline most of the day on vaca so bummed to log in and see I did wrong for you guys
<rick_h_> wallyworld__: hmmm, let me look
<wgrant> lifeless: But it's from qastaging, so it's not completely useful
<wgrant> Not useless, though
<lifeless> not useless
<rick_h_> wallyworld__: ok that's strange. I'll check it out when I get to the follow up branch when I get back
<wgrant> rick_h_: Missing context here, but we only recently moved the banners *into* the HTML, to avoid them popping into the page later on once the JS loads.
<wallyworld__> rick_h_: thanks. i didn't get into the root cause. i'd love to know why
<rick_h_> wallyworld__: nothing looks odd, but running on 3hrs sleep after driving 600+ miles overnight
<wallyworld__> rick_h_: where did you drive from/to?
<rick_h_> wallyworld__: https://maps.google.com/maps?saddr=clarkston,+mi&daddr=Charlottesville,+VA&hl=en&sll=37.6,-95.665&sspn=38.593229,86.396484&geocode=FRAWjAIdYh8H-ymTC47xX5ckiDGKYHxzNWKthw%3BFfpHRAIdeopS-ymPpFDqLYaziTH8dIvDlvCGkA&oq=charlottesvi&mra=ls&t=m&z=6
<rick_h_> doh
<wallyworld__> looks like a nice drive
<rick_h_> wgrant: yea, I'll hopefully be able to take care of that still. The big thing is we need banners on more places and it takes a bunch of code to wire it up it seems. Trying to split it into contained parts
<rick_h_> wgrant: for instance trying to not have the privacy banner need to know about the information type, LP.cache locations, etc.
<wgrant> Indeed.
<rick_h_> wgrant: but thanks for the heads up. I didn't realize it was moved due to a flash effect so good to keep an eye on
<rick_h_> wallyworld__: yea, well with a 2yr old those overnight drives still the best so he sleeps through most of it. Thanksfully we also had the lion king movie soundtrack for backup lol
<wallyworld__> ah, those were the days. long gone for me now
<wallyworld__> rick_h_: wgrant still listens to the Lion King for his beddy byes time
<wgrant> Heh
<rick_h_> hah
<lifeless> wgrant: the other thing is there is a huge amount of content being re-rendered
<lifeless> wgrant: a simple static result cache for rendering of person priority importance status might help a great deal.
<wgrant> We can possibly just also make that not terrible
<lifeless> or do both
<lifeless> evaluating the same template with the same parameters in the same request to the same bytes seems non horrible to me
<wgrant> Says he who removed template fragment caching :P
<wgrant> (yes, yes, it was the wrong way to cache, but blah)
<wgrant> :)
<lifeless> I'm not against caches /per se/
<wgrant> wallyworld__: qas is updated, if you want to check out the JS stuff
<wgrant> Not sure why it's [testfix]
<wallyworld__> finally, been waiting
<wallyworld__> wgrant: because db bb was borked and i needed to get it landed
<wallyworld__> we should fix that
<wgrant> wallyworld__: In that situation you should force the build and wait 5 minutes
<wgrant> [testfix] skips all QA
<wallyworld__> ok
#launchpad-dev 2012-09-28
<lifeless> fun - OpenSSL: error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol
<lifeless> Unable to establish SSL connection.
<rick_h_> wallyworld__: so just an fyi along the lines of what I was thinking. https://pastebin.canonical.com/75528/ is where I'd head to try to make sure the privacy.js is decoupled from the information_type.js aside from listening to the event.
<lifeless> erm wtf
<lifeless> telnet> open 10.0.3.24 443
<lifeless> Trying 10.0.3.24...
<lifeless> Connected to 10.0.3.24.
<lifeless> Escape character is '^]'.
<lifeless> HELO
<lifeless> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<lifeless> <html><head>
<lifeless> <title>501 Method Not Implemented</title>
<lifeless> :)
<wallyworld__> rick_h_: looks ok at first glance. the get_banner_text function can probably be taken off the namespace now with these changes
<lifeless> right, thats better.
<rick_h_> wallyworld__: right, not complete
<rick_h_> wallyworld__: but I wanted to kind of clear up the idea/where I'm trying to head to make sense of it more
<lifeless> whoever had that apache not working to lp.dev before, if you're using lxc etc, make sure your apache config is listening on *:443, not 192.160.0.88:443
<wgrant> lifeless: I added a feature to Makefile to do that, which I added to the LP LXC docs
<wallyworld__> rick_h_: looks ok so far but i probably need to get into the code a little more. i'd run your changes by jc since he did some banner work a few months ago
<lifeless> wgrant: I was giving the lp-setup inline docs a spin
<lifeless> wgrant: they are incomplete
<rick_h_> wallyworld__: yea, honestly I'm afk for a week so I'd not worry about it too much. Just hoping to make me seem les insane
<lifeless> (because it goes for test-suite capability)
<wallyworld__> rick_h_: np. it's all good
 * rick_h_ swears he's not lost it yet 
<wgrant> lifeless: Right
<lifeless> how do I set up the combo loader stuff ?
<wgrant> lifeless: Should just need to set 'js.combo_loader.enabled default 0 true'
<wgrant> May need to make combobuild, but the usual targets should do that
<rick_h_> lifeless: which part? the actual hosting bit? or just enabling?
<lifeless> I have a fresh lxc
<lifeless> I've run lp-setup update
<lifeless> and sudo make install
<rick_h_> then it should be setup to combo build ootb. I thought the combo loading FF was on by default.
<lifeless> I'm getting reference errors
<lifeless> [13:14:08.562] ReferenceError: YUI is not defined @ https://launchpad.dev/product-name-100011/+milestone/unique-from-factory-py-line878-100017/+index:53
<lifeless> [13:14:08.562] ReferenceError: LPJS is not defined @ https://launchpad.dev/product-name-100011/+milestone/unique-from-factory-py-line878-100017/+index:110
<wgrant> Check your browser's HTTP request log
<rick_h_> lifeless: make combobuild ?
<lifeless> [13:14:08.330] GET https://launchpad.dev/+combo/?yui/yui/yui-min.js&lp/meta.js&yui/loader/loader-min.js [HTTP/1.1 200 OK 226ms]
<wgrant> Aha
<wgrant> Go to that URL
<wgrant> It probably says "missing" everywhere
<lifeless>  /* yui/yui/yui-min.js */
<rick_h_> and if it's missing then check build/js/...
<lifeless>  /* [missing] */
<rick_h_> which is what combobuild does
<lifeless>  /* lp/meta.js */
<wgrant> Yeah, make combobuild would be my suggestion
<lifeless> make run doesn't do it ?
<wgrant> Perhaps lp-setup uses a custom target that doesn't include it
<wgrant> It should...
<lifeless>  make combobuild
<lifeless> utilities/js-deps -n LP_MODULES -s build/js/lp -x '-min.js' -o \
<lifeless>         build/js/lp/meta.js >/dev/null
<lifeless> utilities/check-js-deps
<rick_h_> and jsbuild_watch which will should get lined up with combobuild
<lifeless> ctrl-refresh, same stuff in that url
<wgrant> Hm
<wgrant> make inplace
<lifeless> there are a lot of LP modules present
<rick_h_> lifeless: anything in build/js?
<lifeless> its not an empty combo response
<wgrant> Oh
<lifeless> var LP_MODULES = (function(){
<wgrant> Do you have a YUI version flag set?
<lifeless> f'r instance
<lifeless> no
<lifeless> neither does qastaging
<wgrant> Right, it's not necessary
<rick_h_> LP_MODULES is from the build/js/lp/meta.js so that's a good sign
<wgrant> lifeless: Does the /srv/launchpad.net/convoy symlink point to a reasonable location?
<rick_h_> lifeless: so is there anything in build/js/yui ?
<rick_h_> maybe some failure to get that dep right?
<lifeless> lrwxrwxrwx 1 robertc robertc 59 2012-09-28 01:18 convoy -> /home/robertc/source/launchpad/lp-branches/working/build/js
<lifeless> ls build/js/yui
<lifeless> yui-3.3.0  yui-3.5.1
<wgrant> So that's all fine. Must be a buildout issue
<wgrant> Huh
<wgrant> yui should be a symlink to yui-3.5.1, shouldn't it?
<lifeless> there are two instances of 'missing' in the https://launchpad.dev/+combo/?yui/yui/yui-min.js&lp/meta.js&yui/loader/loader-min.js response AFAICT
<rick_h_> no, should have build/js/yui symlink to 3.5.1
<rick_h_> lifeless: right, yui-min.js and load-min.js are coming from the yui libary
<rick_h_> https://launchpad.dev/+combo/?yui-3.5.1/yui/yui-min.js&lp/meta.js&yui-3.5.1/loader/loader-min.js will work since you have that dir
<wgrant> Is build/js/yui a symlink?
<rick_h_> but you should have the yui symlink to yui-3.5.1 as the 'default' yui version and that's missing somehow
<rick_h_> wgrant: right
<lifeless> build/js$ ls -ld yui
<lifeless> drwxr-xr-x 2 robertc robertc 4096 2012-09-28 01:18 yui
<lifeless> its a directory not a symlink
<rick_h_> lifeless: so yea, that's the issue
<lifeless> rm it ?
<rick_h_> no, you need it, it needs to be the symlink, loading up my lxc to look at what makes that symlink sec
<wgrant> On my lpsetup-created instance it's a symlink as expected
<lifeless> well, this is bind mounted
<lifeless> as you'd expect
<lifeless> I've had this working tree for yonks
<wgrant> Ah, so it's an existing checkout?
<wgrant> Right, so I'd make clean_buildout build
<lifeless> of course
<rick_h_> right, clean it up and rerun then
<rick_h_> right, combo-rootdir will do the symlink  if it doesn't exist. Since you have a directory it's failing to generate it
<rick_h_> not sure how you got the directory there, but that's causing it to fail. a clean_buildout and make should work
<lifeless> ok, thats a lot bigger
<lifeless> still funky
<lifeless> 1000 unassigned bugs is 11 seconds to render
<lifeless> thats very interesting
<wgrant> Bugs and people have a few enums
<lifeless> I get Y.lp is undefined still
<wgrant> Any [missing]s?
<lifeless> yes
<lifeless> between meta.js and yui/loader/loader-min.js */
<wgrant> So meta.js is missing?
<lifeless>  /* lp/meta.js */
<lifeless>  /* [missing] */
<lifeless> needed a make combobuild in that recipe you gave me
<lifeless> 5.56 seconds now
<lifeless> so the 10K was noise of some sort
<lifeless> e.g. sitting on battery ;)
<lifeless> 40% time reduction neuterin the tal in lib/lp/registry/templates/milestone-macros.pt
<lifeless> ah, late eval queries
<lifeless> storm cache strikes again I bet.
 * lifeless looks for the hammer
<wgrant> storm_cache_size
<wgrant> configs/development/launchpad-lazr.conf
<lifeless> yeah
<lifeless> do you remember the prod size?
<lifeless> [and why can't we just toss the damn thing..]
<wgrant> 10000 I think
<wgrant> We need *a* size
<lifeless> well
<lifeless> why?
<wgrant> At least for scripts
<lifeless> we discard the cache after every request
<wgrant> Sure, for the webapp the limit can be quite ridiculous
<lifeless> set a ulimit for scripts, so ones that try to do too much in one pass can fail hard
<wgrant> For scripts it might want to be more sensible.
<lifeless> or just have a non-discarding cache with a low fixed limit for scripts
<wgrant> Hm
<wgrant> Why do we still have two storm_cache_size keys...
<wgrant> I thought I removed all the duplicates
<lifeless> 2.5 seconds with minimal td entries
<wgrant> What'd you change?
<lifeless> neutered all the bug data access
<wgrant> Ah
<lifeless> getting a baseline for doing that many td rows
<lifeless> 2.7 seconds with the first cell filled in
<lifeless> same amount of HTML output
<lifeless> running several times and taking min of course
<lifeless>           <td class="icon left">
<lifeless>             <span class="sortkey" tal:content="bugtask/bug/id" />
<lifeless>             <span tal:content="structure bugtask/image:icon" />
<lifeless>           </td>
<lifeless> ^ 0.2 seconds over 1000 rows
<lifeless> vs
<lifeless>           <td class="icon left">
<lifeless>             <span class="sortkey" tal:content="bugtask/bug/id" />
<lifeless>           </td>
<wgrant> So, while I clean up this storm_cache_size stuff I think I might remove the development override
<wgrant> It doesn't make much sense
<lifeless> +1
<wgrant> We keep having to work around it in tests
<wgrant> Heh
<wgrant> In fact, the main tests that override the limit are for ProjectMilestone:+index...
<lifeless> wgrant: where is structure defined
<wgrant> lifeless: In templates?
<wgrant> Or in our Python?
<wgrant> It's a TAL keyword; it's not defined as such anywhere
<lifeless> the implementation
<lifeless> emitSubstitution in talgenerator.py - closing in on it
<wgrant> Right, it's in zope.tal
<wgrant> Or chameleon if the page uses that
<wgrant> But I believe that one's still zope.tal
<lifeless> def do_insertStructure_tal(self, (expr, repldict, block)):
<lifeless> whoa
<lifeless> 18K permission checks
<lifeless> I /really/ want to rip that out entirely
<wgrant> We would need a pretty significant rewrite for that to work
<wgrant> Plus the checks should be mostly cached, so very very fast
<lifeless> 5.5K calls are to block implicit flushes, block implicit flushes makes 18K calls to checkPermission
<wgrant> "makes"
<wgrant> It's a decorator
<lifeless> I know
<wgrant> Ah :)
<lifeless> there are getattr's
<lifeless> that are blocking flushes
<lifeless> and checking permissions
<lifeless> 5.5% of runtime in that stack
<lifeless> so - 'very very fast' - not so much
<lifeless> ahha
<lifeless> wgrant: low hanging fruit:
<lifeless> _get_sqlobject_store
<lifeless> wgrant: spot what it does
<wgrant> The import could be a problem if we were multithreading, but we're not really...
<lifeless> also block_implicit_flushes is bad too
<lifeless> wgrant: its a lock
<lifeless> wgrant: synchronisation primitives are not that cheap
<wgrant> Sure
<lifeless> wgrant: also, prod runs two threads - xmlrpc + http
<lifeless> so we are
<wgrant> But does the profile show that's an issue?
<mwhudson> importing even existing modules in a tight loop is surprisingly slo
<mwhudson> w
<wgrant> Right, and the xmlrpc cohabitation is the root of most of our annoying undiagnosable issues
<StevenK> mwhudson: Namespacing causes problems, news at 11?
<wgrant> Not namespacing...
<lifeless> wgrant: http://paste.ubuntu.com/1231593/
<wgrant> Indeed
<wgrant> Although I'd prefer to look at untangling the imports, that should work
<lifeless> wgrant: its about 300ms over the request.
<lifeless> wgrant: from a quick timeit + back of napkin
<wgrant> Hm
<wgrant> I've seen _get_sqlobject_store show up before in profiles, but hadn't actually looked at it as there were other dominating factors to fix first
<wgrant> But I haven't profiled in several months
<wgrant> Anyway, storm_cache_size is now 10000 everywhere in devel
<wgrant> I meant to do that as followup to my DB config rework branches last year
<wgrant> Or whenever it ws
<wgrant> But never got around to it, apparently
<bigjools> how often is process-upload running these days?
<lifeless> ok so its hard to tell
<lifeless> but it looks like it saved 100ms
<lifeless> wgrant: ^ if you want to do it at some point
<lifeless> I've got to context switch here
<lifeless> hard to tell because of the massive variance
<wgrant> bigjools: */5 for sources
<wgrant> lifeless: Yeah, and it really really depends on the page whether it's a big issue
<wgrant> I might try untangling that stuff
<lifeless> it would be great to make imports barf
<lifeless> install an import hook
<bigjools> ta
<lifeless> hmmm, dunno if cached imports would trigger
<wgrant> lifeless: We have a lot of inline imports, so we can't do it generally
<lifeless> wgrant: we could set a cap
<lifeless> wgrant: 500 imports in a request, then boom.
<wgrant> Yeah
<lifeless> that would be about 5ms
<lifeless> more or less
<wgrant> I was initially thinking we could do a per-import cap
<wgrant> But as you say, I'm not sure it'll actually trigger on repetition
<wgrant> Maybe
<lifeless> I'm not sure it will trigger at all
<lifeless> we could hack the bytecode
<lifeless> but folk might consider that objectionable
<wgrant> Heh
<wgrant> Or we could just ban inline imports in lp.services.webapp...
<mwhudson> __import__ is called for cached imports
<mwhudson> says science
<lifeless> mwhudson: tried monkey patching it ?
<lifeless> mwhudson: and we were actually speculating about pep whatsisthing hooks
<mwhudson> oh
<mwhudson> yeah, i just overwrote __builtin__.__import__
<mwhudson> dunno about the hooks
<lifeless> anyhow replacing __import__ with a thread-local-counting abomination would be effective.
<lifeless> mwhudson: want to write one
<lifeless> ?
<mwhudson> i suppose i could try
<mwhudson> where would the output go?  same place as the query count?
<lifeless> mwhudson: Oh, I was thinking super simple: Raise a Mother* exception  :)
<mwhudson> oh, when it crosses 500 or something?
<lifeless> mwhudson: needs a call to install it, probably one to uninstall it, a per-thread 'request starting, kill me after X imports', and 'request finished, don't kill me anymore'
<lifeless> mwhudson: ^ is how I would do it.
<lifeless> http://pypi.python.org/pypi/pyjack/ is kindof related
<lifeless> mwhudson: might want a fifth call to change the threshold mid-request
<wallyworld__> wgrant: if you want to look https://code.launchpad.net/~wallyworld/launchpad/duplicate-bug-warning-xss-1057630/+merge/126849
<lifeless> mwhudson: would let us featureflag it
<lifeless> mwhudson: hmm, could minimise down to 4 calls: - install/uninstall/reset_count/set_threshold(None-or-an-int)
<lifeless> mwhudson: make the set an attribute access, and you've got the ability to read-back too, for oops integration if we care.
<mwhudson> lifeless: i guess there isn't a bug for this?
<lifeless> nup
<lifeless> man, I can't get used to this fast ->dbstable bb :)
<mwhudson> how do you guys set things up so you can access launchpad running in an lxc from outside it?
<mwhudson> is it just a matter of putting the right bits in /etc/hosts outside the container?
<wgrant> wallyworld__: Might it be worth mustaching this instead? This still injects dup_id directly, which is only safe today because of constraints we place on this particular piece of data
<wgrant> mwhudson: Right, Makefile takes a variable to make Apache listen on *, and then I drop stuff in /etc/hosts
<mwhudson> make install LISTEN_ADDRESS=* ?
<wgrant> Should be on https://dev.launchpad.net/Running/RemoteAccess
<wgrant> But that looks like it
<mwhudson> seems to be
<mwhudson> ProgrammingError: function pg_last_xact_replay_timestamp() does not exist ?
<mwhudson> oh
<wgrant> You fail at 9.1
<mwhudson> i probably haven't updated launchpad-dependencies in the container for eons
<wgrant> Yeah
<mwhudson> The following packages have been kept back:
<mwhudson>  ... launchpad-database-dependencies
<mwhudson> hm
<wgrant> dist-upgrade?
<mwhudson> oh right
<mwhudson> yes, seems happier
<wgrant> Then you'll probably want to purge 8.4, then drop and recreate the 9.1 cluster to get it on port 5432
<wgrant> Then rerun utilities/launchpad-database-setup and all will be good
<mwhudson> ah yes
<StevenK> lifeless: I think db-stable should die. It's not clear what should happen to db-devel, but it's awfully heavyweight for what we want it for.
<mwhudson> i guess what's actually going to happen here is that i'll get to the point where i could do some launchpad development
<lifeless> StevenK: how would you assess 'db and code work well together' ?
<mwhudson> and then it'll be time to go home
<StevenK> mwhudson: Are you coming back to us?
<mwhudson> StevenK: not formally :)
<StevenK> mwhudson: Oh, so you're going to tease us with a few bug fixes? :-)
<mwhudson> i would still like to kill the branch puller
<StevenK> Can you kill the branch scanner too?
<mwhudson> Get:68 http://archive.ubuntu.com/ubuntu/ lucid-updates/main libmysqlclient16 5.1.63-0ubuntu0.10.04.1 [1,898kB]
<mwhudson> whut
<mwhudson> the path to that is less clear i think
<StevenK> mwhudson: stub had a pretty brilliant idea, I thought
<StevenK> mwhudson: A DB backend for bzr so when you push a branch, it directly hits the DB, no muss, no fuss
<mwhudson> ah yeah
<stub> I thought I was trolling?
<mwhudson> i think i first heard that idea from mark, actually :-)
<mwhudson> i don't know if he was trolling either
<mwhudson> it would be awesome, but also a great deal of work
<lifeless> bzr is a db
<stub> In theory, it is a great idea.
<stub> yeah, what he said
<lifeless> so, ITYM *another* DB backend
<StevenK> Fine, a *postgresql* backend
<mwhudson> create table versionedfile (...)
<mwhudson> what could go wrong
<wgrant> So then the question becomes "oh god why"
<mwhudson> Configuring postgresql.conf to use port 5433...
<mwhudson> oy you
<wgrant> Did you purge 8.4 and drop the existing 9.1 cluster?
<mwhudson> yes
<wgrant> :(
<mwhudson> oh
<mwhudson> maybe i didn't purge all of 8.4
<stub> yeah, oh
<mwhudson> ok, that's better
<mwhudson> woo
<jtv> stub: looks like my format-relative-imports branch didn't come through.  :(  I got the EC2 success message, but no landing.
<mwhudson> um
<mwhudson> the importfascist still exists?
<wgrant> Yes.
<wgrant> It doesn't do very much
<wgrant> But it still exists
<wgrant> And someone angered it earlier this week
<stub> jtv: I'll try the landing step again. I too got the success message.
<wgrant> stub, jtv: We were in testfix for several hours
<wgrant> Probably got caught in that
<mwhudson> database_root = 'canonical.launchpad.database'
<stub> jtv: Do you have the mp url handy?
 * mwhudson spots some dead code
<mwhudson> oh yay, bootstrapping
<jtv> stub: https://code.launchpad.net/~jtv/launchpad/format-relative-imports/+merge/124878
<mwhudson> heh
<mwhudson> https://code.launchpad.dev/applets -> 522 imports
<mwhudson> or 1713 for the first request after app server startup :)
<wallyworld__> wgrant: i could look at mustache i guess. we know the id is an int, so i saw no need to do anything special with it
<mwhudson> lol what
<mwhudson> one of the main offenders is get_current_browser_request doing "from zope.security.management import queryInteraction" inline
<mwhudson> which is probably only to keep lazr.restful from unconditionally depending on zope ?
<lifeless> wallyworld__: trusting the integrity of over the wire data is risky
<wgrant> mwhudson: Heh
<lifeless> mwhudson: lazr.restful shoul always depend on zope
<wallyworld__> i guess i need to be more paranoid
<wgrant> lifeless, wallyworld__: It's not so much the integrity of the wire. It's the fact that changing something on the server will subtly make unnecessarily fragile client code vulnerable
<lifeless> mwhudson: the folk making it work for django were being optimists
<mwhudson> yes
<lifeless> wgrant: I didn't talk about integrity of the wire :)
<lifeless> wgrant: and yes, I agree.
<mwhudson> i think reality has won there now?
<lifeless> mwhudson: yes
<lifeless> mwhudson: if it were to be made separate, it would need to be several more separate projects with callbacks etc
<wgrant> wallyworld__: eg. in a tonne of places today we inject URLs containing product names unescaped, because people thought it should be safe
<wgrant> wallyworld__: It's a reasonable assumption, except that it means we have to be really really ultra-paranoid about project names
<wallyworld__> sure, but a name is not an integer
<wgrant> Because if a quote gets in one somehow, we're fucked
<wgrant> wallyworld__: Bugs have nicknames that are used in some situation
<wgrant> Eg. bug gbcw
<wgrant> Or did we remove them, I can't remember.
<wgrant> http://launchpad.net/bugs/gbcw :)
<wgrant> Anyway
<wgrant> Client code shouldn't be unnecessarily fragile
<wgrant> Partly because it's possible it'll change
<wgrant> But mostly because people will copy it
<wgrant> And an argument that people *won't* copy it isn't really valid here, since someone clearly did copy this from elsewhere :)
<wgrant> Launchpad is really good at convincing people to copy code :(
<wallyworld__> wgrant: changes pushed
<wgrant> wallyworld__: That looks much safer and even shorter, thanks.
<wgrant> _show_comment_on_duplicate_warning still needs the same treatment, though
<wallyworld__> np, thanks for the suggestion
<wallyworld__> ah, ok, bug id
<wallyworld__> will do
<wgrant> The mustache implementation isn't precisely fast, but it should be more than fine for a dialogue like this
<wgrant> wallyworld__: Well, you also extracted the title setting
<wgrant> So you can merge that back in and save a line
<wgrant> As well as handling bug_id paranoidly
<wallyworld__> yeah, i extracted it because it failed too
<wgrant> Indeed, thanks for finding that one.
<stub> wgrant, lifeless: Can you think of why Deryck needs this index, when we didn't need similar ones for bug_sharing_policy and branch_sharing_policy?
<stub> https://code.launchpad.net/~deryck/launchpad/product-specification-sharing-policy-idx-1057617/+merge/126728
<wgrant> stub: No. It's possible it's for a garbo job, but I thought that was already done.
<wgrant> So I'm not quite sure what's going on there
<wgrant> It may be for adding a NOT NULL constraint or something like that
<wgrant> (and also we established that for a product garbo job it's not worth it)
<stub> Right. In which case a partial index might be preferable, but whatever
<mwhudson> ok
<mwhudson> boringly, i can report that most of the inline imports are in zope.tal :(
<lifeless> mwhudson: really? FAARK
<wallyworld__> wgrant: right, done
<wgrant> mwhudson: In, or inside?
<lifeless> mwhudson: cause, thats not peformance sensitive or anything
<mwhudson> err
<mwhudson> actually
<mwhudson> pause that thought :)
<wgrant> wallyworld__: Safer and two lines shorter. r=me. Thanks!
<wallyworld__> thank you
<mwhudson> wgrant, lifeless: for your confusion: http://pastebin.ubuntu.com/1231712/
<wgrant> Rather odd.
<mwhudson> if it 'helps'
<mwhudson> _entnd_re = re.compile('&(#[0-9][0-9]*)(?![0-9;])')
<mwhudson> i think the only conclusion possible here is that python is terrible?
<lifeless> mwhudson: wtf is that doing importing ?
<wgrant> Hm
<wgrant> See _sre.c's call func
<wgrant> Oh, that's just the module
<wgrant> nevermind
<lifeless> thats compiled already
<lifeless> tal doing string joining won't be helping
<lifeless> a list accumulator form of it would help I suspect
<mwhudson>             /* not a literal; hand it over to the template compiler */
<mwhudson>             filter = call(
<mwhudson>                 SRE_PY_MODULE, "_subx",
<mwhudson>                 PyTuple_Pack(2, self, ptemplate)
<mwhudson>                 );
<mwhudson> from _sre.c
<wgrant> Oh
<wgrant> Indeed
<mwhudson> aaasd
<mwhudson> is firefox super crashy for anyone else in precise currently?
<wgrant> It's fine for me
<mwhudson> hm
<wgrant> Though I've run with Firebug disabled since the globalmenu issues
<mwhudson> i guess my profile has eaten itself somehow
<mwhudson> ah yea
<mwhudson> firebug got me for a while too
<mwhudson> anyway, on that depressing note, home time
<wgrant> :)
<wallyworld__> wgrant: another one https://code.launchpad.net/~wallyworld/launchpad/confirmation-dialog-xss-1057901/+merge/126855
<wgrant> Ah right
<wgrant> wallyworld__: r=me
<wallyworld__> thanks
<wgrant> IStoreSelector and co really have quite a few callsites
<lifeless> ...
<StevenK> Destroying SQLBase and SQLObject sounds rather more fun
<wgrant> Not destroying
<wgrant> Just moving
<wgrant> To disentangle the import that lifeless was working around
<StevenK> wgrant: Maybe you could destroy Storm and switch to SQLAlchemy
<wgrant> Heh
<wgrant> There we go
<wgrant> Circular imports gone
<wgrant> Without global hacks :)
<StevenK> Blink
<StevenK> How horrible is the diff?
<wgrant> Only about 4000 lines
<wgrant> Net -10 :)
<wgrant> lib/lp/services/job/celeryjob.py:        from lp.services.job.celeryjob import CeleryRunJob
<lifeless> wgrant: !
<adeuring> good morning
<lifeless> speaking of long requests
<lifeless> https://oops.canonical.com/oops/?oopsid=OOPS-ddb3a4e6e473461ac93b92604efcb918
<lifeless> wheee
* adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring  | Firefighting: - | Critical bugs: ~300
<czajkowski> mgz: is this possible ? https://answers.launchpad.net/launchpad/+question/209652
<mgz> czajkowski: dependency resolution doesn't care about where packages come from
<mgz> I'm not sure of bzr-builder needs extra config to look at ppas, will have a quick look
<mgz> so, I don't think you can do remote recipe builds that need things from ppas, but it should just work locally
<mgz> there might be specific launchpad configuration for that, generally just the main archive and sibling packages in the current ppa get used when building
<czajkowski> mgz: ah ok
<mgz> it's not clear from the question exactly what hes trying to do
<mgz> but there's probably a way to do it :)
<czajkowski> mgz: thank you
* bac changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: adeuring,bac  | Firefighting: - | Critical bugs: ~300
<bac> hi adeuring.  nothing in the review queue today.  \o/
<tumbleweed> so, what happens after my merge proposal is approved? I assume someone needs to run the test suite and land the branch?
<cjwatson> tumbleweed: Yes - I can land it for you now if you think it's ready
<cjwatson> tumbleweed: Unless you want to add more tests per stub's comment
<tumbleweed> the questions that lead to that comment were more about LP style than anything else
<tumbleweed> but yes, I suppose I did intend to add tests after finding out how I was supposed to handle it
<cjwatson> tumbleweed: Could you set a commit message too?
<tumbleweed> cjwatson: does it need to be in a particular format?
<cjwatson> No, just a description.
<tumbleweed> will do
<cjwatson> The tools will add necessary metadata to it.
<cjwatson> So let me know once you're happy with the test coverage ...
<czajkowski> jcsackett:  can you look at https://answers.launchpad.net/launchpad/+question/209247  please
<jcsackett> czajkowski: sorry, that one's outside the realm of what i can parse--i haven't done anything with packaging. :-/
<jcsackett> czajkowski: looks like wgrant is helping them out so far though.
<czajkowski> in theory he should be sleeping
<czajkowski> *theory*
<jcsackett> well, i have mentioned his name. i have noticed many people in those timezones seem to appear like magic when mentioned. :-P
<czajkowski> lol
<wgrant> They probably want to be sent to #ubuntu-packaging or so.
<wgrant> As it's now nothing to do with Launchpad.
<jcsackett> czajkowski: see? magic.
<jcsackett> wgrant: thanks, i'll post that as a reply to the question.
<czajkowski> jcsackett: I actualy poked you with the wrong link :/ https://answers.launchpad.net/launchpad/+question/207802
 * jcsackett laughs
<jcsackett> ok, let me take a look at that one.
<czajkowski> jcsackett: you mock it's been a long week
<jcsackett> czajkowski: not mocking, just laughing. we all have moments like that, right? :-0
<jcsackett> s/:-0/:-)/
<czajkowski> lol
 * czajkowski laughs
<tumbleweed> cjwatson: Added 1 test, everything else was already covered. And set a commit message
<cjwatson> tumbleweed: OK, it's off to EC2 now; you'll get e-mail in four hours or so
<tumbleweed> thanks
<jcsackett> czajkowski: so we have a couple of bugs related to branch scanning failing, which looks to be what's happened here. on my own branches, i usually just delete the branch on LP and push a new copy to lp.
<czajkowski> nods
<jcsackett> czajkowski: however, they may be leery of doing that.
<czajkowski> some font like them delted
<jcsackett> czajkowski: it may be worth it for them to push new copies of those branches under new names temporarily to see if those scan right. in the mean time, you can point them at bug 904683 which tracks the issue.
<_mup_> Bug #904683: Updating branch seems to last forever <Launchpad itself:Triaged> < https://launchpad.net/bugs/904683 >
<jcsackett> czajkowski: there is also bug 1018460, but i gather this may have scanned properly initially, and so this isn't applicable.
<_mup_> Bug #1018460: Failure during initial branch scan increases scan time enormously <branch-scanner> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1018460 >
<jcsackett> czajkowski: and yeah, with big main branches i totally can see them not wanting to delete it--just sharing my experience. not really recommending it in this instance. :-P
<abentley> deryck: Another formatting-related test failure that I get even on stable: http://pastebin.ubuntu.com/1247615/
<wgrant> abentley: You're running with 2.7
<wgrant> We only run the test suite on Python 2.6
* adeuring changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On call reviewer: bac  | Firefighting: - | Critical bugs: ~300
<abentley> wgrant: True, but yesterday deryck reported he could not reproduce my test failure even with 2.7.3 on Precise.
<wgrant> Hmm
<wgrant> That's certainly odd
<abentley> wgrant: That was a different failure:  http://pastebin.ubuntu.com/1230926/
<wgrant> That should always fail
<wgrant> As there are no %s in the format string...
<abentley> wgrant: Yet it hasn't.  Both the test and implementation code are years old.
<wgrant> Ah, that branch is never meant to be hit
<abentley> wgrant: But the test is exercising that branch.
<wgrant> Indeed
<wgrant> So I am very confused
<abentley> Me too.
<abentley> wgrant: And today's failure is equally bonkers, because "summary" behaves like a mapping in line 5, but not in line 6.
<wgrant> Hmm
<wgrant>   File "/home/wgrant/src/launchpad/branches/sandbox/lib/lp/code/model/branchmergeproposal.py", line 418, in setStatus
<wgrant> That's from 2.6
<wgrant>     raise AssertionError('Unexpected queue status: ' % status)
<wgrant> AssertionError: Unexpected queue status:
<wgrant> So I guess it must be treating status (which is an enum value) as a zero-length sequence
<wgrant> And as for the other failure, I guess 2.7 is just more strict about what it wants from a mapping for formatting
<wgrant> It is pretty odd, though
<abentley> wgrant: How do you run with 2.6?
<wgrant> In a Lucid LXC
<abentley> wgrant: Ah.
<wgrant> >>> 'foo' % BranchMergeProposalStatus.SUPERSEDED
<wgrant> 'foo'
<wgrant> >>> 'foo' % object()
<wgrant> Traceback (most recent call last):
<wgrant> >>> iter(BranchMergeProposalStatus.SUPERSEDED)
<wgrant> Traceback (most recent call last):
<wgrant> How odd
<wgrant> It's not iterable, but it's 0-length?
<abentley> wgrant: in what sense 0-length?  It doesn't support len().
<wgrant> abentley: If it didn't think it was an iterable, then it would interpret it as a single thing to inject into the format string
<wgrant> If it thought it was an iterable but wasn't 0-length, it'd complain that there were too many arguments
<wgrant> So it must think it's a 0-length iterable
<wgrant> Despite not being iterable
<sinzui> bac do you have time to review https://code.launchpad.net/~sinzui/launchpad/merge-non-active-person/+merge/127041
<bac> sinzui: now that i've enjoyed a fine lunch i do.
<sinzui> thank you
<bac> sinzui: done.  thank you.
<sinzui> thank you bac
<abentley> deryck: I got a test failure on EC2 that I can't reproduce locally.  Any suggestions?
<deryck> abentley, can you email me or paste me the failure?  I'll take a look when back, going for the kids from school now.
<deryck> abentley, back nowâ¦. looking at the mail
<abentley> deryck: I did a second run (using -t) and it passed.  Just saw that now.
<deryck> abentley, ah ok, cool
<abentley> i.e. ec2 test -o '-t externalbugtracker-comment-imports.txt'
<abentley> deryck: I hope the initial failure was due to an issue in devel that has since been resolved.
<deryck> abentley, that's what I was wondering, if it was just timing with another failure not related to you.
<abentley> deryck: I have no data either way.
<sinzui> sigh. buildbot  fellover again on a different test
<sinzui> jcsackett, I will force this build.
<czajkowski> evening
<abentley> deryck: In your add-product-information-type-1046467 branch, the sampledata appears to contain NULLs: http://pastebin.ubuntu.com/1248311/
<deryck> abentley, looking.
<abentley> deryck: (I'm getting that oops because I added a proper information_type to the model definition, but I can just mark it nullable for now.)
<deryck> abentley, ah
<deryck> abentley, I did this the same way I did specification_sharing_policy and relied on the garbo job, or else fixed data locally myself to play around.
<abentley> deryck: That makes sense, I just figured you might want to fix the sampledata before landing, since you're changing it anyhow.
<deryck> abentley, ah, fair point.  I got the success email an hour or two ago now, though.  let me see if it merged.
<deryck> heh, I got my success mail from buildbot before I could finish registering for UDS and check pqm submit mails. :)
<deryck> Have a nice weekend everyone.
<cjohnston> flacoste: ping
#launchpad-dev 2012-09-29
<SpamapS> http://paste.ubuntu.com/1249723/
<SpamapS> getting bzr errors periodically for the last half hour.. seems like maybe a single problem server
<lifeless> SpamapS: #launchpad-ops for that :)
#launchpad-dev 2012-09-30
<hellfire> hey
#launchpad-dev 2013-09-23
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-pf/+merge/186956
<wgrant> StevenK: not quite
<wgrant> StevenK: Code deploys are not atomic.
<StevenK> :-(
<StevenK> wgrant: What would you suggest?
<wgrant> StevenK: You need to be using the new column everywhere before you stop setting it anywhere.
<wgrant> add new column, start setting new column, switch to read from new column, stop setting old column, drop old column.
<wgrant> comma == barrier
<lifeless> BARRIER
 * stub wonders where his Librarian tracebacks are hiding
<cjwatson> wgrant,StevenK: Have you had a chance to review my launchpad-buildd branches?  It just occurred to me that of course large-build-artifacts is a prerequisite for livefs building.
<cjwatson> Or at least for some use cases of that.
<marcoceppi> What does this even mean? http://paste.ubuntu.com/6147644/
<wgrant> marcoceppi: Can you pastebin your changes file?
<wgrant> It seems to be wrong.
<marcoceppi> wgrant: http://paste.ubuntu.com/6147652/
<marcoceppi> is it in the description?
<wgrant> marcoceppi: No, see the Files section.
<wgrant> Did you manually construct that, or do you have the section specified as '-' in debian/control?
<marcoceppi> wgrant: no, I ran debuild -S to make that
<marcoceppi> wgrant: here's the control file
<marcoceppi> wgrant: http://paste.ubuntu.com/6147657/
<wgrant> marcoceppi: You have no Section field in the Source stanza.
<marcoceppi> wgrant: crud, thanks
<marcoceppi> wgrant: that did it, thanks for help
<wgrant> np
#launchpad-dev 2013-09-24
<StevenK> wgrant: http://pastebin.ubuntu.com/6148582/ -- about the only other thing I can thing to change to processor is packagecloner.
<wgrant> StevenK: Does it work?
<StevenK> wgrant: Tests pass, at least -- I'm concerned that it's a little too conservative.
<wgrant> StevenK: What's the remaining diff?
<StevenK> Let me commit those changes and pump
<StevenK> wgrant: http://pastebin.ubuntu.com/6148746/
<StevenK> wgrant: No opinion, or you got distracted? :-)
<wgrant> StevenK: Close enough
<StevenK> wgrant: To which?
<wgrant> StevenK: To correct
<StevenK> Some docstrings and such have needlessly changed between the branches, I'll sort that out tomorrow and propose it.
<stub> Can I get https://code.launchpad.net/~stub/launchpad/swift-librarian/+merge/179142 looked at? Large file support is happening on a separate branch (done, but I don't think I can do tests without extending the mock again).
<cjwatson> wgrant: Does https://code.launchpad.net/~cjwatson/launchpad-buildd/large-build-artifacts/+merge/186503 look better now?
<wgrant> cjwatson: Looks good
<mpt> Oh!
<mpt> Imagine if the "Mark as duplicate" dialog defaulted to suggesting the bug report (other than the current one) that you had opened most recently.
<mpt> So. Much. Time. Saved.
<mpt> (reported bug 1229776)
<_mup_> Bug #1229776: No acknowledgement that a subsequently-opened bug report is a probable duplicate target <Launchpad itself:New> <https://launchpad.net/bugs/1229776>
<Ursinha> wgrant, hi, do you have time to review today my branch that fixes bug 1201485?
<_mup_> Bug #1201485: Need to import translations for the unity daily builds <langpack-o-matic:Triaged> <Launchpad itself:In Progress by ursinha> <Ubuntu Translations:Triaged> <https://launchpad.net/bugs/1201485>
<Ursinha> https://code.launchpad.net/~ursinha/launchpad/bug-1201485/+merge/186305
#launchpad-dev 2013-09-25
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/switch-to-processor/+merge/187441
<StevenK> Oh
<StevenK> Right
<wgrant> 31 minutes ahead of you there.
<StevenK> Hm yeah.
<StevenK> I either need to revert the getRestrictedFamilies() bits, or forward-port the changes from the later branch
<StevenK> wgrant: I've reverted the getRestrictedFamilies bit
<stub> Is the 3-clause BSD licence missing from LP deliberately?
#launchpad-dev 2013-09-26
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-pf/+merge/187645 should be okay to review again
<wgrant> Hm
<wgrant> StevenK: Can you talk to LP atm?
<wgrant> My routing to half of the DC disappeared
<wgrant> Ah, back now
<StevenK> Yay Optus?
<wgrant> Nah, it dropped inside sprintlink somewhere
<wgrant> Between the US and London.
<StevenK> My link to the DC is going via JP
<wgrant> Yes, but your ISP is even stupider than OptusNet :)
<StevenK> ... and then the Netherlands ?
<StevenK>   9.|-- ae-8.r25.tokyjp05.jp.bb.gin.ntt.net      0.0%    10  139.0 143.7 138.3 165.2   8.0
<StevenK>  10.|-- as-2.r22.amstnl02.nl.bb.gin.ntt.net      0.0%    10  405.2 405.5 402.2 408.7   2.1
<cjwatson> StevenK: Just out of interest, is your destruction of PF with the eventual aim of being able to implement builder pooling?
<StevenK> cjwatson: Nope, just destroying PF
<lifeless> destruction for destruction sake!
<cjwatson> StevenK: Damn, I was hoping :)
#launchpad-dev 2013-09-27
<cjwatson> wgrant: Bug 503421 seems like it should be in some state other than Fix Committed (since April)
<_mup_> Bug #503421: Even after fixing translator-credits, some still remain untranslated. <lp-translations> <qa-ok> <regression> <Launchpad itself:Fix Committed by wgrant> <Ubuntu Translations:New> <https://launchpad.net/bugs/503421>
<wgrant> i need to fix the existing data at some point
<cjwatson> Also I wonder if bug 912287 still needs to be Critical; no instances of it in any of the lucid_lp_lxc summary logs
<_mup_> Bug #912287: test_sigint_exits_cleanly breaks <qa-untestable> <spurious-test-failure> <Launchpad itself:Triaged> <https://launchpad.net/bugs/912287>
<cjwatson> Ditto no instances in lucid_db_lp_lxc
<cjwatson> Oh, but looks like buildbot doesn't keep old logs around forever, damn
<cjwatson> Only has back to lucid_lp_lxc #783, which isn't all that long ago
<mpt> "This is the Launchpad Login Service utilizing OpenID technology to synthesize a cromulent authentication experience."
#launchpad-dev 2015-09-21
<blr> cjwatson: are you about?
<cjwatson> little bit, what's up?
<blr> cjwatson: interested in how you're testing snap builds locally
<cjwatson> blr: running with http://paste.ubuntu.com/12517426/ (probably not all strictly necessary, but last bit definitely is)
<cjwatson> and with the snap.allow_new feature flag set
<cjwatson> that should be about all you need
<blr> is the gpghandler related?
<cjwatson> assuming you have an otherwise functional builder
<cjwatson> I think that was a temporary hack for some other reason, ignore it
<cjwatson> and default_batch_size was just to make it easier to see what was going on in some bits of UI
<cjwatson> so basically, you just want
<cjwatson> [snappy]
<cjwatson> tools_source: deb http://ppa.launchpad.net/snappy-dev/snapcraft-daily/ubuntu %(series)s main
<blr> thank you :)
<cjwatson> blr: I also reasonably routinely just run launchpad-buildd slavebin scripts by hand rather than bothering to go through an LP master, if I'm just trying to work on buildd itself
<cjwatson> blr: you can look for the RUN: lines in an existing build log and copy and paste them, just changing the build ID; you need to 'mkdir build-$YOUR_CHOSEN_BUILD_ID' (I usually just set the ID to 1 for less typing) in ~buildd first
<cjwatson> and make sure to do the umount-chroot / remove-build steps at the end even if it fails, or you'll get confused
<blr> cjwatson: what's the path to the slavebin scripts?
<cjwatson> see e.g. https://launchpadlibrarian.net/218457654/buildlog_snap_ubuntu_vivid_ppc64el_wget_BUILDING.txt.gz
<cjwatson> you have to decode the debug output, so:
<cjwatson> RUN: /usr/share/launchpad-buildd/slavebin/unpack-chroot ['unpack-chroot', 'SNAPBUILD-9', '/home/buildd/filecache-default/a33a4a88601a2e76ec85f8a99d2254dbf2d0d1ac']
<cjwatson> ->
<cjwatson> /usr/share/launchpad-buildd/slavebin/unpack-chroot SNAPBUILD-9 /home/buildd/filecache-default/a33a4a88601a2e76ec85f8a99d2254dbf2d0d1ac
<blr> excellent, thanks
<cjwatson> file names in the filecache are sha-1s of the content
<blr> right
<cjwatson> and you'll want to have an appropriate chroot downloaded with manage-chroot and prepopulated in the filecache
<cjwatson> a reason to do this for snaps is that it saves you from also having to have an appropriate local codehosting/git setup that the builder can talk to - that might be easy or it might not :)
<cjwatson> sometimes it's easier not to have N different environments all running and working at once just to test one thing :)
<blr> cjwatson: it certainly feels like quite a few balls to juggle at times :)
<cjwatson> right, so I always prefer to figure out how to run stuff in isolation if I can
<cjwatson> you can also start up the buildd and send xmlrpc requests to it by hand
<blr> right
<cjwatson> should be something like proxy.build('1', 'snap', 'sha-1 of chroot', {}, {"name": "blah", "arch_tag": "amd64", "archives": [list of sources.list lines including the snapcraft-daily PPA], "archive_private": False, "git_repository": "git repo URL", "git_path": "master"})
<blr> right... and the build proxy endpoint
<cjwatson> yeah, as in HowToRunSoyuzLocally
<blr> I'm passing that through _extraBuildArgs in snapbuildhaviour which afaict is correct.
<cjwatson> indeed
<blr> thanks colin, will have more questions at the end of the day no doubt.
<cjwatson> blr: all the primary web UI for snap building is in place now, so if you want to create a test build for yourself to dig sample information out of then you can start from Branch:+index or GitRef:+index
<cjwatson> should be obvious from there
<wgrant> Morning.
<blr> morning wgrant
#launchpad-dev 2015-09-24
<cjwatson> wgrant: Is it worth me pushing up branches for Branch webhooks?  https://posthere.io/0e1d-4225-836c looks vaguely reasonable as a PoC
<cjwatson> Very easy on top of your work
<wgrant> cjwatson: Branches are trivial, indeed.
<cjwatson> Thought I'd see if I could get it to go
<wgrant> What is it, like 10 lines of diff?
<wgrant> Plus UI
<wgrant> Oh, schema.
<wgrant> Thinking about what the payload should look like, hmmm./
<cjwatson>  11 files changed, 54 insertions(+), 10 deletions(-)
<cjwatson> without tests
<cjwatson> (ok, a bit of that is local webhook proxy config)
<wgrant> Not bad.
<wgrant> cjwatson: git:push:0.1 has old and new as dicts, currently containing just the sha1 key.
<cjwatson> Right, they could perhaps reasonably become dicts with just "revision_id" keys.
<wgrant> We should probably retain consistency, which means changing one of them.
<wgrant> I'm not fussed which.
<cjwatson> I prefer dicts over prefixes.
<wgrant> Great, I marginally prefer them too.
<cjwatson> There's an extra level of dict in the git case, but that makes sense given it's a repository hook
<wgrant> Right, exactly.
<cjwatson> https://posthere.io/0e1d-4225-836c updated
<wgrant> Fancy.
<wgrant> Do we have revnos easily accessible at that point?
<wgrant> I suspect not.
<cjwatson> We might, we do have both the db_branch and bzr_branch
<cjwatson> I'm doing this from a TipChanged event
<wgrant> Eh, let's skip it for now.
<wgrant> db_branch isn't entirely trustworthy.
<wgrant> And bzr_branch is wrong by that point.
<cjwatson> bzr_branch had better not be wrong, it's used to get the new revision ID
<wgrant> (well, we could get the info out of bzr_branch in most cases, but not always and it'd always be slow)
<wgrant> Get the new revision ID, but not the revno.
<wgrant> s/revno/old revno/
<cjwatson> We get the old revision ID from db_branch
<wgrant> Ah true.
<wgrant> Hm
<cjwatson> TipChanged.old_tip_revision_id
<wgrant> So we could probably include revno reasonably.
<cjwatson> It's a Revision query I think?
<wgrant> Yep, the number is BranchRevision.sequence
<cjwatson> Or is it Branch.revision_count
<wgrant> Noooo
<wgrant> BranchRevision.sequence is what you want, but you need to be prepared for it to either not be there or not be set.
<cjwatson> Maybe that's more trouble than it's worth, given that a reliable webhook should not use the revno
<cjwatson> (If there's a race with a push --overwrite, the revno might mean something different by the time the other end runs)
<wgrant> True.
<wgrant> Easy to add later if we become convinced it's reasonable.
<cjwatson> Versioning the format was a good idea.
<wgrant> Well, this wouldn't even require a version bump.
<wgrant> Yay for dicts.
<cjwatson> The "Delivery management web UI" Asana subtask should be done now, right?
<wgrant> Er yeah.
<cjwatson> Will push this stuff tomorrow.  I could probably attack the remaining subtasks there now that I've gone to the small effort of getting it all working locally ...
<cjwatson> Dunno how much you have pending
<wgrant> I just use an unrestricted squid in an LXC container for local testing.
<cjwatson> I deployed the spec but with a tweak to allow 10.0.0.0/8
<cjwatson> Which should perhaps go into devel/deploy
<wgrant> Indeed.
<wgrant> I meant to go back and make the delivery UI not suck now the infra is there, but have been distracted so far.
<cjwatson> Adding header/body details?
<cjwatson> Error display is a bit basic too.
<wgrant> And making the status clearer without expansion, and adding the status of the latest delivery to each row on +webhooks.
<wgrant> And adding refresh capabilities, possibly via dropping the AJAX batchnav stuff and use the delivery API collection directly.
 * cjwatson nods
<cjwatson> Right, time to crash.  Just like buildbot.
<wgrant> Heh
<wgrant> Night
<cjwatson> wgrant: https://code.launchpad.net/~cjwatson/launchpad/testfix-import-warnings/+merge/272228 if you have a sec
<cjwatson> silly me ran bin/test -t archivesubscription rather than -t archive.\*subscription :-P
<cjwatson> Actually I'll just self-review that, it's pretty obvious and it's in fact fixing a double-query that was previously present in the view (as shown by the decremented query count)
<wgrant> It is indeed quite obvious.
<blr> morning
<wgrant> Morning.
#launchpad-dev 2015-09-25
<maozhou> The derived series differences is null ,why?
<maozhou> http://i3.tietuku.com/87e9eeb51026da62.png
<maozhou> http://i3.tietuku.com/68caf1daa35f6683.png
<wgrant> maozhou: You need to ensure that the DistroSeriesDifferenceJobs are running.
<wgrant> Using process-job-source.py
<maozhou> Need I run it  manually?
<wgrant> You may run it manually or you may run it automatically.
<wgrant> But it must be run for the list of differences to be populated.
<maozhou> run  crontscripts/process-job-source.py  DistroSeriesDifferenceJobs ?
<maozhou> DistroSeriesDifferenceJobs is the parameter?
<wgrant> IDistroSeriesDifferenceJobSource
<maozhou> ok
<maozhou> thanks
<wgrant> Did it work?
<maozhou> The script It's running,  may be I need to wait for some mimutes.
<maozhou> wgrant
<maozhou> wgrant: It's ok , thank you.
<wgrant> maozhou: Great.
<cjwatson> wgrant: I only converted the stuff that needed to be security-sensitive to Archive.setProcessors; there are a couple of things that still set processors directly, namely the browser code for creating/editing distributions, Archive.enableRestrictedProcessor and friends, and a couple of tests.  Do you want me to convert those too?
<cjwatson> maybe it would be safer to convert them, let's see how hard it is
<wgrant> cjwatson: It's not fatal, since the field is readonly=True in the interface, but it seems like an easy port.
#launchpad-dev 2015-09-26
<cjwatson> wgrant: Yeah, I did it.
<cjwatson> Mostly to avoid future accidents.
<wgrant> Thanks.
<cjwatson> I spent most of the day landing stuff ...
<wgrant> I hopefully won't spend most of the day fixing obscure event failures...
<wgrant> Events cause no end of trouble.
<cjwatson> wgrant: Re bzr-webhooks, my feeling is that git:push:0.1 should probably use the unique name too, to avoid races.
<cjwatson> Although I guess some degree of raciness is inevitable, since you could equally change the repository name.
<cjwatson> So we could use the shortest path for bzr too if you prefer, though I think it will probably have to gain the lp: prefix in that case (Branch doesn't really seem to want to expose the shortened path without it).
<wgrant> cjwatson: Yeah, I'm not really sure which way to go.
<wgrant> If we use the full name it gets slightly hideous.
<wgrant> But only a little.
<cjwatson> To argue against myself, I kind of don't want to encourage people to use unique names unnecessarily
<cjwatson> Since they're kind of an implementation detail of "the default repository for <project>"
<wgrant> Right, exactly.
<wgrant> And it can already be wrong due to renames.
<wgrant> Ah, which you already pointed out.
<cjwatson> So there remains the question of whether it's OK to add the lp: prefix, or whether we need to add a shortened_path interface to Branch that omits it.
<wgrant> Hm
<wgrant> BranchSet doesn't have getByPath
<wgrant> Just getByUniqueName and getByUrl
<wgrant> Possibly we should add lp: to both.
<cjwatson> The reason I didn't for GitRepository was that it made GitRef look weird.
<wgrant> Ah, yes.
<wgrant> cjwatson: When generating keys on DF are you being careful to not upload them to prod keyservers?
<cjwatson> Err
<cjwatson> Possibly not
<cjwatson> http://keyserver.ubuntu.com:11371/pks/lookup?fingerprint=on&op=index&search=0x19D44D6EF975FEC0E91FDEC87B7BBD5205DDBBB2
<cjwatson> Wonder if there's some way I can get rid of that ...
<wgrant> Nope, it's not possible.
<cjwatson> Revoke, I guess
<wgrant> Which is why I always disable that code when I test the script every couple of years.
<wgrant> Normally we just symlink in one of the existing keys on labbu.
<cjwatson> Can we configure DF to not upload the key?
<wgrant> That would be a useful option to have.
<wgrant> cjwatson: Thanks.
#launchpad-dev 2015-09-27
<blr> morning
#launchpad-dev 2016-09-29
<xnox> cjwatson, any idea what component of our infra creates http://archive.ubuntu.com/ubuntu/ubuntu/dists/yakkety/main/dist-upgrader-all/current/yakkety.tar.gz.gpg signature?
<xnox> it's done with the old 2004 archive key, instead of the 2012 archive key.
<xnox> opened https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1628852 for now, will talk to brian when he is online.
<mup> Bug #1628852: upgrade tarballs are signed with deprecated 2004 key, instead of 2012 key <gnupg2> <ubuntu-release-upgrader (Ubuntu):New for brian-murray> <https://launchpad.net/bugs/1628852>
<cjwatson> xnox: lp:ubuntu-archive-publishing publish-distro.d/10-sign-releases
<cjwatson> xnox: I don't remember why *:*/dist-upgrader* is special-cased up top - maybe it wasn't clear whether it supported being signed with multiple keys
<xnox> brilliant! will take a look.
<cjwatson> xnox: anyway, ubuntu-archive-publishing is simple, I encourage you to hack it to fit
<cjwatson> xnox: it's meant to be owned by Ubuntu rather than by the LP team
<xnox> well, i think to support upgrades from precise -> trusty, things up to and including trusty should be signed with 2004 key. Things after trusty, should be just signed with the 2012 key.
<xnox> cool!
<cjwatson> perhaps it was something to do with that, yes
<xnox> thank you, i had no idea about ubuntu-archive-publishing project =)
#launchpad-dev 2016-10-01
<tsimonq2> I really wish that when selecting a lot of packages in Launchpad, that I could use Ctrl (or Shift, whatever it is) Click to select a lot of them
<tsimonq2> it's a real PITA to select a bunch of checkmarks :?
<tsimonq2> *:/
#launchpad-dev 2016-10-02
<wgrant> cjwatson: Thanks for the reviews.
<wgrant> cjwatson: (that last one has some serious history... https://launchpad.net/~wgrant/launchpad/i-really-do-hate-views was my first start on it, a week before I joined the company...)
<cjwatson> Nice.
<cjwatson> Perhaps I should do something with some of my misc branches that are about half that old ...
<wgrant> That's where that batch last week came from...
<wgrant> I have some dozens sitting in various ~ backups that never quite saw the light of day.
<wgrant> cjwatson: Does my reply in https://code.launchpad.net/~wgrant/launchpad/bug-1083709-again/+merge/306167 make sense to you?
<cjwatson> wgrant: Yep, seems reasonable, just hadn't quite had a chance to think about it.  Approved with one extra comment.
<wgrant> cjwatson: Thanks.
<cjwatson> I'm making fairly decent progress with the base git-target import model, BTW.  We should talk about the auth arrangements next week.
<wgrant> Odd is right.
<cjwatson> And resisting the impulse to go and spend a day ripping out the rest of IBranchTarget.
<wgrant> It is conceivable that a simple HMAC could work here with minimal database implications.
<cjwatson> Push over HTTPS, you mean?
<wgrant> Precisely.
<cjwatson> How novel.
<cjwatson> Certainly worth considering.
<wgrant> LP then need only verify the signature and that the encoded job ID is presently Running.
<cjwatson> I like avoiding a new celebrity if we can.
<wgrant> Avoiding celebrities and limiting excess authority always make me happy.
<cjwatson> Right, need to go out shortly, later
<wgrant> Indeed, and I should sleep. See you next week.
#launchpad-dev 2017-10-01
<tsimonq2> Hey everyone, so on https://dev.launchpad.net/PatchSubmission it says I should talk to someone here before making a change.
<wgrant> tsimonq2: We're all in transit atm, but some time next week during EU day should work.
<tsimonq2> Was talking with the Security Team a few days ago and someone brought up bug 439470. Mind if I fix it? :P
<mup> Bug #439470: Cannot attach currently-unknown CVEs via linkCVE() <api> <lp-bugs> <platform-want> <Launchpad itself:Triaged> <https://launchpad.net/bugs/439470>
<tsimonq2> wgrant: Ok
<tsimonq2> wgrant: I can link the bug again next week, unless people idle here and can see it then?
<tsimonq2> wgrant: Regardless, I have some preliminary code that I think works, I didn't fully read that first bullet point before working on it :P
<tsimonq2> Like you said, I'll ping sometime next week
<cjwatson> tsimonq2: How were you planning to do it?  The API takes a CVE reference today.
<cjwatson> I mean, an object rather than a string.
<tsimonq2> cjwatson: So I played with it a bit, the best way I found was to edit lib/lp/bugs/model/cve.py and move the "add to db" logic from inText() to __getitem__()
<tsimonq2> cjwatson: That way, regardless on how you want the CVE to appear (either via bug commit or via the Launchpad interface), if the CVE is valid and exists in Mitre, add it to the database.
<tsimonq2> cjwatson: That (add to db if it's valid) was only done in inText()
<cjwatson> Maybe.  I'd be interested to see what test suite fallout exists from that, since that might indicate difficulties with that approach.
<tsimonq2> Sure, I'll play with that aspect of it a bit.
<cjwatson> I agree that's one possibility, but it is pretty implicit.
<tsimonq2> cjwatson: Here's a diff: http://paste.ubuntu.com/25651103/
<cjwatson> I'm not going to think about diffs now
<tsimonq2> I'll do a runthrough of the tests and see what it does.
<tsimonq2> Ok
<cjwatson> Also check whether that actually helps you over the API.
<cjwatson> I don't remember whether the collection interface goes through __getitem__.
<tsimonq2> I think it will, because afair linkCVE over the API doesn't add new (valid) entries to the database.
<cjwatson> That doesn't have much to do with my question :)
<tsimonq2> That addresses your first statement, though. I'm not entirely sure what you're referring to when you say "collection interface."
<tsimonq2> I *thought* it called ICveSet directly, like this: getUtility(ICveSet)['1999-8979']
<tsimonq2> That in turn executes the logic I put in.
<cjwatson> Right, but API clients use a webservice collection which isn't exactly identical to that.
<cjwatson> Implementing it in __getitem__ only helps API clients if lp.cves[...] will get marshalled into something that ends up as the equivalent of getUtility(ICveSet)[...].  It would be logical for it to do so, but I don't remember whether that's actually the case right now.
<tsimonq2> Ah, I see.
<tsimonq2> I'll test it out and see if doing that adds the CVE properly.
<tsimonq2> cjwatson: Am I missing something, or do I need to compile a custom launchpadlib to be able to test this out?
<cjwatson> Why would you need to do that?
<cjwatson> (No compilation involved, to start with ...)
<tsimonq2> Good question... I just know that as an easy way to reference the API (in an interactive Python session would be a good way to test it out, no?)
<cjwatson> If you're using the default launchpad.dev hostname, then you can use "dev" rather than "production"; otherwise you can pass a root URL
<cjwatson> You'll probably need to run with LP_DISABLE_SSL_CERTIFICATE_VALIDATION=1 set in the environment unless you go to lots of effort to set up a hostname that Python will be willing to validate, but apart from that it works fine
<tsimonq2> Ok
<tsimonq2> Good to know.
<cjwatson> It seems weird to me from a REST perspective that this means merely doing a GET on /bugs/cve/<unknown-sequence> will create a CVE placeholder.
<cjwatson> Also AFAICS there's no way to do that from launchpadlib today; it would need some kind of equivalent of launchpadlib.launchpad.BugSet et al to allow looking up strings in that collection.
<cjwatson> I would take a different approach: add an exported method to CveSet called something like "ensure" which returns a Cve object, inserting a placeholder into the DB if necessary.
<cjwatson> That would make lookups of even existing Cve rows more convenient for API clients immediately, and would save having to make client changes.
<cjwatson> As well as being more compliant with usual HTTP semantics.
<cjwatson> (because the named-operation call to ensure() would be a POST)
<tsimonq2> Alright.
<cjwatson> This is all somewhat dozy post-midnight derivation-from-code rather than actually trying it, but I think it's correct.
<tsimonq2> Ok.
<cjwatson> And at any rate implementing an exported factory operation is the natural and usual way to do it and will definitely work, as opposed to an unusual way to do it which at best only might work. :-)
<cjwatson> (you'll probably want @export_factory_operation rather than @export_write_operation)
<tsimonq2> Sure, makes sense. :)
<tsimonq2> Alright.
<cjwatson> Anyway, that's your pre-implementation review, so I'm going to sleep :)
<tsimonq2> Ok, wfm, thanks cjwatson. :)
<tsimonq2> cjwatson: So I'm looking over the code and your review a bit more, I split the database placeholder entry code into another function that's called by __getitem__, because the way inText works is that it adds a placeholder to the database if it's a valid CVE and if it doesn't already exist, but since the problem is that the browser implementation only runs through __getitem__, we need it there as
<tsimonq2> well, no?
<tsimonq2> cjwatson: So the way I see it, it seems we can just have the function be called by __getitem__, and when inText reaches a point where something needs to be added to the db, it can just loop through __getitem__ and get the new Cve object returned
<tsimonq2> cjwatson: That's how my initial code worked, but it didn't split it into a different function, I'll have to play with @export_factory_operation to make it something that can be accessed via the db.  Is that all OK?
<tsimonq2> s/accessed via the db/accessed via the API/
