#launchpad-dev 2010-02-08
<mwhudson> dhillon-v10: yeah, i'd look for something smaller i think
<dhillon-v10> mwhudson: would you be around in like 5 mins. until i find something else?
<mwhudson> dhillon-v10: i'll have lunch soon, but i'm around for another 4 hours or so
<mwhudson> dhillon-v10: you could try looking at https://bugs.edge.launchpad.net/launchpad-project/+bugs?field.tag=trivial
 * mwhudson has lunch now, in fact
<dhillon-v10> mwhudson: when you get back, look at this one: https://bugs.edge.launchpad.net/launchpad-code/+bug/294048 it doesn't seem too bad
<mup> Bug #294048: Branch name ambiguous in revision feed for a person <feeds> <trivial> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/294048>
<mwhudson> dhillon-v10: yeah, that looks more suitable
<dhillon-v10> mwhudson: and I found another one that is a typo :)
<mwhudson> dhillon-v10: even better :-)
<dhillon-v10> mwhudson: one question, its a little unrealted, I develop kernel drivers for open-solaris, and we use something called open-grok which is a pretty amazing source-code browser, it can locate almost every instance of a word,struct,function and other stuff easily, I want to use that to index launchpad code, when I do that, is it possible to deploy that to a website, opengrok needs tomcat so what do you think about that
<mwhudson> dhillon-v10: it sounds interesting, but i don't think we have tomcat anywhere so i don't think it could be on our servers
<dhillon-v10> mwhudson: in finding typos like that one, I can just type in the word, and it will find the exact file that it is in, do you want to see a sample, I can set it up locally and you can see it :)
<mwhudson> dhillon-v10: i can do that on my machine with grep easily enough...
<dhillon-v10> mwhudson: ohh, I forgot about grep, thanks that saved my 10 mins. of configuration setup :)
<mwhudson> 'bzr ls --versioned --recursive --null --kind file | xargs -0 egrep ... ' is handy, if a little wordy
<wgrant> mwhudson: There is, and it works. But I got distracted when that revealed a whole lot of other isues in process-upload, which make it difficult to test.
<mwhudson> wgrant: can you link it to the bug?
<wgrant> mwhudson: Done.
<mwhudson> wgrant: ta
<dhillon-v10> mwhudson: someone fixed that typo before me: https://bugs.launchpad.net/malone/+bug/415170
<mup> Bug #415170: Typo in AJAX milestone picker class <bug-page> <trivial> <ui> <Launchpad Bugs:Fix Released> <https://launchpad.net/bugs/415170>
<dhillon-v10> mwhudson: I closed it :)
<mwhudson> dhillon-v10: hah
<dhillon-v10> mwhudson: have a look at this one: https://bugs.launchpad.net/soyuz/+bug/410331 , there's a default name but only for the first time someone activated their ppa, does it make sense to have it there every single time
<mup> Bug #410331: PPA: should default to sensible/good name (or give example) <ppa> <trivial> <ui> <Soyuz:Triaged> <https://launchpad.net/bugs/410331>
<mwhudson> dhillon-v10: not really my area, but i don't see why not
<wgrant> There is no default name at all any more.
<wgrant> Note that the bug is about the *display* name.
<dhillon-v10> wgrant: I looked in staging and ppa shows up in the default name field, but you are right :) no display name there
<dhillon-v10> mwhudson: this will have to be edited: http://pastebin.com/d42ab475d
<mwhudson> dhillon-v10: yeah
<mwhudson> dhillon-v10: it would be good for the default to update as the name is updated but that sounds fiddly...
<dhillon-v10> mwhudson: Curtis suggested that on the bug report, so I just put that there :)
<dhillon-v10> mwhudson: so what do you say, should I go ahead and make that edit, then put add a patch to that bug report, so you can review it and push it ?
<mwhudson> dhillon-v10: i might let someone from the soyuz team review it and you should put the change in a branch, not a patch
<mwhudson> but otherwise yes :-)
<thumper> mwhudson: you'll be happy to know that we are killing weekly chr
<mwhudson> thumper: i heard this rumour
<thumper> of a sort anyway
<mwhudson> thumper: but i thought i should do it today at least
<thumper> some things back to daily
<thumper> mwhudson: yeah, not sure when the "new" - old way comes back
<thumper> Ursinha: the getBranches update is being kicked off with ec2 land now
<dhillon-v10> thumper: hi :) I remember you from the developer week
<thumper> dhillon-v10: which developer week?  I did one ages ago
<dhillon-v10> thumper: it was the one with launchpad api, you were only there for a few moments someone else actually did the session
<thumper> ah
<dhillon-v10> mwhudson: for pushing a branch, do I have to download the entire edge branch again (I already did it to setup my developmental environment) or is there another way
<dhillon-v10> mwhudson: sorry for taking a lot of your time, once I get proficient at this, I won't bother you as much :)
<mwhudson> dhillon-v10: do you have a shared repository locally?
<Ursinha> thumper: awesome! :)
<dhillon-v10> mwhudson: I don't think so
<mwhudson> dhillon-v10: did you run rocketfuel-setup ?
<dhillon-v10> mwhudson: yes
<mwhudson> dhillon-v10: ok, so you have a ~/canonical directory and a trunk directory in there?
<mwhudson> what does 'bzr info' say in the ~/canonical directory?
<dhillon-v10> mwhudson: just a sec.
<dhillon-v10> mwhudson: this is what i get on the top-level directory: http://pastebin.com/m3f21dc01
<dhillon-v10> mwhudson: and yes I do have a local shared repo. :)
<mwhudson> dhillon-v10: then the usual practice is to "bzr branch trunk fix-bug-$BUG_NUMBER" in the repo
<mwhudson> make your changes in the branch you just created
<mwhudson> then commit, push lp:~<you>/launchpad/fix-bug-$BUG_NUMBER
<dhillon-v10> mwhudson: ok will do, right now updating my branch after that will follow the steps you listed above :)  thanks a lot for your help
<dhillon-v10> mwhudson: it says not a branch Not a branch: "/home/vikram/launchpad/lp-branches/devel/trunk/".
<mwhudson> um
<mwhudson> oh sorry
<mwhudson> dhillon-v10: cd /home/vikram/launchpad/lp-branches/; bzr branch devel <new-branch-name>
<dhillon-v10> mwhudson: yeah I already did that and it worked :)
<dhillon-v10> mwhudson: I figured if trunk doesn't exist then I can branch devel
<dhillon-v10> mwhudson: one bug down :) i pushed the branch, now do I request a merge or does it get reviewed first
<mwhudson> dhillon-v10: request a merge
<dhillon-v10> mwhudson: alright thanks again, that was my first change :)
<mwhudson> dhillon-v10: woo
<dhillon-v10> mwhudson: just curious, how many changes have you made, give me like 2 years and i'll catch up to you :)
<mwhudson> dhillon-v10: um, not sure, must be a few hundred
<dhillon-v10> mwhudson: wow that's a lot to catch up on, but I'll do it, just wait :)
<mwhudson> dhillon-v10: it's my full time job, that gives me a bit of an advantage!
<dhillon-v10> mwhudson: oh I forgot you work for canonical :P  i go to school which is a big pain
 * thumper is moving on
<dhillon-v10> mwhudson: last question of the day :) is it okay if I push launchpad code to google code, it has a little function search feature that makes it easy to search for functions and so on
<mwhudson> dhillon-v10: so long as it's marked as AGPLv3, sure
<dhillon-v10> mwhudson: yeah, all my projects are with GPL :) alright so thanks a lot, and good night
<wgrant> mwhudson, dhillon-v10: Google Code does permit AGPLv3, AFAIK.
<wgrant> Er, "does not" permit.
<dhillon-v10> wgrant: http://code.google.com/p/launchpad-ubuntu/
<dhillon-v10> wgrant: that was changed a while ago :)
<wgrant> Ubuntu?
<wgrant> Why Ubuntu?
<dhillon-v10> wgrant: it just sounds good, and also because ubuntu uses launchpad, something wrong with it??
<wgrant> Launchpad doesn't need any more publicity about it being linked to Ubuntu.
<wgrant> :/
<dhillon-v10> wgrant: okay, I'll change it, if google code allows me to :)
<bjf> i'd like to know if I can use searchTasks to search only the last 6 months, or to at least order the search results by date
<bjf> i've used order_by='-id' but can't figure out how do order_by date
<mwhudson> bjf: what do you mean by 'date' ?
<mwhudson> bjf: date created?
<bjf> mwhudson, date_created
<wgrant> -datecreated
<bjf> wgrant, that worked, thanks!  where would I have found that out on my own?
<bjf> wgrant, is there a way to limit the search to the last 6 months?
<wgrant> bjf: I don't know how I knew it -- maybe from looking at query strings for normal bug searches.
<wgrant> bjf: There is no way to do that.
<bjf> wgrant, thanks
<bjf> if I take the resulting collection from searchTasks and try to only look at the last 500 with taskSearch(order_by='-datecreated')[:500] I get an "file too long" error
<bjf> https://pastebin.canonical.com/27522/
<mwhudson> that's a launchpadlib bug
<mwhudson> https://bugs.edge.launchpad.net/launchpadlib/+bug/512832, at least
<mup> Bug #512832: launchpadlib caches based on full URL <launchpadlib :New> <https://launchpad.net/bugs/512832>
<bjf> mwhudson, ack
<bjf> mwhudson, just ran int that bug again (for a slightly different reason) the only workaround I can think of is to use taskSearch without any parameters
<mwhudson> bjf: i don't have any great ideas sadly
<bjf> mwhudson, thanks, thought I'd at least ask
<mwhudson> well, apart from fixing launchpadlib to cache in directories named after the SHA1 or something
<bjf> mwhudson, is that bug on anyone's "soon to be fixed" list? :-)
<mwhudson> bjf: i don't know
<mwhudson> let me push up the priority at least
<Ursinha> mwhudson: something crossed my mind now: all branches merged to devel/db-devel are necessarily in lp?
<mwhudson> Ursinha: i guess theoretically not, but that seems very very unlikely
<Ursinha> mwhudson: hm
<Ursinha> mwhudson: same way, all branches merged to db-devel/devel need a merge proposal before being merged?
<mwhudson> Ursinha: no
<Ursinha> mwhudson: right
<mwhudson> testfix branches don't always have merge props for example
<Ursinha> mwhudson: but they are in lp?
<mwhudson> Ursinha: yeah
<mwhudson> the branch has to be somewhere internet accessible to merge
<mwhudson> you *could* push to devpad i guess, but it's really not very likely
<Ursinha> mwhudson: I see
<Ursinha> mwhudson: well, I'll work with monitoring branches that are merged to devel/db-devel in lp
<mwhudson> Ursinha: that should be fine
<Ursinha> mwhudson: I hope so :)
<Ursinha> mwhudson: thanks for the thoughts
<mwhudson> Ursinha: np
<adeuring> good morning
<noodles775> Morning adeuring and all.
<adeuring> Hi noodles775!
<jml> good morning
<jml> noodles775, I'm going to acquaint myself with the last week of discussion of buildbranchtoarchive
<beuno> hey jml
<noodles775> jml: great, thanks.
<jml> beuno, hi
<jml> beuno, I'm working from home today & for the rest of this week, fwiw
<beuno> jml, I expected as much. It's too cold to do anything else  :)
<mrevell> Hello friends
<beuno> hey mrevell
<mrevell> Hi there beuno, congrats on your new role
<jml> beuno, also, despite the length in calendar days, I've really only just moved in. I need to be home to receive deliveries of bookshelves and the like
<beuno> jml, sounds exciting
<beuno> mrevell, thanks  :)
<jml> beuno, yeah, I'm quivering with anticipation.
<jml> how do I tell whether an import branch is bzr-svn or cscvs svn
<wgrant> There's a tooltip somewhere.
<jml> somewhere.
<wgrant> In "This branch is an import of the Subversion branch [...]", "Subversion" has a tooltip.
<jml> subtle
<jml> wgrant, thanks for the "tip" (get it!?!?!)
<wgrant> Rather.
<wgrant> Ha ha ha.
<beuno> jml, how can I find a list of all MPs with the
<beuno> "ui" review tag in them?
<jml> beuno, there's no UI for that.
<jml> beuno, probably not an API either.
<beuno> jml, can I get all MPs against launchpad through the API?
<jml> beuno, the 'review type' thing isn't really a tag, fwiw. perhaps it ought to be.
<jml> beuno, hmm.
<james_w> lp.projects['launchpad'].getMergeProposals() I believe
<jml> beuno, I don't know. I could find out by looking at the API docs. Want me to do that?
<jml> james_w, hello :)
<beuno> jml,
<james_w> status=[<list of statuses you want>]
<james_w> hi jml
<beuno> james_w, you should be on the code team
<beuno> thank you
<james_w> I'd love it if I could get these landed: https://code.edge.launchpad.net/~james-w/launchpad/
<beuno> james_w, my "ec2 land" is broken, but jml was nice enough to land my branch last week, he may still have niceness in him
<james_w> what do you mean? jml is always overflowing with niceness
<jml> jelmer, may I encourage you to reply to Michael Hudson's "[Launchpad-dev] plan for incremental code imports" email?
<jml> james_w, happy to do so.
<jelmer> jml: consider me encouraged.
<jml> jelmer, :D
<james_w> thanks jml
<jml> james_w, although I think I'm going to propose in future that we make this sort of thing the OCR's job.
<james_w> for the older one I think it was submitted, perhaps twice, so I think that has more to do with the fragility of the process. Having the OCR chase up approved but not merged branches would be a good idea though.
<noodles775> jml: will you have time for a call before lunch?
<jml> noodles775, probably not.
<jml> noodles775, but I'll almost certainly be ready right after
<jml> noodles775, unless you want a call right now
<noodles775> jml: right now is fine too.
<jml> james_w, both branches are now being tested on ec2
<noodles775> jml: sorry, right now as in 2 mins :/
<jml> noodles775, np :)
<beuno> does anyone know a way around bug 512832?
<mup> Bug #512832: launchpadlib caches based on full URL <launchpadlib :Triaged> <https://launchpad.net/bugs/512832>
<beuno> I can't use launchpadlib at all  :(
<beuno> james_w, is there anyway to get all the MPs I've reviewed?
<BjornT> beuno: if you have an encrypted home dir, a workaround can be to symlink the .launchpadlib/ dir to an unencrypted folder. that made it work for me
<beuno> BjornT, thanks, I'll try that
<maxb> salgado: Hi, did https://code.edge.launchpad.net/~maxb/launchpad/py2.6-importfascist disappear in a puff of ec2?
<beuno> BjornT, that totally worked, thank you
<salgado> maxb, thanks for reminding me of it -- the test suite was hung and the instance failed to shut down
<salgado> maxb, I'll submit it again
<maxb> thanks
<james_w> beuno: not that I know of. One of the branches of mine that will land shortly allows you to do me.getRequestedReviews(), but I don't know if that includes reviews you have done.
<beuno> james_w, ended up filtering in a loop, thanks
<bac> hi jamalta
<jml> noodles775, hello. I'm now caught up with my reading for daily build ui.
<jamalta> bac: hey, how's it going?
<bac> jamalta: good.  hey have you arranged for someone to land your branch for bug 515761?  i have a branch that needs to use your new AnonymousAuthorization class so I've been waiting.
<mup> Bug #515761: Anonymous API access to some collections returns nothing <Launchpad Foundations:Confirmed for jamalta> <https://launchpad.net/bugs/515761>
<jamalta> bac: well, yes i thought i had
<jamalta> but i guess they didn't get time to do so
<bac> jamalta:  i'll be glad to do it now
<bac> jamalta: if you'd merge from trunk and push back up to LP i'll land it for you
<jamalta> bac: sure! if you could please, i would really appreciate it
<jamalta> bac: sure thing
<jamalta> bac: sorry to have kept you waiting also :\
<bac> np
<jml> noodles775, and I'm thus happy to have a call whenever you are ready
<jml> (except not at 1500UTC).
<noodles775> jml: OK, I'm justgot a scheduled call with abentley first...
<noodles775> abentley: are you available now?
<abentley> noodles775, sure.
<noodles775> abentley: OK, I've added you as a contact on skype.
<jml> noodles775, np
 * jml seizes the opportunity to ruthlessly clean out his desktop & physical in-tray
<abentley> noodles775, I'm on skype, but I don't see a contact request.
<bac>  jamalta: please let me know when that is done
<jamalta> bac: alright, it should be updated now. Thanks for that.
<bac> jamalta: np.  i'll land it now.  please don't do any more pushes to that branch.
<jamalta> bac: of course, thanks so much
<jamalta> bac: oh thanks for catching that, i will start marking bugs as "In Progress" when I'm working on them
<noodles775> jml: is now ok, or too close to your next call?
<jml> noodles775, let's have one now and then schedule another if there's not enough time?
<beuno> # of ui reviews ever done using MPs:
<beuno> {u'beuno': 170, u'launchpad': 5, u'rockstar': 17, u'barry': 17, u'michael.nelson': 39, u'sinzui': 13, u'edwin-grubbs': 2, u'bac': 1, u'adeuring': 1, u'mars': 1, u'intellectronica': 12, u'matthew.revell': 4}
<noodles775> jml: ok, when you're ready.
<mars> EdwinGrubbs, ping, mind if I assign bug #405476 to you?
<mup> Bug #405476: sprite class bleeds extra images in tall elements <css> <post-3-ui-cleanup> <tech-debt> <Launchpad Foundations:Triaged> <https://launchpad.net/bugs/405476>
<EdwinGrubbs> mars: go ahead
<mars> thanks
<kfogel> adeuring: I have read and understood https://bugs.edge.launchpad.net/malone/+bug/518746 .  If you're working on it, I'll just make sure that is communicated to jcastro.  Is there anything else I can do to help?
<mup> Bug #518746: Read the patch age on the +patches view directly from Bug.latest_patch_updated <oops> <patch-tracking> <Launchpad Bugs:In Progress by adeuring> <https://launchpad.net/bugs/518746>
<adeuring> kfogel: well, if you want to discuss details how to address it, I'd appreciate it
<kfogel> adeuring: oh, I thought from this that the solution was already basically known: "The only detail we need from the query is the creation time of the bug message (retrieved in another, faster, query), and we can get this value already from the new column Bug.latest_patch_updated"
<adeuring> kfogel: seems that wrote nonsense: We want to display the title, the URL and a few other things...
<kfogel> adeuring: reading query more carefully now, then
<kfogel> adeuring: you're talking about the stuff in the popup block?
<adeuring> kfogel: yes, and about the URL we show for each patch
 * kfogel thinks out loud... "Maybe our denormalized column should be "latest_patch" rather than "latest_patch_updated"
<adeuring> kfogel: we need something to sort on in this column ;) But since row1.id < row2.id should imply row1.datecreated  row2.dattecreated, that should actually work quite well
<adeuring> kfogel: so: I think I'll change my DB atch again ;)
<adeuring> thanks for the suggestion!
<adeuring> erm, that should have been row1.datecreated < row2.dattecreated
<kfogel> adeuring: the only thing I worry about is, is that something we can count on always being true?  If "later IDs must be higher numbers" is going to be a constraint from now on, where do we document that?
<kfogel> (Do we use this sort-by-ID technique elsewhere in LP already?)
<micahg> if anyone needs a high profile bug with upstream implications to work on...bug 499113 is upsetting bugzilla.mozilla.org users... :)
<mup> Bug #499113: Launchpad will sync comments and link back to all bug watches, even those not linked to a bug task <bugwatch> <story-reliable-bug-syncing> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/499113>
<adeuring> kfogel: We had such a discussion a few hours ago, related to timeouts on the main LP bugs page
<adeuring> where a SELCT * from BUG WHERE ... SORT B> datecreated, id timed out
<adeuring> s/B>/BY/
<kfogel> adeuring: in SQL, "SORT BY foo, bar" means sort by foo first, then by bar within that?
<adeuring> kfogel: yes
<kfogel> adeuring: The idea sounds solid to me.  But I'd feel more comfortable if someone with lots of DB knowledge said "Oh, sure, we sort by ID all the time, it's totally normal."
<adeuring> kfogel: I can imagine one situation where we might get a, let's "minor deviation" from the rule "ordering by id is equvialent to ordering by date_creeated"
<adeuring> When two attachments are created simultaneously, attachment A might get the lower ID, while attachment 2 might have its INSERT statement executed first
<adeuring> but (a) aving two attachments field for the same bug at the same time is quite unlikely, and (2) if this happens, the fine details of which cam first are irrelevant anyway
<kfogel> adeuring: well, they're only going to differ by a milliseconds, right, and we're just sorting for UI purposes.
<kfogel> right
<kfogel> having two *patch* attachments is especially unlikely
<adeuring> kfogel: excatly
<kfogel> adeuring: is there any UI by which someone can retroactively mark an attachment as a patch or non-patch?
<adeuring> kfogel: es. Just follow the "edit" link in the patch/attachment poertlet of any bug page
<adeuring> s/es/yes/
<kfogel> adeuring: so when someone does that, we update the latest_patch_updated field, right?
<adeuring> kfogel: yes, via a trigger.
<kfogel> ah right, thx
<adeuring> kfogel: IIRC, stub alreaddy suggested to sort on bugattachment.id in some +patches-related query, when we discussed the sorting
<kfogel> ah, so this idea has an honorable provenance
<kfogel> good :-)
<beuno> since august last year, developers have done more UI reviews each month than I have
<beuno> http://paste.ubuntu.com/371828/
<beuno> I got my ass kicked in september
<beuno> (I knew I shouldn't of gone on vacations!)
<Ursinha_> abentley: hello.
<abentley> Ursinha_, Hi.
<Ursinha_> abentley: that day, when you suggested me monitoring branches being merged into devel/db-devel instead of their revisions, you really meant branches or merge proposals?
<abentley> I meant merge proposals.
<Ursinha> abentley: so, it turns out that not all branches merged into lp have a merge proposal
<abentley> What branches don't?
<Ursinha> abentley: testfixes, for instance
<Ursinha> not necessarily have mps
<Ursinha> abentley: I did a test here in lp and could see that
<Ursinha> abentley: getting all merged branches of launchpad-project, not all of them have mps
<abentley> Ursinha, Sorry I didn't think of that.
<adeuring> mbarnett: could you please run this query for me on staging: https://pastebin.canonical.com/27546/ ?
<Ursinha> abentley: no problem, actually I'd like to know if you have another idea
<Ursinha> abentley: ideally I'd monitor branches
<Ursinha> abentley: thumper very kindly implemented yesterday a way of getting branches given a date
<Ursinha> in that case, the last modified date
<mbarnett> adeuring: ERROR:  syntax error at or near "ORDER"
<mbarnett> LINE 6:        WHERE BugAttachment.bug = 445852 AND ORDER BY BugAtta...
<Ursinha> abentley: but some information will be missing, case the branch doesn't have an mp, like the target_branch
<abentley> Ursinha, without merge proposals, I don't see a cheap way to query this.
<Ursinha> abentley: ah :/
<adeuring> mbarnett: I'm an idiot, sorry. This one should work: https://pastebin.canonical.com/27547/
<abentley> I'd like to bring it up in our standup.
<Ursinha> abentley: but, is it possible to add more information to the branch? Also, I see that the merged_revno in the mp isn't filled. Is that a bug?
<adeuring> mbarnett: also, could you please check if we have an index on bugattachment(bug), in the staging database?
<mbarnett> https://pastebin.canonical.com/27548/
<adeuring> mbarnett: ot my best day... I meant an "explain analyze" for https://pastebin.canonical.com/27547/ . Sorry for the confusion...
<abentley> Ursinha, we can add more info, but I'm not sure the branch is the right place, because a merge involves two branches and may happen multiple times.
<mbarnett> heh
<abentley> Ursinha, yes, it's a bug that we don't include that revno.
<mbarnett> adeuring: https://pastebin.canonical.com/27549/
<Ursinha> abentley: I agree with your statement about branches not being the right place to put that, but I couldn't find another place considering not all branches have mps
<adeuring> mbarnett: thanks!
<Ursinha> abentley: ideas more than welcome :)
<mbarnett> adeuring: np
<abentley> Ursinha, the two ideas I have are 1. create a "merged" merge proposal when branch merges are detected, 2. create a new table to track merges.
<beuno> abentley, hey, you may be able to answer this. I can't figure out how to, from the API, which user commented on each comment
<beuno> I can get the content of the comment
<beuno> but not the author
<beuno> is it possible that it's not exposed?
<abentley> beuno, I believe that's recorded as the creator.
<beuno> rockstar, ^
<beuno> abentley, there doesn't seem to be such an attribute
<rockstar> beuno, lemme look
<adeuring> mbarnett: so... could you run this query on staging https://pastebin.canonical.com/27550/ ? That's from a not-yet-merged branch (https://code.edge.launchpad.net/~adeuring/launchpad/fix-broken-initialisation-of-bug-latest-patch-uploaded/+merge/18610 ); my hope is that this will improve the run time of the first query you ran
<beuno> http://paste.ubuntu.com/371856/
<beuno> I can get it for votes
<beuno> not for comments
<abentley> beuno, it is the owner of the message.
<rockstar> beuno, huh.  ICodeReviewComment doesn't have a author attribute.
<rockstar> abentley, I don't think message is exposed.
<abentley> rockstar, there's an export_as_webservice_entry line in the interface file.
<rockstar> Nope, it's not.
<rockstar> abentley, yeah, but the ICodeReviewComment.message isn't
<beuno> rockstar, easy fix?   I'm working on publishing a paper on Launchpad's whole UI review experience, and I need it as part the data I want to present  :)
<rockstar> beuno, I can't imagine it would be too difficult, but the API constantly has unknowns whenever I expose something.
<beuno> rockstar, will you have a few minutes to look into it and give me a nod?
<beuno> I'd super appreciate it if you could
<rockstar> beuno, can it wait a few hours.  I'd like to get a branch into review soon.
<beuno> rockstar, of course it can. Thanks
<rockstar> beuno, okay.  If you're lucky, it'll be on edge tomorrow.  ;o)
<beuno> rockstar, fingers crossed
<rockstar> Hell, if _I'm_ lucky...
<mbarnett> adeuring: sorry, got pulled in 2*10^7 directions there... your index is now on staging
<jamalta> bac: hey
<rockstar> gary_poster, hello sir.
<gary_poster> hey rockstar
<rockstar> gary_poster, bin/jsbuild is a generated file, correct?
<rockstar> mbarnett, hi
<gary_poster> rockstar: yes
<mbarnett> heya rockstar
<rockstar> gary_poster, where is the code that generates that?  I think I'm going to have to generate a Makefile in a similar fashion.
<rockstar> mbarnett, so, about that cherry pick...
<mbarnett> rockstar: there was some sql business if i recall correctly
<rockstar> mbarnett, yup.  Lemme get my ducks in a row first here.
<gary_poster> rockstar: If the end result is a Makefile, then I think you want a slightly different mechanism than bin/jsbuild, but same idea.  Look in [LP tree]/buildout-templates.  The .in files are processed and put in the LP tree by buildout.  Processing is as per http://pypi.python.org/pypi/z3c.recipe.filetemplate .  You might be able to get what you need just by looking at the files already in the bin dir there, though
<gary_poster> FWIW, that is hooked up in buildout.cfg in the [filetemplates] section
<rockstar> gary_poster, okay.  Basically, I need a make target that uses the filenames of all our js files as the dependent targets.
<gary_poster> rockstar: ...oh.  I'd guess you want to have something sniff out out js files so you don't have to maintain the list?  Is that the idea?  If you want to know what lazr.js is building, you'd probably need to ask mars or maybe salgado about that
<gary_poster> I don't know if there is a config file for that info anywhere, or what
<rockstar> gary_poster, yes, I want to automate it.
<rockstar> gary_poster, the problem currently is that the js gets combined every time you run make run.  This is no fun.
<gary_poster> rockstar: ah, yes!  have complained about this as well.  mars/salgado did want to address as well.  thank you for tackling.  salgado has a plan for this in fact, IIRC.  salgado, am I right?
<rockstar> gary_poster, well, it's one of the reasons I'm build manager this cycle.  Javascript needs to suck less.  :)
<salgado> gary_poster, I had, yes, but rockstar took it over as he's the build engineer. :)
<rockstar> salgado, if you have a better plan than mine, I'm all ears.
<gary_poster> rockstar: yay :-)
<salgado> rockstar, my plan is the one I described in the UI call last week
<rockstar> salgado, I've been rather perplexed at the nastiness of Makefile generation.
<rockstar> salgado, I don't recall you explaining it last week.
<rockstar> Maybe two weeks ago, before I was build engineer?
<rockstar> I remember you talking about it then, but I don't remember that there were any specifics discussed.
<salgado> we already maintain a hard-coded list of CSS files that we want to combine as we don't want to include everything from yui/lazr-js, so I think you could easily change bin/combine-css to not do anything if combo.css is newer than all CSS files in the list
<rockstar> salgado, ah, you're suggesting hacking it in bin/ scripts then.
<rockstar> Okay, that makes sense.
<rockstar> So the script still runs, but is basically a no-op.
<salgado> yep.  not the cleanest approach, but should be easy enough
<adeuring> mbarnett: cool, thanks!
<bac> hi jamalta
<jamalta> bac: any clue as to why those tests failed?
<jamalta> i guess the ec2 test didn't like '...' being used?
<bac> jamalta: haven't looked yet
<jamalta> bac: alright, when you get a chance3
<bac> jamalta: it will be easiest if i just merge in your branch into mine, fix the tests and land them together.  you'll still get credit as you're in the bzr history
<bac> jamalta: sound good?
<jamalta> bac: yeah that's fine too :)
<bac> jamalta: can you run the xx-bug.txt test in your branch and see if it fails?  i don't get a failure locally
<jamalta> bac: it doesn't fail for me either
<bac> jamalta: :(
<jamalta> that's mainly why i was confused
<jamalta> i know! :(
<jamalta> i thought it might have been after the merge, but they still worked fine
 * jamalta checks if he forgot to commit something
<jamalta> well, that wouldn't make sense because you'd be having the issue too
<jpds> (I usually find that running 'make schema' helps sometimes with weird test failures).
<jamalta> jpds: thanks, will try that
<bac> jamalta: the reason for the failure is not the wild-carding with ellipsis. it is b/c the actual output of that test had the unexpected output for 'task_age'
<jamalta> bac: oh
<bac> jamalta: your MP has db-devel as a landing target, not devel.  db-devel has task_age exported but devel does not
<jamalta> bac: wowah, how and why is it db-devel?!
<jamalta> i'm pretty sure i asked for lp:launchpad/devel
<jamalta> bah
<jamalta> oh i see what i did, hmm..
<jamalta> how can i fix thatA?
<bac> jamalta: it won't be an issue if i land it with mine
<jamalta> bac: ah okay
<jamalta> thanks for figuring that out
<mrevell> night all
<mwhudson> good morning
<jtv> hi mwhudson
<mwhudson> jtv: hello
<lifeless> jml: can I offer any assistance on your subunit branch for lp ?
<jml> lifeless, thanks. What I'm going to do is finish up the zope.testing branch. I'd like you're input on that once I've finished off the last few bits.
<lifeless> sure thing
<rockstar> gary_poster, I don't see a template for bin/jsbuild - Where can I find a mapping for all of these scripts?
<gary_poster> rockstar: all the files in bin are generated by buildout.  If they are not generated from the templates then they are generated from entry points, via the zc.recipe,egg zc.buildout recipe.  See the [scripts] section of buildout.cfg, in the entry-points key.
<gary_poster> (I don't think this affects your needs, but I don't advise looking too closely at those scripts specifically.  I'm putting the final touches now on a branch that gets rid of the whole fragile sys.modules ugliness.)
<gary_poster> rockstar: I'm not sure you are going to be able to get what I vaguely understand you want
<rockstar> gary_poster, getting rid of the sys.modules stuff will be nice, as it makes the script more manageable in an editor.
<gary_poster> but my understanding is vague, so hopefully I'm wrong
<gary_poster> rockstar: yeah, the new scripts are < 20 lines of <80 chars each
<rockstar> gary_poster, awesomeness.
#launchpad-dev 2010-02-09
<mwhudson> flacoste: /me lunches
<mwhudson> oops
 * mwhudson lunches
<maxb> Anyone else seeing a spurious ordering-based failure in lib/lp/bugs/tests/../stories/bugs/xx-front-page-bug-lists.txt ?
<dhillon-v10> can anyone give me a link where I can find more info. on writing tests for a change I just made, thankw
<dhillon-v10> *thanks
<wgrant> Series/milestones/releases could really do with being unbroken.
<mwhudson> wgrant: i think sinzui knows that
<mwhudson> and i'm not sure anyone else understands things well enough to unfix them
<mwhudson> you could argue any random change would likely be an improvement, but that's probably not actually true
<wgrant> I don't get why no time has been dedicated to making those important, obvious features less restrictive and broken.
 * mwhudson eods
<wgrant> spm: Oh, crap, 499421 has happened again?
<spm> wgrant: yeah :-(
<spm> I was like WTF is this alert about!?!?
<spm> fortunately tom belives in docco in our alert scripts so enough clues to find the bug/solution
<spm> no idea if helpful but was the "PPA for Ubuntu Mozilla Daily Build Team"
<wgrant> At least the other one (499095) seems to be properly fixed now.
<poolie> night
<spm> night poolie
<adeuring> good morning
<mrevell> Morgen
<jml> noodles775, james_w: hi
<james_w> hi jml
<jml> james_w: may I join your call?
<james_w> jml: fine by me
<james_w> not sure how to do that though
<jml> james_w, right-click on me in your skype contacts and select "Invite to conference"
<jml> james_w, noodles775: I've started a gobby document on gobby.ubuntu.com, 'lp-daily-builds'
<asabil> hi all
<james_w> jml: did that second branch land yesterday?
<james_w> I think that's the third time it's been put in ec2, perhaps it breaks tests?
<maxb> gmb: Hi, and thanks for the reviewing. Could you go ahead and land lp:~maxb/launchpad/use-hashlib for me? I've set a commit message on the MP. My other branch (lp:~maxb/launchpad/stop-using-deprecated-sets) would merge-conflict with that so if you leave that one alone, I'll merge and resolve after the first lands.
<gmb> maxb: Sure thing, will do.
<asabil> can someone explain how does the authentication work in launchpad ?
<maxb> Speaking of which, who would know what became of the mention of the potential of community PQM access?
<mwhudson> asabil: it's all in canonical.launchpad.webapp.authentication
<mwhudson> asabil: it's moderately complicated though
<mwhudson> asabil: how good are you at zope? :-)
<asabil> mwhudson, well I am trying to run launchpad, it works perfectly until I try to push code
<asabil> mwhudson, not familiar with zope at all
<mwhudson> oh
<mwhudson> that's an entirely different thing
<mwhudson> asabil: what user are you trying to push as?
<asabil> it's the authentication in the xmlrpc service
<asabil> a user I created
<mwhudson> did you add an ssh key?
<asabil> yes
<asabil> where are the keys stored btw ?
<mwhudson> in the database
<asabil> let me check
<mwhudson> asabil: can you ssh $USER@bazaar.launchpad.dev
<mwhudson> ?
<wgrant> You'll probably need launchpad.dev:5022, actually.
<asabil> let me check
<asabil> yes, it's on 5022
<mwhudson> oh right yes
<mwhudson> i have had that in ~/,ssh/config for so long...
<asabil> mwhudson, the server is running but I get an auth failure
<mwhudson> the console running 'make run_all' will have some messages
<asabil> http://pastebin.com/d107872fc
<asabil> that's the log from /var/log/launchpad/launchpad.log
<mwhudson> er
<mwhudson> that's strange
<asabil> btw, it is a custom deployment
<mwhudson> ah
<wgrant> Your Apache config is broken.
<asabil> in other words I am fiddling with launchpad
<asabil> I am using NGINX actually
<mwhudson> yes, what wgrant says is certainly possible
<asabil> so if I can just understand what's the problem
<asabil> I can fix it
<mwhudson> asabil: well, the ssh server will be talking to xmlrpc-private.launchpad.dev
<asabil> private ? not xmlrpc.launchpad.dev ?
<mwhudson> it looks like the virtual host config is busticated so the appserver can't tell which host the request was aimed at
<mwhudson> asabil: yes, private
<mwhudson> asabil: launchpad has two xml-rpc servers, a public one and a private
<mwhudson> one
<wgrant> xmlrpc(-private) is served on a different port.
<asabil> where is it supposed to be sent ?
<asabil> localhost:8087 ?
<asabil> or localhost:8085 ?
<wgrant> 8087
<asabil> both private and non private ?
<mwhudson> i guess, look at configs/development/local-launchpad-apache or whatever the file is called
<asabil> yes, I read it
<asabil> I skipped the rewrite rules to get loggerhead working
<asabil> but besides that the config is the same
<wgrant> Even the order?
<asabil> http://pastebin.com/d2ab85831
<asabil> hmm, why is bazaar.launchpad.dev using a different local IP ?
<mwhudson> i don't want to sound sceptical, but if it was exactly the same, i'd expect it to be working, and it's not working
<asabil> 127.0.0.99 instead of 127.0.0.88 ?
<mwhudson> i don't really remember
<wgrant> Does nginx not respect order?
<wgrant> 99 is only really used for private codebrowse.
<wgrant> Not xmlrpc.
<asabil> mwhudson, I am not disagreeing with you, I also suspect it. I am just wondering why
<asabil> wgrant, it does
<mwhudson> asabil: xmlrpc-private.launchpad.dev listens on 80, not 443
 * mwhudson zzzs
<asabil> mwhudson, in nginx I did setup both
<wgrant> asabil: Disable the .launchpad.dev directive and see what happens?
<Ursinha> good morning launchpadders
<wgrant> Evening Ursinha.
<Ursinha> wgrant: always this tz thing :)
<Ursinha> wgrant: good evening then
<asabil> wgrant, I just did doesn't change much
<wgrant> asabil: Check nginx and Launchpad logs to see which appserver is being forwarded to.
<asabil> wgrant, http://pastebin.com/d76f839ed
<asabil> that's what I see in wireshark
<asabil> and that's what is proxified by nginx: http://pastebin.com/d3ee120b7
<wgrant> asabil: To which IP address is the backend request?
<asabil> 127.0.0.1
<wgrant> Port, sorry.
<asabil> nginx(80) ----> launchpad(8087)
<wgrant> That would appear to be correct.
<asabil> anyway, thanks a lot for your help
<asabil> I will continue investigating
<wgrant> You have not altered the Launchpad configuration at all?
<asabil> may I know which host does launchpad expect ?
<asabil> and where is it specified
<asabil> wgrant, well I did as I said earlier
<asabil> I want to understand how it works
<wgrant> I mean the Launchpad config, not the frontend HTTP server.
<asabil> wgrant, yes I did
<wgrant> asabil: What have you changed?
<asabil> wgrant, seems like I changed the auth endpoint line to xmlrpc instead of xmlrpc-private
<asabil> I guess that's the issue
<asabil> wgrant, thanks a lot
<asabil> that was my mistake
<asabil> but I am still not able to login for some reason
<asabil> oh that's normal, there is no shell
<asabil> wgrant, thanks a lot, not it works
<asabil> I just need to understand the various cron jobs to get everything setup now
<jml> gmb, re bug 519271
<mup> Bug #519271: Ordering of latest bugs on the Malone frontpage appears to have become volatile <tech-debt> <Launchpad Bugs:Triaged> <https://launchpad.net/bugs/519271>
<jml> gmb, isn't that to be expected after dropping the 'id' from the query?
<wgrant> All bugs and bugtasks appear to have distinct creation dates, though.
<maxb> oh, that bug would explain the spurious test fails I've seen
<jml> if two things are created in the same transaction, they have the same create time
<wgrant> I'm also intrigued as to how the extra order clause ended up so slow.
 * bigjools adds MP to finally destroy Secure* publishing records
<wgrant> !!!
<wgrant> It hasn't bitrotted again?
<bigjools> nup, I kept it up to date, just didn't want to release it with the buildd changes last cycle
<bigjools> it's now 1 year and 1 week old :)
<wgrant> Excellent.
<bigjools> \m/
<bigjools> and on that note, food.
<gmb> jml: Well, no, because the creation dates in sampledata are distinct; the ordering in the tests should be sane. I need to investigate to be sure, though.
<gmb> wgrant: Some investigation by jtv yesterday led us to the conclusion that postgres was vastly underestimating the number of rows returned by the query. Adding an index on (datecreated, id) increased the speed of the query by 4 OoM.
<jml> gmb, fair enough. perhaps the tests are using the factory?
<jml> gmb, zowie!
<jtv> gmb: well I suspect that an underestimate (or buffer shortage) while sorting may be one of the causes.  The other one is that you can skip the sorting altogether by adding this index.
<wgrant> gmb: Aha. Ew.
<jml> more of that please!
<jtv> gmb: also, OOM was not in the GTF yet, so please join the GCP.  http://xs4all.nl/~jtv/gtf/
<gmb> jml: D'oh. Looking at it now, that's exactly the problem.
<gmb> jtv: SWD.
<jtv> gmb: ?
<gmb> jtv: Sure, will do.
 * jtv adds another one...
<jtv> and that's three-letter combination #9713
<jtv> (entry 23510)
<jml> gmb, fwiw, preliminary research indicates that transaction.commits in the factory are a big cause of slow tests.
<gmb> jml: Wouldn't surprise me.
<jml> anyway, I want to eat something's flesh.
<wgrant> Thankyou, bzr. http://pastebin.ubuntu.com/372497/
<wgrant> I hope that is a bug.
<bigjools> up late there wgrant
<wgrant> bigjools: A little.
<wgrant> sinzui: Are you trying to start a riot in bug #519100?
<mup> Bug #519100: registry mails use male pronouns <Launchpad Registry:Won't Fix> <https://launchpad.net/bugs/519100>
<sinzui> wgrant: No. I am quietly stating that Launchpad made a decision that the registry must abide by
<wgrant> sinzui: Any such decision is probably ill thought out.
<wgrant> No other software in this world has such a policy.
<sinzui> indeed
<bac> sinzui: where is this writing guideline?
<wgrant> I've not seen it either.
<sinzui> wgrant: I think raging against how language evolves is very pointless. I think the masculine references to users software are a great method to alienate 51% of the world and prevents Launchpad from attracting a balanced group of users
<wgrant> sinzui: Then why is that bug Won't Fix?
<sinzui> bac, wgrant: They were among the documents that were supposed to move from the old wiki to the new wiki a few weeks ago. It was in the page where mpt gave example of improper and correct phrases
<wgrant> Ah, i think I've seen that one.
<sinzui> wgrant: 1) it is launchpad, not registry, 2) it is policy that I lost the battle on.
<wgrant> I cannot find it now, however.
<wgrant> Then the battle should be resumed and trivially won.
 * bac searching
<mpt> https://dev.launchpad.net/UserInterfaceWording
<sinzui> wgrant: Do you think we should pretend it was lost in the great London flood of 2008?
<bac> sinzui: in this specific case we could solve the problem and adhere to the policy by just removing the word 'himself' as the sentence is clear and corrrect without it.
<mpt> That page doesn't say anything about pronouns (and I certainly never would have prescribed using "him" etc)
<mpt> so maybe it's another page sinzui is referring to
<sinzui> mpt: There was a document on it because I wrote her and I was show the wiki page that said I had to use him
<wgrant> Using either is very probably a bug.
<mpt> sinzui, would this have been something beuno wrote? I could ask him
<sinzui> beuno: would not have written it, I learned this rule in 2007
<bac> i've searched the old wiki for 'pronoun', 'masculine', and 'male' and cannot find anything
<sinzui> bac: me too, and there is nothing.
<sinzui> bac: I am happy to declare this issue moot and will reopen the bug
<wgrant> sinzui: Thanks.
<bac> sinzui: i'd reopen and s/himself// as above
<sinzui> I will also stop wasting hours writing retarded sentences
 * bac uh-oh, new can of worms...
<mpt> Really, that message shouldn't use pronouns anyway
<mpt> "The membership status of %s (%s) in the team %s (%s) was changed by the user himself from Approved to Deactivated." is just a long-winded way of saying "%s (%s) has left the %s team (%s)."
<beuno> sinzui!  you're alive!   did you manage to get home uneventfully
<sinzui> beuno: I suppose I did, but I think there is a grand bogus saga waiting to be told about my last two weeks. It may arrive in warthogs in a week
<sinzui> It will not be as good as the beach trip to hell
<beuno> sinzui, I'm looking forward to it
<beuno> sinzui, also, I want to have a call with you at some point this week
<beuno> I've been thinking about stuff
<beuno> and there's one final thing I want to do before officially moving to U1
<beuno> and it involves you  :)
<sinzui> beuno: fab
 * mpt wonders why, about once a week, someone mistakenly links a branch to bug 1
<mup> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Invalid> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <OpenOffice:Invalid by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Ubuntu:In Progress by sabdfl> <ubuntu-express (Ubuntu):Invalid by jahyire2006> <Ubuntu Jaunty:In Progress> <ubuntu-expre
<jml> kfogel, are we on for a call on the hour?
<kfogel> jml: hey!
<kfogel> jml: been a while.  Yes; short one, but let's do it.
<kfogel> jml: skype?
<kfogel> jml: did I miss my chance?
<jml> kfogel, you just dropped out. I'm reconnecting.
<allenap> jml: Thanks for the comment on the twisted-threading-bug-491870 merge proposal. Are you also implying that you think it's better to create the ThreadPool explicitly, or was it a FYI?
<jml> allenap, I think FYI. I've made multiple comments, so I'm not sure which you mean.
<allenap> jml: The most recent about adding an exception to importfascist.
<jml> allenap, oh yeah, that was an FYI. Better to shut up the warning _and_ file a bug on Twisted than do both.
<jml> anyway, I'm off.
<allenap> jml: Thanks, cheerio.
<jml> np. g'night.
 * thumper -> coffee
 * mwhudson vanishes again
#launchpad-dev 2010-02-10
 * mwhudson off home
<adeuring> good morning
<al-maisan> moin adeuring
<adeuring> hi al-maisan!
<mrevell> Morning
<al-maisan> Good morning mrevell
<mrevell> Dobro jutro al-maisan
<al-maisan> oh wow!
<mrevell> al-maisan, Heh, "Good morning in Bosnian" on Google.
 * al-maisan did not know mrevell as a polyglot :)
<asabil> hi all
<asabil> I have this failing import: http://launchpadlibrarian.net/38896393/prosody-im-trunk-log.txt
<wgrant> Hm, that's pretty awesome.
<noodles775> asabil: jelmer should be able to take a look when he's around, but either way, please file a bug about it so it gets tracked :)
<asabil> ok thanks
<wgrant> bigjools: lamont asked me this morning about publishing copy archives. I said it wasn't currently possible, and redirected him to you. Apparently it's going to be needed soon.
<bigjools> they're going to be out of luck then :/
<wgrant> It's not that difficult...
<maxb> gmb: Hi, when you are around, could you initiate the landing of https://code.edge.launchpad.net/~maxb/launchpad/stop-using-deprecated-sets/+merge/18896 (approved; has commit message)? Thanks.
<bigjools> difficulty is not the issue
<gmb> maxb: Will do.
<maxb> thanks
<thekorn> hi, how do I raise an error such that this error is exposed as a 400 HTTP error in the webservice api?
<wgrant> thekorn: grep around for 'webservice_error'
<thekorn> wgrant, ok thanks
<thekorn> hmm, somehow still now working, it is always a 500
<thekorn> ah, nm, I was missing: """This is only effective when the exception is raised from within a  published method[...]"""
<wgrant> thekorn: What were you raising it in?
<wgrant> A property?
<thekorn> wgrant, no, in a seperate method which compiles some BugTaskSearchParams for Person.searchTasks()
<wgrant> The "Request a review" interface is... confusing.
<beuno> yes
<beuno> the type shouldn't be on the bottom
<beuno> blame rockstar and lazr-js
<wgrant> It would be entirely unobvious what to do, even if the type was at the top.
<beuno> why is that?
<wgrant> Forms normally have buttons.
<beuno> right
<beuno> blame rockstar and lazr-js  :)
<beuno> I complained!  but there where some limitations, etc
<wgrant> :(
<beuno> wgrant, I'm sure there's a bug for that, and I'm sure we can push it up the priority list
<wgrant> beuno: It took me a while to work it out, and I've used it before, so it's probably reasonably awkward for newcomers.
<beuno> I'm sure it is
<allenap> jml: I'm getting hangs in tests and I think it's related to Twisted. Specifically, when TestTwistedJobRunner and doc/externalbugtracker.txt are run, one of them hangs (depending on if I change the layer to TwistedLaunchpadZopelessLayer or not). They both start and stop the reactor. Do you have time to discuss this? If not, I'll talk to abentley later about it.
<jml> allenap, sure. gimme a sec first.
<jml> allenap, what's the branch?
<jml> allenap, and will "bin/test -t doc/externalbugtracker.txt" reproduce the behaviour?
<allenap> jml: lp:~allenap/launchpad/twisted-threading-bug-491870 with an additional patch http://paste.ubuntu.com/373163/
<allenap> jml: bin/test -vvct 'externalbugtracker.txt|test_runner'
<jml> allenap, ok. looking into it.
<allenap> jml: It'll hang with or without the patch, just in different ways.
<jml> allenap, while I'm fetching branches, I need to get something out of my system that's not particularly helpful but tangentially related to this discussion
<jml> "don't use threads"
<allenap> jml: I know :)
<allenap> jml: This is Step 1 on the Road To Enlightenment: Getting Twisted's Foot In The Door.
<allenap> jml: I want to be able to convert each remote bug tracker one at a time to run async.
<jml> test_timeout hangs?
<allenap> jml: Yes. If you revert the patch, externalbugtracker.txt hangs.
<jml> allenap, I haven't applied the patch yet
<allenap> jml: Ah :) Maybe it's the other way round...
<jml> allenap, looks like the "hanging" is the reactor running with no events to listen to.
<allenap> jml: Ah, that's interesting.
<jml> allenap, I found that out using strace and gdb, fwiw.
<allenap> jml: I saw that it was hung in a select(...) with strace, but didn't really know what that meant. It feels a little bit obvious now! I don't know how to use gdb :-/
<jml> allenap, https://dev.launchpad.net/Debugging/GDB
<allenap> jml: Thanks.
<jml> allenap, do you ever run the reactor in process manually?
<allenap> jml: Do you mean at the REPL? Yes, sometimes. I haven't been doing so for this.
<jml> allenap, hmm. looks like it. afaict, updateBugTrackers calls reactor.run()
<jml> allenap, I mean in the tests.
<jml> allenap, there's this shitty thing about Twisted where you can't restart the reactor reliably
<jml> allenap, Trial works around this mostly by out-evilling everything around it.
<allenap> jml: Heh :) Trial FTW. I wondered if there was an issue there.
<allenap> jml: Is there an easy way to run these tests in a subprocess? ISTR that the Zope test runner does something along those lines when it can't tear down a layer?
<jml> hmm.
<jml> allenap, that, I don't know.
<jml> you could jigger something up with subunit, I guess.
<allenap> jml: Yes, that would work.
<jml> subunit.IsolatedTestCase() around the doctest.
<allenap> jml: Do you know how it works in TestTwistedJobRunner? Is it simply that that's the first kid on the block to start and stop the reactor so it's been working fine so far?
<allenap> jml: Ooh, that's cool :)
<jml> hmm.
<jml> allenap, I think so.
<jml> IMHO, TestTwistedJobRunner should be tweaked to not call reactor.run either.
<allenap> jml: Use a reactor test double instead?
<jml> allenap, maaybe.
<jml> allenap, I'm not sure.
<jml> allenap, I don't really have the headspace atm to figure out The Right Way of testing This Sort of Thing
<allenap> jml: Okay, it's good to know that I shouldn't pursue the path of trying to get the reactor to restart. I'll look into IsolatedTestCase I think.
<allenap> jml: Thanks.
<jml> allenap, np.
<thekorn> allenap, hey, I think a addressed all your comments on https://code.edge.launchpad.net/~thekorn/launchpad/make_iperson_ihasbugs/+merge/18541  however there is one thing missing, I'm still relying on sample data - I forgot to mention this in my comment to the merge request
<thekorn> but I can try to find out how to produce some data for testing purposes later
<maxb> Nothing landed today? is PQM busy doing private things?
<beuno> maxb, PQM is pretty empty
<maxb> hmm. Maybe it'll do my branch soon then :-)
<beuno> maxb, it's not queued up
<beuno> who sent it to PQM?
<beuno> ah
<beuno> it is queued up
<beuno> 12 minutes ago
<maxb> ah, great
<beuno> it'll take a little while
<beuno> it's the only branch on the queue
<kfogel> should I worry about seeing this on pqm.l.n ?   http://paste.ubuntu.com/373241/
<kfogel> jml: should I worry about seeing this on pqm.l.n ?   http://paste.ubuntu.com/373241/
<BjornT> kfogel: it means that the patch before yours failed because it had db changes
<kfogel> BjornT: Oh!  Thank you.  I would never have guessed that from the output (it looks like both the failure and my change are in the "Now Playing" category, and thus I thought the failure was due to my change.)
<kfogel> s/.)/)./
<allenap> thekorn: Awesome. I'll look at your branch this afternoon.
<thekorn> allenap, super thanks
<BjornT> kfogel: well, they are. the problem is that it's a tail from the pqm log, which doesn't clearly indicate where a new merge request starts
<kfogel> BjornT: ah, so the "cleaning working directory" part (say) is about my change, but stuff farther above is just from earlier in the log?
<BjornT> kfogel: i think so, but i'm not sure
<rockstar> wgrant, beuno, I have a fix for the "Request a Review" picker, but it's ugly, and I'm tired of writing ugly javascript.  I just need to get some time to clean it up.
<beuno> rockstar, cool
<beuno> while you're here
<beuno> could you or abentley take a look at: https://code.edge.launchpad.net/~facundo/ubuntuone-client/lr-clean-trash
<rockstar> beuno, crapola.  :/
<beuno> rockstar, any idea how that got in that state?
<rockstar> Oh wait, this isn't an artifact from the other day.
<rockstar> beuno, no, no idea how it got like that, but I'd be curious to find out.
<beuno> rockstar, AFAIK, just pushing to it
<rockstar> beuno, can you break the lock?  I'm under the impression that the mirrored copy is the locked copy.
<leonardr> gary, you know how the version marker interfaces subclass each other for convenience?
<leonardr> it turns out there's a place where that's very _in_convenient
<gary_poster> heh, what is it?
<leonardr> is there a method like providedBy which only returns true if the object provides the interface itself as opposed to providing a subclass?
<leonardr> i thought there was something like directlyProvidedBy but apparently not
<gary_poster> Yeah I don't think so
<leonardr> gary: the problem is in toWADL(). i go through the registered adapters looking for entry adapters.
<leonardr> IBug_betaAdapter, IBug_10Adapter, and so on
<beuno> rockstar, I'll get him to try
<beuno> it's odd that locks would get mirrored though
<leonardr> the problem is that if you ask for WADL for 'beta', it matches both IBug_betaAdapter and IBug_10Adapter, because IBug_betaAdapter is registered under the 'beta' marker interface, and IBug_10Adapter is registered under a subclass of that interface
<leonardr> so you get an error saying that there are two classes called 'bug'
<rockstar> beuno, no, I'm assuming it got locked so that the mirrorer could mirror the branch.
<beuno> aha
<beuno> rockstar, I'll ge thim to try that and let you know
<gary_poster> leonardr: thinking.  do you already have a work-around in mind?
<leonardr> gary: no, i'm stumped. going through zope.component looking for a function that might help
<gary_poster> ok
<gary_poster> leonardr: Can you give me a code snippet to look at of the pertinent lookup?
<leonardr> gary, sure
<leonardr> gary: http://pastebin.ubuntu.com/373322/
<gary_poster> looks
<gary_poster> so leonardr you need ``if not version.providedBy(self.request):`` to be more restrictive, right?
<leonardr> gary: right
<leonardr> gary: zope.interface implements providedBy by getting some kind of specification object and returning "self in spec._implied"
<leonardr> if i could get that spec there might be a spec._directly
<gary_poster> leonardr: you can call zope.interface.providedBy(obj) which will return a spec, which has an __iro__ that would have the right ordering.  Pretty roundabout but maybe that's all we can do.
<leonardr> i'll try it
<leonardr> gary: changing to "if not version in providedBy(self.request):" worked
<gary_poster> leonardr: great!
<maxb> Whereabouts in the PQM queue is lp:~maxb/launchpad/stop-using-deprecated-sets ?
<beuno> maxb, PQM is empty
<maxb> argh
<maxb> gmb landed my branch on db-devel :-(
<beuno> maxb, I could try and land it against devel, but it will take me a while
<beuno> maybe someone else here?
 * beuno looks around
<maxb> EdwinGrubbs: With your OCR hat on, could you do a PQM submit for me? I have a branch which has already been through ec2test successfully (against devel), but somehow then went on to land on db-devel. I'd like it to re-land on devel, if that's ok. lp:~maxb/launchpad/stop-using-deprecated-sets is the branch. I can forward you the test results email if you'd like some corroboration concerning skipping ec2test
<jml> g'night all
<beuno> maxb, if nobody volunteers in the next 20 minutes, ping me and I'll do it
<maxb> It is not that urgent. I'd like it done if someone's free, else I'll hassle gmb again tomorrow morning
<beuno> maxb, I'll do it now
<beuno> I don't want you to feel slowed down, we appreciate all your work a lot  :)
<beuno> I'm in the London office anyway, so it should be speedier
<EdwinGrubbs> maxb: I can do it.
 * beuno control+c's and moves on
<EdwinGrubbs> maxb: out of curiosity, what is the problem with just waiting for the rollout to get it into devel, since your branch should already be on staging for testing?
<maxb> I have another branch that conflicts with it that I also want to land, and following on from that my aim is to start trying to run the testsuite under Python 2.6. I guess I could just move all my efforts to being based on db-devel for this cycle, but that seems a bit awkward
<maxb> Especially with it being week 1
<EdwinGrubbs> maxb: makes sense, I'll land it now.
<maxb> thansk
<beuno> thumper, ping
<beuno> rockstar, ping
<beuno> https://code.edge.launchpad.net/~facundo/ubuntuone-client/lr-clean-trash
<beuno> is still trashed
<EdwinGrubbs> maxb: your branch can't be landed on devel because changes files in the database/schema directory.
<maxb> oh
<maxb> ugh
<maxb> EdwinGrubbs: Thanks for pointing this out, I failed to consider that, since I was merely tidying scripts, not actually thinking about db schema changes
<mwhudson> good morning
<beuno> mwhudson, hey hey
<beuno> whenever you have enough coffee in you
<beuno> could you take a peak at: https://code.edge.launchpad.net/~facundo/ubuntuone-client/lr-clean-trash
<mwhudson> beuno: hmm
<mwhudson> beuno: i got the puller to try again and it seems happier now
<beuno> mwhudson, that's very nice of you, thank you
<beuno> any idea how it got itself into that situation?
<deryck> +filebug is timing out on malone a lot today.  I wonder if we broke something.
<deryck> gmb, ping
<gmb> deryck: Hi
 * gmb sees previous message
<deryck> gmb, so +filebug seems to be eternally timing out today...
<gmb> Oy
<gmb> deryck: OOPS me.
<deryck> gmb, I can only get the simplest of dupe searches to run.
<deryck> gmb, that was my question... how do I get an OOPS number now? :-)
<gmb> Hah. Good question.
<gmb> There is a way, I think, hang on...
<kfogel> deryck, gmb: either of you know wiki syntax for an xml charref?  e.g., &#321;ukasz Czy&#380;ykowski <lukasz.czyzykowski {_AT_} canonical.com> :-)
<kfogel> Any way to convert that to something that will display right?
<deryck> kfogel, you know, I don't know.  I proudly don't speak moin fluently.
<deryck> kfogel, I assume the syntax guide was no help?
<kfogel> deryck: not so far; googling
<gmb> deryck: Ah, rats. No there isn't, because it's all compressed code so it's impossible to put a breakpoint in. I think it's a job for hte OOPS report.
<deryck> gmb, and we don't have a way to get a list of OOPS other than the OOPS report?
<gmb> deryck: Well, rooting around on devpad I found OOPS-1502EB617 for a start.
<gmb> deryck: But no. And that sucks.
<deryck> gmb, at least one OOPS is good though, thanks!  Some place to start debugging.
<gmb> deryck: Ouch. 17000ms on the query to find possible dupes.
<gmb> deryck: It's an FTI search though, so it's always a bit sluggish.
<deryck> gmb, yeah.  But something has to be wrong'er than normal. :-)
<gmb> deryck: Possibly.
<gmb> deryck: if you grep -r for '+filebug-show-similar' in devpad:/srv/launchpad.net-logs/edge you'll find the OOPSes. you'll need to discard the launchpad access log matches.
<gmb> Obviously you can also limit by date; that helps :)
<deryck> gmb, cool, thanks.
<deryck> gmb, also, I'm trying queries on staging DB for a point of comparison.
<gmb> deryck: Good idea.
 * gmb switches machines; brb
<deryck> gmb, the 17000 ms query was 11064 on staging, which smells wrong.  queries always take longer on staging, no?
<deryck> and repeats are wayyyyyyy faster.
 * gmb returns
<gmb> deryck: That could be a caching / buffering / something-else-about-postgres-I-don't-understand thing, though.
<gmb> Maybe its a db load thing...?
 * gmb clutches at straws
<deryck> gmb, yeah, I'm sure it is.  But why not see the same on re-checks on lpnet?  and yeah, load is what I'm wondering too.
<gmb> Hmm
<gmb> deryck: Well, the request should go to a slave, right, because it's a SELECT. So maybe the re-checks go to a different slave.
<gmb> But this is all guesswork.
<mwhudson> staging is usually much less loaded than prod...
<gmb> Right
<deryck> right, but +filebug for me on staging never works, but does in prod... so if staging queries run in half the time as lpnet today...  anyway, this is just guess work at this point.
<mwhudson> ah ok, that does sound a bit odd
<deryck> and hi mwhudson, btw :-)
<mwhudson> jelmer: are you going to land a change to use lp:bzr-git tip for lp or should i?
<jelmer> mwhudson: is there sense in landing something now, or could we wait until closer to the rollout?
<mwhudson> jelmer: testing on staging, maybe?
<mwhudson> not sure that's needed here
<mwhudson> "being sure we won't forget" is the main one i guess
<kfogel> jml: I'm sure you're not there, but if you are: https://code.edge.launchpad.net/~kfogel/launchpad/cc-script-new-world/+merge/19060
<kfogel> That contains, among other things, the community-contributions.py improvement we were discussing yesterday.
<jml> kfogel, cool. I'll do the code review tomorrow. Hip-deep in my own thing right now.
<jml> (we gonna learn you some Python idioms!)
<kfogel> jml: I see you must have looked at it already :-).
<kfogel> jml: looking forward to the review, thanks.
<wgrant> kfogel: Is that really the latest code? It calls people like Daniel Silverstone non-LP devs (which is wrong), but /Contributions/Draft correctly omits their commits from the list.
<kfogel> wgrant: don't know how Daniel Silverstone ended up on the list.  I'll remove him.  It is the latest code, and so I wonder why Silverstone is omitted when he should be (wrongly) included right now.
<kfogel> wgrant: did he formerly work for canonical on a non-lp team?
<kfogel> wgrant: also noticing david allouche, same situation
<thumper> kfogel: Daniel Silverstone did used to do LP work
<wgrant> kfogel: He was pretty much the primary Soyuz developer at the start, so he was very much LP.
<wgrant> ddaa was Code.
<kfogel> thumper: *nod*, fixing, thanks
<kfogel> wgrant: ddaa is david allouche?
<thumper> kfogel: yes
<wgrant> And carlos Translations.
<kfogel> perello?
<thumper> kfogel: it is wgrant being a young person and abbreviating everything he can :)
<wgrant> Malcolm Cleaton was Soyuz.
<wgrant> thumper: Pfft.
<kfogel> thumper: stp mkng fn of ppl
<kfogel> wgrant: thank you!  I'm fixing these (moving them to the known_canonical_lp_devs list) as you say them
<kfogel> any others?
<thumper> kfogel: you have a surperflous o in there
<kfogel> thumper: it's not superfluououous
<thumper> I wish I got red underlines under incorrectly spelt words
<wgrant> Some of the others were probably on LP ages ago, but I couldn't be sure.
<kfogel> wgrant: I'm sure I'll hear about them eventually.
<wgrant> They seem to be magically not showing up anyway.
<thumper> mwhudson: did you want to have a call this afternoon about the build from recipe stuff?
<kfogel> wgrant: that worries me; I wonder why not
<kfogel> wgrant: maybe because their bzr identities were set up in some other way?
<thumper> mwhudson: I was going to take the car down to get looked at, but we could do after
<wgrant> In fact, despite the list being quite wrong, the produced page contains not one person who even might have been on the LP team.
<mwhudson> thumper: yeah, sounds sane
<kfogel> wgrant: that makes me worry if it's leaving out people who should be there
<mwhudson> thumper: i'm not going anywhere, when is good for you?
<thumper> mwhudson: later :)
<kfogel> wgrant: feel free to do a code review on https://code.edge.launchpad.net/~kfogel/launchpad/cc-script-new-world/+merge/19060  -- I could well have mussed something up.
<mwhudson> thumper: :-)
<kfogel> wgrant: in fact, if you want, I'll put in a review request
<kfogel> (so it's tracked)
<kfogel> wgrant: (draft wiki page regenerated, btw)
<wgrant> Oh, also, Code Somerville is in both lists (the first one twice), when he should just be in the non-LP one.
<wgrant> I didn't think John Lenton was ever LP, and Michael Casadevall never was. And neither was Sidnei, AFAIK.
<kfogel> wgrant: fixed (about to commit and push up)
<kfogel> wgrant: any others you spot?
<kfogel> wgrant: oh that's right, sidnei works elsewhere -- I just talked to him a bunch before, so thought we were on the same team.  I guess I'm pretty informal about these boundaries :-).
<wgrant> Elliot Murphy is in both. I'm not sure about him. David Murphy I'm not sure about. Jonathan Knowles was an LP dev.
<wgrant> Oh, and Michael Vogt should be added to the non-LP list.
<kfogel> wgrant: thanks.  I guess this is proof that we really should be using Launchpad to do these identifications!
<james_w> David is non-LP
<mwhudson> david murphy was an lp dev for a while
 * james_w backpedals
<kfogel> james_w, mwhudson: see, yeah, that's the thing -- the script has no way of dealing with people who changed roles.
 * maxb wonders what the cc script does re db-devel landings
<kfogel> maxb: punts
<kfogel> maxb: see note at top of wiki page
<kfogel> maxb: when they make it to devel, then they show up
<mwhudson> kfogel: it's pretty hard to figure that out i can see
<maxb> ah right, I'll get a bonus point in three weeks then :-)
<wgrant> It should actually be reasonably easy to make it consider both, I think.
<wgrant> Maybe I'll have a look at that later.
<kfogel> wgrant: you'd be my hero
<kfogel> wgrant: its current state is a classic example of tech debt by design, IMHO
<kfogel> maxb: right :-)
 * maxb crosses fingers and commences a test run under python 2.6
<wgrant> maxb: Is all your 2.6 stuff now merged?
<wgrant> (apart from the actual version switch, of course)
<maxb> wgrant: no, I have two branches totally pending plus 1 landed on db-devel not devel
<maxb> One of which can't land because of bugs in the tests of initialize-from-parent.py
<wgrant> maxb: What's the bug?
<maxb> It intends to check that the parent has no pending builds. That check was broken. I fixed it. However, the use of it in the testsuite actually does invoke it on a parent with pending builds.
<wgrant> Ew.
 * maxb wonders why ubuntu/hoary in the sampledata has pending builds
<wgrant> The Soyuz sample data is awfully broken.
<wgrant> It's odd that a test uses ubuntu rather than ubuntutest, though.
<maxb> oh no, it uses both :-)
<maxb> it creates a new series in ubuntutest, parented on one in ubuntu
<mwhudson> man, soyuz is so hobbled
<wgrant> I believe ubuntutest exists because ubuntu got too broken in the sample data.
<mwhudson> but too many tests depend on it
<mwhudson> araragh
 * mwhudson lunches
<wgrant> Right.
#launchpad-dev 2010-02-11
<thumper> mwhudson: I'm back now.  When do you want to talk about recipies?
<mwhudson> thumper: i haven't really started anything after my lunch break so now ish is good
<mwhudson> thumper: gimme a minute to fetch a drink
<thumper> mwhudson: ok, let me grab a glass of water and I'll call you
<mwhudson> thumper: ready now
<dhillon-v10> mwhudson: ping :)
<mwhudson> http://people.canonical.com/~michaeln/bfb/build_now_overlay_v2-expanded.png
 * thumper off to take advantage of sunshine, back later
<noodles775> G'day all
<noodles775> lifeless: Hi, will you have a chance to look at bug 509370 solution before I get it reviewed and landed?
<mup> Bug #509370: PPA access granted for XXXX mail does not identify the PPA. <email> <ppa> <trivial> <Soyuz:In Progress by michael.nelson> <https://launchpad.net/bugs/509370>
<noodles775> s/at/at the
<NCommander_> hey noodles775
<wgrant> Morning.
<lifeless> noodles775: I'm sure you understood the issue, so whatever you've done should be fine
<lifeless> noodles775: if you have some reason to think it won't be, I can make time to look at it.
<NCommander_> noodles775: do you know if there are any Soyuz specs to implement binary rebuilds?
<noodles775> lifeless: ok, I was slightly confused about it, as it is a private PPA that the subscriber doesn't actually have access to, but I've just added the actual PPA name (as opposed to the displayname) and included the description in the email. Thanks.
<noodles775> NCommander_: hi, it seems to be currently without priority - mentioned at https://dev.launchpad.net/Soyuz/WantedFeatureList with the relevant bug.
<NCommander_> noodles775: I was hoping there were some design docs or spec on the topic
<noodles775> Evening wgrant.
<lifeless> noodles775: the key thing I'd want to see is the ppa: url
<lifeless> noodles775: which is perhaps what you mean by 'actual PPA name'
<lifeless> noodles775: the problem being that many many people have a PPA called 'releases' :)
<noodles775> lifeless: by 'actual PPA name' I mean the IArchive.name property which is what is used in the URL. Including the URL has a few issues, the main being that the user *doesn't* have access to view the URL.
<noodles775> (and won't even when they are subscribed - they can download software, but not see the details of uploads etc.
<lifeless> noodles775: I don't understand the issue: the URL is what they add to add-apt-repository etc - its the unique key for the thing.
<lifeless> noodles775: I don't know what IArchive.name property /means/
<noodles775> lifeless: ah, the apt url - right, I thought you meant the LP url.
<lifeless> noodles775: but here is my test: If I can be confused because someone else has a similarly named PPA, then the bug won't be fixed.
<wgrant> The URL, or ppa:wgrant/ppa?
<noodles775> wgrant: right - As long as owner ? ppa name is there it's sufficient to uniquely identify it. Currently the email includes the name, but not the owner (instead displaying info about the person who subscribed you, which won't always be the same)
<lifeless> wgrant: so, ppa:wgrant/ppa, and https://launchpad.net/~wgrant/+archive/ppa - either would be fine for me
<noodles775> Neither of those are actually accessible, but yes, the unique info is contained there.
<lifeless> and I don't want to pin noodles775 down to doing something that doesn't make sense, which is why I'm trying to keep it high level - that both the owner and url element, not the visible description, need to be visible.
<lifeless> noodles775: great, I shall be happy then
<noodles775> Yep, that's great. Thanks.
<adeuring> good morning
<maxb> What is the ettiquette for submitting branches to devel, which you know will cause a conflict in the stable->db-devel automerge?
<maxb> (It's just an unfortunately clashing import change)
<thumper> maxb: propose for devel, and land
<thumper> maxb: once in devel, merge into db-devel
<thumper> maxb: when the automatic merge from stable -> db-devel happens, it is a no-op
<mrevell> Hi.
<thumper> hi mrevell
<maxb> Thanks
<maxb> gmb: When you have time, could I trouble you for review of the additional unreviewed changeset in https://code.edge.launchpad.net/~maxb/launchpad/use-hashlib/+merge/18894 ? - thanks
<lifeless> hi jml
<jml> lifeless, hi
<jml> jelmer, hi
<gmb> maxb: Sure, I'll look now. Sorry, I forgot all about that yesterday
<gmb> maxb: Looks good.
<gmb> maxb: Want me to ec2  it ?
<maxb> Excellent ... yes please
<gmb> It's on its way.
<jelmer> jml, 'morning
<nigelb> any launchpad devs around? I have a feature request and want to know if it is technically feasible before requesting
<nigelb> Recently, we've been having quite a large amount of spam, is it possible to revert all the changes made by a user in this case?
<nigelb> now, we are manually having to change it.  That comes to modifying around 40 or so bugs
<jelmer> nigelb: The required information is present to do something like that, but I have no hard it would be to implement.
<jelmer> nigelb: please file a wishlist bug against Launchpad
<nigelb> jelmer, so shall I log a bug and hope for the best that it would be tried at some point?
<nigelb> oh, great. thanks
<wgrant> jelmer: It's not necessarily all present, sadly.
<wgrant> The activity log isn't perfect.
<wgrant> Although it's much better than it was a few months ago.
<nigel_nb> jelmer, bug 520413 opened in LP :)
<mup> Bug #520413: All changes by user must be revertable <Launchpad Bugs:New> <https://launchpad.net/bugs/520413>
<jelmer> nigel_nb, thanks :-)
<nigel_nb> could you please set that to wishlist?
<sinzui> nigel_nb: we do not use wishlist (we should remove that status). We use the feature tag and usually mark it as low. Low mean it will be fixed opportunistically, but the feature tag means we need a blueprint for it
<nigel_nb> sinzui, and the blueprint would be made at your end ?
<nigel_nb> i.e., anything nothing more I can do?
<sinzui> nigel_nb: not necessarily us. anyone may, and any feature should have one.
<nigel_nb> sinzui, so can I write (or get help from some one to write) one and add a feature tag?
<sinzui> nigel_nb: We only commit to working on high priority work. The priority is determined by our goals, oops, and some bugs. contributors can and do work on low priority features to improve launchpad for their community.
<sinzui> nigel_nb: I added that tag before you asked to have it set to wishlist :)
<nigel_nb> sinzui, well, I'm not a dev at all.  But I can create a feature spec if someone wants to work on it :)
<nigel_nb> I'm afraid this *could* potentially be high priority later on
<sinzui> nigel_nb: I think we really want to understand what needs to be accomplished and why. A spec implies we know that. We may want to change ACLs and that will make the suggested solution moot.
<nigel_nb> sinzui, um, what are ACLs?
<sinzui> access control list. If the the untrusted user could not make the change, there would have been no request to rollback the data.
<nigel_nb> sinzui, ah, well that makes sense too!  Either ways, it has become insane the last week rolling back changes
<wgrant> I think it's just been a particularly bad week.
<wgrant> Most weeks have no idiots. The last week had two.
<nigel_nb> True.  But it would be nice to have a fail-safe
<sinzui> jpds: ping
<jpds> sinzui: Pong.
<sinzui> jpds: my test for your api changes never enters the loop: http://pastebin.ubuntu.com/373951/ can you hit me with a clue-by-four so that I can test  the api changes?
<wgrant> Is that the broken unauthenticated launchpad.View adapter problem?
<thekorn> I think so
<sinzui> yes it is
<sinzui> thank you everyone.
<thekorn> bug 515761
<mup> Bug #515761: Anonymous API access to some collections returns nothing <qa-ok> <Launchpad Foundations:Fix Committed by jamalta> <https://launchpad.net/bugs/515761>
<sinzui> ...I should not have cargo-culted my anonymous test for this test
<wgrant> You should have.
<wgrant> It exposed another bug.
<intellectronica> thekorn: thanks for the work on the iperson_ihasbugs branch. the branch looks in good shape now. set the commit message and i'll land it for you
<thekorn> intellectronica, super, thanks. will set this message in a bit
<jpds> sinzui: I just mirror = ubuntu.getMirrorByName(name="releases.ubuntu.com") personally.
<sinzui> jpds: yes that works, but as wgrant and thekorn rightly noted, there is another bug. I tested it as anonymous and I could not get the mirrors. I am looking for the bad interface
<jpds> Groovy.
<wgrant> There is no launchpad.View for mirrors.
<wgrant> There needs to be, for other reasons, which will fix this.
<thekorn> intellectronica, I added a commit message
<intellectronica> thekorn: lovely, thanks.
<maxb> What's PQM up to, and is lp:~maxb/launchpad/use-hashlib coming up soon?
<bigjools> maxb: should have gone through now, the queue is empty
<maxb> Something's eaten my branch :-(
<maxb> I have a test results email confirming ec2 success
<maxb> Well, if it's not in devel and its not in PQM, could someone resubmit it directly to PQM for me?
<maxb> lp:~maxb/launchpad/use-hashlib  -> devel
<maxb> "[r=gmb][ui=none] Switch from using sha and md5 to hashlib. Also use hashlib.sha256 instead of the python-apt implementation."
<bigjools> it's in testfix mode :/
<thekorn> allenap, thanks for your comments ;)
<thekorn> allenap, ...and your patch
<allenap> thekorn: Cool, no worries. Thank you for doing the branch :)
<thekorn> allenap, I promise, future branches will have smaller diffs :)
<allenap> thekorn: It grew naturally, so no complaints here.
<thekorn> yeah that's exactly the problem here
<thekorn> allenap, when I move get_related_bugtasks_search_params() to bugs.model.bugtask should this IllegalRelatedBugTasksParams exception stay in registry.interfaces.person or can this exception be moved somewhere to bugs.*
<leonardr> flacoste: do you have time for a quick pre-impl chat?
<leonardr> the bug is https://bugs.edge.launchpad.net/lazr.restful/+bug/520542
<mup> Bug #520542: confusing latest_version_uri_prefix should be merged into active_versions <lazr.restful:New> <https://launchpad.net/bugs/520542>
<leonardr> basically, people who encounter latest_version_uri_prefix are confused
<leonardr> my plan is to not spell that our separately, just have it be the last version mentioned in active_versions
<leonardr> the underlying implementation would be the same
<leonardr> the only downside i can think of is it might be confusing to always have 'devel' or 'trunk' at the end of the list, and to slip versions into the list near the end instead of adding them at the end
<leonardr> but i think on balance it's better without latest_version_uri_prefix
<leonardr> let mek now if you agree
<flacoste> leonardr: agreed
<allenap> thekorn: Good question. lp.bugs.interfaces.bugtask seems likely, but I'll check.
<allenap> thekorn: Yeah, that's the place.
<thekorn> okidoki,moving it there, thanks
<kfogel> jml: thanks for the quick re-review
<salgado> deryck, around? is bug 520584 known?
<mup> Bug #520584: Person (assignee) picker is broken on +filebug <Launchpad Bugs:New> <https://launchpad.net/bugs/520584>
<deryck> salgado, yes.  I thought there was a bug for that already.
<salgado> I couldn't find one
 * deryck looks
<deryck> very aggravating.  I know I've seen a bug for this before.
<jtv> I'm tired of writing one-liner stub methods in my tests.  Unless something *simple* already exists, I'm introducing a helper class FakeMethod that gives you a stub for any function or method and counts the invocations.
<deryck> salgado, found it.  and marked yours accordingly.
<deryck> salgado, thanks for the heads up, though.
<salgado> thanks deryck
<mrevell> night
<jml> g'night all.
<thekorn> allenap, still around?
<kfogel> jml: g'night
<kfogel> deryck: any idea what's going on here?  http://paste.ubuntu.com/374133/   (i.e., why are there instances of "\n\t" in the submit message that PQM is quoting back to me, when they're not in the original?)  I don't see why we'd be in testfix mode...
 * deryck looks
<deryck> kfogel, we must be in testfix.  Checking builders now...
<deryck> kfogel, db_lp is in testfix
<kfogel> deryck: "db_lp" means db-devel or something else?
<deryck> kfogel, yeah, the db-devel builder.
<kfogel> deryck: hm, but this submission is to devel
<deryck> kfogel, yeah, but if either buildbot is broken we go into testfix mode.
<kfogel> deryck: oh, I didn't know that.  Okay, thanks.
<maxb> Is anyone working on un-testfixing?
<deryck> I seem to recall something about db devel in email this morning.
<mwhudson> good morning
<maxb> Are we un-testfixed now? If so, please could someone do a PQM submit for me?
<mwhudson> barry: ping?
<barry> mwhudson: pong
<mwhudson> barry: do you know anything about getting the magic gdbinit file to work with python2.5?
<mwhudson> maxb: yes, untestfixed it seems
<barry> mwhudson: i wasn't aware that it didn't work, but it's been a long time since i tried.
<maxb> <maxb> lp:~maxb/launchpad/use-hashlib  -> devel
<maxb> <maxb> "[r=gmb][ui=none] Switch from using sha and md5 to hashlib. Also use hashlib.sha256 instead of the python-apt implementation."
<maxb> That got ec2tested OK but apparently dropped on the floor presumably due to testfix
<barry> mwhudson: which gdbinit file are you using?
<mwhudson> i think it'll be ok with a non-debug build, but too much seems to get inlined into PyEval_EvalFrameEx in the release build
<mwhudson> man gdb's command language sucks
<bdmurray> where do the losa's hide out?
<mwhudson> bdmurray: here, among other places
<mwhudson> barry: i'm using the one from the release2.5-maint branch currently
<bdmurray> I'd like a Launchpad account suspended.
<mwhudson> aaaah
<mwhudson> gdb has an embedded python interpreter now
<barry> BOGGLE
<mwhudson> OH MAN
<mwhudson> ACTUAL PROGRAMMING WOO
<maxb> Sorry to nag, but as my message is vanishing up in the scrollback: Would someone be able to do a PQM resubmit for me?
<mwhudson> maxb: i guess i'm not very trusting, but i'd like confirmation that it passed ec2 from somewhere
<mwhudson> did gmb try to land it?
<maxb> quite understandable. Shall I forward the ec2test email to mwh@canonical?
<mwhudson> maxb: that'd be good
 * mwhudson grrs at gdb's python thing
<mwhudson> close but no cigar
<maxb> sent
<mwhudson> ok, got
<mwhudson> maxb: in pqm
<maxb> \o/
<wgrant> jelmer: I notice that your sync-source.py fix tests for lzma tarballs, which are not supported by dak or LP.
<EdwinGrubbs> maxb: ping
<maxb> EdwinGrubbs: pong
<EdwinGrubbs> maxb: I saw your email. I wasn't sure if that was something you were planning to work on, or if I should plan on doing it.
<maxb> This is about PIL 1.1.7, right?
<EdwinGrubbs> maxb: right
<maxb> The relevant change to debian/control is a mere 10 characters or so. I figured I'd leave it to you, as you can better explain why we need 1.1.7
<EdwinGrubbs> ok, cool
 * mwhudson lunches
<maxb> Hrm
<maxb> launchpad-database-dependencies is no longer installable on lucid, because postgresql-8.3-slony1 has been dropped
<wgrant> Oops.
<wgrant> Rebuild rebuild rebuild?
<wgrant> Or convince stub to fix 8.4..
<wgrant> maxb: Do you have any ideas on the lucid python-setuptools incompatibility?
<maxb> I've not looked at the slony1 source package, but adapting it to build for multiple postgresql versions doesn't sound all that fun
<maxb> wgrant: I've not examined it - I've literally just upgraded my desktop to lucid now, so I've been focussing on karmic+2.6 up til now
<wgrant> maxb: Ah, right.
<wgrant> Well, you'll probably need to download python-setuptools and python-pkg-resources to their karmic versions, because of the migration to distribute.
<wgrant> I must file a bug on that.
<maxb> Oh, the setuptools guys are starting to think about fixing the bug that stops us using pytz source#
<maxb> I need to get back to them about that, actually
<wgrant> Ah, good.
 * maxb wonders what the lp buildbot is up to
<maxb> 6 more revs in devel over stable seems high
<wgrant> It should be just a few minutes off merging.
<wgrant> (I'd guess < 10)
<maxb> I wonder if slony1 is actually needed for launchpad development environments
 * maxb ponders the idea of a slony1pg83 renamed source package that only builds the postgresql-8.3-slony1 binary (slony1-bin and slony1-doc unbuilt and coming from the lucid archive)
#launchpad-dev 2010-02-12
<maxb> After the next devel buildbot run, the stable->db-devel merger is going to hit a conflict
<noodles775> Hi all
<wgrant> Morning.
<adeuring> good morning
<maxb> Hi, it's my belief that the stable->db-devel automerge is currently broken due to conflict, due to branches of mine
<maxb> I have a resolved merge branch ready: https://code.launchpad.net/~maxb/launchpad/devel-10306-to-db-devel-resolve-conflict/+merge/19154
<noodles775> maxb: thanks, get it sorted.
<mrevell> G'Day
<allenap> thekorn: Morning :)
<thekorn> allenap, good morning
<thekorn> allenap, I'm about to push a new doctest for person.searchtasks()
<allenap> thekorn: Cool, I'll have a look in a bit.
<thekorn> allenap, I'm using factories there to generate sample data, but I'm having a hard time using this non-static data in this doctest
<allenap> thekorn: Often you have to do things like setting displayname to give something to match against.
<noodles775> maxb: sorry, i just re-read my message. Epic fail. s/get it sorted/I'll get it sorted.
<thekorn> allenap, yes, this works fine for Persons, but I'm also generating two sample bugs, and I found no way to preset the bug id
<thekorn> allenap, so I ended up with a comparing the bug_url, but you will find out about it ;)
<thekorn> pushed it now, btw.
<allenap> thekorn: Cool.
<thekorn> I *think* I've adressed everything
 * jml screws his courage to the sticking place and starts to work through the inbox
<allenap> thekorn: Looks good, ready to land :) One *tiny* thing. There's a lot of trailing white-space in the files you've touched. Can you clean this up, and perhaps set your editor to remove it automatically? If left it becomes a source of confusing diffs and conflicts; most/all of the LP team automatically remove white-space.
<thekorn> allenap, argh, ok, I'm on it
<allenap> mrevell: Did you want me to review this: https://code.edge.launchpad.net/~matthew.revell/launchpad/tags-help-484259/+merge/19114 ?
<mrevell> allenap, I have a call with jml now. Could we have a quick call after that? I'm still concerned about the icon placement.
<allenap> mrevell: Sure.
<mrevell> thanks allenap
<thekorn> allenap, I just pushe a fix for the whitespaces, but when running   make lint   I get alot of messages, even about parts that where not touched in this branch
<allenap> thekorn: Odd, I'll have a look.
<thekorn> allenap, I think this messages need to be fixed in devel itself, in a separate branch. for example when I change lib/lp/registry/interfaces/person.py in current devel by adding a whitespace and then run   make lint  I get alot of messages
<deryck> Morning, all.
<allenap> thekorn: I think you merged db-devel in r10132 instead of devel.
<allenap> thekorn: I think you're going to have to do a few uncommits to get back to that revision and revert it. I can't figure out how to revert it without mucking up history.
<thekorn> allenap, damn
<allenap> thekorn: You can probably save the diff of 10132..10134 and reapply it afterwards to save some time.
<thekorn> allenap, the brnach I get with rockertfuel-get should be lp:launchpad and not lp:launchpad/devel, correct?
<thekorn> somehow I messed thing up :(
<allenap> thekorn: For me it's lp:launchpad/devel.
<thekorn> allenap, I'm sorry, I 'll take care of it later today, or over the weekend,
<thekorn> sorry for the inconvenience
<allenap> thekorn: No worries. I can fix it up now if you want.
<thekorn> allenap, It is up to you
<thekorn> I've to run now
<thekorn> have a good weekend
<allenap> thekorn: Okay, I'll do it. You too :)
<allenap> thekorn: Thanks for this branch; it's great, and I'll get it landed.
<thekorn> super great
<gmb> Argh, can't we just grant * to * in the DB?
 * gmb hates at database permissions
<gmb> Does anyone with a bigger brain than me know why a cronscript would run fine normally but, when run via `run_script` in a unit test would fail on db permissions? Is possible it's being run as some other db user even though it's running in a subprocess?
<bdmurray> This url seems to have a spelling error or two
<bdmurray> https://help.launchpad.net/Bugs/BugAttchements
<bdmurray> However, its linked to from bugs.launchpad.net as help regarding attachments.
<bigjools> heh, mrevell ^^
<mrevell> thanks bdmurray, let me take a look at that
<allenap> gmb: You might know this. If I get ComponentLookupError: (<...IPlacelessAuthUtility>, ''), what's happening, and how do I solve it?
<bigjools> maxb: thank you thank you thank you for the hashlib cleanup
<maxb> :-)
<bigjools> in particular the soyuz crack to cope with hardy bustage
<maxb> barry deserves a lot of the credit, but I finished off what was abandoned on the python-migration2.6 branch
<bigjools> thank you barry then :)
<mrevell> Night all
<maxb> noodles775: You resolved my conflict wrong :-/
<noodles775> maxb: er, I'm not sure how that's possible? I simply merged stable->db-devel, and the only conflict was this
<noodles775> http://pastebin.ubuntu.com/375040/
<noodles775> ie. an import which was no longer used in the file.
<maxb> *blink*
<maxb> When I did my merge, "import sets" was inside the conflict markers too
<noodles775> maxb: is it just the lint on the file then? Or is there a bigger problem?
<maxb> Well, the objective of one of my earlier branches was to remove all imports of 'sets' from launchpad, since it raises DeprecationWarnings in python 2.6
<noodles775> I see. Strange that it didn't appear in the conflict then.
<noodles775> Night.
<noodles775> maxb: Just checking out of interest, the stable revision that I merged has the sha removed, but not sets, so the diff makes sense?: http://pastebin.ubuntu.com/375050/
<noodles775> That's stable r10312
<noodles775> maxb: in fact, bzr diff -c 10306 lib/lp/services/mail/sendmail.py seems to show that the import of sets wasn't removed in that rev, but was *moved*.
<maxb> Indeed, sets was removed in db-devel
<maxb> This was because it happened to touch a couple of scripts in the schema dir :-/
<noodles775> I see.
<wgrant> The entirety of database/schema is blacklisted, not just the schema?
<maxb> Apparently
<noodles775> maxb: I've approved the MP and have sent it to ec2.
<maxb> Thanks
<noodles775> morning wgrant, and good night :)
<noodles775> np.
<wgrant> Night noodles775.
<lfaraone> How does one turn off devmode on Launchpad?
<jelmer> lfaraone: What do you mean with devmode, the beta (edge) ?
<wgrant> In your configuration's launchpad.conf, remove the 'devmode on' line.
<lfaraone> jelmer: I meant for running LP locally.
<lfaraone> wgrant: ah, mk.
<wgrant> lfaraone: You know about the licensing restrictions?
<lfaraone> wgrant: yes, I'm aware.
<lfaraone> wgrant: I'm not intending to run this full-time, but rather as a demo that our project is capable of running Launchpad outside of launchpad.net if we ever have a reason to leave. I personally think the idea's silly, but I'm not on the board :)
<wgrant> lfaraone: Oh, right, I remember your situation now.
#launchpad-dev 2010-02-13
<quentusrex> anyone awake?
<bjf_> anyone using groovy with the launchpad api?
<quentusrex> Any devs in here?
<quentusrex> I've found a bug that is only happens when a package is built on launchpad.
<lifeless> quentusrex: not a bug, a feature :). Debian guidelines say you can't rely on internet connectivity for buildds, and ubuntu buildds /all/ have internet disabled while building.
<quentusrex> thanks lifeless
<quentusrex> It was an application build bug. It wasn't erroring out the build when it was missing a set of libs
<quentusrex> So, it was completing the build, just with large chunks missing.
<lifeless> thats also a packaging bug
<lifeless> your install rules are so generic debhelper won't error
<lifeless> if you make them a little more specific it can error for you
<quentusrex> yeah, that is what I noticed too
<quentusrex> it won't error out if you have a * in the install rules.
<lifeless> thinking about this, thats worth filing a bug on debhelper
<lifeless> well
<lifeless> if your build was finding 0 files it worth filing a bug on
<lifeless> if it found 1 (e.g. a symlink file or something) then its not as obviously a bug in debhelper
<quentusrex> it wasn't finding any of the files that would have matched the * line
<lifeless> then I suggestyou file a bug on it
<_Groo_> hi/2 all
<_Groo_> is  dput still broken?, i wanna contribute some new packages but i cant upload a 25k package!!!
<maxb> _Groo_: that is more a topic for #launchpad
<_Groo_> maxb: k
#launchpad-dev 2010-02-14
<dhillon-v10> hi all, can anyone really quick tell me how to run a test
<maxb> dhillon-v10: ?
<dhillon-v10> maxb: hi :) alright so I made a change in the code for a bug, now I want to see if it works or not, I have to edit the test for that feature right?
<dhillon-v10> maxb: the story file actually
<dhillon-v10> maxb: I am talking about this file: lib/lp/soyuz/stories/ppa/xx-ppa-workflow.txt
<maxb> right.... so I'm still not sure what your question is
<dhillon-v10> maxb: sorry for being ambigious, so here's what I am trying to do, I made a change in a feature, now I want to see how that change looks in my local launchpad, before I commit to my branch, so how do I do that?
<maxb> You're still being ambiguous :-)
<maxb> You started off talking about tests, now you're asking how to run a local launchpad?
<dhillon-v10> maxb: no, how to run a test in my local launchpad instance
<maxb> tests don't run "in a launchpad instance"
<dhillon-v10> maxb: i found this page: https://dev.launchpad.net/Testing
<maxb> I'm guessing that 'bin/test -vvt xx-ppa-workflow.txt' might be what you're after
<dhillon-v10> maxb: YES :)
<dhillon-v10> maxb: so make changes in that file and then run it using the command you gave ?
<dhillon-v10> maxb: i think i get it, thanks :)
<dhillon-v10> maxb: can you tell me if this is valid: http://paste.ubuntu.com/375856/
<maxb> valid?
<maxb> The logic looks wrong to me
<dhillon-v10> maxb: what's wrong with it? sorry I am new to launchpad coding, that's why i am making a lot of errors
<wgrant> The logic is fine (assuming fixed indentation). The name is not.
<dhillon-v10> wgrant, maxb: this is what I am working on: https://code.launchpad.net/~dhillon-v10/launchpad/fix-bug-410331/+merge/18817 and wgrant please explain what's wrong with the name
<wgrant> dhillon-v10: The name for additional PPAs is missing and space, and self.context.owner.name is not what you want there.
<wgrant> s/and/a/
<dhillon-v10> wgrant: alright so what should be there instead of self.context.owner.name, maybe somthing like "PPA named X"
<wgrant> The name of the PPA, which probably does not at that point exist.
<dhillon-v10> wgrant: yeah, because the ppa doesn't even exist (this only works when the first ppa is activated) how do I get the name of that ppa, i think a name should be hardcoded like X
<wgrant> You should maybe talk to a UI person, but such a person no longer exists.
<dhillon-v10> wgrant: thanks for your help :) I'll present both options and see what Julian (my reviewer atm) says fits the best in that case
<maxb> The perfect option would be for the displayname to suggest itself with javascript as someone types the name. But that would be hard
<dhillon-v10> maxb: agreed, that's quite a bit of coding
<wgrant> There is already code to do something similar.
<wgrant> In the guided project registration form
<dhillon-v10> wgrant: so should I work on porting that here ?
<wgrant> You should talk the to relevant developers with domain knowledge.
<wgrant> ie. somebody from Soyuz.
 * maxb comes across database/dia/ :-)
<maxb> I feel like an archaeologist :-)
<thumper> morning
<mwhudson> thumper: morning
<thumper> mwhudson: morning
<thumper> mwhudson: when do you want to do a call?
<mwhudson> thumper: now-ish works for me
<thumper> mwhudson: let me top up my coffee first
<magcius> Is a hosted wiki feature in the works for 4.0?
<thumper> magcius: we don't know yet
<thumper> magcius: although some people are investigating a bzr backed wiki in off hours
<magcius> thumper, alright
<maxb> If there's a code team person around, what does "Next mirror: Disabled" mean in this context: https://code.edge.launchpad.net/~jelmer/bzr-rewrite/trunk-mirrorred ?
<poolie> maxb i suspect it means that someone manually turned it off
<poolie> i don't know why
* mwhudson changed the topic of #launchpad-dev to: Launchpad Development Channel | Week 2 of 10.02 | PQM is open | https://dev.launchpad.net/ | Get the code: https://dev.launchpad.net/Getting | On-call review in irc://irc.freenode.net/#launchpad-reviews | Use http://paste.ubuntu.com/ for pastes | Channel logs: http://irclogs.ubuntu
<maxb> ok
<poolie> mwhudson: ^^?
<mwhudson> poolie: seems like a reasonable guess
<thumper> maxb: if the mirroring fails 5 times in a row, we disable it
<mwhudson> $ gnome-open /home/mwh/Desktop/MockupsForDesktop.air
<mwhudson> $ Error loading the runtime (libadobecertstore.so: cannot open shared object file: No such file or directory)
<maxb> thumper: ok. can I find out the failure cause somehow?
<thumper> maxb: not sure... should be able to
<thumper> maxb: I would have thought it would show on the page already
<maxb> Since it doesn't, is it "ask a LOSA" time?
<wgrant> mwhudson: Copy /usr/lib/adobecertstore.so to /usr/lib32.
<mwhudson> wgrant: i found the appropriate page in the end
<mwhudson> thanks though
 * thumper off for Maia collection, coffee and lunch
<wgrant> thumper: Ah, good, more LP devs using Chromium. LP might get unbroken in it!
#launchpad-dev 2011-02-07
<huwshimi> lifeless: On #712894 you mentioned some helpers to preload user's avatars. Are there any docs on how to use that or can you explain where I might start?
<_mup_> Bug #712894: Display avatars next to usernames instead of icons <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/712894 >
<lifeless> getUtility(IPersonSet).cacheBrandingForPeople(participants)
<lifeless> see model/person.py for the gory details
<huwshimi> lifeless: Thanks mate
<cjohnston> is there any plan on setting up LP to be translated?
<huwshimi> lifeless: Do I need to use that once on all the users that need an avatar on the page, or can I call it whenever I want (note, this is an exercise in me learning the codebase, so I might be asking dumb questions)?
<lifeless> cjohnston: there was discussion @ UDS, met favourably, to do so. But its not scheduled.
<lifeless> huwshimi: that should (I haven't checked that its correct :P) be called once on a page, because doing one person at a time would be terribly slow.
<cjohnston> im guessing alot of work involved?
<huwshimi> lifeless: Ok thanks, I'll look into it a bit more... might not be feasible to do that then.
<lifeless> huwshimi: it is going to need to be called once, for *every page* that starts showing avatars
<lifeless> huwshimi: or performance will go to the toilet.
<huwshimi> lifeless: Yeah, that is going to be a big issue
<Ronnie> how is https://login.ubuntu.com/ connected to https://login.launchpad.net/
<wgrant> Ronnie: They are just alternative skins for the same service.
<wgrant> Same DB.
<spm> same servers even
<wgrant> The latter will hopefully go away eventually.
<lifeless> huwshimi: its going to need extreme care
<wgrant> Ubuntu services should prefer the forer.
<wgrant> +m
<lifeless> cjohnston: a moderate amount of work
<cjohnston> If you create a login.u.c you dont have an LP account though correct?
<Ronnie> wgrant: so when you register on ubuntu.com you can login to LP?
<wgrant> Ronnie, cjohnston: You don't automatically have an LP account if you create an account on either.
<wgrant> But if you try to log into Launchpad, it will redirect you to login.launchpad.net. You can then log in using your login.ubuntu.com account, and Launchpad will create an account for you.
<wgrant> LP is an OpenID consumer, just like LD.
<wgrant> (except that login.ubuntu.com and login.launchpad.net use a private interface to return data from the linked LP account, if it exists)
<cjohnston> wgrant: the reason for the questions is that people are wanting to move away from the LP requirement for LP.. but the devs dont really see it as possible
<lifeless> cjohnston: the which requirement for LP ?
<cjohnston> lifeless: you must have an LP account to be a part of a team, and to register for an event/meeting
<lifeless> cjohnston: you said 'LP requirement for LP'
<lifeless> cjohnston: this confused me
<cjohnston> People don't like sorry
<cjohnston> LP requirement for LD
<lifeless> ok
<lifeless> right, with that cleared up
<thumper> why do I often feel like I'm the first person to do something :-(
<lifeless> LP maintains the team database
<thumper> writing lazr-js tests
<cjohnston> correct
<lifeless> so I don't think you're going to get away from that at all easily; and there are no plans to make SSO maintain teams
<cjohnston> People 1) dont like the fact that they have to sign up somewhere other than LD... and 2) that LP isnt translated
<cjohnston> right
<lifeless> (SSO teams are mirrored from LP)
<cjohnston> lifeless: thats what the couple devs have a hard time explaining to people
<lifeless> we'd take patches for I18N of LP
<cjohnston> I bet
<cjohnston> heh
<lifeless> at one point we wouldn't have.
<lifeless> but I think that that bridge has been successfully fixed.
<wgrant> Excellent.
<Ronnie> cjohnston: can we set login.ubuntu.com as openid provider?
<Ronnie> i tested locally and worked fine with login
<wgrant> For a while it wasn't open to arbitrary consumers, but I think that changed a few months ago.
<Ronnie> hmm, but for joining a team, we still need to login to LP
<cjohnston> users still need lp accounts to make LD useful...
<lifeless> Ronnie: login.ubuntu.com is fine.
<Ronnie> cjohnston: they need to login only once to LP to join the team, but for other parts the l.u.c. should be fine (altough the mugshot is also in LP)
<cjohnston> correct.. so why not just leave it the way it is since they still have to go into lp?
<Ronnie> lifeless, wgrant: is there an alternative way to join a lp team, than the webpage?
<lifeless> Ronnie: apis, but the user still has to accept the membership
<wgrant> lifeless: No, they don't :(
<lifeless> and you can't talk about a user until they sign into LP once.
<wgrant> Right.
<wgrant> The LD can add people to teams.
<lifeless> wgrant: as part of the disclosure work that should be fixed
<wgrant> But they need to have an LP account first.
<wgrant> And there's no way to create one of those unless the user logs in.
<wgrant> Or you are the Software Center Agent (ugh)
<Ronnie> wgrant: is it possible to do one login to LP in the background, so the user is not aware (or manually restyle the page somehow?)
<Ronnie> lifeless: and how should the user accept the membershit trough api?
<wgrant> That would be very bad.
<Ronnie> making programms userfriendly, is sometimes choosing between 'the bad stuff' of the 'hard stuff' ;)
<Ronnie> of = or
<lifeless> Ronnie: they would get an email with a link to click on
<lifeless> os
<lifeless> so
<lifeless> what teams does LD care about?
<Ronnie> all the team which are subteams of the main loco team (cant remember the name)
<cjohnston> ubuntu-locoteams iirc
<Ronnie> https://launchpad.net/~locoteams
<lifeless> anyhow, I don't see - in principle - a problem with designing and building a facility for LD and other closely affiliated sites to have impersonation facilities for users.
<lifeless> whether that looks like LP APIs or something radically different is an open question.
<cjohnston> but we also have a plan of adding a "sister" to LD being a global directory which will provide the meeting feature (and upcoming team reports) to all teams that want it
<lifeless> the SCA approach seems rather unscalable from a risk perspective to me.
<Ronnie> SCA?
<lifeless> software centre agent
<Ronnie> lifeless: so having an API for 'trusted affilated'  sites is an option?
<lifeless> yes
<lifeless> I've spent approx 0 time thinking about the necessary requirements and constraints for it though.
<Ronnie> cjohnston: i think thats a very good solution
<cjohnston> Except for what lifeless just siad
<cjohnston> said
<Ronnie> indeed
<Ronnie> lifeless: and the 'one time lp login' can that be solved by the same API (in your first toughts)
<lifeless> Ronnie: if LD was able to act as an LP frontend
<lifeless> Ronnie: then it could create accounts given an sso signed in user, add them to teams etc
<Ronnie> but is haveing LD as a frontend not very dangerous without limiting the features?
<lifeless> Ronnie: thats right, thus - 13:30 < lifeless> I've spent approx 0 time thinking about the necessary requirements and constraints for it though.
<lifeless> we'd be separating the business logic from presentation
<lifeless> and we'd need an impersonation api for the glue
<lifeless> so you could say 'on behalf of <ld logged in user> create a LP account'
<lifeless> but the integrity of the system would be maintained by the LP middleware
<Ronnie> i have to sleep and think about it for a while. i added this channel for auto join
<lifeless> cool
<Ronnie> till soon
<thumper> huwshimi: ping
<huwshimi> thumper: Hello
<thumper> huwshimi: do you know how to get some javascript to drop into the firebug debugger?
<thumper> huwshimi: I think it is something like " Y.debug() "
<wgrant> Ronnie: But we cannot sacrifice security like that for user friendliness.
<wgrant> Except perhaps as lifeless suggests.
<huwshimi> thumper: console.log();
<wgrant> In a very restricted context.
<huwshimi> thumper: That will work on Chrome debugger too
<thumper> huwshimi: I don't want to log stuff out, I want to debug some javascript
<huwshimi> thumper: What kind of info do you want?
<thumper> I want to interrogate the DOM state mid function call
<thumper> I'm not sure if my test is wrong, or the code isn't doing what it says it should
<thumper> I'm trying to add a test for the multi line lazr-js editor
<huwshimi> thumper: There is console.debug, but I can't remember what it does
<thumper> huwshimi: ok, ta
<huwshimi> thumper: Check out this page: http://getfirebug.com/logging
<huwshimi> thumper: It has info about stack traces etc.
<huwshimi> thumper: From memory if you log a reference to a function you can get a whole pile of info from it
<huwshimi> thumper: So if you do a console.log(YAHOO.util.Dom) or whatever it should give you an object with a bunch of properties
<huwshimi> thumper: Just ducking out for a minute. Let me know if that doesn't help you and I'll get to it when I'm back
<lifeless> wallyworld_: can I have a review please of https://code.launchpad.net/~lifeless/launchpad/bug-661988/+merge/48740 ?
 * wallyworld_ looks
<thumper> huwshimi: ack
<wallyworld_> lifeless: is this an r-c for 11.02?
<lifeless> wallyworld_: no
<lifeless> wallyworld_: it will halve the time taken to do distribution bug searches
<lifeless> wallyworld_: which is a nice improvement, and will drop a top 10 timeout out of the list
<wallyworld_> lifeless: sure. a question - why is product_ids.discard(None) needed?
<lifeless> wallyworld_: that should be obvious :)
<lifeless> wallyworld_: there are multiple different contexts a task can be target to.
<wallyworld_> ah, ok.
<wallyworld_> and we were using a left join
<wallyworld_> previously
<lifeless> the left join was crack and is unrelated
<wallyworld_> osrry for the dumb question
<lifeless> bug:bugtask is 1:M
<lifeless> bugtask.bug is never NULL
<lifeless> and bugs always have one or more bugtasks.
<lifeless> wallyworld_: the linked bugs in the mp explain it all
<wallyworld_> and the list(store.find(..)) inside the pre_iter_hook causes the results of the find to be cached for use by the main result set when it iterates?
<lifeless> yes
<lifeless> they sit in the storm cache
<lifeless> then by-id lookups will succeed
<wallyworld_> cool. that wasn't obvious to me :-) storn noob ;-)
<lifeless> reasonably common idiom in lp
<wallyworld_> should there be a one line comment to that effect then in case anyone else reading the code is not sure - just to make it explicit?
<wallyworld_> or if it's well known, no need
<lifeless> its in a function called eager_load
<lifeless> I think a comment would be adding neon lights
<lifeless> it might be nice to have a function on StormResultSet that will completely iterate the set
<lifeless> just for this
<wallyworld_> suppose, but in general calling list() without assigning the result to anything may not always be "obvious" what it does. but that may just be me.
<lifeless> I think it would be sad to have identical comments all over the code base saying this
<thumper> \o/
<thumper> stupid js tests now working
<thumper> debugging the tests sucks badly
<thumper> but they are working
 * thumper wonders how to commit to lp:lazr-js
<wallyworld_> thumper: did you find out how to get access to the DOM then?
<lifeless> thumper: bzr lp-land
<thumper> wallyworld_: no
<thumper> wallyworld_: but I found the bug in my code
<lifeless> thumper: after its reviewed :)
<thumper> lifeless: it is reviewed
<lifeless> thumper: it just uses the normal lp pqm
<wallyworld_> thumper: that sucks. there has to be a better way to debug that sort of stuff
<thumper> wallyworld_: agreed
<thumper> wallyworld_: it was a real PITA
<lifeless> thumper: can you mentor ian's review of https://code.launchpad.net/~lifeless/launchpad/bug-661988/+merge/48740 ?
<wallyworld_> thumper: maybe my IDE can do it :-)
<lifeless> wallyworld_: btw, why do you say 1000 items in an IN clause is an issue ?
<wallyworld_> lifeless: that's when databases start to get inefficient. oracle actually has a hard 1000 item limit - it throws an exception. postgres i believe has a soft limit - it doesn't complain but performance goes south
<lifeless> wallyworld_: I think its an overly naice heuristic
<lifeless> wallyworld_: I've seen fine performance up at 15K items in IN clauses
 * wallyworld_ wonders what naice means
<lifeless> wallyworld_: *naÃ¯ve*
<wallyworld_> lifeless: wow. 15K items!!!!! that suggests to me that the query could be reconstructed
<wallyworld_> /scould/should perhaps
<lifeless> wallyworld_: that application had two different dbs; the output from the query on one db went into the query on the other.
<lifeless> wallyworld_: but the point is, performance was fine
<wallyworld_> sounds like a job for a temp table then
<lifeless> wallyworld_: at 15 times the point of the 1000 limit you've seen before
<wallyworld_> hmmm. i'll have to read mor eon what postgres can do. maybe i've been brainwshed by working with oracle
<lifeless> wallyworld_: temp table would help if they were doing more than one query in the second db
<lifeless> wallyworld_: this is one of those 'unless its been measured its irrelevant' cases
<wallyworld_> sure. i've tended to use exists when the in list is large. but again, that may be my oracle bias coming out
<lifeless> that seems bonkers
<lifeless> the exists subsquery would have to have the IN list as well
<mhall119> cjohnston: yup
<lifeless> or you would have to write a temporary table, and select from that
<lifeless> which is equivalent with any sensible implementation of IN
<wallyworld_> i don't think oracle has a sensible implementation :-) it's always been a pita actually
<wallyworld_> \o/ buildbot finished building db-devel rev 10180
<StevenK> thumper: O hai?
<StevenK> wallyworld_: ORA had some good ideas. They counter this with some *shocking* ones.
<lifeless> StevenK: like what community means? :)
<wallyworld_> lifeless: you took the words right out of my keyboard
<wgrant> lifeless: The Launchpad definition of community sucks too :P
<lifeless> wgrant: less
<lifeless> wallyworld_: btw
<lifeless> wallyworld_: for the bind variables patch
<StevenK> lifeless: I was talking just in terms of the Oracle database product -- which has a vibrant community
<wgrant> lifeless: The MP definition of community, that is.
<lifeless> wallyworld_: test_bugtask_search has at least several patches that trigger the failure
<lifeless> wgrant: even that fails less
<StevenK> wgrant: In terms of what? Military Police? :-P
<lifeless> s/patches/tests/
<wallyworld_> lifeless: yeah, and also nascentupload tests too
 * wallyworld_ is impatient for staging to get rev 10180 deployed
<wgrant> Are we going to unfreeze as soon as we are QA'd past the merge?
<lifeless> wallyworld_: while you wait, get that bind variables thing underway :)
<lifeless> wgrant: yes
<wgrant> Yay.
<wallyworld_> wgrant: yeah
<wallyworld_> lifeless: i have some recipe stuff to do first
 * wallyworld_ has too many concurrent tasks
<lifeless> bad idea ;)
<wallyworld_> yes
<StevenK> lifeless: So, in leiu of thumper -- I have fixed 683321 -- but I'm not happy with my fix
 * wgrant throws fire at checkwatches.
<lifeless> StevenK: shoot
<lifeless> wgrant: so fix it
<lifeless> wgrant: btw I did some analysis of the perf bugs you had in progress; hope it helped.
<StevenK> lifeless: http://pastebin.ubuntu.com/563642/ is my diff
<wgrant> Those statement counts of 10000 are a bit suspicious.
<wallyworld_> wgrant: what was the end result of qa on rev 12321? did you come to the conclusion it is ok?
<lifeless> wgrant: its not establising a new request context on each watch
<lifeless> wgrant: very shallow fix
<wgrant> wallyworld_: It seems to work, and hasn't broken anything that I can see. But I don't know Translations in depth.
<lifeless> StevenK: whats unsatisfying about that ?
<StevenK> lifeless: If you look at lib/lp/code/browser/sourcepackagerecipe.py, lines 528-545 and lines 631-650 (but my line count is off due to said diff)
<wgrant> wallyworld_: I'm happy to qa-ok it, given how harmless the fix seems.
 * wgrant qa-ok's it.
<wallyworld_> wgrant: hennige is going to qa it as his SOD but that's a few hours away yet. we'll have to wait
<StevenK> lifeless: Compare and contrast those two code blocks
<wallyworld_> wgrant: ok. i'll make sure it's followed up. thanks
<lifeless> StevenK: yes
<StevenK> They're effectively indentical
<lifeless> right
<lifeless> needs to be pulled out sideways
<StevenK> lifeless: Which is what is my question is -- how?
<lifeless> looks like a method on RecipeRelatedBranchesMixin would come close to trivial
<StevenK> lifeless: I was going to suggest RecipeTextValidatorMixin
<lifeless> StevenK: even better
<StevenK> lifeless: I might need a little more of a hint :_)
<lifeless> StevenK: do you have the book 'refactoring' ?
<StevenK> Nope
<lifeless> I suggest you grab it; you should be able to expense it bu tcheck with your mgr first.
<lifeless> the martin fowler one
<lifeless> anyway
<lifeless> what you need to do is:
<lifeless> identify the common code
<lifeless> if it surrounds some different code, you're going to need a callable or some such
<lifeless> rearrange both locations until they are truely identical
<lifeless> then move one of them to the mixin, turning local variables into parameters
<lifeless> the other copy becomes just a call.
<lifeless> StevenK: http://martinfowler.com/books.html#refactoring
 * thumper is back now
<StevenK> lifeless: Examples using Java and UML?
<lifeless> yes
<StevenK> And this is a *good* thing?
<lifeless> the basic structures are the same
<lifeless> there are some things that don't translate well to python
<lifeless> e.g. accessors
<lifeless> and balancing it with performance is a bit of an art
<lifeless> but there is a tonne of good shit well presented
<huwshimi> thumper: Just saw your post to the mailing list about lazr-js. When we were in Dallas he/we started to do the upgrade but hit failing tests with the new version of YUI. I'm not sure of the status of those problems though.
<thumper> huwshimi: I recall that there was something going on
<thumper> I didn't want to duplicate effort in fixing the tests
<huwshimi> thumper: I don't remember the specifics of what was breaking, but I think it might have been something that Deryck couldn't fix directly
 * thumper nods
<thumper> I'll catch up with deryck in the morning
<poolie> is this change to using courier as the fixed width font intentional?
<wgrant> I've not heard anything about font changes recently.
<poolie> in chromium, launchpad today started using a fairly ugly monospace font
<wgrant> You didn't install msttcorefonts yesterday?
<wgrant> Hmm.
<wgrant> Chromium 9 was pushed out to Ubuntu yesterdayish.
<poolie> it seems to want
<poolie> font-family: "UbuntuBeta Mono","Ubuntu Mono",monospace;
<huwshimi> poolie: It looks like if you don't have the Ubuntu Mono font it will default to whatever your browser/os default mono font is
<poolie> I have "Ubuntu Beta Mono 17"
<poolie> from "Walled Garden of Temptation"
<poolie> is there a font "UbuntuBeta Mono"?
<huwshimi> poolie: I don't think that would cut it
<wgrant> poolie: That was the name we were given months ago, before a mono variant existed.
<wgrant> Apparently they did not follow their scheme.
<poolie> apparently not
<poolie> do either of you have "Ubuntu Mono" or "UbuntuBeta Mono"?
<huwshimi> poolie: nope
<huwshimi> I should though
<huwshimi> poolie: I can tell you how to rename the font
<poolie> i guess that chromium's change may have it no longer interpreting "monospace" as meaning the system monospace font
<poolie> which is probably a bug there too, but lp has a bug if it's asking for ubuntu fonts that don't/won't exist
<poolie> huwshimi, how?
<poolie> istr you can make aliases in fontconfig
<huwshimi> poolie: The way I would do it would be to modify the font itself (or a copy of the font)
<huwshimi> poolie: but you might be right about using aliases
<lifeless> well
<lifeless> we shouldn't have poolie rename the font
<lifeless> we should update lp to use the name actually used by the font
<james_w> well, I doubt the number will be in the final name
<huwshimi> lifeless: I suspect that poolie has a pre-release version with a version number in the name
<poolie> right
<poolie> i think _everyone_ has a version number in the font
<poolie> if they have it at all
<huwshimi> poolie: I guess people will have different version numbers though
<poolie> https://bugs.launchpad.net/launchpad/+bug/714381
<_mup_> Bug #714381: launchpad css asks for "UbuntuBeta Mono" font that doesn't exist <css> <easy> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/714381 >
<poolie> huwshimi, yeah
<poolie> i find that a bit weird, but i guess that's their decision
<poolie> we could ask for 17
<poolie> or prefer 20, 19, 18, 17, ...
<huwshimi> poolie: neither Chrome or Firefox respect the os's default font it seems.
 * thumper EODs
 * wallyworld_ wonders why staging seems to be taking so long to come up again
<lifeless> wallyworld_: we'll find out when spm returns
<wallyworld_> lifeless: is he the one who also needs to then do the merge into devel etc
<wallyworld_> lifeless: i'm off to pickup the kid from school. will check back in 30 minutes or so to see the status of staging
<lifeless> wallyworld_: see -ops
<lifeless> wallyworld_: will need stubs input to recover
<lifeless> wgrant: view-source:https://qastaging.launchpad.net/ubuntu/+archive/asuka-wants-to-get-rocked/+index
<lifeless> At least 80 queries/external actions issued in 9.28 seconds
<lifeless> wgrant: I'm just impressed its rendering on qastaging
<wgrant> lifeless: Oh wow.
<wgrant> That's nice.
<wgrant>     At least 4 queries/external actions issued in 0.08 seconds
<lifeless> ?!
<wgrant> Ah, I can't see it.
<wgrant> That's fewer queries than I would have expected for an Unauthorized, though.
<lifeless> oh, needs to be enabled ?
<wgrant> I guess it reinitialises the view.
<wgrant> Yeah.
<lifeless> yeah, it does
<lifeless> https://qastaging.launchpad.net/ubuntu/+archive/asuka-wants-to-get-rocked should work for you now
<lifeless> I wish we had a discrete menu at the top like gmail does
<wgrant> Hm?
<huwshimi> lifeless: You mean like a global navigation/user specific options sort of thing?
<lifeless> yes
<lifeless> huwshimi: oh excellent, you are here
<lifeless> is span still appropriate to wrap something inline in a paragraph ?
<lifeless> silly tal wants hierarchical containers :(
<huwshimi> lifeless: Yes, a span is good.
<wgrant> lifeless: If you don't actually want the element to be there, you can just use a <tal:ANYTHING replace="foo" />
<huwshimi> lifeless: I was thinking the exact same thing about the global nav earlier today. I came to the conclusion that it depends what launchpad wants to be. At the moment, once you get to a project you're pretty much stuck there (except by using the links in the footer or clicking your name at the top right). This makes Launchpad good if you want Launchpad to be quite invisible. If Launchpad wants to be more collaborative
<huwshimi>  and feel like a destination itself (rather than the project being the destination) then I think some global navigation would go a long way to making Launchpad more whole.
<huwshimi> I think.
<wgrant> AFAICT the point of LP 3.0 was to make LP disappear.
<wgrant> The project was made the prominent entity.
<huwshimi> wgrant: Right. So it depends what Launchpad wants to be.
<wgrant> Exactly.
<huwshimi> I get the feeling that Launchpad may move back away from that
<lifeless> FWIW I'd be looking at a balancing act
<lifeless> I think lp is terribly hard to navigate at the moment
<lifeless> but its easy to jump around within a project on lp.
<huwshimi> lifeless: I guess it's something we should talk to jml about?
<lifeless> wgrant: ah yesm cool. thanks.
<lifeless> huwshimi: I think that would be a good start; OTOH this is arguably small fry right now given the massive lack web2.anything ;)
<huwshimi> lifeless: It might be small fry, but I think it's these little steps that quickly add up to creating a lot of impact.
<huwshimi> lifeless: I'll shoot jml an email about it
<lifeless> huwshimi: cool
<huwshimi> lifeless: Do you have a minute to talk about another navigation issue?
<lifeless> sure
<lifeless> huwshimi: trade you for a little dom glue
<huwshimi> lifeless: Deal.
<lifeless> so, what can I help you with ;)
<poolie> draft post about web_link: http://blog.launchpad.net/?p=1916&preview=true
<huwshimi> lifeless: I was wondering if you knew what technical advantages we gain by having our "apps" (bugs, code etc.) on different sub-domains, if any.
<poolie> :)
<lifeless> huwshimi: it costs us
<huwshimi> lifeless: Oh, in what way?
<lifeless> huwshimi: its complex to do, to maintain, has a performance cost on domain switches.
<huwshimi> lifeless: Right.
<lifeless> clicking on code, for instance, -> 6 second delay to do SSL handshake (for you or I
<poolie> huwshimi, i think it's a bit of an artifact of there once being a plan to make them more separated
<lifeless> its a solution to one ui problem, which is 'what url to give a different rendering of a single object'
<huwshimi> poolie: yeah, I read Mark's blog post about it.
<lifeless> huwshimi: url for that?
<huwshimi> lifeless: http://www.markshuttleworth.com/archives/30
<poolie> :)
<poolie> keeping people in the zone is good, but i don't know that splitting the url is the most useful thing to get there
<poolie> but that's 5 years ago now
<huwshimi> lifeless: I'm just speculating now, and really just doing research, but would would be the cost of migrating off subdomains?
<lifeless> huwshimi: I dislike estimating for other people.... but I think a feature squad could do the heavy lifting in a week.
<lifeless> huwshimi: there are several steps needed:
<lifeless>  - we need to map the existing content into the main url hierarchy. E.g. we could put +blueprint at the end of a url to mean what currently blueprints....../thing/ means
<lifeless>  - we need to decide on a forwarding strategy for the old urls (e.g. do it in apache, or in the appserver indefinitely or ...)
<lifeless>  - we need to assess the usability impact - and benefits [this is a LEP level thing I think]
<lifeless>  - and we need to execute
<lifeless> I *think* some clever code in the publisher could do the initial translation for us, but we'd want a way to be really clean internally going forward.
<wgrant> Moving the pages off subdomains is very easy.
<wgrant> There may be some slight issues getting the facet breadcrumbs to work properly.
<wgrant> But that's about it.
<lifeless> wgrant: right; and we have to retain urls to show all the facets
<wgrant> We already have those.
<wgrant> But we might want to rename them.
<wgrant> (+code-index, +bugs-index, ettc.)
<lifeless> ah, I hadn't actually read that bit of glue; ok, so yes, what I thought could be written has been.
<wgrant> There are some views (mostly Code and Translations) that exist only on the relevant domain.
<stub> Our bzr-git is still oldformat bzr repo
<wgrant> But they are very much the exception.
<lifeless> also a source of user complaints
<wgrant> Yes.
<lifeless> notwithstanding the issue with sending api calls to the right place, I'd like to fix that.
<wgrant> Particularly the lack of Branch:+index.
<wgrant> It vanished a couple of months back :(
<lifeless> success
<lifeless> 15 queries/external actions issued in 0.18 seconds â¢ lifeless â¢
<lifeless> huwshimi: ok, so
<lifeless> huwshimi: I've got this little bit of text I want to show up beside my login
<lifeless> huwshimi: the problem is that it has to be rendered *after* all the rest of the page.
<huwshimi> lifeless: Yeah thanks for that. It was very helpful.
<lifeless> huwshimi: its only going to show for developers
<lifeless> whats the best way to make it show up where the login name is, but have it evaluated at the end of the page.
<lifeless> e.g. is a <script> segment appropriate, or something else ?
<huwshimi> lifeless: What does it need that is only available at that point?
<lifeless> the amount of time that the page takes to render
<huwshimi> lifeless: Ah right :)
<lifeless> it /probably/ needs to be fixed up client side.
<huwshimi> lifeless: render time, including javascript execution?
<lifeless> server render time
<huwshimi> lifeless: Ah ok
<lifeless> adding in javascript render time would be an awesome bit of filigree but its not my first target.
<stub> lifeless: You could set a cookie after the page has been generated (and before returned to the client) containing the details, and have the javascript display the contends
<lifeless> stub: thats possible; could also just render the javascript to set it with the contents.
<wgrant> stub: Race race race.
<stub> wgrant: Shouldn't be a race - cookies are sent in the header, and they are called headers for a reason. I suspect I'm overly optimistic here :)
<lifeless> huwshimi: my js is extremely rusty - the last time I did significant stuff with it was in 97
<wgrant> stub: It'll race with other pages, though.
<lifeless> huwshimi: so I'm wondering if you'd care to proffer a little snippet
<huwshimi> lifeless: Where does it get the timestamp from, or do you want to generate it with the javascript?
<stub> So we need to inject the tag after generating the page and before returning it to the client. No JS needed, no race conditions
<lifeless> huwshimi: I propose to put the js in base-layout.pt
<lifeless> huwshimi: where the current comment listing the page metadata is
<lifeless> huwshimi: and I can render the javascript with the right duration immediately
<stub> Minor publisher hack to our collection of minor publisher hacks we call our publisher.
<lifeless> stub: I'm alittle worried about where in the publisher I'd need to poke to make that happen; doing a 5-line js render seems cheaper
<lifeless> stub: +
<lifeless> stub: doing it as js lets us get js render times eventually as well
<stub> The publisher basically does 'return foo(request)'. Change that to 'body = foo(request); body.replace('$$$ I CAN HAZ RENDERTIME $$$', str(rendertime)); return body
<lifeless> stub: right, thats expensive on our big pages
<lifeless> measurably so
<huwshimi> lifeless: If you're generating the timestamp with the javascript you'll have issues with javascript execution times
<lifeless> huwshimi: not a timestamp; string description of duration.
<huwshimi> lifeless: Ah ok, so it's already been generated? Sorry I'm a bit confused :)
<lifeless> huwshimi: visit any old launchpad page
<lifeless> view the source and scroll to the bottom
<stub> I'm causing confusion because I'm talking page generation time and this conversation is about client side rendering time I realize
<lifeless> stub: no, its a bit about both.
<lifeless> stub: so on particular confusion, but I think its worth having one change that will do both eventually.
<lifeless> huwshimi: so at the bottom there is a comment block
<lifeless> with things like '15 queries/external actions issued in 0.18 seconds' in it
<huwshimi> lifeless: yeah got it
<lifeless> huwshimi: I want to show that string (perhaps more compactly) to the left of my name in the login area
<huwshimi> lifeless: Right, I'm with you
<poolie> i wish lp would stop sending:
<poolie> ** Changed in: bzr
<poolie>     Assignee: Registry Administrators (registry) => Curtis Hovey (sinzui)
<poolie> ** Changed in: bzr
<poolie>     Assignee: Curtis Hovey (sinzui) => (unassigned)
<wgrant> You want it to collapse them?
<poolie> huwshimi, +1, i think that would be great
<huwshimi> lifeless: Because it is outside the entire <html> definition you'll probably have to do something a little hacky to get it to work. Unless I'm overlooking something, but I don't think I am. Let me do a quick test and I'll give you some code
<huwshimi> poolie: About subdomains?
<lifeless> huwshimi: we can put it in the html easily
<lifeless> huwshimi: thats a 5 second change
<huwshimi> lifeless: I guess the real issue is that it is not inside a single element to nicely pull it out.
<lifeless> huwshimi: how do you mean ?
<poolie> about subdomains but also about showing the db query count
<lifeless> huwshimi: I can put it into the javascript we output
<lifeless> poolie: db count is me :)
<lifeless> poolie: I'm nabbing huwshimi for help.
<huwshimi> lifeless: Oh I see you'd modify the javascript server side to set a javascript var?
<lifeless> yes
<huwshimi> lifeless: Oh, easy then :)
<lifeless> I can write out the js all prepped and ready to go
<lifeless> exactly
<huwshimi> lifeless: ok let me give you some code
<huwshimi> you can stick it where you like, it doesn't matter when it is executed then.
<huwshimi> one sec
<lifeless> huwshimi: obviously I can add a span or what have you at the top to get replaces
<lifeless> *replaced*
<lifeless> huwshimi: and I can take care of all the logic for when to show/not show.
<huwshimi> lifeless: Sure
<huwshimi> http://paste.ubuntu.com/563723/
<huwshimi> lifeless: ^ that should be roughly it
<huwshimi> lifeless: if you want you could add a dive with javascript as well so you don't have to add any html to render
<huwshimi> lifeless: Ouch, actually there is one bug
<lifeless> does that replace the entire location bar
<huwshimi> lifeless: yes :)
<lifeless> ok, well I'll wrap this in when-to-show and the render time
<lifeless> right, thats all glued in
<lifeless> just needs the tweak to not replace it all
<huwshimi> lifeless: ok, for that you need it to look like this: http://paste.ubuntu.com/563729/
<lifeless> huh
<lifeless> wouldn't this work ?
<huwshimi> lifeless: That will create the extra div and everyone
<huwshimi> *everything
<lifeless> http://pastebin.com/pSek6jTi
<lifeless> ah, it renders quirkily my way
<huwshimi> lifeless: Yes, but then you don't have a parent element to control it's position with'
<huwshimi> lifeless: Yeah it'd probably look a bit strange without a float or anything
<lifeless> so
<lifeless> I can create the dic up front
<lifeless> give it a static 'loading...' message
<huwshimi> lifeless: Yes that would work
<lifeless> sweet
<lifeless> it sits a little close to the person icon
<poolie> lifeless, bug 703807 looks a lot like a squid problem
<_mup_> Bug #703807: "easy_install pyOpenSSL" says "error: Unexpected HTML page found at http://launchpad.net/pyopenssl/main/0.11/+download/pyOpenSSL-0.11.tar.gz" <Launchpad itself:Triaged> <pyOpenSSL:New> < https://launchpad.net/bugs/703807 >
<poolie> since it shows up consistently on one proxy
<poolie> just thought you might be amused
<lifeless> s/amused/horrified/
<poolie> :)
<wgrant> poolie: It depends on the file.
<wgrant> poolie: Some work fine on both.
<poolie> i have a tcpdump here but i don't know if it really shows anything interesting other than what's in the header
<wgrant> Others work only on one sometimes.
<poolie> wgrant, true
<lifeless> poolie: I doubt that its squid; squid will be doing what its told.
<wgrant> It may be that only one has cached bad responses.
<wgrant> The other managed to get a good one.
<poolie> i don't think it's a squid bug but it may be a squid issue
<poolie> whether that is bad configuration, bad data on disk, bad cache guidance from lp
<lifeless> uhm
<lifeless> So I still doubt that; I bet if squid wasn't there we would get users complaining from time to time
<lifeless> squid probably makes the issue, whatever it is, more visible when it happens.
<poolie> wgrant, now that would be interesting if we can find a url that works on banana and not nutmeg
<poolie> well, it probably makes it sticky
<poolie> lifeless, how likely is it that it could cache a content-type and a body that weren't originally sent together?
<poolie> i would have thought pretty unlikely
<wgrant> 14:31 < wgrant> At the moment, http://launchpadlibrarian.net/58498441/pyOpenSSL-0.11.tar.gz gets the right type from nutmeg, but the wrong from banana.
<lifeless> poolie: cosmic ray unlikley.
<wgrant> That was a couple of weeks ago.
<poolie> wgrant, that's also what i'm getting today
<wgrant> Ah.
<wgrant> True.
<lifeless> huwshimi: if you wanted to eyeball this and see how it looks - lp:~lifeless/launchpad/showtimes has the patch.
<huwshimi> lifeless: Do you want a bit more styling for it? Is this a permanent thing? At the moment the css applied is kind of bad, but I can give you some proper stuff?
<poolie> if we found that they swapped around either for this url, or for different urls, that would be quite interesting
<huwshimi> lifeless: OK, I'll take a look
<wgrant> Right, I thought I found such an example, but I was confused.
<lifeless> huwshimi: to play with it, pull/merge that branch in, run it, visit 'https://launchpad.dev/+feature-rules' and add a rule 'visible_render_times default 1 on'
<poolie> do you know off hand if these machines will respect any cache-busting headers?
<huwshimi> lifeless: Actually how do I run your branch locally?
<huwshimi> lifeless: Do I stick it in lp-branches?
<wgrant> poolie: Uh, did you actually look at launchpad.net/debian?
<lifeless> huwshimi: make a branch of your own to hold it, then run 'bzr pull --overwrite lp:~lifeless/launchpad/showtimes'
<wgrant> poolie: I made sid the dev focus this morning, when I created wheezy.
<wgrant> lp:debian/foo now resolves to sid.
<huwshimi> huwshimi: Can I just create that initial one with rocketfuel-branch?
<poolie> hooray
<poolie> no, i didn't look closely enough
<wgrant> Heh
<huwshimi> ugh
<huwshimi> lifeless: Can I just create that initial one with rocketfuel-branch?
<huwshimi> I was talking to myself again
<lifeless> huwshimi: yes, you can
<poolie> wgrant, so nothing more needs to be done? or should we rejigger stacking?
<huwshimi> lifeless: Thanks, I'm still a noob :)
<poolie> i suppose that would mean unstacking the sid branches
<wgrant> poolie: We could restack everything if we really wanted to. But the benefit is negligible.
<poolie> hm
<poolie> ok
<wgrant> We need a way to do that sort of thing, but I don't think we have it at the moment.
<wgrant> Actually.
<wgrant> Hmm.
<wgrant> I guess we probably should do that.
<poolie> what did you do to change the focus?
<wgrant> Or we are going to have multi-level stacking. And I guess that's not going to work very well.
<lifeless> sometimes I think drmo doesn't read blog posts. sigh.
<wgrant> ~registry can change the status on +edit of Debian's distroserieses.
<wgrant> There's no link, but URL hacking works.
<lifeless> we want /sid/ to be unstacked
<poolie> actually https://launchpad.net/debian doesn't say which one is the development focus
<wgrant> The dev focus is the "Current Development" series.
<lifeless> and the rest stacked on sid
<poolie> neither does https://launchpad.net/debian/sid
<wgrant> No, because it's not explicit for distributions.
<wgrant> It's implied from the status.
<poolie> i feel less bad about not seeing it now :)
<poolie> ah, "active development" implies that?
<wgrant> Er, yeah, Active Development, not Current Development
<poolie> well that's obvious
<wgrant> That's 2005.
<poolie> ?
<poolie> the ui design here is from 2005?
<wgrant> The data model is.
<wgrant> Products have a dev focus.
<wgrant> Distributions do not.
<wgrant> And yes, most of the UI design is too :)
<lifeless> review plox https://code.launchpad.net/~lifeless/launchpad/showtimes/+merge/48754
<lifeless> huwshimi: its visible_render_time - no s. my bad.
<huwshimi> lifeless: Ah thanks
<poolie> nice
<lifeless> thanks
<lifeless> huwshimi: commit -2 is the meat of the change
<lifeless> huwshimi: you can see that with 'bzr diff -c -2'
<wgrant> We don't have any tools at the moment to mass-restack branches, do we?
<poolie> nup
<lifeless> other than branch-distro
<lifeless> no
<poolie> well, shell scripts
<wgrant> branch-distro cheats.
<poolie> i wonder what degree of tool-building would be worthwhile?
<huwshimi> huwshimi: ok cool thanks. Did you want me to give you some css to make that spaced a bit better?
<wgrant> Right. It's really easy to script it up. Just wondering if we had an existing solution.
<wgrant> I think most sid branches should already contain ~all the data anyway.
<wgrant> But it would be nice to formalise that.
<lifeless> huwshimi: now you are talking to yourself :)
<huwshimi> ugh, I keep doing that!
<wgrant> Perhaps we want to revert the dev focus until we do that.
<lifeless> huwshimi: sure, that would be cool
<huwshimi> lifeless: ok no problems :)
<lifeless> huwshimi: it doesn't matter a great deal, but we might find that interested users want to see this or something.
<huwshimi> lifeless: Sure
<lifeless> huwshimi: so I don't think it should be /ugly/
<poolie> lifeless, can i see a screenshot?
<wgrant> poolie, lifeless: We should probably work this out before we run branch-distro, which will create 20000 new branches stacked on wheezy rather than sid. It sounds like we want to reconfigure --unstacked all of sid's branches (should be cheap, since revs should have appeared in sid first anyway), then hack branch-distro to stack on there instead of the new series.
<poolie> bug 714414
<_mup_> Bug #714414: unstack debian sid branches <code-hosting> <stacking> <Launchpad itself:Triaged by canonical-bazaar> < https://launchpad.net/bugs/714414 >
<huwshimi> lifeless: Do you want a patch or something?
<lifeless> huwshimi: patch sure, or you could commit and push and I'll pull in your branch
<huwshimi> lifeless: ok I'll commit
<poolie> wgrant, right, so i wonder if that should just be $something|xargs -n1 bzr reconfigure --unstacked, and ask a losa to run that
<lifeless> poolie: just trying to remember the hostname to use to sftp up the screenshot
<wgrant> poolie: Pretty much, I think.
<wgrant> Or possibly a harness.
<poolie> what does 'harness' mean in this context?
<wgrant> As in 'make harness', sorry.
<wgrant> Giving us access to the usual codehosting Python APIs.
<wgrant> Allowing us to list and open branches and stuff...
<wgrant> A smartserver restack is server-side, right?
<poolie> hm
<poolie> this is the thing that opens up a python shell with an lp object?
<wgrant> assuming it is, we just need a member of ~ubuntu-branches, and launchpadlib...
<poolie> i think that's true
<poolie> it does depend on keeping the connection open, but that could be run from the dc
<wgrant> Right.
<huwshimi> lifeless: lp:~huwshimi/launchpad/showtimes
<huwshimi> lifeless: Tell me if that looks ok
<poolie> lifeless, i think jorge recommended 'shutter' which can upload them various places
<lifeless> huwshimi: I think you haven't pushed
<huwshimi> lifeless: Oh, it says it's done...
<huwshimi> lifeless: oh, I've failed.
<huwshimi> lifeless: I'm trying to do too many things
<huwshimi> lifeless: one sec
<huwshimi> lifeless: I pushed it without the changes :D
<huwshimi> lifeless: OK, try now.
<lifeless> thanks, trying
<lifeless> poolie: http://people.ubuntu.com/~lifeless/showtime.png
<lifeless> thats without huw's fixes.
<lifeless> huwshimi: thanks, pushing that into the proposal
<huwshimi> lifeless: Great.
<huwshimi> lifeless: Just before I head off, in terms of the subdomain stuff, what are your initial reactions to the idea of change to a different url structure? I don't want to push the issue if I should really just be leaving it alone.
<lifeless> uhm
<lifeless> so there are three things you might mean
<lifeless> if you mean 'lets use one domain for the app, one for apis and the librarian/apt-archives/etc off to the side' - fine by me
<lifeless> on a technical level that has many advantages
<lifeless> if you mean use a different way of generating urls.
<lifeless> e.g. /objectid
<lifeless> and being much less 'object traversal and guessable'
<lifeless> well, perf wise that will have implications (neither good or bad per se - just change we need to accomodate)
<lifeless> and I think it needs to be vetted in terms of usability
<lifeless> one of the early design considerations was that our urls should be tellable
<lifeless> (vs copiable)
<lifeless> if you mean something in between the two, my reaction is in between the two :)
<huwshimi> lifeless: ok, I'm really only thinking about removing the bugs.LP code.LP etc. and somehow merging them into the main urls
<huwshimi> which would be your first option
<lifeless> I know jml is interested in doing that
<lifeless> and as I say, technically this would be great in many ways.
<huwshimi> lifeless: I had a brief discussion with him about and his concern was the technical impact of it, which by the sounds of things would affect things positively.
<lifeless> I think it would a bit of a wash UI wise in some ways - some things like 'type in bugs.' would become 'suffix with +bugs', or whatever.
<lifeless> huwshimi: I'm reasonably sure he knows my opinion here; happy to write it down for reference if you like
<lifeless> I *don't* think this is a high priority in terms of improving the UI or experience of LP; but thats not grounded in science.
<huwshimi> lifeless: OK thanks very much. I'll do some more thinking about it then.
<lifeless> the things I think are key priorities are:
<lifeless>  - making it feel snappy
<lifeless>  - making doing the most common things easy to do
<lifeless> for the former more extensive API use vs page loads will help considerably.
<lifeless> E.g. search pagination should not be a page load.
<lifeless> for the latter, I think doing some extensive log analysis could be a goldmine for finding out what folk do the most. And then we can start including that data in our scheduling discussions.
<huwshimi> lifeless: How much impact does the ssl stuff have?
<huwshimi> is that delay every time you switch subdomain?
<lifeless> our SSL cache is set (IIRC) to 6 hours expiry now
<lifeless> so users should only perceive it when either:
<lifeless>  a - their brower switches backend IP (should be never, but you can't be sure without reading the browser source code :P)
<lifeless>  b - they've just started using the site in a new browser session or after a many hour delay
<huwshimi> I guess b would be once or twice daily then
<lifeless> well, 6 hour gap
<lifeless> (I think thats what its at)
<lifeless> I'm negotiating with ubuntu-server team to apply the memcached ssl cache patch to apache for us
<lifeless> if we get that in a backport for lucid, we can push it up to 24 hours and have it shared between apaches
<lifeless> that should mean ~ never for our more active users.
<huwshimi> lifeless: Ok, so in terms of performance subdomain stuff is negligible
<lifeless> we can reduce the impact till its largely ignorable. there will always be a 6 second warmup for folk near gmt+12, but the distributed ssl front ends we're looking at will mitigate that a great deal
<huwshimi> lifeless: OK thank.
<lifeless> huwshimi: shiny theming on the render times
<huwshimi> lifeless: Ok cool, that's ok then?
<lifeless> yeah, I just took it before, ran it up now.
<lifeless> iz nice.
<lifeless> its a little bit of a shame that the bullet point is now a different size
<lifeless> but 'meh'
<huwshimi> lifeless: We can fix that if we care enough
<lifeless> huwshimi: wait till it annoys you
<huwshimi> lifeless: Haha
<lifeless> huwshimi: this will go live monday next week
<lifeless> huwshimi: as I'm not going to push it via r-c, and friday will be too late for it.
<huwshimi> lifeless: For some reason those bullet points annoy me any way, so watch out otherwise I'll delete them all :P
<lifeless> huwshimi: wouldn't bother me; I was following suit
<lifeless> huwshimi: now, to show javascript render times
<lifeless> huwshimi: I imagine we'd put a little <script> at the top of the html to grab a timestamp as the page starts loading. Probably not even aa YUI call; bare js.
<lifeless> huwshimi: then this code block at the end could grab that and subtract to figure out the interval; but would it be realistic - that is, would the overlays for bug task buttons etc have all rendered by then ?
<huwshimi> lifeless: Yeah that will be the hard bit.
<huwshimi> lifeless: Are you doing this so that the time is in our face the whole time?
<lifeless> is there a 'bing, its cooked, ready to eat' event ?
<lifeless> huwshimi: hell yes.
<huwshimi> lifeless: Awesome
<lifeless> i'm a huge fan of continual partial awareness of things that need optimising
<lifeless> if you can't see it, and its not your primary concern, it won't get looked at.
<huwshimi> lifeless: There's a few dom states for things like that. I think you might be able to use the 'ready' state. I think DOM and javascript execution is done then, but I'm not sure if all execution is done and I don't think images are either
<huwshimi> lifeless: I think it's a good idea.
<lifeless> huwshimi: an approximation may still be usfeul
<huwshimi> lifeless: Yeah, you should be able to get some idea from comparing the numbers to a browser profiler (like the chrome one or firebug or something).
<lifeless> huwshimi: right now I'm not likely to add the js times myself
<lifeless> huwshimi: but I'd be delighted to help you overcome any issues you might have adding that, if you are interested in doing so
<huwshimi> lifeless: Haha.
<lifeless> primarily because I want to get the server side /sorted out/
<huwshimi> lifeless: Did you say that someone is looking into lazy loading the javascript?
<lifeless> huwshimi: deryck has mumbled various things
<lifeless> there is a usable combo loader in lazr-js; I helped sidnei optimise that a few weeks ago
<lifeless> huwshimi: oh, the other perf advantage of one domain
<lifeless> less repeated downloads of javascript
<huwshimi> lifeless: Yeah, I was surprised to see we don't stick all the js/css/images on it's own server
<lifeless> huwshimi: for first access, another ssl handshake == slower
<huwshimi> lifeless: Ah right
<huwshimi> lifeless: disconnecting for one minute
<huwshimi> lifeless: Is the media served through it's own apache instance though?
<lifeless> so we have 2 sets of media
<lifeless> we have user media
<lifeless> and system media
<lifeless> system media is treated like css etc; its static files on the same domain as the page, so no new ssl handshakes.
<lifeless> user media is put on the librarian
<lifeless> the librarian is launchpadlibrarian.net (for public files) and *.restricted.launchpadlibrarian.net for private files
<lifeless> so user branding will generate (at least one) ssl handshake.
<huwshimi> ssl is such a pain
<StevenK> huwshimi: I'd rather it was using SSL :-)
<lifeless> technically speaking, we're staying on pure ssl
<lifeless> :)
<adeuring> good morning
<mrevell> Hello
<Ursinha> good morning launchpadders
<wgrant> lifeless: Still around?
<lifeless> somewhat
<wgrant> lifeless: What do you think of http://pastebin.ubuntu.com/563762/? It may need loop-tunerising, but it's probably OK.
<lifeless> wgrant: well it will work, but isn't it going to double our disk usage?
<wgrant> lifeless: I suspect our disk usage is already doubled.
<wgrant> lifeless: Since all the new data will be going into sid first.
<lifeless> wgrant: well the importer is halted for now
<lifeless> wgrant: isn't it ?
<wgrant> lifeless: I mean historically.
<wgrant> New revs are imported into the stacked sid branches.
<lifeless> ah yes
<lifeless> so anyhow
<wgrant> Only after ten days do they enter the stacked-on branch.
<lifeless> I think this will work
<wgrant> We probably want to later on manually "
<lifeless> loop tuning would be pointless
<wgrant> restack" the rest of the series by recloning.
<wgrant> But that can happen later.
<wgrant> Right.
<lifeless> we should get a report of disk waste and some code to discard duplicate revs and tune
<lifeless> wgrant: gc, no need to reclone.
<lifeless> wgrant: specialised pack()
<lifeless> jml: are you here yet?
<wgrant> lifeless: I thought bzr didn't support that yet!
<wgrant> Does it now?
<lifeless> wgrant: no, but it can
<wgrant> Heh
<wgrant> It seems to not trigger a rescan, which is nice.
<jtv> hi wgrant, hi lifeless
<wgrant> Evening jtv.
<lifeless> hi jtv
<jtv> fosdem was funâpresentations on pgpool-II and postgres-R in particular.
 * jelmer waves
<jtv> hi jelmer :)
<wgrant> Is postgres-R another replication solution?
<jtv> Yes, but it's multi-master.
<wgrant> Ahh.
<wgrant> Hi jelmer.
<jtv> Unfortunately it's not quite done yet.
<jtv> Which is a real shame.
<lifeless> jtv: whats its relation to -XC ?
<jtv> None.
<lifeless> so a different approach then ?
<jtv> I haven't looked at -XC's architecture AFAIR
<jtv> It's an optimistic approach, but with a centrally imposed commit order.
<jtv> Of course recovery can be really really hard.
<jtv> When there's a "deadlock," whichever transaction comes last breaks.
<adeuring> wgrant: thanks for qa-ing bug 705652!
<_mup_> Bug #705652: Make remove_translations side aware. <qa-ok> <upstream-translations-sharing> <Launchpad itself:Fix Committed by adeuring> < https://launchpad.net/bugs/705652 >
<wgrant> adeuring: I don't know translations fantastically, so you might want to QA in detail yourself. But it seemed to work OK, from what I could see in the code and MP.
<lifeless> mrevell: have you seen jml around?
<mrevell> lifeless, Not yet.
<lifeless> jml: I'll try to catch you in my morning tomorrow
<lifeless> night all
<Ursinha> night lifeless
<Ursinha> is there a correct tag to use when filing checkwatches related bugs?
<henninge> Hi Ursinha! ;-)
<Ursinha> hi henninge :)
* henninge changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is in RC for devel | firefighting: - | On call reviewer: henninge (r-c only atm) | https://code.launchpad.net/launchpad-project/+activereviews
<gmb> Ursinha: For checkwatches we used to use bugwatch as  a tag.
<gmb> Also, "argh-argh-argh-stoppit-die".
<gmb> But that one wasn't adopted as official.
<Ursinha> hahaha
<Ursinha> thanks gmb
<gmb> Ahahaahahahhahahaha.
<gmb> Windmill tests in my branch are failing because windmill isn't rendering a "Complete" element quickly enough.
<gmb> ... Hmm. Although windmill looks different than it last did. Coincidence?
<jtv> henninge: review done
<henninge> jtv: thank you!
<jtv> np
<mpt> Huh, TIL that the RPM Package Manager uses Launchpad for feature and bug tracking
<deryck> Morning, all.
<gmb> Morning deryck; just the man I wanted to talk to about Windmill :)
<deryck> ah happy way to start my day ;) :)
<deryck> gmb, so what's up?
<gmb> deryck: Yeah. Have you seen this before: http://pastebin.ubuntu.com/563808/
<gmb> Looking at the code, it looks like Windmill is failing to render a "complete" element. The problem isn't LP code, it's Windmill itself.
<deryck> gmb, no, it's the standard way Windmill fails when one of the YUI tests doesn't pass.
<gmb> OIC.
<deryck> gmb, you have to run the yui tests individually now to see which one failed.
<gmb> Hahaha.
<gmb> Joy.
<gmb> deryck: Thanks for the "help".
<gmb> :)
<deryck> I've gotten Windmill to spit that out before, but I don't recall how.  I think maybe:  ./bin/test -cvvt test_yuitests --layer=BugsWindmillLayer
<deryck> gmb, spit out the individual test failing, I mean. ^^
<deryck> gmb, and no problem :-)
<gmb> deryck: Right. I'll give that a shot. Thanks.
<bigjools> stub: do you want me to add the manual debversion patch rollout step to LPS, or have you got that covered?
<stub> bigjools: What in particular where you thinking about? debversion.sql has already been applied to production if that is what you mean.
<bigjools> stub: sweet
<Ronnie> lifeless: ping
<Ursinha> Ronnie, he's gone already, I'm afraid
<Ronnie> ok, thx Ursinha
<Ursinha> np
<Ronnie> wgrant: ping
<Ronnie> im trying to figure out the interaction between LD, LP and the openId provider: http://img812.imageshack.us/img812/7037/schemaopenidld.png
<wgrant> Ronnie: I'm not here either.
<wgrant> However, the question mark is about right.
<wgrant> It is a terrible hack involving partial database replication.
<wgrant> SSO does not store team memberships or timezones, though -- it gets them from the replicated LP DB.
<Ronnie> wgrant: does i access the LP DB each time the SREG is requested, or does it work on daily update or something?
<wgrant> Ronnie: The team membership tables are continuously replicated to it, just as if it was a normal DB slave.
<wgrant> So it should be up to date, at least within a couple of minutes.
<wgrant> Normally seconds.
<Ronnie> oke
 * wgrant sleeps.
<deryck> henninge, ping for standup
<henninge> deryck: oops, sorry. Be right there.
<gary_poster> hm.  when I try to run make schema I get "psycopg2.ProgrammingError: type "debversion" does not exist
<gary_poster> ".    This is from db patch 40.  I don't see anything on the lists about this.
<gary_poster> stub: ^^ ?
<bigjools> gary_poster: you need to update your lp-deps
<gary_poster> ah-ha thanks bigjools
<bigjools> no prob - if this is the only problem with that branch I'm happy :)
<gary_poster> :-)
<statik> goooooooooood morning launchpad hackers
 * bigjools waves at statik
<flacoste> good morning statik
<flacoste> back from the tropics!
<statik> tropics are overrated, computers are more fun
<gary_poster> :-)
<bac> abentley: i need to land a loggerhead branch for max.  do i just use 'bzr lp-land' to land it or do i need to do anything else?
<abentley> bac, I imagine lp-land will work, but I've never landed a loggerhead branch.
<bac> abentley: ok, i assumed you would've.  thanks.
<abentley> bac, are you asking whether you should do something prior to landing, or just whether lp-land will work?
<bac> abentley: actually wondering if i need to do something post-landing.  'bzr lp-land --dry-run' looks reasonable, so i assume it will work.
<abentley> bac, I notice the branch isn't owned by pqm, so it's likely PQM doesn't manage landings for it.
<abentley> bac, you could ask jam since he landed the most recent changes.
<bac> abentley: https://code.launchpad.net/~mkanat/loggerhead/launchpad/+merge/46880 -- the merge to branch is owned by pqm
<abentley> bac, you probably just push the branch.
<abentley> bac, okay, for that branch I'd expect lp-land to work.  Trunk isn't maintained by PQM.
<sinzui> jml: Do you want to mumble today?
<deryck> adeuring, hi.  Did you get a chance to look at that mail/bug/etc. that was qa related?
<adeuring> deryck: yes; I'm right now fiugring out some qa tests
<deryck> adeuring, ok, cool.  thanks
<jcsackett> deryck: can i pick your brain about bug 632847 for a just a second?
<_mup_> Bug #632847: Bug page OOPS when viewed in deactivated project context <404> <lp-bugs> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/632847 >
<jcsackett> specifically, do you think the fix is just removing the OOPS condition, or making sure the bug link works via the (not-deactivated) other context?
 * deryck looks at bug
<jcsackett> i'm leaning towards the latter, but wondering if there might be precedent for the former in bug stuff.
<deryck> jcsackett, I think we're trying to prevent people viewing deactivated projects.  So I think we shouldn't list bug tasks for dead projects.  That seems the right fix to me.
<deryck> jcsackett, in other words, there should be no entry in the bugtask table that leads someone to want to click through to the dead project.
<deryck> or bug list, or whatever
<deryck> assuming the goal is to hide dead projects.  if that's not our goal (and I'm really not sure), then just make the dead project viewable with a "this is dead" notice :-)
<sinzui> jcsackett: deryck. I agree with do not list. If we supported project deletion, we would want them deleted to. If the project is re-enabled, we expect them to show up again
<jcsackett> right, but the task listing for the active one should work. that's a better statement of what i meant.
<jcsackett> dig.
<deryck> yes, right.  I think we all agree :-)
<jcsackett> cool. thanks, deryck, sinzui.
<sinzui> jcsackett: are you pondering what happens when you (~registry member) visits the bug for a deactivated project. Should /you/ see the bug task?
<sinzui> Most bugs have one task. I think the page will break if there are no tasks. We may not want to fix an oops that only we can see, but that is unlikely
<jcsackett> sinzui: i think probably ~registry members should see the bug task, but it shouldn't be listed otherwise.
<jcsackett> for ~registry members, there isn't an OOPS. it's non ~registry folk who see the link, click it, and then get a 404 (with an OOPS).
<sinzui> jcsackett: yes. I was pondering what would happen if we always hid the task, then we might mutate the oops to ourselves
<jcsackett> sinzui: i think it should be reasonably easy to check if the person can see deactivated contexts, and then throw in the parameter for whether or not to also list the associated tasks.
<lifeless> Ursinha: checkwatches I think; it should autocomplete.
<lifeless> jml: (hopeful) ping
<Ursinha> lifeless, it's bugwatch
<lifeless> kk
<jml> lifeless: hi
<lifeless> \o/
<lifeless> hi
<lifeless> I'd like to nab you for a vocal catchup at a convenient time
<lifeless> jml: ^
<jml> lifeless: sure. later tonight ok?
<lifeless> sure
<lifeless> jml: I have a couple of calls with us folk, but they can probably shuffle if you can tell me when your preferred time is
<lifeless> s/us/north american/
<jml> lifeless: I'll get back to you about that shortly
<lifeless> excellent, thank you
<jcsackett> sinzui: mumble?
<lifeless> I can has review ? https://code.launchpad.net/~lifeless/launchpad/showtimes/+merge/48754  - its not r-c, but I want to move it out of the coding lane in my head
<lifeless> jcsackett: hi
<jcsackett> lifeless: hello.
<lifeless> jcsackett: I saw that you ran into a wall on bug 421901
<_mup_> Bug #421901: Person:+bugs timeouts <lp-bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/421901 >
<lifeless> jcsackett: I did some analysis on that in the weekend to help
<lifeless> jcsackett: merging the union won't fix the bug that is reported - its one particular sub part that is the problem.
<lifeless> jcsackett: separately, as something to keep in your toolbox - unions that are each highly selective can be more efficient than a very wide query - see for instance bug 714383
<_mup_> Bug #714383: bugtask fti search is slightly faster as a union rather than combined or clause <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/714383 >
<jcsackett> lifeless: huh. that flies in the face of anything i would expect. :-)
<lifeless> jcsackett: sql tuning, like python, is 'best measured not guessed' :)
<jcsackett> :-p
<lifeless> anyhow
<lifeless> I was hoping that narrowing the focus to changing the 'commented on' component would make bug tractable for you
<jcsackett> lifeless: actually, it might and i may grab that again, but i needed to get out of it and do something i could get some success again on and thought i would leave it open in case someone else wanted it.
<lifeless> jcsackett: cool
<lifeless> jcsackett: I was checking to make sure I'd unblocked it; if/when you get back to it, if its still not helpful enough I'd be delighted to do more
<jcsackett> lifeless: i will check it out again when i finish what i'm currently working on; if i need more data i'll definitely ping you.
 * lifeless waggles fingers together
<lifeless> excellent
<lifeless> statik: hi
<lifeless> statik: we catching up today?
<thumper> deryck: ping
<deryck> hi thumper
<thumper> deryck: what's happening with lazr-js?
<deryck> thumper, did you see my mail?
<thumper> no
 * thumper looks for it
<thumper> oh found it
<thumper> ok, thanks
<thumper> do you need a review?
<deryck> thumper, not yet.  Finishing one little issue.  will get it up before I leave and you can review it while I'm away if you like.
<deryck> but it should be easy to review for someone during my am.  since we can't land it yet anyway.
<wallyworld_> thumper: i gotta drop the kid to school early this morning. as in now :-( so i'll have to miss the standup. we can catch up later
<thumper> wallyworld_: sure, np
<thumper> deryck: ok
<thumper> leonardr: ping
<leonardr> thumper, yo
<thumper> leonardr: care to join me in mumble?
<leonardr> sure
<deryck> thumper, actually EOD is on me.  I'll get this through review before your AM tomorrow, though.
<lifeless> flacoste: skype?
<flacoste> lifeless: yes
<deryck> later on, everyone
<LPCIBot> Project devel build (423): FAILURE in 6 hr 5 min: https://hudson.wedontsleep.org/job/devel/423/
<LPCIBot> Launchpad Patch Queue Manager: [release-critical=wallyworld][r=jtv][bug=710591][incr] Provide
<LPCIBot> TranslationMessage.acceptFromImport and
<LPCIBot> .acceptFromUpstreamImportOnPackage.
<wallyworld_> thumper: catch up now or later?
<StevenK> I think he's still injecting coffee
<wallyworld_> of course, i'm sure it's been 5 minutes since the last time :-)
<jml> huwshimi: ping
<huwshimi> huwshimi: Hello.
<huwshimi> ugh
<huwshimi> jml: Hello
<huwshimi> how do I do that!
<jml> huwshimi: skype?
<huwshimi> jml: Sure
<StevenK> wallyworld_: I wonder if thumper has started stalking his coffee maker repair man yet
<wallyworld_> StevenK: perhaps. it seems to be taking a long time to get fixed
<poolie> hi all
<wgrant> Morning poolie.
<poolie> hi wgrant
<poolie> iirc i can get the api to send xhtml by setting the right Accept header?
<jcsackett> sinzui: i am stumped on the best way to double check if someone is member of ~registry for the purposes of deciding to list deactivated projects. thoughts?
<poolie> ah, application/xhtml+xml
<sinzui> jcsackett: I think that is a role. registry_experts
<sinzui> jcsackett: in security.py you use user.in_registry_experts or in other code you can get the team using getUtility(ILaunchpadCelebrities).registry_experts
<jcsackett> sinzui: ah, fantastic. thanks.
<wgrant> You can adapt to IPersonRoles to get in_registry_experts anywhere.
<jcsackett> wgrant: cool. thanks, both. :-)
<poolie> leonardr, hi
<lifeless> StevenK: hi
<lifeless> StevenK: yesterday you were looking at consolidating the recipe exception handling code
<StevenK> lifeless: Hai
<lifeless> StevenK: did you get a handle on that, or would you like to work through it in more detail ?
<StevenK> lifeless: https://code.launchpad.net/~stevenk/launchpad/set-recipe-text-bad-data/+merge/48853
<lifeless> reviewed
<leonardr> poolie, hi
<lifeless> I've suggested an alternate protocol for signaling 'error was handled'
<leonardr> yes, if you pretend to be a web browser the web service will send you xhtml
<lifeless> what you have will work; I think what I suggest would be simpler.
<StevenK> lifeless: I wasn't asking for one, but thanks
<lifeless> I figured having read it I may as well :)
<StevenK> lifeless: What do you mean 'only accept *args' ?
<lifeless> StevenK: the normal idiom for functions like this in python is
<lifeless> def foo(its, params, callable, *args, **kwargs):
<lifeless> but you've got **kwargs missing, which is surprising, so worth a note about why (or perhaps just fix)
<wgrant> :( nightly.sh ran yesterday
<wgrant> So the new shiny one won't run today :(
<poolie> i just added a new official tag and it's not showing up in the official tags portal
<poolie> is that a bug?
<wgrant> We have no cache invalidation mechanism.
<poolie> it's cached and not invalidated?
<wgrant> I thought that was cached. Let me check.
<wgrant> Yeah, cached publicly for an hour.
<StevenK> lifeless: http://pastebin.ubuntu.com/564126/ was what you were thinking?
<lifeless> StevenK: and remove the ret variable entirely
<poolie> flacoste, https://bugs.launchpad.net/bugs/714414
<_mup_> Bug #714414: unstack debian sid branches <code-hosting> <stacking> <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/714414 >
<lifeless> StevenK: you can just return it directly
<StevenK> return callable ... ?
<StevenK> Well, duh :-)
<lifeless> StevenK: and you don't need one raise per except
<lifeless> StevenK: just put one raise at the bottom of the method
<StevenK> lifeless: Anything else?
<lifeless> StevenK: also, one minor thing is that you need to do 'raise ErrorHandled()' - note the brackets.
<lifeless> StevenK: I think you had two calls to error_handled to update
<StevenK> lifeless: I thought I did those ...
<lifeless> StevenK: push the branch, I'll eyeball for you
 * StevenK checks he hasn't broken the tests while making tea
<poolie> wgrant, thanks, https://bugs.edge.launchpad.net/launchpad/+bug/714901
<_mup_> Bug #714901: updates to official bug tags not visible because of stale cached tags portlet <bug-tags> <bugs> <confusing-ui> <memcached> <Launchpad itself:Triaged> < https://launchpad.net/bugs/714901 >
 * poolie should get rid of bookmarks to edge
<poolie> wgrant, thanks for taking 714414
<wgrant> poolie: I have the script, but it needs testing and landing.
<maxb> firefox has a very useful "forget history for this host" buried in the manager dialog
<wgrant> poolie: Has package-import been taught about wheezy yet?
<lifeless> wgrant: I thought we were restarting it ?
<poolie> wgrant, not yet
<wgrant> lifeless: It needs to be taught about wheezy first.
<wgrant> Or it will see the new wheezy pubs that gina imported this morning, and ignore them because wheezy isn't a valid series.
<StevenK> lifeless: Changes pushed, diff updated.
<lifeless> StevenK: oh, btw you don't need the super() call
<lifeless> I totally glitched on that
<lifeless> you're not upcalling, you're side calling
<StevenK> lifeless: But it's in a superclass?
<lifeless> does'nt matter
<lifeless> it would matter if you wanted that *specific* variant
<StevenK> Okay, let me change that
<lifeless> but there are no variants, and if there were you'd want the one in your class
<lifeless> self.error_handler
<lifeless> self.error_handler(..)
<lifeless> yes, that all looks good.
<lifeless> one final suggestion would be s/error_handler/recipe_error_handler/
<StevenK> Rargh, I just reflowed stuff due to the method call being short
 * StevenK waves his arms at lifeless
 * lifeless waves back
<wgrant> poolie: Are we going to turn the package importer on before we unstack sid?
<lifeless> wgrant: I think you should
<lifeless> unstacking is orthogonal
<wgrant> It's not entirely orthogonal until bzr has a GC.
<lifeless> wgrant: sure it is; you're going to unstack sid, which will have /zero/ impact on the revisions present in the basis for wheezy branches.
<lifeless> wgrant: because the unstack will fetch them into the sid branches if they are in sids current dependency
<wgrant> lifeless: Is stacking transitive?
<lifeless> wgrant: yez
<lifeless> yes
<lifeless> the only thing I can see going wrong is something in squeeze that sid doesn't reference - a dead head - that wheezy then references.
<wgrant> Ohh. I had always understood that it stacked on a branch's repo, not the whole branch.
<lifeless> the branch contains the pointer
<StevenK> I can't see that happening -- if something isn't in sid, then it almostly certainly isn't in wheezy
<lifeless> it points to another branch
<wgrant> lifeless: Right, but I basically assumed it would just look for whatever repo was there.
<lifeless> at runtime the chain of branches is loaded and a composite repository with (however many) extra revision sources is assembled
<wgrant> Not follow further stacking references.
<wgrant> Right.
<wgrant> StevenK: Hmm? Why not?
<wgrant> StevenK: wheezy is a copy of squeeze
<wgrant> anything from t-p-u will be in wheezy but not sid.
<lifeless> it has to follow branches, because otherwise the repository it found there would be broken
<StevenK> Sorry, I was thinking source package names only
<wgrant> This is a major problem.
<wgrant> Ugh.
<wgrant> lifeless: Can you see a way to work around this? Unless when we unstack sid we also pull the missing revs into the repo of things stacked on it..
#launchpad-dev 2011-02-08
<lifeless> wgrant: which missing revs
<lifeless> wgrant: if you want todo that btw, its easy.
<lifeless> after unstacking
<lifeless> do sidbranch.repository.fetch(oldbasis.repository)
<poolie> wgrant, i think we should leave it off just for the sake of being careful
<poolie> i'd be happy to look at your script too
<StevenK> wallyworld_: O hai?
<wallyworld_> StevenK: yo
<StevenK> wallyworld_: With your RM hat on, when do you expect PQM to re-open for srs bzns?
<wgrant> lifeless: The revs containing versions that entered squeeze through testing-proposed-updates instead of sid.
<wallyworld_> StevenK: i'm waiting on a branch in db-devel to make it into devel - another rc db patch occured
<wallyworld_> StevenK: i'd say a bit after eod our time today
<lifeless> wgrant: that one liner will ensure that any such revs are copied
<lifeless> wgrant: and because the stack is transitive, its complete.
<wgrant> lifeless: Perhaps we should revert the dev focus to squeeze, push up wheezy branches, then unstack sid and restack everything on top of sid next week. Otherwise we have to fetch on every child before we can unstack sid.
<lifeless> wgrant: huh?
<lifeless> wgrant: I think you're underestimated bzr
<lifeless> wgrant: add that one liner I gave you above to the script; fin.
<wgrant> lifeless: wheezy branches will reference revs that sid does not reference, but they will get them through sid's stacked-on branch.
<lifeless> thats fine
<lifeless> the fetch line above will copy said revisions
<wgrant> So we cannot just unstack sid using my usual script. We first have to go through every branch stacked *on* sid, and fetch into them.
<wgrant> This seems a lot more risky than just unstacking sid ASAP.
<lifeless> no we don't
<lifeless> I think we need voice
<wgrant> Oh, you want to pull the entire contents of the squeeze repo into sid?
<wgrant> That would work, but is a bit dirty.
<lifeless> skype?
<wgrant> If it ever connects.
<wgrant> Oh good, it works.
<wgrant> Ready when you are.
<lifeless> poolie: the wheezy config changes to the pkg importer are being done by the bzr team ?
<lifeless> poolie: wgrant and I agree that the importer should be started up now; we'll deal with the mechanics of changing stacking for sid next week.
<poolie> i can do them now; i don't know of anyone doing them at the moment
<poolie> ok
<poolie> thanks for working that out
<thumper> wallyworld_: I'm back now
<wallyworld_> thumper: ok. all pumped and toned i assume
<lifeless> the current plan for unstacking is to use the bzrlib api to unstack & fetch all revs from squeeze into sid; this will increase the size of sids repositories but its a one time hit.
<thumper> wallyworld_: actually shaking and trying not to die
<lifeless> we need to check there is enough space on crowberry to do that.
<wallyworld_> thumper: mumble?
<thumper> ok
<lifeless> jam: btw
<lifeless> https://code.launchpad.net/~loggerhead-team/loggerhead/trunk-rich/+reviewer - has loggerhead-team as reviewer already
<lifeless> the reason you get that annoying mail is that launchpad is in loggerhead-team
<poolie> https://code.launchpad.net/~leonardr/launchpadlib/bug-714043/+merge/48842 really reminds me of the glock safety design
<lifeless> so we could change that to be canonical-launchpad-reviewers, though that would stop considering the folk who are individually involved in loggerhead already
<wallyworld_> thumper: https://code.launchpad.net/~wallyworld/launchpad/request-build-popup/+merge/48864
<lifeless> flacoste: btw
<lifeless> https://bugs.launchpad.net/apache-openid/+bug/712698/comments/2
<_mup_> Bug #712698: No way to expire existing sessions <Apache OpenID:New> < https://launchpad.net/bugs/712698 >
<lifeless> sinzui: around ?
<sinzui> I am
<lifeless> perhaps you could review https://code.launchpad.net/~lifeless/launchpad/showtimes/+merge/48754
<lifeless> for gotchas
<lifeless> its a developer only thing
<sinzui> lifeless: the Mp's description does not mention changes to bug task. Are those changes unintended?
<lifeless> oh
<lifeless> it has a separate branch conflated with it accidentally
<lifeless> that branch is reviewed and approved
<lifeless> ignore the bugs/* changes
<sinzui> lifeless: okay. This look great. I have no remarks. I will update the MP
<wgrant> lifeless: Why is the <script> element done like that?
<wgrant> Can't it be a real element in the TAL, with a <tal:blah replace="render_time" /> inside it?
<lifeless> wgrant: tal evaluates as it goes.
<mwhudson> i think it's because zpt is terrible about <script>
<wgrant> Could you put the JS in the normal place, and just set the variable there?
<thumper> script tags are special for TAL
<thumper> nothing inside a script tag is executed by TAL
<thumper> if you need expansion
<wgrant> Keeping code XML-quoted in an attribute seems... suboptimal.
<thumper> you do a replace="string: lots of rubbish..."
 * wgrant lunches.
<mwhudson> is chameleon less unhelpful abou this?
<thumper> wgrant: look at lib/lp/app/templates/text-area-editor.pt
<thumper> wgrant: that seems to be how we do it now
<lifeless> so, it could be a little better. Meh, next time its touched.
<lifeless> okies
<lifeless> wgrant: so checkwatches
<thumper> wallyworld_: mumble now?
<wallyworld_> ok
<lifeless>   Hard / Soft  Page ID
<lifeless>      341 / 6404  Archive:+index
<lifeless>      273 /  468  BugTask:+index
<lifeless>      134 /  304  Distribution:+bugs
<wgrant> lifeless: Hi.
<lifeless> hi
<lifeless> wgrant: so
<wgrant> lifeless: Sorry, Unity decided to wander away for a while.
<wgrant> Seems happy now.
<lifeless> so
<wgrant> What do you know about the CCW-spam?
<lifeless> first I'm going to point you at a bug
<lifeless> https://bugs.launchpad.net/launchpad/+bug/623199
<_mup_> Bug #623199: scripts do not establish valid zope partiticipations <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/623199 >
<wgrant> Ah, right, that one.
<lifeless> many backend scripts do not create participations/run in different security model
<lifeless> webapp.adapter therefore *duplicates* this infrastructure
<lifeless> so we have two different 'request' concepts
<lifeless> lib/lp/bugs/scripts/checkwatches/base.py
<lifeless> the interaction context manager
<lifeless> *that* gets called around each watch
<lifeless> its buggy, per bug 623199
<_mup_> Bug #623199: scripts do not establish valid zope partiticipations <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/623199 >
<lifeless> fixing the CCW issue won't fix bug 623199; I just wanted to paint the larger picture
<_mup_> Bug #623199: scripts do not establish valid zope partiticipations <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/623199 >
<wgrant> lifeless: Interestingly, checkwatches is running with --jobs=1 at the moment...
<lifeless> wgrant: so basically I suspect its as easy as adding, after setupInteraction
<lifeless> either an adapter.set_request_start or lp.services.timeline.requesttimeline.set_request_timeline call
<lifeless> and similar before the end interaction
<lifeless> wgrant: possible, on the transaction property instead of the interaction one; I'm ambivalent there. But one or tother should do it.
<wgrant> lifeless: I'm currently waiting for a big OOPS to load to see why it's trying to do more than one job in a single script execution.
<wgrant> But lp-oops is very slow.
<poolie> wgrant, it's working out if the import of wheezy works that may be harder
<lifeless> wgrant: jobs is concurrency not length
<wgrant> lifeless: Ah, I confused it and --batch-size.
<wgrant> sinzui: Still around?
<wgrant> lifeless: So, I'm not exactly sure what we want to do here, because a lot of the OOPSes happen in the batch retrieval code, which is outside the per-watch code.
<lifeless> whats batch retrieval all about
<wgrant> lifeless: For some tracker types it will retrieve lots of bugs in a single request.
<wgrant> https://lp-oops.canonical.com/oops.py/?oopsid=OOPS-1864CCW2202 for example.
<lifeless> well
<lifeless> I think we want a context no smaller than that needed to make sense of the oops
<wgrant> Right.
<wgrant> We could possibly wrap the batch code in one timeline.
<lifeless> 3532642
<wgrant> And then each watch update in another.
<lifeless> seems larger than needed.
<wgrant> Yes, slightly.
<lifeless> wgrant: that sounds like a reasonable first approximation
<wgrant> We may end up with massive timelines wrapping them, though.
<wgrant> But I wonder how many exception happen outside there.
<wgrant> My guess is "not many"
<lifeless> wgrant: we can iterate
<wgrant> So I might make a context manager than switches in a new timeline.
<wgrant> It'll leave big gaps in the overall one, though. Hmm.
<huwshimi> A js fix for bug #457856 if someone is available sometime to review. Thanks! https://code.launchpad.net/~huwshimi/launchpad/tag-dialogue-457856/+merge/48868
<_mup_> Bug #457856: Tag dialog never closes <bug-page> <bugtag> <lp-bugs> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/457856 >
<huwshimi> Nevermind, lifeless is one step ahead of me.
<huwshimi> lifeless: Thank you :)
<lifeless> huwshimi: anytime
<wgrant> lifeless: Does it sound reasonable to have a catch-all timeline handle things when none of the finer-grained ones do?
<wgrant> It's bad, but I'm not sure what else we can do.
<lifeless> wgrant: sounds like it needs restructuring
<lifeless> wgrant: the finer grained things do commits
<lifeless> wgrant: generally speaking a timeline across commits is rather pointles
<lifeless> s
<wgrant> Ah, true.
<wgrant> I guess.
<wgrant> I wanted to ideally keep more state around, but with differing transactions it's probably pointless.
<lifeless> s/pointless/buggy/
<wgrant> Well, the previous behaviour is still potentially handy.
<lifeless> I think there should always be a timeline when there is a participation | db queries
<lifeless> but it should be fresh when the transaction is reset (and we shouldn't be carrying objects across transactions)
<huwshimi> Anyone know what I need to get this branch to not fail its tests? http://paste.ubuntu.com/564218/
<huwshimi> I think the important bit might be: Failed to create database or load sampledata.
<huwshimi> This is with ec2 land
<StevenK> psycopg2.ProgrammingError: type "debversion" does not exist
<StevenK> That's the error
<StevenK> And *awesome*, we need a new AMI
<lifeless> I thought bigjools made one
<lifeless> ah... probably hasn't made it public yet
<StevenK> Yes, I just remembered
<StevenK> I thought he did, but bin/ec2 didn't know about his ID?
 * StevenK checks
<StevenK> huwshimi: Which revno of devel is that branch based on?
<lifeless> ah yes, merging in trunk should fix, if its an old(ish) branch
<StevenK> Right
<huwshimi> erm, how do I find out? :)
<StevenK> r12336 of devel has the merge in it
<StevenK> huwshimi: I use bzr log and look for the first comment message that starts with '[r=
<huwshimi> StevenK: Maybe r12337
<StevenK> lifeless may have a better way
<StevenK> huwshimi: Do you still have the output from ec2 land? And you know PQM is closed, right? :-)
<lifeless> bzr show-merge-base , bzr missing - probably bzr missing
<StevenK> bzr missing assumes launchpad/lp-branches/devel is up to date
<StevenK> As a caveat
<huwshimi> StevenK: Oh, I did not.
<StevenK> huwshimi: PQM is closed so we can nail done exactly which revision is going to be deployed -- once we're close it will re-open. Hint: PQM state is in the topic.
<StevenK> s/done/down/
<huwshimi> StevenK: Yeah, I just didn't think
<StevenK> However, I'm still concerned which machine id your ec2 land used
<StevenK> Er, s/machine id/AMI/
<huwshimi> StevenK: Where do I need to look for that info?
<StevenK> huwshimi: If you have the output that ec2 land dumped into your terminal, one of the first lines is "Using machine ..."
<huwshimi> I have the terminal open, but not enough lines to show back that far
<huwshimi> StevenK: Unless there's a way to go back further
<StevenK> huwshimi: I don't think so, but you might be able to edit the Profile for your terminal and increase the scrollback lines. The output might be lost, though.
<huwshimi> StevenK: No luck
<huwshimi> StevenK: Actually I have the info from my console. What do you want? AMI ID?
<huwshimi> StevenK: From Elasticfox console
<wgrant> There should be an "Using machine image version 504", or something like that.
<wgrant> Ah.
<wgrant> Does it show the AMI owner?
<huwshimi> wgrant: There's an owner ID, but it doesn't say anything to do with AMI... might be the same thing though
<StevenK> huwshimi: Can you run the script in http://pastebin.ubuntu.com/564220/ in your branch root?
<StevenK> That will tell us the machine image version your branch things is the latest
<StevenK> *thinks
<StevenK> huwshimi: The output is one line, so just paste it
<huwshimi> StevenK: RuntimeError: Your version of paramiko (1.7.6 (Fanny)) is not supported.  Please use 1.7.4.
<StevenK> Wow, I did see that when I ran it
<StevenK> And I have 1.7.6 installed. This is strange.
<huwshimi> You did see it or you didn't?
<StevenK> steven@liquified:~/launchpad/lp-branches/devel% ./which_ami.py
<StevenK> (507, [Image:ami-4209f92b])
<huwshimi> StevenK: Well elasticfox gives me: ami-fa956493. Does that help?
<StevenK> huwshimi: Yes, that's 504.
<StevenK> Which is too old.
<huwshimi> StevenK: Is that all you wanted to know?
<StevenK> huwshimi: It means you need to merge devel into your branch and then ec2 land should work
<huwshimi> StevenK: OK. When will PQM open again?
<StevenK> That's up to wallyworld_.
<huwshimi> StevenK: Like a couple of days or a week or something?
<wallyworld_> huwshimi: another version of db-devel is being merged right now. then it needs to be deployed
<StevenK> huwshimi: Estimates say our tonight
<huwshimi> wallyworld_: Oh right
<wallyworld_> huwshimi: the release is scheduled to occur in a day or so but there's been some qa issues
<huwshimi> wallyworld_: Yeah I saw some emails.
<wallyworld_> so hopefully this latest deployment occuring now will be The One and we can open pqm again
<huwshimi> wallyworld_: Great :)
<wallyworld_> huwshimi: not so great that we've had these issues :-) but i think everything's been found and fixed so that's good
<lifeless> StevenK: you can run missing with a url
<StevenK> Ah
<StevenK> huwshimi: Are you good, or have you not merged devel into an existing branch before?
<huwshimi> StevenK: All good.
<huwshimi> StevenK: Thanks for that.
<huwshimi> I guess I'll find out when PQM opens up again
<StevenK> huwshimi: You're welcome
<huwshimi> Seeing open interface bugs that were filed in 2006 hurts.
<huwshimi> We should change the reported date format to "Reported by Foo, 5 years ago" just so that it hurts that little bit more.
<wallyworld_> huwshimi: i didn't know you were into pain :-)
<huwshimi> wallyworld_: :)
<huwshimi> wallyworld_: The pain is knowing that there are users who are unhappy because we haven't fixed things.
<wallyworld_> huwshimi: yeah. gary fixed bug 548 for this release. not sure if that's the oldest but it would have to go close
<_mup_> Bug #548: Launchpad sends change notification updates to the person who requested the change <email> <lp-bugs> <qa-ok> <story-better-bug-notification> <story-better-notification-sending> <Launchpad itself:In Progress by yellow> < https://launchpad.net/bugs/548 >
<lifeless> huwshimi: most bugs affect users, ui ones are privileged :)
<lifeless> *aren't*
<huwshimi> wallyworld_: Ouch.
<huwshimi> lifeless: I know, but they're the ones I can fix :)
<lifeless> I'm glad you are
<huwshimi> lifeless: And UI bugs can make great technology horrible to use
<lifeless> huwshimi: indeed
<huwshimi> lifeless: Although it goes both ways
<lifeless> huwshimi: indeed !
<lifeless> bad technology can drive terrible UI
<huwshimi> lifeless: You're glad I'm what?
<lifeless> fixing
<huwshimi> lifeless: I'm trying!
<huwshimi> Another review if anyone feels the desire: https://code.launchpad.net/~huwshimi/launchpad/hover-row-43231/+merge/48877
 * huwshimi is heading off, night people.
<adeuring> good morning
<poolie> hello abel
<bigjools> good morning
<jtv> morning bigjools
<al-maisan> moin adeuring, bigjools and jtv!
<jtv> morning al-maisan!
<adeuring> hi al-maisan!
<jtv> and mrevell too of course
<mrevell> Hey there
<mrevell> jtv, and me what? :)
<al-maisan> hola mrevell
<mrevell> Hello al-maisan!
<jtv> mrevell: "moin"
<mrevell> How is the land of Alps, skiing and low taxation?
<jtv> And let's not forget molten cheese.
<mrevell> Ah yes.
<mrevell> And alp-horns.
<bigjools> cowbell
<al-maisan> it's great fun :)
<mrevell> Excellent :)
<al-maisan> once you start understanding "Schweizer Deutsch" which is the local dialect :)
<mrevell> I visited Interlaken 20 years ago and I seem to remember they had a word other than "schloss" for castle.
<mrevell> :)
<al-maisan> not sure about that one .. but the Swiss do have their own vocabulary .. I came across some words I've never heard before .. "ZnÃ¼ni" would be one example
<al-maisan> which is the Swiss term for "snack" :)
<wgrant> bigjools: Did you have everything on a tmpfs?
<bigjools> makes no difference
<bigjools> I have huge gobs of memory anyway, everything gets cached easy
<Ursinha> good morning
* gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is in RC for devel | firefighting: - | On call reviewer: gmb (r-c gets priority) | https://code.launchpad.net/launchpad-project/+activereviews
<lifeless> jml: hi
<jml> lifeless: hello
<lifeless> jml: I think you may have missed https://bugs.launchpad.net/launchpad/+bug/713518
<_mup_> Bug #713518: recipe description is mandatory <recipe> <Launchpad itself:New for jml> < https://launchpad.net/bugs/713518 >
<jml> lifeless: I have not.
<jml> lifeless: just haven't got around to it.
<lifeless> jml: its the only untriaged bug we have; would be nice to have a clean slate.
<jml> lifeless: ok.
 * bigjools considers a Firefox patch to make ctrl-Q pop up an "are you sure" dialog
<lifeless> bigjools: 'vimperator'
<bigjools> lifeless: not sure I want to turn my browser into an editor
<lifeless> him
<lifeless> hmm
<lifeless> there should be a foxerator then
<bigjools> I think I tried it a year or so ago
<bigjools> the simple solution is to warn on ctrl-q like every other browser does :)
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (424): FIXED in 5 hr 44 min: https://hudson.wedontsleep.org/job/devel/424/
<jml> bigjools: "every other browser" eh?
 * bigjools waves hand
<jml> :)
<jml> chrome has disabled C-q
<bigjools> "these aren't the browsers you're looking for"
<jml> which isn't such a bad idea
<bigjools> chrome has ctrl-shift-Q IIRC
<bigjools> yeah
<jml> oh, that's good to know
<jml> tbh, I'd rather have the browser fast to start with an easy way of getting old tabs back than an Are you sure? box. Not that they're mutually exclusive.
<bigjools> the problem is losing data in unsubmitted forms
<bigjools> if it restored that, then fine
<jml> bigjools: yeah, it ought to warn about that.
<jml> or restore, as you say.
<jml> I really want these damned driving lessons to be over.
<bigjools> restore would be better although I imagine it'd do nothing for browser performance
<bigjools> pass yer test then :)
<jml> waiting for them to book the test!
<jml> doesn't help that they went bankrupt and got bought out.
<bigjools> !
<lifeless> well, gnight
<jml> bigjools: yeah. BSM went into receivership. Got bought by AA, I think.
<bigjools> nn lifeless
<bigjools> jml: damn, they were quite big too
<jml> bigjools: yeah
<jml> apparently they got bought a year or so ago by some guys who basically drove the business into the ground. (pardon the pun)
<bigjools>  /o\
<jml> all of the instructors are in work, but I imagine call centre & office staff might be facing probs.
<jml> AA are going to keep the brand, because, well, they aren't stupid.
<bigjools> I find it fun that AA can also mean something about drinking
<jml> yeah. me too.
<jml> grant me the serenity to get through this lesson without resenting my instructor
<bigjools> on a more topical note, why do we get "Unknown entry URL:" all over the place when compiling wadl?
<jml> I don't know.
<jml> I think I used to have an idea, but if I did it has gone.
<bigjools> I vaguely remember something in the past about having to fix stuff in lazr.restful
<bigjools> eek, my eggs directory is busy
<wgrant> IIRC it happens when the interface has no URL template defined.
<wgrant> I think they might have to be defined in the XSLT..
<wgrant> Which lives either in LP or launchpadlib.
<wgrant> It moves around occasionally.
<bigjools> we need to do 1 of 2 things:  1) fix it, or 2) remove the warning if it's not a problem
<bigjools> I suspect the latter since we've lived with those warnings for as long as  I can remember
<wgrant> Yes.
<jml> hmm.
<jml> I wonder if "No warning without a ratchet" is a sensible idea.
<jtv> gmb: got a non-urgent branch for youâ¦ https://code.launchpad.net/~jtv/launchpad/bug-181368-parallelize/+merge/48903
<gmb> jtv: Okidoke. I'll take a look at it when I come back from grazing.
<jtv> OK
<wgrant> jtv: !!
<jtv> wgrant: ??
<wgrant> Yay!
<jtv> Yay?
<wgrant> Parallel a-f.
<jtv> Oh
<jtv> Yeah that was easy.  Making sure it works is the hard part.
<wgrant> Yeah.
<jtv> Also, I first had to come up with some infrastructure of course.  But that's best done separately.
<jtv> Of course the big question now is: will it help?  :-)
<wgrant> It will.
<deryck> Morning, all.
<jtv> hi deryck!
<jtv> wgrant: it will, assuming the processes don't start fighting over I/O.  Which I suppose will depend largely on FS cache.
<wgrant> Well, yes, but I trust cocoplum to not be too shit.
<jtv> If it is, there's one exceedingly simple fix: limit the number of parallel processes.
<wgrant> Right.
<jtv> Easy to do underneath the MF API.
<jtv> And ta-daaa: you have something similar to go's thread management.
<jtv> (Who made that insightful remark?  "You'd expect a leading search engine company to put a bit more thought into making sure people can search for their new programming language on the internet.")
<al-maisan> sounds familiar but I can't recall who it was
<al-maisan> agu
<al-maisan> ooops
<jtv> al-maisan: those last two things I imagine are sounds often heard in the land of fondu. :-)
<al-maisan> he-he
<al-maisan> jtv: agu = apt-get update
<al-maisan> jtv: sorry to disappoint you ;)
<jtv> Oh.  I thought it made a wonderful onomatopoeia but another GTF entry is good too. âº
<bigjools> hmmm since when did "test -1" stop working :(
<jtv> bigjools: what did that do?
<jtv> al-maisan: thank you for TLA number 23772.
<al-maisan> jtv: you're welcome :)
<bigjools> jtv: stops after first error
<bigjools> kinda useful for pagetests
<jtv> ah yes
<jtv> that does sound useful
<jtv> and I guess now it's not.
<wgrant> So that *did* used to work.
 * wgrant blames a zope.testing upgrade a few months ago.
<wgrant> I'd been beginning to think it had never worked.
<bigjools> jtv does the TLA list include TLA itself?
<jtv> bigjools: what do _you_ think?
<bigjools> heh
<bigjools> you need to start an ETLA list
<jtv> bigjools: even the name includes itâ¦ GTF stands for the GPL'ed TLA FAQ
<jtv> Everyone keeps saying that, but everyone can do it themselves!
<al-maisan> every self-respecting TLA list obviously needs to include "TLA" ;)
<bigjools> I am amazed that you'd never heard of LFLs though
<jtv> http://paste.ubuntu.com/564394/
<jtv> bigjools: I think that's because where I come from they're called Blinkenlights.
<bigjools> Two Letter Acronym / Three-Letter Abbreviation
<bigjools> inconsistency!
 * jtv was in the Computer History Museum recently and saw the real blinkenlights
<bigjools> holy crap the ppa page tests crawl
<jtv> Perhaps a 2-letter one should be called a bilexical acronym (BA).
<bigjools> is "jtv" in the GTF? :)
<jtv> $ tla jtv
<jtv> JTV	Jeroen Thomas Vermeulen
<jtv> JTV	Jordan TeleVision
<bigjools> \o/
 * jtv wonders if we need an IRC bot to answer TLA inquiries
<bigjools> jtv: gimme your API details, I'll code it into edbot
* leonardr changed the topic of #launchpad-dev to: https://dev.launchpad.net/| PQM is in RC for devel | firefighting: - | On call reviewer: gmb, leonardr (r-c gets priority) | https://code.launchpad.net/launchpad-project/+activereviews
<jtv> urrr there's a shell script that wraps grep. :)
<bigjools> pfff
<jtv> Although there's also a "GTF Monitor" written in Java.
<al-maisan> jtv: so, it is enterprise ready then ;)
<jtv> ouch :)
<al-maisan> sorry .. could not resist :P
<bigjools> java gives me nightmares just thinking about it
<al-maisan> COBOL^Wjava has a safe albeit "limited" future according to tech pundits
<al-maisan> whatever that means
<wallyworld> what's wrong with java?
<bigjools> where do I start ...
<wallyworld> well, nothing is perfect but you can't argue with java's adoption and usefulness in the enterprise
<jtv> A lot of that, in turn, is because it supports large-scale software development by low-skill developers.
<wallyworld> bigjools: i want to be able to nominate the rev for release. it's now on qastaging.  do you need to do any final checks to ensure the debversion functionaity if all ok?
<jtv> Therefore, I wonder if Oracle will re-brand Java as Enterprise PHP.
<bigjools> wallyworld: I'll take a quick wander around some pages, gimme 5 mins
<wallyworld> jtv: hey, i was/am a java dev for 13 years. who you calling low skill :-)
<jtv> wallyworld: having seen you with a Bushmaster including telescopic sight, I'll gladly point out the "supports" as not implying "requires."
<jtv> Gladly, nodding politely, and grinning slightly worryingly
<wallyworld> jtv: i know where you live :-)
<jtv> Good.  Glad that's all settled.
<wallyworld> gary_poster: morning to you. i would love it if you could take a couple of minutes to double check qastaging to ensure the person settings db stuff is all 100% ok so I can select the rev to deploy and hence open pqm.
 * bigjools stabs staging
<wallyworld> gary_poster: rev 12338 has the db patch included and is the rev running on qastaging now
<bigjools> bloody timeouts
<wallyworld> yeah, those timeouts sure take the "joy" out of qa :-)
<bigjools> I can't test this change since the damn page is timing out
<wallyworld> :-(
<bigjools> I'll take a slightly less demanding PPA page
<wallyworld> i find hitting refresh several times eventually makes it work
<bigjools> not in this case :(
<gary_poster> wallyworld: hi.  thank you, on it
<wallyworld> awesome
<bigjools> wallyworld: it looks ok
<wallyworld> bigjools: thanks muchly
<bigjools> here's hoping pqm can open
<wallyworld> i hear you
<bigjools> right, food time
<gary_poster> wallyworld: qastaging is happy
<wallyworld> gary_poster: \o/ thank you
<gary_poster> :-) thank you
<wallyworld> \o/ PQM is open again
<gary_poster> yay thanks wallyworld
<wallyworld> gary_poster: np. only just over one day till rollout. can't come soon enough  :-)
<gary_poster> heh, I hear you :-)
<leonardr> gmb, if you're not reviewing anything atm, can you take https://code.launchpad.net/~leonardr/launchpadlib/bug-712808/+merge/48830 ? i need it to get the new launchpadlib into natty
<gmb> leonardr: I'm just in the middle of reviewing jtv's branch. I can take a look at it after that, though.
<leonardr> gmb, great
<gmb> jtv: Most of the tests in TestFTPArchiveRunApt need comments, if you please. Otherwise I'm happy with the code, but I'm not convinced that I actually have enough domain knowledge to review this - my brain seems to keep skipping off it.
<gmb> jtv: I'll give it r=me, but you might want to get a review from someone who knows more about it than I do.
<jtv> gmb: thanksâthe tests were an attempt to make the identifiers speak for themselves, so apparently that failed.  The domain knowledge is actively being contributed by william & julian.
<gmb> jtv: Well, you could be running up against my brain being tired today.
<leonardr> gmb, i don't know anything about it but i'm fresh, i can take a look
<gmb> jtv: ^^
<gmb> leonardr: https://code.launchpad.net/~jtv/launchpad/bug-181368-parallelize/+merge/48903 is the MP in question
<leonardr> ok
<jtv> leonardr: appreciated!
<leonardr> don't thank me yet...
<jtv> uh-oh âº
<leonardr> actually, it's not so bad since i reviewed your CommandSpawner branch last week
<gmb> leonardr: r=me on your branch, btw.
<leonardr> gmb, great
<jtv> leonardr: as I recall, the Pilfering Puppy distro release led to questions.  There's also an Ominous Okapi.
<jml> meh. X redraw issues still present.
<bigjools> jml: intel?
<leonardr> jtv, test_getArchitectureTags_contains_no_duplicates would be easier to read if you created the architecture tag and processor family ahead of time. otherwise it looks like there's something special about pilfering puppy
 * jtv looks
<jtv> leonardr: I'm a bit worried about making the setup too long thoughâalways a problem with Soyuz
<leonardr> jtv: you could just assign ominous_arch.architecturetag and .processorfamily to generic-sounding variables
<leonardr> comments would also help. that's the only test it's been difficult for me to read so far
<jtv> What if I do that, but in a separate "give me two identical archdistroserieses but for different release series of the same distro" method?
<jtv> Maybe even a "how many archdistroseries would you like for this distro and architecture" argument?
<leonardr> jtv: sure. i think you'd use that in the next test as well?
<jtv> Exactly.
<jtv> And with the extra argument, I might be able to use the same method for creating a single archdistroseries as well.
<jtv> Not that that's too much use though.
<jtv> It just seems slightly easier to explain.
<leonardr> i think your first idea was better
<jtv> Can I play with it for a bit and get back to you?
<leonardr> sure
<leonardr> jtv: did the last test fail because the architecture started with --?
<leonardr> or because you got it to use some "bogus-config"?
<jml> bigjools: yeah
<jtv> leonardr: frankly I don't know.  I only wanted it to breakâand the other tests confirm that normally the exception does not happen.
<bigjools> jml: same here - the intel driver is buggy as hell
<jtv> leonardr: call it blind hatred as a testing methodology.
<jml> bigjools: this is natty
<jml> bigjools: worked fine in mav
<bigjools> jml: it's been fucked since maverick
<jtv> leonardr: I just piled on whatever I could to make it break.
<bigjools> I guess gnome didn't prod it in the same way as kde until natty
<bigjools> I get GPU hangs
<jml> bigjools: I just get redraw bugs. I have to PgUp then PgDown every time someone says something on IRC
<bigjools> jml: yeah I get that too :)
<leonardr> jtv: i'm a little bit worried at what looks like an argument injection attack
<jtv> leonardr: yes, that's what it isâbut only our code could do that.
<bigjools> jml: turn off compositing and see if that helps
<jml> bigjools: done so, doesn't.
<bigjools> :(
<jtv> leonardr: it's basically a test attacking the regular code, and showing that it leads to the appropriate exception.
<leonardr> jtv: you couldn't relaly create a distro arch series called --fail-for-my-test?
<jtv> leonardr: that's an interesting point that I'll have to look into.
<jcsackett> gmb, leonardr: when you get the chance i have an mp: https://code.launchpad.net/~jcsackett/launchpad/bugtasks-deacitvated-context-632847/+merge/48925
<gmb> jcsackett: I'll take a look in a minute
<jcsackett> gmb: thanks!
<bigjools> what is wrong with this documentation:
<bigjools> param principal: The principal for the request
<jml> :param principal:
<jml> also, it doesn't say what a principal is.
<bigjools> 1 cookie to jml
<jml> but maybe other docs around it make it clear.
<bigjools> see lib/lp/testing/views.py
<leonardr> jtv: r=me once you clarify the tests, especially the last one
<bigjools> well, see most of our docstrings.... :/
<bigjools> it drives me batty
<jtv> leonardr: still looking into the architecture tagâ¦ bigjools, where do architecturetags come from?
<bigjools> distroarchseries
<jml> bigjools: not the best docs ever.
<jtv> bigjools: Yes but who puts them there?
<bigjools> jtv: we do, and we need to do better
<jtv> leonardr, bigjools: how about I add some validation as part of a separate branch that can even bypass this one?
<leonardr> jtv: i'm not sure what you mean by 'bypass this one'. the other branch will go in first?
<jtv> leonardr: also, once I have a nice & short test setup, do you feel the tests will still need comments?
<jtv> leonardr: that's a possibility, yes, since this branch is being held up by other things.
<leonardr> jtv: the only ones i felt needed comments were the two i called out. i'll take another look once you refactor
<jtv> leonardr: great!  Doing that now.
<bigjools> jtv: what do you need to validate?  Sorry, I'm missing some context apart from the a-f branch.
<jtv> bigjools: make sure there can't be any weirdness in the tag, so people can't blow up the apt-ftparchive call.
<bigjools> jtv: ok I see.
<nigelb> Hey, someone from the lp team can talk about daily builds and lp at UDW?
<bigjools> god DAMN openid + oops page.... >:(
<bigjools> jtv: ok now I know what you're doing, you need to use the Processor table
<jml> nigelb: yeah, probably.
<bigjools> see the "name" column
<bigjools> it has all the tags
<jtv> thanks
<nigelb> jml: can I put you down for it? :)
<bigjools> jtv: and this is an excellent piece of validation
<jml> nigelb: I'm not going to volunteer right now, because I need to know times, dates and so forth
<nigelb> jml: I can show you empty slots and you can pick one
<jml> nigelb: could you email lp-dev?
<nigelb> jml: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable/
<nigelb> jml: yup, will do
<jtv> bigjools: so the validation happens at the processor, not at the distroarchseries?
<jml> nigelb: thanks.
<bigjools> jtv: if you want to make sure the tag is a valid one, look it up as Processor.name
<jtv> bigjools: isn't that ensured when the DAS is created?
<bigjools> jtv: quite probably - I'd be surprised if this sort of thing is not checked repeatedly
<jtv> leonardr, bigjools: also, my impression is that the scope for breaking the apt-ftparchive invocation is limited to making the invocation fail, and it can be done only by someone with the power to create an architecture tag to be used for that build.
<leonardr> jtv: ok, so it's not a big problem
<nigelb> jml: Mailed :)
<bigjools> jtv: correct - it's whomever sets up the DAS
<jtv> leonardr: I don't _think_ so, but best be careful. :)
<jml> nigelb: thank you.
<jtv> bigjools: is that a privileged operation?
<bigjools> yes
<bigjools> did Ian open PQM after the release revno was decided?
<jtv> bigjools: then I think the risk of this particular use is acceptable.
<bigjools> jtv: I think belt + braces is good though
<bigjools> protecting the archive is always a good idea :)
<jtv> bigjools: OK, then how about we add a constraint and a UI validator to the tag?
<bigjools> jtv: you might be fighting sampledata :/
<jtv> oh good :/
<bigjools> which is a world of pain in soyuz
<jtv> You're telling a Translations guyâ¦
<bigjools> :)
<Ronnie> anoyone knows hoe to limit the credentials for websites that ask user to access their LP account,  with only: allow_access_levels=["WRITE_PRIVATE"]
 * bigjools also needs to send a patch to the bazaar team so that "bzr doff" does something
<benji> bigjools: it should show you all the lines that haven't changed
<gmb> lol
<bigjools> :)
<Ronnie> im talkin about: https://help.launchpad.net/API/ThirdPartyIntegration#Website%20integration
<leonardr> Ronnie: what website is this?
<Ronnie> some testings for loco-directory
<leonardr> Ronnie: can you explain in more detail what you want? are you a user of this website or are you the one setting up the integratino?
<leonardr> we don't have a good story for website-to-website integration right now
<allenap> gmb: Fancy a fairly trivial review? https://code.launchpad.net/~allenap/launchpad/better-caching-iterator/+merge/48927
<gmb> I've still got to look at jcsackett's, but after that, sure (if leonardr doesn't get there first)
<leonardr> allenap, i'll do it
<allenap> gmb, leonardr: Thank you :)
<Ronnie> leonardr: im a developer of the loco website. currently there is a link on the team pages (Example: http://localhost:8000/teams/ubuntu-nl (you need to login first)) (https://launchpad.net/~ubuntu-nl/+join) which results in leaving the loco-directory page. therefore i want to do this on the backend
<Ronnie> some ubuntu teams do not use the loco-directory much, because they should register on LP and manage their profiles on LP (which in english only). As the loco-directory we try to make the interaction with LP partly invisible
<leonardr> Ronnie: ok, when you redirect the user to launchpad.net/+authorize-token, you will add the query argument "allow_permission=WRITE_PRIVATE"
<Ronnie> leonardr: that works, thx
<jtv> bigjools, leonardr: I've updated my test setup.  Those two tests are much cleaner now.
<jtv> Shall I add validation in a separate branch?  I don't think my branch particularly affects what a bad tag might or might not break.
<leonardr> jtv, sure another branch is fine
<jtv> Thanks.
<gmb> jcsackett: One minor comment on your branch, but it's r=me.
<jtv> leonardr: by the way, just the bogus config turns out to be sufficient to break the script run in the test.  So I removed the bogus option.
<leonardr> allenap, r=me
<bigjools> abentley: lp/services/job/tests/test_runner.py / test_timeout is failing in db_lp, would you mind having a look please?
<leonardr> jtv: i think you should test both a failure to invoke the script and the failure of the script?
<allenap> leonardr: Thanks.
<abentley> bigjools, looking.
<bigjools> thanks
<jtv> leonardr: I don't see a differenceâthe question is what happens when the command returns failure.  Either way the command gets run, and breaks while processing its arguments.
<leonardr> jtv: ah, i didn't realize the command is run either way
<leonardr> ok, just the bogus config is fine
<jtv> :)
<jtv> Thanks.
<abentley> bigjools, thumper was looking at that failure last.  I don't know what conclusions he came to.
<bigjools> abentley: ah ok, didn't realise it was an old one, I only just saw the email pop up
<bigjools> seems like StuckJob is not really stuck
<abentley> bigjools, you could probably increase the length of time it waits, but I don't understand how it could fail to time out.
<abentley> bigjools, I've never observed it locally.
<abentley> bigjools, this is bug #681770
<_mup_> Bug #681770: Failure in lp.services.job.tests.test_runner.TestTwistedJobRunner.test_timeout <lp-foundations> <Launchpad itself:Triaged> < https://launchpad.net/bugs/681770 >
<bigjools> aha
<bigjools> it was reported in november!
<abentley> bigjools, or possibly bug #505913
<_mup_> Bug #505913: TestTwistedJobRunner.test_timeout fails intermittently <lp-foundations> <spurious-test-failure> <Launchpad itself:Triaged> < https://launchpad.net/bugs/505913 >
<jml> deryck: are we able to use YUI 3.3 stuff in Launchpad yet?
<deryck> jml, not yet.  but I'm about an hour for having my upgrade branch ready for review.
<jml> deryck: sweet. :)
<deryck> jml, so another day or two and you can have your charts ;)
<benji> has anyone seen "psycopg2.ProgrammingError: type "debversion" does not exist" while doing a make schema?
<bigjools> abentley: is that really doing a sleep(30) in the middle of  test :/
<jml> benji: yes.
<abentley> bigjools, yes, so that it will timeout after a few seconds.
<jml> benji: I haven't had the opportunity to chase it any further than that.
<bigjools> abentley: we should be winding the reactor clock forwards to simulate that.... would be a lot more reliable
<abentley> bigjools, sounds low-level and risky to me.
<benji> jml: thanks; well I'll see what I can do
<bigjools> abentley: it's a standard twisted testing approach, it's done like that in a few places
<jml> there's an object that implements the same interface as the IReactorTime (spelling?) and has a special .advance() method to change the time to something in the future.
<jml> relies on passing the reactor in.
<bigjools> jml: Clock() :)
<jml> bigjools: thanks. not sure if I got the interface right though.
<bigjools> I don't know what its interface is so I didn't pick you up on that
<abentley> bigjools, anyhow, I have trouble understaing how a job could have a timeout of 1 second, yet complete successfully after 30 seconds.
<bigjools> abentley: yeah something is weird
<bigjools> what is the lease_length unit?
<jcsackett> gmb: thanks for the r. :-)
<gmb> np
<abentley> bigjools, seconds, IIRC.
<benji> jtv: apt-get install postgresql-8.4-debversion
<jtv> benji: Permission denied
<benji> sudo make me a sandwich
<benji> I guess I should file a bug and/or point this out on the dev list.
<jtv> benji: No rule to make target `me'.  Stop.
<jtv> benji: care to explain what you're talking about?
<benji> jtv: that fixes the "psycopg2.ProgrammingError: type "debversion" does not exist"
<jtv> benji: I have a vague recollection of hearing about thatâ¦ something for bigjools maybe?
<benji> jtv: of course, it would help if you were jml, but that's a side issue :P
<bigjools> benji: update lp-deps
<jtv> benji: I thought there was something along those linesâ¦ help whom though, I wonderâhim, you, me, or the team?
<benji> jtv: :)  I need all the help I can get.
<bigjools> s/benji/jtv/
<jtv> bigjools: now don't _you_ start!
<jtv> bigjools: what was that about?
 * bigjools is desperately trying to get context :)
 * benji starts over.
<benji> jml: apt-get install postgresql-8.4-debversion fixes the "psycopg2.ProgrammingError: type "debversion" does not exist" problem
<jml> benji: thanks.
<bigjools> wait
<bigjools> just update lp-dependencies
<bigjools> jml ^
<jml> launchpad-developer-dependencies is already the newest version.
<sinzui> gmb: leonardr: can either of you review https://code.launchpad.net/~sinzui/launchpad/recipe-owner-widget-1/+merge/48937
<leonardr> sinzui, i got it
<LPCIBot> Project db-devel build (349): FAILURE in 5 hr 36 min: https://hudson.wedontsleep.org/job/db-devel/349/
<jml> benji: which Ubuntu are you using?
<benji> jml: maverick
<jml> benji: huh.
<jml> I can understand lp-dependencies being wrong for me since I'm on natty.
<benji> jml: my install was screwed up anyway, so I'm not surprised, launchpad-developer-dependencies wasn't even installed
<jml> benji: ahh.
<gary_poster> gmb or leonardr, is it still appropriate to highlight newly-created MPs, or is it now considered pushy? :-)
<gary_poster> If not pushy, https://code.launchpad.net/~gary/launchpad/bug713392/+merge/48939 :-D
<gmb> gary_poster: It's fine :)
<leonardr> gary: it's fine by me
<gary_poster> ok thanks :-)
<gmb> gary_poster: I'll look shortly.
<gary_poster> awesoe
<gary_poster> m
<leonardr> sinzui, having a bit of difficulting understanding your branch, so going to try out the code
<sinzui> yes?
<sinzui> leonardr: https://code.launchpad.dev/~mark/firefox/release--0.9.1/+new-recipe
<sinzui> leonardr: and https://code.launchpad.dev/~mark/firefox/release--0.9.1/+register-merge
<jcsackett> gary_poster: question for you about bug 623099. got a sec?
<_mup_> Bug #623099: AttributeError filing a bug using the API <lp-foundations> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/623099 >
 * gary_poster looks jcsackett 
<jcsackett> i have the feeling this might be going away as the edge redirects go away, gary_poster. is that wishful thinking on my part?
<gary_poster> I *think* it is wishful, jcsackett...I think this redirection is for old project names
<gary_poster> and I don't think that the edge/not-edge part of it is going to affect much
<gmb> gary_poster: r=me
<gary_poster> thanks gmb
* gmb changed the topic of #launchpad-dev to: https://dev.launchpad.net/%7C PQM is in RC for devel | firefighting: - | On call reviewer: leonardr (r-c gets priority) | https://code.launchpad.net/launchpad-project/+activereviews
<leonardr> sinzui: "if '<label' in text" is a little hacky (for instance, it won't catch "< label"). why did you choose that over "Redefine _renderItem() to so that a wrapping label is not added,"
<jcsackett> gary_poster: ah, i had missed the project name redirect.
<sinzui> leonardr: we will shoot any engineer who constructs markup like "< label"
 * jcsackett is blinded by subdomains.
<gary_poster> jcsackett: :-)
<leonardr> sinzui: what if we shot any engineer who constructed their own <label> tag?
<sinzui> leonardr: but I agree is a hack. We know that a label cannot cannot contact a label so any occurrence of "<label" in the text means we cannot generate a wrapping label
<leonardr> why is it important to allow the subclass to generate its own label? it doesn't seem like anything special to me
<sinzui> leonardr: Some are doing more than for="" attrs, they are adding scripts to them
<leonardr> i see
<sinzui> leonardr: other have special rules for generating the id of the for="" attr
<leonardr> sinzui: i don't see UNSAFE_TERM used in TestSuggestionWidgetCase. are you showing that it doesn't show up at all because it's not returned by _getSuggestions?
<leonardr> if so, why make it unsafe? i thought you would demonstrate that it was rendered properly
<sinzui> leonardr: oops. I cargo culted that with the intention to use it in a test to veryify something waky does not happen
<leonardr> sinzui: ok, add that test
<sinzui> leonardr: I think I should write a test with UNSAFE_TERM to verify a bad display name does not render markup
<leonardr> i agree
<leonardr> sinzui: r=me with that added test and a couple other trivial changes
<sinzui> thank you leonardr
<jcsackett> sinzui: do you know what mechanism is responsible for redirection from old product names? e.g. ubuntufontbetatesting => ubuntu-font-family
<sinzui> jcsackett: yes, Launchpad's root object uses pillar name lookup and if it is an alias, it gets the real pillar
<jcsackett> sinzui: thanks.
<jml> woot
<jml> working IRC client.
<jml> and emacs
<Ronnie> leonardr: i have some problems with the Launchpad website integration. https://help.launchpad.net/API/ThirdPartyIntegration#Website%20integration . Everytime i do the request, a have to give access. im probably doing something wrong. http://paste.ubuntu.com/564580/
<leonardr> Ronnie: are you storing the credentials in a persistent data store, and reusing them? i don't see that in your code
<Ronnie> oh, i have to pickle the credentials and save it into the DB?
<leonardr> Ronnie: yes, otherwise launchpad can't identify you with the client who made the previous request
<Ronnie> leonardr: what happens when the user at some point decides to revoke the authentication?
<leonardr> Ronnie: you'll try to use the credentials on the web service and you'll get a 401, so you'll have to redirect them to authorize new credentials
<Ronnie> oke, thx
<Ronnie> how much steps / user actions would it take if the user needs to create an LP account from an login.ubuntu.com openid account?
<leonardr> Ronnie: i don't know.
<leonardr> you'd have to do a click to https://login.launchpad.net/+new_account -- i don't know what would happen after that
<Ronnie> leonardr: can i test this on staging without creating real new accounts?
<Ronnie> or would this still trigger the openid server to create a new openid
<leonardr> Ronnie: good question. maybe salgado knows
<salgado> Ronnie, leonardr, I think you should be able to create new accounts on staging; it uses login.staging.lp.net instead of login.lp.net
<leonardr> there you go
<Ronnie> salgado: thx ill have a look then
<leonardr> bigjools, i'm reviewing your branch
<Ronnie> salgado: ah, login.staging.launchpad.net runs on django. got an error ;)
<Ronnie> http://paste.ubuntu.com/564602/
<Ronnie> salgado: any more information you need?
<salgado> Ronnie, I don't know much about our openid provider; it's maintained by another team
<Ronnie> salgado: who should i contact?
<salgado> sinzui, do you know who Ronnie should talk to about that error on login.staging.lp.net?
<sinzui> salgado: Not really. I think a losa + stuart metcalfe, but my knowledge is 19 months our of data
<sinzui> salgado: ricardokirkner may have work on it in the last 6 months
<salgado> sinzui, indeed, I've asked him
<leonardr> bigjools, r=me with some additional thought about wording
<salgado> <ricardokirkner> I think staging may be currently broken (at least login.staging.ubuntu.com is)
<salgado> <ricardokirkner> because we deployed some code to staging last week which requires a db upgrade
<salgado> <ricardokirkner> which was reset on monday (as it usually does)
<salgado> <ricardokirkner> we have a redeploy on schedule for this week
<salgado> Ronnie, ^
<Ronnie> ok, good to know
<Ronnie> the registration process did work tough, except for the error
<salgado> Ronnie, in the future, if you have issues with login.lp.net (including the staging version), you can report it on #canonical-isd
<Ronnie> salgado: ok, i will next time
<Ronnie> thx for the help
<salgado> sinzui, ^ (fyi)
<thumper> morning
<thumper> I'm trying to work out when to run for coffee
<thumper> my machine is still not right :-(
 * thumper leaves his home office in favour of shared office with coffee shop attached
<lifeless> jml: still around ?
<thumper> gah
<thumper> shared office space has blocked IRC
<thumper> running on 3g tether
<lifeless> :(
<lifeless> shoot em
<mwhudson> wtf
<thumper> I've asked him on facebook :)
<mwhudson> freenode runs on a bunch of non-standard ports
<thumper> I'm connecting to port 4242 at home
<mwhudson> if they're doing packet inspection to block the irc protocol, shoot them with great force
<thumper> mwhudson: I think they have just blocked a shed load of high ports
<thumper> I can ssh home
<mwhudson> ah ok
<thumper> I wonder if mumble works
<thumper> skype is open
<thumper> I wonder how well mumble works over 3g
<mwhudson> latency is the killer
<mwhudson> (also most 3g contracts forbid voip)
<cjohnston> so does the new squads mean that blueprints are going to be fixed?
<abentley> cjohnston, updating blueprints is part of the plan.
<wallyworld_> thumper: i could hear you fine, maybe you didn;t hear me
<cjohnston> yay!
<cjohnston> any idea as to a time frame abentley ?
<abentley> cjohnston, I don't have that information handy.
<thumper> wallyworld_: yeah, didn't hear you
<wallyworld_> hmmm. stupid mic
<lifeless> cjohnston: we're probably going to be doing the IssueTracker LEP
<cjohnston> is there some further info on that lifeless ?
<cjohnston> (somewhere)
<wallyworld_> thumper: my mic is borked
<lifeless> cjohnston: its not scheduled yet, we're currently driving our cycle time down and doing fewer things faster & better
<thumper> wallyworld_: so fix it :)
<wallyworld_> trying
<cjohnston> cool
<lifeless> cjohnston: https://dev.launchpad.net/IssueTracker
<cjohnston> thanks
<thumper> mwhudson: mumble works over 3g
<thumper> mwhudson: not too bad
<mwhudson> cool
<abentley> lifeless, you estimated 6-12 months, right?
<lifeless> abentley: something like that yes; AIUI this is reasonably high on jmls list
<lifeless> high enough that the product team were doing analysis with mpt the whole epic
<leonardr> thumper, are we having a standup?
<thumper> leonardr: yep
<thumper> leonardr: wally and I are in mumble
<leonardr> ok
<thumper> StevenK: ping
* leonardr changed the topic of #launchpad-dev to: https://dev.launchpad.net/%7C PQM is in RC for devel | firefighting: - | On call reviewer: - (r-c gets priority) | https://code.launchpad.net/launchpad-project/+activereviews
<leonardr> thumper et al: https://code.launchpad.net/~leonardr/launchpad/use-web-link
<thumper> StevenK: nm, just remembered where you are
<lifeless> wallyworld_: here ?
<thumper> w00t
<thumper> got the ports un-firewalled
<thumper> it's all good
<wallyworld_> lifeless: i just have to duck out and drop the kid to school, i'll ping you when i'm back
<lifeless> wallyworld_: ok, was just checking pqm is opened
<wallyworld_> lifeless: yes, opened last night. i sent an email
<lifeless> \o/
<lifeless> the mail didn't mention pqm :)
<wallyworld_> yeah, tell me about it
<wallyworld_> yes it did?
 * wallyworld_ looks
<lifeless> hmm, perhaps I'm blind
<lifeless> I saw 'rev selected'
<lifeless> anyhow, you have to pop out
<lifeless> so shoo
<wallyworld_> agggh. i "refacroed" the email as i was writing it and cut out the bit about pqm :-(
<wallyworld_> and i can't type
<Ronnie> lifeless: ping
<lifeless> hi
<Ronnie> wow thats quick :D
<Ronnie> i trying to implement launchpadlib (user/website access) into loco-directory
<Ronnie> with the new approach the following steps are needed (worst case secnario): http://paste.ubuntu.com/564709/
<Ronnie> it still pretty much
<Ronnie> did you have tought for other ways to implement>
<Ronnie> or can the pages seen in step 9-12 be translated?
<Ronnie> or is it possible the change (on request) the LP openid provider from login.launchpad.net to login.ubuntu.com ?
<Ronnie> ow, maybe i can make LD to skip step 12 and check for ourself (altough the popup should still be closed)
<lifeless> so, is LD grabbing a launchpadlib oauth token on the users behalf?!
<Ronnie> yes, its a possible way i think it is most userfriendly
<Ronnie> for users who do not want it, can change their data on LP itself tough
<lifeless> is the LD deployment area secured ?
<Ronnie> good question
<Ronnie> mhall119: ^
<Ronnie> cjohnston: ^
<lifeless> so, as long as the LD deployment is really secure, I think this is reasonable
<lifeless> its what OAuth is all about, after all - the ability for e.g. twitter to log into gmail
<Ronnie> the LD is (i tohught) maintained by caninical-isd
<lifeless> It may well be, and if so thats great.
<Ronnie> yes, with OAuth the server must really be trusted
<wgrant> lifeless: With Launchpad's current... security... I'd say that allowing any other website to have an OAuth token on your behalf is beyond foolish.
<lifeless> wgrant: in principle I agree, but the LD code can be vetted and is open
<lifeless> if its deployed by losas the isn't a risk due to who is operating it :)
<lifeless> s/the/there/
<wgrant> :(
<lifeless> wgrant: I'd be delighted for us to be much more granular
<lifeless> 'LD wants permission to add you to / remove you from teams starting with ubuntu-loco-*'
<wgrant> No, not that. IArchive['publish'] now uses "publish" to describe its function, and its description starts with 'Whether'
<thumper> psycopg2.ProgrammingError: type "debversion" does not exist
<lifeless> bigjools patch ?
<thumper> on make schema
<thumper> WTF?
<lifeless> thumper: update your lp deps
 * thumper sighs
<thumper> doing that now
<wgrant> lifeless: Yes.
<lifeless> wgrant: why do we need disabled archives?
<wgrant> lifeless: OEM does.
<lifeless> not whom, why
<wgrant> lifeless: They have approved moving the flags to +admin.
<wgrant> I don't really know.
<wgrant> cody-somerville would know.
<lifeless> cody-somerville: ^
<wgrant> lifeless: The difficulty is that Zope security is crap.
<wgrant> So it's hard to have .publish and .enabled on +edit for copy archives, and +admin everywhere else.
<lifeless> wgrant: what makes that hard? Is it a lack of separate types, or lack of an adapter declaring when view/edit are available
<wgrant> lifeless: I can move the widgets easily, but I can't say that both launchpad.Edit and launchpad.Commercial can set them.
<lifeless> so why do copy archives need .enabled ?
<lifeless> wgrant: also, you'd just say that .edit is needed, and grant .edit to commercial admins on such objects
<cody-somerville> lifeless, Hey. Whats your question exactly?
<wgrant> lifeless: They should not have .Edit on such objects.
<lifeless> cody-somerville: why do you need an enabled/disable flag for publishing
<wgrant> lifeless: Because they start disabled so they can be tweaked (dependencies, scores) before they start building.
<lifeless> cody-somerville: alternatively, if we said 'PPAs are always enabled', what impact would that have on you.
<cody-somerville> lifeless, We disable PPAs in a number of circumstances such as a project freeze or for commercial reasons.
<thumper> lifeless: :(
<thumper> updated all dependencies
<thumper> and I still get that error on make schema
<wgrant> thumper: Is postgresql-8.4-debversion installed?
<wgrant> And postgres restarted?
<lifeless> thumper: is postgresql-8.4-debversion installed ?
<thumper> nope
<wgrant> Your dependencies don't seem to be updated.
<thumper> what is pB in debian statuses?
<thumper> pinned?
<thumper> if so, how do I change it?
<thumper> pB  launchpad-developer-dependencies
<cody-somerville> lifeless, We'd be sad if we could no longer disable PPAs but I suppose it wouldn't be the end of the world if you really need to remove that feature.
 * thumper installs   launchpad-developer-dependencies 
<lifeless> cody-somerville: I'm questioning the value of everything :)
<lifeless> cody-somerville: particularly things that regularly lead to foot-gun events.
<dobey> the worst part about foot-gun events, is when there's no bandage to stop the bleeding afterward :)
<cody-somerville> Understood. Incidentally, we actually use the ability to disable PPAs to avoid our own foot-gun events. :-)
<huwshimi> sinzui: Not sure what happened there, ack now though
<huwshimi> *back
<sinzui> huwshimi: I cannot hear you
<wgrant> huwshimi: We can hear you.
<huwshimi> ugh
<lifeless> cody-somerville: ok, well we'd need to figure out how to preserve your safety without encouraging other users to break stuff :)
<wgrant> lifeless: They want to create a derivative distro and use our queue functionality.
<huwshimi> wgrant, sinzui: I'll reconnect
<cody-somerville> lifeless, I thought that was accomplished by moving the option to the 'Administer PPA' page?
<dobey> lifeless: pretty much every time i click "disable ppa" what i actually want is "eradicate this ppa from the face of the internets"
<huwshimi> sinzui: No luck, if you guys are talking I can't hear it.
<cody-somerville> dobey, When you click the edit PPA link to get where the disable ppa option is you don't notice the delete this PPA link underneath it? :P
<sinzui> huwshimi: :(. DO you want to talk since we hear you?
<huwshimi> sinzui: ok, tell me when :)
<sinzui> go
<dobey> cody-somerville: well, ok, so i do click delete ppa i guess
<sinzui> I hear
<dobey> cody-somerville: but it sticks around as "Abandoned $PPANAME"
<dobey> which is kind of eh
<cody-somerville> dobey, yea... not sure why it doesn't get hidden all together
<sinzui> thanks huwshimi
<wgrant> We don't want to delete the DB records completely at the moment.
<huwshimi> sinzui: Weird. I got sound back just as you said goodbye
<wgrant> But I want to rename the PPA out of the usual namespace, and hide it.
<huwshimi> sinzui: Did you want to have a look at the work I've done so far on the unification of colours sometime?
<sinzui> huwshimi: I would love to
<sinzui> I will be free in about 2.5 h
<huwshimi> sinzui: Ok great
<wgrant> huwshimi: Is this the deletion of facet colours?
<huwshimi> wgrant: yeah
<wgrant> Excellent.
<wgrant> First step to merging the domains.
<lifeless> oh man
<wallyworld_> lifeless: the latest buildbot failure (on the db-devel branch) - seems rather random to me. TestTwistedJobRunner does appear to have a genuine failure but as to why.... ?
<lifeless> wgrant: gary may have some ideas about the security issue you're running into
<poolie> hi huwshimi
<huwshimi> poolie: Hey there
<poolie> hi huwshimi
<wgrant> We're not still RC, are we?
#launchpad-dev 2011-02-09
<lifeless> pqm is open
* lifeless changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<wgrant> lifeless: Erk
<wgrant> garbo-hourly is failing
<wgrant>  -> http://launchpadlibrarian.net/63827955/dMm2kkmdygvorvKKvD9t02EQdHa.txt (duplicate key value violates unique constraint "bugmessage__bug__index__key"
<lifeless> thanks
<lifeless> unindex that bug
<wgrant> Hm?
<lifeless> a bug message index is being changed
<lifeless> if we unindex that bug, it will resume
<wgrant> Right.
<lifeless> we can tell the bug by running the query it uses
<lifeless> -> -ops and nab a losa
<wgrant> Ah, possibly, true.
<lifeless> alternatively
<lifeless> unindex all partly indexed bugs
<poolie> where should a developer guide to feature flags live? on the wiki? under the architecture guide?
<mhall119> lifeless: the production environment for LD is secure, it's on Canonical's servers and managed by the sysadmins
<mhall119> any credentials or anything can be stored there, and even us developers wouldn't know them
<poolie> wgrant, i have a patch up for multiply stacked repositories, which is +1
<poolie> i will land that, i guess into 2.3
<wgrant> poolie: So I saw.
<wgrant> Should I patch our egg with it?
<poolie> do you know of any other problems related to this?
<wgrant> I don't really feel like RCing 2.3 in.
<poolie> i thought you had a branch not an egg?
<wgrant> We have an egg, not a branch.
<poolie> (hm, did that change?)
<poolie> anyhow, that seems like a reasonable approach to me, given my understanding of lp deployment
<wgrant> Not in my time, I don't think.
<lifeless> wgrant: I'll do a branch in the meantime, when reindexing, to set all to NULL, then flush, then assign values.
<wgrant> lifeless: Thanks.
<wgrant> poolie: Hm, we're running a patched 2.2.2 at the moment.
<wgrant> I suppose we should upgrade to at least 2.2.4 soonish.
<wgrant> wallyworld_: Hi.
<wallyworld_> hello
<wgrant> wallyworld_: I am about to apply https://code.launchpad.net/~mbp/bzr/715000-stacking/+merge/48886 to our bzr egg.
<wgrant> wallyworld_: This ideally wants to be deployed tomorrow.
<wgrant> Will we deploy the latest stable rev, or the one that you blessed?
 * wallyworld_ looks
<wallyworld_> wgrant: the mp diff has conflict markers in it?
<poolie> wgrant, since we just froze 2.3.0 i think we should go straight to that
<poolie> wallyworld_, that's because it's targeted to trunk; it should be clean against 2.2
<wgrant> poolie: OK, I might do that next week.
<poolie> i'd be happy to help
<wallyworld_> poolie: wgrant: is there an urgent need to have to rollout the bzr update with this release or can we do it as a nodowntime deployment after release?
<wgrant> wallyworld_: crowberry isn't in nodowntime.
<wgrant> But I guess this is only realllllly needed on loganberry.
<wgrant> I think.
<wallyworld_> ah ok
<wgrant> This is also a critical issue.
<wallyworld_> last time a bzr upgrade went into lp, stuff broke so i'm being cautious
<wgrant> It is preventing us from starting the package importer, which blocks UDD.
<wgrant> Right.
<wgrant> But this is a very small patch :)
<wallyworld_> so was the other one :-P
<wgrant> Oh?
<wgrant> I don't recall it.
<wallyworld_> i can't recalls the specifics now
<poolie> we can do it separately from the release i think
<poolie> in that case, why not do it now and then do the release tomorrow?
<wallyworld_> to me, any change close to release time is risky
<wgrant> wallyworld_: OK, can I at least get it on stable nowish so we can deploy right after the release?
<poolie> i know, but it's always release time
<wallyworld_> we need time to do proper qa, considering the potentialimpact if the bzr upgrade breaks things
<wallyworld_> poolie: true
<lifeless> so
<lifeless> this is what I suggest
<lifeless> a) land the patch
<lifeless> b) qa
<lifeless> c) if, at rollout time, a newrev is deployable, great. Do that.
<lifeless> d) if the bzr change isn't ready by then, we do scheduled downtime to codehosting to deploy it
<wgrant> That was my plan.
<wgrant> Except that loganberry runs the scanner, so we probably don't need downtime.
<wallyworld_> does bzr 2.3 have the change in it already?
<wgrant> No.
<wallyworld_> so in that case imho we patch our current bzr egg as suggested
<poolie> great
<wallyworld_> and rollout 2.3 later once it has had the change and full qa for the other new 2.3 things etc
<wallyworld_> qa in terms of lp integration
<wallyworld_> poolie: you still ok to help with the forking lp-serve switchover tomorrow?
<wallyworld_> do you need to help?
<wgrant> wallyworld_: Right, that's what I thought.
<wallyworld_> wgrant: great. thanks for doing the work to get it in
<poolie> wallyworld_, i shouldn't need to do anything afaik but i'll be on line if you want to talk/ask about it
<poolie> i just want to make sure it goes live
<poolie> you could perhaps check now whether it's sufficiently documented in the rt etc
<poolie> or i guess we can just discover that tomorrow
<wallyworld_> poolie: that would be appreciated. just in case.  i've not enough knowledge to know if the doc is good. has a dry run been done using the doco? if not, perhaps we should do one?
<poolie> good idea; maybe we should do it with a losa
<poolie> i guess spm
<wallyworld_> if he is the one doing the work on the day, then that would be my suggestion
<poolie> it's not *that* scary of a change
<wallyworld_> sure, but doco needs "testing", just like code :-)
<wallyworld_> just to ensure that it is correct and when followed on the day, everything goes as expected
<wallyworld_> so a dry run often achieves this goal, especially when done by the intended implementer
<poolie> sure
<poolie> so when spm gets back(?) we could do a walk-through?
<wgrant> poolie: Can a 2.3.1 come soon with this fix, or should I prepare a patched 2.3.0?
<poolie> wallyworld_, i think of you when i say "treat every gun as loaded" in bug 714043 :)
<_mup_> Bug #714043: defaulting to staging is confusing <launchpadlib :Triaged> < https://launchpad.net/bugs/714043 >
<poolie> wgrant, it can come soon
<poolie> but where are you going to use a patched 2.3?
<poolie> i thought you said lp was on 2.2.
<wgrant> poolie: I'm patching 2.2.2 for now.
<wgrant> But you say we want to be on 2.3.0 soon.
<poolie> ah, by the time we get there it will be in 2.3x, and probably in 2.3.1
<poolie> i think for conceptual clarity it would be good to keep lp on actual releases as much as we can
<wgrant> Definitely.
<poolie> huwshimi, oh, interesting re my comment about hover and tablets to see the thread about mobile browsers
<wgrant> How do I run bzr tests?
<wallyworld_> poolie: watch what you say or else i'll get out my uzi. i know where you live :-)
<poolie> ./bzr selftest
<wgrant> I tried that.
<wgrant> bzr: ERROR: exceptions.AttributeError: 'module' object has no attribute '_WritelnDecorator'
<wgrant> :/
<wgrant> Maybe it'll work on 2.6.
<wgrant> Yes.
<spm> <wallyworld_> sure, but doco needs "testing", just like code :-) <== /me awards 100 awesome points to wallyworld_ :-)
<poolie> was that on 2.7?
<poolie> i think that's fixed in bzr 2.3
<wgrant> That was.
<wgrant> I forgot that 2.2 was still 2.7-hating.
<thumper> FUUUUUUU.....
<wallyworld_> spm: i spent 10 years seeing the results of deployment doco used on site without doing a run through first - not pretty :-)
<poolie> :)
<spm> ha
<wallyworld_> poolie knows the project i am referring to :-)
 * thumper wants to stab lazr-js in the face
<cjohnston> lifeless: if by secured you mean I can't access it yes... we have to submit an RT
 * thumper takes a deep breath
<poolie> yeah, and i tried to help deploy it after about 6 months working on it
<poolie> i felt a bit out of my depth :)
<poolie> was kind of fun though
<lifeless> wgrant: checkwatches; halted? in progress?
<sinzui> huwshimi: wontfix? really? I was hoping for a unification of shades and a fix for the two odd tables I found
<wgrant> lifeless: I was going to get back onto it after lunch, which is itself going to happen once I get this bzr thing proposed.
<huwshimi> sinzui: I think those are a separate issue. If you file a bug about them I can get to them at some stage.
<huwshimi> sinzui: I think there are bigger issues with the readability of the tables, and I'm not sure the hover is the right solution.
<sinzui> huwshimi: I think mpt had similar concerns in the past
<huwshimi> sinzui: I want to think about the tables a bit more and come up with a plan.
<sinzui> huwshimi: The plethora of background shades may be the same issue. I wonder if I never see some of them
<huwshimi> sinzui: yeah there is a bit of that.
<huwshimi> sinzui: I'm always grepping through the source trying to find weird situations where things show up
<sinzui> I new to look at the mirrors listing because I recalled they had an exceptional style
<sinzui> s/new/knew/
<sinzui> or gnu
 * thumper is full of lazr-js sadness
 * thumper branches lp:lazr-js again
<lifeless> thumper: whats wrong?
<thumper> lifeless: I'm hacking a BinaryChoiceWidget based on lazr-js ChoiceEdit
<thumper> lifeless: it is just not good, and needs fixing
<thumper> I'd be happy to bitch at length, but that doesn't help it get fixed
<thumper> also, your use of the ChoiceEdit for the vocabulary choosers is HORRIBLE
<thumper> and needs to be widgetized
<thumper> s/your/our/
<thumper> it is just a whole pile of javascript hurt in our tree
<thumper> and the bug use of it is not entirely standard
<thumper> which also hurts
 * thumper goes to pick up the girls from school
<poolie> i'm going out to lunch, maybe we can do the walkthrough after htat
<lifeless> I need a quick teddy bear
<lifeless> I want to use feature flags in base-layout
<lifeless> but base-layout also does +opstats
<lifeless> which has a DisallowedStore policy
<lifeless> so I'm thinking that catching DisallowedStore in the flag lookup and signalling no-rule, would be ok.
<lifeless> anyone see a zomg thing with that ?
<thumper> I don't know what the DisallowedStore policy is
<lifeless> lib/canonical/launchpad/webapp/dbpolicy.py
<lifeless> its used for pages which are nt allowed to use a given store
<lifeless> e.g. +opstats isn't allowed DB access at all
<wgrant> lifeless: I think that's OK.
<thumper> lifeless: when is the exception raised?
<lifeless> the alternative is, in the +opstats codepath to inject a different FeatureController
<thumper> lifeless: as long as it is not before the query, you should be ok
<lifeless> thumper: its raised in IStore
<lifeless> theres some nuance around this thing, I'm going to keep looking, but thats the crux of it
<wgrant> poolie: I cannot get bzr selftest to pass on the 2.2 branch on either of my machines, parallel or not :(
<poolie> wgrant, i'll check
<poolie> i'm pretty sure the whole thing passed here last night
<poolie> wgrant, did you merge it into any branch, or just run mine as-is?
<thumper> lifeless: got a minute to chat?
<poolie> spm, hi
<wgrant> poolie: I merged it into our 2.2.2-ish branch.
<wgrant> But I also tried lp:bzr/2.2.
<wgrant> Without your patch.
<wgrant> And it fails there too.
<wgrant> lp:~launchpad/bzr/2.2-lp is your patch on top of our branch.
<poolie> !
<lifeless> thumper: sure
<thumper> lifeless: skype?
<lifeless> also
<lifeless> I hate our request timeout tests
<spm> poolie: am about to fetch boy from school, I'll ping you on return?
<poolie> sure
<poolie> wgrant, maybe your branch is old enough that the thread leak bugs i thought were fixed are still present
<poolie> but even then it never caused it to actually fail for me, just some warnings
<wgrant> poolie: There's nothing in 2.2 to fix them.
<wgrant> Since you presumably have a working test setup, could you test our branch?
<poolie> yes, i will
<poolie> i'm re-running my branch now
<poolie> wgrant, i suppose i should test on lucid?
<wgrant> poolie: That would be great, if you could.
<poolie> yes, i have a schroot
<lifeless> bug 707234
<_mup_> Bug #707234: multiple redundant copies of person picker make_picker function in view-source:https://bugs.launchpad.net/launchpad-project/+bugs?advanced=1 <javascript> <Launchpad itself:Triaged> < https://launchpad.net/bugs/707234 >
<poolie> wgrant, ok, i do get some spurious failures due to, i think, testtools version mismatches
<poolie> that's on maverick, my branch, my laptop
<poolie> will re-run lp's branch under lucid shortly
<wgrant> Thanks.
<poolie> turns out i need to bootstrap it
<poolie> anyhow, my branch, aside from some things i feel safe saying are skew against testtools, passes ok
<wgrant> Right, thanks.
<wgrant> The changes in lp:bzr/2.2 since we branched are irrelevant, so it seems good.
<wgrant> I will push the egg.
<poolie> just so i know, what do you actually do to make this happen?
<wgrant> python setup.py sdist, copy it into ~/launchpad/lp-branches/download-cache/dist, commit, push.
<wgrant> Then create an LP branch updating versions.cfg.
<lifeless> ahhha
<lifeless> finally got it all figured out
<lifeless> so
<lifeless> rendering an exception is done with db access turned off
<lifeless> the first few lines of handleException
<lifeless> and base-layout is used there, so my change to base-layout triggers the flag lookup
<poolie> bug expiry just restarted
<poolie> or at least, it just got around to projects i'm watching
<huwshimi> wgrant: What were you saying the other day about not having a wrapping element on tal conditions?
<wgrant> poolie: I thought it was restricted to ubuntu. Maybe that changed in the last few days.
<poolie> it just hit bzr
<wgrant> poolie: And LP.
<wgrant> huwshimi: Any element in the tal: namespace will be omitted from the rendering.
<poolie> since we told people about it in http://blog.launchpad.net/general/enabling-automatic-bug-expiry ah about 3 months ago, maybe we should tell them now?
<huwshimi> wgrant: ok thanks
<wgrant> poolie: Do you know how I create an sdist with pyrex already compiled to C?
<poolie> i think so but i'm not sure
<wgrant> Oh.
<wgrant> The one in download-cache at the moment appears to not be an sdist at all.
<wgrant> Perhaps it is a manually created tarball.
<wgrant> thumper: Around?
<poolie> wgrant, my run under lucid of 2.2-lp completed with some thread leaks, one failure due to not having python-dev installed, and no other problems
<poolie> also i sent that branch to pqm for our 2.2
<wgrant> Thanks.
<wgrant> poolie:
<wgrant> -17 04 * * * $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/expire-bugtasks.py -l 200 --ubuntu >> /srv/launchpad.net/production-logs/expire-bugtasks.log 2>&1
<lifeless> grr
<wgrant> +17 04 * * * $LP_PY /srv/launchpad.net/production/launchpad/cronscripts/expire-bugtasks.py >> /srv/launchpad.net/production-logs/expire-bugtasks.log 2>&1
<lifeless> now a DoomedTransaction
<wgrant> Last night.
<poolie> ?
<poolie> they took of the size limit and the limit to ubuntu
<poolie> but now it's doomed because it's too big?
<spm> poolie: yo
<poolie> wgrant, that's lp-production-configs or something?
<wgrant> poolie: lp-production-crontabs
<wgrant> lifeless' doom is unrelated.
<poolie> :)
<wgrant> Codehosting tests, please stop messing with my dev branches...
<poolie> wgrant, sanity check of http://blog.launchpad.net/?p=1925
<poolie> spm, hi, i'm happy to go through the lp-serve rollout dry run whenever you are
<spm> poolie: lets make it so
<wgrant> poolie: I can't see it.
<poolie> wgrant, how about if you click log in?
<poolie> in the top right
<wgrant> I didn't even know there was a login link.
<wgrant> But so there is.
<wgrant> No, it still hates me.
<wgrant> Doesn't use LP teams.
<poolie> huh
 * poolie tries
<wgrant> I can log in.
<wgrant> But I have no privs.
<poolie> win
<poolie> now you should
<wgrant> So I do.
<wgrant> poolie: Looks good.
<wgrant> Could you do it last night? :)
<lifeless> wgrant: no, its very related.
<lifeless> wgrant: if a db request expires the transaction is doomed
<lifeless> *as well* as requestexpired getting raisde.
<poolie> thanks
<wgrant> lifeless: This is related to the unchoking of expire-bugtasks.py?
<poolie> hahaha
<poolie> i can _pretend_ i did it last night, does that help? :-)
<poolie> iwbn to have had whoever committed that change do it
<lifeless> wgrant: no, getting the render time patch landed
<wgrant> Yes.
<wgrant> lifeless: Right.
<wgrant> lifeless: So it's not related.
<lifeless> wgrant: its related to the thing I have been whining about
<lifeless> wgrant: when I said 'now a DoomedTransaction' it was following that thread.
<wgrant> lifeless: Right, but you said that right after my expire-bugtasks.py diff, which seemed to confuse poolie that it was related.
<lifeless> oh
<spm> poolie: do you have some docco on the process for the lp-serve rollout lying around somewhere? or is it buried in the losa wiki and I need to search harder?
<lifeless> you were not speaking to me in saying it was unrelated
<lifeless> gotcha
<wgrant> lifeless: Yeah, "'", not ":".
<poolie> spm, there's an rt linked from unusual rollout requests
<spm> Ahh. ta
<poolie> if it's missing anything i'm happy to add it but i'd rather you read it than me just tell you
<poolie> so we have docs
<spm> wfm
<spm> oh. gah. face. palm. for some reason I had it fixed in my head this was the debian import system whatsist on jubany. lalalalalala
<poolie> nup
<poolie> we're going to do that on the 1st of March
<poolie> happy to talk about how that will happen, but this other one is more pressing
<wgrant> Where's it moving to?
<poolie> we're moving machine from jubany to pepo
<poolie> and we're aiming to do all operations through remote losa arms at the same time
<wgrant> Excellent.
<poolie> rt 39614 if you're curious
<poolie> but the ticket's a bit of a saga
<spm> the good ones usually are
<lifeless> thumper: still around per chance ?
<lifeless> wgrant: I'd like to borrow your eyeballs
<lifeless> wgrant: can you look at the tip of lp:~lifeless/launchpad/showtimes and see if it makes sense to you
<lifeless> 12342
<wgrant> lifeless: The tip rev in particular, or all the changes?
<lifeless> tip rev
<lifeless> you can eyeball more if you want, but thats all reviewed yada yada yada
<lifeless> base-layout.pt is (sadly) used in error rendering.
<lifeless> so changes there tend to trigger nasty interactions with publication
<wgrant> lifeless: You elide the features and scopes because they are now being queried?
<lifeless> wgrant: if the request has expired, I return no rules
<wgrant> lifeless: Right, I see that.
<wgrant> But I'm wondering why you elide them now.
<wgrant> Because some show up with None?
<wgrant> It looks fine, just want to be sure.
<lifeless> oh, in the other tests
<lifeless> because the feature visible_render_times shows up now
<lifeless> and thats not very interesting to those tests
<lifeless> other features in future would also be uninteresting
<wgrant> Right.
<wgrant> Looks fine, then.
<lifeless> thanks for the yeeballs
<wgrant> lifeless: I was just going to ask you to do that review.
<wgrant> But you are too efficient :(
<lifeless> ok, render time on page -> ec2; me -> shops
<lifeless> stub: hi
<wgrant> lifeless: You fail at shopping.
<lifeless> wgrant: EWIFE
<wgrant> Or you are exceptionally good.
<lifeless> wgrant: I will be shopping soon
<wgrant> Ah.
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (350): FIXED in 5 hr 40 min: https://hudson.wedontsleep.org/job/db-devel/350/
<lifeless> woo
<lifeless> At least 110 queries/external actions issued in 8.12 seconds
<lifeless> for a search for kpassgen on qastaging /ubuntu
<wgrant> Excellent.
<lifeless> terrible cold cache effects still
<lifeless> we're going to need to do something about that eventually
<lifeless> wgrant: did bug 709717 make any practical difference ?
<_mup_> Bug #709717: Archive:+index timeouts : ArchiveView.num_pkgs_building can be very slow <lp-soyuz> <qa-ok> <timeout> <Launchpad itself:Fix Released by julian-edwards> < https://launchpad.net/bugs/709717 >
<stub> lifeless: yo
<wgrant> lifeless: Impossible to say without a new copy archive.
<lifeless> stub: flacoste has suggested you and I setup a weekly catchup voice call; do you have any sort of preference for when such a call would happen?
<stub> later in the week so I might actually remember what I've done, nearing end of your official work day probably best
<lifeless> thursday avo?
<stub> sure
<lifeless> I'll send a calendar thingy in a bit
<stub> I'm happy with a flexible time too
<stub> So 'thursday arvo' is fine.
<lifeless> ok; I'll send a calendar thing anyhow cause that will remind me; we can always fudge it on the day
<stub> One day I'll recover that password...
<lifeless> heh
<lifeless> #is can do that
<poolie> wgrant, pass/fail/don't know?
<wgrant> poolie: On what?
<poolie> the bzr rollout
<poolie> the fix for 71500
<poolie> 715000
<wgrant> It's in ec2. It may not be QA'd in time for the release, but if not we can nodowntime to loganberry later tomorrow.
<poolie> ok
<poolie> if/once it gets through ec2, will it automatically deploy, or will a losa just deploy it?
<wgrant> Once it's QA'd someone will request a deployment.
<wgrant> Given the timing I will probably not be awake in time to QA it, so it probably won't make the downtime rollout tomorrow.
<lifeless> matsubara-afk is doing deploy requests, wgrant does them, I do them... we all do them.
<poolie> sure
<wgrant> Hah, the last three have been me.
<poolie> i just wondered if/when i should try to test it or request deployment
<lifeless> by which I mean it won't hang around long
<wgrant> It should be on qastaging in 10 hours.
<wgrant> Then it needs somehow to push up an appropriate branch configuration, and a LOSA to run scan_branches.py
<wgrant> s/somehow/someone/
<wgrant> In the likely even that it's not QA'd before the release, I will QA it during the release and we can release again a couple of hours later :)
<wgrant> And then we can switch jubany back on and wait for more explosions, and then work out how to retry all the scan failures.
<wgrant> And the import failures.
<wgrant> And then resolve the next batch of wheezy-related fun.
<lifeless> http://searchengineland.com/google-proposes-to-make-ajax-crawlable-27408
<wgrant> lifeless: EAYEARAGO
<lifeless> I'm old school
<lifeless> wgrant: linked from http://isolani.co.uk/blog/javascript/BreakingTheWebWithHashBangs
<wgrant> Heh
<wgrant> Woah.
<wgrant> The universal Gawker redesign is, uh, special.
<lifeless> indeed
<wgrant> I see that the ui= curse continues.
<lifeless> weren't you fixenating?
<wgrant> I fixed the commit message thing last week, yes.
<poolie> do you know off hand a good branch that's nontrivially doubly stacked?
<wgrant> But I refer to the ui reviewer blight, which causes graduated UI reviewers to leave the LP team.
<wgrant> poolie: lp:ubuntu/lucid/bzr
<lifeless> wgrant: causes?
<wgrant> lifeless: Well, all our graduated UI reviewers except one or two have left the LP team.
<wgrant> And it just happened again, which is a little sad.
<lifeless> correlation != causation
<poolie> spm thanks for your mail on rt43743
<poolie> do you need anything else?
<wgrant> lifeless: I summise otherwise :P
<spm> I swaer I only pressed "reply" a couple of microseconds ago....
<spm> poolie: if we can get the configs formally landed that'd be a big plus.
<wgrant> Can I somehow tell doctest ellipsis to not cross linebreaks?
 * huwshimi heads off
<lifeless> wgrant: possibly with doctest flags
<LPCIBot> Project devel build (426): FAILURE in 6 hr 5 min: https://hudson.wedontsleep.org/job/devel/426/
<LPCIBot> * Launchpad Patch Queue Manager: [r=thumper, wallyworld][ui=none] [r=thumper, wallyworld][bug=661988,
<LPCIBot> 714312] Reduce the time taken for distro scope bug searches by 50% by
<LPCIBot> using sequence-of-sets based eager loading rather than
<LPCIBot> wide-query eager loading. As part of making this fit cleanly
<LPCIBot> stop loading assignees during bug task search (they are not
<LPCIBot> rendered so not needed).
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][bug=713392] make the +structural-subscriptions UI correctly
<LPCIBot> show the effect of an event filter setting.
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][no-qa] Use itertools.tee() to simplify and speed up
<LPCIBot> CachingIterator.
<LPCIBot> * Launchpad Patch Queue Manager: [r=jcsackett, sinzui][ui=none][bug=344125,
<LPCIBot> 712012] Remove obsolete method Bug.addChangeNotification().
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][no-qa] test, tweak, and exercise the dbuser test helper
<lifeless> wgrant: btw, FYI - lp:~lifeless/launchpad/bug-704446 - has the reindex fix
<adeuring> good morning
<jtv1> hi adeuring
* jtv1 changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: jtv | https://code.launchpad.net/launchpad-project/+activereviews
<adeuring> hi jtv!
<jtv> hi lifeless!
<jtv> lifeless: you recommended getting a ++profile++ on qastaging, but the docs still suggest that that's impossible.  Need updating?  https://dev.launchpad.net/Debugging
<lifeless> jtv: requires losa intervention to turn it on (and then off)
<jtv> lifeless: both staging and qastaging?  (Asking so I can update the wiki)
<lifeless> yes; if you want a reference, see some of my early performance tuesday mails
<jtv> Thanks.
<mrevell> Hello all.
<Ursinha> good morning, launchpad
<allenap> jtv: Good morning. Ready for a review? https://code.launchpad.net/~allenap/launchpad/use-zope-tb-formatter/+merge/48843 :)
<jtv> hi allenap!
<jtv> allenap: we do have the call first.  :)
<allenap> jtv: Yeah, you've got 8 minutes! ;)
<jtv> uh-oh
<bigjools> bloody full-stop nazis
<wgrant> bigjools: Hey, this isn't in a comment!
<bigjools> it's also only a warning banner!
<wgrant> And bad punctuation in the UI looks shit.
<wgrant> We should try to avoid it :)
<bigjools> no, you don't always need to use them
<wgrant> All notifications I've seen do. And this one has paragraphs after it, so it's even more convincing.
<bigjools> phrases don't need them
<bigjools> check the code again
<lifeless> night all
<bigjools> nn lifeless
<wgrant> Night lifeless.
<wgrant> bigjools: Ah. So it will occasionally be "Publishing has been disabled for this archive Note: since this archive is private, no builds will be dispatched." (no linebreak, since addNotification wants HTML)
<bigjools> le sigh
<wgrant> HTML is fun :D
<bigjools> fsvo
<bigjools> when using ec2 land it's extremely disconcerting for it to pop up a gnome-keyring password dialog when I don't use gnome-keyring
<wgrant> fd.o really should standardise keyrings.
<bigjools> yes
<bigjools> we can just use kwallet
<bigjools> ARGH, why does ec2 land amend the commit message on lp, when lp-land doesn't ....
<jtv> allenap: in test_logger.py, is the boilerplate at the end of the test still really needed?
 * allenap looks
<jtv> The test_suite() stuff
<allenap> jtv: I think so, for the doctest.
<jtv> ahh
<jtv> nm then
<jtv> allenap: isn't [0, 1, 2, 3, 4] more easily written as range(5)?
<jtv> (Serves you right for fixing all that lint :)
<jtv> allenap: also, from the diff:
<jtv> 213+        # The local variable __traceback_info__ is set by `traceback_info`.
<jtv> Easier to avoid passive voice I think.
<allenap> jtv: otp, back soon.
<allenap> jtv: Regarding range(5). Yeah, it's a bit shorter, but it's slightly less readable, in my mind anyway, and range() returns an iterator in Python 3.
<jtv> Fair enough.  Anyway, I had voted already.  :)
<allenap> jtv: Thank you :)
<allenap> jtv: Fancy another?
<jtv> Oh yes, please, make me work!
<jtv> :)
<allenap> jtv: https://code.launchpad.net/~allenap/launchpad/cw-bugzilla-sniffing-expat-errors/+merge/48985
<allenap> :)
<jtv> allenap: nice grammarâ¦ "because they require that none be in progress."
<jtv> Does TestBugzillaSniffing really need DatabaseFunctionalLayer though?
<allenap> jtv: I tried it with no layer and it got grumpy. Perhaps there is a lighter layer I could use, but I'm not good at knowing which one. I tend to try them haphazardly until the test works and isn't too slow.
<jtv> allenap: sounds about rightâ¦ I was thinking maybe the ZopelessLayer or something?
<allenap> jtv: I'll give that a go.
<jtv> thanks
<jtv> allenap: also, I'm no expert at python method binding butâ¦
<jtv> 280+            response.geturl = lambda: req.get_full_url()
<jtv> â¦looks sort of equivalent to
<jtv>         response.geturl = req.get_full_url
<allenap> jtv: Ah yes, I noticed that and meant to change it. Will do.
<jtv> Excuses, excuses.
<jtv> allenap: meanwhile, you have my vote.
<allenap> jtv: Thanks :)
<allenap> jtv: ZopelessLayer works a treat, thank you.
<jtv> Great!
<jtv> Anbd for that, I award myself a cup of coffee.
<jtv-afk> Damn, can't use â in a nick.
<adeuring> henninge: do you have to talk about but 702468?
<jtv> adeuring: are you asking him whether he has _time_ to talk about bug 702468?  Or asking him to stop talking about it?  :-)
<_mup_> Bug #702468: First upstream translation does not replace Ubuntu-only translation <upstream-translations-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/702468 >
<adeuring> jtv: yeah, that's what I meant ;)
<adeuring> but I think I'll start my lunch break first.
<deryck> Morning, all.
<jtv> hi deryck
<henninge> adeuring: Hi. Sorry for replying so slowly.
<adeuring> henninge: mo problem,. I think I answered my question myself meanwhile ;)
<henninge> adeuring: oh, cool ;-)
<henninge> adeuring: how/where are you going to fix it?
<henninge> adeuring: Are you touching POTMsgSet.setCurrentTranslation?
<henninge> i.e. _setTranslation
<adeuring> henninge: right.
<adeuring> this bug is just a special case for the '*' option.
<henninge> sounds like the right place.
<henninge> oh cool, you got into the matrix ... ;)
<henninge> jtv: Hi!
<henninge> jtv: Did you know that your description of the decision matrix in the comment in _setTranslation is truncated?
<henninge> I always thought I should try and figure out what is missing there exactly.
<henninge> adeuring: Did you notice that?
<adeuring> no...
<bac> hi bigjools, can you and i have a 10 minute mumble so i can ask you questions about bug mail subscriptions?  you are rumored to have some strong opinions (shock).
<bigjools> bac: scurrilous rumours!  Sure thing.
<bac> bigjools: nowish?
<bigjools> I'm in yer mumble room
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (427): FIXED in 6 hr 6 min: https://hudson.wedontsleep.org/job/devel/427/
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][bug=714527] Properly escape labels in suggestion widgets.
<LPCIBot> * Launchpad Patch Queue Manager: [r=gmb][ui=none][bug=50616] Catch the ValueError while validating
<LPCIBot> image file.
<jtv> henninge: back from lunchâ¦ no, I did not realize that or I would have fixed it!
<abentley> jtv, aren't you EOD?
<jtv> abentley: different tz
<abentley> jtv, Ah, cool.
* abentley changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: jtv, abentley | https://code.launchpad.net/launchpad-project/+activereviews
<jtv> henninge: far as I can make out, I never completed that comment!
<henninge> oic
<leonardr> jcsackett, i'm very confused by the problem about which you sent me email
<leonardr> can you tell me what http requests are being sent out?
<jcsackett> leonardr: hurray, i can actually use IRC today. one second.
<jcsackett> leonardr: https://pastebin.canonical.com/43026/, but that's not showing responses, i believe i set the wrong debuglevel.
<leonardr> jcsackett: so it follows the redirect, and then the thing at the other end of the redirect is weird?
<bigjools> what's the right place to file a bug on our landing tools? (ec2 land and bzr lp-land)
<leonardr> ah, i see the problem. the redirect is not a redirect to the web service
<leonardr> it's a website redirect
<jcsackett> leonardr: right, it's a redirect from the alias for the product to the actual product.
<leonardr> but the redirect switches layers
<leonardr> it should send you to api.launchpad.net/1.0/gdp and it sents you to launchpad.net/gdp
<jcsackett> ah,yes. okay.
<leonardr> i'm not sure how that results in an oops--that looks like a different problem
<jcsackett> well, the OOPS that occurs is when you then try to file a bug after that redirect.
<jcsackett> and lazr/launchpadlib says "i have no idea what you want me to do here."
<leonardr> jcsackett: but the first redirect caused an exception. what are you filing a bug on?
<jcsackett> i'm not filing a bug, i'm looking at bug 623099
<_mup_> Bug #623099: AttributeError filing a bug using the API <lp-foundations> <oops> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/623099 >
<jcsackett> oh, you mean via the api.
 * jcsackett has not had enough coffee yet.
<leonardr> yeah
<leonardr> here's what i think is happening
<leonardr> you assign lp.projects['geditdevplugins'] to a variable and then try to file a bug on it
<bigjools> allenap: did you want another call about the "fail a build" button?
<leonardr> there's an exception when launchpadlib tries to resolve the reference, but you catch it or ignore it somehow
<leonardr> then you file a bug on the variable
<leonardr> so you POST to /1.0/geditdevplugins, or you post to /bugs and reference /1.0/geditdevplugins
<leonardr> and when lazr.restful tries to resolve /1.0/geditdevplugins *internally*, you get the oops
<jcsackett> leonardr: that makes sense and jives with my thinking.
<jcsackett> incidentally, if you just execute "var = lp.projects[alias]" and then don't try to use the alias, nothing happens, exception wise; which might explain the issue with no exception in grabbing the product.
<leonardr> jcsackett: yes, you get a shim object
 * jcsackett nods.
<leonardr> and if you try to use the object on the client side, you get an exception on the client side
<leonardr> but you're sending it off to the server side
<leonardr> so, we need to force the resolution to happen on the client side, so we send the right url
<leonardr> or we need to make the server side capable of understanding the redirect
<leonardr> and then there's this *other* problem where /1.0/geditdevplugins redirects you outside the web service
<jcsackett> leonardr: dig. and that needs to be fixed server side.
<leonardr> yeah, in launchpad
<leonardr> i'll summarize in the bug
<jcsackett> leonardr: thanks. i'm glad to know i'm dealing with two bugs--i was starting to be slightly confused.
<leonardr> jcsackett, bug updated
<jcsackett> leonardr: dig. and thanks again.
<allenap> bigjools: I'm going to spend a few minutes looking at the code, but I'd love to talk after that.
<dobey> so i just got an e-mail from LP with an OOPS id in it
<dobey> OOPS-1866MPJ3
<dobey> i guess LP doesn't like making a merge proposal against a branch which has 0 revisions :)
<bigjools> allenap: ping when when you're ready then
<leonardr> i have a stupid question: how can i get my launchpad install to use the non-compressed javascript? i thought it used to do that by default in dev mode, but not anymore?
<jml> leonardr: I recall Tim asking something similar on the mailing list.
<jml> leonardr: https://lists.launchpad.net/launchpad-dev/msg06358.html -- not that helpful, but it's there.
<leonardr> thanks, i remember that message from tim but not any followup
<jml> deryck followed up, but it was more along the lines of "here's what we could do to make this better", rather than "Oh, you forgot to flick the 'make it work' switch"
<deryck> there is no switch
<deryck> jml, leonardr, a not nice but possible solution is find and replace "-min.js" with ".js" in utilities/yui-deps.py or utiltities/lp-deps.py and run make jsbuild again.
<deryck> I've trimmed the ginormous load of js files in my recent yui upgrade to make enabling a devmode flag a possibility again.
<lifeless> deryck: please no
<jcsackett> leonardr: so, in testing, there's no way to get a product via alias. you just get a key error. thoughts?
<deryck> lifeless, why not?
<jcsackett> this is using launchpadlib_for from lp.testing
<lifeless> deryck: or rather, if you do, let me know so I reopen the bugs I had with devmode
<lifeless> deryck: with devmode, js wouldn't work for me locally
<deryck> lifeless, ah, ok.  interesting.
<lifeless> deryck: and all the fragments got redownloaded on every page
<leonardr> jcsackett: what code are you running? i can't visualize
<Ursinha> allenap, hi, is bug 714820 In Progress/Fix Committed?
<_mup_> Bug #714820: Many ExpatErrors from checkwatches <oops> <Launchpad itself:Triaged by allenap> < https://launchpad.net/bugs/714820 >
<deryck> lifeless, ok.  And I'm not saying we have to do it this way either.  but we need something in devmode to use non-minified files at least.
<deryck> just that with 45 instead of 450 files, it's a bit better to do again ;)
<lifeless> can I suggest that such a mode be opt-in
<lifeless> that by default we want to be as close to prod as possible
<deryck> yes, definitely agree there.
<deryck> the current js build is cleaner anyway, since it's not sniffing templates for files, too.
<jcsackett> leonardr: https://pastebin.canonical.com/43051/
<allenap> Ursinha: I think it's committed.
<allenap> Ursinha: Nope, it's not... just a moment.
<Ursinha> sure
<allenap> Ursinha: Ah, the branch is at the end of the PQM queue.
<Ursinha> cool, so it's at least In Progress :)
<allenap> Ursinha: Ah yes :) Oops. Thanks
<Ursinha> allenap, no problem :) I'm asking because if that wasn't in progress I'd mention it in the TLs meeting
<Ursinha> thanks!
<leonardr> jtv or abentley, can i get you to review a little javascript? https://code.launchpad.net/~leonardr/launchpad/use-web-link/+merge/48991
<jtv> leonardr: sure
* jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: abentley | https://code.launchpad.net/launchpad-project/+activereviews
<jtv> (Last one for the day)
<sinzui> jcsackett: Do you have time to discuss a bug I am working after 1:00 PM?
<jcsackett> sinzui: sure.
<jcsackett> say, 1:15?
<sinzui> okay
<jtv> leonardr: I suppose there's no legitimate scenario where web_link is not present?
<leonardr> jtv: i'm pretty sure not, since the whole point of this thing is that you are at a web page corresponding to some object
<leonardr> and that's the scenario under which web_link will be present--if there's some web page corresponding to this object
<leonardr> but if it should happen, i put in code to do nothing instead of crash
<Ursinha> https://bugs.launchpad.net/loggerhead/+bug/701329
<_mup_> Bug #701329: loggerhead OOPS - error: [Errno 32] Broken pipe <oops> <Launchpad itself:Triaged> <loggerhead:Invalid> < https://launchpad.net/bugs/701329 >
<jtv> Ursinha: I looked at that one, and ISTM it's really two bugs in one: dealing better with socket breakage is one, but another is stopping after a HEAD request.  I wonder if sitting around trying to send a body would tie up a connection.
<sinzui> jcsackett: Here is the background on the issue: http://pastebin.ubuntu.com/565072/
<jcsackett> sinzui: dig.
<jcsackett> leonardr: have you had a chance to look at the paste i sent you?
<leonardr> jcsackett: sorry, looking now
<jcsackett> leonardr: no worries. :-)
<jtv> leonardr: done
<Ursinha> jtv, as you have deeper knowledge than I do, could you add a comment in that bug mentioning that, please? :)
<jtv> Ursinha: me and my big mouth âº Will do.
<Ursinha> hahahaha
<Ursinha> thanks!
<leonardr> jcsackett: 1. set httplib2.debuglevel = 1 and see what requests, if any, are being sent
<leonardr> 2. does lp.projects['lemur'] work?
<jcsackett> lp.projects['lemur'] does work.
<jcsackett> debuglevel gets me nothing, just the keyerror.
<jcsackett> leonardr, i seem to recall once being told that launchpadlib did some tricks in testing mode rather than always making requests. think this might be running up against that?
 * jcsackett is considering just using WebServiceCaller.
<leonardr> jcsackett: uh, it may not be going through httplib2, that's true
<leonardr> it may be using a webservicecaller or something behind the scenes
<jcsackett> leonardr: okay. since for purposes of this issue it's all about the server sending the correct 301, and less about lplib behavior, i guess i can use the caller and check the repsonses instead of the lplib returned objects.
<leonardr> jcsackett: that might be easier
<jcsackett> leonardr: okay, thanks.
<jcsackett> sooner or later i will have asked you so many questions i might actually know how this all works. yay domain knowledge transfers. :-P
<lifeless> flacoste: hi
<flacoste> hi lifeless
<lifeless> flacoste: got time for a brief call on capacity ?
<flacoste> (was about to go for lunch)
<flacoste> lifeless: i read the update to the ticket
<flacoste> lifeless: but we could catch-up later
<lifeless> which ticket ?
<lifeless> after lunch should be fine; have to take lynne into hospital 4 hours from now
<flacoste> lifeless: ok
<bigjools> allenap: you have some interesting test data in your tests :)
<lifeless> https://qastaging.launchpad.net/ubuntu - 145 queries!
<jcsackett> sinzui: i can mumble now, if you like.
<sinzui> jcsackett: I will get a drink
<jcsackett> sinzui: gid.
<jcsackett> er, dig.
<Ronnie> is there a short way to get all the admins (which are not teams) of a lp_team recursively. Currently i created http://paste.ubuntu.com/565096/ but it takes a lot of launchpadlib calls
<lifeless> get_team_members_r is replacable by the participation call
<Ronnie> is participants fully recursive?
<lifeless> IIRC yes
<lifeless> what do you need to figure the administrators out for though ?
<lifeless> as in, whats the use case
<Ronnie> in the loco-directory to give the people the rights they need
<lifeless> so wouldn't a query 'is foo an admin of bar
<lifeless> '
<lifeless> be a better thing to have?
<leonardr> thumper, i filed bug 715990 because i don't think the other web_link hack is worth removing right now
<_mup_> Bug #715990: Remove self_link -> web_link hack in bugtask_index.js <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/715990 >
<Ronnie> lifeless: its an regular update script, so we do not have to retrieve info from LP on user page load
<lifeless> Ronnie: we should be able to answer a question like that in ~ 40ms
<lifeless> Ronnie: so doable on page load if you wanted.
<lifeless> I -very much- want to get away from 'nightly updates' - its horribly inefficient
<Ronnie> ah, that explains the question ...
<Ronnie> lifeless: the thing is, that on most pages, we need info from multiple teams, so that should take too much time i guess
<lifeless> well
<lifeless> we could answer for multiple teams, if you can clearly describe the check that is needed
<Ronnie> lifeless: on each page different :(
<lifeless> Ronnie: thats fine, its how we figure things out
<lifeless> we don't have to do this now
<lifeless> its a long term transition; we need an event system, we need targeted APIs, we need launchpadlib to be concurrency-safe
<Ronnie> an event system could indeed be better
<Ronnie> or "show changes of teams since"
<Ronnie> lifeless: is latter an good idea ^ to brainstorm further?
<lifeless> that might be a useful api as well
<Ronnie> i think its easier to implement than events (which are realtime)
<lifeless> we do have a teammembership datestamp
<flacoste> lifeless: skype me when you want to chat capacity
<thumper> leonardr: ok
<thumper> deryck: I'd like to talk to you about how we do lazr-js releases into LP
<deryck> thumper, ok.  I really want to get this current update up for review first.
<deryck> thumper, Can we IRC chat it, or wait until I'm done for voice?
<deryck> FWIW, I've quit worry about incrementing the version in lazr-js and just rolling a new tarball from trunk, with a revno string.
<deryck> if that makes things faster for you.
<thumper> deryck: is there a make target for that?
<deryck> thumper, for building a tarball from lazr-js trunk?
<thumper> yeah, to make sure we get all we need and nothing we don't
<deryck> thumper, no, I just do `python setup.py egg_info -b-r202 sdist` to get a new tarball and copy to download-cache
<deryck> where -r202 represents the current revno.
<thumper> is that documented anywhere in the lazr-js docs?
<deryck> thumper, no, I learned this from doc/buildout.txt in the launchpad source.
<deryck> but it's really secret knowledge BjornT_ passed on to me, I think. ;)
<Ursinha> lifeless, hey, do you know if bug 702819 was released in a nodowntime rollout? I still see oopses
<_mup_> Bug #702819: Log parser should skip lines raising InvalidURIError <lp-soyuz> <oops> <qa-ok> <Launchpad itself:Fix Released by wgrant> < https://launchpad.net/bugs/702819 >
<lifeless> no, it needs downtime
<Ursinha> lifeless, so why is that marked as Fix Released?
<lifeless> Ursinha: it may be a new bug
<thumper> deryck: how has the lazr-js updating going?
<lifeless> flacoste: https://lpstats.canonical.com/graphs/GandwanaCPU/
<deryck> thumper, proposing for merge now.
<Ursinha> I'll ask wgrant later, thanks
<thumper> deryck: cool
<thumper> deryck: if you have a few minutes, I'd like to chat about my upcoming changes for lazr-js
<lifeless> flacoste: https://lpstats.canonical.com/graphs/PotassiumCPU/
<deryck> thumper, sure.  When I'm done with this.
<lifeless> https://lpstats.canonical.com/graphs/PalladiumCPU/
<deryck> hmmm, who wants to review a largish lazr-js upgrade? :-)
<deryck> flacoste, could you spare the time maybe? ^^
<flacoste> deryck: i could
<deryck> flacoste, thanks!  https://code.launchpad.net/~deryck/launchpad/update-lazr-js-yui-3-3/+merge/49122
<deryck> thumper, voice or irc?
<thumper> deryck: voice would be better
<thumper> mumble?
<deryck> sure
<LPCIBot> Project devel build (428): FAILURE in 6 hr 9 min: https://hudson.wedontsleep.org/job/devel/428/
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=715000] Upgrade to a bzr with a fix for the graph
<LPCIBot> ancestry chained stacking issue.
<LPCIBot> * Launchpad Patch Queue Manager: [r=sinzui][bug=715474] Permit showing server side render times in the
<LPCIBot> visible page (controlled by feature flag visible_render_time).
<maxb> I was thinking I'd try to learn some YUI. deryck's branch makes me think you don't learn YUI, you learn a particular minor version of YUI :-/
<deryck> maxb, well dot releases in YUI are major upgrades.  Learn the current YUI. It has value on its own, and now we're current, too. ;)
<thumper> maxb: YUI is worth learning I think
<maxb> I'm somewhat convinced of that. Just looking for a good place to start _understanding_ more than the surface
<mwhudson_> given that yui 2 and 3 are basically separate project, i guess the yui3 team have to have 3.x ->3.x+1 be major
<deryck> maxb, the YUI 3 site has excellent docs.  I'd focus on the stuff under "Component Infrastructure"
<lifeless> Ursinha: hi, sorry about fading away
<deryck> maxb, then read "JavaScript, the good parts" and learn to think like Crockford.  YUI all makes perfect sense then. :-)
<lifeless> Ursinha: I would file a new bug, and wgrant can eyeball  and see if its a previously hidden issue or a duple and the other hadn't been rolled out.
<maxb> hmm. I think *finding* the bits of the YUI site you want to read is half the battle :-) I've read "JavaScript, the good parts" once, I should go back over it carefully.
<deryck> maxb, yeah, that's why I suggested the stuff under the component infrastructure heading on the yui 3 homepage. :-)
<maxb> ahhh.... you appear to have given me the magic words leading to the right place to start! thanks :-)
<deryck> heh, np!
<lifeless> deryck: hi
<lifeless> deryck: I've replied to your nodowntime db mail, but if you want to talk more today it should be soon
<deryck> lifeless, ok, saw it.  Thanks.  If it's not possible, it's not possible.  I don't think we need much beyond that for now.
 * thumper runs to make a coffee before the standup
<flacoste> deryck: how did you get the list of deps?
<deryck> flacoste, I used the configuration tool on YUI 3's website.
<flacoste> deryck: ack
<flacoste> deryck: i think your change of root initialization in combine-css is broken
<flacoste> deryck: it assumes the script is run for the root directory
<flacoste> deryck: what's the problem with the buildout var?
<deryck> flacoste, it would add a "./" in the middle of the path
<flacoste> deryck: and i think a lazr-js change broke this, btw
<flacoste> deryck: normpath would remove it
<flacoste> deryck: probable that lazr-js / should call this
<flacoste> deryck: but changing calling normpath around the buildout var would also work
<flacoste> if you don't want to dig deeper
<wallyworld_> thumper: stupid mic again
<flacoste> which i would totally understand
<deryck> I'll use normpath then, if you really don't care :-)
<thumper> leonardr: mumble?
<leonardr> thumper, yes
<flacoste> deryck: r=me with that
<deryck> flacoste, excellent, thanks!
<flacoste> deryck: and great job trimming the dep list
<deryck> thanks!  I was pretty happy about that, too.
<deryck> And she's off to ec2.  Until tomorrow then!  Later, all!
<huwshimi> Morning
<benji> leonardr: are you aware of any docs about how to use LP.client.Launchpad() to interact with the web service from JavaScript?
<leonardr> benji: no, i'm not, but it's been a looong time
<benji> :) ok, thanks
<wgrant> Ursinha-bbl: It was mistakenly closed. It will not be deployed for another couple of hours.
<wgrant> gary_poster: Hi.
<LPCIBot> Project db-devel build (353): FAILURE in 5 hr 23 min: https://hudson.wedontsleep.org/job/db-devel/353/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12347
<LPCIBot> included.
<wgrant> sinzui, huwshimi: The large icons are not there any more.
<wgrant> Will have to check history.
<wgrant> Yay, nightly.sh now finishes in time.
<wgrant> And logs properly.
<wgrant> And there were no scriptactivity errors overnight!
<poolie> jam: bug 716169 re the multiple mps
<_mup_> Bug #716169: does not send mail on superseded proposals <code-review> <confusing-ui> <mail> <Launchpad itself:Triaged> < https://launchpad.net/bugs/716169 >
<poolie> wallyworld_, there's no blog post about lp going offline? should there be?
* mbarnett changed the topic of #launchpad-dev to: Launchpad down/read-only from 23:00 - 00:30 UTC for a code update || https://dev.launchpad.net/ | firefighting: - | On call reviewer: abentley | https://code.launchpad.net/launchpad-project/+activereviews
<jam> poolie: ?
<poolie> re your question of "which of these should i review"
<poolie> i think all but one was superseded
<jam> ah, ok
<poolie> but lp does not mail you to tell you
<wallyworld_> poolie: i guess so. i posted to identi.ca. i'm not sure about the blog though
<poolie> is there a policy?
 * wallyworld_ checks but ssems to recall it only mentions identi.ca
<poolie> we seem to have done so in the past
<wallyworld_> poolie: wiki says "Re-announce downtime so it serves as a reminder on launchpadstatus account at least 4h before the actual rollout. You can do this yourself with the identi.ca login info. "
<wallyworld_> no mention of a blog
<wallyworld_> poolie: do you have details of the blog site - i've never been there.
<poolie> ok, i posted
<wallyworld_> poolie: thanks for that. url?
<poolie> see pm
<poolie> but, blog.launchpad.net would be a good guess :)
<poolie> i posted
<poolie> ah, i see mrevell did on http://blog.launchpad.net/notifications/launchpad-read-only-23-00-utc-9th-february-2011
<jam> poolie: how often does the kanban board update? It would be a bit more satisfying if closing a bug actually cleared off the board, etc.
<wallyworld_> poolie: thanks
<poolie> jam, at the moment, from my laptop, ~once per day
<poolie> i agree doing it faster or indeed live would be better
<poolie> i need to ask for the dependencies to be on devpad or similar
<jam> poolie: k. There is a certain amount of needing a queue to go to 0 when you do stuff, so you don't spin thinking you need to fix something that is fixed
<poolie> agree
<jam> more than just 'feels good' satisfaciton
<jam> satisfaction
<poolie> once it's there i could probably run it every half hour or so
<poolie> absolutely
<poolie> i would like to also make it read things a bit faster
<wgrant> gary_poster: If you are around again this evening, could you give me any advice on QAing your two pending items? They're blocking a bzr upgrade that is needed ASAP.
<poolie> though moving it to the dc would also help with that
<poolie> beyond that, we probably need feeds or push notification
<jam> poolie: yeah. It is a nice reminder of things for me to push on. I tried to push on everything that was past the first column
<poolie> i was going to see if people liked it first
<poolie> graphs would be good too
<jam> poolie: having it easier to get the one just for me would also be useful. Probably because jelmer does too much, so I get lost in the mix :)
<poolie> you know there is one just for you?
<poolie> you can bookmark it
<poolie> direct navigation wbn
<jam> yeah, but it isn't the site that gets linked by you repeatedly :)
<poolie> up one level and across
<poolie> but i see what you meaon
<poolie> i wonder if it will work while lp is readonly?
<poolie> no apparently not
<poolie> seems like a bug
<jam> poolie: "up one level" I don't see any links, but I can url hack
<jam> but I can just s/bzr/jameinel/ if I'm going to do that
<poolie> https://devpad.canonical.com/~mbp/kanban/jameinel-kanban.html
<poolie> perhaps it would be better to have ajax filters
<jkakar> poolie, jam: Hi! :)
<jkakar> Out of curiousity, are the warning/danger icons useful to you?
<poolie> mm
<poolie> they're a bit of a reminder we have too much inventory, which is good
<poolie> they are maybe a bit alarming
<jkakar> poolie: Heh, that's their job. :)
<poolie> thanks for fixing the bugs i filed!
<poolie> i'm just filing one against lp that it fails api requests while readonly
<jkakar> poolie: Anyway, I plan to make the setting configurable.  Perhaps the current defaults are not quite right for Bazaar.
<jkakar> poolie: My pleasure!  And thanks, I was just popping in here because of those failures.
<poolie> oh, the api calls failing?
<poolie> i'll subscribe you when i get the bug number back
<jkakar> poolie: Yes, the API calls.  I'll appreciate the subscribe, thanks.
<jkakar> poolie: Specifically this kind of failure: http://paste.ubuntu.com/565213/
<jkakar> poolie: Okay, it's bedtime here.  Have a good one. :)
<poolie> that's what i get too
<poolie> sleep well
#launchpad-dev 2011-02-10
<mwhudson> ugh, i'm sure apis are supposed to work in read-only mode...
<wgrant> mwhudson: I'm seeing distribution['ubuntu'] failing.
<wgrant> I never have before.
<wgrant> Are you seeing something similar?
<james_w> 503s?
<wgrant> Yeah.
<james_w> I've definitely seen them before
<wgrant> For some things, sure.
<james_w> I've not tried to correlate it to anything
<wgrant> But never this.
<wgrant> Ugh.
<mwhudson> wee!
<wgrant> c.l.d.oauth tries to use the master store.
<mwhudson> i wonder what's happening
<wgrant> But that hasn't changed lately.
<mwhudson> the response is being generated by launchpad, it seems?
* mbarnett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: abentley | https://code.launchpad.net/launchpad-project/+activereviews
<mwhudson> so there should be oopses
<mwhudson> maybe?
<wgrant> mwhudson: Unlikely.
<wgrant> That probably won't generate an OOPS.
<wgrant> But I can see the issue locally.
<mwhudson> ah ok
<wgrant> http://paste.ubuntu.com/565226/
<wgrant> That's with login_anonymously
<gary_poster> wgrant: looking
<wgrant> gary_poster: Thanks. Although it's less critical now, since the rollout failed so we'll probably have to cowboy.
<gary_poster> wgrant, ah :-/
<gary_poster> wgrant, qa instructions already exist for the first: last para of description of https://code.launchpad.net/~gary/launchpad/bug548/+merge/48850
<gary_poster> looking at the other one...
<gary_poster> I also did the same for the other one, wgrant (https://code.launchpad.net/~gary/launchpad/bug713392/+merge/48939)
<wgrant> gary_poster: Ah, sorry. Just about nobody does, so I stopped checking there a while ago.
<gary_poster> wgrant, np, understood :-) .  I'm not consistent either, but I try to do that
<thumper> so...
<thumper> what's the status with writing new windmill tests?
<thumper> we are supposed to?
<poolie> spm, i sent bug mail to lp during the rollout and it does not yet seem to have any effect....
<poolie> nm, they have come through
 * thumper nipping out to what the girls' first touch game of the season
<LPCIBot> Project devel build (429): STILL FAILING in 6 hr 6 min: https://hudson.wedontsleep.org/job/devel/429/
<LPCIBot> * Launchpad Patch Queue Manager: [r=jtv][bug=714820] Ignore malformed responses when probing remote
<LPCIBot> Bugzilla instances for XML-RPC capabilities.
<LPCIBot> * Launchpad Patch Queue Manager: [r=adeuring][bug=181368] Gut BinaryPackageFilePublishing view.
<LPCIBot> * Launchpad Patch Queue Manager: [r=jtv][bug=715659] Use zope.exceptions to format logged exceptions
<LPCIBot> so that __traceback_info__ is reported.
<LPCIBot> * Launchpad Patch Queue Manager: [r=leonardr][bug=715116] Add a big informational notice on the PPA
<LPCIBot> pages if publishing is disabled.
<LPCIBot> * Launchpad Patch Queue Manager: [r=lifeless][bug=713234] Remove duplicated queries issued when
<LPCIBot> calling ArchiveView.latest_updates
<lifeless> https://code.launchpad.net/~lifeless/launchpad/bug-704446/+merge/49167
<poolie> hi lifeless
<lifeless> hi poolie
<poolie> do you have any idea whether https://bugs.launchpad.net/launchpad/+bug/716175 would be shallow?
<_mup_> Bug #716175: api calls fail while launchpad is readonly <Launchpad itself:Triaged> < https://launchpad.net/bugs/716175 >
<lifeless> poolie: I suspect its not, but without an oops can't really confirm (could simulate locally I guess)
<lifeless> poolie: but I'm not hugely interested in fixing readonly mode, I don't think its a particularly good use of engineering time
<lifeless> poolie: I'm going to reply to jam about loggerhead and try and clear up the confusion
<lifeless> poolie: however I have a few fires to deal with first today.
<lifeless> huwshimi: ping
<huwshimi> lifeless: Hey
<lifeless> huwshimi: contrast this
<lifeless> http://bazaar.launchpad.net/~jameinel/loggerhead/merge_pqm_updates/files
<lifeless> and
<lifeless> http://bazaar.launchpad.net/~jameinel/loggerhead/merge_pqm_updates/changes
<lifeless> note the former has a 'help' tab
<lifeless> its in the lp loggerhead branch only
<lifeless> I think it was added during the drive to have 'help everywhere' in LP
<lifeless> but if you click on it
<lifeless> it takes you to a sad panda wiki page
<lifeless> I'm seeking a second opinion on just discarding that noddy tab
<wgrant> lifeless: It's easy to replicate locally.
<wgrant> I pastebinned the traceback earlier.
<wgrant> I don't see how it could have ever worked, but it apparently did.d
<lifeless> wgrant: I was not connected to irc :)
<wgrant> Right.
<lifeless> wgrant: feel free to annotate the bug ;)
<poolie> lifeless, yeah, much better to just never go into  readonly mode
<poolie> hearty +1 from me to removing the help tab
<huwshimi> lifeless: Help that is not helpful is useless. It appears to me that that help is not really helpful. You could either remove the tab or provide some useful help.
<poolie> those little 'help' drawers were such an awful idea
<poolie> lifeless, in that case i might bump 716175 down to low
<lifeless> poolie: I have done so
<huwshimi> Useless help just results in what I like to call "help page rage".
<huwshimi> I once worked on a massive application where all the help documentation for every form field was "This is the Foo field". The documentation guy didn't understand why this was a bad thing.
<poolie> huwshimi, that's what we had
<poolie> i cannot think of a better way to train people to never click on things labelled Help
<huwshimi> poolie: Ouch.
<poolie> if we'd kept the same mechanism but only used it when we had something important to say, it would have been half decent
<poolie> but better to just put it inline if it's really important and you can't think of a way to make it obvious
<huwshimi> If there is a bug that has been fixed by another bug do I change it to "Fix released"?
<poolie> yes, or mark it as dupe, or as invalid
<poolie> whatever you think best expresses the situation or is easiest
<huwshimi> poolie: Cheers
<lifeless> abentley: are you still OCR?
<thumper> lifeless: somewhat late for abentley don't you think?
* thumper changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: -  | https://code.launchpad.net/launchpad-project/+activereviews
<lifeless> yes :)
 * thumper still feels strangely protective
<poolie> :)
<huwshimi> Does anyone know what research might be alluded to in this comment? https://bugs.launchpad.net/launchpad/+bug/490058/comments/7
<_mup_> Bug #490058: Launchpad shouldn't present itself as a database <lp-web> <Launchpad itself:Triaged> < https://launchpad.net/bugs/490058 >
<poolie> she has done some user testing sessions
<poolie> mm
<poolie> i don't think the title of that bug is very accurate
<poolie> it should be something more like "Launchpad home page should show cool stuff that's happening"
<poolie> "not presented as a database" would be more like getting away from table-type views
<huwshimi> poolie: Hmm.. I should try and get her findings
<poolie> she'd be a good person for you to know
<wgrant> There were a couple of surveys last year too.
<wgrant> I never saw anything from them; were they even distributed internally?
<poolie> mrevell posted something, but not very prominently
<poolie> mm
<spm> fyi. am doing the stabby dance on the builtbot master to remove the living dead problem it's caused.
<poolie> it's kind of connected to the timeline view concept
<thumper> w00t: Committed revision 12345.
<thumper> nice number
<LPCIBot> Project db-devel build (354): STILL FAILING in 5 hr 20 min: https://hudson.wedontsleep.org/job/db-devel/354/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12348
<LPCIBot> included.
<huwshimi> Ugh, what am I doing wrong. I updated download-cache and did an update of devel and merged it into my branch and now getting this error: http://paste.ubuntu.com/565245/ . I know there was an update to YUI that removed a whole bunch of files. Is it possible there's something else I need to update?
<thumper> huwshimi: try a "make clean build"
<huwshimi> thumper: Trying but really weird things are going on
<huwshimi> thumper: That's fixed it. Thanks mate
<huwshimi> wgrant: Did you end up finding any of those facet images?
<wgrant> huwshimi: They should be in the history of lib/canonical/launchpad/icing.
<wgrant> Removed in the last 18 months.
<huwshimi> wgrant: Cheers
<huwshimi> wgrant: Would you use bzr explorer or something to find these files?
<wgrant> huwshimi: Try checking the directory around r10000 or so. Just create a new branch and revert to then.
<huwshimi> wgrant: ah right ok
<lifeless> thumper: ping
<lifeless> thumper: I know its paste your EOD, but perhaps you could mentor Ian's review on https://code.launchpad.net/~lifeless/launchpad/bug-704446/+merge/49167
<wallyworld> lifeless: that sql bind params review - you approved it but you also need to claim it so it can be landed https://code.launchpad.net/~wallyworld/launchpad/profile-sql-bind-values/+merge/48872
<wallyworld> pretty please :-)
<lifeless> roger
<wgrant> huwshimi: Did you find the images?
<huwshimi> wgrant: yeah got them. I remember then now
<wgrant> Someone went through and cleaned up c/l/icing a while back.
<huwshimi> ok time to head off
<lifeless> stub: could I have a review on https://code.launchpad.net/~lifeless/launchpad/bug-704446/+merge/49167
<stub> lifeless: What is the "+                    AND BugMessage.index > 0" for?
<stub> end of the diff
<lifeless> tunes the query for 'commented on a bug'
<stub> oic. 0 is first comment == description
<lifeless> https://bugs.launchpad.net/launchpad/+bug/421901/comments/10
<_mup_> Bug #421901: Person:+bugs timeouts <lp-bugs> <timeout> <Launchpad itself:Triaged> < https://launchpad.net/bugs/421901 >
<stub> approved
<lifeless> thanks
<lifeless> hmm
<lifeless> bringing back fti columns seems entirely pointless
<lifeless> jkakar: is there some way to tell storm /not/ to load a column from the db ?
<lifeless> stub: can you compare the execution time for these on prod ? http://pastebin.com/raw.php?i=Lib9DXHz
<stub> lifeless: second 11 seconds, first 12.7 seconds
<lifeless> grr, really?
<lifeless> Time: 1355.438 ms on staging
<lifeless> [qa]staging
<stub> http://paste.ubuntu.com/565267/
<stub> lifeless: qastaging is patched up remember
<lifeless> stub: this doesn't depend on any db patches
<lifeless> oh...
<lifeless> we haven't indexed BugMessage.index on qastaging yet.
<lifeless> stub: can I get a plan of that second query, once hot ?
<lifeless> stub: also please try http://pastebin.com/TeHbFEwD
<stub> That was the second query. This is the plan of the first one: http://paste.ubuntu.com/565268/
<lifeless> seq scan on bugmessage
<stub> urg... that pastebin includes linenumbers in c&p
<lifeless> http://pastebin.com/raw.php?i=TeHbFEwD
<lifeless> stub: click on 'raw'
<stub> I suspect there are a lot of bugs with only a single comment
<stub> reverse that...
<lifeless> indeed
<stub> We have an index on (bug,index)
<stub> http://pastebin.com/HMY6QqJd btw
<lifeless> well, 8 seconds is better than 12
<lifeless> I think I'll unlink the bug fro mthis branch, its going to need more work
<lifeless> stub: do you think a separate index on (index,) is needed, or perhaps two indices (bug,) and (index,) and drop the composite index?
<stub> I'll test a separate index in a tic. Looking at some alternative querys atm.
<lifeless> the one in https://bugs.launchpad.net/launchpad/+bug/421901/comments/5 I think you tried already for me, but was the best I found when experimenting last week
<_mup_> Bug #421901: Person:+bugs timeouts <lp-bugs> <timeout> <Launchpad itself:Triaged by lifeless> < https://launchpad.net/bugs/421901 >
<stub> different indexes don't seem to help on BugMessage.index (or message,index)
<stub> There are 177k messages from that user...
<lifeless> probably why it shows up in the timeouts
<stub> but I don't see a sane way to execute the query. Traversing from bug -> Message means materializing all the bugtasks with those statuses, traversing from message -> bug means materializing all 177k messages...
<lifeless> perhaps if owner was on BugMessage
<stub> So for that data, I'm not sure if we can beat explain analyze
<stub> SELECT DISTINCT ON (BugTask.id) BugTask.*
<stub> FROM BugTask, Bug, BugMessage, Message
<stub> WHERE
<stub>     Bug.id = BugTask.bug
<stub>     AND Bug.id = BugMessage.bug
<stub>     AND BugMessage.message = Message.id
<stub>     AND BugTask.status in (10, 15, 20, 21, 22, 25)
<stub>     AND Bug.duplicateof IS NULL
<stub>     AND Bug.private = FALSE
<stub>     AND BugMessage.index > 0
<stub>     AND Message.owner = 931129
<stub> ORDER BY BugTask.id;
<stub> Yer - we would have to denormalize
<stub> Or we just store a table of commenters on bugs
<lifeless> distinct on is just more efficient, right ?
<stub> it's a little more efficient than DISTINCT BugTask.*
<lifeless> yeah
<stub> But probably not noticebly faster
<lifeless> stub: how many seconds is that ^
<lifeless> I'm not actually sure why BugMessage is separate to Message
<stub> 8.7 seconds
<lifeless> hmm, I had a 6 second one
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (430): FIXED in 6 hr 11 min: https://hudson.wedontsleep.org/job/devel/430/
<LPCIBot> * Launchpad Patch Queue Manager: [r=flacoste][bug=716109] Update Launchpad to r202 of lazr-js,
<LPCIBot> which includes an update to YUI 3.3.
<LPCIBot> * Launchpad Patch Queue Manager: [r=jtv] [ui=none][bug=316694][incr] Take advantage of web_link when
<LPCIBot> changing the URL in the browser bar,
<LPCIBot> rather than hacking self_link into web_link.
<LPCIBot> * Launchpad Patch Queue Manager: [r=jtv][bug=705657] Fix mirror-prober.sh wrapper script to export the
<LPCIBot> correct config. (Fix bug 705657)
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][bug=710603] The new direct subscription overlay allows
<_mup_> Bug #705657: cronscripts using production/launchpad-lazr.conf config file with REPORTIFSEEN prefix <Launchpad itself:In Progress by matsubara> < https://launchpad.net/bugs/705657 >
<LPCIBot> subscribing,
<LPCIBot> unsubscribing and editing subscriptions and is available to the
<stub> BugMessage contains bug message specific data. Message contains data relevant to all messages (answer comments etc.)
<LPCIBot> ~malone-alpha team.
<stub> Spambot
<lifeless> http://pastebin.com/raw.php?i=UdFwWx33
<stub> 10s now :-) But the estimated cost is lower, and I think that is what we need to go by here.
<lifeless> stub: the distinct on is 10 seconds?
<lifeless> stub: whats the http://pastebin.com/raw.php?i=UdFwWx33 one ?
<stub> They are all around the same range in seconds. The distinct on has a cost of 391000, your variant 325000.
<lifeless> ok
<lifeless> so I'll code up my variant next week
<lifeless> how should we go about assessing the right denormalisation (e.g. owner in bugmessage; fold bugmessage and message togeter; have a table listing commentors)
<stub> That last one has pretty much the same cost
<stub> Even with denormalizing, we are going to have similar issues - materializing 170k rows. Lots of messages there.
<stub> Doing a count of 'messages owner by 931... and index > 0' has a cost of 280k
<lifeless> stub: if we had (bugtask.id, commentator), and updated it when adding a bugtask ?
<stub> Bug,commentator makes more sense
<lifeless> stub: we filter on bugtask status, and we search and report rows in bugtask; thats why i thought bugtask would make more sense
<lifeless> -> what do I have wrong
<stub> That user has commented on 43k distinct bugs
<thumper> stub: is that user lifeless?
<stub> People comment on bugs, not on bugtasks.
<lifeless> apport
<lifeless> actually not apport
<lifeless> !janitor
<stub> janitor
<stub> who I never wanted as an actual user.
<lifeless> apport has made the most comment
<lifeless> and seb128 the next least
<lifeless> what is ~janitor for?
<stub> I think expiry and stuff
<stub> its the launchpad system robot anyway
<stub> so, this query makes no sense for their outliers anyway. Are we tackling the wrong problem?
<stub> c/their/these
<lifeless> seb128 is an outlier :P
<lifeless> [yes, he is, I'm trolling]
<lifeless> so there is a bug saying that the default Person:+bugs view is useless because it includes these bugs
<stub> heh... so we can't just turn this off for robots (unless we just make it official and designate seb a robot) - he has almost as many messages in the system as the janitor.
<lifeless> I know :)
<adeuring> good morning
<mrevell> Guten morgen
<lifeless> jml: oh hai
<jml> lifeless: hello. I got your message.
<lifeless> great
<lifeless> since i'm still conscious, and thinking work; do you want to chat now?
<jml> lifeless: definitely would like to talk, but not now.
<lifeless> ok
<Ursinha> good morning
<bigjools> morning Ursinha, up early again
<Ursinha> bigjools, trying to make it a habit
<bigjools> lifeless: totally loving the render time data at the top of the page
<adeuring> henninge: fancy a small review? https://code.launchpad.net/~adeuring/launchpad/bug-702468/+merge/49205
<henninge> ma kuckn
<henninge> I am getting this error when doing "make schema" http://paste.ubuntu.com/565319/
<henninge> Anybody can tell me what is wrong?
<wgrant> henninge: Upgrade lp-dev-deps.
<henninge> hm
<wgrant> You don't have postgresql-8.4-debversion installed.
<henninge> wgrant: I see, thanks.
<stub> Please send more Internets. Thailand has run out.
<stub> I'm rather surprised the scripts get that far when the debversion package isn't installed.
<henninge> Why does it keep these packages back? Anything I might have done? http://paste.ubuntu.com/565321/
 * henninge realizes this is probably turning into Ubuntu support.
<wgrant> dist-upgrade instead.
<wgrant> upgrade will try to avoid installing new packages.
<henninge> I only get this on this machine, though. My laptop upgraded fine (using update-manager).
<wgrant> Right, update-manager does more than just apt-get upgrade.
<henninge> currently update-manager gives me the "Not all updates can be installed. Run a partial update to install as many updates as possible." message and offers to "Partial upgrade". Is that a dist-upgrade?
<wgrant> henninge: Hmm, that's not good.
<wgrant> What does apt-get dist-upgrade say? It sounds like it may want to remove stuff, which would be bad.
<wgrant> Or there is some version skew.
<henninge> http://paste.ubuntu.com/565323/
<henninge> This looks about right, though.
<wgrant> That does.
<wgrant> Do it.
<henninge> Doing ...
<henninge> ... done.
<henninge> Now it wants to reboot, of course. (kernel update)
<henninge> But update-manager is quiet about partial updates.
<henninge> wgrant: tanks a lot!
<wgrant> Great.
<wgrant> Hopefully make will be happy now.
<bigjools> jtv: does these queries look like they'll do the same thing? http://pastebin.ubuntu.com/565325/
<bigjools> s/does/do/
<jtv> bigjools: lookingâ¦
<jtv> bigjools: what's the %s in the COALESCE stand for?
<bigjools> jtv: False
<jtv> bigjools: NULL OR TRUE equals TRUE, so no need for that I think.
<bigjools> jtv: see lib/lp/buildmaster/model/buildfarmjob.py -> getBuildsForBuilder()
<bigjools> for the storm code that generated that
<bigjools> jtv: null equals true in PG?
<jtv> No!
<bigjools> :)
<jtv> But unusually for binary operators, OR has the property that (NULL OR TRUE) evaluates as TRUE.
<bigjools> the second query is missing the coalesce
<jtv> Rather than to NULL, as one might otherwise expect.
<bigjools> the second is Rob's attempt to optimise the first
<bigjools> I'm not convinced it's right
<jtv> bigjools: I don't see the "TeamParticipation.person = 2" reflected in the new query.
<jtv> Oh wait, found it
<jtv> It's another % in the old query.
<bigjools> yeah
<jtv> bigjools: but all the nastiness, complexity-wise, is in the question of which foreign keys may be null.
<bigjools> the nastiness is in the fact that not all build farm jobs will have a related package build
<bigjools> ie TTBJs
<jtv> I get an impression that this won't show jobs for public archives that the user is not an owner of.
<jtv> No, that's not right.
<jtv> But the other way around?  Will this respect privacy?
<jtv> Say that Archive.private = TRUE and there's no matching TeamParticipation.
<bigjools> looks wrong
<jtv> There'll be no matching (PackageBuild, Archive, TeamParticipation), since those are inner-joined together on the conditions for visibility to the given user.
<jtv> Which _sounds_ like what we want,
<jtv> except then that tuple is being outer-joined to BuildFarmJob.
<bigjools> it's making my head explode
<jtv> Which means that if there is no (PackageBuild, Archive, TeamParticipation) that proves visibility to the user,
<jtv> the outer join will just make up a (PackageBuild, Archive, TeamParticipation) of all nulls.
<jtv> And the WHERE clause doesn't check for that, so AFAICT it'll happily return a BFJ for an archive that the user isn't supposed to see.
<jtv> The important thing there is that with an outer join, a join condition is crucially different from a "where" condition in that the latter filters out tuples from the entire join, whereas the former may just result in a tuple of nulls where nothing matches.
<bigjools> the problem with the original query is that it's doing a seq scan on archive
<jtv> Use Union.
<bigjools> right
<jtv> This is the wide-shallow/narrow-deep pattern that we keep seeing with privacy.
<bigjools> I'll ditch the left joins
<jtv> Just write out separate cases for public and private archives, then factor for identical parts that you can share.
<jtv> What should happen if there's no PackageBuild?  Should be shown anyway?
<bigjools> yes
<bigjools> there's no privacy outside of anything that has a packagebuild
<jtv> So for public archives you get something likeâ¦
<jtv> SELECT DISTINCT BuildFarmJob.*
<jtv> LEFT JOIN PackageBuild ON PackageBuild.build_farm_job = BuildFarmJob.id
<jtv> LEFT JOIN Archive ON Archive.id = PackageBuild.archive
<jtv> WHERE Archive.private IS FALSE
<jtv> UNION
<jtv> SELECT DISTINCT BuildFarmJob.*
<jtv> LEFT JOIN PackageBuild ON PackageBuild.build_farm_job = BuildFarmJob.id
<jtv> LEFT JOIN Archive ON Archive.id = PackageBuild.archive
<jtv> LEFT JOIN TeamParticipation ON TeamParticipation.team = Archive.owner
<jtv> WHERE Archive.private IS TRUE AND TeamParticipation.person = %s;
<jtv> If there are a lot of BFJs without PBs, you could go even further:
<jtv> SELECT DISTINCT BuildFarmJob.*
<jtv> LEFT JOIN PackageBuild ON PackageBuild.build_farm_job = BuildFarmJob.id
<jtv> WHERE PackageBuild.id IS NULL
<jtv> UNION
<jtv> SELECT DISTINCT BuildFarmJob.*
<jtv> FROM BuildFarmJob  -- I've been forgetting these lines, haven't I?
<jtv> JOIN PackageBuild ON PackageBuild.build_farm_job = BuildFarmJob.id
<bigjools> I think you need to paste
<jtv> JOIN Archive ON Archive.id = PackageBuild.archive
<jtv> OK, OK, I'll paste. :)
<bigjools> I can't follow this here
<jtv> bigjools: https://pastebin.canonical.com/43093/
<jtv> Ahhh, there's the LIMIT/OFFSET too isn't it?
<jtv> Need to work that in as well.
<jtv> We can use that to solve the remaining optimization problems.  Hang on.
<bigjools> jtv: don't worry about that, it's the batchnav
<jtv> Doesn't mean we shouldn't worry about it.  It's actually most likely the single biggest factor in this problem.
<bigjools> the problem is that a slow query is issued twice, once to count, the next time with the limit/offset
<jtv> But part of the problem is that slicing happens all the way at the end, and the query planner currently has no way to push that down into the nodes for preliminary optimization.
<jtv> Hence the seq scan on Archive.
<bigjools> we need ordering as well
<jtv> Yes.
<bigjools> and, is the distinct honoured across unions?
<bigjools> or did you guarantee they don't intersect?
<jtv> Yes, I required that "Archive.private = TRUE" in the last query so that makes this a partitioning.
<jtv> No overlap.
<bigjools> jtv: the queries are also missing a BuildFarmJob.builder = XXX
<jtv> ah
<bigjools> but I shall experiment and see what else I can do!
<jtv> bigjools: I'm not done either :)
<deryck> Morning, folks.
<jtv> hi deryck
<bigjools> howdy deryck
<bigjools> jtv: explain analyze on your new query shows a seq scan on archive still
<jtv> bigjools: not entirely surprising.
<bigjools> because there's no index on private
<jtv> Well that's why I said index it.  :-)
<bigjools> :)
<jtv> bigjools: somewhat elaborate attempt hereâ¦ https://pastebin.canonical.com/43094/
<bigjools> jtv: why order each inner query and then again in the outer?
<jtv> bigjools: to shortcut their execution when the limit is reached.
<bigjools> order and limit in fact
<bigjools> ok
<bigjools> I don't know how we can control that in the batchnav
<jtv> The backend may be smart enough to do that for itself, but not sure.
<bigjools> one can try
<jtv> I've seen 8.4 backends push the ORDER BY down into sub-plans, so maybe we can leave that out.
<bigjools> well I can't do it in our current infrastructure anyway
<jtv> OK, I'll drop that bit.
<jtv> BTW I've been assuming that by far most archives are publicâ¦ is that correct?
<bigjools> yep
<bigjools> 3 seq scans in that query
<bigjools> buildfarmjob, which is ok
<bigjools> packagebuild
<jtv> 2 on Archive?
<bigjools> and archive
<jtv> Oh
<bigjools> the good news is that it seems to return the right number of rows :)
<jtv> We could try the TDD approach: write the absolute minimum that satisfies our tests...  SELECT %(expected_number_of_rows)d
<jtv> Is this less elaborate version any worse?  https://pastebin.canonical.com/43095/
<bigjools> assuming the tests are good, yes
<bigjools> jtv: same sort of performane
<bigjools> performance
<bigjools> same seq scans
<bigjools> we definitely need an index on archive.private
<bigjools> it would help elsewhere
<jtv> Or in this last version of the query, one on (private, owner)
<bigjools> yeah
<jtv> bigjools: can you see which of the two parts the packagebuild query is coming from?
<bigjools> the seq scan?
<jtv> Sorry, yes.
<bigjools> the second I think
<bigjools> there's a hash cond for archive.id above it
<jtv> Could you paste me the plan?
<bigjools> so prob need an index on packagebuild.archive
<bigjools> which query? :)
<bigjools> they're all similar but ...
<jtv> https://pastebin.canonical.com/43095/
<jtv> Quite possible that we need that index, yes, or on (archive, buildfarmjob) or vice versa.
<jtv> There's a patch now for hypothetical indexes in postgres.  That'd be cool to have.
<bigjools> http://pastebin.ubuntu.com/565348/
<bigjools> yes, you mentioned that, it would be very useful
<jtv> Doesn't create real indexes, but lets you say "EXPLAIN HYPOTHETICAL" and it'll explain your query as it would do it if the hypothetical indexes were real.
<bigjools> so you do CREATE INDEX HYPOTHETICAL ... ?
<bigjools> hmmm so packagebuild already has indexes on archive and BFJ
<jtv> Yes, like that
<jtv> A unified index may help.
<jtv> So one on both columns at the same time.
<bigjools> is that hypothetical index stuff packaged?
<jtv> No
<jtv> It's a patch.
<bigjools> urgh
<jtv> But there's a PostgreSQL eXtension Network coming.
<bigjools> so, I am seeing the original query run quicker than your new ones right now
<jtv> heh
<bigjools> I suspect it's cause it only has one seq scan
<jtv> The seq scan on archive doesn't look at all costly.
<bigjools> rows=23596
<jtv> bigjools: oh!  And have you tried indexing on the sort order?
<bigjools> yeah that adds 2 seconds alone, good idea
<jtv> Indexing slows it down?
<bigjools> removing the ORDER BY speeds it up by 2 seconds
<bigjools> I'll add the index on dogfood and see what happens
<jtv> Another big cost seems to be the PackageBuildâBFJ join.
 * jtv slowly figures out that bigjools wasn't being sarcastic with the "that adds 2 seconds, good idea" :)
<bigjools> heh
<bigjools> jtv: actually date_finished is already indexed
<jtv> bigjools: but (date_finished, id)?
<bigjools> no, but how often will date_finished need a tie breaker to ID?
<jtv> If the sort order is completely covered, that may open up new plans.
<bigjools> index on private makes bugger all difference
<jtv> :(
<jtv> Well, scanning Archive wasn't that costly.
<bigjools> no, I mean there's still a seq scan
<bigjools> why is it scanning :/
<jtv> A seq scan is the most efficient thing to do unless it's clear that only a surprisingly small percentage of the table will actually be needed.
<jtv> Think disk seeks: you can read quite a lot of data in a seq scan in the same time that it might take to seek to the next table record that an index identifies as matching.
<bigjools> indeed
<jtv> (Bearing in mind that the index is in key order, not tuple storage order, so likely to be very random access patterns)
<jtv> That's also why we have bitmap scans.
<jtv> bigjools: hang on, I just stumbled onto a major simplification
<bigjools> adding an index on (date_finished, id) makes no difference :/
<jtv> bigjools: boo
<jtv> But here's another version.  I'd guess it was slower, but knowing trumps guessing: https://pastebin.canonical.com/43096/
<bigjools> so far, a lot slower ....
<jtv> bigjools: that's fine; it's just a stepping stone to https://pastebin.canonical.com/43097/
<jtv> Oh, that needs a DISTINCT obviously
<jtv> Like so: https://pastebin.canonical.com/43098/
<bigjools> oooooo quick
<jtv> Then presumably it's incorrect in some way, but still nice to see a bit of speed.  :-)
<bigjools> nope, looks fine!
<jtv> I suspect the UNION is a very effective optimization barrier.
<bigjools> returns correct number of rows
<bigjools> down to 2 seconds from 9
<jtv> This makes it possible for the backend to materialize "archives this user is an owner of," which just has to be fast because so few records will be involved.
<bigjools> it's quicksorting in memory now
<bigjools> was using external merge on disk last time
<jtv> The joins can't have helped.
<bigjools> "Disk: 142912kB" - yes :)
<jtv> The key to this is that the Archive seq scan is actually relatively cheap.
<bigjools> it is
<bigjools> actual time=0.011..21.494
<jtv> So I'm materializing one, as the first part of the union!
<jtv> That's even cheaper than previously, for some reason.
<bigjools> bizarro
<jtv> There was just no way to get around a seq scan on archive, unless we managed to cram enormous amounts of selectivity into the PBs firstâand even then.
<jtv> I suspect that selectivity just isn't there.
<jtv> Which can't have helped the size of the ultimate sort buffers either, for what it's worth.
<jtv> Also, the PackageBuild join was very slow, and an outer join didn't look very different from an inner one, so I hoisted it out of the subquery.
<jtv> That way it gets done only once.
<bigjools> thanks jtv, I'll Stormify this and run the tests against it
<bigjools> now, I need food
<jtv> OK, glad I could help.
<bigjools> jtv: you certainly did
<jtv> :)
<gary_poster> bo hoo, no reviewer
<gary_poster> boo, even
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: jcsackett | https://code.launchpad.net/launchpad-project/+activereviews
<jcsackett> gary_poster: looking for a review for https://code.launchpad.net/~gary/launchpad/bug713382/+merge/49145 ?
<gary_poster> yes, jcsackett ! :-)
 * jcsackett is looking at it now.
<gary_poster> thank you
<jcsackett> gary_poster: in bug.py, what's the reason for working with "temp_recipients" instead of on "recipients"?
<jcsackett> nm, reread proposal.
<gary_poster> :-) l
<gary_poster> k
 * jcsackett gets more coffee while reviewing.
<gary_poster> m
<gary_poster> n
<deryck> henninge, we see you connect, but never hear you
<jcsackett> gary: r=me. i've requested follow up from sinzui. let me know if that becomes a blocker and i'll hunt him or someone else down.
<jcsackett> gary_poster ^
<sinzui> I can review it now
<jcsackett> ah, i missed that you had logged on, sinzui. :-)
<gary_poster> jcsackett: many thanks.  will be back in afternoon
<abentley> jcsackett, thanks for your review.  You'll see that all the items I've put up for review build toward the goal of merging translations using a job.
<jcsackett> abentley: i am indeed noticing that trend.
<abentley> If you have any questions, I'm happy to answer 'em here.
<henninge> adeuring: Two things about your branch.
<adeuring> henninge: yes?
<henninge> 1. I am pretty sure this is only supposed to work one way.
<henninge> i.e. first "upstream" translation overwrites "Ubuntu" translation but not the other way round.
<adeuring> henninge: right, but this is guarded by share_with_other_side
<adeuring> this flag is always true for product and projectgroups
<adeuring> and must be expicitly enabled for SPs
<adeuring> so I think we don't need extra guards
<henninge> hm
<henninge> Where is the flag "always true"?
<henninge> In the policy?
<adeuring> henninge: right
<henninge> ok, I see what you mean but AFAICT this is not the what you want.
<henninge> s/the//
<henninge> adeuring: ^
<adeuring> henninge: well, I think we want upstream translations propagated to ubuntu, and that's done by share_with_other_side == True for upstreams
<adeuring> Or am I missing something?
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (355): FIXED in 6 hr 1 min: https://hudson.wedontsleep.org/job/db-devel/355/
<henninge> adeuring: no, they are only to propagate if the Ubuntu translation is either empty or identical to the upstream one.
<henninge> adeuring: if they are different, they stay different.
<adeuring> henninge: well, the bug says "In the old model, providing the first upstream translation would have overwritten the Ubuntu translation, too. "
<henninge> adeuring: yes, that is the exception to the rule I just described and which is missing from the code.
<henninge> and which you implemented correctly.
<henninge> But it does not work the other way round.
<henninge> The exception, I mean.
<adeuring> henninge: ah, so you think thatg we should restrict this feature explicitly for the flow upstream -> ubuntu?
<henninge> exactly! ;-)
<adeuring> even if sharing the other way round is enabled?
<henninge> yes
<henninge> The reasoning for this exception goes like this:
<henninge> We import templates and translations from upstream, but there are no (or little ) translations yet.
<henninge> Then Ubuntu translators go to work and start translating.
<henninge> The upstream translators get going, too, and after a while we get updated upstream translations.
<henninge> Without this exception, these upstream translations would not show up in Ubuntu.
<henninge> We have been getting bad press about how "Ubuntu ignores upstream translations2
<henninge> ".
<henninge> But really, Ubuntu translations should be fed back to upstream anyway, but that is not something we can solve by code.
<adeuring> right. But how likely is the situation that the other "sharing variant" does something wrong? I'd prefer to not make the code even more complex ;)
<adeuring> I mean, somebody must explicitly enable this sort of "sharing flow"
<henninge> adeuring: It needs to retain the old behavior, though. It's documented and the translators are used to it.
<henninge> What do you mean by "enable"?
<adeuring> well, ok, I'll add a sort of diode then
<bigjools> jtv: so I converted your SQL into STORM syntax.  I think I might be about to faint that I got it right first time and the tests all pass.
<henninge> adeuring: please do.
<jtv> bigjools: congratulations!
<adeuring> henninge: and what is the other issue?
<bigjools> jtv: http://pastebin.ubuntu.com/565404/
<henninge> adeuring: secondly, I would expect a test or two for this specific behavior.
<henninge> adeuring: you adapted some tests but I guess they just failed because the incumbent message happened to be empty.
<adeuring> henninge: hmmm, I think the test method names indicate that the incumbent message is supposed to be empty, right?
<adeuring> but nevenr mind, i can add another test ;)
<henninge> adeuring: hm, you may be right
<henninge> but then perhaps a test is missing for when it is not?
<adeuring> ok, i'll check it
<henninge> adeuring: thanks.
<henninge> adeuring: I fear you will run into some work with the test when you add the "diode" because I think it is designed highly symmetrical atm.
<henninge> but it would be good to show the assymmteric behavior in the test.
<benji> deryck: do you know of any docs about how to use LP.client.Launchpad() to interact with the web service from JavaScript?
<deryck> benji, on call, will respond just a minute
<benji> thanks
<LPCIBot> Project devel build (431): FAILURE in 5 hr 33 min: https://hudson.wedontsleep.org/job/devel/431/
<jcsackett> abentley: i'm looking at your last branch now. i'm not familiar with lazr configs--the purpose of your additions is just proper error capturing when the job runs?
<abentley> jcsackett, no, the configuration glues it all together.  Nothing could be run without it.
<abentley> jcsackett, It specifies the database user to use, the JobSource to use, the error handling, etc.
<jcsackett> abentley: ah, i see. i had only looked at the first two config changes.
<abentley> jcsackett, lazr-js is a layered configuration system, so those first two overlay the last one.
<jcsackett> abentley: dig. thanks.
<deryck> benji, hi, back now.
<deryck> hmmm, so lp_client docs basically>
<deryck> benji, I don't think we have any actually.  I've always looked at the client code itself, or followed examples in other js code.
<deryck> sorry
<benji> deryck: that's what I suspected; I'm writing the start of some docs that will hopefully fill the hole
<deryck> ah nice
<jcsackett> abentley: all branches are r=me; sinzui has already followed up on several.
<jcsackett> really nice work.
<abentley> jcsackett, thanks.
<deryck> abentley or rockstar -- has the minus icon on bug pages to unlink a branch been ajax before now?  Or it always went to a confirmation page?
 * deryck is QAing new lazr-js and not sure
<rockstar> deryck, on bug pages? No idea.  gmb did that work.
<abentley> deryck, unsure.
<deryck> ah ok. gmb ^^ ?
<sinzui> abentley: I think everything is cleared to land now
 * gmb reads scrollback
<abentley> sinzui, great, thanks.
<gmb> deryck: I *think* it's always gone to a confirmation page.
<gmb> Yet another we-only-did-half-the-work-before-moving-on.
<deryck> gmb, ok, cool.  thanks.
<jcsackett> deryck: assuming you're concerned about a branch that recently hit, i can confirm that as of last monday unlinking went to a page, not ajax.
<deryck> jcsackett, indeed that is my concern.  Thanks!
<deryck> heh, oops.  Somewhere a link from qastaging pointed to lpnet.  And now there is a dumb project on launchpad.
<deryck> or a new team rather.
<deryck> heh, or a project that thinks it's a team.  gah!
<deryck> sinzui, can I or you delete https://launchpad.net/deryck-test-qa-team/, or do we need an admin for that?
<sinzui> deryck: you cannot see the delete link?
<sinzui> deryck: oh sorry, that is a project. the cannot be deleted. you can rename it and deactivate it
<deryck> sinzui, ok, thanks.  I'll just deactivate it.  Sorry about that.
<deryck> maybe I hand entered a URL and didn't realize I forgot the qastaging bit.
<abentley> sinzui, I want to create a Job every time a Packaging is created, to merge the translations between the sourcepackage and the productseries.
* allenap changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: jcsackett, allenap | https://code.launchpad.net/launchpad-project/+activereviews
<abentley> sinzui, Packaging doesn't have a constructor, but I'm thinking of adding one, and having it call notify.  Make sense?
<sinzui> yes it does
<abentley> sinzui, cool, thanks.
<abentley> sinzui, are Packagings ever modified, or just created and deleted?
<sinzui>  abentley never modified
<abentley> sinzui, great.
 * sinzui wonders though if changing a ds packaging workflow calls delete?
 * sinzui lookse
<sinzui> abentley: definitely not modified. We create, and occasionally delete. Packaging acts as a historical record
<abentley> Good to know.
<jtv> jcsackett: got an MP for you!  Are you free?  https://code.launchpad.net/~jtv/launchpad/bug-711077/+merge/49242
<jcsackett> jtv: in the middle of investigating a test failure. can look in half an hour?
<jtv> jcsackett: if you like, though I could ask allenap first
<jcsackett> jtv: if he's free now, sure. if not, i'll be happy to take a look at it soon. :-)
<allenap> jtv: I'm up for a review.
<jtv> great!
<jtv> see mp                                                                   ^^^^
<jtv> bigjools: it seems the parallel a-f is on qastagingâ¦ want to walk me through the Q/A process?
<bigjools> jtv: I'm in the middle of something, happy to do so later
<jtv> OK
<bigjools> jtv: passing tests were some sort of weird miracle earlier, they don't actually pass and my storm expression won't compile
<bigjools> I am starting to really detest storm syntax
<jtv> bigjools: it can be annoying, yes.  Anything there I can help with?
<bigjools> jtv: maybe, one sec
<jtv> Debugging the things isn't fun either.
<bigjools> tell me about it
<bigjools> jtv: http://pastebin.ubuntu.com/565450/
<bigjools> won't compile,  it doesn't like the PackageBuild.archiveID or PackageBuild.archive
<jtv> bigjools: have you tried PackageBuild.id.is_in(Select(â¦))?
<bigjools> jeez
<bigjools> ok
<bigjools> it would be PackageBuild.archive.is_in of course
<bigjools> AttributeError: 'Reference' object has no attribute 'is_in'
<jtv> Grrrr
<jtv> Try PackageBuild.archive_id.is_in or PackageBuild.archiveID.is_in
<bigjools> this ID vs reference stuff is seriously irritating
<jtv> This stuff is way too hard.
<jtv> Yes
<bigjools> that too
<bigjools> I suspect the _id will do it, I was using ID before
<jtv> grrrr
<bigjools> yay it worked
<jtv> \o/
<bigjools> thanks jtv
<jtv> np
<jtv> you were blocking my lane, had to help :)
<bigjools> I think I knew about this, it's clearly been a while since I wrote storm
<jtv> But you keep hoping someone will fix this stuff while you're away, don't you?
<bigjools> now that part is fixed, I get the problem somewhere else
<jtv> That's progress.
<jtv> What is it now?
<bigjools> same compile error about a Reference - but no indication of which one
<jtv> Ah yes that one
<jtv> it's always fun.
<bigjools> FSVO
<jtv> I do TLAs, not ETLAs
<bigjools> ha
<bigjools> OMG NFW BMX
<jtv> BMX?  WTF!?
<jtv> Anyway, with the Reference one at least you know you're missing a _id or ID suffix on a reference attribute.  It's not that you might have mis-spelled one.
<jtv> (That comes later.)
<bigjools> yes
<bigjools> shockingly, my first guess found it
<jtv> the gods are toying with you
<bigjools> so is dogfood
<jtv> "â¦they play with us for their sport"
<bigjools> dogfood is doofgod backwards.
<bigjools> mawson should be aergia it's so bloody slow
<jtv> aegria?
<bigjools> aergia
<jtv> Ah, not familiar with her
<bigjools> darn, this query is bust
<jtv> What now?
<bigjools> it's returning the wrong stuff - yet the tests pass
<LPCIBot> Project devel build (432): STILL FAILING in 1 hr 53 min: https://hudson.wedontsleep.org/job/devel/432/
<LPCIBot> * Launchpad Patch Queue Manager: [r=thumper][no-qa] Mechanical move of
<LPCIBot> canonical.launchpad.windmill.testing to lp.testing.windmill.
<LPCIBot> * Launchpad Patch Queue Manager: [r=allenap][bug=528367] Added alt tag to remove icons.
<LPCIBot> Project db-devel build (356): FAILURE in 2 hr 27 min: https://hudson.wedontsleep.org/job/db-devel/356/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12357
<LPCIBot> included.
<bigjools> jtv: hurray at last.
<jtv> What was the problem?
<bigjools> the history page on dogfood finally loads for adare
<bigjools> jtv: pebkac
<bigjools> jtv: where's your branch that you need testing?
<jtv> bigjools: lp:~jtv/launchpad/bug-181368-view
<jtv> That's against devel though.
<bigjools> 'sok
<jtv> (In fact it's already _in_ devel)
<bigjools> I'm going to pocket copy a package to create publications in lots of places (it has 6 arch binaries)
<lifeless> moin
<lifeless> bigjools: glad you like it
<bigjools> lifeless: saves a bit of ctrl-u/page-down
<lifeless> I described it to elliot as 'tastefully IN YOUR FACE'
<bigjools> jtv: ok, I've copied acl in maverick to maverick-proposed, with binaries.  See https://dogfood.launchpad.net/ubuntu/+source/acl/+publishinghistory
 * bigjools runs df publisher
<jtv> bigjools: I'm not sure what to look out for though
<bigjools> jtv: I'll send you a log file when it's done.  You'll see that source go from pending to published
<allenap> jtv: I'm not going to finish your review today. Do you mind if I complete it in the morning?
<jtv> allenap: then maybe I should ask jcsackett to give it a go after all.
<jtv> allenap: or were you already partway through it?
<bigjools> jtv: also this publisher may not finish within the 20 minutes I have left today
<jtv> bigjools: ahâ¦ and this is df innit?
<bigjools> jtv: yeah I limited it to just the suite we want, but it will still take some time
<bigjools> a full run takes *hours* :/
<allenap> jcsackett: I am partway through it, but not that far, so I'm happy for him to take it if he is too. I have been pulled away by non-work things.
<jtv> Oh well, have to check up tomorrow then.
<bigjools> jtv: ah it finished
<jtv> bigjools: so it seems to have
<jtv> So how do we know it did something sensible?
<jml> lifeless: good morning.
<lifeless> jml: hi hi
<jcsackett> jtv: you want to wait on allenap, or shall i take a look at it now?
<jml> lifeless: now or in the next hour would be a good time for a call.
<bigjools> jtv: I am checking the Packages files
<lifeless> ok, I'll ping you in a few minutes
<bigjools> jtv: how many does it kick off in parallel BTW?
<jtv> jcsackett: I'd appreciate a lookâI'm pretty much EOD, but I'm slightly ahead of allenap timezone-wise.
<jtv> bigjools: one for each architecture (including "source")
<jcsackett> jtv: okay, i'll take a look and ask any questions in the comments.
<bigjools> jtv: so 6
<jtv> bigjools: but that's the parallel run.  This branch is a different change.
<jml> lifeless: ok.
<bigjools> it is?
<jtv> bigjools: yes, circumventing an awkward view.
<bigjools> seemed quicker :)
<jtv> Good!
<jtv> bigjools: the parallel run is still waiting for the RT
<bigjools> jtv: only 4 of the binaries got published, I don't know if that's right or not
<bigjools> but the ones that did look ok
<jtv> bigjools: hmmm for proper Q/A we'd have to know whether that was right.
<bigjools> yes
<bigjools> could be PaS
<jtv> PhotoAcoustic Spectroscopy?
<bigjools> ah I should try an arch indep, that'll not matter
<bigjools> Package Arch Specific
<bigjools> it's a last-ditch override file that the publisher uses
<jcsackett> jtv: while you're still here, i note in the diff you're adding some columns, but this isn't targeted to db-devel; i assume it's not introducting change to the db, but don't really understand why not.
<jtv> jcsackett: adding columns!?
<jtv> jcsackett: sounds as if something went wrong with the MPâ¦ just a mo'
<jcsackett> jtv: several adds of IntCol (branch_id), but not replacing similar statements. i may be misinterpreting.
<jtv> jcsackett: oh, those aren't columnsâthey're attributes that allow me to read the FK attributes directly
<jtv> Pretty standard stuff.
<jcsackett> jtv: ah. i figured it was something like that, but wasn't sure. and the use of "Col" in the declaration raised alarms. :-)
<jtv> Seems I have to go help with a little accident here.
<bigjools> jtv: so a tentative ok, but please ask wgrant to double check since this really needs more eyes to verify it before we unleash on the distro
<jtv> bigjools: ack
<bigjools> jtv-afk: so meh, I forgot to notice that copy-package only copied some of the binaries, so it seems perfectly ok.
<lifeless> jml: ping
<lifeless> jml: skype me
<lifeless> deryck: question for you, why are BugMessage and Message separate tables?
<deryck> lifeless, I literally have no idea. :-)  I asked once before and didn't understand the response.  I think....
<deryck> lifeless, it was written in a time when we imagined different kinds of messages, of which bug message was one type.
<lifeless> there are 640 shared messages
<jml> lifeless: k
<lifeless> that is, one message on several bugs.
<deryck> hmmm, I don't know why that would be.
<lifeless> deryck: I think we could make a bunch of queries faster if we deep sixed the sharing and just copied the message when that happens
<lifeless> deryck: email control interface controlling many bugs?
<lifeless> deryck: in case its not obvious I mean a db migration too :)
<deryck> lifeless, perhaps.  but I thought you could only affect multiple bugtasks, not bugs, from email
<deryck> lifeless, yes, I think moving all that across to copies, not shared messages, is best
<jcsackett> what's the difference between using IStore and Store.of? they seem to result in the same thing, but i'm not certain.
<deryck> jcsackett, so IStore is what we provide to help manage connecting to the db, instead of just straight import Store from Storm.
<deryck> jcsackett, see lib/canonical/launchpad/doc/storm.txt
<jcsackett> deryck: thanks.
<deryck> jcsackett, actually, I meant to point you at:  lib/canonical/launchpad/doc/db-policy.txt
<deryck> well, either is probably ok ;)
 * jcsackett changes which file he is opening...
<lifeless> jml: http://gems.github.com/list.html
<jcsackett> today has been a very busy review day...
<jcsackett> sinzui: can i get you to look at something?
<sinzui> yes
<jcsackett> i'm having trouble understanding the "why" of a bit of publisher code: https://pastebin.canonical.com/43132/
<jcsackett> it looks like it's trying to rebuild web service based requests, but i don't understand why--commenting out that code doesn't seem to hurt webservice functions.
<jcsackett> (this is the actual culprit for the api.launchpad.net pillar aliases redirecting outside of the api)
<sinzui> jcsackett: I confess I do not understand it
<lifeless> jcsackett: btw
<lifeless> jcsackett: see my last comment on https://code.launchpad.net/~jtv/launchpad/bug-711077/+merge/49242 - thats something to bear in mind
<sinzui> my head may be filled with straw today. I can struggling to refactor what I think is a simple test
<jcsackett> lifeless: good thought.
<jcsackett> sinzui: yeah, after a morning filled with the largest review queue i've seen, i'm feeling pretty muddled.
<jcsackett> (and since you follow up on them all, i'm not surprised you feel the same).
<jcsackett> lifeless, any chance you know what's up in this bit? https://pastebin.canonical.com/43132/
<lifeless> other than the gratuitious pass?
<jcsackett> hm, you can ignore that--left over from when i commented out a bunch of code to see what changed.
 * jcsackett edits paste.
<lifeless> what file is that in ?
<lifeless> jcsackett: have you been introduced to bzr's annotate functionality ?
<jcsackett> lifeless: i've seen annotate used once, and heard much of it. i do not, as yet, know how to do anything useful with it. :-P
<jcsackett> file is canonical.launchpad.webapp.publisher
<jcsackett> it seems to rebuilding webservice requests (and in the process losing the api layer)
<lifeless> so the comment says:
<lifeless>  - no rootsite
<lifeless>  - handling shipit
<lifeless> blame says the outer if was done in rev 3564.1.43
<lifeless> and the inner one in 7675.289.2 / 3 / 4
<lifeless> bzr log -r 7675.289.2..7675.289.4 tells me that bug-376990 was at issue
<lifeless> 'canonical_url() needs to return browser URLs when generating XHTML representations'
<jcsackett> yeah.
<jcsackett> that seems to be the inverse of the problem leonardr pointed out to me.
<lifeless> so, it wants to get canonical urls for browser links some of the time
<jcsackett> so, this only happens when canonical_url is called for pillars that we've gotten by alias in the webservice. i think i can just change a call up the pipe to pass the request along.
<lifeless> this also tells us how to test it
<lifeless> inline bug commenting
<lifeless> but we have a stale comment or something, because the block *above* the comment was changed by tim in rev 3758.1.1
<bac> hi sinzui
<lifeless> jcsackett: so, what are the symptoms?
<sinzui> hi bac
<jcsackett> lifeless: bug 715992
<_mup_> Bug #715992: Pillar aliases redirect outside of webservice on webservice calls <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/715992 >
<lifeless> wow, we are digging up some chestnuts
<lifeless> this should be critical otherwise its a priority inversion
<jcsackett> this came up because it needs to be whacked to deal with bug 623099
<_mup_> Bug #623099: AttributeError filing a bug using the API <lp-foundations> <oops> <Launchpad itself:In Progress by jcsackett> < https://launchpad.net/bugs/623099 >
<lifeless> yes
<lifeless> agreed; I'm just saying bump it to critical
<jcsackett> ah, dig.
<jcsackett> done.
<lifeless> because its otherwise holding a critical hostage, which wouldn't make sense
<lifeless> so
<lifeless> looks to me like you need to pass a request in
<lifeless> '    If there is no request available, the protocol, host and port are taken
<lifeless>     from the root_url given in launchpad.conf.
<lifeless> '
<lifeless> as leonardr says
<lifeless> 'Possibly there's a method that needs to have the current request passed into it.'
<lifeless> jcsackett: whats the backtrace leading into this call of canonical_url ?
<jcsackett> yeah, i think i've found it; i just hit this block of code and was wondering what on earth it was doing.
<jcsackett> bit of a rabbit hole, really.
<lifeless> its guessing at the url the client used
<lifeless> and the default is to guess 'web browser request on main site'
<lifeless> worth enhancing the comment
<lifeless> and adding a :param request: up in the docstring (subsuming the 'if there is no request available' prose.)
<lifeless> ?
<jcsackett> lifeless: yeah, i'm cleaning up the comments.
<jcsackett> lifeless: thanks.
<benji> deryck: I'd love any feedback or additions you might have to my first draft of "how to access webservice APIs via JavaScript": https://dev.launchpad.net/yellow/JavaScriptAPIAccessDraft
<deryck> benji, ok, taking a look now
<jcsackett> any chance i can get a review on https://code.launchpad.net/~jcsackett/launchpad/api-pillar-redirects-715992/+merge/49279?
<deryck> benji, yeah, it's good.  Do you have plans to fill in more about PATCHPlugin?
<benji> deryck: I hope to.  I have to figure out how to use it first. :)
<deryck> benji, you can look at how the inline editor widgets and commenting use it.
<benji> My plan is to put in everything I know so people can get a better start.  I spent way too much time figuring out what little I know thus far.
<benji> cool, thanks for the pointer
<deryck> benji, I can add to this too.  But I'll need pings to remind me about it.
<benji> you can count on me
<deryck> benji, our use of the js client as evolved over time, and we're probably named_post and named_get heavy, when we should favor patch with patch_field set true.
<benji> interesting
<deryck> and then setting accept to xhtml, we get back the html for the part we patched. instead of the full resource.
<deryck> well, unless we need the entire thing.  it depends on use, I guess.  but it seems more common to do attribute patching.
<benji> can the client understand xhtml?  why does the server not return partial JSON?
<deryck> benji, well xhtml can be created into a node easily in YUI.  it's just a string, I think, not try xhtml.
<deryck> s/try/true/
<deryck> so...  var stuff = result_of_my_patch(); var my_html = Y.Node.create(stuff);
<benji> hmm, I don't understand.  Is that for when we only patch one attribute at a time?
<deryck> benji, yes.  which is actually common.  And the attribute will be a FK to some other object on the backend.
<benji> ah, ok that makes sense
<deryck> that pseudo code might not be exactly how we do it either.  Just going off sketch from memory.
<sinzui> benji: js replies on the the DOM's engine to construct elements You can create xhtml or html using DOM nodes, but what is rendered could be the other :( I have also see cases where the code tries to place a list in a paragraph, but what is rendered is a paragraph, a list, and another paragraph
<sinzui> s/replies/relies/
<benji> interesting
<thumper> morning
<abentley> jcsackett, I have a sequel for you: https://code.launchpad.net/~abentley/launchpad/job-on-new-packaging/+merge/49285
 * jcsackett looks
<thumper> deryck: ping
<thumper> deryck: do you know most about windmill tests?
<deryck> thumper, I guess I'm your only help where windmill is concerned ;)
<thumper> I have a question about lines like: start_url = (windmill.settings['TEST_URL'] + 'bugs/%d' % bug.id)
<thumper> windmill.settings['TEST_URL'] is what?
<thumper> and why?
<thumper> and why does only the code windmill tests use it?
<thumper> and lib/lp/testing/windmill/lpuser.py:35
<deryck> thumper, I actually don't know what that is.
<thumper> deryck: I think it may have to do with that wallyworld did, to do with parallelizing the test suite
<deryck> thumper, only code tests made use of it, and I'm not sure why.
<thumper> and not using hard coded ports
<deryck> yeah, that would be my guess.  but that's not the way he originally mentioned about not hard coding ports.
<thumper> deryck: I have a day of doing windmill today with three branches needing some form of windmill testing
<thumper> deryck: I was thinking of a base class helper method
<thumper> deryck: that uses canonical_url(obj, force_local=True)
<thumper> deryck: and appending that to the base test url
<thumper> deryck: there are too many uses of this already
<deryck> thumper, why do you need windmill tests?  What are you wanting to test?
<thumper> deryck: mumble?
<deryck> sure
<Ronnie> is there a python-launchpadlib that can run without compability problems on 8.04?
<Ronnie> SWAT ^
<jcsackett> abentley: r=me.
<abentley> jcsackett, thanks.
<deryck> wallyworld, windmill.settings['TEST_URL']
<deryck> wallyworld, thumper -- client.open(url='%s/bugs/1' % BugsWindmillLayer.base_url)
<_mup_> Bug #1: Microsoft has a majority market share <iso-testing> <ubuntu> <Clubdistro:Confirmed> <Computer Science Ubuntu:Invalid by compscibuntu-bugs> <EasyPeasy Overview:Invalid by ramvi> <GNOME Screensaver:Won't Fix> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <The Linux OS Project:In Progress> <metacity:In Progress> <OpenOffice:In Progress by lh-maviya> <Tabuntu:Invalid by tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:New> <Ubuntu:I
<deryck> later on, everyone
<wallyworld> thumper: http://people.canonical.com/~ianb/request-build-error.png
<Ronnie> lifeless: wgrant ^^
<lifeless> Ronnie: how far up are you wanting me to look ?
<Ronnie> a few lines: (21:46:52) Ronnie: is there a python-launchpadlib that can run without compability problems on 8.04?
<lifeless> the one we ship in 8.0.4 ?
<lifeless> blah, 8.04
<lifeless> checking rmadison
<lifeless> no, nothing before karmic
<lifeless> dapper is EOL in a few months
<lifeless> so no plans to chane this
<lifeless> Ronnie: why?
<Ronnie> the ubuntu-nl server still runs on 8.04. we want in one case to communicate with launchpad (creating bug reports)
<lifeless> if thats in the canonical datacentre, they are migrating them all to lucid
<lifeless> just tee that up, it should be queued already
<Ronnie> lifeless: its an own managed server
<lifeless> ah
<Ronnie> hoe flexible are loco's if we use canonical data centre>
<Ronnie> can we deploy our apps ourself, are there limitations, whats the connection speed in europe etc
<lifeless> theres a range of configs, really up to IS what and where
<lifeless> in terms of capabilities and performance, pretty darn good; the dc is in London
<lifeless> that said
<lifeless> uhm, you should be able to get launchpadlib on 8.04, it will just require some work
<Ronnie> lifeless: currently were thinking about staticcaly linking
<lifeless> Ronnie: well, its pytho n:)
<lifeless> you can probably backport the karmic set of packages fairly easily
<beuno> so, is it known that the page to reqeust a merge proposal is slightly broken?
<beuno> the "Other" option shows up as: "Other:'>"
<beuno> which I assume is a broken template
<thumper> beuno: yeah, I saw that today too... file a bug?
<lifeless> there is a bug open
<lifeless> its critical
<Ronnie> lifeless: again about the hosting on canonical servers. how would such thing look like. if we have problems can we fix it ourself or do we have to ask canonical-isd, and what are there response times?
<lifeless> sinzui is looking at it
<beuno> cool
<lifeless> Ronnie: I'm a poor source of info for this; #canonical-sysadmins is I think the channel for contact
<Ronnie> lifeless: spel error on channel?
<wgrant> #canonical-sysadmin
<wgrant> No s.
<Ronnie> thx wgrant
<sinzui> beuno: the fix is waiting for the rollout
<sinzui> abentley: I had a few remarks about your last branch. Maybe you have good reason to not do as I expected
<abentley> sinzui, no, mostly copying bad ideas from existing code.
<jam> i'm seeing an odd typo on the merge proposal page. https://bugs.launchpad.net/launchpad/+bug/716713
<_mup_> Bug #716713: typo in propose page <Launchpad itself:New> < https://launchpad.net/bugs/716713 >
<jam> Specifically, the "Other: "line is rendered as "Other: '>"
<jam> Looking at the HTML it looks like invalid html
<lifeless> sinzui: whats the bug number, so we can dup jams bug :)
<jam> ah, beuno, you beat me to it
<sinzui> lifeless: beuno jam: bug 714527 address the issue on the recipe and Mp pages
<_mup_> Bug #714527: owned widget structured strings render as bits of quoted html <qa-ok> <regression> <Launchpad itself:Fix Committed by sinzui> < https://launchpad.net/bugs/714527 >
<abentley> sinzui, thanks for your review.  I've pushed changes.  Diff still updating, though.
<sinzui> abentley: I approved it.
<abentley> sinzui, I saw, I just wanted to close the loop.
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<sinzui> wgrant: mumble?
<huwshimi> sinzui: Can I get you to review the colour unification stuff I've done? Not now as it sounds like you've had a long day, but when you have a chance?
<sinzui> huwshimi: I sure can
<huwshimi> sinzui: Thanks heaps.
<sinzui> I think I have done part of it already since I looked at it the other day
<huwshimi> sinzui: OK great. Would be good if you could have a quick look at the css if you haven't already.
<huwshimi> just putting together the mp
<huwshimi> sinzui: For whenever you can get to it: https://code.launchpad.net/~huwshimi/launchpad/unified-colours-710446/+merge/49316
<sinzui> thanks. I will wait for the diff to generate
 * thumper is hacking the windmill base test case class
<thumper> interesting.... windmill hanging on start at http://code.launchpad.dev:8085/windmill-serv/start.html
<thumper> sometimes only...
 * thumper wanders into the kitchen in search of food
<huwshimi> sinzui: There's 60 or 70 lines removed from style.css which is nice
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project db-devel build (357): FIXED in 5 hr 43 min: https://hudson.wedontsleep.org/job/db-devel/357/
<lifeless> wgrant: the linkification of post-filing messages is nice
<lifeless> wgrant: I'm really glad you jumped on that
<huwshimi> sinzui: I removed that line. All ok?
<sinzui> yes
<huwshimi> sinzui: Thanks :)
#launchpad-dev 2011-02-11
<lifeless> sinzui: I think you should just self-review https://code.launchpad.net/~sinzui/launchpad/bad-malone-0/+merge/49325
<huwshimi> Any ideas where the package input widget being referred to in this comment is? https://bugs.launchpad.net/launchpad/+bug/591274/comments/1
<_mup_> Bug #591274: tags field is too small <lp-bugs> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/591274 >
<wgrant> huwshimi: On an Ubuntu bug page, click the drop down arrow on the left of a row on the task table.
<wgrant> eg. https://bugs.launchpad.net/ubuntu/+source/wxmaxima/+bug/43150
<_mup_> Bug #43150: [SRU] maxima frontends fail to connect <wxmaxima (Ubuntu):Fix Released> <gcl (Ubuntu Dapper):Fix Released by wgrant> <maxima (Ubuntu Dapper):Fix Released> < https://launchpad.net/bugs/43150 >
<huwshimi> wgrant: Cheers mate
<wgrant> I wish the death-to-ZConfig policy had been seen through to completion.
<thumper> lifeless: ping
<thumper> mwhudson: ping
<lifeless> thumper: hi
<thumper> lifeless: I've got windmill hung here locally, and I want to debug where it is with gd b
<thumper> lifeless: can you help?
<lifeless> sure
<lifeless> first thing to try is strace
<lifeless> it can often be surprisingly informative
<thumper> lifeless: assume I'm a dumb code monkey
<thumper> strace how?
<lifeless> ok
<lifeless> first thing is ps :)
<lifeless> find out what processes you have
<lifeless> identify the ones we care about:
<lifeless>  - the python driver
<thumper> looking for the one running the windmill test
<lifeless>  - the ff slave
<thumper> tim      18086  1943  4 13:43 pts/1    00:00:19 /usr/bin/python2.6 -S ./bin/test --layer=Windmill -vvt TestRecipeSetDaily
<thumper> that should be the driver
<lifeless> that tells it the layer to continue from
<lifeless> it might be a child of this
<lifeless> pstree will show
<thumper> can I get pstree to show me pids
<thumper> ?
<lifeless> pstree --show-pids
<thumper> or -p
<lifeless> so if this has not spawned another bin/test runner
<lifeless> then yes, its the one that is hung
<lifeless> what version of gdb do you have installed ?
<thumper> 7.2-ubuntu
<lifeless> apt-get install python2.6-dbg
<thumper> already got it
<lifeless> gdb /usr/bin/python2.6 18086
<lifeless> thread apply all py-list
<lifeless> and threat apply all py-bt
<thumper> Could not attach to process.  If your uid matches the uid of the target
<thumper> process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
<thumper> again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
<thumper> ptrace: Operation not permitted.
<thumper> but the uid matches
<lifeless> cat /proc/sys/kernel/yama/ptrace_scope
<thumper> 1
<wgrant> thumper: >= Maverick have security settings to prevent processes from ptraceing each other.
<wgrant> sudo it.
<thumper> ack
<lifeless> or push 0 into /proc/sys/kernel/yama/ptrace_scope
<thumper> lifeless: ok, I've got gdb running and did the thread apply thingies
<lifeless> pastebin
<thumper> https://pastebin.canonical.com/43168/
<lifeless> might be slightly useful to get a thread apply all bt
<lifeless> might be slightly useful to get a thread apply all list
<lifeless> because we're getting the usual noise around python traces :(
<wgrant> sinzui: Still around?
<thumper> https://pastebin.canonical.com/43169/
<lifeless> thumper: ok, so the higher frames are new
<lifeless> opposite to pdb
<lifeless> thread one is trying to read from a socket
<thumper> ok, so how do you look for value in this?
<lifeless> thread x to switch to a thread
<lifeless> frame x to go to a frame
<lifeless> py-locals for the python locals
<lifeless> info locals for the C locals
<lifeless> thread 2 is doing a 0.25 second sleep.
<lifeless> which is zomg bad programming
<cody-somerville> lol, yea I was just looking at that.
<lifeless> thats in _wsgi_jsorpc
<lifeless> windmill runs up a server of its own for ff to talk to
<lifeless> thread 3 is doing nonblocking IO
<lifeless> inside a socketserver
<lifeless> which is a little odd.
<lifeless> at best
<lifeless> not entirely sure what its about
<lifeless> but
<lifeless> perhaps its trying to read the entire request
<lifeless> and stuck getting it
<lifeless> we should get the sockets it has open
<lifeless> thread 4 looks like its the smtp server test harness thingy
<lifeless> so threads 2 and 3 are candidates for the hang
<thumper> I don't suppose we can break a pdb into it?
<thumper> I'd like to be able to inspect the python itself
<mwhudson> thumper: pong
<thumper> mwhudson: I've got lifeless "helping" me with gdb
<lifeless> you can tell the process to evaluate some python code
<lifeless> but its a little hacky
<thumper> although I don't feel like I understand much how gdb works
<thumper> never been much for command line debugging
<mwhudson> thumper: https://code.launchpad.net/~pygdb-hackers/pygdb/trunk ?
<thumper> mwhudson: what does that give me?
<mwhudson> thumper: a back trace
<lifeless> mwhudson: have those ;)
<lifeless> mwhudson: live session
<thumper> I may have that already
<lifeless> https://pastebin.canonical.com/43168/
<lifeless> https://pastebin.canonical.com/43169/
<mwhudson> oh yeah, gdb gives you the python code these days
<mwhudson> (unreadably)
<cody-somerville> lifeless, Why isn't thread 1 a candidate for the hang? recv is blocking, isn't it?
<mwhudson> thumper: what is fd 20 for this process?
<mwhudson> (lsof -p $windmill_pid i think)
<thumper> localhost.localdomain:53395->localhost.localdomain:4444 (ESTABLISHED)
<mwhudson> netstat -tp and look for those ports?
<cody-somerville> 4444 is the http server
<mwhudson> is it talking to itself, i wonder
<cody-somerville> 53395... looks like thats from Thread 2
<thumper> tcp        0      0 localhost.localdo:53395 localhost.localdom:4444 ESTABLISHED 18086/test --layer=
<thumper> and there is one with the other order too
<cody-somerville> ugh... no line wrap makes navigating this output disorientating, lol
<mwhudson> ah yeah indeed
<mwhudson> so thread 2 is serving http, thread 1 is trying to read part of the headers from thread 2 and not getting anything?
<mwhudson> potentially
<thumper> ok, I'm going to kill everything and get some more work done now
<cody-somerville> awwww
 * cody-somerville is having fun. :-(
<cody-somerville> and I think we're close to debugging it
<thumper> cody-somerville: well, it isn't gone yet
<thumper> cody-somerville: if you want more fun
<maxb> Would someone be able to point me in the direction of the code which determines whether or not a recipe daily build is needed on a given day?
<cody-somerville> mwhudson, I think thread 3 is serving and thread 2 is either the request or the request handler
<cody-somerville> thumper, did you ever manage to get a strace?
<LPCIBot> Yippie, build fixed!
<LPCIBot> Project devel build (433): FIXED in 5 hr 40 min: https://hudson.wedontsleep.org/job/devel/433/
<mwhudson> cody-somerville: oh right yes
<mwhudson> probably right there
<thumper> Operation not permitted
<cody-somerville> thumper, sudo su and then try
<thumper> sudo strace doesn't work, do I need a root shell?
<wgrant> thumper: sudo strace does work :(
<thumper> getting the same as root
<cody-somerville> thats odd. you're on maverick?
<thumper> yep
<cody-somerville> sudo strace -p <pid> works fine for me
<wgrant> Me too.
<wgrant> On maverick and natty.
<wgrant> Hmmm.
<wgrant> Surely not.
<thumper> could it be that gdb is connected?
<wgrant> Could it be because launchpadlib loads keyring loads gnome-keyring which might forbid ptraceing?
<wgrant> No.
<wgrant> It could be that gdb is connected, I suppose.
<wgrant> An odd errno for that, though.
<mwhudson> only one process can ptrace a process at a time, i think
<mwhudson> so yeah, having gdb attached would break it
<thumper> so... most likely a race condition in windmill
<mwhudson> man ptrace says it returns EPERM in this case
<thumper> nothing I'm likely to fix today
<wgrant> mwhudson: That's a bit opaque.
<wgrant> I would have expected EBUSY.
<mwhudson> wgrant: i guess ptrace comes with a big "we hope you know what you are doing" sticker
<wgrant> Or something like that.
<thumper> detached gdb, strace said: recvfrom(20, ^C <unfinished ...>
<mwhudson> i don't know how threads and ptrace interact
<cody-somerville> If a system call is being executed and meanwhile another one is being called from a different  thread/process  then
<cody-somerville>        strace will try to preserve the order of those events and mark the ongoing call as being unfinished.  When the call
<cody-somerville>        returns it will be marked as resumed.
<mwhudson> ah yes
<mwhudson> so if there's no output, then it really is totally hung
<cody-somerville> or aren't making any syscalls at least ;)
<mwhudson> yeah, but all threads in the gdb trace were in syscalls, no?
<mwhudson> and if it's talking to itself and one thread is calling recv and nothing is calling write... it could be waiting a while
 * mwhudson wonders how easy it is to write a website that accesses the launchpad api over js
<thumper> https://code.launchpad.net/~thumper/launchpad/daily-ajax/+merge/49295 anyone?
<cody-somerville> Thread 1 is the first thread and is blocked waiting for data - it looks like its waiting for the response to a json-rpc call it made
<cody-somerville> looks like its the.... dragDropElemToAbs test its hung onn?
<cody-somerville> oh wait
<cody-somerville> maybe thats the action its asking to have performed or something
<cody-somerville> so, its actually the test_inline_recipe_daily_build test that its hung on
<cody-somerville> which happens to be the test thumper is adding in his MP, lol
<lifeless> cody-somerville: thread 1 is the thing making an http request
<lifeless> cody-somerville: its trying to read the response
<lifeless> another way of thinking about this is 'blocking w/o timeout is bad'
 * cody-somerville nods.
<cody-somerville> ah
<cody-somerville>         while not resolution_suite.resolved.get(uuid):
<cody-somerville>             sleep(.25)
<cody-somerville> ^^ that doesn't look so great.
<lifeless> cody-somerville: so thread 1 might be the cause of the hang
<lifeless> we should make that call have a timeout
<lifeless> which wouldn't fix the test
<lifeless> but it would stop a complete hang
<huwshimi> People who review things: if I want to fix several (fairly minor) bugs relating to a particular thing in launchpad but are unrelated themselves, is it better for you if I use different branches?
<sinzui> huwshimi: I think the answer is really about the cover letter and the diff
<wgrant> It's common to stick a few small changes in one branch.
<wgrant> But if they're intertwined I prefer to split them.
<sinzui> huwshimi: we often want one branch per change so that both are clear. Several small changes can be in a branch and have a clear diff
<wgrant> sinzui: Three years ago you added althostnames of 'launchpad' and 'www.launchpad.net' to most non-appserver configs. Do you recall why? Is there a good reason not to just inherit launchpad.net from the global lpnet config?
<wgrant> Er.
<wgrant> s/'launchpad'/'localhost'/
<sinzui> hi wgrant. Sorry was was away. I did not mean to be, My daughter killed pulseaudio I could not hear
<wgrant> Haha.
<lifeless> hi
<lifeless> speaking of hostname
<lifeless> AFAICT the machine hostname isn't needed in launchpad.conf
<lifeless> am I wrong?
<wgrant> Not even for nagios checks?
<wgrant> That's my presumption for why they are there.
<sinzui> wgrant: I really do not recall why I did that. I cannot think of a reason why www in in there
<wgrant> (the production configs pissed me off for the last time this morning, so I am purging cruft... I will gladly remove the althostnames from the appservers as well as non-appservers)
<cody-somerville> lifeless, it sort of looks like it already does
<cody-somerville> lifeless, would thread 2 stuck in a loop prevent the timeout from occurring in thread 1?
<wgrant> sinzui: Non-appservers need *a* hostname. But they get that from lpnet-lazr. It seems pointless to have the others (perhaps they were automatically added?)
<lifeless> cody-somerville: rarely, it *is* possible though to have a thread spinlock prevent other threads executing in python
<lifeless> wgrant: sysadmins don't know why they are there
<lifeless> wgrant: nagios can be told what hostname to use, i'm pretty sure
<wgrant> lifeless: Probably.
<wgrant> We should check the nagios config and try cowboying it out on one server, perhaps.
<sinzui> wgrant: that is certainly possible. The configs were partially built (and separated) by scripts I wrote
<wgrant> sinzui: That's what I gathered from the somewhat massive and partially insane diff.
<sinzui> utilities/lsconf is all that renames of those scripts
<sinzui> remains
<wgrant> Hrrngh.
<wgrant> (that's a "why do the production configs inherit production-specific domains from the config schema?" sort of hrrngh, FWIW)
<cody-somerville> it looks like thread 2 has added something to a queue to be executed and is now waiting for it be executed... but whats processing that queue?
 * cody-somerville realizes that its now almost 10 and so puts the windmill hang problem away for another day.
<lifeless> die ec2, die in a fire
<wgrant> Who has it killed this time?
<lifeless> no freaking way did I hit ctrl-C after 5 hours of tests
<wgrant> lifeless: You saw a KeyboardInterrupt around a windmill test?
<lifeless> mailed the output to you
<lifeless> I saw no other tests and this was a tobesuretobesure so I'm just landing directly now.
<lifeless> please don't hate me when this turns out to be a bad idea
<wgrant> Right.
<wgrant> I just land directly in that case.
<wgrant> Windmill tests hang in a subprocess, root process notices lack of activity, root process sigints child.
 * thumper looks up
<thumper> AARRGGHHHHH!!!!!!
<thumper> :((
<thumper> the lazr.restful 0.16 egg isn't 0.16
 * thumper is confused
<thumper> clucking bell
 * thumper looks for someone to smack around
<poolie> thumper, yeah, this was my thing with oauth too: 1.0 != 1.0
<thumper> it seems that the 0.16 tarball was created from a branch of lazr.restful that wasn't trunk
<thumper> is there any way to introspect the egg to see what it was created with?
<thumper> ok... so how do I make these egg things
<thumper> sdist?
<wgrant> sdist for most things.
<wgrant> Except bzr.
<wgrant> And meliae.
<wgrant> And some other stuff.
<wgrant> Try sdist. Then diff it with the old one.
<thumper> wgrant: it will create a different result, I know that
<thumper> wgrant: as it is missing at least two revisions of data
<thumper> wgrant: is there a way to add a suffix?
<wgrant> thumper: I extract the two and diff the trees to make sure they have the same files.
<wgrant> thumper: Hmmm.
<thumper> wgrant: they won't have the same files
<thumper> that is the problem I'm trying to fix
<thumper> trunk has r171 tagged with 0.16.0
<wgrant> I mean more that the tree is roughly the right shape.
<thumper> which isn't the revision that made the 0.16.0 egg in our download cache
<thumper> oh
<wgrant> Is it the revision on https://launchpad.net/lazr.restful/+download?
<lifeless> sinzui: ping
<lifeless> sinzui: or are you gone?
<thumper> wgrant: I don't suppose there is an MD5 hash of it somwhere
<thumper> duh
<thumper> I see it
<thumper> :(
<thumper> lp has: 925128c13ada9e7cbb50ae86538c6812 lazr.restful-0.16.0.tar.gz
<thumper> download cache has: 9469c4b0081ab0bd8796dc52ee1c2353 lazr.restful-0.16.0.tar.gz
<thumper> and my new one is: 7daed9cea664e564386381da320b3519 lazr.restful-0.16.0.tar.gz
<wgrant> Awesome.
<wgrant> Diff the trees.
 * thumper sighs...
<wgrant> Hopefully the first and last are identical, and you can wipe your new tarball from existence.
<lifeless> 3 tars... fark
<wgrant> Whatever you do, do not let a third file with that name leave your system :)
<wgrant> Or people from Ubuntu will hunt you down.
<thumper> ok, my one from trunk matches the launchpad one
<thumper> so at least that is good
<thumper> the download cache one is wrong
<thumper> so...
 * thumper updates download-cache
<thumper> ok, so I've update the download cache to have the correct lazr.restful
<thumper> lifeless: do you know how that'll impact rolling out?
<wgrant> Did you give it the same name?
<thumper> it is the correct 0.16
<wgrant> Yes.
<wgrant> Don't do that.
<thumper> so yes
<wgrant> It confuses things.
<wgrant> Uncommit, give it a new version number, recommit.
<wgrant> (dev systems won't ever see the changes in the new, because they have already built 0.16.0)
<thumper> :(
 * thumper uncommits
<wgrant> Just like Debian archives: do not ever use the same version twice, and if you see someone lying about version numbers, slap them.
<thumper> do the tarball names need to match the folders on the inside?
<wgrant> No.
<thumper> ok
<wgrant> You probably need to change the version number in setup.py.
<lifeless> thumper: it won't impact anything right now
<lifeless> because we've already cut the tree to deploy.
<lifeless> but it will impact the nodowntime.
<wgrant> I think nodowntime will see the new tarball.
<wgrant> as will qastaging and staging.
<wgrant> But dev/ec2/buildbot won't.
 * thumper nods
<thumper> I've fixed the download
<wgrant> Hopefully nobody saw the bad rev except me.
<thumper> lifeless: if you want to review my daily-ajax, I'll fix the versions.conf in that
<mwhudson> i wonder if we can set a hook on the download-cache branch to reject commits that change an existing file
<thumper> Getting distribution for 'lazr.restful==0.16.0-r171'.
<thumper> Installing lazr.restful 0.16.0-r171
<thumper> Caused installation of a distribution:
<thumper> lazr.restful 0.16.0
<thumper> with a different version.
<thumper> Got None.
<thumper> with make build
<wgrant> thumper: Did you change setup.py?
<thumper> arse
<thumper> no... you didn't say to!
<wgrant> 15:10:19 < wgrant> You probably need to change the version number in setup.py.
<thumper> :(
<mwhudson> er
<mwhudson> versions.cfg surely
<mwhudson> not setup.py
<wgrant> The tarball is called 0.16.0-r171, but internally versioned 0.16.0
<thumper> I changed versions.cfg, but it seems that it is expecting a differnt directory on the inside
<thumper> yes
<mwhudson> oh
 * thumper uncommits again
 * thumper read the scrollback for deryck's magic incantation
<thumper> python setup.py egg_info -b-r171 sdist FTW!
<thumper> hmm...
<thumper> perhaps I'll just submit the right lazr-restful branch directly
<thumper> as in, with a self review
<wgrant> Sounds reasonable.
 * thumper is doing so right now
<wgrant> lifeless: Can you see any reason not to drop the hostname-based althostnames?
<wgrant> nagios doesn't use them.
<wgrant> Normal requests don't.
<wgrant> I guess haproxy might?
<thumper> wgrant: want to review a branch of mine?
<wgrant> thumper: Sure.
<thumper> https://code.launchpad.net/~thumper/launchpad/daily-ajax/+merge/49295
<wgrant> aaaaaaa
<wgrant> But OK.
<thumper> wgrant: whazzup?
<wgrant> thumper: JS!
<thumper> :)
<thumper> there isn't that much actual JS
 * thumper is EODing, but will be back later
<lifeless> wgrant: we'll stage a test in a bit
<lifeless> wgrant: I'll remove them using make-appserver.py
<wgrant> lifeless: They also need to be removed from the non-appserver configs.
<lifeless> sure
<huwshimi> Does anyone know what I'm supposed to do when making changes to lazr-js stuff for launchpad? Do I need to make a branch of lazr-js directly and wait for the changes to be merged back into LP?
<wgrant> thumper did that recently.
<wgrant> But yes, fix lazr-js, then upgrade or get someone to upgrade the Launchpad version of it.
<huwshimi> wgrant: ok thanks.
<lifeless> poolie: its pretty consistently 50/50
<lifeless> poolie: its achieving that at the overcommit level - 4 threads, 4 backlogged requests
<huwshimi> Couple of reviews for someone who is kind enough to do them: https://code.launchpad.net/~huwshimi/launchpad/tag-field-length-591274/+merge/49341 and https://code.launchpad.net/~huwshimi/launchpad/tag-field-space-394342/+merge/49342
<poolie> nice
<poolie> lifeless, good to see we're not wasting mark's money having hardware sit around idle ;-)
<poolie> huwshimi, can has screenshots?
<huwshimi> poolie: Of both?
<poolie> yeah
<huwshimi> poolie: coming up
<poolie> i have this not-well-substantiated theory that attaching screenshots will be a cheap way to get better ui oversight
<poolie> (or more bikeshedding :-)
<huwshimi> poolie: Well the tag field length one is not really going to show much :)
<huwshimi> poolie: Also fixed bug #580404 but need to figure out how to get that review in lazr-js first.
<_mup_> Bug #580404: pressing enter in tags field doesn't save them <ajax> <javascript> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/580404 >
<poolie> sorry
<lifeless> poolie: https://lpstats.canonical.com/graphs/SoybeanCPU/ https://lpstats.canonical.com/graphs/WampeeCPU/ https://lpstats.canonical.com/graphs/PalladiumCPU/ https://lpstats.canonical.com/graphs/PotassiumCPU/ https://lpstats.canonical.com/graphs/GandwanaCPU/
<poolie> i thought that was a different bug
<poolie> the length will but the stray space won't, right?
<huwshimi> poolie: Yes it's a different bug... I was mostly telling you cause you reported it.
<poolie> oh, 580404 is my bug!
<poolie> thanks, that always annoys me
<poolie> and one other person apparently
<lifeless> poolie: ^ the two that are idle will be getting 'fixed' soon.
<poolie> two idle cores?
<lifeless> 4 per box
<lifeless> they are 8 core machines
<lifeless> not enough memory on one atm
<lifeless> the other we have the memory, haven't had cycles to do the reconfig
<poolie> huwshimi, so what i should have said is that i think a screenshot on https://code.launchpad.net/~huwshimi/launchpad/tag-field-length-591274/+merge/49341 would exemplify a good practice
<poolie> even if it is probably pretty obvious how it would turn out
<huwshimi> poolie: I can't attach an image directly can I?
<huwshimi> poolie: Or am I missing something
<poolie> unfortunately you need to attach it to the bug
<huwshimi> poolie: Ok
<huwshimi> poolie: https://bugs.launchpad.net/launchpad/+bug/591274/comments/2
<_mup_> Bug #591274: tags field is too small <lp-bugs> <trivial> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/591274 >
<poolie> sorry, this is probably the worst ui change to ask for this on since it's so simple
<huwshimi> poolie: Nah all good.
<poolie> that misaligned help button looks a bit naff
<wgrant> RIP facets.
<poolie> not your fault though
<huwshimi> poolie: I know. I need to think about a plan for how fix our sprite generator so that it doesn't make everything look so ugly
<huwshimi> poolie: The screenshots are probably a good idea so the reviewer can make sure they get the same thing as the commiter
<huwshimi> wgrant: Did you just pull my changes or something?
<wgrant> huwshimi: I saw the commit fly past.
<huwshimi> wgrant: Ah right
<poolie> huwshimi, unofficial +1s from me
<poolie> with tweaks on the space thing
<huwshimi> poolie: Oh right
 * huwshimi facepalms
<huwshimi> poolie: Fixed if you want to take another look
<poolie> i forget, semicolons before } are optional in js, aren't they?
<poolie> +1 now
<poolie> but i'm not an official reviewer
<huwshimi> poolie: semicolons are completely optional in js. In that case I just forgot to add it.
<poolie> so optional in the syntax but required by convention?
<poolie> i guess you can treat this as an optionally reviewed patch
<huwshimi> poolie: Yeah, few people code javascript without semicolons.
<huwshimi> poolie: I'm not sure I follow about the optional review
<poolie> i can't give you an official approval but if you wanted you could treat this as being optionally reviewed and land it anyhow
<poolie> up to you; it depends how confident you are
<poolie> or maybe wgrant's still here
<wgrant> I am still here. But I am but a code*.
<wgrant> Which MP?
<wgrant> tag-field-length-591274?
<lifeless> wgrant isn't a full reviewer yet either, but if he reviews, I'll mentor
<poolie> and https://code.launchpad.net/~huwshimi/launchpad/tag-field-space-394342/+merge/49342
<poolie> you could mentor me too, if you don't mind
 * wgrant does them.
<wgrant> lifeless: Could you also mentor https://code.launchpad.net/~thumper/launchpad/daily-ajax/+merge/49295?
<lifeless> sure, I'll cook dinner first
<lifeless> poolie: you should let bac know you want to be a reviewer; I'm happy to be your mentor
<huwshimi> Does anyone know who can review lazr-js stuff?
<wgrant> I think it's the normal LP reviewers.
<huwshimi> wgrant: Ah right thanks.
<huwshimi> Can someone review this then: https://code.launchpad.net/~huwshimi/lazr-js/autocomplete-enter-580404/+merge/49351
<lifeless> huwshimi: everything listed on https://launchpad.net/launchpad-project/ is reviewable by LP reviewers.
<huwshimi> Many thanks
<lifeless> huwshimi: some have additional reviewers on top of that
<huwshimi> lifeless: Ah right.
<wgrant> huwshimi: Both reviewed.
<huwshimi> wgrant: Cheers mate, thanks a lot
<huwshimi> wgrant: Are you changing the status or should I do that?
<wgrant> huwshimi: lifeless needs to mentor my review first.
<huwshimi> wgrant: ok right
<wgrant> 2x ui* == ui, but 2x code* < code
<lifeless> stub: btw
<lifeless> stub: you might find bug 716760 an interesting one for your when-coding time
<_mup_> Bug #716760: no measurement of in-datacentre queue timings <Launchpad itself:Triaged> < https://launchpad.net/bugs/716760 >
<poolie> huwshimi, i don't totally understand your fix to bug 580404 yet
<_mup_> Bug #580404: pressing enter in tags field doesn't save them <ajax> <javascript> <lp-bugs> <Launchpad itself:Triaged> < https://launchpad.net/bugs/580404 >
<huwshimi> poolie: So the change is that instead of checking that there is a query (i.e. someone has typed in a string) we check if there are results for the string (which includes a check for the string) otherwise the autocomplete will always capture the enter event even when we're typing in a tag that doesn't exist.
<huwshimi> poolie: Does that shed any light or am I just confusing things?
<huwshimi> poolie: Oh and another spelling mistake :(
<poolie> that makes sense
<huwshimi> poolie: My comment in the code was slightly wrong as well as the grammar mistakes (of which there were few)
<huwshimi> poolie: Just pushed those changes
<huwshimi> OK, heading off. Have a good one people.
<poolie> cheerio huw
<lifeless> spm: could you please set qastaging cron.hourly to run, well, every hour ?
<spm> crazy talk
<lifeless> I know we've load issues
<lifeless> but we have a db patch in the pipeline that needs db migration completed
<lifeless> otherwise Bad Things will happen
<lifeless> (you know the one)
<spm> btw. what cron.hourly? cronscripts/? and where?
<wgrant> Which patch?
<lifeless> wgrant: bugmessage.index
<lifeless> spm: qastaging garbo-hourly is what I meant
<spm> ah. righto.
<wgrant> lifeless: Oh, missed the 'qastaging' bit. Sorry.
<lifeless> it has the migration job for bugmessage.index, and we can't do the db constraint for bugmessage.index NOT NULL until that migration is complete.
<lifeless> wgrant: no, it is a db patch
<wgrant> lifeless: I know. But I knew it was nowhere near prod.
<lifeless> wgrant: the ui will tolerate (enough, given its qastaging) nulls being present.
<lifeless> wgrant: next week we can use the column
<wgrant> We could, alternatively, restore qastaging from today's DB dump.
<wgrant> Which already has the data.
<lifeless> we should do that too, but there is still at least one run needed
<lifeless> + the patch to ensure it needs to be live
<wgrant> Right.
<wgrant> But it has no chance of catching up without the restore.
<spm> lifeless: enabled. 13 past the hour. same as prod.
<lifeless> spm: thanks
* mthaddon changed the topic of #launchpad-dev to: Launchpad down/read-only from 09:00-10:30 UTC for a code update | https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<poolie> lifeless, just so you know, i'm still getting rejection messages regarding reviews of bzr
<poolie> bzr!
<lifeless> poolie: thats very unexpected
<lifeless> poolie: is loggerhead-team perhaps in one of the bzr teams?
<poolie> sorry
<poolie> i'm confused/tired
<poolie> it's a different problem
<adeuring> good morning
<mrevell> Hello
<poolie> hi mrevell
* adeuring changed the topic of #launchpad-dev to: Launchpad down/read-only from 09:00-10:30 UTC for a code update | https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring | https://code.launchpad.net/launchpad-project/+activereviews
<thumper> :(((
<bigjools> why so sad thumper
<thumper> my simple branch to fix the lazr.restful version to be 0.16 proper failed a bunch of tests
<thumper> due to a change that I did in lazr.restful
<thumper> to be more sensible about adding tracebacks to errors
<thumper> I'm not going to fix it tonight
<thumper> it can wait until Monday
<wgrant> thumper: The update_preview_diffs MP job still uses the update_preview_diffs config for errors, not the merge_proposal_jobs config that everything else uses. Do you know of a reason for that?
<wgrant> It's all that uses that config now.
<thumper> wgrant: no idea
 * wgrant removes the config override.
<lifeless> thumper: you did leave the prior tarball in place right ?
<thumper> yes
<bigjools> wgrant: did you look at that php-uploadprogress build with the bad dependencies that's generating 24 oopses a day?
<wgrant> bigjools: I saw it in the OOPS reports.
<wgrant> Didn't look at the build.
<bigjools> ok
<wgrant> It's going to be at the top tomorrow :)
<bigjools> yeah
<bigjools> I need to work out what caused the bad dependencies
<bigjools> whether it's a dodgy package or bad sbuild
<bigjools> talking of which, did you get the newer sbuild working? :)
<wgrant> I haven't looked at that lately. The lp-buildd branch is on LP, but the (fairly tiny) sbuild changes are not.
* mthaddon changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring | https://code.launchpad.net/launchpad-project/+activereviews
<lifeless> poolie: do you get the render times too ?
<Ursinha> morning
<jtv> hi wgrant!
<wgrant> Hi jtv.
<wgrant> Your change looks good.
<wgrant> I tried it on a couple of pockets on mawson.
<wgrant> But gave up waiting for it to finish on the release pocket.
<jtv> wgrant: thanks!  Sorry to trouble youâsomeone thought that archive publication was something to take extra care with, pah
<wgrant> I've already broken it once this evening :)
<jtv> Ahem. :)
<jtv> Julian tried it too, thought it felt quicker, but wasn't sure whether all binary files were published.
<wgrant> It only affects the dists tree, and that looked identical except timestamps.
<wgrant> We might want to try it over some larger pockets just in case.
<wgrant> But that takes forever, and I needed mawson for other things.
<jtv> Then I'm marking it as qa-ok.
<bigjools> wgrant: I pocket copied stuff from release to proposed and it published everything ok
<bigjools> 4 arches
<wgrant> bigjools: Great.
<wgrant> I published lucid-updates and diffed the dists tree.
<wgrant> All fine.
<bigjools> but a second pair of eyes is never wasteD on the publisher
<bigjools> nice
<jtv> Let's hope the other optimization comes through as nicely.
<poolie> lifeless, i do get them
<gmb> Is anyone else having trouble pulling branches from LP?
<gmb> losa ping
<henninge> gmb: yes, and pushing does not work at all for me atm.
<wgrant> gmb: We're just reverting the codehosting change.
<wgrant> Should be back in just a moment.
<gmb> wgrant: Ah, okay, cool.
<gmb> Thanks.
<henninge> thanks
<bigjools> adeuring: can I poke this in your direction please: https://code.launchpad.net/~julian-edwards/launchpad/builder-history-timeout-bug-631206/+merge/49374
<adeuring> bigjools: sure, I'll look
<bigjools> thank you
<adeuring> bigjools: the branch looks good, I think, just a minor remark: you need inner_privacy_query only for non-admin users, i.e., in the "else" parts of the "if user is None: ... elif is user_is_admin: ... else: ...". What about moving the definition of inner_privacy_query into this "else:" block?
<bigjools> adeuring: I put it there to get more width on the screen as it's less indented :)
<adeuring> bigjools: ah, right, makes sense for this monster ;)
<bigjools> indeed
<bigjools> although it would only affect one line
<bigjools> storm syntax is ....
<bigjools> thanks for looking at it adeuring
<henninge> Hi jtv!
<jtv> hi henninge!  Saw your email about the bug.
<jtv> I'm about to start on the XPI problem.
<henninge> Ah yes, thanks for the comment.
<adeuring> bigjools: and one question, more out of curiosity: There is no privacy check if packagebuild.id is None. What does this mean?
<henninge> jtv: can you re-review my branch first, please?
<jtv> oh, OK
<bigjools> adeuring: only package builds are private
<henninge> https://code.launchpad.net/~henninge/launchpad/devel-710591-importer/+merge/48682
<bigjools> s/are/can be/
<adeuring> bigjools: Ah, ok, thanks.
<adeuring> r=me
<henninge> jtv: I am not sure if I should re-submit it. I have added quite a few changes.
<bigjools> cheers
<jtv> henninge: I'm surprised :)
<henninge> jtv: Let me add a comment to explain the changes.
<jtv> Thanks, that'd help.
<bigjools> adeuring: can you mark the MP reviewed please
<adeuring> bigjools: sure, sorry...
<jtv> henninge, an unfortunate complication: when you steal a flag, you also need to set a flush order.
<henninge> jtv: you mean, whenever I change flags?
<jtv> henninge: only when you clear one TM's flag in order to set the same flag on another.
<henninge> jtv: yes, what I meant. ;-)
<jtv> henninge: this should have been a separate branch and a separate MPâ¦ you're adding a whole new script!
<henninge> jtv: yes, it was its own branch at first.
<henninge> right now I cannot really remember why I merged it ...
<henninge> the script, I mean
<henninge> my bzr-foo was insufficient to sort things out correctly ...
<jtv> henninge: better resubmit then.  The MP's documentation trail *and votes* have very little to do with the branch now.
<henninge> jtv: yeah, what I thought. I will have to do that after lunch, though. Thanks for looking into this.
<jtv> ok
 * henninge feels slightly dizzy, time to add some calories ...
<gmb> adeuring: Do you have time to review the addition of a vestigial page? https://code.launchpad.net/~gmb/launchpad/add-+subscriptions-page-bug-715802/+merge/49385
<adeuring> gmb: sure
<gmb> Thanks
<adeuring> gmb: r=me
<gmb> adeuring: Thanks.
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring, benji | https://code.launchpad.net/launchpad-project/+activereviews
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring,bac | https://code.launchpad.net/launchpad-project/+activereviews
<benji> heh, topic race
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: adeuring, benji*, bac | https://code.launchpad.net/launchpad-project/+activereviews
<bac> you won but i got the last word!
<benji> :)
<bac> good morning adeuring
<bac> benji: the review backlog doesn't look too intimidating.  you want to work through the MPs and i'll mentor them?  (as opposed to me taking some branches myself.)
<benji> sounds good
<bac> huw's looks interesting...
<adeuring> hi bac
<bigjools> benji: hello - can I talk about keyrings widya
<benji> bigjools: sure, on a call at the moment, I'll ping you when I get done
<bigjools> nae prob
<wallyworld_> bigjools: don't forget to mention that your keyring issue appears very similar to the one i had, may be a pattern there
<bigjools> wallyworld_: you bet.  Did you see it end up with a password of [0] ?
<wallyworld_> perhaps. could be. not sure
<bigjools> wallyworld_: have you got gnome desktop installed as well?  or bits of it
<wallyworld_> bigjools: yes. i need the gnome keyring for ubuntu one sso in particular
<wallyworld_> wish ubuntu one supported kde :-(
<bigjools> wallyworld_: that's a bit annoying that it has to use that :/
<bigjools> someone in the community did a port
<wallyworld_> there was an attempt, but i think it was aborted
<wallyworld_> the port was aborted
<bigjools> :(
<wallyworld_> yeah :-(
<persia> You could pick it up again ...
<wallyworld_> persia: thought about it. need some spare time though
<jtv> henninge, did you resubmit?
<henninge> jtv: almost
<jtv> losa ping
<mthaddon> jtv: hi
<jtv> whoops, wrong channel
<benji> bigjools: what's up with keyring?
<bigjools> benji: yo
<bigjools> so, I had the same problem as wallyworld_ apparently
<benji> "had" or "still having"?
<bigjools> using ec2 land, it was picking up the Gnome keyring instead of kwallet and then throwing a weird error
<bigjools> still having - it's mutated :)
<bigjools> the original error is: ConfigParser.NoOptionError: No option 'consumer_key' in section: '1'
<benji> that's familiar
<bigjools> which seems to be because the password itself is [1]
<bigjools> which is somewhat odd!
<bigjools> I deleted the password from the keyring, re-authed with launchpadlib and it puts the same thing back, which breaks next time
<bigjools> I've made a keyringrc.conf to force kwallet and I now get a different error
<bigjools> here's the conf: http://pastebin.ubuntu.com/565888/
<bigjools> and the error: http://pastebin.ubuntu.com/565889/
<benji> ok, I have a diagnostic script I asked Ian to run, but he had already (accidentally) fixed his problem by that time, I'll dig it up and see what it tells us
<benji> oh, and what does "dpkg -l gnome-keyring" report?
<bigjools> 2.92.92.is.2.31.91-0ubuntu4.1
<benji> here's the script: http://pastebin.ubuntu.com/565891/
<bigjools> I see someone cocked up the versioning :)
<benji> it sure is an odd version string
<bigjools> benji: last output is:
<bigjools> [{'item_id': 18L, 'domain': 'service', 'password': '[1]\nfoo\nbar', 'keyring': 'default', 'user': 'username'}]
<bigjools> oh arse
<bigjools> I am still configured for kwallet, let me remove that, one sec
<bigjools> benji: so now I get:
<bigjools> [{'item_id': 18L, 'domain': 'service', 'password': '[1]\nfoo\nbar', 'keyring': 'default', 'user': 'username'}]
<bigjools> looks the same :)
<benji> man, that is really odd; I expected this to be a problem with older versions of gnome-keyring and newlines in the stored value, but apparently not
<benji> and the first line of output is something like <GnomeKeyring instance>?
<bigjools> yes
<bigjools> <keyring.backend.GnomeKeyring object at 0x2479a10>
<bigjools> I'll get you a full backtrace
<bigjools> aaand now it decides to start working
<benji> pfft
<bigjools> t
<benji> you could try removing the dummy data the diagnostic script added to your gnome keyring; if it starts failing again then that's at least something
<bigjools> anyway, I still have the wallet problem
<bigjools> the backend is found ok, it doesn't seem to initialise it
<benji> let me look at the code for that bit...
<henninge> jtv: resubmitted. Thanks for your patience.
<jtv> ok
<jtv> henninge: URL?
<henninge> check your mail! ;-)
<henninge> https://code.launchpad.net/~henninge/launchpad/devel-710591-importer/+merge/49399
<benji> bigjools: using the same Python you're running keyring under, run this import and see if it succeeds: from PyKDE4.kdeui import KWallet
<bigjools> benji: I'm not sure which python it's using - it's the ec2 script so I guess 2.6
<bigjools> benji: that gives an error about kdeui not existing
<benji> I thought so.  The keyring package is taking your word that kwallet will work, when in fact it can't import the library.
<benji> That's a bug (I'll file one).
<bigjools> benji: aha
<benji> the KDE bits are apparently not installed
<bigjools> benji: mmm they should be
<benji> and I should be king of the world
<bigjools> benji: I have a /usr/lib/pyshared/python2.6/PyKDE4/kdeui.so
<bigjools> and a /usr/lib/pymodules/python2.6/PyKDE4/kdeui.so it seems
<benji> you can peek at the shebang of the ec2 script and see if you're using the same python as it
<bigjools> yeah I copied it
<benji> maybe a python path problem then?
<bigjools> most likely
<bigjools> hmm
<bigjools> it works on my other box.... (which I can't start right now because of a power cut, sorry)
<bigjools> grar netsplit
<jml> *sigh*
<jcsackett> bad day?
<jml> I'm running Launchpad locally for the first time in a couple of months.
<jcsackett> aaah.
<jml> And of course, it's not working straight away.
<jcsackett> what's the hangup? I just had to rebuild an lp dev environment.
<jml> jcsackett: well, it was a js build problem. have just run 'make clean' and am running 'make schema' now in stable so I can debug fo' realz.
<jcsackett> dig.
<bigjools> you can make -j2 for a good speedup now
<jml> bigjools: ooh, that's good to know.
<bigjools> higher numbers are slower for some reason, but thank jtv
<jml> http://paste.ubuntu.com/565909/
<jml> just got this.
<bigjools> run rocketfuel-setup lately?
<jml> and this in the logs: http://paste.ubuntu.com/565911/
<jml> bigjools: no, should I?
<bigjools> I think it added some extra hosts
<jml> hmm.
<bigjools> the openid hosts
<jml> I have testopenid.dev. Will look at rf-setup and see if it has anything new.
<jml> lots new, apparently.
<jml> I bet lots of these are cruft.
<jml> I wonder how I could tell.
<bigjools> divination
<jml> There must be a better way.
<jml> grep, perhaps.
<jml> jam: your edit on the IR implies that there's a bug in Twisted wrt ReactorNotRunning. Is there a ticket for that?
<jam> jml: not that I know of
<jam> jml:  I did file https://bugs.launchpad.net/launchpad/+bug/717205
<jam> losa ping, I'm trying to dig out the log file for the bzr-forking-server running on production.
<jam> the qastaging one is at: /srv/launchpad.net-logs/code/tellurium/qastaging-codehosting/codehosting/bzr-lp-forking-service.log
<jam> But I don't see a similar file in
<jam>  /srv/launchpad.net-logs/code/tellurium/codehosting/codehosting/bzr-lp-forking-service.log
<jml> jam: can I share that bug with other Twisted developers? (Can I make it public?)
<jam> ah, I see a crowberry/codehosting/log
<jam> jml: I didn't think I made it security private
<jam> no problem with me to make it public
<jam> I must have checked something I didn't mean to
<mbarnett> jam: yeah, that log will be from crowberry.
<jam> mbarnett: I think I was just confused by tellurium also having a "codehosting" rather than just "qastaging-codehosting"
<jam> mbarnett: is that staging- files, then?
<jam> (just not marked as such)
<mbarnett> yeah, that's staging.
<jml> jcsackett: seen this one http://paste.ubuntu.com/565920/ ?
<henninge> jtv: any questions about the mp?
<jtv> henninge: not at the moment, no
<jcsackett> jml: i saw something go wrong with min on a rocketfuel-get this morning, but a make clean && make got around it.
<jml> I'll try that again, I guess.
<jcsackett> well, if you just did it and are still in an error state...
<jcsackett> one sec, i'm rolling my devel directory back and getting again; i'll see if i get the error and then can poke it with a stick.
<jcsackett> jml: i assume you do have the file in question?
<jml> jcsackett: I did make clean; make; bzr merge ../stable; make. Trying make clean & make again.
<jcsackett> jml: dig.
<jtv> henninge: here's one question nowâwhen determining whether upstream has templates, shouldn't we ignore deactivated ones?
<henninge> hm, probably
<henninge> jtv: I'll file a bug to add that later.
<henninge> It is not very important for the current bug because we are looking at upstream projects that never had any translation activity.
<jtv> I see.
<henninge> bug 717220
<_mup_> Bug #717220: Translation sharing info should ignore deactivated templates. <upstream-translations-sharing> <Launchpad itself:Triaged> < https://launchpad.net/bugs/717220 >
<jtv> OK
<henninge> jtv: please email any further comments. I have to leave now. Sorry.
<jtv> ok
<bigjools> grrrrr hanging ec2 from windmill ....
<jml> bigjools: I haven't seen that hanging recently (although I haven't done many runs recently), and I don't know much about windmill. The way to diagnose is probably to shell in and start using unix tools
<jml> since the email you get when that happens should contain everything that the ec2 test tools know about what's going on.
<bigjools> jml: the instance is down after the email though
<jml> bigjools: yeah. you'd have to try again.
<bigjools> ok thanks
<jml> np. sorry I can't really help more.
<benji> bac: I finished the review of https://code.launchpad.net/~huwshimi/lazr-js/autocomplete-enter-580404/+merge/49351
<abentley> jkakar, I'm using a ClassAlias in Storm, with no apparent effect.  Is this a bug? http://pastebin.ubuntu.com/565962/
 * jkakar looks
<jml> g'night all
<deryck> so apparently running for i in `seq 10`; do my windmill test; done was not a good idea.
<benji> bac: another review for your review: https://code.launchpad.net/~jameinel/loggerhead/pygment-annotate-fail/+merge/49312 (there's a yo dawg joke in there somewhere)
<bac> benji: thanks
<bac> benji: would you add me as a 'code' reviewer to the ones you need me to do?
<benji> sure thing
<benji> bac: is there a way to change a reviewer type after choosing another reviewer?  I didn't type anything and now I can't even remove you to try again.
<bac> it is pretty hinky
<benji> bac: nevermind, if I add you again it overwrites the old one
<bac> as long as i'm added it doesn't matter.
<bac> great
<benji> bac: I've looked over the other reviews and they seem to be mid review with another reviewer, so I'll skip those
<bac> benji: ok
<abentley> jkakar, how's it look?
<gary_poster> benji, https://code.launchpad.net/~gary/launchpad/refactoractivitylog/+merge/49444 is ready when you are
<benji> gary_poster: cool
<gary_poster> thanks
<benji> bac: I manually applied the patch to lazr-js/build/autocomplete/autocomplete.js and ran make to rebuild icing
<benji> bac: I also talked to you in the wrong channel, that helps too
<benji> gary_poster: reviewed, only one small comment
<gary_poster> ack benji, thank you.  For single and double quotes, I generally prefer single except when I need to use double.  I needed to use double for "attribute" because there is a single in the string acting as an apostrophe.  I'll leave that as it is.  I can adjust the spacing, sure.
<benji> gary_poster: I missed that, thanks.
<sinzui> benji: bac. can either of you review https://code.launchpad.net/~sinzui/launchpad/prf-connection-0/+merge/49456
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: benji*, bac | https://code.launchpad.net/launchpad-project/+activereviews
<benji> sinzui: ooh ooh, Mr. Kotter, Mr. Kotter
<sinzui> yes horshack
<lifeless> deryck: bugs question for you
<deryck> lifeless, sure.  sup?
<lifeless> deryck: the portlet, why does it show 'new' bugs but not 'untriaged' (e.g. those in new|confirmed|undecided-importance)
<lifeless> deryck: if its oversight, do you see any issue in adding an 'untriaged' link (or even just replacing new with untriaged) ?
<lifeless> actually (new|confirmed|undecided-importance|incomplete-with-reply)
<deryck> I seem to be having connection issues.... lifeless, am I still here? :)
<lifeless> deryck: no
<deryck> heh
<deryck> ok, so untriaged....
<deryck> new has always been equated to untriaged.
<deryck> that's why the current portlet setup
<lifeless> deryck: status=new is a subset of untriaged, for Ubuntu and for us - for most of our users I suspect.
<deryck> lifeless, how are you defining untriaged?
<deryck> confirmed and/or undecided importance ?
<lifeless> new|confirmed|undecided-importance|incomplete-with-reply
<deryck> would you drop anything from the portlet, or just add those?
<lifeless> well
<lifeless> I dunno
<lifeless> to me, 'new' is uninteresting
<lifeless> I'd be interested in s/new/untriaged/ and put that criteria behind it
<deryck> so replace "new" with "untriaged" and have the untriaged link go to a list of bugs that includes the list:  new|confirmed|undecided-importance|incomplete-with-reply
<deryck> ?
<lifeless> yes
 * deryck is thinking
<lifeless> or add a row, but that seems less interesting, because its really that 'new' isn't inclusive enough
<lifeless> I'll discuss this in a wider forum when you and I are in agreement
<lifeless> basically I want to replace the two searches on https://dev.launchpad.net/BugTriage
<lifeless> there are equivalent searches in the Ubuntu docs
<deryck> for our use and I imagine Ubuntu's, this makes sense.  I'd like wider discussion to decide the fate of new.  Some folks may really like new all on its own.
<deryck> so I'm +1 on an "untriaged" link.  Whether or not it replaces "new" or sites alonside it, we need more input, I think.
<lifeless> I propose to put a blog post up and a thread on lp-users
<lifeless> https://wiki.ubuntu.com/Bugs/HowToTriage#Untriaged%20bugs
<benji> sinzui: mentored approval, bac will review my review for final approval
<deryck> lifeless, sure.  I think it would be worth pinging a couple larger users of lp beyond us and ubuntu for feedback, too.
<deryck> if reaction is limited in those two places
<lifeless> do we have a canned list of such users ?
<deryck> no, not really
<deryck> mrevell would be a good resource there
<lifeless> k
<lifeless> thanks
<deryck> np
<deryck> later on.  enjoy the weekend everyone!
<jam> lifeless: it looks like whatever is generating https://lpstats.canonical.com/graphs/CodehostingCrowberryConnections/20110210/20110212/
<jam> doesn't see the bzr processes that are spawned by the forking server
<jam> and we don't have a graph similar to that for qastaging
<jam> It is a bit hard to see
<jam> but at 10:00 and 10:30 there are no green dots in that graph
<jam> I would guess it is doing some sort of "ps" grepping, and the signature changed
<lifeless> thats possible
<lifeless> you can tell by checking the lp tuolumne branch, I think.
<jam> lifeless: more info would be good there
<jam> That is supposed to be the script that generates the graphs?
<lifeless> tuolumne is what runs lpstats
<lifeless> we have a branch of it that adds data gatherers
<lifeless> talk to a losa for the raw info
<jam> weird, the project itself isn't marked as private, but all branches for it are
<jam> only branch on lp is trunk
<lifeless> lp does not support private projects yet
<lifeless> anyhow, I'm fuzzy on this
<lifeless> I think you need to talk to a losa, or flacoste, to get more info
<jam> https://wiki.canonical.com/Launchpad/PolicyandProcess/AddLPStatsGraph
<jam> is part of the code
<jam> which talks about getting db items tracked
<jam> but lp:tuluomne-lp-configs doesn't seem to have anything like "bzr ping" stats
<jam> "There are any number of other data gathering processes that work in  different ways. All they need to do is dump data into a file in the "name:value@timestamp" format in the /srv/lpstats.canonical.com/data  directory. "
<jam> but it certainly looks like all of that isn't versioned with everything else
<lifeless> jam: like I say, /talk/ to a losa
<lifeless> I have to afk for a while [tis saturday]
<jam> lifeless: sure, but you've mentioned them about 4 times now, and you're the only one still talking here
<jam> have a good weekend
<lifeless> jam: will do, you to. They don't highlight losa in public channels or something
<lifeless> needs an explicit ping in -ops.
* benji changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: bac | https://code.launchpad.net/launchpad-project/+activereviews
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | firefighting: - | On call reviewer: - | https://code.launchpad.net/launchpad-project/+activereviews
<jcsackett> how does one push branches and test mp diffs on lp.dev?
<james_w> jcsackett, https://dev.launchpad.net/Code/HowToUseCodehostingLocally
<jcsackett> james_w: thanks. clearly my search-fu is weak this evening.
<james_w> don't know if that covers mp diffs though
<james_w> it will get you the branch, then you can propose the merge, and then run the script by hand I assume
#launchpad-dev 2011-02-12
<lifeless>       201 / 2790  Archive:+index
<lifeless>      186 /  385  BugTask:+index
<lifeless>      113 /  240  Distribution:+bugs
<nigelb> folks, troll in #launchpad
 * nigelb pokes lifeless 
<nigelb> wgrant: ^^
<wgrant> nigelb: I know, but I don't have a canonical/launchpad cloak, so I can do nothing :(
<nigelb> wgrant: Ah. about time you got one ;)
<nigelb> I asked in #freenode, don't think that did much good anyway
<wgrant> I figure that he'll give up eventually.
<nigelb> heh
<nigelb> I'm giving up looking for help.  Can't find any.
<lifeless> wooo
<lifeless> https://launchpad.net/~chromium-daily/+archive/stable/+packages down to 52 queries
<wgrant> lifeless: The queries are still nice and slow, though :(
<lifeless> wgrant: with one dimension under control, the others are attackable
<wgrant> Indeed.
<lifeless> the bug search issue has 300 waste queries
<jtv> hi wgrant, hi lifeless
<wgrant> Hi jtv.
#launchpad-dev 2011-02-13
<wgrant> Ah, the Soyuz OOPS report is a bit happier today.
<wgrant> lifeless: :(
<wgrant> Archive:+index's soft timeouts have gone away.
<wgrant> Our exception counts are 20% lower than pre-release, soft timeouts down by more than 60%.
<wgrant> Yay.
<lifeless> wgrant: cool
<lifeless>      219 /  432  BugTask:+index
<lifeless>       90 /  241  Distribution:+bugs
<lifeless> next up
<lifeless> I think Monday is 'remove substring search' day
<wgrant> Heh.
<wgrant> Hmm
<wgrant> Unbreak checkwatches, or split it into its own report?
<wgrant> The former will take quite a while, I suspect.
<wgrant> Particularly since it uses OOPSes somewhat differently to the rest of the world.
<lifeless> wgrant: unbreak
<lifeless> splitting it into its own report makes the daily report analysis harder, while not making the checkwatches component easier.
<lifeless> its a pessimism - just like having a soyuz specific report
<wgrant> Right.
<wgrant> But checkwatches is designed to use OOPSes for warnings.
<lifeless> we should get an oops when we need to take an action
<lifeless> checkwatches seems to be in a little bit of a grey area
<wgrant> Hmm.
<wgrant> We seem to have a major performance issue with update-bugtask-targetnamecaches.
<wgrant> It is again taking >18 hours.
<wgrant> I think I will delete it.
<wgrant> :( things still use it.
<wgrant> Perhaps selecting distinct targets and updating changed ones will be better and easy.
<wgrant> Well, that looks like it should take about 10 seconds.
<wgrant> Yeah.
<LPCIBot> Project devel build (436): FAILURE in 5 hr 37 min: https://hudson.wedontsleep.org/job/devel/436/
<lifeless> wgrant: what uses it?
<wgrant> lifeless: I guess search is the only thing that can't calculate it on-the-fly.
<wgrant> But tables and titles use it too.
<lifeless> grah
<lifeless> well, fix that.
<lifeless> no good reason for it to be used; we load the related objects always anyway.
<wgrant> Fix what? The non-search uses?
<lifeless> yes
<lifeless> the search use I'm going to put behind a FF tomorrow
<wgrant> Aha.
<wgrant> Then turn it off and see if anyone notices?
<lifeless> hey, why does the cache updater touch every bug? surely just 'bugs changed since the last run' is sufficient.
<wgrant> product renames, I suspect.
<lifeless> wgrant: well, turn it off for lp devs, test the improvement, then wider etc.
<wgrant> :(
<lifeless> wgrant: products have a datestamp
<wgrant> A 'when my display name was last changed' datestamp?
<lifeless> wgrant: doesn't matter
<lifeless> actually no
<lifeless> product doesn't have a mod date
<lifeless> *fail*
<wgrant> That's what I thought.
<wgrant> Most stuff doesn't.
<wgrant> The only mandatory fields are owner and datecreated.
<lifeless> ok, so product and sourcepackagename [blech - this is crazy to normalise such fields] - need a last_modified
<lifeless> and distribution
<lifeless> or
<lifeless> just ditch all use of it
<lifeless> its really uninteresting
<lifeless> I think we can remove all uses by friday, with care and caution
<wgrant> Yeah.
<wgrant> We could disable it until then.
<lifeless> new data is updated by hand, right ?
<lifeless> I mean, new bugs have a valid cache value
<wgrant> Yes.
<wgrant> I'm not sure if task moves are.
<wgrant> But I presume so.
<lifeless> woo 12365 hath landed
<wgrant> Yep.
<lifeless> hmm
<lifeless> Does staging have the render time on it yet
<wgrant> It should...
<wgrant> Even the FF should have propogated by now.
<lifeless> nope
<lifeless> https://staging.launchpad.net/+feature-rules
<lifeless> wgrant: loggerhead really needs some time
<lifeless> wgrant: jam has prepped patches to fix the biggest issues; they need review and landing
<wgrant> Ah, great. I'll have a look tomorrow.
<lifeless> that would be awesome
<LPCIBot> Project db-devel build (362): FAILURE in 5 hr 18 min: https://hudson.wedontsleep.org/job/db-devel/362/
<LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12367
<LPCIBot> included.
<LPCIBot> Project devel build (437): STILL FAILING in 14 min: https://hudson.wedontsleep.org/job/devel/437/
<thumper> morning
<thumper> tethering with Rachel's phone is working
<thumper> so I'm off to town to get a haircut :)
<lifeless> mwhudson: what is 'mkdir -p /var/tmp/vostok-archive
<lifeless> '
<lifeless> for
<mwhudson> lifeless: i think it's a DocumentRoot for apache
<mwhudson> that stuff is all stillborn though :/
<lifeless> mwhudson: also https://code.launchpad.net/~mwhudson/lp-production-configs/no-more-launchpad-loggerhead/+merge/24366
<lifeless> mwhudson: land or delete IMO
<mwhudson> oh oops, that should be landed
<mwhudson> lifeless: do we still use the production-devel and production-stable branches?
<lifeless> no
<lifeless> we deploy from stable
<mwhudson> lifeless: so the config-manager/production-{stable,devel} files can go?
<lifeless> we have a vestigial process to use production-stable if we have something that has to be embargoed all the way
<lifeless> we haven't used it in 6 months though
<mwhudson> i guess i don't need to care about those files referencing launchpad-loggerhead, anyway
<lifeless> mwhudson: also, while you are around
<lifeless> whats the deal with the different theme in lp's loggerhead
<mwhudson> at the time the idea was just to make the launchpad loggerhead blend in with the lp colour scheme a bit more
<lifeless> mwhudson: it seems to be a different colour scheme than lp itself has though ?
<mwhudson> it may have been less different once
<mwhudson> the 'codehosting orange' matches up, at least
<lifeless> codehosting oragne?
 * mwhudson realizes that that probably wasn't useulf
<mwhudson> lifeless: the colour the h1 is in on https://code.launchpad.net/~mwhudson/lp-production-configs/no-more-launchpad-loggerhead
<mwhudson> is used in the lp loggerhead theme
<lifeless> oh
<lifeless> I'd always thought the h1's were arbitrary
<lifeless> nice
<lifeless> best overall 99th percentile yet, I think
<lifeless> 2.63 - https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-categories.html
<lifeless> 6M renders
<michaelh1> Morning.  How can I register my application with login.lp.net so that I can get group membership information?
 * mwhudson listens carefully
<lifeless> losas do that
<michaelh1> lifeless: sorry, I don't understand
<lifeless> michaelh1: you need to talk to a losa
<lifeless> the operators of login.ubuntu.com
<lifeless> michaelh1: login.lp.net is just a theme on l.u.c.
 * thumper is futzing around with lazr.restful again
<thumper> tests failed on Friday
<thumper> due to the fix I did
<thumper> the tests need to be updated, as it is working now as designed
<lifeless> wgrant: around?
<wgrant> lifeless: Yup.
<wgrant> mwhudson: Except that codehosting orange's reign ended yesterday.
<lifeless> wgrant: I'm wondering if I could ask you to do the rollback for https://bugs.launchpad.net/launchpad/+bug/632847
<_mup_> Bug #632847: Bug page OOPS when viewed in deactivated project context <404> <lp-bugs> <oops> <qa-needstesting> <Launchpad itself:Fix Committed by jcsackett> < https://launchpad.net/bugs/632847 >
<mwhudson> wgrant: hence 'at the time' :)
<wgrant> What's broken?
<lifeless> wgrant: correlated subquery on every bug search by a logged in user ?
<lifeless> wgrant: back to product for disabled products - something like 5% selectivity.
<lifeless> wgrant: its madness and will break performance
<wgrant> Ah, I hadn't actually looked at the diff yet.
<wgrant> Have you tested the performance hit on qastaging?
<wgrant> Yes, it looks bad, but I'd like to have something more concrete before I roll something back.
<lifeless> ok
<lifeless> I'm going to make you an admin of ~registry on qastaging
<lifeless> and now I've removed ~launchpad from it
<lifeless> OOPS-1870QS55)
<lifeless> wgrant: I've added another comment
<wgrant> Thanks.
<wgrant> mwhudson: What do you think about https://code.launchpad.net/~mwhudson/lp-production-configs/remove-production-max_workers_per_machine/+merge/19671?
 * thumper wipes brow
<thumper> phew
<thumper> icky tests fixed
<wgrant> lifeless: Rolling it back.
<wgrant> But it'll be a couple of hours.
<wgrant> Since the queue is up to three items.
<lifeless> wgrant: thanks
<lifeless> hmm
<lifeless> I can't seem to login to qastaging with a slightly old lp lib
<lifeless> launchpad.Launchpad.login_with('hello-world', 'https://qastaging.launchpad.net/')
<lifeless> -> 404
<wgrant> That's no service root.
<wgrant> api.
<lifeless> thanks
<thumper> lifeless: 86 queries/external actions issued in 1.78 seconds
<thumper> lifeless: this is just for devs yeah?
<thumper> on the main page
<lifeless> yes
<lifeless> its controlled by a feature flag
<lifeless> thumper: do you like it?
<thumper> yep
<Ursinha> morning people
<huwshimi> Ursinha: Hello
<Ursinha> :)
<Ursinha> huwshimi, why aren't you on our team's channel? :)
<huwshimi> Ursinha: Oh
<Ursinha> I understand, we all live in the past :P
<lifeless> you have a team channel?
<huwshimi> Ursinha: yeah no-one is ever awake there :)
<Ursinha> lifeless, yes sir
<wgrant> lifeless: Hum, targetnamecache is used for sorting too.
<wgrant> I wonder if anyone ever uses that.
<wgrant> lifeless: Do you have a problem with removing targetnamecache from the UI, turning off the cron job (or maybe taking it weekly or something), and hoping that nobody notices that sort order doesn't update when they rename their products?
<lifeless> when is it used for sorting
<wgrant> When you order bug search results by location.
<lifeless> is that used?
<wgrant> Occasionally by Ubuntu.
<wgrant> Where targetnamecache never changes.
<wgrant> It could also be used in a project group context, I suppose.
<lifeless> sure it can
<lifeless> retarget source package
<lifeless> but you mean 'where the thing targeted changes value
<wgrant> Well, yes.
<lifeless> wgrant: so, I suggest a similar discussion to mine about search
<lifeless> blog + launchpad-users + microblog links
<lifeless> and/or
<lifeless> web log analysis
<lifeless> wgrant: we can efficiently support this, if its useful
<wgrant> Right.
<lifeless> if its not useful we should drop the column
<lifeless> wgrant: to answer your question
<lifeless> a) happy to switch from the targetname cache in the UI to the raw data; that or actually transition to not loading the related things at all, but that seems improbable to me
<lifeless> b) fixing the cron job is pretty straight forward, if tedious
<lifeless> wgrant: I agree we need to fix the short term pain
<lifeless> wgrant: its up to you to choose how, I think.
<wgrant> I will remove it from the UI and rewrite the script to do a batch update. Requires no model changes, should be a lot quicker, and won't take long to do.
#launchpad-dev 2012-02-06
<wgrant> wallyworld_, StevenK: You've a revision each to QA.
<wgrant> Then we can unbreak JS :)
<StevenK> wgrant: I'm distracted by Apache and convoy, but also still trying out how to QA it
<StevenK> SetEnv doesn't hit os.environ :-(
<wallyworld_> wgrant: do you know of any private branches on qas?
<StevenK> Make one
<wgrant> wallyworld_: All of lp-production-configs
<wallyworld_> right, thanks
<wallyworld_> wgrant: qa is done
 * StevenK kicks Apache, and looks at his QA.
<wgrant> wallyworld_: Thank
<wgrant> s
<wallyworld_> np
<StevenK> Mine is done too
<StevenK> wallyworld_: Jon marked my combo-url branch as Needs Information :-(
<wgrant> Great. Now we just need the DB user setup.
 * wallyworld_ takes a look
<wallyworld_> StevenK: i think a fair point is raised? rf already does sudo stuff to install apache, so it could do the new stuff as well
<StevenK> wallyworld_: You can NOT re-run rf-setup after it has run once
<StevenK> We need to handle existing setups as well as new ones
<wallyworld_> sure, but for new installs
<rick_h> StevenK: right, but for those starting from now on it could/should be there right?
<wallyworld_> +1 onwhat rick said
<rick_h> StevenK: so it seemed like a small missing automated update for the branch to be "complete"
<StevenK> New installs will just work with rf-setup
<rick_h> I was hoping he'd ok it with the request for that added, but didn't
<StevenK> Current installs need to install mod-wsgi, and run 'sudo make copy-apache-config' if they want to play with the loader
<wallyworld_> yes, and he was suggesting that be done in rf wasn't he?
<StevenK> In rf-setup?
<wallyworld_> yes
<StevenK> Like I said, we can't?
<StevenK> It is already handled in rf-setup
<wallyworld_> ok, so was the needs info request redundant?
<wallyworld_> if it's already all done
<StevenK> I have no idea, and you've confused me.
<rick_h> rf-setup already install mod_wsgi and creates the symlink directory for the convoy root?
<StevenK> rf-setup install mod_wsgi, and if I'm reading the makefile correctly, it will create /srv/launchpad.dev too
<wallyworld_> i think the above is what jon was askin for, if not done already
<rick_h> StevenK: so the answer is that it already does that. I don't think we saw it that way reading the diff
<StevenK> rick_h: Right -- it requires some knowledge of what rf-setup does
<wallyworld_> so, bottom line is that rf-setup needs to prepare a clean system to be able to run the combo loader. if it can do that,  the needs info is redundant
<rick_h> wallyworld_: +1
<wallyworld_> and we also need to the tools/make target(s)/process doc to be able to add the required symlink/whatever to an existing system
<StevenK> wallyworld_: I was going to announce that on launchpad-dev once combo-url lands
<wallyworld_> yeah, as i thought you would, just rounding out the requirements so we all understand
<wallyworld_> or agree
<StevenK> Sigh. WSGI sucks.
<StevenK> "Environment variables are too hard, so you need to deal with it in this dict
<StevenK> So to get convoy working with overriddable roots, I had to copy the inner function in combo_app :-(
<StevenK> Just returning the app didn't work, since I can't pass the environ and start_response into the inner function in combo_app.
<StevenK> And this, kids, is why nested functions are bad.
<rick_h> StevenK: huh?
<rick_h> StevenK: if you wsgi layer another app on top of the convoy wsgi app and chage convoy to pull from there no worky?
<rick_h> or we don't want to change convoy for that, it would suck
<StevenK> rick_h: WSGI layer?
<rick_h> sec, let me pull it up
<StevenK> rick_h: Using def application(...): return combo_app(root) no worky
<rick_h> StevenK: right right
<rick_h> StevenK: hmm, so I think what we'd have to do is move the app aprt out of inside of combo_app() in convoy'
<rick_h> and then we'd wrap that ourselves with our own wrapper
<rick_h> the problem is that convoy doesn't expose the raw wsgi app without the root already set
<StevenK> Right
<rick_h> that's ok thoguh, should be a small patch to convoy to get it so we can import app vs combo_app
<rick_h> and then we'd have raw access to setting root as we see fit ok
<StevenK> So we *could* change convoy to in the inside app call to set root from the environ if it's None
<StevenK> rick_h: But changing it so the inner function becomes an exportable one sounds fine too
<rick_h> StevenK: right, but I'd rather do something like tihs: https://pastebin.canonical.com/59462/
<rick_h> which is a completely off the cuff 2min take at it
<rick_h> then we'd basically change our .wsgi files to do our own combo_app with our own values and can change them as we see fit
<StevenK> Right
<StevenK> Why partial() ?
<rick_h> just because it keeps their signature all the same
<rick_h> I'm sure combo_app could be turned into some sort of decorator but that would require me to hit more docs
<StevenK> return partial(.. ? :-)
<rick_h> I jsut mean that I had to add extra kwargs to app() so that their combo_app thing works the same
<rick_h> and those values need to get passed through, since we're returning a function, not a result you'd either have to decorate it or partial it or something
<rick_h> but if I'm off let me know, I'm 3 glasses of wine into the night before bed so grain of salt and all that jazz
<StevenK> I was hoping I could just use os.environ, but I'm not that lucky
<rick_h> StevenK: well our wrapper could once the app is exposed on its own
<rick_h> but right, we're going to need to do another patch to convoy to get it there
<StevenK> We'll need to patch it before it hits qas
<rick_h> ok, well I can do that tomorrow morning if you want.
<StevenK> Because as it stands, the version in our PPA will only look in /var/tmp/convoy
<rick_h> I'm working on updating the tets and such, but that requires your convoy patch to land first so I'm stacking branches like there's no tomorrow
<rick_h> StevenK: right
<StevenK> Haha
<StevenK> rick_h: I'm happy to work off your pastebin
<rick_h> StevenK: k, if it falls apart shoot me an email and I'll pick it up come morning
<StevenK> rick_h: Okay, thanks!
<wgrant> stub: In PL/pgSQL I can INSERT from a ROWTYPE variable, but I don't seem to be able to UPDATE all fields without naming them explicitly.
<wgrant> Is there any benefit to an UPDATE over a DELETE and INSERT?
<stub> wgrant: syntax sucks there
 * stub ponders
<wgrant> I guess in 9.2 there might be (what with immutable columns and all that), but I suspect now there's no difference.
<stub> wgrant: Two statements get run - two lookups etc. The end result on disk will be the same.
<stub> Unless the only change is to unindexed columns
<wgrant> Hm?
<wgrant> Won't the UPDATE create a new tuple regardless?
<wgrant> and therefore poke the indexes the same way
<wgrant> ?
<stub> So if you update a row, and don't touch indexed columns, and the new row can be written to the same page, the indexes don't need to be rewritten.
<wgrant> Ah
<wgrant> Anyway, I guess I'll just name the columns explicitly :/
<stub> Yer. You can use dynamic SQL, but that solution sucks worse than the problem
<wgrant> Yep
<stub> Or plpython, but that will be slower due to the type casting that needs to go on
<wgrant> plpython is never the solution :)
<stub> Lots of improvements have gone into plpython in 9.1
<wgrant> Yes, but it's still terrible.
<lifeless> stub: I thought you could write to indexed columns and only the affect indices must change (and they may end up with same-page updates too, under appropriate circumstances)
<stub> "UPDATEs and DELETEs leave dead tuples behind, as do           failed INSERTs. Previously only           VACUUM could reclaim space taken           by dead tuples. With HOT dead tuple space can be           automatically reclaimed at the time of INSERT or UPDATE           if no changes are made to indexed columns. This allows           for more consistent performance. Also, HOT avoids adding duplicate index           entries."
<stub> ^^^ was what I was thinking off, pulled from the 8.3 changelog
<lifeless> hmm, I should dig up the code and check the conditions. It makes sense to me that the same core logic would allow a wider ranger of conditions.
<stub> I'm not sure about the optimization you mention
<lifeless> anyhoo, I'm not really here today ;)
<rick_h> StevenK: ping
<StevenK> rick_h: Hai
<StevenK> rick_h: Aren't you supposed to be sleeping
<rick_h> StevenK: so stupid ?, why do we need the ENV based root for convoy?
<rick_h> StevenK: yea, but I can't stop thinking about this, I don't thinkt he answer I gave you will help
<StevenK> Haha
<rick_h> and then I got wondering why we're doing this anyway
<StevenK> rick_h: I just put up an MP: https://code.launchpad.net/~stevenk/convoy/exportable-app/+merge/91601 . That should answer your question
<rick_h> because if we update convoy we can set the root to /srv/.../ right?
<rick_h> StevenK: right, but when are we going to have to change the root in the wsgi config in apache?
<rick_h> that's the part I'm missing
<StevenK> rick_h: So, asuka runs both staging and qastaging
<StevenK> rick_h: So it will have convoy installed, and the WSGI file in /usr/share/convoy/convoy.wsgi
<rick_h> and they're not the same rev/updated together?
<StevenK> rick_h: staging uses db-stable and qas uses stable
<rick_h> e.g. is there a reason they can't share the same combo loader?
<StevenK> And no, they aren't updated together
<rick_h> StevenK: ah right, ok...well @#$#@$
<lifeless> they can share the same combo loader as long as:
<rick_h> nvm then, carry on. Thanks for updating me
<StevenK> rick_h: So we need a way to inject a different root directory
<lifeless>  - we never ever do an incompatible change to it
<lifeless>  - we do something to accomodate the different revno sequence between db-stable and stable
<lifeless> the former point is probably pretty easy, as incompatible changes will screw deploys anyhow
<rick_h> StevenK: ok, so this change will do what you need? You've tested this?
<lifeless> the latter point is harder
<StevenK> rick_h: I've tested both cases of combo_app() and _application()
<rick_h> StevenK: because we're still just building a callable we return and don't actively change the root here are we?
<rick_h> StevenK: right, but I mean when you use _application in LPs .wsgi file it will listen to the ENV path as you wnt?
<StevenK> def application(environ, start_response):
<StevenK>     root = environ.get('CONVOY_ROOT', '/var/tmp/convoy')
<StevenK>     return _application(environ, start_response, root=root)
<StevenK> Our WSGI file with that change
<rick_h> StevenK: right, but that's called once when apache starts up the wsgi app
<rick_h> StevenK: so whatever one is the latest one wins? How is this passing two different roots?
<rick_h> StevenK: because we're saying one apache .wsgi file is serving both servers right?
<StevenK> rick_h: The environment variable in environ will be different for both staging and qas
 * rick_h should go to bed, probably missing something easy
<rick_h> StevenK: ok, so in apache are there one or two convoy servers running?
<StevenK> There will be two
<rick_h> StevenK: so why couldn't we pass the root kwarg to the old combp_app thing?
<rick_h> StevenK: ah I get it, the environ is where you're getting it from
<StevenK> Right
<rick_h> StevenK: so you need the app to be up first, ok, sinking in now.
<StevenK> And Apache's SetEnv does not hit os.environ
<rick_h> I was thinking a system ENV variable like os.environ
<rick_h> StevenK: right right, remember hitting that before now that you mention it
<StevenK> rick_h: Clear as mud?
<rick_h> ok, the world makes sense again, I can go back to sleep. Thanks for walking me through it
<StevenK> rick_h: I should probably thank you for the patch in the MP.
<StevenK> My guilt may not let me claim credit. :-P
<rick_h> StevenK: heh, it's ok. Consider it a freebie :P
<StevenK> rick_h: I've been in free software since 2000 -- I can't not mention you. :-P
<StevenK> It's just not done.
<rick_h> anyway, see you all again in 6hrs ish
<StevenK> lifeless: Can I nail bug 805546 shut?
<_mup_> Bug #805546: persontransferjob does not have a unique oops prefix <Launchpad itself:Triaged> < https://launchpad.net/bugs/805546 >
<wgrant> wallyworld_, StevenK: The AJAX log is still broken on production, despite the LPJS thing being deployed.
<StevenK> :-(
<wallyworld_> is that all that look broken?
<wgrant> No idea.
<stub> And all my qa done for me, ta muchly :)
<StevenK> Haha
<StevenK> wgrant: Wish I knew how to debug it
<StevenK> wallyworld_: Can haz update of the kanban board?
<StevenK> Since wgrant has gone and done the one bit I was about to
<wallyworld_> done. didn't realise you were so anal about it :-P
<nigelb> lol
 * StevenK sighs at bugs including OOPSes that have been pruned
<lifeless> StevenK: does it generate good oops ids now?
<StevenK> lifeless: PTJ? I have no idea. I thought we didn't use prefixes for oopsii at all now?
<wgrant> We really must get LaunchpadScript to inject a sensible reporter.
<lifeless> StevenK: if there is no oops prefix configured for it in the configs, then it should get a sensible one at runtime
<lifeless> as long as a) the base config its using is sane (e.g. has 'production') and b) it attempts an override, which I think the job runners all do
<StevenK> lifeless: The bug was reported when it would oops with REPORTIFSEEN
<StevenK> Can haz review? https://code.launchpad.net/~stevenk/launchpad/invalid-mp-api/+merge/91607
<StevenK> stub: ^ You're on the hook as OCR.
<stub> That will teach me for starting on time.
<StevenK> It's a very short MP
<stub> I'll just finish typing up this db review
<stub> StevenK: r=stub
<StevenK> stub: Thanks!
<StevenK> wgrant: The CommercialSubscription query is ~12ms on DF, and ~4ms when I create the index on CS.date_expires
<wgrant> StevenK: It's a small table atm, but still worth the index
<wgrant> can has explain with and without?
<StevenK> wgrant: http://pastebin.ubuntu.com/831004/ -- but it doesn't seem to use the index?
<wgrant> Ah, so the 12ms was cold?
<wgrant> And the 4ms reasonably hot?
<StevenK> Perhaps
<wgrant> Anyway, looks like there's so few rows that it doesn't even try the index, so let's not bother.
<wgrant> We'll have other problems once the table starts getting big.
<StevenK> Oh, right, Postgress will just decide to not touch the index?
<wgrant> Right. The whole table probably fits on just a page or two.
<wgrant> Using the index would double the reads.
<wgrant>  relpages
<wgrant> ----------
<wgrant>         7
<wgrant> But similar argument.
<wgrant> The index is 4 pages, so yeah, I think the planner's decision is reasonably correct.
<wgrant> stub: I wonder if a sequence column is missing from specificationworkitem
<wgrant> They presently seem to like to keep them roughly in implementation order.
<wgrant> But perhaps not.
<wgrant> Hm
<wgrant> Why is everything segfaulting...
<StevenK> Everything?
<stub> wgrant: I've added a comment re: sequence column.
<wgrant> StevenK: Well, tail still worked, but pretty much everything else I could find segfaulted in libc6 startup
<wgrant> I think x-x-v-ati was doing bad thing.
<StevenK> Yet again another reason that fglrx is a pox.
<nigelb> pox?
<nigelb> POS?
<wgrant> StevenK: Hmm? x-x-v-ati isn't fglrx
<lifeless> nigelb: http://en.wiktionary.org/wiki/pox
<nigelb> oh.lol.
<adeuring> good morning
<rick_h> morning
<jelmer> hey rick_h
<nigelb> rick_h: I find you online at the start of my day and end of my day.  Do you sleep at all? :)
<rick_h> nigelb: of course, during your day :)
<nigelb> heh
<rick_h> StevenK: still around? Is your combo-url branch updated and ready for review again?
<StevenK> rick_h: It is, yes. You can also prod sidnei to review my convoy branch.
<rick_h> StevenK: will do, ok I'll mark that branch as needs review. Thanks
<nigelb> 35
<rick_h> anyone know a trick to download all translation .pot files for a project/lang at once? https://pastebin.canonical.com/59476/ is the question
<rick_h> lp-translations-tools just seems to do multi uploads
<rick_h> and all the wiki info is about downloading one .pot at a time
<rick_h> adeuring: deryck gone through RT, new projects, POT translations, and some spam monitoring
<deryck> rick_h, ack, cool.
<rick_h> deryck: this is the first one, I wanted to go over the new templates for testing and make sure that they looked good to you: https://code.launchpad.net/~rharding/launchpad/combo_yui_tests/+merge/91478
<rick_h> so that's the updated templates and a couple of modules changed over to it
<rick_h> deryck: and this is the next big changeset https://code.launchpad.net/~rharding/launchpad/combo_yui_tests2
<rick_h> with #3 in the works as well
<deryck> rick_h, ack, will look now
<rick_h> np, heading afk
<jcsackett> sinzui: saw your notes on my MP; i've pushed up changes addressing them.
<sinzui> I have approved
<sinzui> jcsackett, about the date in the XXX: https://dev.launchpad.net/PolicyandProcess/XXXPolicy
<jcsackett> sinzui: yeah, i went looking for that after your comment.
<sinzui> I think the policy was added after we could not tell what sabdfl, kiko, and stevea meant in their comments
<jcsackett> sinzui: make sense. i've updated the wiki page too, as the date example for the python was another ambiguous case, and only became clear when you read the TAL example.
<sinzui> thanks
<jcsackett> basically, when dealing with multiple country date formats, numeric dates are problematic. :-P
<jcsackett> sinzui: do you have time to talk about bug 741234? i'm contemplating tackling that next.
<_mup_> Bug #741234: product:+code-index merge proposal queries do not show private bugs visible by assignment <disclosure> <easy> <Launchpad itself:Triaged> < https://launchpad.net/bugs/741234 >
<sinzui> jcsackett, I do
<sinzui> jcsackett, confirm you do not see this: https://bugs.qastaging.launchpad.net/gdp/+bug/864587
<_mup_> Bug #864587: compiz crashed with SIGSEGV in PrivateWindow::configureFrame() <amd64> <apport-crash> <compiz-0.9> <oneiric> <running-unity> <ubuntu> <compiz (Ubuntu):New> < https://launchpad.net/bugs/864587 >
<sinzui> and look at this : https://code.qastaging.launchpad.net/gdp
<lifeless> nigelb: so when did you want this presentation on lp thingy?
<nigelb> lifeless: heh, it was last week.
<nigelb> I completely forgot.
<lifeless> ah well :)
<nigelb> ^-^
<abentley> deryck: my QA's giving some really weird results.  Can we chat?
<deryck> abentley, sure.  let me just get coffee. was just about to do that.  and then we can chat.
<abentley> deryck: cool
<rick_h> abentley: deryck adeuring heads up, back and numb wheee
<abentley> rick_h: hehe.
<deryck> rick_h, oba-kba
<deryck> abentley, ready nowâ¦. mumble or hangout?
<abentley> deryck: mumble.
<rick_h> jcsackett: heads up, StevenK updating the MP for the convoy stuff: https://code.launchpad.net/~stevenk/launchpad/combo-url/+merge/91203
<sinzui> danhg, I am going to attempt a last minute change the interactive mockup. Many of the tests I am writing for you require a new project. I think we want a start page where you choose a young or old project so that the data looks right for the task we are testing
<danhg> hey sinzui
<danhg> OK sure
<sinzui> danhg, I think i want to change the names of the people and teams too because the nonsense is a barrier to knowing you have done the right thing. eg football teams and politicians do not on you mind when you are looking for project-related groups
<danhg> If it it is difficult to implement these changes, we could start some of the tests off with an ''imagine that this is a new project'' narrative to put testers into the right frame of mind.
<danhg> If it can be done though, that's great
<danhg> Sure, the comedy names make it seem 'less real'
<sinzui> danhg, okay. I will set a limit of 2 hours to do this.
<danhg> OK. Thanks sinzui. I'll be working most of this evening so we'll be able to talk things over later than normal.
<jcsackett> rick_h: i've replied, thanks for the heads up.
<rick_h> jcsackett: thanks
<jcsackett> sinzui (or anyone): we're supposed to be removing remove_security_proxy_and_shout_at_engineer, right? i have stumbled across a use of it and am wondering if i should replace it.
<sinzui> jcsackett, we can remove them. It is okay to remove the proxy to work with the object, but that naked object should not be return to an ignorant callsite
 * jcsackett nods.
<jcsackett> ok, that's what i thought.
<jcsackett> so when it's just a onetime use to manipulate something in a test, we're good.
<sinzui> absolutely
<jcsackett> fantastic.
<lifeless> flacoste: taking cynthia for a bit; not sure when I'll be back to keyboard, I should be on skype though if you want to ping me for our call
<jcsackett> sinzui: this test look like it's setting up the scenario we discussed? b/c it's passing, and given our test and our assumptions it shouldn't. http://pastebin.ubuntu.com/831640/
<jcsackett> i've poked at it a bit, and i think either i'm missing something or an assumption is wrong.
<sinzui> jcsackett, please wait while I stop the bank from contriving a scheme to make me default on my mortgage
<jcsackett> sinzui: sure, that sounds like a priority.
<sinzui> jcsackett, I ca talk now
<abentley> deryck: changing the feature flags didn't solve it.  Copying the remote feature flags to my dev instance didn't solve it.
<abentley> I mean Copying the remote feature flags to my dev instance didn't reproduce it.
<jcsackett> sinzui: excellent. i was briefly away, but i'm back now.
<deryck> abentley, hmmm, ok, very weird.
<deryck> abentley, I've got a call now and I can look deeper after that.
<jcsackett> sinzui: http://pastebin.ubuntu.com/831740/
<sinzui> jcsackett, http://pastebin.ubuntu.com/831747/
<abentley> deryck: I think it's from dupe detection.
<sinzui> jcsackett, do you see the linked bu on https://code.qastaging.launchpad.net/~sinzui/gdp/trunk-1/+merge/77651
<sinzui> jcsackett, https://code.qastaging.launchpad.net/gdp/+activereviews
<sinzui> jcsackett, https://code.qastaging.launchpad.net/gdp/
<sinzui> jcsackett, https://bugs.launchpad.net/launchpad/+bug/723783
<_mup_> Bug #723783: distribution and project group index pages have wrong header <confusing-ui> <distributions> <projectgroups> <trivial> <Launchpad itself:Triaged> < https://launchpad.net/bugs/723783 >
<deryck> abentley, ok, interesting.
<deryck> abentley, duplicate comment detection?
<abentley> deryck: Yes, I think I saw something about that in the bug message handling.
<deryck> abentley, that kind of makes sense.  So nothing wrong with your work per se, just the kinds of comments you posted as tests being mistaken as dupe comments?
<abentley> deryck: That's right.  Not detected locally, because a unique subject, author, bugtask & bug is used by default.
<deryck> abentley, right, makes sense
<deryck> abentley, glad you tracked it down.
 * deryck goes offline for school pick up, back soon
<abentley> deryck, rick_h: did interrupt duties: bugs, RT, questions.
<lifeless> wgrant: hey
<lifeless> wgrant: whats the status of the heat plumbing
<wgrant> lifeless: I was planning on waiting for a few days of insufficient complaints before ripping it out.
<lifeless> wgrant: doit
<lifeless> or at least, lets get the branch ready to troll
<wgrant> lifeless: Disable the max heat update code, and the aging job?
<wgrant> s/Disable/Delete/
<lifeless> yeah, and remove the flag
<wgrant> lifeless: Do you know what's happening with removing the old bug listing code?
<lifeless> deryck: ^
<lifeless> deryck: also I imagine its too late today; shall we talk tomorrow?
<deryck> lifeless, yeah, let's chat tomorrow.
<deryck> and we haven't made plans for removing the old code yet.
<deryck> how about "while we're on maintenance"
<wgrant> There's a regression which means we're still using the old code on one of the feeds.
<deryck> ah right.
<deryck> meant to add that to our board actually
<deryck> our board is kind of full right now though
<wgrant> Heh
<wgrant> lifeless: Like blueprints? :)
<wgrant> Although Linaro seems to be trying to prevent it :(
<StevenK> rick_h: Still here?
<lifeless> wgrant: blueprints is very heavily used; there hasn't been a real proposition to *remove* it, ever - but there is one to fold it into the rest of the system better (issuetracker)
<StevenK> lifeless: Please file bugs about use of sourcecode
<lifeless> StevenK: please reply to the thread and say 'yay'.
<StevenK> Bah, then I need to find the mail again
<StevenK> I will when I dig my way out of my warthogs folder
<poolie> lifeless, re policy
<poolie> i do wonder if there ought to be some at least rough calculation of bugs from a particular type of change
<poolie> i guess people do this alreday with "X is dangerous" or "Y could close many bugs"
<lifeless> poolie: that might be nice too; as jml says though, these things require knowing the future (or at least trying to predict) - so they are intrinsically harder than knowing the now.
<poolie> well, that's what i'm trying to get away from
<poolie> i'm talking about looking only at currently open bugs
<poolie> for example,
<poolie> we know removal of a moderately-used feature tends to cause about A amount of noise/complaint
<poolie> we also know having semi-working hg imports causes B amount of noise
<poolie> i can't work out how to make this very concrete though
<lifeless> interesting to think about though
<lifeless> no reason we can't evolve the policy as better rules are created / become feasible
<mabac> A general question for anyone; I have a merge proposal that is approved. Should I do something more to land the change or will that happen automatically?
<lifeless> you need an LP core dev to land it for you
<lifeless> the person that approved often will, but its best to nag (gently) here :)
<StevenK> mabac: I'm happy to land for it you, please link me the MP.
<mabac> StevenK, thanks. it's https://code.launchpad.net/~mabac/launchpad/login-raises-non-string/+merge/91265
<mabac> lifeless, thanks, that's kind of what I was going for :)
<StevenK> mabac: Please set a commit message on the MP.
<StevenK> I'll toss it at ec2, just to be safe.
<james_w> is https://lp-oops.canonical.com/?oopsid=OOPS-4cc7d8d466ed2a4569ebb00fa667f23e just me because of the number of branches my teams own?
<james_w> hi mabac!
<StevenK> mabac: Too slow. :-)
<mabac> StevenK, sorry about that. it's added
<mabac> StevenK, hmmpf ;)
<mabac> james_w, hi!
<james_w> mabac, how is connect so far?
<mabac> james_w, it's great. we miss you of course :)
<lifeless> james_w: I don't know :P
<lifeless> james_w: but I'll have a look.  You should be able to see it too...
<james_w> I did look, and that's my guess
<lifeless> james_w: do you still own all of ubuntu?
<james_w> yeah
<james_w> indirectly
<james_w> ~ubuntu-branches, which I am a member of
<lifeless> thats probably it
<james_w> I can't see any code indexes, which is mighty annoying
<StevenK> mabac: That branch is hitting an ec2 instance to run tests first. I'm not expecting any failures, but you should get a mail in about four hours from it.
<james_w> I was wondering if it was just me, as that would explain why it wasn't fixed yet
<mabac> StevenK, cool, thanks. it's not the most intrusive change I can imagine. good for me to learn the process before I get to propose any more significant changes.
<james_w> mabac, say hi to everyone
<lifeless> james_w: there is or was a bug about it
<lifeless> james_w: its nasty business to fix
<mabac> james_w, the Infra team waves back from our hacking room!
#launchpad-dev 2012-02-07
<salgado> is there a way to move a PPA from a team to another or do we need to create a new PPA and copy all the packages over?
<lifeless> new ppa + copy
<salgado> hm, ok. thanks lifeless
<rick_h> StevenK: what's up?
<StevenK> rick_h: sidnei marked my MP as Needs Fixing :-(
<StevenK> I didn't think combo_app() was actually tested.
<rick_h> StevenK: yea, it is
<rick_h> the TestApp() wraps combo_app
<rick_h> and loads it as a wsgi appliaction that gets tested in the tests/test_combo.py
<rick_h> StevenK: not sure what he wants test-wise, the current tests make sure combo_app functions, I suppose a test mounting _application in TestApp would work
<rick_h> StevenK: and yea, I kind of agree with him that it'd probably be best to not _ it if we're going to import it
<StevenK> Right
<StevenK> I also think I didn't explain it the best in the MP, if he's asking "Why do you need this?"
<rick_h> StevenK: yea, I didn't follow it either until you showed me how we were changing out code side
<rick_h> though I think that the reason of "combo_app should be able to be wrapped as a wsgi app" is enough reason
<StevenK> Right, so pasting our WSGI wrapper might help
<rick_h> StevenK: yea, at least in the MP so there's a record I guess. Technically it's the more 'correct' way anyway.
<StevenK> rick_h: I'll look at sorting it out after lunch.
<rick_h> StevenK: ok, thanks
<rick_h> I didn't see his response so sorry I didn't catch him during hte day with it
<rick_h> just ping'd to let him know we needed it and ask him to take a peek
 * StevenK tries to work out how to run convoy's test suite
<wgrant> Grarrrr
 * wgrant mauls the branch scanner
 * wgrant chainsaws the branch scanner
<StevenK> Haha
<StevenK> Whyfor?
<wgrant> It is slow.
<wgrant> It holds locks.
<wgrant> It randomly hangs.
<wgrant> It's like Soyuz, except more unreliable and with a simpler task.
<StevenK> wgrant: Can't bug 910492 be closed?
<_mup_> Bug #910492: long urls break lazr restful object representation cache <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/910492 >
<wgrant> StevenK: Done.
<wgrant>         # Bug heat increases by a quarter of the maximum bug heat
<wgrant>         # divided by the number of days since the bug's creation date.
<wgrant> wut
<wgrant> lifeless: Bug heat confuses me
<lifeless> I expect there are plentiful lies by now in the code
<lifeless> due to age
<wgrant> Ha ha
<wgrant> Hm
<spm> wgrant: while you're in a chainsawing slow services mindset, may I direct your energies towards.... checkwatches?
<spm> or have I trolled too far?
<wgrant> Hey, it hasn't hung in weeks.
<spm> is it running?
<wgrant> Unfortunately.
<spm> :-)
<StevenK> wgrant: O hai. So given https://code.launchpad.net/~launchpad/+recipe/launchpad-convoy . If I push changes to the packaging branch does that mean it will build 0.2.1-0~19-oneiric1 again?
<wgrant> StevenK: Yes
<wgrant> StevenK: The packaging revno is not included in that version template.
<wgrant> Also, why do both thumper and StevenK ask me about recipes, when it was their project :(
<StevenK> Haha
<StevenK> wgrant: What would you recommend?
<StevenK> wgrant: You know, the brain supresses bad memories ...
<wgrant> StevenK: Either commit to trunk or include the packaging revno in the template (possibly temporarily)
<StevenK> wgrant: I don't want the packaging in trunk
<wgrant> StevenK: I never suggested that :)
<StevenK> I could pull out lp:convoy, but then I/someone else has to merge lp:convoy into the packaging branch and push it
<wgrant> What about one of the options I gave?
<StevenK> I'm just not sure how/where to inject the packaging revno
<StevenK> Without screwing up upgrades
<wgrant> Let me find one of mine.
<wgrant> StevenK: https://code.launchpad.net/~wgrant/+recipe/ivle-trunk
<StevenK> Why +dr?
<wgrant> debian revision
<wgrant> It's arbitrary.
<StevenK> Right
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/stop-this-aging-nonsense/+merge/91763
<StevenK> It's over 9000!
<StevenK> (IE, r=me)
<wgrant> Thanks.
<StevenK> I thought bug heat was already done in the DB
<wgrant> The calculation is a PL/Python function, if that's what you mean.
<StevenK> Right
<nigelb> lol. stop this aging nonsense.
<StevenK> Yes. wgrant will forever be 16.
<nigelb> hahaha
<nigelb> wgrant is the Australian vampire I suppose. :P
<nigelb> StevenK: ^
<StevenK> Haha
<cody-somerville> He doesn't sparkle though.
<StevenK> Spoken like a Twilight fan
<wgrant> Heh
<wgrant> stub: Oh, didn't know that was possible. Thanks.
<stub> The planner gets to inline SQL functions into SQL queries. Not sure if it will help in this case.
<wgrant> Unlikely, since the surrounding Python is terrible.
<wgrant> But it's something.
<adeuring> good  morning
<bigjools> jml: who do we ping to get your updated testtools in the archive? Do you know who packages it?
<jml> bigjools: it gets imported from Debian, lifeless is the maintainer there.
<bigjools> jml: ok ta
<bigjools> jml: there's an ubuntu-specific version in the archive at the moment
<jml> oh really?
<bigjools> jml: 0.9.11-1ubuntu1
 * jml should really pay more attention to downstreams.
<bigjools> I haven't looked at its local patch
<bigjools> heh, debian has 0.9.11-1
<jml> "  * Build using dh_python2."
<jml> from doko
<jml> I guess it's not much of a patch :)
<jml> (incidentally, well done LP for making that easy to find out: https://launchpad.net/ubuntu/+source/python-testtools)
<bigjools> \m/
<adeuring> gmb, wgrant: could you review this MP: https://code.launchpad.net/~adeuring/launchpad/bug-829074-ui/+merge/91796?
<gmb> adeuring: Sure thing.
* gmb changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: gmb | Firefighting: - | Critical bugtasks: 4*10^2
<adeuring> gmb: thanks!
<gmb> adeuring: Just finishing another branch, but I'll get to it presently.
<gmb> adeuring: Looks good. r=me.
<adeuring> gmb: thanks!
<gmb> Welcome :)
<StevenK> adeuring: I think your change in r14748 does require QA.
<adeuring> StevenK: yes and no -- the point is that the new featrues can't be used yet. The branch just reviewed by Graham will make that easier
<rick_h> morning
<adeuring> morning rick_h
<wallyworld_> bigjools: wtf, just read that kubuntu is being killed :-(
<jelmer> wallyworld_: it no longer has a dedicated canonical engineer working on it (as was the case when riddell was on rotation to Bazaar)
<jelmer> wallyworld_: that's not quite the same as it being killed
<wallyworld_> jelmer: the net effect will be the same i fear
<jelmer> they seem to've done fine for 11.10 when jonathan was on rotation to bzr, and {x,edu,l}ubuntu seem to do fine with just infrastructure support too
<jelmer> not saying it won't have a negative impact
<stub> I think it would take much more than a single bullet to kill of kubuntu.
<wallyworld_> yeah, maybe i'm being too pessimistic
<wallyworld_> just a bit sad i guess
<bigjools> wallyworld_: not killed
<bigjools> wallyworld_: I think it's a good thing actually
<wallyworld_> really?
<bigjools> yeah, it means any criticism about it will need to be levelled at the community, not canonical
<wallyworld_> true
<bigjools> and the community will not be encumbered by anything
<rick_h> StevenK: can the combo-url land? Or we waiting on RT?
<StevenK> rick_h: We are waiting for the convoy MP.
<rick_h> StevenK: ok cool.
<StevenK> rick_h: If that lands, then I can update the convoy package, and land combo-url
<rick_h> adeuring: do you know anyone that knows translations well?
<adeuring> rick_h: jtv for example
<rick_h> adeuring: I'm trying to find some way to mass download .pot files without any success in wiki/google
<rick_h> adeuring: ok, thanks
<rick_h> jtv: ping, got a sec for a translation question? someone is asking about mass downloading all ubuntu .pot files for spanish languages?
<rick_h> jtv: I don't see any way to mass download from the wiki/webui. I see a lp-translations tools package that seems to do mass uploads though, but code doesn't seem to download?
<rick_h> adeuring: so did maint. RT, questions, translations, and new projects
<adeuring> rick_h: cool -- i sucked again :(
<rick_h> bah, missed jtv
<deryck> Morning, all.
<rick_h> morning deryck
<deryck> adeuring, rick_h -- I'd like to do a G+ hangout for our standup today.
<rick_h> deryck: sounds like a plan
<adeuring> deryck: gahh -- i still have no g+ account :(
<deryck> adeuring, see my PM to you. :)
<deryck> abentley, we're G+ hanging out today for standup.
<abentley> jcsackett, sinzui: A branch's unique name is a well-established term.  Unique names do not include the lp: prefix.
<sinzui> my apologies
<abentley> sinzui: np, just let's keep the definition consistent.
<jelmer> what's happening with bug heat?
<jelmer> I thought it was going to be removed - is it going to stay around in some form (given it has just changed)?
<jcsackett> abentley, sinzui: so do we need to roll that back?
<abentley> jcsackett: No, but you should change the function name, or else change where you attach the prefix.
<jcsackett> abentley: ok, i'll land a follow up to correct the name.
<abentley> jcsackett: thanks.
<abentley> jcsackett: You should also change the HTML so it's not called #branch-unique-name.
 * jcsackett nods
<jcsackett> seems odd unique name was ever used, as it's all about presenting the location, which incorporates the unique name but isn't the same thing at all.
<abentley> jcsackett: I don't know where this is, but it's possible the authors thought it was about presenting the name, not the location.
<jcsackett> abentley: fair. could be it was misappropriated for presenting the location later.
<abentley> jcsackett: Nope, looks like it was always presenting the name and calling it the location.
<jcsackett> right on. well, i'll be making it consistent shortly.
<abentley> jcsackett: I guess you could stick the lp: in the template.
<jcsackett> possibly, but it would have to exist outside of the node, since that gets set by the js.
<jcsackett> seems a might bit hackish.
<abentley> jcsackett: Yes, it's treating HTML as a template language.
<abentley> jelmer: https://blog.launchpad.net/general/bugheatchange
<jelmer> abentley: ah, thanks - missed that for some reason
<sinzui> danhg, talky talky time?
<danhg> Hey sinzui, I'm in the middle of MaaS tests, I should be free by 18:00 GMT?
<sinzui> okay
<deryck> adeuring, hey, any luck on those interrupt duties? (a friendly ping from one slacker to another. ;)
<adeuring> deryck: sgh... goit distracted again by working on a branch...
<lifeless> deryck: hey
<deryck> hi lifeless
<lifeless> how is your schedule to-day?
<deryck> lifeless, unfortunately, my wife ninja-scheduled me for the dentist.  and I need to leave a little early today.
<deryck> she knows I'm a baby and need her to hold my hand.
<lifeless> deryck: I take it that that is in a few minutes time? If it was say 40-50 minutes away we could do a quick call...
<deryck> lifeless, no, it's actually couple hours away still.  I'm just heads down trying to finish these hanging actions from TL call.
<deryck> lifeless, I'd really love to chat, but I don't want to be yet another day working on these "investigations" either. :)
<deryck> lifeless, how about tomorrow post TL call?
<lifeless> IIRC I was going to give you a hand with one of them
<deryck> lifeless, you gave me enough of I hand, I think.  I filed a bug this morning.
<lifeless> uhm, I have no idea, let me check (the new time has thrown out my memosied schedule)
<deryck> let me see bug number....
<deryck> lifeless, bug 928327
<_mup_> Bug #928327: codebrowse hangs due to exception/oops handling <loggerhead:Triaged> < https://launchpad.net/bugs/928327 >
<deryck> lifeless, my guess/diagnose could easily be wrong ^^ so I appreciate you looking at the bug.
<lifeless> gary_poster: we have a parallel testing biweekly thing conflicting with the TL new time
<lifeless> deryck: I have a slot *before* the tl meeting; after has my 1:1 with statik
<deryck> lifeless, that works for me better actually.  forgot about the TL call time shift.
<lifeless> deryck: why do you think oops is implicated ?
<deryck> the hang seems to be in oops_middleware
<lifeless> I don't follow - oops_middleware is in the call stack yes, but its a WSGI middleware, so it will always be so.
<lifeless> thread 11 in https://pastebin.canonical.com/59603/ is in the middle of a global GC run
<lifeless> but the other one has no GC in it, so either different cases, or not GC.
<deryck> lifeless, so I saw the threads that seemed stuck in sock_sendall had stuff happening in httpexceptions and oops_middleware....
<deryck> lifeless, so I just assumed something was hanging in dealing with an oops.
<lifeless> so this, for instance:
<lifeless> #6 0x00000000004fa67b in sock_sendall (s=0xa8e4ba0, args=<value optimized out>) from ../Modules/socketmodule.c
<lifeless> #7 0x00000000004a7c5e in call_function () from ../Python/ceval.c
<lifeless> /usr/lib/python2.6/socket.py (282): flush
<lifeless> /usr/lib/python2.6/socket.py (292): write
<lifeless> /srv/codebrowse.launchpad.net/production/launchpad2-rev-14640/eggs/Paste-1.7.2-py2.6.egg/paste/httpserver.py (123): wsgi_write_chunk
<lifeless> /srv/codebrowse.launchpad.net/production/launchpad2-rev-14640/eggs/oops_wsgi-0.0.8-py2.6.egg/oops_wsgi/middleware.py (131): oops_write
<lifeless> ?
<lifeless> deryck: ^
<deryck> lifeless, indeed.  that's what I meant.
<lifeless> deryck: ok, so the way wsgi works means that every layer that offers facilities will /tend/ to have its own 'write' callable that is passed down.
<gary_poster> lifeless, yeah I noticed
<gary_poster> lifeless, I think TL wins ;-)
<lifeless> oops_write is the callable passed from the oops middleware to the next deeper wsgi thing
<lifeless> and wsgi_write_chunk is the callable that was returned by the paste http server
<gary_poster> flacoste, lifeless, should we move parallel testing to 4PM Eastern, 21 UTC?
<lifeless> http_exceptions etc
<gary_poster> Wed still?
<lifeless> gary_poster: is that 1 hour later or something?
<deryck> lifeless, ah, ok.  Didn't realize that.
<gary_poster> lifeless, right
<lifeless> gary_poster: I have a call with statik then
<gary_poster> lifeless, doesn't parallel testing take precedence? ;-)
<gary_poster> lifeless, ok.  I'll look at schedules and make another proposal later
<lifeless> gary_poster: I'm about a month out what with budapest, sickness, the QBR.
<lifeless> gary_poster: if I hadn't missed that many 1:1's I'd say sure...
<gary_poster> lifeless, sure. np
<lifeless> but IME if you don't pin statik down with a nailgun .. :)
<deryck> lifeless, so it seems those pastes are pretty useless then, if I understand that right.  except for knowing we're stuck in socket send.  or am I missing something?
<lifeless> deryck: well, we don't know we're stuck in socket send
<deryck> ok
<lifeless> deryck: there are lots of threads, and some of them were writing content when the core was taken
<lifeless> we don't know how long they had been there
<lifeless> deryck: it *may* be that that is a smoking gun indicating e.g. network issues talking to haproxy or something
<lifeless> or it may be totally irrelevant
<deryck> ah, gotcha.
<lifeless> deryck: lets go through in some detail tomorrow, for now I've gardened the bug to have just the definitive data
<lifeless> gary_poster: +1
<gary_poster> cool
<deryck> lifeless, ok
<lifeless> deryck: note that sock_sendall is a python module, so it may well get involved in or mangled by GIL issues, bad locking etc
<lifeless> deryck: we may end up spelunking into C
<lifeless> deryck: that said, we're missing line numbers
<deryck> sounds fun :)
<lifeless> deryck: what command did you use to get the traces ?
<lifeless> deryck: and did you get missing symbol errors when you fired up gdb in the chroot ?
<deryck> lifeless, used pygdb.  and no, I don't think so.  I can look again now.
<lifeless> deryck: if you could, with regular gdb, uhm, 'thread apply all bt' and see if you get line numbers for the C frames
<lifeless> if you don't, then we haven't got the debug environment right
<deryck> lifeless, ah, yes, that is better.  line numbers indeed.
<deryck> lifeless, could have sworn I did this and didn't get anything, and then tried pystack macros which hung.
<deryck> lifeless, but may the regular bt attempt was when I was running locally still, and not in right env.
<lifeless> deryck: not to worry - you have line numbers now ;) - could you refresh the paste links in the bug ?
<abentley> gmb: are you still ocr?
<deryck> lifeless, done.
<lifeless> deryck: in bug 928327 ? I still see the old numbers.
<_mup_> Bug #928327: codebrowse hangs in production <loggerhead:Triaged> < https://launchpad.net/bugs/928327 >
<lifeless> deryck: ahha
<lifeless> deryck: mmm, cluster lag
<lifeless> deryck: the trick for the source is apt-get source python2.6 in the chroot
<lifeless> deryck: so we can see that in https://pastebin.canonical.com/59625/
<lifeless> thread 3 is in a libc call -  n = send(s->sock_fd, buf, len, flags);
<lifeless> thread 7 is in the same libc call - send()
<lifeless> the content being written looks like fairly inane annotated pages
<lifeless> mysql-5.1-wl820 in thread3
<lifeless> same branch in thread 7
<lifeless> totally different thing in thread 8 - ~dcplusplus-team/dcplusplus/dcpp-plugins/revision/3/win32/PluginPage.h
<lifeless> and it renders pretty snappily
<lifeless> thread 10 is in the python zlib module
<lifeless> I've found race conditions / bugs in it before
<lifeless> so little alerts are going off for me
<lifeless> note that it is in PyEval_RestoreThread
<lifeless> see (http://docs.python.org/c-api/init.html) - in short, this is a common place for hangs
<lifeless> it means it will be trying to get the GIL
<lifeless> now, looking down its frames, that is in knit extraction
<lifeless> so this should be safe as long as loggerhead isn't sharing the same objects across threads
<lifeless> (it may be safe if the objects are being shared, but its less of an automatic assumption)
<flacoste> gary_poster: how about at the old TL call position?
<lifeless> threads 14,13,12 10 are all waiting on the GIL
<lifeless> (determined by taking the GIL lock which the call to RestoreThread identifies and searching fo rit
<deryck> lifeless, interesting.  I had to read back a few times, but I follow now. I feel +2 times smarter now. :)
<lifeless> if you check the code for PyEval_RestoreThread you can see how I got the GIL lock just from the backtrace
<lifeless> because the only lock it tries to get is the GIL
<lifeless> thread 11 is doing a GC
<lifeless> this means thread 11 holds the GIL
<lifeless> the threads that are in sock_sendall have released the GIL
<lifeless> (line 2723 in socketmodule.c is wrapped in Py_BEGIN_ALLOW_THREADS / Py_END_ALLOW_THREADS
<lifeless> again - see http://docs.python.org/c-api/init.html - that means they have released the GIL
<lifeless> so thats all the threads
<lifeless> the other threads have noise in their stack
<lifeless> I *suspect* they are killed threads by the paste thread killing code
<lifeless> e.g. dead but not joined yet
<lifeless> now, if the server has been attempted to shutdown
<lifeless> but hasn't gone
<lifeless> this would explain why there is no main thread visible
<lifeless> (thread 1 shows
<lifeless> Thread 1 (Thread 27332):
<lifeless> #0  0x00002b34765e5ebc in ?? ()
<lifeless> #1  0x0000000000000000 in ?? ()
<lifeless> )
<lifeless> deryck: ^ probably need to ask webops for the exact sequence of events leading up to the core to validate that theory
<lifeless> if we can validate the theory then we can make an interesting observation
<lifeless> which is that the listen event loop *has* shutdown properly; what is missing is cleanup of these other threads
<lifeless> which cannot happen until garbage collection completes
<deryck> lifeless, right
<lifeless> well, not properly :P
<lifeless> there are 2 threads in sock operations, 4 threads waiting for the gil (and apparently fine otherwise) and 1 in gc with nothing sensible higher up its stack
<lifeless> thats a total of 7, but we'd expect 10 worker threads IIRC, plus mainloop
<lifeless> so I strongly suspect a SIGINT or something already sent
<lifeless> now, lets peek at the other core
<lifeless> thread 4 is in sendall
<lifeless> as is 9, same spot as they have all been
<lifeless> thread 12 is taking a threading lock
<lifeless> lets see
<gary_poster> flacoste, sorry, just saw this.  The old team lead call time is fine with me, but I thought lifeless would prefer not to meet that early.  The later we make it, the less likely Europeans from my team can attend, and the easier it is for lifeless, AFAIK.
<lifeless> gary_poster: I can attend at that time, but we'll have to boot deryck :)
<lifeless> gary_poster: who claimed that spot like a flash, before
<gary_poster> lifeless, heh
<gary_poster> um
<gary_poster> ok, I'll go look at the calendar...
<lifeless> deryck: you'd be ok ~ this time on your thursday ?
<deryck> I'm more Batman than Flash.  are we talking about me? :)
<gary_poster> heh
<deryck> lifeless, sure.
* abentley changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2
<lifeless> ok, so deryck if you move your one +24 hours or so, and gary_poster you can move the paralleltests one an hour earlier.
<deryck> lifeless, done!
<gary_poster> thank you lifeless & deryck
<lifeless> deryck: thread 12 looks like its the implementation for a threaded queue or something (haven't checked the .py source yet)
<gary_poster> flacoste, done on calendar
<lifeless> deryck: so its not going to be the gil that its waiting ok - in fact it has just released the gil (see threadmodule.c line 46)
<lifeless> deryck: it looks like it is waiting for another request to service, judging from the call stack
<lifeless> thread 13 is running some code *I think*
<lifeless> the python integration blew up though (frame 0 is the fail)
<lifeless> so we need to check the source to see if it holds the GIL
<lifeless> and indeed, line 943 is in the middle of the big opcode jump case statement
<lifeless> so, thread 13 holds the gil
<lifeless> and is processing a knit repository, which the other inventory access in the other core was doing as well
<lifeless>  /~starbuggers/sakila-server/mysql-5.1-wl820/view/head:/plugin/java_udf/java_context_test.cc is the file
<abentley> deryck, rick_h: Interrupt dutes done in less than an hour.  Went down the whole list.
<lifeless>  /~starbuggers/sakila-server/mysql-5.1-wl820/view/head:/plugin/java_udf/grokjni.pl was the inventory content the other core was doing
<deryck> abentley, nice!  I'll look forward to mine in an hour then. :)
<rick_h> abentley: rocking
<rick_h> deryck: coat tail rider :P
<lifeless> so, weak correlation there
<deryck> rick_h, now you've finally figured me out.  oh no, my secret is exposed! :)
<lifeless> thread 14 is another waiting-for-a-request
<lifeless> as is 15,16,17
<deryck> lifeless, ah, so dealing with the same objects in different threads.  did I understand that right?
<lifeless> 18
<lifeless> deryck: no, no indication of that yet; was noting that the same branch is being accessed from each core
<lifeless> so there may be something to do with that content
<deryck> lifeless, ok
<lifeless> its also a 'knit' format branch which is bzr < 1.0's native format
<lifeless> I think, or something in that general area
<lifeless> 18 is waiting for a request
<lifeless> 19 and 20 too
<lifeless> 21 is waiting for the GIL
<lifeless> and its the actual mainloop - note the serve_forever () and the PyMain at the top of the stack
<lifeless> Py_Main I mean
<lifeless> deryck: I think https://pastebin.canonical.com/59626/ has two different bt's in it, its a little confusing
<lifeless> yeah, definitely does
<lifeless> my info is ok, because I started at the bottom which was indeed the other set of bt's
<lifeless> anyhow, what does this mean
<lifeless> 12,14,15,16,17,18,19,20 are workers waiting for a request, 21 is the mainloop, 13 is doing work - thats 9 waiting, one mainloop and one worker working
<lifeless> so this second core looks totally healthy and unstuck
<lifeless> threads 9 and 4 are a little worrying - that send() behaviour
<lifeless> but they don't hold the GIL
<deryck> did I cut-n-paste wrong or something, to get different bt's?  I thought I just scp'ed gdb and pasted straight as is.
<deryck> gdb.txt, I meant.
<lifeless> there is nothing, assuming thread 13 would come alive again, stopping the healthy workers from serving more requests
<lifeless> deryck: https://pastebin.canonical.com/59626/ and https://pastebin.canonical.com/59625/
<lifeless> deryck: compare the first four lines
<lifeless> deryck: and then the bottom four lines
<lifeless> the bottom four lines of 59625 appear in the middleish of 59626
<lifeless> deryck: so, the core with happy workers has only one real issue and thats a busy thread; its possible that that isn't releasing the GIL for some reason, but just regular bzrlib code *should* give other threads timeslices
<lifeless> deryck: were both cores taken from hung loggerheads? How was hung determined ?
<deryck> lifeless, that's a webops question.  not sure.  I can ask them.
<lifeless> deryck: the mysql urls in question both render near-instantly for me
<lifeless> http://bazaar.launchpad.net/~starbuggers/sakila-server/mysql-5.1-wl820/view/head:/plugin/java_udf/grokjni.pl and http://bazaar.launchpad.net/~starbuggers/sakila-server/mysql-5.1-wl820/view/head:/plugin/java_udf/java_context_test.cc
<lifeless> deryck: so, you may want to copy some of this to the bug; the bad news is I see now reason for the second process to appear hung, and the first process appears to have had its mainloop killed (e.g. via the OOM killer, manual SIGINT, whatever) and that *will* stop it serving.
<lifeless> deryck: we now need to track down more data around the state of both of the cores, to see if we can infer anything else.
<lifeless> deryck: I hope this has helped!
<deryck> lifeless, I really don't mind copying this too the bug.  but it's a lot of text.  Would it be better for you to just summarize this briefly there?
<deryck> just so I don't mis-represent.
<lifeless> one core has damaged (I suspect killed but not joined()) threads including a missing mainloop. The missing mainloop would on its own make it appear dead to haproxy.
<lifeless> It is in gc in another thread; one possible theory is it got too big memory wise and what we are looking at is damaged fallout from some attempt to recover it
<lifeless> the other core appears entirely healthy except for the oddness that stuff is stuck in send(); but that is normal if the OS buffer is full, which will happen if the internets are not brilliantly happy (because buffering affects the entire chain)
<lifeless> so we need to know for the first one, as much as we can about how it got to that state - were any sysadmin interventions applied first? (if so, the core doesn't represent the failure, it represents the failure + mangling)
<lifeless> for the second, we need to know the symptoms that were being reported
<lifeless> deryck: I suggest putting the transcript in an attachment for folk wanting to check the workings
<deryck> lifeless, done
<lifeless> cool
<lifeless> and now, breakfast.
<barry> sinzui: is there anything we can do to fix private mailing list archive access? :(
<lifeless> barry: isd have a fix
<lifeless> barry: it is 'in deployment'
<barry> lifeless: excellent, thanks
<sinzui> lifeless, since when.
<sinzui> barry, lifeless bug 663923 give no indication there is a fix available
<_mup_> Bug #663923: Cannot view list archive of private team <escalated> <mailing-lists> <ml-archive-sucks> <regression> <Apache OpenID:In Progress by mars> <Launchpad itself:In Progress by mars> < https://launchpad.net/bugs/663923 >
 * barry subscribes
<sinzui> I still believe grackle will be deployed and that bug will be fixed
<barry> sinzui: what's grackle?
<sinzui> barry, the archiver we are writing
<barry> ah, right.  do you mean once grackle is deployed, you won't need the openid dance?
<sinzui> correct
<barry> cool
<barry> that'll be nice
<barry> heck,  i might even switch to grackle in mm3
<sinzui> barry, possibly. I think Cassandra should be a choice rather than a requirement. We can written an almost complete memory store implementation that could be subclassed to implement a sql or simple mbox implementation
<sinzui> s/We can written/We HAVE written/
<barry> nice.  what's the status of it?  is code available?  is it functional yet?
<abentley> barry: We started work on it at the Thunderdome, but I haven't been involved since.
<barry> where are the branches? :)
<abentley> barry: lp:grackle
 * barry branches it for later
<sinzui> barry, I need one more day to complete the client. We can them complete the server in a  few days
<sinzui> barry, all the code is in trunk https://code.launchpad.net/grackle
<lifeless> sinzui: since the ISD weekly report
<barry> thanks.  i will definitely keep my eye on it
<mars> sinzui, it is also in my team's goals for Q4
<sinzui> mars, thanks
<lifeless> sinzui: are you on isd-announce?
<sinzui> no
<lifeless> sinzui: I'm not sure how to get you on it; but it does have a aweekly summary of what ISD are up to that may be informative
<sinzui> lifeless, I do not need to be more involved. This issue will be closed  soon
<lifeless> sinzui: bug 928391
<_mup_> Bug #928391: ProgrammingError creating new team <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/928391 >
<lifeless> sinzui: I think that that might be something your squad knows aboot
<sinzui> lifeless, i learn about it an hour ago.
<sinzui> My team will fix it
<lifeless> kk
<deryck> dentist time, yuck
<abentley> rick_h: have  you closed bug #294656  ?
<_mup_> Bug #294656: Every page requests two JavaScript libraries (remove MochiKit) <javascript> <lp-bugs> <lp-translations> <lp-web> <tech-debt> <Launchpad itself:Triaged> < https://launchpad.net/bugs/294656 >
<rick_h> abentley: ah, sorry. Guess that never got linked to the branch. Yea, mochi is done and gone
<wallyworld_> sinzui: https://pastebin.canonical.com/59655/
<wgrant> fuuuu
<wgrant> <unprintable Unauthorized object>
<wgrant> From the isd team creation forbidden
<jelmer> g'morning wallyworld_, wgrant
<wallyworld_> jelmer: g'day
<sinzui> wallyworld_, are you running tip? I see what looks like a fix: https://code.launchpad.net/~bzr-pqm-devel/bzr-pqm/devel
<wallyworld_> sinzui: no, just whatever a default precise install provides. i'll try tip, thanks
<wgrant> Morning jelmer.
<wgrant> StevenK: Bug #928440
<_mup_> Bug #928440: When attempting to create a new team, I'm told I am "Not allowed here" <fallout> <regression> <Launchpad itself:Triaged> < https://launchpad.net/bugs/928440 >
<wgrant> See my comment
<sinzui> wallyworld_, or revert to -r 80.
<wallyworld_> sinzui: tip still breaks, so will try that rev
<sinzui> wallyworld_, the branch is in ec2 now
<wallyworld_> sinzui: and rev 80 breaks too. i need to see where RemoteBranch lives
<wallyworld_> thanks for landing
<wallyworld_> sinzui: the issue is the version of bzrlib
<sinzui> wallyworld_, yes, I think I am using the system lib
<wallyworld_> sinzui: makes sense. i am using the one from lp-sourcedeps
<wgrant> lifeless: Shall I start landing my heat incineration branches?
<lifeless> wgrant: yes
<lifeless> noone has flamed us AFAICT
 * thumper flames lifeless
<wgrant> That was my thinking
 * thumper flames wgrant and wallyworld for good measure
<wgrant> Uhoh
 * thumper leaves again
<wallyworld> thumper: what have i done this time?
<thumper> wallyworld: I'm sure you know...
<wallyworld> thumper: well, it could be one or soooo many things
<wallyworld> s/or/of
<wgrant> lifeless: Does this count as removing complexity to offset disclosure? :P
<lifeless> wgrant: I can see we're going ot have fun with that
<lifeless> disclosure is offsetting user ticket complexity and performance suckiness too
<wgrant> It is
<wgrant> I am trying to respect the 5s rule with bug searches.
<wgrant> As much as I can.
<lifeless> anyhow
<lifeless> heat was signed off on by stakeholders including ubuntu, for the changes effective monday
<lifeless> I see no reason to wait an extended period
<wgrant> Sure.
<wgrant> The stakeholders aren't the only stakeholders, but indeed the outcry seems to be nonexistent.
<lifeless> wgrant: btw
<wgrant> Which is as I expected.
<lifeless> wgrant: you can't delete the garbo job straight away
<wgrant> Oh?
<wgrant> (he says, as he Ctrl+Cs the lp-landing of the garbo job removal)
<lifeless> exercise for the reader. You will facepalm.
<lifeless> tell me if you timeout ;)
<lifeless> rick_h: is bug 928500 your work?
<_mup_> Bug #928500: 'Series and Milestones' graph not loading - LPJS is not defined <graph> <javascript> <latency> <loading> <lpjs> <milestone> <series> <Launchpad itself:New> < https://launchpad.net/bugs/928500 >
<wgrant> lifeless: I don't see the issue.
<lifeless> wgrant: we are changing the rule for heat calculation to not include age.
<lifeless> wgrant: what process will we use to update bugs that *are not changed* to use the new rule ?
<wgrant> lifeless: I decided that we don't care enough.
<wgrant> Do we?
<lifeless> Well, if we can point any-and-all 'wtf' bug reports to you, sure.
<lifeless> I think its pretty cheap to let the garbo do one full scan post-heat-calculation-change, and it ensures that it is all consistent
<wgrant> Then I'll mark the bug as affecting and then not-affecting me, and then say "wtf" back because the value is correct :)
<wgrant> But true.
<wgrant> So, I guess I'll put the DB patch in a separate pipe and do that first.
<lifeless> \o/
<wgrant> lifeless: Hm,
<wgrant> lifeless: Except that the updater never completes.
<wgrant> Bug #906193
<lifeless> wgrant: I'm pretty sure it is incremental
<wgrant> Probably better to do a one-off
<_mup_> Bug #906193: BugHeatUpdater never completes <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/906193 >
<wgrant> It's not
<wgrant> Oh
<wgrant> I guess it is
<lifeless> the warning was bogus, last I looked at it
<lifeless> it doesn't do a full scan in 1 hour
<wgrant> Yeah, true.
<wgrant> It probably never catches up, though.
<wgrant> Anyway, will land the DB patch without the garbo dropping.
<lifeless> let me check ze code
<lifeless> wgrant: so yeah -
<lifeless>     def _outdated_bugs(self):
<lifeless>         outdated_bugs = getUtility(IBugSet).getBugsWithOutdatedHeat(
<lifeless>             self.max_heat_age)
<wgrant> But it seems to never finish.
<wgrant> Which means it is behind.
<wgrant> It's incremental, but probably never catches up.
<lifeless> your new function should be cheaper
<wgrant> I suspect it's better just to do a one-off four-line script to update everything.
<wgrant> It is about 5 times cheaper, true.
<lifeless> I don't have an opinion; script is fine if thats what you think is best
<lifeless> my reading of the code is that the heat updater will, on each run, do the lowest-id N older-than-X bugs
<lifeless> this could be always be behind but still hit everything
<wgrant> It does, yes.
<wgrant> Oh?
<wgrant> What if the first hundred thousand bugs get updated regularly?
<wgrant> The top 800000 never will
<lifeless> so lets say it takes Y days to become stale
<lifeless> mm, rephrase
<lifeless> runs hourly
<lifeless> in one hour, it does N bugs
<lifeless> if the number of bugs *becoming stale* per hours is greater than N
<wgrant> I wouldn't expect it to be, but it looks like isDone is never hit.
<wgrant> Which suggests that it is.
<lifeless> then after X days, it will have to do the first N again, and you'll have a loop over 24*Y*N bugs
<lifeless> any bug updated for other reasons within that Y period will perturbate the loop and get other bugs updated.
<lifeless> anyhoo; shrug. Like I say, choose the best use of your time w/curtis, and have fun.
#launchpad-dev 2012-02-08
<rick_h> lifeless: looks like it is my work. will fix that up
<StevenK> rick_h: So, Sidnei explained himself, and I've rejected my convoy MP.
<StevenK> rick_h: So I'll be sorting out combo-url today, after I fix a critical regression. That I caused. :-(
<rick_h> StevenK: yea, saw that. Does his stuff work then?
<rick_h> StevenK: ouch, gotcha
<StevenK> Seems to, yes.
<rick_h> StevenK: cool, very nice then
<lifeless> StevenK: for my edification, whats the MP url ?
<StevenK> lifeless: Which MP?
<lifeless> the convey one
<lifeless> I'd like to see what sidnei has proposed
<rick_h> lifeless: https://code.launchpad.net/~stevenk/convoy/exportable-app
<rick_h> he's right, I should have seen it, but got hung up on the wsgi callable args
<StevenK>     root = environ.get('CONVOY_ROOT', '/srv/launchpad.dev/convoy')
<rick_h> Sorry I led you around the fence there StevenK
<StevenK>     app = combo_app(root)
<StevenK>     return app(environ, start_response)
<StevenK> That ^ works
<rick_h> right
<lifeless> heh
<StevenK> rick_h: I'll be splitting the setup.py changes into a seperate MP, but they are only a would be nice.
<wallyworld> sinzui: i'm having trouble reproducing the badge issue on lp.dev. i created a private bug, linked to a branch, assigned bug to foo, in a separate browser logged in as foo, went to code page, and badges were visible. i restarted lp and badges were still visible
<wgrant> wallyworld: foo being name16, the admin?
<wallyworld> no, name12
<wgrant> Hmm
<wgrant> What about no-priv?
<wallyworld> let me try
<wgrant> name12 does have some privs.
<wgrant> owns some projects, IIRC
<wgrant> May even be in ubuntu-team
<rick_h> StevenK: cool
<wallyworld> wgrant: sinzui: assigning to no-priv seems to reproduce it
<wallyworld> wgrant: btw, what happened to the password when logging in on lp.dev?
<wgrant> wallyworld: I deleted passwords
<wgrant> LP doesn't know about passwords any more.
<wgrant> So I removed the field.
<StevenK> And deleted the code. \o/
<wgrant> And DB tables.
<wallyworld> ok. so sso is the service that prompts for pw?
<StevenK> On prod? Yes
<wgrant> Yep
<wgrant> LP's AccountPassword table has been sitting around with old data since April 2010.
<wgrant> Basic auth even still worked with the old passwords :)
<wallyworld> sinzui: found the issue. added comment on the bug
<sinzui> wallyworld, great news. Thank you for taking a look into the issue.
<wallyworld> sinzui: np. it's all a mess - there's duplicated code that "does the same thing" from 2007 and 2009
<sinzui> You get to delete lines. We should get karma for deleting lines of code instead of adding features
<wallyworld> sinzui: i have a fix and test i could land but i think i'll delete the dup code. i'm worries about the sql though since one codebase uses permissions and the other direct queries. i'll look into it
 * wallyworld has just got a call from the mechanic - have to pop out to get car looked at 
<StevenK> wgrant: Hai. I *think* I have it working. Would you mind eyeballing my diff?
<StevenK> How does this even work? The mutator method isn't on the model.
<wgrant> StevenK: The mutator method is on the model...
<StevenK> I've declared it on the interface, with the decrations.
<wgrant> You declare it there, but the method itself is on the model.
<StevenK> Right. What I'm saying is my test passes, but I haven't even written the method yet.
<lifeless> StevenK: I think wgrant is trying to say 'interface methods never ever ever actually get called'
<StevenK> Perhaps the set_attributes="visibility" is wrong wrong wrong.
<wgrant> StevenK: The mutator is to prevent unauthorized transitions.
<StevenK> wgrant: http://pastebin.ubuntu.com/833450/
<wgrant> StevenK: Right. I would add visibility to IPersonEditRestricted.
<wgrant> StevenK: And add a test to confirm that a mortal without commercial subs can't set the visibility through the API.
<wgrant> Erm, no, not that interface
<wgrant> Do it however the rest of the launchpad.Edit-write-restricted attributes are done.
<StevenK> I thought that was IPersonEditRestricted
<wgrant> Maybe it is.
<StevenK> from lp.services.verification.model.logintoken import LoginToken
 * StevenK glares at his mouse
 * wgrant banishes bug search to a separate module.
<StevenK> Could you perhaps banish it to something outside of the code base?
<nigelb> heh
<StevenK> wgrant: http://pastebin.ubuntu.com/833507/ is what I have so far, but it doesn't allow anyone to check visibility
<wgrant> StevenK: Looks like a good start
<wgrant> Ah, Launchpad.
<wgrant> IBugTask has three methods which do similar but not quite the same thing for different targets: getStatusCountsForProductSeries getBugCountsForPackages getOpenBugTasksPerProduct
<james_w> http://lpqateam.canonical.com/qa-reports/deployment-stable.html looks rather odd, are parts not updating>?
<wgrant> james_w: What's odd?
<james_w> it's saying that a revision can be deployed that already has
<james_w> and that an undeployable revision has been deployed?
<wgrant> Right, that's the last revision that can be deployed.
<wgrant> Deployed to qastaging, yes.
<james_w> or is qastaging not the target?
<wgrant> That page shows things that are on qastaging but not on production.
<james_w> ah, ok
<wgrant> qastaging automatically updates about 40 minutes after buildbot blesses a devel revision.
<james_w> "Revision 14747 can be deployed to production." is what started my confusion
<james_w> it looks like 14747 is *already* deployed to production?
<wgrant> Right.
<wgrant> But it also can be deployed :)
<james_w> ok :-)
<james_w> do you know where the code for this lives?
<wgrant> lp:qa-tagger
<james_w> thanks
<wallyworld> lifeless: would you be adverse to me adding a permission "launchpad.CommercialSubscriber"?
<wgrant> wallyworld: That's not needed here.
<wgrant> wallyworld: Since you have project scope to work with.
<wgrant> launchpad.Edit with a mutator checking that there is a commercial subscription is fine.
<wallyworld> wgrant: we currently have a declarative permission check on that field for launchpad.Moderate. seems like a good  practice
<wgrant> It also doesn't really scale, as we see here.
<wallyworld> declarative security = good
<wallyworld> i'm sure we can find other usages for the new permission
<wgrant> Yes, declarative security is good.
<wallyworld> instead of hard coding rules everywhere
<wgrant> But not in the current style we have.
<wallyworld> not sure i understand your objection?
<wgrant> Having to define new global permissions is a bit icky.
<wallyworld> why?
<wgrant> Because we end up with stuff with three subtly conflicting meanings, like launchpad.Moderate.
<wallyworld> the meaning is pretty well documented in permissions.zcml
<wgrant> Heh
<wallyworld> my view at the moment is that we have too many permission checking bits of code scattered everywhere
<wallyworld> and i don't want to add another
<wallyworld> the bug i fixed this morning was due to this sort of thing
<wallyworld> so if i have to add something, i wanted it to be done using our current security framework
<wgrant> We don't have a security framework..
<wallyworld> we do - it's provided by zope
<wgrant> The one we inherit from Zope is not suitable for our purposes.
<wallyworld> seems to be doing ok for now - it functions, no? may not be perfect but it's what we have
<wgrant> Huh?
<wallyworld> so i'd rather stick to that than adding new stuff
<wgrant> We work around it in tonnes of places.
<wgrant> For this sort of thing.
<lifeless> wallyworld: bug this morning ?
<lifeless> wallyworld: the merge proposal one ?
<wallyworld> lifeless: the bug badges one
<lifeless> wallyworld: bug # ?
 * wallyworld looks
<wallyworld> bug 741234
<_mup_> Bug #741234: product:+code-index merge proposal queries do not show private bugs visible by assignment <disclosure> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/741234 >
<lifeless> ok
<lifeless> so that has nothing to do with declaritive security
<lifeless> and everything to do with querying too restrictively - duplication of code yes
<wallyworld> i meant that it had to do with bits of security code scattered everyehrre
<wallyworld> and delarative security helps avoid that
<lifeless> mmm
<wgrant> It can't avoid that.
<lifeless> so there is a layering confusion in this discussion
<wgrant> This is exactly the sort of thing that cannot be done with anything like the Zope security framework that we inherit.
<lifeless> the DB layer, unless we model *everything* [and thus don't need any zope security framework stuff] cannot implement all business rules.
<lifeless> The app server layer, unless the DB returns *only* the right stuff, cannot validate and serve content quickly, unless they hold all objects in memory all the time [more-or-less, and close enough for the purpose of this discussion]
<lifeless> today, we neither model everything (e.g. the appservers do not impersonate the user who made the request - the DB does not know about users and cannot enforce update business logic like 'bug supervisors can set this enum')
<lifeless> nor can we hold everything in memory in every appserver process
<wallyworld> agree with all that
<wallyworld> the issue at hand - we have a field protected in zcml by a declarative permission. i want to change that to a new one
<lifeless> -> we have two entirely different layers, which need entirely different implementations even though there are many rules which will occur at both levels
<lifeless> wallyworld: ok, well I went on this tangent when you used the bug this morning as a symptom of what you're dealing with this afternoon :P You can understand my confusion?
<lifeless> wallyworld: what are you working on this afternoon ?
<wallyworld> lifeless: sure, sorry. i was merely trying to illustrate a point
<wallyworld> bug 885503
<_mup_> Bug #885503: Its not obvious on the UI how to choose to have all bugs reported against your project marked private by default. <bugtracker> <disclosure> <documentation> <privacy> <Launchpad itself:In Progress by wallyworld> < https://launchpad.net/bugs/885503 >
<wallyworld> the private_bugs field is protected by launchpad.Moderate
<lifeless> wallyworld: I'm horribly detail orientated - sorry!
<wallyworld> i was thinking about using a new permission launchpad.CommercialSubscriber
<wallyworld> since that's what defines the editablity of that field once the bug is fixed
<wallyworld> or i could use a mutator like wgrant suggested but i didn;t want to do that
<lifeless> so, your logic here is 'add a new rule saying 'members of commercialsubscribers get commercialsubscriber on the product configuration'
<wgrant> The editability of the field is defined by (user holds launchpad.Edit on project + project has commercial subscription)
<lifeless> s/logic/proposed solution/
<wallyworld> i was also thinking we could use the permission elsewhere
<wallyworld> not sure where right now... but
<lifeless> so, AIUI the zope way of doing this is to only grante Moderate to the field for the right folk
<lifeless> e.g. its just granted too leniently atm
<wallyworld> or too restrictive
<lifeless> and probably you'd end up factoring out a separate object so that the granularity of the permission system would allow custom rules for that field(s)
<wallyworld> since we want to allow folks other than registry and admin
<lifeless> specifically, permissions *should not* reflect 'combination of rules' - they should reflect 'allowed to do X'
<lifeless> so yes, I object.
<lifeless> it doesn't fit with the zope security model
<lifeless> (AIUI)
<wallyworld> np, thanks for the input
<wallyworld> gotta fly out and get the kid from school - it's just started to piss down rain here
<wgrant> wallyworld: I complete share your concerns about security code being everywhere.
<lifeless> the /adapters/ that grant moderate for objects of IFoo - thats where there rules, and combinations of rules, are meant to live
<wgrant> But I don't think we should shoehorn everything into the Zope model.
<wgrant> Because we've seen it simply doesn't work.
<lifeless> so I'd rephrase the problem as 'why isn't lp.Moderate being granted to $user on $field' and chain back.
<lifeless> we may find the zope model isn't granular enough, and we can look at how to deal with that
<lifeless> wallyworld: ciao, chat later
<wallyworld> lifeless: i haven't looked where else moderate is used, don't think chaining will necessarily work perhaps
<wallyworld> talk later
<wgrant> lifeless: Max heat demolition has landed.
<wgrant> lifeless: I'll land the aging removal tomorrow once these get through to db-stable.
<stub> Anyone know if there is a workaround to this ec2 land error? https://pastebin.canonical.com/59669/
<stub> Think it is because the branch is owned by a team, not a person
<wgrant> stub: You'll have to either hack it or ec2 test and lp-land manually.
<stub> Yer, looks like a trivial fix. Just one more thing to sort before actually landing what I wanted to land :)
<stub> But of course, I only need the fix locally to use it and can land later.
<lifeless> wgrant: cool
<lifeless> wgrant: btw what was the change from max heat to bug count - I saw a reference fly by but didn't look into it
<wgrant> lifeless: The ordering on DistroSeries:+needs-packaging
<wgrant> ie. nobodycares
<wgrant> Sort of like hardware bug searches.
<wgrant> Tag sorting.
<wgrant> Blueprint sorting.
<wgrant> Except those three are a little harder to remove without people noticing.
<stub> Is it my imagination, or are ec2 errors 'psycopg2.OperationalError: FATAL: Â could not open relation mapping file "global/pg_filenode.map": No such file or directory' rather common?
<wgrant> I've had approximately two of them ever.
<stub> db setup must be failing, or ram disk being full or something?
<stub> hmm...
<stub> oh... think it is picking up my PG9.1 image rather than the 8.4 image
 * stub gets explicit
<lifeless> wgrant: e.g. sortbypopcon would be win
<adeuring> good morning
<wgrant> lifeless: If we had it :)
<wgrant> But LP doesn't really consume.
<wgrant> It subsumes :(
<StevenK> gmb: Bwahahaha at your Churchill comment on FB.
<StevenK> adeuring: If you QA r14748 and r14755 we can probably deploy
<adeuring> StevenK: ah,. ok, let me look...
<rick_h> morning party people
<adeuring> StevenK: done
<rick_h> adeuring: can you do me a fav and peek at this really quick? https://code.launchpad.net/~rharding/launchpad/graph_lpjs_928500/+merge/92024
<adeuring> rick_h: sure
<rick_h> ty, very small but want to get it going
<adeuring> rick_h: looks good. thanks for this fast fix!
<rick_h> adeuring: ty
<rick_h> bah, anyone seen broken ec2 land in get_stakeholder_emails in autoload.py?
<rick_h> nvm, found it, bug https://bugs.launchpad.net/launchpad/+bug/928853 in case anyone hits it
<_mup_> Bug #928853: ec2 land fails if there is no None value in the stakeholder email set <ec2> <land> <Launchpad itself:Triaged> < https://launchpad.net/bugs/928853 >
<rick_h> adeuring: another one please if you have a sec, sorry https://code.launchpad.net/~rharding/launchpad/ec2_land_928853/+merge/92033
<adeuring> rick_h: sure, np
<adeuring> rick_h: r=me.
<rick_h> adeuring: ty
<wallyworld_> jcsackett: hi, there's only one way to figure out what badges to show - i removed the duplicate code
<jcsackett> wallyworld_: i only see you removing the bug badge code; BranchBadges still exists, as does HasBadges &c.
<jcsackett> wallyworld_: i was referring to the problem that over all of LP we now have multiple ways of doing things--which isn't a problem you introduced, it clearly already existed.
<wallyworld_> from memory HasBadges is a base class/interface and the code in branchlisting uses BranchBadges/HasBadges to do it's work, but now there's only the one way of doing it
<wallyworld_> it's a bit convoluted, but there is only the one code path
<jcsackett> wallyworld_: ok.
<wallyworld_> it's a bit hard to explain on irc - i'll fill you in on the standup
<jcsackett> wallyworld_: i won't be at tonight's standup. we'll have to discuss at the next one. but please do fill me in. :-)
<jcsackett> thanks again for solving that bug. good to know that i was just looking in an entirely the wrong place. :-)
<wallyworld_> will do. i'm fairly sure i'm correct in my assertion but still i may have made a mistake. it was a lot clearer in my mind several hours ago when i did it
<wallyworld_> np. i can see where the confusion crept in - there we 2 methods to determine whether to show bug badges
<wallyworld_> and one was never called by the view code
<wallyworld_> hence your test passed but it still failed in practice
<wallyworld_> there pseudo dup code was done in 2007 and in 2009
<wallyworld_> so i deleted the 2nd way (which was inferior anyway since it made one sql per linked bug)
<wallyworld_> and now there's a single method that is invoked when the branch listing renders and i reimplemented it to re-used the bug privacy filter stuff instead of doing it's own thing
<wallyworld_> which was the real root cause here
<wallyworld_> ie duplicated (but not) bug visibility code
<wallyworld_> messy
<deryck> adeuring, abentley -- reminder that standup is G+.  I sent invites.
<deryck> abentley, adeuring, rick_h -- ah, one more thing, I will take lunch offline so I can get back into my gym routine and relocate to Wendy's shop.
<adeuring> ok
<rick_h> deryck: good stuff, go kill the treadmill
<deryck> rick_h, it usually is the one doing the killing.
<abentley> sinzui: I have pocketlint 0.5.27-0gdp410~oneiric1 installed, and it's broken with doctests.  Known issue?
<sinzui> abentley, no. please report a bug at https://bugs.launchpad.net/pocket-lint so that I can get a fix in today
<abentley> sinzui: bug #928903
<_mup_> Bug #928903: Pocketlint is broken with doctests <pocket-lint:New> < https://launchpad.net/bugs/928903 >
<sinzui> abentley, I might have this fixed in the hour. I need to save my blog post first
<abentley> adeuring: Could you do a review for me?  It's a one-liner.  https://code.launchpad.net/~abentley/launchpad/stable-test-failures2/+merge/92047
<adeuring> abentley: sure
<abentley> adeuring: thanks.
<adeuring> abentley: r=me
<abentley> rick_h: know anything about jsbuild failures?  http://pastebin.ubuntu.com/834010/
<rick_h> abentley: looking
<rick_h> abentley: is this off devel? /me looks if the combo stuff from SteveK landed
<abentley> rick_h: This is off stable.
<abentley> rick_h: r14759
<rick_h> abentley: make clean? I'm not seeing that locally
<abentley> rick_h: That works, but if I delete build/js/yui/yui-3.3.0/yui/yui.js it breaks again.
<rick_h> abentley: ok, SteveK has a branch that redoes how that build stuff works that should be coming really soon
<rick_h> it's been reviewed
<abentley> rick_h: cool.
<rick_h> abentley: so if it's ok, we'll just think to test it once it lands
<abentley> rick_h: Sure.
<sinzui> abentley, pocket-lint is fixed, you will get the package in about 4 hours
<abentley> sinzui: Thanks!
<salgado> lifeless, do you want to talk about our plans for work-items in LP or are you happy with what we described on the mailing list?
<sinzui> salgado, I believe lifeless is dismantling a droid to get a message to General Poster about the plan for the death star
<salgado> heh
* abentley changed the topic of #launchpad-dev to:  https://dev.launchpad.net/ | On call reviewer: abentley | Firefighting: - | Critical bugtasks: 4*10^2
<lifeless> salgado: I would enjoy chatting about it, but you shouldn't block on us talking; I've got no timeslots today but perhaps tomorrow (you can check my google calendar)
<lifeless> rick_h: btw
<lifeless> rick_h: talking of template engines, handlebarsjs.com is horribly misleading vs the actual handlebars.js git repo. (e.g. examples that don't work ...)
<rick_h> lifeless: :( sucky.
<lifeless> meh, its advertising site
<lifeless> I tried an experiment, and found errors on the site, so went 'wtf'?!?!?!
<lifeless> (also note the total lack of contact details >< hard to file a bug...
<rick_h> yea, that's beyond annoying when the main examples don't work
<lifeless> rick_h: the example 'Handlebars HTML-escapes values returned by a {{expression}}. If you don't want' ... is the first (perhaps only) one that was wonky
<lifeless> a vs A
<lifeless> small thing, but quite disappointing
 * rick_h is now curious how different Y.Handlebars might be from the git repo
<rick_h> I've not tracked how the pulling in has gone from the YUI side
<lifeless> I'd be interested to know, it has some bearing on my experiment
<lifeless> as does the breadth of features yui itself uses from within handlebars
<rick_h> lifeless: right, I'll check that out. I'm curious now. The framework isn't using much, but my understanding is that they're using for internal/public apps that should be working it a bit
<rick_h> but not sure which apps have it so I'll ask/check
<rick_h> lifeless: https://pastebin.canonical.com/59772/
<rick_h> lifeless: basically any file in that dir yui- is yui customizations, some api docs, tweaks
<lifeless> thanks
<lifeless> what channel is that ?
<rick_h> #yui
<rockstar> rick_h, handlebars and Y.Handlebars are not different
<rockstar> rick_h, are you using 3.5pr2 currently?
<rick_h> rockstar: on an outside app yea. I'm trying to talk lifeless into handlebars for our stuff
 * rick_h hates mustache with the heat of many pizza ovens
<rick_h> :)
<rick_h> rockstar: you guys playing with it?
<rockstar> rick_h, we've been using Y.substitute still
<rick_h> ah ok
<rockstar> rick_h, your loader code that you stole from us won't run in its current form on 3.5
<rick_h> rockstar: I'm not using most of it
<rick_h> only stole some basics on generating the module config
<rockstar> Why do you need handlebars currently?
<rick_h> we've got mustache and not happy with it
<rockstar> What are you not happy with?
<rick_h> but it has a python version which is why it won
<rick_h> really poor performance, lack of building decent helpers/modules
<rick_h> and very buggy from python -> js versions
<rockstar> Oh, so apparently you're doing templating somewhere other than the browser as well?
<rick_h> rockstar: yea, the new buglisting is mustache on server/client
<rick_h> the first load is server generated and the subsequent are client
<rick_h> right, so the dicussion is can we implement a python version of handlebars and use it client side and solve a lot of issues
<rick_h> or does fixing mustache make sense
<rick_h> or something else entirely
<rick_h> but LP is getting waaaay to many ways to build a tpl
<rockstar> Yeah, I bet.
<rick_h> the fact that we're YUI and YUI is bringing in handlebars is a BIG plus imo
<rockstar> Absolutely.
<lifeless> rockstar: we still have use cases around filing bugs etc from stone age (text) browsers
<rockstar> lifeless, yeah, and U1 doesn't worry about those browsers.
<lifeless> rockstar: which is a bit sad; also for google juice you still need server rendered content
<rockstar> But we also aren't TOO concerned about duplicating templates slightly.
<beuno> lifeless, not for private content you don't  :)
<rick_h> I still think there's a way around that using normal "google, don't index this...but go look here" for that
<lifeless> beuno: actually you do
<lifeless> beuno: search appliance
<beuno> lifeless, we don't do search appliance, but yes, that would be a use case
<lifeless> rick_h: there is, the way it works is you point google at server rendered pages using a site map
<rockstar> rick_h, yeah, google has a hashbang protocol
<lifeless> beuno: canonical has one internally
<rockstar> But javascript only is not great for accessibility
<rick_h> yea, that's very true
<rockstar> Or, rather, it misses a11y in many core cases
<lifeless> so, long story short, I don't think we can justify client only rendering yet, all things considered.
<lifeless> but we don't want to pay through the nose for doing both, nor do we want to only do client in a few cases
<rockstar> I don't think you *should* justify client only rendering
<rockstar> Ever.
<lifeless> rockstar: my personal jury is still out on that; call me on the fence with a lean towards server-side-needed-indefinitely
<lifeless> I do think we should separate the layers
<lifeless> data layer <-> template layer <-> HTTP HERE
<rockstar> lifeless, yeah, I'd be happy to chat about that sometime and kick you off the fence.
<lifeless> and client rendering can possibly suck straight from the data layer
<lifeless> rockstar: which side do you want me to land on ?
<rick_h> hah
<rockstar> lifeless, server-side-needed-indefinitely
<lifeless> :) so as I say I'm bent that way as it stands
<rockstar> :)
<lifeless> but its worth reevaluating regularly
<beuno> don't ruin the surprise!
<rockstar> Screen readers force us into perpetual IE6 support. :)
<rick_h> you guys are sending the end of my day into depression
<mwhudson> it's just a trick to make you stay working later
<lifeless> rockstar: we just blew IE6 away
<lifeless> rockstar: so gnar gnar gnar :P
<rockstar> Yeah, we did that too (and IE7 as well), but if you care about a11y, you still have to *kinda* support it.
<rockstar> Screen readers don't care about bleeding edge.
<lifeless> We can ship out cd's more cheaply.
<rick_h> what are our stats on that stuff? Is that out there to see?
<rick_h> not to minimize the issue at all, just curious
<lifeless> we have *200* data types in LP, supporting something awkward across the board is very expensive
<lifeless> rick_h: stats on which stuff?
<rick_h> browser/screen reader/etc
<rockstar> rick_h, how do you get stats on browser plugins?
<rick_h> I'd assumed that the screen readers would alter UA?
<rick_h> I guess I've never actually used/seen used one
<lifeless> rick_h: chat to TheMuso
<lifeless> rick_h: he's one of our blind staff
<rockstar> rick_h, go make a blind friend.  That's what I did.
<rick_h> k
<rockstar> I mean, chat with TheMuso as well, but have someone you can meet for lunch.
<lifeless> he'll be in #canonical in a couple hours
<rick_h> I'll put out a personal ad in the area :)
<rockstar> Seeing the crap impaired sight people deal with makes my heart hurt.
<rick_h> lifeless: so this guys in #yui gave me this for some handlebar exapmles: http://beta.tdp.me/static/scripts/bundle.js http://beta.tdp.me
<rick_h> lifeless: says he's using some self build block helpers and such
<rick_h> to give you stuff to poke at
<rick_h> lifeless: so do you have stuff with the server side making api calls to services so it can server side process it?
<rick_h> sorry, meant rockstar ^
<bryceh> sounds like it's affecting a few people - https://bugs.launchpad.net/ubuntu/+source/python-launchpadlib/+bug/929068
<_mup_> Bug #929068: [Precise] bug_task.date_created is returning 'unicode' objects instead of 'datetime' objects <amd64> <apport-bug> <precise> <running-unity> <python-launchpadlib (Ubuntu):New> < https://launchpad.net/bugs/929068 >
<abentley> lifeless: After updating sourcedeps.conf, update-sourcecode will update sourcedeps.cache for you.  Please commit that.
<lifeless> abentley: it still works if it is stale, right ?
<abentley> lifeless: Yes, it's just slower.
<lifeless> abentley: I did that particular change in an environment where update-sourcecode won't work [long story], which is why I didn't have the cache updated
<abentley> lifeless: Ah.
<james_w> bryceh, bug 924240 looks to be the same
<_mup_> Bug #924240: datetime interpretation changed <wadllib:Triaged> < https://launchpad.net/bugs/924240 >
<lifeless> statik: can we move our 1:1 up (to ~now ?)
<bryceh> <bryceh> well, wadllib could do something like that
<bryceh> <bryceh> try downgrading it?
<bryceh> <Sarvatt> hah
<bryceh> <Sarvatt> python-wadllib_1.2.0+ds-2build1_all.deb
<bryceh> <Sarvatt> indeed it works
<statik> lifeless: yes! better for my schedule also
<lifeless> skype? g+? pots? pigeons?
<statik> lifeless: g+? https://plus.google.com/hangouts/extras/canonical.com/statik-hangout
<lifeless> I'll start one - that wants me to activate my canonical address as a profile
<lifeless> ETOOMANYONLINEIDENTITIES
<lifeless> invites sent
<rockstar> rick_h, I make a <script type="text/x-template"> with my template code inside, and then do Y.one().getContent() to get the template.
<deryck> abentley, r=me for your upgrade branch.
<abentley> deryck: thanks.
<lifeless> wgrant: bug tag portlet is bugsummary based now right ?
<wgrant> lifeless: I think so, but don't quote me on that.
<deryck> Later on, everyone.
<lifeless> rick_h: btw, I've replied to the MP - but -- pydoc set.discard :)
<rick_h> lifeless: what MP is this?
<lifeless> rick_h: the ec2 land notification error one
<lifeless> maybe it wasn't yours
<rick_h> lifeless: ah yea. I didn't see a comment in my email, /me goes to look again
<rick_h> oh bah, completely missed that. What I get for trying to rush a quick fix through
<lifeless> what you did works, but its not exactly idiomatic :)
<rick_h> lifeless: yea, gotcha. Missed discard when I hit the docs on remove() today.
<StevenK> wallyworld_, sinzui, wgrant: http://pastebin.ubuntu.com/834556/
<sinzui> wgrant, wallyworld_: These are the projects that violate the commercial subscription for commercial features policy http://pastebin.ubuntu.com/834571/
<sinzui> I will deal with these tomorrow
<wgrant> omg qastaging bug updates so fast
<StevenK> Haha
<lifeless> wgrant: \o/
<cody-somerville> sinzui, how do you intend to deal with them?
<sinzui> cody-somerville, Not sure yet. I could land a branch to let me give the projects a commercial subscription, or I get a webops to add the proprietary checkbox to them so that I can apply the subscription with the current rules
<cody-somerville> Some of those projects are PES projects.
<sinzui> They were not setup correctly. I think all are probably valid uses. I just need to get the power to complete their setup
<StevenK> wgrant: http://pastebin.ubuntu.com/834599/
#launchpad-dev 2012-02-09
<rick_h> StevenK: howdy, how goes the convoy branch?
<StevenK> rick_h: I've not worked on it. If this critical regression branch gets finished off, I'll toss it at ec2 today.
<rick_h> StevenK: awesome, ok. wanted to check. I've got deryck starting to reivew my JS test branches so was curious
<wgrant> Hahahawefwefw
<rick_h> quick! someone get wgrant some water before he passes out!
<wgrant> I just discovered why Product:+index is so terrible.
<wgrant> ProductPackagesPortletView always calculates linkage suggestions, even if it's not going to show them.
<wgrant> And that's an expensive FTI query.
<huwshimi> Is there a way to merge pipes, or push changes back into the parent? I accidentally created a pipe when I had uncommitted changes and now want these changes to be in the parent pipe.
<wgrant> huwshimi: They're just normal branches with handy aliases.
<wgrant> You should be able to say 'bzr merge :next'
<wgrant> That sort of thing.
<huwshimi> wgrant: Ah awesome, that makes sense
 * wallyworld punches wireless keyboard and mouse that just died
<rick_h> wallyworld: wired > *
<wallyworld> i think it's the receiver. bollocks
 * StevenK loves his wireless keyboard and mouse
<wallyworld> mine is a logitech which should be better than a no-name brand you would think
<StevenK> I think they're due for replacement. I've played enough first person shooters that the labels for WASD are either completly or just about worn off
<wallyworld> hah
<wgrant> That's why real keyboards don't have labels :)
<wgrant> Well, that and Dvorak.
<wallyworld> i've never tried a Dvorak keyboard
<rick_h> vim + dvorak scares me too much
<rick_h> though I do love my buckling spring unicomp :)
<StevenK> wallyworld: I do hate that the two major choices for keyboard/mouse are Microsoft and Logitech
<rick_h> bah
<rick_h> http://elitekeyboards.com/ http://www.pckeyboard.com/
<wallyworld> yeah. i've have to buy another one today. can't not have one :-(
<rick_h> there's your real keyboards
<StevenK> rick_h: How much do you want to bet they don't ship to .au?
<wallyworld> wow. the pckeyboard one even has a clitoris
<rick_h> wallyworld: yea, but no middle scroll mouse button :( guess it's a trademark thingy they can't do
 * wgrant hates non-mechanical switches now.
<rick_h> StevenK: ah, ok got me there.
<rick_h> wgrant: you tried a topre yet? I can't get my wallet out to go that route
<wgrant> rick_h: No, but they intrigue me.
 * StevenK prefers keyboards that are quiet
<wgrant> But they feel terrible :/
 * wallyworld prefers keyboard that work
<StevenK> wallyworld: You seem to be typing okay.
<rick_h> wgrant: do they? it's one of the few switches I've used
<rick_h> StevenK: check out the cherry brown
<wallyworld> StevenK: on my laptop keyboard
<rick_h> those are pretty quiet switches
<wallyworld> i'll have to undock for today
<StevenK> Googling for Cherry Brown isn't so helpful
<wallyworld> and whenever i undock, it kernel panics
<wgrant> rick_h: I was replying to StevenK's quiet keyboards thing.
<StevenK> wallyworld: Handy.
<wallyworld> yeah
<wallyworld> well here goes.....
<wgrant> I believe mine has Cherry Browns.
<wgrant> They're certainly not quiet.
<rick_h> wgrant: oic
<wgrant> But they're a bit quieter than Blues :)
<StevenK> Bwaha
<StevenK> That sounds like a panic
<rick_h> wgrant: yea, I've got two of the leopolds, one in brown and one in blue
<StevenK> wgrant: So you prefer keyboards that sound like a typewriter factory?
<rick_h> from the elite keyboards place
<wgrant> StevenK: Yes, because they are so nice to type on.
<rick_h> wgrant: ++
<wgrant> I used to prefer my ThinkPad keyboard to every other keyboard I'd tried.
<wgrant> But now it feels terrible compared to this :/
<StevenK> rick_h: $54USD to ship a keyboard from elitekeyboards
<rick_h> StevenK: ouch
<wgrant> pccasegear has some reasonable keyboards.
<wgrant> They're Australian.
<wgrant> http://www.pccasegear.com/index.php?main_page=index&cPath=113_1277
<StevenK> All four of them are corded :-)
<rick_h> cool, the leopolds are two that I have used. wgrant you used cherry reds? another one I'm interseted in
<wgrant> Why would you want a wireless keyboard :/
<wgrant> You have to have wires to your monitor, and your keyboard is right in front of your monitor...
<wgrant> rick_h: I just have a Das Keyboard Ultimate S
<wgrant> Which has Browns AFAIK
<rick_h> wgrant: ah, gotcha
<wgrant> I've never tried reds.
<rick_h> heh, tonight at the local coders meet up is keyboard night. Brought out the leopold blue, brown, happy hacker, and unicomp
<rick_h> I need help...
<StevenK> wgrant: My keyboard isn't
<StevenK> I have a keyboard drawer
<wgrant> I used an actual Model M for a while.
 * StevenK wonders why calling this view is returning ""
<rick_h> wgrant: my unicorn is one of those split model M's. Like a model M and a MS Natural had babies, but they for for like $1k on ebay :/
<lifeless> is bug 732510 f-r really?
<_mup_> Bug #732510: poppy-sftp should connect to the database with a unique user ID <canonical-losa-lp> <dbuser> <poppy> <qa-ok> <tech-debt> <trivial> <Launchpad itself:Fix Committed by stub> < https://launchpad.net/bugs/732510 >
<StevenK> wallyworld_: That was a nice panic?
 * StevenK puts together a deployment
<wallyworld_> StevenK: i went and got a drink before i rebooted
<wgrant> lifeless: No
<wgrant> lifeless: Needs downtime.
<lifeless> wgrant: paramses?!
<wgrant> lifeless: Well, it's a sequence of sets of parameters :(
<wgrant> Yes, it's terrible, but params is already used for the singular.
<lifeless> rules, searches, clauses, conditions, param_sets, ...
<lifeless> I dunno, but accepting it as terrible seems undesirable :)
<wgrant> lifeless: It's a sequence of BugTaskSearchParams objects.
<lifeless> yes
<lifeless> which all get unioned together
<lifeless> not anded
<lifeless> this is worth calling out perhaps
<wgrant> Yes
<lifeless> -> alternatives
<lifeless> -> alternate_parameters
<wgrant> alternatives it is
<lifeless> wgrant: bug 929241
<_mup_> Bug #929241: ProductPackagesPortletView calculates suggestions when it knows it won't show them <Launchpad itself:In Progress by wgrant> < https://launchpad.net/bugs/929241 >
<lifeless> wgrant: why can't that just be the first line of setUpFields ?
<wgrant> lifeless: Because then setUpWidgets complains that there aren't any fields.
<lifeless> ah. thanks
<wgrant> If I avoid setUpFields, I have to also avoid the rest of the form code.
<lifeless> yea
<StevenK> WidgetInputError('name', u'Name', LaunchpadValidationError(u'unique-from-test-team-py-line529-100007 is already in use by another person or team.'))
<StevenK> I call shenanigans
<ayan> maybe i was dreaming but i recall hearing about a C API for launchpad.
<ayan> if it exists, where can i download it?
<wgrant> I'm not aware of one.
<wallyworld_> lifeless: the docs say any alter table patch cannot be applied live. is this true even for "alter table xxxx drop constraint...." patches?
<StevenK> Doesn't that take a full write lock on the table?
<wallyworld_> no idea
<StevenK> wallyworld_: It should still be fine to apply during FDT
<wallyworld_> but i would have thought a drop would be virtually instant
<StevenK> It still needs a lock
<wallyworld_> sure, but a very short one
<wallyworld_> which hopefully we could tolerate?
<StevenK> wallyworld_: Applied live refers to "Do not needs us to go down, can be done live"
<wgrant> I think we should tolerate it.
<wgrant> Although it will cause timeouts.
<wgrant> Ah, except slony.
<wgrant> So no, it requires a full lock across the cluster.
<StevenK> Which is FDT only
<wgrant> If we weren't using slony, I think it would be acceptable, as it would only cause things to time out for a few seconds.
<wgrant> Yes.
<wallyworld_> ok, will redo patch nr
<wgrant> nr?
<lifeless> wallyworld_: yes, it is true.
<wallyworld_> nr is an (i thought) common abbreviation for number
<wgrant> wallyworld_: Right, but this doesn't involve a number change.
<wgrant> The docs in allocated.txt are out of date.
<wallyworld_> wgrant: my patch nr ends in -1
<lifeless> wallyworld_: the reason it says cannot be applied live is because it cannot be applied live.
<wgrant> 'tis irrelevant nowadays.
<wallyworld_> so do i make the patch nr end in -0?
<lifeless> wallyworld_: in a busy cluster with e.g. backups, we might wait up to 24 hours to get a lock.
<wgrant> wallyworld_: It no longer matters.
<lifeless> wallyworld_: so even without slony, it would be unsafe to apply such a patch live.
<wgrant> lifeless: It's safe if you are careful.
<wallyworld_> ok, will mark the mp as needs review then
<lifeless> wgrant: FSVO
<lifeless> wgrant: its not trivially repeatedly safe
 * StevenK stops looking at this visibility branch for a bit, since it is making him very very frustrated.
<wgrant> lifeless: It involves less downtime than fastdowntime (up to ~9s of timeouts, rather than 90s of outage)
 * wallyworld_ taps fingers waiting for diff
<lifeless> wgrant: the goal of the process is to make it trivially and repeatedly safe to evolve the schema; having complex rules that only db gurus can get right is not a good way to achieve this.
<wgrant> But because of slony we can't do it.
<wgrant> Mmm
<wgrant> True
<lifeless> wgrant: more than 9 seconds, even without slony. not unless and until we have sorted a bunch of other stuff out.
<lifeless> wgrant: (other stuff being e.g. backups - anywhere in the cluster. Cronscripts with locks. Etc.
<wgrant> lifeless: Assuming that you are smart and don't apply when there are long transactions.
<lifeless> (read locks)
<wgrant> Which is what I meant by "careful"
<lifeless> wgrant: hard to automate -well- because you cannot tell what /will/ be long when you start, only what *is* long already.
<wgrant> lifeless: Lies.
<wgrant> crontab disablement is handy.
<lifeless> wgrant: e.g. the fdt kick everyone off logic would still be needed.
<wgrant> Nope.
<wallyworld_> hurry up diff!!
<wgrant> You set a global flag which tells longrunning jobs to GTFO
<wgrant> s/GTFO/not start/
<lifeless> wgrant: I agree that in an ideal world it could be made moderately reliable, but I won't go further than that :0
<wgrant> Wait for any stragglers to go away.
<wgrant> Apply patch, which waits for contending requests to go away
<wgrant> Done
<lifeless> wgrant: modulo bugs, modulo stale connections, modulo another sysadmin doing something ...
<wgrant> Yes.
<lifeless> wgrant: the patch during that period breaks the world, of course.
<lifeless> wgrant: taking everything out as fdt does, ignoring cluster sync, we can get less than that 9 second downtime window, and do it reliably (ignoring cluster sync because this is a post-slony discussion)
<wgrant> lifeless: It breaks things that use that table for up to $REQUEST_TIMEOUT.
<wgrant> Rather than breaking the entire application for $SLONY_TIME
<lifeless> wgrant: and it also pauses all other incoming queries for that same window
<wgrant> Isn't that
<wgrant> "breaks things"?
<wgrant> That was my definition of "breaks things".
<wgrant> Oh, you mean it will hang threads and therefore cause queueing?
<wgrant> True.
<lifeless> yes
<lifeless> knock on effects
<lifeless> rather than 'LP is down, come back soon' folk see 'LP is slow with no notice'
<lifeless> this is undesirable
<wgrant> Mmm
<wgrant> Slow for 5 seconds is better than down ever.
<wgrant> s/5/10/
<lifeless> debatable; there is no reason FDT can't be that fast *anyhow*, so ...
<lifeless> given a less risky and highly repeatable process, with similar limits on performance, why would you want a more risky process?
<lifeless> wgrant: are you working on that new loggerhead bug right now? should I delay releasing?
<wgrant> lifeless: I'm 30s from pushing
<wgrant> Just found another couple
<lifeless> cool
 * wgrant stomps on the branch scanner's face
<wgrant> Hard
<StevenK> That's okay, it has another one
<wgrant> Unfortunately.
<wgrant> wallyworld_: this ajax submit thing is very slow
<wgrant> Or is it broken...
<wallyworld_> wasn't slow for me before
<wgrant> I'm leaning towards broken at this point.
<wgrant> Oh
<wgrant> It's the longpoll bug
<wgrant> Had too many MPs open.
<lifeless> rotfl
<lifeless> cat just fell off the desk
<wallyworld_> meow
<lifeless> I have pillows behind my LCD
<wallyworld_> wgrant: what's the longpoll bug?
<lifeless> nice big one stacked two deep; both cats can lie up there
<wgrant> wallyworld_: Web browsers suck
 * wallyworld_ hates cats
<wgrant> wallyworld_: They try to avoid DoSing, by limiting the number of connections per hostname
<lifeless> the white one stretched out, arched back, and slid off the edge of the pillows, and the desk, and fell onto my minitower case :)
<wallyworld_> ah :-)
<wgrant> lifeless: https://code.launchpad.net/~wgrant/loggerhead/bug-929275/+merge/92194
<wgrant> Finally
<lifeless> is that a request for a code review ?
<wgrant> s/request/fishing attempt/
<StevenK> 31	from paste import httpexceptions
<StevenK> 32	+from paste.httpexceptions import HTTPNotFound
<StevenK> Fail
<wgrant> bah
<lifeless> wgrant: so, I wonder, would a wsgi middleware to map NoSuchId and NoSuchFile -> 404 be a good idea, or hide to many legit issues
<wgrant> lifeless: I don't think that's a good idea.
<lifeless> right now, for instance, the cod eyou've added can mask some classes of file system error
<lifeless> because they just trigger NoSuchFile
<wgrant> I used NoSuchId and NoSuchRevision
<wgrant> Aren't those pretty specific?
<lifeless> oh hmm,
<lifeless> I misread slightly
<lifeless> so yes, that should be pretty narrow
<lifeless> anyhow, fine at first glance, I'll let StevenK who seems to be in a reviewing mood do it ;)
<wgrant> StevenK: FIxed
<wgrant> lifeless: I think that could mask legitimate bugs.
<wgrant> And encouraging people to write terrible code is not what Loggerhead needs more of :)
<StevenK> wgrant: r=me
<wgrant> StevenK: Thanks.
 * wgrant lands.
<wgrant> lifeless: Should I upgrade Launchpad's?
<wgrant> Or do you have stuff planned?
<lifeless> wgrant: just release stuff from toshio, so please go ahead
<wgrant> k
<StevenK> WidgetInputError('name', u'Name', LaunchpadValidationError(u'unique-from-test-team-py-line529-100007 is already in use by another person or team.'))
<StevenK> LIES!
<wgrant> lifeless: the GIL contention between xmlrpc-private and app seems to be growing :(
<wgrant> we see lots of https://lp-oops.canonical.com/oops/?oopsid=OOPS-1e8d134f2de3a8101bf09a55c20c00ae now
<lifeless> 4 seconds getting feature flags?
<wgrant> Precisely.
<lifeless> ugh.
<lifeless> ugh ugh ugh ugh ugh guh
<wgrant> It's not unexpected.
<lifeless> doesn't make it /nice/ :)
<lifeless> so, we need to figure an appropriate ratio and then manually split the cluster, I guess
<wgrant> Yeah
<lifeless> I haven't seen anything suggesting haproxy knows how to count across two clusters yet
<wgrant> I don't think so, no.
<lifeless> that, or we teach lp how to server both from the same port
<wgrant> But we can do the rebalancing entirely in haproxy
<wgrant> which is nice
<wgrant> I considered that, but that is scary.
<lifeless> it could be a pgbouncer limit being hit
<wgrant> Unlikely
<lifeless> first query
<wgrant> Hm, really?
<lifeless> https://lp-oops.canonical.com/oops/?oopsid=OOPS-1e8d134f2de3a8101bf09a55c20c00ae#statementlog
<wgrant> Oh, xmlrpc, so no auth
<wgrant> I've never seen that on a webapp request, though.
<lifeless> in main servers we get the ff early too, to determine query timeout
<lifeless> should be the first query everywhere
<wgrant> I don't think we get it before auth.
 * wgrant checks.
<lifeless> webapp threads are probably never idle
<lifeless> fsvo idle
<wgrant> SQL-main-slave SELECT getlocalnodeid()
<wgrant> is the first for webapp
<lifeless> or more importantly, the number of webapp errors probably dwarfs the number that would match this...
<wgrant> Right.
<lifeless> which is on -slave
<wgrant> Mmm, true.
<lifeless> so, two theories; whats the cheapest thing to do
<wgrant> Graph pgbouncer connections, which UI has been trying to do this week? :)
<wgrant> At least that's what #webops has looked like.
<lifeless> excellent
<wgrant> I've only glanced, though.
<lifeless> as a starting point that makes sense
<lifeless> I wonder if pgbouncer logs enough that we can short circuit that
<wgrant> I'll check when these started
<wgrant> Because we hit the FD limit last week
<wgrant> when we moved session to go through pgbouncer.
<lifeless> e.g. we've just added X appservers (have we?) -> more connections used
<wgrant> No, they've not been added yet
<lifeless> Also someone needs to add the new prefixes to oops-tools once they are hactive
<wgrant> At least I hope not
<wgrant> Since there's still queue depth issues
<StevenK> Last I heard we were still waiting for more RAM and the extra CPU in one appserver
<wgrant> HMmm, you may be right.
<wgrant> On the pgbouncer thing
<wgrant> Unfortunately I started pruning properly again yesterday, so we don't have full records.
<wgrant> But I can't see too many similar OOPSes before the 31st.
<lifeless> I think we should investigate pgbouncer
<lifeless> 4 seconds in the GIL is pretty extreme, we were seeing that when we had 20 threads running on private-xmlrpc full-tilt, or something crazy like it
<lifeless> its more plausible to me that this is a queued connection in pgbouncer
<lifeless> at least on the data we have
<lifeless> grrr, wtf, quoting *everything*. sob.
<wgrant> What's quoting everything?
<lifeless> handlebars
<lifeless> shouldCompileTo("{{awesome}}", {awesome: "&\"'`\\<>"}, '&amp;&quot;&#x27;&#x60;\\&lt;&gt;'
<lifeless> its quoting " and ' `
<lifeless> some might say this is overkill
<wgrant> "' need quoting
<wgrant> ` not really
<lifeless> why does ' need quoting in a template expansion ?
<wgrant> lifeless: Attributes
<wgrant> Some misguided folk use ' to delimit XML attributes.
<wgrant> It's perfectly valid, if a little discouraged and quite rare.
<lifeless> nah
<lifeless> ah
<poolie> hi
<poolie> is it a regression, or a known problem, that attaching a patch to a bug no longer shows up in the comment timeline?
<poolie> oh well, https://bugs.launchpad.net/launchpad/+bug/929313
<_mup_> Bug #929313: patches aren't mentioned in the bug comment where they were attached <Launchpad itself:New> < https://launchpad.net/bugs/929313 >
<lifeless> I'm not sure it is either
<lifeless> o/
<StevenK> wgrant: Can haz help? With http://pastebin.ubuntu.com/834814/ and running the new feature flag test I get WidgetInputError('name', u'Name', LaunchpadValidationError(u'unique-from-test-team-py-line529-100007 is already in use by another person or team.'))
<wgrant> StevenK: Looking
<wgrant> StevenK: I'm not sure that's a problem.
<wgrant> StevenK: (Pdb) view.request.response._headers
<wgrant> {'location': ['http://launchpad.dev/~unique-from-test-team-py-line529-100007']}
<wgrant> It created it anyway, and redirected.
<wgrant> it's possible that you're not meant to render the form in that case.
<StevenK> So I'm not supposed to call view()?
<lifeless> IIRC redirects have no body -> no need to render ever
<StevenK> I'm just a bit unclear what I should do in that case.
<StevenK> Just call c_i_v() and then check the team exists and is private?
<wgrant> StevenK: I believe so.
<StevenK> AssertionError: !=:
<StevenK> reference = <DBItem PersonVisibility.PRIVATE, (30) Private>
<StevenK> actual = <DBItem PersonVisibility.PUBLIC, (1) Public>
<StevenK> :-(
<wgrant> StevenK: Also, lint.
<wgrant> Trailing whitespace everywhere!
<StevenK> If everywhere is 3 places
<StevenK> Anyway, fixed.
<wgrant> It's bright red.
<wgrant> So yes, everywhere.
 * StevenK isn't sure why visibility isn't set
<stub> ImportError: No module named pqm.pqm_submit
<stub> Anyone know where that is supposed to be pulled in from? I don't see this bzr plugin in sourcecode.
<wgrant> stub: The bzr-pqm package
<stub> Ta
<wgrant> Are you on precise?
<stub> Which is installed
<stub> Oneiric
<wgrant> Hmm
<wgrant> Possibly 2.6 vs 2.7
<stub> My system bzr is happy with the pqm plugin. Not sure how Launchpad's bzrlib is supposed to load the system plugin.
<stub> Could be right about 2.7 - system bzr uses 2.7 and lp uses 2.6
<stub> Nah
<stub> So how is the pqm plugin from the package supposed to get loaded when bzrlib.plugins is an egg?
<stub> The system path is shadowed
<wgrant> bzrlib.plugins is magical.
<wgrant> It can pull stuff in from lots of places.
<wgrant> I don't know how, though.
<wgrant> stub: Will postgres plan through a view as if it wasn't there?
<stub> Yes
<stub> It gets expanded inline and the whole thing planned
<wgrant> Right. Thanks.
<StevenK> stub: You're not really concerned with say, planner changes between 8.4 and 9.1?
<stub> StevenK: Usually things get better with a few regressions.
<stub> webops ping: Need the pqm pre-commit hook tuned
<stub> Or maybe just removed is better no
<stub> w
<stub> Need 'Makefile' added to the list of exceptions along with *.sql and fti.py
<wgrant> stub: Why?
<wgrant> stub: We've never had problems with database/schema/Makefile changes accidentally landing on devel, so I don't see any point in restricting them.
<stub> sorry... on the phoe
<stub> Had to change Makefile rules for the newly labotimized fti.py invocation
<stub> lobotomised  even
<wgrant> stub: *-0.sql and fti.py are the only things that are *forbidden*
<stub> I think I should give up typing today
<wgrant> Everything else is allowed.
<stub> Ahh... so my fti.py changes are the trigger
<wgrant> Yep
<stub> webops ping: Please remove the precommit hook then
<wgrant> Heh
<hloeung> stub: where would I find this?
<hloeung> ah, think I've found it
<hloeung> stub: is this for /home/pqm/archives/rocketfuel/launchpad/devel or /home/pqm/archives/rocketfuel/launchpad/db-devel or both?
<hloeung> precommit_hook=[ -z "$(bzr status -S database/schema/ | grep -e '\(-0\.sql\|/fti.py\)$')" ]
<hloeung> this one?
<stub> hloeung: that is the one
<stub> hloeung: It is no longer helpful, and a hindrance for my branch
<stub> lifeless: Do you really think it is worth keeping memcache around for just the blog info?
<hloeung> stub: ok, commented out
<stub> Ta
<lifeless> stub: well its also used as a cheap temp store for some migrations
<lifeless> stub: I nearly wrote 'and move the blog to something else' before I remember that
<lifeless> StevenK: I expect us to get fucked over in short order by pg 9.1, but the really traumatic stuff I think was in 8.4
<lifeless> StevenK: when a bunch of old implicit optimisations got derailed by CTE AFAICT
<mthaddon> wgrant: I'm not sure I see the logic of "we've never had a problem, so let's remove the prevention of a problem"
<wgrant> mthaddon: For some things, sure.
<mthaddon> can we change it rather than removing it altogether?
<wgrant> mthaddon: The particular case I was arguing against was a suggestion to *add* a new restriction that would not have stopped any previous problems.
<wgrant> But in general I think that restriction does more harm than good.
<adeuring> good morning
<wgrant> rick_h: JS on qastaging seems to be pretty broken.
<wgrant> LPJS is not defined
<wgrant> rick_h: At least on +register-merge
<rick_h> wgrant: looking
<rick_h> wgrant: @#$#@ see it. Putting up a mp right now. Very stupid
<StevenK> rick_h: I got annoyed with the regression branch so much I pushed convoy to the PPA and put up a small MP for convoy.
<StevenK> rick_h: I also tossed combo-url at ec2, which failed with codehosting failures.
<rick_h> StevenK: or wgrant can you review: https://code.launchpad.net/~rharding/launchpad/graph_lpjs_928500/+merge/92257
<rick_h> very small stupid me change that's got qastaging broken JS
<rick_h> StevenK: ok, thanks for the heads up. Want to shoot me the failed tests and I can peek at them today?
<StevenK> rick_h: Forwarded. Not sure if it's my fault.
* rick_h changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rick_h* | Firefighting: - | Critical bugtasks: 4*10^2
<rick_h> adeuring: ping, can you peek at the MP please? https://code.launchpad.net/~rharding/launchpad/graph_lpjs_928500/+merge/92257
<adeuring> rick_h: sure
<adeuring> rick_h: r=me
<rick_h> adeuring: thanks
<lifeless> bah, whats that thing where you can't sleep?
<stub> day?
<lifeless> hah yes
<lifeless> hey, so I've got the db hardware quote moving again
<lifeless> should have updated options soon and will rope flacoste into it when he is back on deck
<lifeless> stub: herb is proposing SSD, perhaps with the same RAM we have today, or even a reduction. Your thoughts?
<stub> SSDs are great if you pick the right hardware (and a disaster waiting to happen if you pick the wrong ones, such as the ones with volatile write caches on board). But not sure if they help our performance since we see little disk activity overall.
* jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rick_h*, jcsackett | Firefighting: - | Critical bugtasks: 4*10^2
<stub> Not sure what RAID setup we would need - need to scan the section in the PG performance tomb.
<stub> Maybe a single RAID5 would be fine offsetting cost, or maybe we would still need two channels or an expensive RAID0+1 setup.
<lifeless> stub: we do have a number of cold-cache bugs open
<lifeless> stub: I know we see little absolute disk IO, but when we do its all concentrated AFAICT :)
<abentley> gmb: I'm taking on branchscanner-timeout-bug-808930.  Can we chat?
<gmb> abentley: Sure, can you give me a little while to get to a point where I can switch? Say 14:30 UTC?
<abentley> gmb: That's stand-up time.  15:00?
<gmb> abentley: Sure, 15:00 would be fine.
<abentley> gmb: great.
<flacoste> good night lifeless ;-)
<lifeless> flacoste: heh I wish.
<lifeless> flacoste: we finally got cynthia to sleep properly, fingers crossed. And now *I* have insomnia.
<flacoste> lifeless: that's so not unusual!
<lifeless> stub: whats your feeling about RAM usage with SSD's? Could we keep it at todays levels, even with more appservers; or could we even reduce it?
<lifeless> stub: and yeah, please do scan the PG performance tomb and get back to me
<lifeless> flacoste: \i/
<stub> lifeless: I'd need to do research or benchmarking. Spinning plates of rust could end up faster if we can afford more RAM
<lifeless> so, herb is going to get options on SSD w/128GB of RAM
<stub> lifeless: similarly, you are right that we might be able to get away with less RAM with SSDs (although SSD access is still slower than cache)
<lifeless> I think we need to advise on the raid setup for those options?
<herb> my intention would be raid 10
<stub> Yes. There have been several threads on the mailing lists.
<lifeless> herb: oh hai!
<herb> even with SSD. :)
<stub> herb: over hardware raid 5? For paranoia or throughput reasons?
 * lifeless guesses at less rewrites-of-sectors
<lifeless> (+ performance)
<herb> stub: both
<lifeless> herb: ok, since thats about as good as it gets, I don't think we need to ask you for a specific config :)
<stub> herb: And one or two channels? We have two partitions, but that might be unnecessary since we are not queuing up writes for the right bit of rust to be in the right point in space/time.
<herb> my intention was a single channel SAS. even with SSD RAID 10 we won't be able to saturate the channel (nor could with with 16 or more spindles)
<lifeless> stub: the controller would still have a limited tagging queue, which can still saturate; but I doubt we would have an issue given our current write load
<herb> but I'm happy to take input on that.
<stub> elmo has the same book I havem but I'll trawl the mailing lists for the more resent threads. Only major thing I recall is many drives cheat by having write caches that fail for disaster recovery (including 'enterprise' devices)
<lifeless> herb: we could add another channel later, right ?
<herb> in any case, let's get some order of magnitude pricing. it might show that SSD is a non-starter and RAM is the way to go.
<stub> I suspect it is unnecessary
<lifeless> herb: if we can add another channel later, I think its totaly fine to start with one; SSD is -very- nice these days :)
<herb> lifeless: indeed we could.
<lifeless> so, we all seem agreed - lets defer the question
<stub> I think we should save money on RAM and buy me a coffee machine. Much better performance improvement.
<lifeless> use your frequent flyer points :)
<herb> I find your claim to be suspect.
<lifeless> herb: lol :) Also, I can point you at some hair raising queries/schema bits, which no amount of hardware can compensate for :)
<stub> KLM, Air France, Emirates.... don't think I've earned a real FF point in ages...
<stub> Anyway, off for dinner at 9:20pm because some of us have this non-sleeping thing from the other end.
<lifeless> ciao
<stub> herb: Consider a combination of SSD and spinning metal. No point wasting SSD on logs and dumps.
<herb> stub: good call. will do.
<deryck> abentley, adeuring, rick_h -- https://plus.google.com/hangouts/extras/talk.google.com/orange-standup
<lifeless> stub: herb: May I suggest the san rather than spinning metal for those offcuts ?
<lifeless> probably faster than spinning metal ...
<abentley> gmb: mum-ble or han-gout?
<gmb> abentley: Hangout works for me - besides, I can't guarantee that Mumble will. Bear with me a sec...
 * gmb waits for firefox to get its act together
<flacoste> adeuring, deryck: are we done with bug 829074? or is there some other branches that need to land?
<_mup_> Bug #829074: Show bugs that are not known to affect "official" upstream <bugs> <escalated> <qa-ok> <Launchpad itself:Fix Released by adeuring> < https://launchpad.net/bugs/829074 >
<deryck> flacoste, on call with adeuring now.  explain shortly.
<flacoste> deryck: ok
<adeuring> flacoste: there is a minimal fix in place: you can filter by upstream target, if a packaging link exists
<adeuring> flacoste: i am working on a more comprehensive fix:
<adeuring> under the label "bug 2325"
<_mup_> Bug #2325: Distro CVE report: permission denied! <lp-bugs> <Launchpad itself:Fix Released by kiko> < https://launchpad.net/bugs/2325 >
<adeuring> the idea is to porvide an option to select arbitrary upstream targets
<adeuring> well, not completely arbitrary, but any product or other source pachkage
<adeuring> erm, i meant bug 232545
<_mup_> Bug #232545: resolved_upstream list does not do product / source package matching <lp-bugs> <ubuntu-upstream-relations> <Launchpad itself:In Progress by adeuring> < https://launchpad.net/bugs/232545 >
<flacoste> adeuring: is the comprehensive fix requested by the stakeholders also?
<jcsackett> anyone else unable to use ec2 commands b/c of pqm issue? did i miss an email about something i need to change?
<adeuring> the bug report was a bit vague...
<lifeless> jcsackett: I am, abentley is/has fixed it.
<jcsackett> lifeless: ah fantastic. thanks.
<lifeless> jcsackett: I haven't tried again since, so i don't know where teh fix has gotten up to.
<abentley> lifeless: mur?
<lifeless> abentley: the pqm-submit config stacks patch
<lifeless> abentley: (IIRC the various bits correctly) - a few days ago.
<abentley> lifeless: Yes, I've fixed the lp-land command.  Does that also fix ec2 land?
<lifeless> abentley: oh, I thought it did/would :)
<lifeless> abentley: IIRC the error in ec2 land happens when it invokes bzr lp-land to get the signed email for later delivery
<lifeless> jcsackett: can you pastebin the transcript showing hte error?
<jcsackett> lifeless: sure, one moment.
<flacoste> adeuring: might be worth talking to brian and bryce about it
<abentley> lifeless: Oh, I didn't think it shelled out to lp-land.
<lifeless> it might be the thing rick has fixed
<flacoste> adeuring: just to make sure we actually implement what they need
<jcsackett> lifeless: http://pastebin.ubuntu.com/835337/
<lifeless> in which case pulling trunk will fix it
<adeuring> flacoste: ok
<lifeless> jcsackett: ah, thats not what I saw a few days back
<abentley> jcsackett: That looks unrelated to the issue I fixed.
<jcsackett> lifeless, abentley: well, darn.
<lifeless> jcsackett: that looks like what stub experienced
<jcsackett> lots of different issues cropping up here, huh? :-P
<lifeless> jcsackett: system plugin path isn't on your bzr plugins path (is all I know)
<abentley> jcsackett: Possibly pqm-submit isn't installed on the box in question.
<lifeless> jcsackett: stub filed a bug
<flacoste> adeuring: from the launchpadlib pseudo-code that Bryce shows in the bug report, i think it was fine to make this work for linked_product only
<flacoste> adeuring: best to validate with them directly
<lifeless> jcsackett: look in latest-bugs for LP
<jcsackett> pqm-submit is installed, abentley. i was hoping that was the issue too, since it was easily resolved. :-p
<adeuring> flacoste: ok
<jcsackett> lifeless: ok, thanks.
<jcsackett> lifeless: yup, i'm experiencing the same thing. thanks for pointing me to the bug report.
<sinzui> danhg, I have 3 draft posts on blog.launchpad.net. Do you want to read them?
<deryck> adeuring, abentley, rick_h -- I'm starting on the open questions now. for real. :)
<rick_h> deryck: excellent
<deryck> allenap or gmb -- if an external tracker is a Trac bug tracker, and we're syncing comments, shouldn't the status also update based on upstream bug?
<gmb> Yes
<allenap> deryck: Yes, it ought to be.
<deryck> there's no mapping required between trac and us, right?
<deryck> ah, not updated in awhile. resetting watch it is.
<deryck> bigjools or jelmer -- I've got a question about failed recipe build I don't know how to answer. Can I assign to one of you, or you point me to who? :)
<rick_h> deryck: link? jelmer was just helping someone in #lp and curious if it's the same
<deryck> rick_h, https://answers.launchpad.net/launchpad/+question/186193
<rick_h> deryck: ok, different one, nvm
<deryck> rick_h, thanks anyway :)
<bigjools> deryck: I really have NFI what's going on there.
<bigjools> other than something wants more memory than it can get
<bigjools> deryck: however, it's Java, so all bets are off, we've had this before with java builds
<jelmer> deryck: that just sounds like the issue with java using too much memory on the buildds
<lifeless> adeuring: that launchpadlib bug is a dupe of a server side bug, i forget the # though.
<lifeless> adeuring: you may want to mark it as such to avoid duplicate analysis
<adeuring> lifeless: right
<deryck> bigjools, jelmer -- ok thanks guys.  I'll find the bug and point the user at it.
<lifeless> adeuring: its almost certainly fallout from the materialised INCOMPLETE enums
<lifeless> adeuring: (but you know that :P)
<jelmer> bigjools: bug 693524 might be related
<_mup_> Bug #693524: Daily builds of Java packages fail: "Could not reserve enough space for object heap" <recipe> <Launchpad Auto Build System:Triaged> < https://launchpad.net/bugs/693524 >
<adeuring> yeah ;)
<deryck> abentley, adeuring, rick_h -- questions are all caught up.  answered or assigned them all.
<abentley> deryck: win!
<deryck> \o/
<deryck> adeuring, have you done interrupts today? ;)
<adeuring> deryck: working on roject review
<deryck> adeuring, awesome!
<deryck> adeuring, I shall quit nagging you now. :)
<adeuring> ;)
<deryck> adeuring, was about to ratchet it up to public internet shaming, but all is well now. ;)
<deryck> I had alreading registered adeuringsucksatinterruptduties.com
<deryck> :)
<mabac> rick_h, thanks for reviewing https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-model-classes/+merge/92174 . could you have a look at my update and let me know if I'm on the right track?
<rick_h> mabac: will do, sec
<mabac> rick_h, absolutely no rush. :) thanks!
<abentley> lifeless: What's the best way to examine an OOPS that occurred on a dev instance (launchpad.dev) ?
<lifeless> abentley: my preferred way is to glue oops-tools into the rabbit instance and have them come up in the normal web UI
<lifeless> any oopses before you set that up will have been tossed by rabbit (as the exchange would have had no queue attached to it)
<lifeless> on https://dev.launchpad.net/QA/OopsToolsSetup there is a 'deploying locally' section
<abentley> lifeless: I have an oops in /var/tmp/codehosting.test/2012-02-09
<lifeless> abentley: ah, interesting - must have been running without rabbit active
<lifeless> in which csae the simplest thing is dump-bson
<lifeless> sorry, bsondump
<lifeless> which is in utilities/bsondump, or if you have a buildout of oops-amqp in bin/bsondump of it
<lifeless> e.g. bsondump $path
<abentley> lifeless: cool.
<abentley> lifeless: utilities/bsondump says "No module named bson", but "bin/py utilities/bsondump" says "'module' object has no attribute 'decode_all'"
<lifeless> you can load that into the web UI if you want using datedir2amqp from python-oops-datedir2amqp
<lifeless> abentley: argh, that blows.
<lifeless> abentley: I know the one in oops-amqp works well
<lifeless> erm, wrong project :<
<lifeless> abentley: quick start:
<lifeless> branch python-oops-datedir-repo
<lifeless> link in the eggs and download-cache from your LP work area
<abentley> lifeless: I installed python-bson with synaptic, and it works with that.
<lifeless> ./bootstrap ...
<lifeless> abentley: ok cool
<rick_h> mabac: hey, sorry, was going to ping you in irc but you stepped out
<rick_h> mabac: replied to your MP, the model definition is different with stormbase
<mabac> rick_h, sorry. I'm going in and out of sessions at Linaro Connect
<mabac> rick_h, thanks. I'll check in a bit
<rick_h> mabac: I hooked you up with an example in the blueprints directory there with you
<rick_h> let me know if that doesn't help
<mabac> rick_h, awesome. thank you!
<rick_h> mabac: thank you for working on it
<mabac> my pleasure :)
<abentley> gmb: The transaction killer is not related to bug 808930 AFAICT.  The jobs are killed by the job-running infrastructure, because they run too long.  It's not length-of-transaction; it's length-of-job, which is tougher to optimize, because you'll be lucky if you only have O(n) complexity.
<_mup_> Bug #808930: Timeout running branch scanner job <escalated> <linaro> <oops> <Launchpad itself:Triaged> < https://launchpad.net/bugs/808930 >
<abentley> And with O(n) complexity, it's always possible to time out by increasing n.
<bac> hi, abentley, i've been looking around and cannot figure out the story for nested branches with bzr.  is it in 2.5?  can you point me somewhere to find out about them?
<abentley> bac: Nested trees?  Not implemented yet AFAIK.
<bac> abentley: ok.  i'd heard they were
<abentley> bac: You don't mean colocated branches, do you?
<bac> no
<bac> nested, as in the equivalent of svn externs
<abentley> bac: jelmer is planning to implement them, but he was nowhere near finished at the thunderdome.
<bac> abentley: ok, thanks
<sinzui> wallyworld_, wgrant, jcsackett, StevenK, I think this summarises my day reading the voucer/commercial subscription code: http://people.canonical.com/~curtis/wtfpm.jpg
<maxb> lol
<maxb> I shall have to show that picture to my colleagues tomorrow :-)
<StevenK> sinzui: http://pastebin.ubuntu.com/835839/
<jcsackett> sinzui, wallyworld: bug 929352 is what has hit me.
<_mup_> Bug #929352: ec2 land unable to find pqm plugin <Launchpad itself:Confirmed> < https://launchpad.net/bugs/929352 >
<sinzui> jcsackett, set the env before calling the script BZR_PLUGINS_AT=gtk@/path/to/your/plugins/pqm c
<jcsackett> sinzui: thanks!
<sinzui> ^ that is how I test plugin changes in the branch I am hacking on
<sinzui> oops
<sinzui> jcsackett, set the env before calling the script BZR_PLUGINS_AT=pqm@/path/to/your/plugins/pqm c
<wgrant> abentley: Around?
<abentley> wgrant: yes.
<wgrant> abentley: I think your bzr plugin loading changes break ec2 land
<wgrant> It can't load the pqm plugin
<abentley> wgrant: You're talking about the site-customize changes?
<wgrant> abentley: Yes. Just finding exactly what it is now.
<abentley> wgrant: wouldn't have thought that ec2* ran Launpad in-process.
<wgrant> abentley: bin/ec2 is a buildout script
<wgrant> So it uses lp_sitecustomize
<wgrant> Hmm
<wgrant> So loading lp.codehosting breaks everything.
<wgrant> abentley: Can we avoid that, or should I revert the whole rev?
<abentley> wgrant: I don't think we should avoid that.  If we do, we get weirdness where LoomBranch isn't treated as a subclass of Branch.
<wgrant> abentley: I suspect we want to rip that out of lp.codehosting, then.
<wgrant> lp_sitecustomize is imported extremely early, and pulls in no other big bit of lP.
<wgrant> Just a few isolated bits from lp.services.
<abentley> wgrant: I don't know what you're saying would be ripped out of lp.codehosting.
<abentley> wgrant: I'm sure the fact that it's loading bzr plugins is related to the fact that pqm-submit isn't loading.
<wgrant> Yeah, but separately I don't think lp_sitecustomize should be importing codehosting.
<abentley> wgrant: Okay, but the main efffect of importing codehosting is initializing the plugins.
<wgrant> abentley: True
<wgrant> Anyway, I think we have little choice but to revert this.
<wgrant> As it breaks the dev toolchain.
<abentley> wgrant: Doesn't break *my* dev toolchain, but I guess you should.
<wgrant> abentley: Have you rerun bin/buildout?
<abentley> wgrant: I don't use ec2.
<wgrant> Hah
<sinzui> wallyworld_, http://www.youtube.com/watch?v=YWMVVpOsjko
<sinzui> Its from 2005 I think
<wallyworld_> sinzui: thanks, looking now :-)
<james_w> omg buildout is annoying
<james_w> "no you can't have that"
<james_w> Error: Picked: distribute = 0.6.24
<james_w> ok, add to to versions.cfg
<james_w> Error: There is a version conflict.
<james_w> We already have: distribute 0.6.16dev-r0
<james_w> ok, so why didn't you pick that one?
<james_w> change versions.cfg
<james_w> Error: Couldn't find a distribution for 'distribute==0.6.16dev-r0'.
<james_w> but you said you already had it!
<wgrant> james_w: That's what you get for daring to use a packaged Python.
<wgrant> Upstream doesn't like distributions much.
<james_w> clearly
<james_w> we're considering migrating to buildout though
<james_w> because it's possible that other alternative suck more
<wgrant> I think buildout sucks less than virtualenv(+pip)
<james_w> I find that combination easier to use
<wgrant> In some respects.
<james_w> but I don't like the "oh, you have that version already installed? well I'm going to try installing it anyway? oh look, it's already in the download cache! well, I'll try downloading it anyway just to make sure"
<james_w> https://code.launchpad.net/~james-w/python-oops-amqp/bson-compat/+merge/92389 is what I was trying to do
* wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: wallyworld | Firefighting: - | Critical bugtasks: 4*10^2
<mabac> james_w, hi. looks to me that you need to have a little cider break ;)
<mabac> rick_h, thanks for being patient. I have pushed another change to lp:~linaro-infrastructure/launchpad/workitems-model-classes/ and hope that will work better
<james_w> mabac, heh, yeah, heading out curling now :-)
<mabac> james_w, sounds dangerous ;) take care!
<james_w> I will!
#launchpad-dev 2012-02-10
<salgado> wallyworld, hey, thanks for that review!  would you mind landing it for me as well as I don't have ec2-utils setup?
<wallyworld> salgado: np. will do it today. thanks for doing the work :-)
<sinzui> StevenK, after looking at formlibs processing of the form, visibility is excluded from the data because the input == false. So while the widget got input that we recognise as valid, it is ignored because of this "input" flag. I think "input" means the field is read-only
<StevenK> sinzui: I set readonly=true in the visibility attribute
<StevenK> I remember Zope de-praming its toys if it wasn't
<sinzui> correct, but I think out mutator rules are in conflicts with form lib
<sinzui> We may need to check the state of the widget ourselves, or as we have done before...copy a writeable field into the ITeamCreation schema
<StevenK> sinzui: I've just removed readonly=True, let's see what Zopes does.
<sinzui> StevenK, mutator will kill startup
<StevenK> Indeed
<StevenK> TypeError: Only a read-only field can have a mutator method.
<sinzui> StevenK, We know at the time of creation, we can do what we want because there is no mutation
<wgrant> Ah, yes, that's right.
<wgrant> You need to override the readonlyness in setUpFields
<sinzui> wgrant, StevenK I see the widget got the value and it was valid. are you saying setupfields did something else to say do a lot of work, but I intend to ignore it later
<sinzui> ?
 * sinzui must eat
<StevenK> sinzui: Thanks for the pointer
<StevenK> wgrant: How do I do that?
<wgrant> StevenK: See BugSecrecyEditView for a way to do it without customising setUpFields
<wgrant> The copy_field business
<StevenK> I'm tempted to do it in conditionallyOmitVisibility()
<StevenK> Then everything gets it
<wgrant> It's not appropriate to do it there.
<StevenK> class schema? Wow, really?
<wgrant> ?
<StevenK> That's what under BugSecrecyEditView does copy_field()
<wgrant> Yes.
<wgrant> I'm just wondering why you question it.
<StevenK> Seems like a horrid hack :-P
<wgrant> It's a horrid problem with a not particularly horrid solution.
<StevenK> Hmm, but TeamAddView already defines schema = ITeamCreation
<wgrant> Yay, top OOPS fixed.
<StevenK> That was Product:+index?
<wgrant> No, loggerhead's DownloadUI
<wgrant> Product:+index rarely times out now, it's just 30% slower than it needs to be.
<wgrant> And that fix is not on production yet.
<StevenK> Or even qas?
<wgrant> Correct
<StevenK> ValueError: ('Duplicate name', 'visibility')
<StevenK> :-(
<wgrant> Oh, that fixed oops #5 too
<lifeless> wgrant: so the question is where folk were getting bad links from
<wgrant> lifeless: I would tend to suspect spiders, but loggerhead OOPSes don't contain any info.
<wgrant> The access logs might.
 * wgrant hunts.
<lifeless> spiders don't make up urls though
<lifeless> so if its spiders, something is broken
<lifeless> somewhere
<wgrant> Why?
<wgrant> These are referring to fileids in head:
<wgrant> That easily linkrots.
<lifeless> true
<lifeless> downloadUI is quite new though
<lifeless> that one in particular...
<wgrant> DownloadTarballUI is now
<wgrant> DownloadUI isn't, is it?
<wgrant> s/now/new/
<lifeless> ah, right right
<wgrant> Interesting.
<wgrant> There's far fewer requests in the logs than there are OOPSes.
<wgrant> All the problematic requests are from Android
<wgrant> So I wonder if the app is looking at that URL for updates.
<lifeless> wgrant: the garbo job change landed?
<lifeless> wgrant: I take it we're doing a one-off ?
<lifeless> wgrant: hah, an android app updating from loggerhead. Aieee!!!! !!
<wgrant> lifeless: No, just the DB patch so far.
<lifeless> oh phew
<wgrant> Will be deployed on Monday
<lifeless> \o/
<wgrant> Oh, blah.
<wgrant> This is going to take forever to branch.
<wgrant> Because it has Java disease.
<wgrant> Dozens of embedded jars.
<lifeless> head-spike
<wgrant> Perhaps we can alter the LP ToS
<wgrant> To state that if you embed dependencies, your forfeit your access to LP
<wgrant> alert, alert
<wgrant> We are in the green for criticals in the last week :/
<StevenK> Isn't that a good thing?
<wgrant> It can only mean one thing: our OOPS reporting system is broken.
<lifeless> how wrong is it to call functions via exec function.__code__ in custom_globals
<wgrant> That ranks at roughly 11/10 evil points
<lifeless> it is sad when language docs need to say things like:
<lifeless> In some cases, a fruitful optimization is to assign the attribute to a local variable and call that local variable.
<lifeless> anyhow, func_code is the support attribute. win.
<wgrant> It is sad when the project is 10MB but the branch is 150MB because of the jars.
<wgrant> collectionista-library/res/values/strings-versioncheck.xml:    <string name="version_file_url">http://bazaar.launchpad.net/%7Epjv/collectionista/trunk/download/head:/collectionista_versi-20110605182324-0nll835704egr1kc-219/collectionista_versions.xml?file_id=collectionista_versi-20110605182324-0nll835704egr1kc-219</string>
<wgrant> woot
<lifeless> headdesk deskhead
<wgrant> It's a reasonably strategy.
<lifeless> not with that url
<wgrant> Strategy, not implementation :)
 * StevenK stabs NFS, and then twists the knife.
<lifeless> its a bit disappointing that the vm bypasses __getitem__
<wgrant> Grar
<wgrant> Too many bug statuses
 * wgrant becomes murderous.
<lifeless> win 3658  OOPS-11d83b82cd4d682e6c5cd63a9326e9db  Unknown
<wgrant> It's always in the top 5
<lifeless> top today
<wgrant> With a count like that I would certainly hope so :)
<wgrant> Ah, process-apport-blobs
<wgrant> Hmm
<wgrant> I think it may have a somewhat serious bug.
<wgrant> 3658 queries, 3200 of which are made up of two massively duplicated librarian reads.
<wgrant> Ah, possibly it's chunked.
<wgrant> lifeless: So, simply realising the join removes the Ubuntu FTI issue.
<wgrant> I have most sensible orders with FTI pretty fast now, even on DF.
<wgrant> I wonder if I can make a guess at how many rows there are and disable insane orders if there are too many.
<wgrant> aaaaah launchbag
<StevenK> Kill it, it's moving!
<wgrant> I have to say, it is somewhat pleasing to see dogfood reliably faster than production.
<wgrant> Oh no :(
<wgrant> My launchpad shared repo is now tainted.
<wgrant> I accidentally branches collectionista into it, so it's now covered in revolting embedded jar residue :(
<wgrant> lifeless: How are we looking for bug index bloat?
<wgrant> Oh, blah.
<wgrant> Nevermind.
<wgrant> The massive PPR regression is the bug listings release.
<wgrant> However, we have a serious xmlrpc-private regression start on the 26th and escalating since then.
<wgrant> Hm, unless it actually started on the 30th, when the session DB was put through pgbouncer.
<wgrant> But it seems to have been going slightly badly since the 27th.
<lifeless> is it just me or is js calling conventions a tad idiosyncratic
<wallyworld> StevenK: can't recall your previous issue exactly, but i can't create_initialized_view for a team with a rootsite specified eg https://blueprints.launchpad.dev/~teamname and have it render correctly
<wallyworld> is that something you ran into before?
* wallyworld changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2
* adeuring changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring | Firefighting: - | Critical bugtasks: 4*10^2
<rick_h> morning
<jelmer> hey rick_h
<jml> hello
<jml> I have a couple of questions:
<jml> Is there an IRC bot that can announce when new MPs are up on Launchpad (for a user-defined set of projects)
<wgrant> jml: I think Landscape has one.
<jml> Would it be OK if I amend an existing IRC bot to do this? Are there any guidelines for the inevitable polling that I will have to do?
<stub> jml: Rabbit FTW
<jml> stub: Rule Britannia.
<stub> jml: txlongpoll + rabbit if not running in our DC
<jml> stub: do you mean that I can actually set something up today that wait for events from Launchpad and not run in the DC?
<stub> jml: It is used by the merge proposal page at the moment to load the diff as soon as it is available, so all the pieces are in place.
<jml> stub: I don't see that behaviour...
<wgrant> It's restricted to ~launchpad until it's ready.
<jml> stub: also, that sounds suspiciously like a "No, not yet"
<stub> jml: It means in theory yes, in practice ask the people who implemented it :)
<jml> stub: heh, ok.
<jml> wgrant: ok. I'll make a note to come back and ask about this some time in the future.
<jml> wgrant: I feel a bit stupid for asking, but, any guess on when it'll be opened up to a broader group?
<wgrant> jml: There's one current show-stopping bug which I might get bored and illicitly fix at some point.
<jml> wgrant: ok, thanks.
<wgrant> In fact, why don't I try to fix that now.
 * wgrant fixes.
<matsubara> hey guys, I replied to a merge proposal by email but my reply didn't show up in the web ui. should I have signed the email?
* bac changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: adeuring, bac | Firefighting: - | Critical bugtasks: 4*10^2
<bac> hello adeuring
<bac> matsubara: i did the same yesterday with this MP:  https://code.launchpad.net/~frankban/charms/oneiric/buildbot-slave/02-09/+merge/92340 . you'll see my second comment showed up just fine.  the email was unsigned.
<bac> but i wondered as i hit 'send'
<matsubara> how strange. In any case I copy and pasted my reply into the MP
<adeuring> morning bac
<StevenK> rick_h: O hai. You agree with my Evil Plan?
<rick_h> StevenK: your plan works for me I believe
<rick_h> and I can start landing fixes like a mad man once that's there and we get some testers
<StevenK> rick_h: One thing I'd love for you to look at is why the AJAX drop-down doesn't work.
<rick_h> orly? ok, where is this?
<rick_h> is there a bug to look at?
<StevenK> rick_h: On any page, it's the green "AJAX log" next to your name.
<rick_h> oh that, ok. I'll peek
<StevenK> rick_h: It's only shown for us, but it hasn't worked since our fixes from the epic were deployed
<StevenK> rick_h: I'm guessing it's something trivial
<rick_h> StevenK: ok, I had hoped it was part of the single LPJS thing
<StevenK> So had I
<StevenK> It wasn't. :-(
<rick_h> if it's still broken today, then I'll peek at it
<StevenK> rick_h: I'm not sure if there is a bug. wgrant may have filed one.
<rick_h> k, I'll look, thanks for the heads up
<StevenK> rick_h: Do you also want to prod sidnei to review my convoy branch? :-)
<rick_h> ah ok, I haven't peeked over there. Will do.
<rick_h> StevenK: he's in Brazil so should be mid day now I tink
<rick_h> think*
<rick_h> StevenK: ok, didn't see a bug, so added one and got the card on the board
<StevenK> rick_h: I'd be very curious to find out what the issue was.
<jelmer> what's the best way to check if a call exercises the database again?
<StevenK> In a test?
<jelmer> StevenK: yep
<jelmer> I'm testing to see if something that's supposed to cache will actually cache
<StevenK> jelmer: Right, we have an existing pattern for that. Have a grep for StormStatementRecorder
<jelmer> StevenK: I don't recall seeing that before, is it new?
<jelmer> StevenK: either way, that seems to be exactly what I'm looking for - thanks!
<StevenK> I think it's been around for a little while
<rick_h> StevenK: sidnei is +1'ing your MP
<StevenK> rick_h: Sweet. Feel free to merge it in
<rick_h> will do
<StevenK> Then we should automagically get a new version of convoy in the PPA.
<rick_h> StevenK: awesome
<gary_poster> jelmer, hi.  Congrats on colocated branches!  Where do we read about how to use them?
<jelmer> gary_poster: Hi
<jelmer> gary_poster: they're not really prime-time material yet; most of the documentation there is can be found in my last post on them to the bazaar mailing list
<gary_poster> jelmer, ok.  So should we not try to rely on them?
<jelmer> gary_poster: their format is stable, but the support in the UI is still a bit awkward
<gary_poster> jelmer, hm, ok.  I'll review the post and see if we can give it a whirl.  I'm guessing testers would be good. :-)
<gary_poster> thank you
<jelmer> gary_poster: yep, definitely - thanks :)
<jelmer> gary_poster: see also the list of bugs tagged 'colocated' in bzr
<wallyworld_> jelmer: colocated branches are not new are they? i've been using branches switching between a single working tree ever since i started
<wallyworld_> lp is too large to do anything else imo
<wallyworld_> plus it suits modern IDE's
<jelmer> wallyworld_: colocated branch support in bzr itself is new
<jelmer> wallyworld_: perhaps you mean bzr-colo?
<wallyworld_> yes, i think that's what i meant
<bigjools> wallyworld_: jelmer: bzr switch I suspect?
<wallyworld_> bigjools: yes, i use bzr switch
<bigjools> me also
<wallyworld_> with a single working tree, and no-tree branches
<wallyworld_> i'm not 100% sure what colocated branch support is, have to rtfm
<jelmer> wallyworld_: switching a single working tree between multiple branches has been supported for a long time
<jelmer> this is just the support for having the branches live in the same location as the tree
<jelmer> rather than having to have a separate shared repo with the branches elsewhere
<wallyworld_> ah, ok. i follow now. thanks for the extra explanation.
<jelmer> hi adeuring, bac
<wallyworld_> although for my use, i want the branches and working tree separate
<adeuring> hi jelmer
<bac> hi jelmer
<jelmer> would either of you have time for the review of a small branch?
<jelmer> https://code.launchpad.net/~jelmer/launchpad/branchjob-cache-authors/+merge/92470
<adeuring> jelmer: sure
<jelmer> wallyworld_: why do you need to have them separate?
<jelmer> adeuring: thanks!
<wallyworld_> jelmer: i like the working tree to be "pure" and not have extra VCS directories in it like with svn or cvs. but i guess if they are hidden then it's ok
<wallyworld_> jelmer: so now i have a lp-branches dir, and all my branches are directories named after the branch containing .bzr etc, and my working tree sandbox is nicely uncluttered
<jelmer> wallyworld_: that's still the case with colocated branches, they all live under .bzr/branches
<wallyworld_> ah, ok. then that sounds cool :-)
<wallyworld_> although now i can ls to see what my branches are easily
<wallyworld_> and use ls -lort to see what the most recently checked out one is
<adeuring> jelmer: r=me
<jelmer> adeuring: merci :)
<jelmer> wallyworld_: the difference once it's set up is quite small
<jelmer> wallyworld_: we have a 'bzr branches' command that can list all branches and pinpoint which one is active at the moment
<jelmer> wallyworld_: the main advantage in colocated branches vs the the traditional setup with a lightweight checkout and shared repository, is that it requires less setup
<jelmer> wallyworld_: you can just go "bzr branch lp:foo" and then run "bzr switch -b newbranch" in the resulting directory
<wallyworld_> makes sense. atm i just go "bzr switch ../foo" to changes branches so i guess it comes down to what you are used to
<wallyworld_> the setup was a one time thing, not too onerous from memory
<wallyworld_> but anything to make it easier is good :-)
<wallyworld_> the reason i like ls -lort is that sometimes i need to recall what the last few branches were that i worked on because i need to switch back to one and can't recall it's name
<deryck> adeuring, abentley, rick_h -- https://plus.google.com/hangouts/extras/talk.google.com/orange-standup
<deryck> superspeed standup today.
<rick_h> deryck: ok
<deryck> I'm stuck waiting on plugin in FF.  switching
<deryck> abentley, adeuring, rick_h -- I'm back now.
<adeuring> ack
<abentley> deryck: Cool.
<rick_h> deryck: yay
<deryck> rick_h, hey, so just to be clear, you don't need reviews from me now, thanks to wallyworld_ right?
<rick_h> deryck: not for those two, I'm making the changes there and will put up the next set for you :)
<deryck> rick_h, rockin'! :)
<rick_h> deryck: 3 is up, 4 says conflicts to looking into that
<abentley> deryck: talk in 2 minutes?
<deryck> abentley, yup.  firing up a hang out now.
<deryck> abentley, actually, warming coffee.  but here's the linkâ¦.  https://plus.google.com/hangouts/extras/talk.google.com/go-for-deryck
<rick_h> deryck: ok, branch 4 is fixed and pushed as well and setup for review
<deryck> rick_h, I'm working on them now.
<rick_h> deryck: let me know where to send the beer to in payment
<deryck> rick_h, not necessary. :) It's actually easy to review this stuff to me.
<rick_h> hah, you say that now! I know my steam is slowing down in writing it, I'll bet the review does as well :P
<deryck> rick_h, r=me for #3 branch.
<rick_h> deryck: ty much
<deryck> rick_h, it helps that I'm a really fast reader anyway, and I know these tests really really well. :)
<rick_h> I like to remind myself that the worst I can do is cause a test failure because I broke it really
<deryck> rick_h, yup. it's really a very safe change, despite the diff size.  r=me on #4.
<rick_h> deryck: ok thanks.
<rick_h> deryck: since 5 is just the html files getting a lot more files into there, still working. Almost done with /bugs/
<rick_h> so I'll be back! bwuhahahaha
<rick_h> lol, there's a 'test_me_too.js' never noticed that one
<sinzui> bac, do you have time to review changes to commercial subscription rules: https://code.launchpad.net/~sinzui/launchpad/apply-commercial-subscription/+merge/92547
<bac> sinzui: yes
 * james_w curses incompatible bson libraries
<salgado> rick_h, hi there. when you have a minute, we could do with another review on https://code.launchpad.net/~linaro-infrastructure/launchpad/workitems-model-classes/+merge/92174 :)
<rick_h> salgado: loading up
<beuno> so
<beuno> this new thing of not changing the URL when a merge proposal is files
<beuno> *filed
<beuno> and it still being +register-merge
<beuno> is tehre a bug yet?
<rick_h> salgado: looks good, passed onto jcsackett for final ok
<rick_h> salgado: thanks for both of you for the updates to the storm way vs sqlobject way.
<salgado> rick_h, thank you for the reviews! :)
<lifeless> james_w: patches...
<james_w> lifeless, unpossible!
<james_w> I think we'll just have to cut oops-* over to pymongo everywhere
<lifeless> james_w: I'm no particular objection to that
<james_w> yeah
<james_w> I'm just not sure how for the tendrils will stretch yet
<lifeless> everywhere.
<lifeless> muhhahahhahhahahha
<james_w> for instance, we may end up deleting the rfc serializer as part of the change
<lifeless> why ?
<lifeless> I mean, no great loss IMO, but why?
<james_w> because this will change the semantics of what you get back from oopses
<lifeless> how so ?
<james_w> pymongo always returns naive datetimes
<lifeless> what?!
<lifeless> thats totally bogus
<lifeless> also error prone
<lifeless> do they have a fixed point of reference? or does stuff build on mongo vary by the tz of your server?
<lifeless> so, ok, I do have an objection.
<lifeless> *this*
<james_w> everything in the serialized form is UTC
<james_w> with the rule that you can't put a naive datetime with a non-UTC tz as input
<lifeless> naive has no tz
<lifeless> so that rule doesn't make sense to me
<james_w> it has an unrecorded tz
<lifeless> you *can't tell* if someone is messing up if you accept naive tz's
<james_w> "everyone that decodes the bson will assume that datetimes are UTC, so don't break that assumption for them"
<lifeless> hahahahahaha
<james_w> so we're back to...
 * james_w curses incompatible bson libraries
<lifeless> if they were here, I would say to the authors: "There is a way to do that in python, its called tz aware datetimes"
<lifeless> I mean really, it is astonishingly bad
<james_w> lifeless, you do realise that the bson library already in use does pretty much the same thing?
<james_w> it just returns non-naive datetimes
<james_w> http://paste.ubuntu.com/836939/
<lifeless> yes, thats the right way
<lifeless> strict on emission, broad on acceptance but tell folk they are being daft
<james_w> they just add a warning, and return a non-naive datetime with the same assumptions
<lifeless> yes
<lifeless> the wire protocol is defined as being utc
<lifeless> which is great
<lifeless> so, we could warap pymongo, we could give them a patch providing an option for folk that want nicer coding environmens
<james_w> aha
<james_w> there's an option
<lifeless> cool
<james_w> https://code.launchpad.net/~james-w/python-oops-datedir-repo/bson-compat/+merge/92560
<lifeless> amqp coming soon I presume ?
<james_w> already done
<lifeless> \o/
<lifeless> james_w: wait, what? :)
<james_w> https://code.launchpad.net/~james-w/python-oops-amqp/bson-compat/+merge/92389
<timrc> flacoste, I must be living in the past because it says this policy was approved 17th Feb 2012.. https://dev.launchpad.net/PolicyAndProcess/MaintenanceCosts :)
<flacoste> lol
<flacoste> timrc: nah, it's only lifeless living in the future
<timrc> flacoste, that oddly makes sense..
<timrc> :)
<flacoste> but he's usually only one day ahead
<flacoste> i think he must have made a breakthrough in his timewarp machine
<bac> sinzui: done.  sorry for the delay
<sinzui> That okay, I almost have my next branch complete
<lifeless> bah no
<lifeless> its me confounding dates
<sinzui> The cursing and screaming upstairs in English, German, and Japanese, can mean onyl two things. Firstly, I taught my daughter well, and secondly, she has reached the mind-f**k ending of Evangelion You Shall Not Advance.
<jelmer> sinzui: :)
<sinzui> I just advanced the film to the closing scene after the credits. She at lease knows that world will not end.
<lifeless> sinzui: :)
<lamalex> Hey, is this right place to ask questions about the API usage, or is that better suited for #launchpad
<lamalex> i'm trying to copy from a PPA into another from a jenkins job, a python script seems best (but if there's a better way please let me know!)
<lifeless> lamalex: #launchpad
<sinzui> bac: I think you are about to EOD, but if you have time I have a branch that could be reviewed: https://code.launchpad.net/~sinzui/launchpad/contact-team/+merge/92589
<bac> sinzui: probably.  otp atm
<bac> sinzui: i don't understand this comment in the MP
<bac> ADDENDUM: I cannot 'hit' the cancel link. I do not think the cancel
<bac>       is a verb and suffices.
<bac> sinzui: can you clarify?
<sinzui> bac The text instructs me to "hit" "cancel"
<bac> ohhh
<sinzui> bac https://launchpad.net/~lifeless/+contactuser
<sinzui> ^ We might have had a Cancel button in the past
<bac> it should read 'hit lifeless' ?
<bac> sinzui: thanks.  that makes sense now.
<sinzui> I press keys and tap buttons. maybe I should tap lifeless
<bac> hmm, maybe not
<bac> sinzui: done
<bac> sinzui: my stupid irc client won't let me edit the topic.  would you remove abel and me from the topic, please, while i go search for a less dumb client?
* sinzui changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: - | Firefighting: - | Critical bugtasks: 4*10^2
<sinzui> done
<lifeless> rick_h: ola!
 * wgrant glares at the Web.
<wgrant> But I think I have three ways of inter-tab communication that cover all major browsers except maybe IE...
<wgrant> s/cover/together cover/
<lifeless> wgrant: sweet
<lifeless> wgrant: evil. But sweet.
<lifeless> wgrant: and if you are around; I have some js questions; up for a [briefish] voice call ?
<wgrant> lifeless: Well, since we can't reasonably maintain one connection per tab, there's not much other choice. And only one of the ways is evil.
<wgrant> Sure
<lifeless> hangout invite sent
<wgrant> I've not used one before, but let's see how it goes...
<lifeless> ah, you'll be a minute installing the binary blob plugin then
<lifeless> (yes, twitch)
<wgrant> wtf
<wgrant> Do invites show up somewhere?
<wgrant> I don't have an email.
<wgrant> Ah
<wgrant> In the unified Google bar of stupidity.
<wgrant> "Installing Google voice and video chat will add the Google voice and video chat repository so your system will automatically keep Google voice and video chat up to date."
<wgrant> wtf is this shit
<lifeless> its the HTML5 web
<wgrant> I wonder if I can apparmor this to death.
<wgrant> wtf plain http download link
<lifeless> if you do, submit a patch to the ubuntu apparmour config!
<wgrant> Aha, there's one on the wiki already.
<lifeless> internal?
<wgrant> Yeah :(
<wgrant> Firefox has hung twice, but it seems to be loading...
<lifeless> wgrant: anything in dmesg ?
<lifeless> wgrant: also check top; precise has a horrible habit of *not killing hung things*
#launchpad-dev 2012-02-11
<wgrant> lifeless: Doesn't work even unconfined as a proper package installed (in a VM) :/
<wgrant> Can you Skype?
<lifeless> sure
<lifeless> though I can't alt-tab to it under precise. NO idea why
<rick_h> lifeless: what's up?
 * rick_h looks to make sure I haven't broken anything 
<lifeless> rick_h: no, I wanted to sanity check my brain w/js
<lifeless> rick_h: I nabbed wgrant as another js-head for that :>
<rick_h> ah, okie then
<wgrant> Unfortunately I just made the problem worse :)
<lifeless> rick_h: getting my head around handlebars, and it has some really uhm crazy stuff
<rick_h> heh, any example? I'm curious
<lifeless> block helpers are called with a function which has had attributes on it - so options.fn === fn, for instance.
<rick_h> yea
<wgrant> options.fn === options
<lifeless> 'tasteless' is one way to describe that
<lifeless> also two typos in two answers, so I'm clearly not awake enough yet to be programming.
<lifeless> I'm going to go fly some spaceships
<wgrant> Heh
<rick_h> hmm, looking at handlebars, but not seeing it. In base.js I see it registering helpers, which have a second arg options and it can have a fn in it
<rick_h> if you guys have a link/line # handy be curious about the 'tasteless' bits
<rick_h> hmm, fly spaceships. I should get started on the book club book tonight. Hope they didn't pick a dud
<wgrant> rick_h: populateParams in compiler.js
<rick_h> ah, thanks
<wgrant> It sets tmp1 to the function, then conditionally adds various unrelated bits of data to it.
<rick_h> geeze, could they leave out any more comments
<wgrant> Basically it looks like they initially specified block helpers to take a function, but then realised they needed more so they decided to add unrelated attributes to the function.
<wgrant> Yeah
<wgrant> Does that file have even a single comment line?
<rick_h> wgrant: yea, makes sense
<wgrant> Oh, it does have a couple.
<rick_h> yea, // HELPERS
<rick_h> woot, I feel aided by the comment
<rick_h> ah, interesting. Makes sense I guess. Means they don't have to maintain/change code elsewhere. Normally you'd just move that data up in scope.
<rick_h> or deal with various arguments length checking stuff
<lifeless> rick_h: doing it one way or the other would be fine
<lifeless> rick_h: they do *both*
<lifeless> rick_h: -> fugly
<StevenK> lifeless: I didn't want the convoy tests module installed in the deb package, and I didn't want to wield rm in the build step.
<lifeless> StevenK: I'd do what bzr does then, generate two packages
<StevenK> lifeless: I'll make a note to have a quick look on Monday
<lifeless> ok, so after all the fuss about 'classic twitter/new twitter' they go and change it (roughly) back. grah
<wgrant> Oh?
<lifeless> you don't have a new layout ?
<wgrant> Doesn't look radically different from before, AFAICT.
<lifeless> click on a tweet
<wgrant> Ahh
<wgrant> indeed
<lifeless> and click on the tweeters name
<nigelb> some changes are good.
<nigelb> like, now its easiser to find if someone follows you.
<nigelb> also, conversations are win!
<wgrant> Are they as good as identi.ca's yet?
<nigelb> Nope!
<lifeless> sure
<lifeless> I wasn't saying good/bad
<lifeless> just that they spent /how long/ socialising the other change, letting folk opt in then opt out before finally forcing it
<lifeless> and this, they just do.
<lifeless> it is interesting
<nigelb> You mean the first new twtter?
#launchpad-dev 2012-02-12
<wgrant> lifeless: Around?
<lifeless> yes
<lifeless> wassup
<lifeless> wgrant: ^
<wgrant> Was wondering if you could try https://pastebin.canonical.com/59988/ on qastaging. It takes >100ms in OOPS, but 10ms when run in psql on DF.
<wgrant> I wonder if person descriptions are big.
<wgrant> Monday's OK too :)
<wgrant> lifeless: ^^
<lifeless> 218.988ms on wildcherry
<wgrant> :/
<wgrant> Thanks
<lifeless> 100ms in explain analyze
<lifeless> but still ~200 when rerun as a normal query
<lifeless>  Total runtime: 4.484 ms
<lifeless> (23 rows)
<lifeless> Time: 78.842 ms
<wgrant> Heh
<lifeless> note the startup vs exec difference - we've seen this before
<wgrant> Planning overhead?
<lifeless> IIRC it was stats access stuff
<wgrant> Yeah
<wgrant> We ran into this when we increased the stat sizes.
<lifeless> should be a UNION ALL
<wgrant> No, it shouldn't exist at all :)
<lifeless> yeah, 77ms to do the explain
<lifeless> (not explain analyze - just explain)
<wgrant> Right.
<wgrant> (this is person.administrated_teams, as called by the structural subscriptions JS to populate a form field on most structural subscription context pages)
<lifeless> what is this checking (my brain is to whacked to reverse engineer the meaning)
<lifeless> too
<lifeless> so, its checking tp + membership to find the admins ?
<lifeless> the second clause looks odd to me
<lifeless> ah, owned by any team the person is in
<wgrant> It's checking for membership in an admin or an owner
<lifeless> so first clause is 'in the team as an admin' and the second is '...
<lifeless> the sort shouldn't be there
<wgrant> Well
<wgrant> It wants a sorted list.
<wgrant> The issue is probably more that the query shouldn't be there.
<wgrant> Because I suspect that form is used on <0.1% of requests
<lifeless> ah, for subscribe a team ?
<lifeless> sure, I buy that too
<wgrant> And of the times that form is used, about 1% are probably for teams.
<wgrant> And of those, about 20% are probably not misguided :)
<lifeless> its the first clause that is an issue - the one with tm
<lifeless> 188K rows, so its now exactly huge
<wgrant> Should be an index scan down TP, into a 200-row read from TM, filtering down to a few rows, which then are read from person
<lifeless> it runs in 2.6ms
<lifeless> it plans in 70->140ms
<wgrant> Hah
<lifeless>  Nested Loop  (cost=0.00..753.27 rows=2 width=633)
<lifeless>    ->  Nested Loop  (cost=0.00..748.78 rows=2 width=4)
<lifeless>          ->  Index Scan using teamparticipation_person_idx on teamparticipation  (cost=0.00..147.56 rows=114 width=4)
<wgrant> That's a bit of worry
<lifeless>                Index Cond: (person = 21997)
<lifeless>          ->  Index Scan using membership_person_key on teammembership  (cost=0.00..5.26 rows=1 width=8)
<wgrant> As it touches like 4 tables.
<lifeless>                Index Cond: (teammembership.person = teamparticipation.team)
<lifeless>                Filter: (teammembership.status = 3)
<lifeless>    ->  Index Scan using person_pkey on person  (cost=0.00..2.23 rows=1 width=633)
<lifeless>          Index Cond: (person.id = teammembership.team)
<lifeless>          Filter: (person.merged IS NULL)
<lifeless> (10 rows)
<lifeless> 3
<wgrant> Right, that's what I would have done :)
<lifeless> I want 'explain explain'
<wgrant> Heh
<wgrant> Also, I want to talk to you next week about weaning SSO.
<wgrant> If you have time.
<lifeless> that would be wuverly
<lifeless> gotta get it on solids first
<wgrant> I got it mostly working on the way back from Budapest, but there are availability and performance concerns.
<lifeless> right
<lifeless> so lets talk early in the week
<lifeless> get me across the parameters
<wgrant> Yep
<lifeless> and I will either talk with, or setup a conf with, the sso folk
<lifeless> depending on $stuff, $timing etc
<wgrant> Thanks.
<lifeless> de nada :)
<wgrant> lifeless: Can you see any reason that person validity checks should require a search for a preferredemail, rather than having a constraint that account_status == ACTIVE => there is a preferredemail?
<wgrant> Trying to kill off validpersoncache and all these stupid repeated emailaddress.status == 4 queries.
<lifeless> uhm
<lifeless> do we change account_status -> inactive if the last email address gets invalidated ?
<lifeless> wgrant: I suspect the question needs to be put to the list; or we need to do some re-analysis; I don't have an easy answer.
<wgrant> lifeless: The only thing that can now cause the last email to be invalidated is deactivation/suspension.
<wgrant> lifeless: And those two only do it because the lack of a preferredemail is how we determine that a person is invalid.
<lifeless> wgrant: I think we'd want some safeguard to ensure consistent data
<lifeless> but I see no reason why we shouldn't trust the status field if we do that
<wgrant> "having a constraint that account_status == ACTIVE => there is a preferredemail"
<lifeless> something like that yes
<lifeless> a preferred validated mail
<lifeless> blah, youknowwhatImean
<wgrant> preferred => validated, but yeah
<nigelb> StevenK: watched cricket? :D
<StevenK> nigelb: No. But I saw the result.
<nigelb> :D :D
<lifeless> (ht spm: http://blog.markwshead.com/1148/design-problem/)
<wgrant> Yay, sinzui did most of my QA
<lifeless> not what I expected https://launchpad.net/lca
<wallyworld_> lifeless: there's a branch of python-oops-amqp ready to be merged into trunk make release 0.0.6 (i haven't done the merge yet). but i don't have pypi permissions to create a release. is that something you can do?
<StevenK> wallyworld_: Can haz some QA?
<wallyworld_> sure, just getting a couple of things done
<lifeless> wallyworld_: whats your pypi userid ?
<wallyworld_> lifeless: wallyworld
<lifeless> wallyworld_: also, you need to actually merge, else trunk shows all the intermediate work.
<wallyworld_> ok
<lifeless> wallyworld_: added you as maintainer; should let you do it
<wallyworld_> lifeless: thank you muchly
<lifeless> de nada
<lifeless> would love a team-plugin for pypi
#launchpad-dev 2013-02-04
<StevenK> I've spent a few minutes trying to work out where file uploads are handled in lazr.restful
<wgrant>         file_content=Bytes(constraint=productrelease_file_size_constraint),
<wgrant> So it'll be in the Bytes handler
<wgrant> Support was only added relatively late, AFAICR
<StevenK> wgrant: ... which I can't find in lazr.restful
<wgrant> class BytesFieldMarshaller(SimpleFieldMarshaller):
<wgrant> (is it just me, or does lazr.restful have marshall/unmarshall around the wrong way?)
<StevenK> wgrant: I can't see anything in either BytesFieldMarshaller or SimpleFieldMarshaller that would call _decode
<wgrant> StevenK: No, so you'll have to trace through to see how it happens
<wgrant> And why it doesn't happen for normal file uploads
<StevenK> wgrant: Hmmm, pdb.set_trace() inside IProductRelease.addReleaseFile() is probably far too late
<wgrant> StevenK: Probably, but it might vaguely hint where it could get the data
<wgrant> I'd rather break in the Bytes (un)marshaller
<StevenK> wallyworld___: https://lh6.googleusercontent.com/-awustg4A1HQ/UQ1pZ49aYjI/AAAAAAAB0_k/ZXhib0JPDXQ/s728/YoomaShreddedBedText.jpg
<wallyworld___> what you saying 'bout me?
 * StevenK stabs this script
<StevenK> Unknown consumer (System-wide: Ubuntu (undermined)).
<mwhudson> undermined? :)
<StevenK> mwhudson: Matches my current naming scheme
<StevenK> wgrant: How can I debug Unknown consumer?
<wgrant> StevenK: Probably means your gnome-keyring has a token that your Local DB no longer has
<wgrant> Assuming it's not production
<StevenK> It's dev
<wgrant> Right
<wgrant> Poke around with seahorse
<wgrant> And delete the key that is no longer valid
<StevenK> Right, deleted two of them
<StevenK> The authorization page:
<StevenK> ...
<StevenK> Success!
<wgrant> Great
<StevenK> Hmm, but my pdb did not fire
<StevenK> Oh
<StevenK> I edited the wrong version
<wgrant> Hah
<StevenK> wgrant: http://pastebin.ubuntu.com/1606599/
<StevenK> I can't see the tarball content being called in _decode, but the GPG sig is
<wgrant> StevenK: You might have to look through the code to see how lazr.restful gets its values, and how Zope forms do it differently.
<wgrant> Because Zope forms clearly don't use the decoded version
<StevenK> Hmmm
 * StevenK stabs lazr.restful for being obstreperous.
<StevenK> wgrant: QA could be fun
<wgrant> Quite
<wgrant> StevenK: SPRB and TTB are populated on DF, BPB is about 1/3 done...
<StevenK> Wow
<StevenK> Nice
<wgrant> It's been going for about 3 hoursish, though
<wgrant> Or 2
<wgrant> Something like that
<StevenK> Bleh
<StevenK> launchpadlib, forget your auth token!
<StevenK> wgrant: Is DF done?
<wgrant> No
<wgrant>  f        | 2112345
<wgrant>  t        | 1721777
<wgrant> Almost half way
<StevenK> wgrant: Put me out of my misery trying to work where lazr.restful gets it values from?
<wgrant> StevenK: ResourceOperation.validate
<wgrant> (I just stuck a pdb.set_trace() in addReleaseFile, called it with lp-shell, and looked through the traceback to see what would be parsing args)
<StevenK> Bleh, I did that too, but didn't see ResourceOperation there
<wgrant> It wasn't
<wgrant> Well, I guess it was
<wgrant> But that method wasn't
<StevenK> Unknown consumer again! And Seahorse is unhelpful
<wgrant> You probably nuked your DB
<wgrant> Or it expired
<StevenK> I did nuke my DB
<StevenK> Your denorm columns not existing required a make schema
<wgrant> Or a database/schema/upgrade.py :)
<StevenK> I will usually just run make schema
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/flatten-bfj-5-app-cleanup/+merge/146349 is a big bit boring and mostly red diff
<StevenK> And contains two conflicts
<wgrant> Pretend they're not there, and I'll fix them as I merge the pipe :)
<StevenK> 183>>>>>>> MERGE-SOURCE
<StevenK> Haha, looks like they're earlier up the chain
<StevenK> wgrant: PackageBuildMixin does not die yet?
<wgrant> StevenK: It never dies
<wgrant> It's a mixin
<wgrant> Used for functionality that's shared between BPB and SPRB
<wgrant> Like uploads and such
<StevenK> Possibly rename it? Or you don't care enough?
<wgrant> Hmm?
<wgrant> It's a mixin for package builds
<wgrant> So PackageBuildMixin seems like an apt name.
<StevenK> Fairy nuff
<wgrant> Did you have an alternate suggestion?
<StevenK> No, was just trying get the name 'PackageBuild' killed everywhere
<StevenK> wgrant: Oh, when does IPackageBuild die?
<wgrant> StevenK: It doesn't
<wgrant> It's an interface for package builds
<StevenK> wgrant: So IBinaryPackageBuild will also implement IPackageBuild ?
<wgrant> StevenK: It in fact inherits from it
<wgrant> BinaryPackageBuild implements it, with the help of PackageBuildMixin
<StevenK> Right
<StevenK> wgrant: r=me
<wgrant> Thanks
<cjwatson> Has anyone had a chance to look at https://code.launchpad.net/~cjwatson/launchpad/bpph-phase/+merge/144154 ?  I have another piece of work to do that touches some of the same code, so it would be nice to get this out of the way.
<wgrant> cjwatson: Oops, sorry
<wgrant> Should have time to look at that tomorrow
<cjwatson> Great, thanks
<wgrant> StevenK: Can you QA 16468 tonight?
<wgrant> Should be on qas shortly
<StevenK> Is now, apparently
<StevenK> wgrant: Done
<wgrant> StevenK: Thanks
<wgrant> We shall garbo it up on prod tonight
<StevenK> wgrant: All gree
<StevenK> *green
<adeuring> good morning
 * mpt rediscovers bug 533044
<_mup_> Bug #533044: Resummarizing bug report doesn't change page title <lp-bugs> <ui> <Launchpad itself:Triaged> < https://launchpad.net/bugs/533044 >
#launchpad-dev 2013-02-05
<StevenK> wgrant:
<StevenK> (Pdb) p hasattr(item, 'file')
<StevenK> True
<StevenK> (Pdb) p hasattr(item, 'filename')
<StevenK> True
<wgrant> StevenK: Is the filename non-empty?
<StevenK> Nope
<StevenK> It's None
<wgrant> Aha
<wgrant> So
<wgrant> Compare the requests that are sent
<StevenK> I wonder about lazr/restful/_bytestorage.py
<wgrant> StevenK: That's a Resource
<wgrant> Not relevant here
<wgrant> (though you should probably also test it, it's probably fine as it will just use the raw body)
<StevenK> BLEH
<StevenK> The traceback does not show lazr.restful's call
<StevenK> Just the WSGI and the zope publisher
<wgrant> Which traceback?
<StevenK> The pdb I have in zope.publisher.browser
<StevenK> I was hoping to get a clue what called it
<wgrant> That's before lazr.restful, usually
<StevenK> Oh, then what forms this request?
<wgrant> StevenK: lazr.restful interprets the request
<wgrant> After it gets through the normal Zope request stuff, which eventually decides that it's an API request
<StevenK> So it could be launchpadlib itself, then?
<wgrant> StevenK: Right, I'd examine the POST request it makes
<wgrant> Using httplib2.debuglevel
<StevenK> httplib2.debuglevel seems to be working great. Not.
<wgrant> StevenK: You need to set it before you instantiate the launchpad object
<StevenK> Oh
<StevenK> wgrant: http://pastebin.ubuntu.com/1611158/
<StevenK> That looks wrong already
<wgrant> Yeah, there's the problem
<StevenK> So it could be lazr.restfulclient?
<wgrant> It is, yes.
<wgrant> So we ideally want to fix it and work around on the server side too
<wgrant> Although I'm not quite sure what lazr.restfulclient can do
<wgrant> It doesn't necessarily have a filename
<wgrant> It may be better to see if addReleaseFile can somehow obtain the request, and get the file out somewhat manually
<wgrant> Or we could make lazr.restful do that
<StevenK> I was thinking we could change lazr.restfulclient to set a filename of 'bytestream' or something like that
<wgrant> We have to do something server-side anyway
<StevenK> What are you thinking?
<wgrant> We need to either fix lazr.restfulclient to send the header and fix the server to reject the request if the content is a unicode, thus making everyone upgrade... or we can fix lazr.restfulclient for the future and make the server grab the str directly from the request, bypassing the decoded value
<StevenK> Sounds like you prefer the second option.
<wgrant> We want to avoid breaking clients if we can.
<StevenK> wgrant: Does that bug have enough branches linked to it?
<wgrant> No
<wgrant> I could link the 5-10 I landed before I started linking things if you want :)
<StevenK> Haha
<StevenK> wgrant: QA and deployment, or what is your plan?
<wgrant> StevenK: Hahahaa no deploying now would be suicide
<StevenK> There is still stuff to land?
<wgrant> There's about a dozen indices to go
<wgrant> Working through the last few pages now
<StevenK> Right
<StevenK> Hmm, now. How to get at the request
<StevenK> (Pdb) p request
<StevenK> <lp.services.webapp.servers.LaunchpadTestRequest instance URL=http://launchpad.dev>
<wgrant> did you use get_current_browser_request()?
<StevenK> Yeah
<StevenK> Still trying to figure out what I want to pull out from it
<wgrant> Yeah, I'm not quite sure
<wgrant> Look at how BrowserRequest.__processInput gets stuff
<StevenK> That iterates over items()
<StevenK> I think
<StevenK> But items() for these LTRs is not helpful
<wgrant> Or it might no longer be helpful
<wgrant> It's possible that it gets consumed
<StevenK> It looks to play with self._environ, and then throws that to ZopeFieldStorage
<StevenK> request._environ has stuff in it, but nothing of any use
<wgrant> It doesn't use request.read()?
<wgrant> The FieldStorage itself might do that
<StevenK> *** AttributeError: AttributeError("'LaunchpadTestRequest' object has no attribute 'read'",)
<wgrant> Well, it's something like that
<wgrant> Maybe request.body.read()
<wgrant> Anyway, can you obtain the ZFS?
<StevenK> I don't think the ZFS is saved anywhere
<StevenK> So I think the answer is no
<wgrant> :(
<wgrant> Also, if I was to come up with a list of good ideas, reading the file into RAM would not appear on it
<StevenK> Bah, RAM is cheap
<StevenK> :-P
<StevenK> wgrant: http://pastebin.ubuntu.com/1611231/ not sure if the request is actually helpful
<wgrant> StevenK: The environment won't be useful for the request body, no
<StevenK> But that's what ZFS is pulling from
<wgrant> Oh
<wgrant> There's extra stuff in there
<wgrant> wsgi.input
<StevenK> (Pdb) p request.form['field.filecontent']
<StevenK> <zope.publisher.browser.FileUpload object at 0x2abb382f71d0>
<wgrant> That sounds like it was correctly submitted, and to +addownloadfile, not the API
<StevenK> Which it was, yes
<StevenK> (Pdb) p request.form['file_content']
<StevenK> u'\x1f\...'
<StevenK> Right, broken like hell
<StevenK> wgrant: It's broken in request.items() too
<wgrant> Naturally.
<wgrant> that just iterates over the form items, doesn't it?
<wgrant> Not the raw request data
<StevenK> Then where would that be hiding?
<wgrant> In _environ. I assume ZFS parses that
<StevenK> (Pdb) p request._environ['wsgi.input'].read()
<StevenK> ''
<StevenK> Not so helpful
<wgrant> seek(0)
<StevenK> Content-Disposition: form-data; name="file_content"\n\n\x1f...
<wgrant> Right :)
<wgrant> You might be able to use ZopeFieldStorage to parse it more easily and get the raw content without parsing the MIME yourself
<StevenK> So it's broken everywhere?
<wgrant> Hmm?
<StevenK> But that is from the MIME?
<wgrant> What's wrong with it?
<StevenK> And it looks encoded already
<wgrant> It's a bytestring
<wgrant> Which is what we want
<wgrant> \x1f isn't an obvious test, since it's ASCII.
<wgrant> So decoding it as UTF-8 won't break
<wgrant> But that looks fine to me
<StevenK> name="file_content"\n\n\x1f\x8b\x08\x00\xcc\x03\x0fQ\x00\x03\xed\xce1\x12\x82@
<StevenK> Still looks okay?
<wgrant> Nothing in there looks like a U+FFFD
<wgrant> So indeed
<wgrant> Compare it to the data you gave it?
<StevenK> Don't know how to get it in that format
<wgrant> Hmm?
<wgrant> What format?
<wgrant> That's just the raw bytes
<wgrant> (but \x-escaped because you're repr()ing the str)
<StevenK> It's a tarball, so ...
<wgrant> open('foo.tar').read()[:20]
<StevenK> Ah
<StevenK> It is identical
<wgrant> Good :)
<wgrant> It would be a matter of great concern if it did not
<StevenK> Heh
<StevenK> So I want to rely on _environ['wsgi.input'] ? Seems like an awful hack
<wgrant> It is a terrible revolting hack
<wgrant> But if Zope doesn't give us another way to get it, then we have little choice
<StevenK> ZFS is just cgi.FieldStorage
<StevenK> ... which is nicely undocumented
 * StevenK stabs cgi.FieldStorage
<StevenK> wgrant: http://pastebin.ubuntu.com/1611421/
<wgrant> StevenK: Isn't that unicodeness check around the wrong way?
<wgrant> We want to reretrieve it if *has* been decoded
<wgrant> (we also want to run this past gary_poster or benji)
<StevenK> Yeah
<StevenK> Fixed
<wgrant> Also, that's really awful and I hope you pay for your crimes.
<wgrant> But it looks quite effective
<StevenK> Hahaha
<StevenK> I really don't want to use it
<StevenK> wgrant: The other half of that branch is the _decode resurrection
<wgrant> Right
<adeuring> good morning
<lifeless> http://webnumbr.com/launchpad-critical-bugsï»¿ is looking pretty good
<czajkowski> not bad for only having two people on there :)
<jml> heh
<jml> still more evidence against using centralized allocation of scarce resources to meet inexhaustible demand?
<czajkowski> wgrant: StevenK if either of ye are about I'd apprecite some help on answers trying to catch up from being off and some of them need yer help
<czajkowski> please
<czajkowski> https://bugs.launchpad.net/launchpad/+bug/1108790  bug or not a bug also
<_mup_> Bug #1108790: Ubuntu-launchpad uses google-analytics by default <Launchpad itself:New> < https://launchpad.net/bugs/1108790 >
<lifeless> czajkowski: well it has flattened off recently
<lifeless> czajkowski: but yeah
<lifeless> jml: possibly eveidence that changing things when the system is unstable leads to more instability
<jml> lifeless: heh, maybe
<wgrant> lifeless: Hmmm?
<wgrant> lifeless: We know from the lpstats graphs that the number of incoming bugs did not change significantly
<wgrant> We're just less hopeless at closing them
<lifeless> wgrant: presumably all the low hanging fruit :)
<lifeless> wgrant: have you repeated the root cause analysis flacoste did?
<wgrant> lifeless: No
<lifeless> wgrant: that was fairly conclusive that most criticals were self inflicted :)
<lifeless> IIRC
<lifeless> wgrant: how long is buildbot now?
<wgrant> lifeless: 38 minutesish
<czajkowski> hmm I still need to write up post fosdem review
<czajkowski> can I have another 4 hours in todays day please
<StevenK> czajkowski: Sure, if you have four hours less sleep.
<czajkowski> I am already running on low from the weekend of brussels, beer and geeks = late night chats and catch up
<czajkowski> was great fun
<czajkowski> though I thnk I've had enough waffles to last me till next year
<lifeless> czajkowski: amen :)
<czajkowski> heh
<czajkowski> it was very good this year , lifeless you ever been?
<lifeless> czajkowski: no, I haven't. I was at LCA though - same week :)
<czajkowski> ah not been there, this is a little closer for me to get to
<czajkowski> although there was a large USA attendees who all flew in for the weekend
<czajkowski> plus RMS arrived
<czajkowski> alhtough he was banned/asked not to attend the legal sessions
<lifeless> ROTFL
<lifeless> I probably shouldn't be so amused.
<lifeless> But still, I am.
<czajkowski> so was I when I heard
<czajkowski> there was much running around keeping him away from perople it seems
<czajkowski> he's now in ireland
<lifeless> man on a mission
<czajkowski> to aleniate a lot of people
<cjwatson> wgrant: Did you get a chance to look at bpph-phase?
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/unexport-updatepreviewdiff/+merge/146744
<wgrant> StevenK: https://code.launchpad.net/~wgrant/launchpad/setupCompleteBuilds-nonspecific/+merge/146751
<wgrant> StevenK: r=me
<StevenK> wgrant: Can't getSpecificJobs die as pointless now?
<wgrant> StevenK: No
<wgrant> StevenK: You need to get the specific jobs for Archive:+builds and Builder:+history
<wgrant> Because the underlying queries just give you BuildFarmJobs, so you need to translate them.
<StevenK> Right
<StevenK> wgrant: r=me
<wgrant> StevenK: Thanks
<StevenK> And Firefox hangs for 30 seconds because I dared to close a tab that contained Flash
#launchpad-dev 2013-02-06
<StevenK> wgrant: Would you hate me for using lp.services.webapp.adapter for this request munging?
<wgrant> StevenK: adapter is more to do with the DB
<StevenK> wgrant: I can add lp.services.webapp.utils if you wish, I can't see anything close-ish
<wgrant> StevenK: Or in publisher?
<StevenK> publisher works
<StevenK> wgrant: http://pastebin.ubuntu.com/1614625/
<wgrant> StevenK: You'll probably only want to refetch when you're called from the API
<wgrant> (by using eg. @callwith(from_api=True))
<wgrant> Otherwise adding an attachment or release file from the UI will find a request that lacks what it needs, or the field might have a different meaning
<StevenK> No, the field name is different
<wgrant> Right now, yes
<StevenK> It's field.<foo> from the UI
<wgrant> Then someone changes it and the world breaks
<wgrant> Far better to be explicit here
<wgrant> When committing evil, you want to be *really* sure that it's not going to have unintended consequences
<wgrant> Also, get_raw_form_value_from_current_request or something
<wgrant> refetch_file_content does not well convey the magnitude of the evil
<StevenK> wgrant: omg_it_burns_and_refetch ?
<wgrant> StevenK: Might even be an idea to assert in the function that it's an API request
<wgrant> Just in case
<wgrant> It might eventually be needed outside API requests, but the added paranoia would feel nice right now
<StevenK> wgrant: And what do you suggest as a name?
<wgrant> get_raw_form_value_from_current_request?
<wgrant> Maybe throw a 'horrid', 'evil', 'vile' or 'unsafe' in there somewhere
<StevenK> Which is horribly long
<wgrant> Good
<wgrant> Lucky it only has two callsites :)
<StevenK> The import is 80 characters
<StevenK> And now buildmailman fails?
<StevenK> wgrant: buildmailman dies due to:
<StevenK> no lists == nothing to do, exiting
<StevenK> make[1]: Leaving directory `/home/steven/launchpad/lp-sourcedeps/sourcecode/mailman'
<wgrant> StevenK: Is that a problem?
<StevenK> Yes, since make run fails
<wgrant> Fails how?
<StevenK> make: *** [compile] Error 1
<wgrant> Have you tried deleting lib/mailman and rerunning?
<StevenK> That's the next line
<StevenK> Compiling /home/steven/launchpad/lp-branches/handle-invalid-unicode-in-query-string-redux/lib/mailman/Mailman/versions.py ...
<StevenK> No updates are necessary.
<StevenK> make[1]: Leaving directory `/home/steven/launchpad/lp-sourcedeps/sourcecode/mailman'
<StevenK> make: *** [compile] Error 1
<StevenK> wgrant: ^ That's after deleting lib/mailman
<wgrant> StevenK: Perhaps make clean
<StevenK> wgrant: make clean && make lead to the no lists == nothing to do error
<StevenK> Handy. Something in my diff causes it
<wgrant> StevenK: Hm, but lp.services.webapp.publisher is fairly widely imported
<wgrant> So there should be minimal circular issues
<StevenK> I'll binary search through the diff after lunch
<StevenK> WAT
<StevenK> % bzr di lib/lp/services/webapp/publisher.py | head -n 37 | tail -n 1
<StevenK> +from lp.services.webapp.servers import WebServiceClientRequest
<StevenK> That is what causes buildmailman to lose its mind
<StevenK> So I guess it's circular, but eh ....
<StevenK> And now the FieldStorage is empty :-(
 * StevenK mutters at IProductRelease._getFileObjectAndSize
<StevenK> wgrant: It asserts it is passed a file or StringIO
<wgrant> StevenK: You're not giving it a StringIO?
<StevenK> FieldStorage returns an object that identifies itself as cStringIO.StringO
<StevenK> Ah, the critical bug didn't get re-opened when you reverted the fix?
<wgrant> No, I forgot to
<StevenK> Eh
<StevenK> I'll just link the High bug then
<wgrant> No
<wgrant> Reopen
<wgrant> I think
<StevenK> And then close the two of them?
<wgrant> It fixes both
<wgrant> So why not :)
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/handle-invalid-unicode-in-query-string-redux/+merge/146773
<StevenK> But I've just realized I don't have an XXX
<wgrant> StevenK: Reviewing cjwatson's branch atm (finally!), will do that after
<StevenK> Let me file a bug and add an XXX to both callsites.
<StevenK> Since you asked me to on the call this morning
<wgrant> Yeah
<wgrant> It's clearly a terrible hack, so deserves an XXX or three
<StevenK> wgrant: Against lazr.restfulclient ?
<wgrant> StevenK: LP
<wgrant> The hack is in LP
<lifeless> flacoste: o/
<StevenK> wgrant: Do I get a review now?
<wgrant> StevenK: You run it through StringIO in one case but not the other?
<StevenK> wgrant: Yes. IBug.addAttachment just wants to read() from it, whereas IProductRelease.add_file actually cares if it's a StringIO or file.
<wgrant> StevenK: Ah
<wgrant> StevenK: If there's a launchpadlib-based test for add_file, can you extend it to verify correct behaviour?
<wgrant> XXX and bug reference in the Function of Doomâ¢ too, pls
 * StevenK peers at this horrible doctest
<wgrant> Even if there isn't one already, they're pretty short to write (but long to run), so it's probably worth adding one
<StevenK> wgrant: There are two sections that add a PRF to firefox, just need to work out how to get the content of the file easily
<StevenK> Changing the content of one of the strings would be easy
<StevenK> '\x1f\x0cf\xff' seems good enough
<adeuring> good morning
<jtv> Guten Morgen adeuring
<adeuring> hi jtv!
<czajkowski> ello
<jtv> Hi there czajkowski
<czajkowski> jtv: hey hows things?
<jtv> czajkowski: nice and busy.
<jtv> Also, more expensive than last year.  :)
<czajkowski> why's that?
<jtv> Just a general observation.  Things are more expensive  than last year.  Apply to any given year.
<jml> jtv: deflation has been known to happen.
<czajkowski> jtv: I just moved out of london, it brought it down a meer fraction of cost
<jtv> jml: Mostly local though.  For the true pessimist there is always a lead lining _somewhere_ in the world.
<jml> jtv: :)
<jtv> Pessimism: because if failure is your goal, you really can't lose.
#launchpad-dev 2013-02-07
<StevenK> Failed example:
<StevenK>     print concrete_one_zero.files[0].libraryfile.read()
<StevenK> Differences (ndiff with -expected +actual):
<StevenK>     + None
<StevenK> :-(
<StevenK> wgrant: From what I can see, everything should be okay, but why does read() return None :-(
<wgrant> StevenK: You sure you opened it? You might even need to call read() on the object that gets returned from open()
<StevenK> read() will autoopen
<StevenK> (And autoclose, which is handy)
<wgrant> StevenK: Is it using a real librarian?
<wgrant> If you break in the test, can you see the file?
<wgrant> Have you checked the librarian log?
<StevenK> It's a doctest, breaking is hard
<lifeless> you could fix that
<StevenK> pdb inside a doctest has always broken
<StevenK> And the only way I know to fix it is to destroy all doctests
<wgrant> It'll break
<wgrant> It just won't have useful context
<wgrant> You can still poke around outside it
<StevenK> (Pdb) p self._datafile
<StevenK> <lp.services.librarian.client._File object at 0x10489890>
<StevenK> (Pdb) p self._datafile.read()
<StevenK> 'None'
<wgrant> Did that make a request to the librarian?
<wgrant> Can you seek?
<wgrant> What does it mean for it to return None?
<StevenK> *** ForbiddenAttribute: ForbiddenAttribute('seek', <lp.services.librarian.client._File object at 0x10489890>)
<StevenK> wgrant: Ah, but it isn't None, it's the string None
<wgrant> Ah, true
<wgrant> So maybe your code is buggy :)
<StevenK> Yes, I'm checking
<StevenK> (Pdb) p fs['file_content']
<StevenK> MiniFieldStorage('file_content', 'first attachment file content \xff')
<StevenK> (Pdb) p fs['file_content'].file
<StevenK> None
<StevenK> wgrant: http://pastebin.ubuntu.com/1618379/
<StevenK> wgrant: Does that address your concerns?
<wgrant> StevenK: Can you confirm that the test fails if you go back to the code that I reverted?
<wgrant> ie. without the reretrieval
<StevenK> I have already confirmed before I pasted the diff
<wgrant> Great
<wgrant> Sounds reasonable, then
<StevenK> wgrant: I thought those were your two concerns? A XXX in the function itself, and a test
<StevenK> wgrant: The MP is updated
<wgrant> StevenK: Looking
<wgrant> StevenK: Oh
<wgrant> StevenK: What about signature_content?
<StevenK> I think that one is immune
<StevenK> Let me check
<StevenK> In [6]: l.files[0].signature.read()
<StevenK> Out[6]: '-----BEGIN PGP...
<StevenK> It's ASCII-armored, so coercing to unicode will not negatively impact it
<StevenK> In [8]: f = open('/tmp/f.tar.gz.asc').read()
<StevenK> In [9]: lfa == f
<StevenK> Out[9]: True
<wgrant> StevenK: Yeah, but still
<wgrant> ASCII-armored sigs are designed to survive exactly this sort of thing, but we should probably apply this hack to all lazr.restful file inputs
<lifeless> you could fix zope.
 * lifeless waits for the laughter
<wgrant> s/laughter/stabbage/
<StevenK> wgrant: http://pastebin.ubuntu.com/1618447/
<wgrant> StevenK: :)
<StevenK> I can add a \xff to the signature content if you wish
<StevenK> Just to be sure
<wgrant> Might as well
 * wgrant lunches
<StevenK> wgrant: Back from lunch?
<wgrant> StevenK: Yeah
<StevenK> wgrant: Should I take the Branch:+register-merge critical?
<wgrant> StevenK: Worth a try
<StevenK> wgrant: So the method to find a branch needs a rewrite and new indicies?
<wgrant> StevenK: Don't think of it as a rewrite and new indices
<wgrant> Think of it as a redesign approximately from scratch
<wgrant> It may or may not need new indices
<wgrant> But the search method needs to be rethought with performance over more than 1000 branches in mind
<StevenK> wgrant: https://code.launchpad.net/~stevenk/launchpad/destroy-private-projects-feature-flags/+merge/147022
<wgrant> StevenK: r=me
<StevenK> wgrant: And my QA is done
<StevenK> wgrant: You want a NDT?
<wgrant> StevenK: Please :)
<wgrant> The indices are there now
<wgrant> So we should be good to go
<StevenK> And kills 4 criticals
<StevenK> You have a lock on LPS?
<wgrant> StevenK: Apparently. It's yours
<wgrant> I sadly can't really close the vocab critical
<wgrant> It's still pretty awful for bad names
<wgrant> Depending on the number of builds
<StevenK> Aww
<StevenK> wgrant: Are you going to land 7?
<wgrant> StevenK: Not just yet
<wgrant> Going to wait and see if the world ends
<StevenK> Fair enough
<wgrant> It's still safe to back out the ndt at this point.
<StevenK> Mmmm, 7 is the point of no return
<wgrant> Exactly
<StevenK> It's probably landable and deployable tomorrow
<wgrant> That's the plan
<StevenK> It's a good plan
<wgrant> Hm, I should fix tuolumne
* wgrant changed the topic of #launchpad-dev to: http://dev.launchpad.net/ | On-call reviewer: - | Firefighting: - | Critical bugs: <130
<adeuring> good morning
<jtv> Good morning adeuring
<adeuring> hi jtv!
<jtv> Nice weather today.  Let me just check if any of my mangoes are ripe yet.
<lifeless> hi
<lifeless> where should stale vcs mirrors be reported these days
<lifeless> https://code.launchpad.net/~testing-cabal/testtools/trunk only tracks up to the 24th jan
<lifeless> there have been 27 or so commits since spread over the interveneing period
 * wgrant guesses it's a https github import
<wgrant> Indeed it is
<jml> wgrant: is there an open bug re that?
<wgrant> jml: Yes
<jml> wgrant: got it. ta.
<wgrant> https://bugs.launchpad.net/bugs/1072461
<_mup_> Bug #1072461: Code import from github does not take latest commits <code-import> <git> <Launchpad itself:Triaged> < https://launchpad.net/bugs/1072461 >
<slank> Is there a way to get a list of branches for a user/project via the api? I'd like to grab the equivalient of code.lp.n/~user/project
<james_w> slank: I don't know of a way to do that without filtering client side
<slank> james_w: that's probably ok. perhaps there's a way to get branches for a user? I haven't found that either.
<james_w> slank: user.getBranches()
<james_w> slank: I can't link directly, but the second "Custom GET method" under https://launchpad.net/+apidoc/devel.html#person
<slank> james_w: ah. thanks!
#launchpad-dev 2013-02-08
<StevenK> wgrant: Very vague plan: http://pastebin.ubuntu.com/1622793/
<wgrant> StevenK: Probably
<StevenK> wgrant: You don't object?
<wgrant> StevenK: You need to think about how it makes sense to match on unique_name
<wgrant> eg. if I search for 'launchpad', I probably don't want to find every branch in the launchpad project
<StevenK> wgrant: Right, maybe I only want to do that for the lp: and code.*.launchpad case
<StevenK> Just add Branch.unique_name = '<parsed out bit>' to clauses and move on
<wgrant> Well, I wouldn't invoke the search infrastructure at all if you're given a URL
<wgrant> just use getByURL or whatever the method is
<StevenK> And assume the user can view it?
<wgrant> That should only find things if the user can view it
<wgrant> I think
<StevenK> Well, we can do getByURL, and return the branch if visibleByUser, but that might make you stab me
<wgrant> If getByURL doesn't do an access check then that is the correct thing to do
<adeuring> good morning
<jtv> Hi adeuring
<adeuring> hi jtv
#launchpad-dev 2013-02-10
<trkv> hi all, I have a little bugfix to implement, but I am unsure if there already were any bugreports or thoughts related to it
<trkv> there is a Rosetta with its translations import/export. When it exports an translation (manually into .po-file or into some bzr branch) it doesn't writes an Plural-Forms header, which should contain specific rules of the language of translation.
<trkv> It is an obvious bug, since such plural forms won't be properly compiled, but may be there're some reasons for such a behaviour?
<wgrant> trkv: It'll only export a Plural-Forms header if there are plural messages.
<wgrant> And it's been doing that for nearly 9 years now, so I suspect everything copes with it.
<wgrant> (in fact, gettext's exporter has the same behaviour, so I'd be surprised if anything *didn't* cope with it)
<trkv> hm
<trkv> so it probably a bug of Qt's lconvert
<trkv> I faced a message in buildlog, checked the other .po-file and thought that it behaves in the same way for all the files.
<trkv> now I see I was wrong
<trkv> ok, thanks anyway :)
<nha> Hi everybody; I'm considering writing a bot that interfaces Launchpad for a project that I'm involved in.
<nha> Basically, I would like to automatically run a large test suite (too large to be convenient for commit hooks etc.) whenever someone submits a Merge Proposal, and then add a comment to the Merge Proposal with the test results
<nha> The bot would run on my own server, and I don't think I need hand-holding with the API or anything, but I would like to know if there are any relevant suggestions or policies that I should know about
<nha> The stuff in the Wiki and API docs seems pretty much geared to people writing desktop applications, which is obviously a bit different as a use case
<cjwatson> nha: hm, there are various bots already that do that kind of thing: https://code.launchpad.net/~cjwatson/indicator-datetime/cleanup-timezone-monitor/+merge/145921 shows one of them in action
<cjwatson> I wonder if I can find the code ...
<cjwatson> nha: https://launchpad.net/jenkins-launchpad-plugin I think
<cjwatson> nha: the trunk seems to be private for some reason, but not all the branches are
<cjwatson> not quite sure how it's triggered, looking through it - you could ask somebody who hacks on that, if it interests you
<cjwatson> nha: lp:tarmac may help too
<nha> cjwatson: cool, thank you :)
<StevenK> wgrant: search_branches has been subsumed into branchcollection
<wgrant> StevenK: Great
#launchpad-dev 2014-02-05
<jtv> Is the bzr host broken?  IIRC it mirrors from a writable area to a read-only area, in which case it looks as if that mirroring isn't happening right now!
<jtv> For several hours now I think, new revisions that I've pushed to my branch have been failing to show up not only on my merge proposal, but also in attempts to land using tarmac.
<wgrant> jtv: Which branch?
<jtv> Hi wgrant! lp:~jtv/maas/validate-clashing-networks
<wgrant> jtv: I don't think you pushed to the right place.
<jtv> Odd... it's the remembered location.  Lemme check.
<jtv> It pushes to bzr+ssh://bazaar.launchpad.net/~jtv/maas/validate-clashing-network/
<wgrant> s
<jtv> !
<wgrant> vs not s
<jtv> *bash* *bash* *bash* thank you...
<wgrant> Heh :)
<jtv> and... my apologies for wasting your time.  :)
<wgrant> np
#launchpad-dev 2014-02-06
<bigjools> bzr: ERROR: Invalid url supplied to transport: "bzr+ssh://bazaar.launchpad.net/~julian-edwards/maas/xss-bug-1251336": no supported schemes
<bigjools> O_o
<StevenK> bigjools: No XSS bug fix for you
<bigjools> shhh sekrit :)
<bigjools> still hanging on here then StevenK?
<StevenK> bigjools: Eh, some interesting discussion happens in here from time to time
<bigjools> StevenK: occasionally
<bigjools> oh arse my branch is private and I wasn;t logged in.  Misleading error or what.
<lifeless> bigjools: like me and cody-somerville...
<bigjools> lifeless: I'd expect nothing less from you :)
#launchpad-dev 2014-02-07
<mpt> Hi, Iâm stuck on step 8 of <https://dev.launchpad.net/Running/LXC>: âssh -A lpdev.local to connect to the container.â I get the error: âssh: Could not resolve hostname lpdev.local: Name or service not knownâ
<mpt> Do I need to add it to /etc/hosts or something?
<cjwatson> avahi is supposed to take care of that
<cjwatson> However, there can be problems if the container's networking hasn't come up properly
<cjwatson> What does "sudo lxc-ls --fancy" say?
<mpt> NAME   STATE    IPV4        IPV6  AUTOSTART
<mpt> -------------------------------------------
<mpt> lpdev  RUNNING  10.0.3.170  -     NO
<cjwatson> And you did step 5, installing avahi-daemon in the container?
<mpt> avahi-daemon is already the newest version.
<mpt> </quote>
<cjwatson> Does "sudo avahi-browse -at | grep lpdev" print anything?
<mpt> cjwatson, it exits without output
<cjwatson> Hmm
<cjwatson> I have to admit that I stopped using lucid containers for LP a while ago
<cjwatson> wgrant: possibly we should update Running/LXC to recommend precise
<cjwatson> mpt: It might be worth retrying with precise - you can call the container something different like "precise-lpdev" to avoid having to redo the lucid work if that turns out not to help
<mpt> ok, Iâll try that, thanks
<cjwatson> There's only a limited extent to which it makes sense to try to fix lucid at this stage, I think
<cjwatson> And the majority of LP is on precise now ...
<mpt> Doing the lxc-create, Iâm getting a lot of âCan not write log, openpty() failed (/dev/pts not mounted?)â
<mpt> Does that mean Iâm out of disk space?
<cjwatson> Shouldn't, that literally just means /dev/pts isn't mounted in (I suppose) the container
<cjwatson> Probably a bug in the lxc template
<mpt> ok
<cjwatson> Relatively harmless during creation though
<mpt> Well, the container wonât start up like the lucid one did: âlpdev-precise login: <4>init: setvtrgb main process (270) terminated with status 1â
<mpt> Oh, I just needed to press Enter X-)
<cjwatson> Ah, yeah, that's just overlapping output
<cjwatson> Unsightly but harmless
<mpt> Success: Thanks cjwatson
<cjwatson> Great
<wgrant> cjwatson: Indeed. I'll run through it with precise next week just to make sure nothing else needs fixing.
 * mpt wonders what the past tense of âtroubleshootâ is. Troubleshooted? Troubleshot?
<cjwatson> investigated
<cjwatson> It's one of those irregular verbs. :-)
<mpt> Troubleshat
<wgrant> Heh
<cjwatson> problemgeschossen [yes yes I know]
<jpds> mpt: Now ask yourself what the past tense of 'tweet' is.
<mpt> jpds, I believe you are referring to http://www.theguardian.com/politics/2009/jul/29/david-cameron-apology-radio-twitter
<cjwatson> I discovered around new year that the Irish for "to tweet" is tvuÃ­teÃ¡il, which is rather mine
<cjwatson> *nice
<cjwatson> (where did "mine" come from?)
<jtv> cjwatson: If I were of the Freudian persuation, I'd say you were greedy.  :)
#launchpad-dev 2014-02-08
<fully_human> Hello. I'm getting my feet wet fixing a bug. I haven't fully done a bug fix yet (a few attempts) and am hoping a small bug like https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/807861 can help me get started.
<_mup_> Bug #807861: typo in ../src/widgets/toolbox.cpp:4685 <bitesize> <patch> <raring> <Inkscape:Fix Committed> <inkscape (Ubuntu):In Progress by johnsmith1234> <https://launchpad.net/bugs/807861>
<fully_human> So far I've apt-get sourced the code. I'm assuming I now need to do bzr branch?
<fully_human> Hello. I'm getting my feet wet fixing a bug. I haven't fully done a bug fix yet (a few attempts) and am hoping a small bug like https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/807861 can help me get started.
<_mup_> Bug #807861: typo in ../src/widgets/toolbox.cpp:4685 <bitesize> <patch> <raring> <Inkscape:Fix Committed> <inkscape (Ubuntu):In Progress by johnsmith1234> <https://launchpad.net/bugs/807861>
<fully_human> So far I've apt-get sourced the code. I'm assuming I now need to do bzr branch?
<fully_human> Hello. I'm fixing my first bug (bug week is as good a time as any). I know I'm supposed to write a test case for the bug. If the bug is a typo within the source code would a good test be to parse the source line in question and verify it?
<fully_human> The bug I'm fixing is https://bugs.launchpad.net/ubuntu/+source/inkscape/+bug/807861
<cjwatson> I applaud your enthusiasm for testing, but there's really no need to write tests for that kind of thing
<cjwatson> Anyone who requires you to do so doesn't really understand what testing is for :-)
<cjwatson> (By the way, this channel is for development of Launchpad itself.  You perhaps meant #ubuntu-motu or #ubuntu-bugs or something)
<fully_human> cjwatson, Ah, thanks.
<cjwatson> (Maybe not #ubuntu-bugs, that's more for bug triage)
#launchpad-dev 2015-02-03
<cjwatson> wgrant: Could you find a moment to have a look at https://code.launchpad.net/~cjwatson/launchpad/ul10nstats-security-distribution/+merge/248257 ?  I'd like to unblock dpm.
<wgrant> We reall need to demolish that script.
<cjwatson> I know
<cjwatson> Been meaning to take up the half-done branch to do so
<cjwatson> But time ...
<cjwatson> wgrant: Would also be nice to get https://code.launchpad.net/~cjwatson/txpkgupload/sftp-interface-oopses/+merge/247459 going, if you have any time free from the sprint to stare at more than one-liners.  (Not that I'm obsessed with proving that this deployment process can not suck, or anything)
<wgrant> cjwatson: We should really trim down txpkguplad, but that looks good. Thanks.
<cjwatson> Yes ... thanks
<wgrant> Hopefully the deployment bits are fixed.
<cjwatson> Should be.  I'd like to battle-test them.
<wgrant> Definitely.
<wgrant> The old secondary LP trees still exist, too, don't they?
<cjwatson> So far, yes
#launchpad-dev 2015-02-04
<thomi> cjwatson: wgrant, blr: For your consideration, when you have time: https://code.launchpad.net/~thomir/launchpad/devel-set-content-type/+merge/248207
<cjwatson> thomi: Morning.  Do you need help landing your set-content-type branch?
<thomi> cjwatson: hi - wgrant approved it. I was going to ask - what's the process here? Do I need 2 reviews or something?
<cjwatson> thomi: No, one is fine.  (That was true even when there were lots of developers.)
<thomi> so, I can top-approve?
<cjwatson> Some of https://dev.launchpad.net/PreMergeReviews and linked stuff is probably still up to date.
<cjwatson> Right, top-approve and then I can land it for you (presumably your key isn't yet in PQM).
<thomi> cool
<thomi> I believe it's not
<thomi> cjwatson: I don't have perms to top-approve :-/
<cjwatson> OK, I've done that for you
<thomi> thanks :D
<cjwatson> It's on its way now.  You should shortly see it appear on http://lpbuildbot.canonical.com/waterfall, and you'll be e-mailed with the result of testing.  Please take action if it fails
#launchpad-dev 2015-02-05
<cjwatson> wgrant: Do you happen to have a way to get hold of the output of RAISE LOG commands in plpgsql trigger functions during tests?  I have a feeling that LP_DEBUG_SQL=1 is not enough to actually get the relevant bits of log printed
<cjwatson> Oh, I guess I can go and look in /var/log/postgresql/postgresql-9.3-main.log
<cjwatson> Not as good as it winding up on my terminal but it'll do.
#launchpad-dev 2015-02-06
<stub`> cjwatson: I believe you can access the messages via the database connection after executing a statement, but I can't remember the details and never bothered.
<stub`> One of many reasons to avoid stored procedures when possible :)
#launchpad-dev 2015-02-07
<gorille> hello
<gorille> where can I contact the launchpad support?
<gorille> (without create a launchpad account)
<jelmer> gorille: #launchpad
<gorille> yep, I'm on #launchpad --'
#launchpad-dev 2015-02-08
<rpadovani> cjwatson, since I'm curios and I follow your work on launchpad, I'm quite happy for your lasts MR - how many time do you think will need to have git support on lp? :-)
#launchpad-dev 2016-02-10
<xnox> wgrant, you might find this funny
<xnox> so i've just added a disk "pool" to libvirt
<xnox>  /dev/disk/by-path/
<xnox> works great for dasd
<xnox> i do wonder if i do the same on my laptop, and "boot" my windows 10 in qemu -> how well would it feel about it.
#launchpad-dev 2016-02-12
<tigerite> Hi, is there some issue with Launchpad publishing packages today? Many of mine are spending a long time "awaiting publication" after building..
<cjwatson> tigerite: Yes, there's a handful of very large and popular PPAs taking up all that system's outgoing bandwidth, which means it has very little bandwidth available for downloading packages to publish from Launchpad's core systems ...
<cjwatson> tigerite: It's an anomalous event but it seems to be mostly legitimate traffic, so for the moment, we're just going to need to wait for it to calm down naturally
<cjwatson> tigerite: The PPA publisher is running, just very slowly
<tigerite> No worries, just was wondering as it's been fine until today, but that makes complete sense
<cjwatson> We're looking at ways to make it a bit more resilient in case something like this happens again
<cjwatson> But, well, Friday evening
<tigerite> Yeah, it'll probably calm down over the weekend
<cjwatson> Things like this normally last less than a day
<cjwatson> (cron cycles etc.)
<tigerite> By the way is this a good place to ask for a quota increase if I should need it? I did leave a question on Launchpad but didn't hear back, and then chained PPAs instead, but I may after all need a small increase depending on how much space boost and virtualbox end up taking
<cjwatson> tigerite: Leaving a question is normally the best way and we normally do handle those reasonably quickly; we must just have missed handling that one in time
<tigerite> No problem, the space is fine at the minute, it's funny though how quickly 2Gb goes! I already had to trash two PPAs as the binaries got "stuck" :)
<cjwatson> We're happy to issue quotas for what looks like reasonable use.
<cjwatson> Er, increase quotas.
<tigerite> That's cool. I really don't want to trash this one, I've uploaded 50 packages (not all built at the mo) and more to come, making dependencies play nice is a challenge, certainly!
<tigerite> Anyway thanks for all the help and will keep checking to see if my packages get published this evening ;)
<tigerite> The longest one's been 4 hours in the queue, heh!
<cjwatson> Yeah, our last run took about five hours
<cjwatson> We're looking at options
<tigerite> At least it happened on a Friday..
<tigerite> And, packages are uploading fine now, which is a big improvement on earlier in the day :)
<cjwatson> PPA publishing issues should hopefully improve very shortly
#launchpad-dev 2018-02-08
<mwhudson> huh https://code.launchpad.net/+code-imports?field.review_status=FAILING 403s
<mwhudson> i guess there is a private code import in there?
<wgrant> mwhudson: Yeah, that happens occasionally.
#launchpad-dev 2020-02-03
<stub> Having the test suite rewind the database is best done by not using the system PostgreSQL service, but having it run the postgres executable on a DATADIR itself. It is easy then to kill it and reset the DATADIR.
<stub> We didn't do it *at the time* because it was slower than keeping the process running a creating a new database from a template.
<stub> But those timings change every release.
<wgrant> It's still slower
<wgrant> Well, it was ~2y ago when I last tested
<wgrant> Startup isn't quick.
<wgrant> IMO the most likely way to optimise further is to have another thread/process keeping a pool of fresh DBs available that can just be renamed across.
<wgrant> There are also possibilities around causing the librarian to run in the same snapshot as the main testrunner (and testrunner-appserver, where applicable), so the commit after librarian adds can be optimised out in the test suite.
<SpecialK|Canon> cjwatson: nice!
<cjwatson> ilasc: go ahead and top-approve https://code.launchpad.net/~ilasc/launchpad/+git/launchpad/+merge/377875 when you're ready
<ilasc> cjwatson thanks! done
<cjwatson> Could I have reviews of https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378126 and https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378131 ?  Simple-ish dependency upgrades
<ilasc> on it now
<cjwatson> Thanks
<cjwatson> More py3 reviews wanted: https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378430 (dep upgrade), https://code.launchpad.net/~cjwatson/lazr.restful/wsgiref-py2/+merge/378432 (setup.py tweak), https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378459 (dependency adjustments), https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378460 (large, ...
<cjwatson> ... bulk conversion to six.moves.urllib.*)
<cjwatson> Other than the above, FWIW, all it takes to get the virtualenv building on py3 is: (1) PYTHON := python3 (2) remove bzr, mailman, meliae, Paste*, subvertpy (3) upgrade wsgi-intercept and FormEncode
<cjwatson> subvertpy needs non-trivial work to unblock removing bzr properly, as previously discussed, but everything else is in progress
<cjwatson> Then there's a lot to do before the rest of the build will work, because building API documentation tends to import basically everything.  And running very much of the test suite before lazr.restful at least sort of works is going to be hard.
<SpecialK|Canon> That's awesome
<SpecialK|Canon> Nice work
<cjwatson> https://github.com/cdent/wsgi-intercept/pull/61   so many yaks, and some of them are camped out in other people's houses
<tomwardill> I'd say 'networks, not even once', but it appears that my computer agrees
<tomwardill> It's installing things into the build LXD, while the firewall is active!
<tomwardill> shame that's as far as it gets, but still... it did a thing!
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378477   another py3 improvement, gradually disentangling stuff
<pappacena> Done!
<cjwatson> cheers
#launchpad-dev 2020-02-04
<cjwatson> Any objections to me self-approving https://code.launchpad.net/~cjwatson/lazr.restful/py3-print/+merge/378511 ?  I don't think it makes sense to have somebody else spend their time reading a bulk print syntax conversion
<ilasc> cjwatson: no objections from my side
<cjwatson> landed, thanks
<cjwatson> https://code.launchpad.net/~cjwatson/lazr.restful/wsgiref-py2/+merge/378432 wants an actual review, I think, but is also very short
<cjwatson> And https://code.launchpad.net/~cjwatson/lazr.restful/py3-raise/+merge/378513
<cjwatson> I'd also like reviews of https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378430 and https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378459, please - more various dependency mangling for py3
<cjwatson> https://code.launchpad.net/~cjwatson/lazr.restful/six-urllib/+merge/378515
<cjwatson> And https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378518 to upgrade pip
<tomwardill> cjwatson: GIT_PROXY_COMMAND appears to not be doing anything
<tomwardill> I've edited the script to create a file in /tmp when it's run
<tomwardill> but no file appears
<tomwardill> "the script" = snap-git-proxy
<cjwatson> tomwardill: Which git invocation is failing?
<tomwardill> clone
<cjwatson> tomwardill: Outside the docker container?
<tomwardill> yep
<tomwardill> https://pastebin.canonical.com/p/vWjcSTgWR9/
<cjwatson> tomwardill: Have you tried stracing git?
<tomwardill> not yet, my strace parsing is not good.
<tomwardill> will give it a try though
<cjwatson> add strace to deps and wrap strace -f -s1024 -tt around the git call
<cjwatson> then you should get something useful in the build log
<cjwatson> happy to have a look / walk you through it if you can get a trace
<tomwardill> righto, trying
<cjwatson> but you could start by searching the trace for snap-git-proxy and seeing if it's e.g. trying to exec it but failing
<cjwatson> Can I have a review of https://code.launchpad.net/~cjwatson/launchpadlib/py38-access-token/+merge/378523 to fix a crash on focal please?
<tomwardill> sometimes, I dislike pythons string syntax if you forget the , in a list
<tomwardill> looking
<tomwardill> cjwatson: +1
<cjwatson> Thanks
<tomwardill> cjwatson: snap-git-proxy doesn't appear in the strace: https://pastebin.canonical.com/p/Dv4vNfh5b2/
<tomwardill> (I ctrl-c'd when it looked like it had entered a polling/timeout loop)
<cjwatson> tomwardill: Could you add -v to the strace arguments so that we get unabbreviated versions of the environment variables in subprocesses?
<cjwatson> tomwardill: GIT_PROXY_COMMAND is actually only for git://
<tomwardill> aha!
<cjwatson> tomwardill: For https://, git should honour https_proxy
<tomwardill> aha! aha!
<tomwardill> right.
<tomwardill> that might explain it
<tomwardill> I'll get a trace with -v and then try and work out why https_proxy isn't behaving
<tomwardill> cjwatson: okay, it looks like what ever is meant to be running on the buildd machine on 8222 isn't actually running
<tomwardill> looks like that's started in startProxy in SnapBuildProxyMixin
<tomwardill> oorrrr... there'
<tomwardill> there's a firewall problem
<cjwatson> Did you remember to call that?
<cjwatson> The local proxy on 8222 should write access logs to the build log
<cjwatson> lpbuildd/oci.py:        args.extend(self.startProxy())
<cjwatson> Hm looks OK
<tomwardill> yeah, i mostly suspect firewall
<tomwardill> just constructing a test environment to find out
<cjwatson> OK, if you don't get anywhere that way, I'd consider stracing (only) the top-level launchpad-buildd process as the build is running and looking for CONNECT requests
<tomwardill> aha! progress
<tomwardill> `ufw allow in on lpbuilddbr0 to any port 8222` did the trick
<tomwardill> and now I'm failing in docker, which is more what I expected
<cjwatson> Ah good
<tomwardill> https://docs.docker.com/config/daemon/systemd/ well, that proxy section is a bit ergh
<SpecialK|Canon> specifically...?
<cjwatson> Easier if you put stuff in place before installing docker, I expect (since then you don't need to restart anything)
<tomwardill> one step further down the line...
<tomwardill> 2020-02-04 16:56:20+0000 [-] Returning build status: OK
<tomwardill> IT LIVES!
<SpecialK|Canon> w00t
<tomwardill> okay, wasn't actually all that bad a change, just took a while to get there...
<SpecialK|Canon> tomwardill: this Issue just went past on my timeline and I thought of you https://github.com/docker/for-linux/issues/690
<tomwardill> SpecialK|Canon: thatâs the same problem as the lxd one I mentioned in the meeting
<SpecialK|Canon> nodnod
<cjwatson> wgrant: Could you have a look at https://code.launchpad.net/~cjwatson/lazr.restful/py3-declarations/+merge/378548, please?  (I think it's probably a bit much to ask people not very familiar with lazr.restful to review that.)
#launchpad-dev 2020-02-05
<cjwatson> Could I have reviews of https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378473 and https://code.launchpad.net/~cjwatson/lazr.restful/py3-no-cmp/+merge/378531 ?
<cjwatson> Both short
<cjwatson> ilasc: thanks
<ilasc> +1
<cjwatson> Landing pappacena's audit trail stuff, if I can get buildbot to not be stupid
<ilasc> :)
<cjwatson> tomwardill: Do you think I can make the index on OCIFile (build, layer_file_digest) unique?
<tomwardill> I think so
<cjwatson> Can't see why a given build would ever have more than one file with the same layer_file_digest
<tomwardill> yeah, same
<cjwatson> tomwardill: And in https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/374673, William asked if we might need to look up OCIFile by layer_file_digest globally (i.e. without a context build), for index purposes.  What do you think?  It'd be easy enough to add an OCIFile (layer_file_digest) index
<tomwardill> I don't think it's required in the normal operation of things, but might be useful for garbo?
<cjwatson> tomwardill: Do we not need it for sharing of layer files?  I've forgotten exactly how you were doing that
<tomwardill> oh, good point!
<tomwardill> yes, it's needed for that
<cjwatson> The versions of your draft code that I could find didn't do sharing, I think
<cjwatson> But yeah, presumably there are two uses: one is reassembling layers when doing a registry push, and the other is sharing
<tomwardill> the end result is here: https://git.launchpad.net/~twom/launchpad/tree/lib/lp/oci/model/ociregistryclient.py?h=docker-registry-upload#n120
<tomwardill> but there's a part in the build artifact retrieval that checks if the file already exists in the librarian
<cjwatson> I found https://git.launchpad.net/~twom/launchpad/tree/lib/lp/archiveuploader/ociupload.py?h=docker-registry-upload but that seems to add unconditionally
<tomwardill> indeed
<tomwardill> fairly sure I did actually write that code...
 * tomwardill is unsure where though
<cjwatson> OK, no big deal, we knew that was draft
<cjwatson> tomwardill: Could you have a look over the last four commits in https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/374673 and make sure you're OK with them before I land that?  The OCIRecipe.ociproject â OCIRecipe.oci_project renaming will require a bit of work on your end, I'm afraid, but the rest should be transparent
<tomwardill> righto, will have a look
<tomwardill> cjwatson: they look good to me
<cjwatson> Thanks, will land after the standup
<cjwatson> I'll sort out the test failures from Thiago's branches
<cjwatson> Could I please have reviews of https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378599 and https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378600 ?  The first is a testfix
<cjwatson> Urgh, and db-devel is broken now too, faff faff faff
<cjwatson> OK, I also need a review of https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378602 to fix db-devel
<tomwardill> +1 on the latter
<tomwardill> I'll have a look at the others in a mo
<cjwatson> cheers
<tomwardill> trying to extract myself from the mess I've made in the tests
<cjwatson> Tell me about it ...
<cjwatson> I should go for a walk though, doing too much at once
<cjwatson> tomwardill: Have you had a chance to look at the other testfix at least?
<cjwatson> Would like to unblock devel before I finish today
<tomwardill> argh, sorry. Looking now
<tomwardill> got lost in trying to constract tarfiles in python :)
<tomwardill> +1 to both :)
<cjwatson> tomwardill: Did you find lp.services.tarfile_helpers?
<cjwatson> I realise that's in LP and not in launchpad-buildd, but it might give an idea
<cjwatson> And thanks
<tomwardill> aha, now I realise why I had a known file checked in
<tomwardill> otherwise the digests change every time (due to file access times, etc)
<tomwardill> can probably mock that out though
<tomwardill> mock/fixture/appropriate
<cjwatson> An alternative would be to commit documentation/scripting/whatever for building the test file.  I suspect mocking etc. will be less effort though
<tomwardill> yeah
<tomwardill> but it's beer, pizza and DnD night, so it'll have to wait till tomorrow :)
<cjwatson> Heh.  Enjoy
<jelmer> cjwatson: our plan for breezy is to create a 3.1 branch which will support python 2 and 3, and only support python 3 in trunk
<jelmer> We'll merge any changes necessary for launchpad into the 3.1 branch
<jelmer> (such as changes necessary for SVN support)
<cjwatson> jelmer: OK, that sounds reasonable - thanks for letting me know
<cjwatson> I started trying to see if I could work out what's up with subvertpy, but it's a slow debugging process and I'm not sure whether I'll be up to it
<cjwatson> And this is in parallel with plugging away at ~everything else :-)
<roadmr> subvertpy mangles mentally into "pervy" and downhill from there
#launchpad-dev 2020-02-06
<tomwardill> just when you think you're done with the firewall things... it strikes back!
<tomwardill> just spent 10 minutes wondering why my bzr push wasn't working...
<ilasc> tomwardill: was trying to think of something constructive to reply to that... came up with nothing :) I was pushing to the wrong repo yesterday, spent an hour wondering why things are not working as they should :D
<tomwardill> computers: how do they work!?
<wgrant> They don't.
<tomwardill> ... a valid point
<wgrant> I always drop in for the valuable contributions.
<SpecialK|Canon> <3
<ilasc> LOL
<tomwardill> cjwatson: I'm getting the Mir thing on running tests now too
<cjwatson> I haven't had time to debug it, so if you feel the urge then please do
<cjwatson> It doesn't happen in the wrapper I normally use, only when I ssh into the container and run tests directly with bin/test
<tomwardill> yeah, same
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378658 is another py3 dependency upgrade
<cjwatson> full test suite passed
<ilasc> do we feel strongly about names for the migration endpoint ? /migrate or /inject ?
<ilasc> what are we leaning towards ?
<cjwatson> ilasc: inject seems more explicit; I'd go with that
<cjwatson> migrate leaves the direction unclear
<ilasc> cjwatson: excellent, thanks! agreed
<pappacena> +1 for inject. We could need this endpoint for other purposes, other than migration
<ilasc> and forgot to say in Standup: thank you for taking on the webhooks QA and test issue!
<ilasc> cool, we're all in agreement, thanks guys!
<cjwatson> I was feeling slightly guilty about stealing that from you, but you did say you wanted to get onto lp-signing work
<cjwatson> And as it happened writing target-generic tests for this turns out to be weirdly difficult
<cjwatson> Something very odd going on in the innards of the navigation menu system
<ilasc> hmmm.... definitely no need to feel guilty, that would've been a 3 months time sync for me by the sound of it, very glad I didn't step on that particular landmine at this point - really appreciate you looking at it, you're right I did want to get to lp-signing as soon as possible
<cjwatson> ok :)
<cjwatson> ilasc: https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378660
<ilasc> wow! that was fast! looking now
<cjwatson> Well, I was working on it most of the morning :)
<SpecialK|Canon> Agreed re inject, fwiw
<cjwatson> Including lots of "why on earth is the navigation menu not showing up at all?"
<ilasc> SpecialK|Canon: +1
<ilasc> cjwatson: sounds like u had my kind of morning, however the first part did make laugh as in my world it would translate to "well I was working on it most of this spring" :)
<ilasc> but I see what you mean on the navigation topic
<tomwardill> cjwatson: the rename to 'oci_project' in the DB patch, are you intending to backport that fix to 'OCIProjectSeries'?
<cjwatson> tomwardill: Renaming DB columns is kind of unreasonably painful.  I'd suggest it might be a good idea to paper over it at the app level though (i.e. oci_project_id = Int(name='ociproject', allow_none=False); oci_project = Reference(oci_project_id, "OCIProject.id"))
<cjwatson> tomwardill: Sorry, I should have caught it before
<tomwardill> well, the rename wasn't a thing before this patch :)
<cjwatson> Yeah, but William is right that we've preferred this style in most new things for a while
<tomwardill>  Ran 48 tests with 0 failures, 0 errors, 0 skipped in 7.600 seconds
<tomwardill> now to re-add all the tests I've taken out
<cjwatson> Ugh, I really hate system-site-packages, so confusing
<tomwardill> indeed
<tomwardill> I've had a fair few disagreements with that
<cjwatson> I'd love to stop using it, but python-apt, mostly
<cjwatson> https://github.com/sivel/python-apt-wheel   not quite the shape of thing I'd ideally like, but I wonder if it'd be worthwhile
<tomwardill> that seems to be a lot of technology involved
<cjwatson> Right, ideally we'd just unpack the .deb and slam it into a .whl
<cjwatson> (We have a few other system Python dependencies too; it's never been worth solving all of them without a strategy for python-apt)
<cjwatson> Also would need to think about how it interacts with OS upgrades
<tomwardill> cjwatson: given the name uniqueness constraint on OCIRecipe, where is best to check for existing recipes with the same name on creation? the .new method of OCIRecipeSet?
<cjwatson> tomwardill: I think that's our usual strategy, ues
<cjwatson> *yes
<cjwatson> Compare SnapSet.new
<tomwardill> cool, thought so
<SpecialK|Canon> I've lost count of how many times I've been bitten by MoinMoin syntax not being MD/rST
<SpecialK|Canon> I only have enough room in my brain for a small number of markup languages
<cjwatson> tomwardill: Could you have a look at https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378670 ?  That's my system-site-packages nightmare for today
<tomwardill> on it
<cjwatson> And addresses the reason that qastaging isn't updating
<cjwatson> Also staging in fact
<cjwatson> dogfood was OK because it updates in place so had a cached wheel
<cjwatson> But production would run into the same thing
<tomwardill> well, it's kind of ergh-ish, but all fixes for this type of thing are :)
<tomwardill> +1, lgtm, glad I didn't have to write it.
<cjwatson> I would feel exactly that way if I hadn't had to write it
<cjwatson> Thanks, and agreed
<tomwardill> cjwatson: Storm is giving me "RuntimeError: Property used in an unknown class"
<tomwardill> query looks like this: https://pastebin.canonical.com/p/tKWcSKWNTs/ in OCIRecipeSet
<cjwatson> tomwardill: Can I see the OCIRecipe model?
<cjwatson> Query itself looks OK
<tomwardill> cjwatson: https://pastebin.canonical.com/p/kGHKKWdc2p/
<tomwardill> oh wait
<tomwardill> that's the interface
<tomwardill> sec
<cjwatson> I was going to say
<tomwardill> cjwatson: https://pastebin.canonical.com/p/mV2nHh8Wvh/ slightly better
<cjwatson> tomwardill: That looks OK to me.  Um.  What's the traceback?
<cjwatson> tomwardill: Or maybe push WIP to a temporary branch and I can try it
<tomwardill> sure, one sec
<tomwardill> cjwatson: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+ref/runtime-errors
<tomwardill> test is `lp.oci.tests.test_ocirecipe.TestOCIRecipeSet.test_new`
<cjwatson> OK, give me a bit to build that
<tomwardill> cjwatson: I've got it
<cjwatson> Oh?
<tomwardill> passing 'owner' to self.exists, rather than 'oci_project'
<tomwardill> stupid copy and paste error
<tomwardill> (found it by debugging at the point of raise and wondering why it was searching the Person class)
<cjwatson> Ah right, wrong caller
<cjwatson> Got it
<cjwatson> pappacena: Audit trail stuff looks good on dogfood.  The only comment I have is that the colspan="2" thing doesn't look quite right on all queues.  On the Rejected queue the audit trail appears under the file list, which is reasonable enough.  But on the Done queue there's no checkbox column and so it appears under the version instead, which looks odd
<cjwatson> pappacena: Example of the latter is https://dogfood.paddev.net/ubuntu/xenial/+queue?queue_state=3&queue_text=httmock
<cjwatson> pappacena: I think you need something conditional on view/availableActions there (see a bit further up in lib/lp/soyuz/templates/distroseries-queue.pt)
<pappacena> uhm... yes, it doesn't look alright this way.
<pappacena> Thanks for showing. I will try to reproduce locally and open a MP later today
<cjwatson> It's deployable like this, just a little odd-looking
<cjwatson> Thanks for this feature, I bet it will make some people very happy
<pappacena> I hope so! :-)
<pappacena> I'll work on a fix today... let me just finish something I'm in the middle here with the signing service...
<cjwatson> Thanks
<cjwatson> I've done most of the QA, but I need to wait for my fix-clean-build patch to finish landing so that (qa)staging come back up before I can get any further
<cjwatson> So possibly a deployment tomorrow late morning ish, which is always nice for the snap store weekly report
<pappacena> Cool! I'll try to have it ready to review by the end of the day today
<pappacena> cjwatson: https://code.launchpad.net/~pappacena/launchpad/+git/launchpad/+merge/378679
<pappacena> The fix for the extra colspan when there is no action
<cjwatson> Thanks, looking
<cjwatson> pappacena: one query
<cjwatson> (in a comment there)
<pappacena> Sure. I will check in a minute
<pappacena> Replied there... I needed to double check and test something about your comment.
<cjwatson> pappacena: of course you're right - sorry for my confusion.  Go ahead and land at your convenience
<pappacena> No problem! I got a bit confused too, and had to check to make sure. ;-)
<pappacena> I'll top-approve now
#launchpad-dev 2020-02-07
<wgrant> cjwatson: Replied to your bugsummary triggers MP, finally. I think my revised version is cleaner, but interested to hear your thoughts.
<wgrant> https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/373765
<wgrant> Would be a bit nicer were it not for the lack of anonymous composite types, and an apparent inability to do a FOR loop with a list of scalars despite the error message saying that it is possible.
<cjwatson> wgrant: Thanks, will look with interest once I've sorted out staging
<tomwardill> fixed a test! Broke 6 others.
<SpecialK|Canon> hurrah!
<ilasc> tomwardill: welcome to the club :)
<ilasc> SpecialK|Canon, tomwardill, pappacena, cjwatson: will be away for about 1 hour over lunch today (doctor app. I couldn't reschedule), I've let Tony know I won't make his meeting today
<tomwardill> oh, I forgot about the retro!
<ilasc> :) I will definitely make Standup
<SpecialK|Canon> We talked in London about if we still wanted to attend those or do our own
<SpecialK|Canon> I forget what we concluded and didn't take a note...
<ilasc> SpecialK|Canon I think we concluded to split them
<tomwardill> that's my memory too
<SpecialK|Canon> In which case I wouldn't be expecting you to attend "the store retro" today at all ;)
<tomwardill> excellent!
<SpecialK|Canon> I would be expecting me to schedule an LP retro though!
 * tomwardill claims that's what I originally intended
<SpecialK|Canon> I'll do that after the Store one
<SpecialK|Canon> all part of the grand plan, honest...
<cjwatson> retro> ack
<SpecialK|Canon> you might say that's...
<SpecialK|Canon> retro...ack..tive
<tomwardill> you might
<SpecialK|Canon> sorrynotsorry
<tomwardill> but you wouldn't
<tomwardill> because it's a terrible pun and you would be ashamed
<SpecialK|Canon> you're half right
<cjwatson> don't make me start relaying all the terrible astronomy institute whiteboard jokes here
<cjwatson> how do you hire a horse?
<cjwatson> put it on four bricks
<SpecialK|Canon> you say terrible
<SpecialK|Canon> I'm totally here for this
<cjwatson> (the whiteboard is headed "putting the LOL in cosmlology since 2017" or some such)
<SpecialK|Canon> amazing
<SpecialK|Canon> it would be a kindness if y'all would respond appropriately to Tony's calendar invite if you're not attending ;)
 * tomwardill does the thing
<cjwatson> done
<tomwardill> cjwatson: https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/376132 is updated (I think) for the latest DB patch changes, if you have a moment to look over it again
<tomwardill> https://code.launchpad.net/~twom/launchpad/+git/launchpad/+merge/377768 is my getopts rocketfuel patch from London if anyone has a mo to look at that too
<cjwatson> reviewed the second, will look at the first today
<tomwardill> ta
<cjwatson> tomwardill: did you forget to push the first?  I don't see your changes
<tomwardill> errr,I might've done a silly with branches
<tomwardill> sec
<tomwardill> cjwatson: done, had forgotten I was on a different branch and pushed the original
<cjwatson> tomwardill: Could you look over https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378716 ?  I think it should actually fix (qa)staging this time
<cjwatson> pappacena: Do you think you could look into removing auditor and friends from LP at some point, since we have the new approach in place now?
<cjwatson> Should get Django out of our virtualenv, I think ...
<pappacena> Sure... I just need to understand what auditor and friends are...
<cjwatson> That's the old unfinished microservice approach to the queue audit trail problem, which you've done with an extra DB table instead
<cjwatson> Was never finished enough to be enabled on production AFAIK
<pappacena> ahhh, now I remember.
<pappacena> Sure, I'll work on it as soon as I'm done with this signing thing integration, probably early next week
<cjwatson> Cool, no rush, thanks
<cjwatson> Hm, it did actually get deployed to staging, see https://portal.admin.canonical.com/C55785
<cjwatson> So I guess we should clean stuff up there
<cjwatson> I can help if needed but it might be a good exercise in chasing things down with IS :)
<pappacena> Sure! It will be good to better know people/processes/machines involved in this part
<cjwatson> Anyone else able to look at https://code.launchpad.net/~cjwatson/launchpad/+git/launchpad/+merge/378716 ?  I'd like to get this in ASAP since stuff is broken right now
<pappacena> On it
<cjwatson> Thanks
<pappacena> Approved
<tomwardill> sorry, was out getting a samwich
<cjwatson> pappacena: thanks
<pappacena> ð
<tomwardill> cjwatson: I can't find/create/write an early exit in the case of errors in the getopts line
<cjwatson> tomwardill: https://paste.ubuntu.com/p/xpM3DTv3zB/
<tomwardill> ah, neat!
<tomwardill> taht's that branch fixed up, seems to still work
<tomwardill> going to land
<tomwardill> in fact, I'l lwait till Monday morning :)
<wgrant> cjwatson: ah, can you fix my todo type names too? I was hoping to make them anonymous, but failed
<cjwatson> wgrant: Do you think I just need to try harder to make them anonymous, or that I should find better names?
<cjwatson> I assumed you'd meant "todo" as in "rows to process" rather than as in "need to fix this name"
<wgrant> cjwatson: I don't think it's possible to make them anonymous, unfortunately.
<wgrant> Nah, they should probably have bugsummary_temp_* names or something like that
<cjwatson> OK, will fix, possibly on Monday
